This section describes how to configure OER to exchange metadata with OSR using the exchange utility.

The Oracle Registry Repository Exchange Utility can be used to:

Before we can execute the utility, we need to configure the connections to OER and OSR. The following sections will show you how to do this.

<repository>
  <uri>http://<OER SERVR>:7101/oer</uri>
  <credentials>
    <user>admin</user>
    <password>*****</password>
  </credentials>
</repository>

http://<host>:<port>/<OER web app name>

<registries>
  <registry name="INTERNAL-DEV-OSR">
    <inquiryURI>http://<SERVER>:<PORT>/registry/uddi/inquiry</inquiryURI>
    <publishURI>http://<SERVER>:<PORT>/registry/uddi/publishing</publishURI>
    <securityURI>http://<SERVER>:<PORT>/registry/uddi/security</securityURI>
    <credentials>
      <user>admin</user>
      <password>*****</password>
    </credentials>
  </registry>
  <registry name=" INTERNAL-PROD-OSR ">
    <inquiryURI>http://<SERVER>:<PORT>/registry/uddi/inquiry</inquiryURI>
    <publishURI>http://<SERVER>:<PORT>/registry/uddi/publishing</publishURI>
    <securityURI>http://<SERVER>:<PORT>/registry/uddi/security</securityURI>
   <credentials>
      <user>admin</user>
      <password>*****</password>
    </credentials>
  </registry>
</registries>

Services are published to OSR based on the metadata attributes such as Asset status or Asset lifecycle stage. It is up to your specific implementation to define which attribute to use. In our use case, we used the Asset status; however, in the subsequent sections we describe how to do this configuration regardless of the approach taken.

Data that passes to and from OSR has to be mapped to the UDDI entities (see Chapter 7, Oracle Service Registry, for more details on UDDI). All the mappings are contained within the UDDIMappings.xml file that is also located under <OBPM HOME>/workflow/aler_egine.

The following metadata entities are mapped in UDDIMappings.xml and handled by the ORRXU:

Next, we need to specify the connection to the registry that is to be published to. We do this by editing the orrxu.xml file and entering values for the <destinationRegistries> element. The following snippet demonstrates an example configuration that shows how to use the <destinationRegistries> element to refer to one or more destination registries. These elements specify where the selected services from OER will be deployed.

In our use case, we also want to query Assets based on their lifecycle stage. As such, Assets that reach the lifecycle stage of Stage 4 - Release should be released to the internal registry.

<destinationRegistries>
  <destinationRegistry name="INTERNAL-PROD-OSR">
    <endpointAssetLifecycleStatus>Stage 4 – 
      Release</endpointAssetLifecycleStatus>
  </destinationRegistry>
</destinationRegistries>

Each destination registry element can optionally contain an endpointAssetLifecycleStatus property that filters service endpoints by the Asset Lifecycle Stage Categorization type. This ensures that only service endpoints that match the given Asset Lifecycle Stage Categorization are published to the specified registry.

It is necessary to create different configuration files configured to point at each registry. Depending on the lifecycle, the services can be moved to different registries based on the Asset lifecycle triggers.

<registrationStatus>Registered</registrationStatus>

<query>
  <!--Query: the services to publish-->
  <repositoryQuery>
    <services>
      <service name="%"/>
    </services>
    <!--Search criteria for the registration status of the service in OER -->
    <registrationStatus>Registered</registrationStatus>

<filter
type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy Service" />

<uddi:uddiSettings xmlns:uddi="http://www.bea.com/aler/integration/config/uddi">
  <categorizationMappings>
    <categorizationType 
      alerCategorizationTypeName="AssetLifecycleStage"
      alerCategorizationTypeId="112"
      uddiCategoryTModelKey=
        "uddi:bea.com:aler:categorization:AssetLifecycleStage">
      <categorization alerCategorization=
        "Stage 4 – Release to Preproduction" 
        uddiKeyName="Stage 4 - Release" 
        uddiKeyValue="Stage 4 – Release to Preproduction" />

<state:name="urn:com:bea:aler:events:type:AssetTabApproved" value="Taxonomy">
  <action>PublishAssetToUDDI</action>
  <alrrxConfigFileName>orrxu.xml</ alrrxConfigFileName>
  <alrrxMappingFileName>UDDIMappings.xml</alrrxMappingFileName>
</state>

<state:name="urn:com:bea:aler:events:type:AssetTabApproved" value="Documentation">
  <action>ChangeAssetLifeCycle</action>
  <assetLifecycle>Stage 4 - Release</assetLifecycle >
</state>

Chapter 5, Harvesting, of this book introduced the harvester as the tool used to gather the metadata about services deployed in the SOA ecosystem. Once the OSB proxy has been deployed, we need to harvest the endpoint back into OER.

For details on how to configure the harvester tool the user should refer to Chapter 5, Harvesting.

For this use case, the administrator needs to configure the Repository connection details for the command line. This is done by editing the HarvesterSettings.xml file. You will recall that we will harvest both the SOA composite information and the OSB business and proxy services. The latter should use the harvester that ships with OSB only. Locate the appropriate HarvestingSettings.xml file and set the repository connection details illustrated as follows:

<repository>
  <uri>http://localhost:7101/oer</uri>
  <credentials>
    <user>harvester</user>
    <password>*****</password>
  </credentials>
</repository>

Here it is necessary to provide the login details to the repository. Note that the password should be encrypted using the Oracle supplied encryption tool as described earlier in the book. In this case, we created a special user called harvester so that we could identify those Assets that have been automatically harvested.

We also need to configure the host details for the OSB server in order to harvest the OSB proxy. The following snippet shows how to connect to the OSB server:

<remoteQuery>
  <serverType>OSB</serverType>
  <projectName>%</projectName>
  <uri>http://<SOA Server>:7001/</uri>
  <credentials>
    <user>weblogic</user>
    <password>v2_1.G+NTr3az8thaGGJBn0vwPg==</password>
  </credentials>
</remoteQuery>

Here, we specify the server type as OSB and provide credentials on how to log into the OSB server.

<!--Registration status to set on created Assets in OER.
  The Valid Registration states are 1) Unsubmitted 2)Submitted - Pending Review 3)Submitted - Under Review 4)Registered -->
  <registrationStatus>Submitted - Pending Review</registrationStatus>

As described, Assets that are harvested from the testing environments will have been submitted with a status of Submitted - Under Review. The service will then need to be reviewed and registered. The Registration process will ensure that all the appropriate policies have been applied to the Asset. For details on how the service is accepted and registered, please refer to Chapter 6, Asset Lifecycle and Workflow, of this book, which details the Asset lifecycle and its approval processes.

Once a service has been deployed to the internal registry, the OAG developer can access the WSDL and create the Policy Enforcement Point (PeP) in OAG. The developers, in effect, will produce a proxy WSDL which will be used to access the service via the Oracle Enterprise API Gateway (OAG). The gateway will enforce security policies and protect Weir and Bell against threats such as XML bombs, denial of service attacks, and other external threads.

To access the service endpoint from the internal registry, the user must first configure the connections between OAG and OSR. This section describes how to configure the OAG Policy Studio to connect to OSR in order to browse the service data held in the registry. The Gateway itself does not connect to OSR but rather the Policy Studio connects to OSR in order to consume a service WSDL. The Policy Studio, however, must be connected to a Gateway in order to access the registry.

For details on how to determine the required repository URL settings, please refer to the section on Setting up the OSR Connection Details for OER. Once this configuration has been performed, log into the OAG Policy Studio and select the Web Services Repository node. Right-click on it and select Browse UDDI Registry. You will see the following screen:

Click on the Add button to add a new registry connection. Select UDDI v3, and enter the WSDL URLs for the inquiry, publishing, and security services that were found previously into the Inquiry URL, Publish URL, and Security URL fields as follows:

In the Registry Authentication fields enter the username and password for registry access.

Finally, click on OK and you are ready to browse OSR and consume service endpoints. This book will not provide details on how to create PePs for services and the reader should refer to the Oracle documentation that can be located at the following URL: http://docs.oracle.com/cd/E39820_01/index.html.

The gateway developer is able to create PePs that encompass the underlying service and the external bodies used to access the exposed services. The PePs implement protection steps, such as WS-Security, and utilize features of OAG to protect internal Assets against external threats.

Once the PeP is created, the developer can then enter the PeP endpoint into the external registry so that it can be consumed by the third party suppliers. Please note that it is possible to publish endpoints directly into OSR from OAG but this subject is beyond the scope of this book.

For completion, the OER administrators may wish to harvest the PeP endpoints from the external registries back to OER. Details of this can be found in Chapter 5, Harvesting, which details how to harvest Assets.