10 Configuring Oracle Enterprise Repository to Exchange Metadata with the Oracle Service Registry

10.2.3.3.1 Query by Name

When the <services> element is configured, the service name specified is published to Oracle Service Registry. However, due to a limitation in the Oracle Enterprise Repository REX API, only one <services> element can be added.

<query>
    <repositoryQuery>
      <services>
        <service name="HelloWorld" /> 
      </services>
      <registrationStatus></registrationStatus>
      <serviceCategorizations type="AssetLifecycleStage" value=""/> 

10.2.3.3.2 Query by Registration Status

When the <registrationStatus> element is configured, only the services with the specified Registration Status are published. For example, if this field is set to Registered, then only registered services are published to Oracle Service Registry, while ignoring all other matched services that are not in this state.

  <registrationStatus>Registered</registrationStatus>

The acceptable values for registration status, which are not case sensitive, are as follows:

• registered

• rejected

• under_review

• pending_review

• submitted

• unsubmitted

• undefined

10.2.3.3.3 Query by Categorizations

When the <serviceCategorizations> element is configured, only the services with the specified categorization is published. For example, when using the following categorization, only the Recommended services are published to Oracle Service Registry.

  <serviceCategorizations type="AssetLifecycleStage" value="Stage 4 - Release"/>

10.2.3.3.4 Query by Filters

You may want to limit the kinds of services that are promoted to a UDDI registry from Oracle Enterprise Repository. The Filters element further narrows the selection based on the type of service besides registration status, service categorizations, and endpoint asset lifecycle. When configured, services that meet the specified criteria are the only services published. Each <filter> element has three attributes: type, exclude, and value.

• Type (required field): There are two types of filters: metadata and wsdllocation.

  • metadata: In Oracle Enterprise Repository, a service asset has several types of metadata. This data can be filtered based on the metadata type name and the xpath for the field.

    An example is Service Type. This is a piece of metadata applied to all services created by the Harvester. The metadata type is internal.introspector and the xpath for the field is /sync/Service_Type.

    The format for the filter is as follows (prefixed by "metadata."):

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

  • wsdllocation: When harvesting services into Oracle Enterprise Repository, the WSDL location can be stored either on a remote server or as a local file information in Oracle Enterprise Repository.

  Note:

  When a service with a local file information is published, information on that WSDL will not be added to Oracle Service Registry, only metadata of the service.

• Value (required field): Each type has its own set of possible values. This value is what is used to determine which services to filter on.

  • metadata values: Accepted values depend on the metadata type being filtered. For example:

    Service_Type: Proxy Service or Split-Join Service

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

    Scope: global or local

    <filter type="metadata.internal.introspector.store/sync/Scope" value="global" />

    Local indicates services that are not consumable.

    Deployment_Status: run-time or design-time

    <filter type="metadata.internal.introspector.store/sync/Deployment_Status" value="run-time" />

  • wsdllocation values: remote, local. The following will publish services with a remote WSDL.

    <filter type="wsdllocation" value="remote" />

• Exclude (optional field): The exclude flag, if set to the value of true, publishes all services except those that match the criteria in the filter. The following publishes all services except those with a WSDL stored in a local file information.

  <filter exclude="true" type="wsdllocation" value="local" />

If the Exclude flag is set, then there can be multiple filters of the same type. This means that a search can be performed where a service is of the type Business Service or Split-Join Service. However, if the Exclude flag is not set, then multiple filters of the same type will not work, meaning a search cannot be performed where a service is of the type Business Service and Split-Join Service.

You can only combine multiple FILTER criteria when you are excluding the criteria from the search results. The EXCLUDE Business Service and the EXCLUDE proxy service will work. However, the INCLUDE business service and the INCLUDE proxy service will not work.

For example,

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

The following example will not work:

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

Example 1

The following example is the default configuration for Exchange Utility. It publishes services that are not of the service type Proxy Service from Oracle Service Bus and only services that have remote WSDLs.

<repositoryQuery>
  <services>
  <service name=" "/>
  </services>
  <!--Search criteria for the registration status of the service in
 Oracle Enterprise Repository -->
   <registrationStatus></registrationStatus>
   !--Search criteria for a categorization assigned to the service in
 Oracle Enterprise Repository -->           
   <serviceCategorizations type="AssetLifecycleStage" value=""/>
   <!--Name of UDDI Registries to publish to.  This name corresponds with
 UDDI Registry definitions -->
   <!--below under the <registries> section -->
   <destinationRegistries>
   <destinationRegistry name="TEST_UDDI">
   <endpointAssetLifecycleStatus></endpointAssetLifecycleStatus>
   </destinationRegistry>
   </destinationRegistries>
   <!--Filter: identify metadata to apply filter on services to
 publish-->
   <filters>
   <filter type="wsdllocation" value="remote" />
   <filter type="metadata.internal.introspector.store/sync/Scope"
 value="global" />
   <filter exclude="true"
 type="metadata.internal.introspector.store/sync/Service_Type" value="Proxy
 Service" />
     </filters>
</repositoryQuery>

Example 2

The following will publish services with both remote and locally stored WSDLs and only services of the type Proxy Service.

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

Example 3

The following publishes only Web services and exclude Business, Proxy, and Split-Join services:

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

10.3.1.1.1 Prerequisities

This section describes the prerequisite configuration steps required prior to running Oracle Registry Repository Exchange Utility workflows:

1. Download the Oracle Registry Repository Exchange Utility solution pack, 11.1.1.x.x-RR-ExchangeUtility.zip, from <Oracle_HOME>\repository111\core\tools\solutions.

2. Extract the zip file and copy the following files from it to <Oracle_Home>\obpm\enterprise\server\aler_engine directory:

   • plugins

   • orrxu.properties

   • orrxu.xml

   • log4fl.properties

   • types.properties

   • UDDIMappings.xml

   These files are required to run the Oracle Registry Repository Exchange Utility workflows from Oracle BPM.

3. Configure orrxu.xml for the connection information of Oracle Enterprise Repository instance that generates events from and for the Oracle Service Registry instance, and also for publishing/receiving assets.

4. Ensure that the passwords in the files are encrypted using the encrypt tool.

10.3.1.1.2 Synchronizing Using Timer Based Workflows

A timer based workflow can be used to synchronize Oracle Enterprise Repository from Oracle Service Registry, or to synchronize Oracle Service Registry from Oracle Enterprise Repository.

Table 10-2 shows the names and descriptions of the timer based workflows:

The timer can be configured to wake up based on the timerInterval settings in the workflow.xml file. The following example shows the autoSyncAlerToUddi and autoSyncUddiToAler workflows configured in the workflow.xml file:

<automation>
    <autoSyncAlerToUddi configFilename="AlerToUddiSyncOrrxuConfig.xml"
    mappingFileName="AlerToUddiSyncOrrxuMapping.xml" timerInterval="2d"/>
    <autoSyncUddiToAler configFileName="UddiToAlerSyncOrrxuConfig.xml"
    mappingFileName="UddiToAlerSyncOrrxuMapping.xml" timerInterval="3d"/>
</automation>

10.3.1.1.3 Synchronizing When Events are Triggered

Individual services and their metadata can be moved to Oracle Service Registry by wiring the events that get triggered when these services are registered or a lifecycle of a service is changed.

The PublishAssetToUDDI workflow can be used to move the services. The PublishAssetToUDDI workflow can be wired to any event trigger, depending on the requirements.

For example, the following configuration moves the service when the Asset Lifecycle stage is QA:

<state name="urn:com:bea:aler:events:type:CategorizationChanged:AssetLifecycleStage" value ="QA">
<action>PublishAssetToUddi</action>
<alrrxConfigFileName>my_orrxu.xml</alrrxConfigFileName>
<alrrxMappingFileName>my_uddiMappings.xml</alrrxMappingFileName>
</state>

Also, note that the configuration related to where the registry is running is configured using the alrrxConfigFileName setting, and that the mapping file related to the categorization is configured using the alrrxMappingFileName setting.

You could have differerent configuration files configured to point to different registries. Depending on the lifecycle, the services can be moved to different registries based on the Asset Lifecycle triggers.

10.3.1.1.4 Example Use Cases

Oracle Enterprise Repository supports the following use cases for automated workflows:

• Automated workflows can automate synchronizing Oracle Enterprise Repository and Oracle Service Registry based on a configured timer interval.

• When different registries are running to categorize services based on the Lifecycle, services can be published automatically to these registries by wiring the Asset Lifecycle event trigger to publish to the relevant registry.

• Services can be automatically published to Oracle Service Registry if a service is submitted to Oracle Enterprise Repository. When a service is submitted to Oracle Enterprise Repository, it triggers an event which is processed by the workflows. The workflows will move this to Oracle Service Registry automatically, if it is configured to do so.

10.3.2.1.1 Business Entities

Check if the Service asset being published has a related (by configured relation) Business Entity asset:

• If yes, use the existing Business Entity asset to relate to newly created Service asset using configured relation.

• If no, get default Business Entity name from configuration, as follows:

  • Check if default business entity asset is configured in the Oracle Enterprise Repository System Settings.

  • If yes, use that as the default Business Entity.

  • If no, use the default Business Entity name from the orrxu.properties file.

10.3.2.1.2 Service Keys

When you publish services to Oracle Service Registry, the Exchange Utility automatically generates a new service key and assigns it to the service in Oracle Enterprise Repository as well as Oracle Service Registry. You can also supply your own service key on a service through the Asset Editor.

For Types that have the UDDI Plugin applied, you could use the Service Key field, which is located in the Technical tab under the UDDI Service section. If this field is populated, then the service key is synchronized to Oracle Service Registry. However, once this service is published, this field will no longer be editable.

Oracle Enterprise Repository determines the published status by the existence of UDDI Registries that the service has been published to.

To see this, a table displaying the UDDI Registries is available to the Endpoints that belong to the Service. This table can be found in the Technical tab. However, if the Service is defined by a WSDL that is stored locally in Oracle Enterprise Repository, the Endpoints will not be published to the UDDI Registry. Due to this, the table can be found in the Service asset within the Technical tab.

If the Exchange Utility configuration is not using the Endpoint asset type, then you must add the UDDI Registries plugin manually. To do this, go to the Type Manager and select the asset type that is being used. Select the desired tab and under Elements, select Add. From the list, select UDDI Registries. Also, ensure that you add this plugin to the Viewer tab.

For more information about modifications to asset types, see Oracle Fusion Middleware User's Guide for Oracle Enterprise Repository.

10.3.2.1.3 Endpoint

Check if the Service asset being published has one or more related endpoint assets, as follows:

• If yes, then create UDDI Binding Templates if this is the first time. If this was synchronized before, update the existing Binding Templates. Use the Endpoint URI in the Endpoint asset to arrive at the UDDI Access point. Derive the port from the WSDL that is attached to the File Info of the endpoint asset. If the WSDL is stored locally in Oracle Enterprise Repository, the existing binding template in Oracle Service Registry will not be updated.

• If no, then create the Binding Templates based on the WSDL that is attached to the File Info of the Service asset if the WSDL contains the port info. The Binding Templates are created only for WSDLs that are located remotely (http://). WSDLs that are stored locally in Oracle Enterprise Repository are not included.

• If Asset Life cycle is attached to the endpoint and if the Endpoint Asset Life cycle Query is used, then filter the endpoints based on the Asset Lifecycle. For example, you can publish the staging endpoint to the Staging Registry and publish the production endpoint to the production registry.

10.3.2.1.4 Categorizations

Check if Categorizations are applied to Service and Endpoint assets, as follows:

• If yes, then load the Categorization mapping for each of the applied Categorizations from the UDDIMappings.xml file.

  • If the mapping is found, then add an entry to the Category Bag, either to the Business Service or Binding Template.

  • If the t-model is not found in the Oracle Service Registry, then automatically create the t-models.

• If no, then the Categorization will not be applied to the Service in Oracle Service Registry.

10.3.2.1.5 Registration and Active Status

The Registration and Active Status are added to Category Bags. Figure 10-8 illustrates how references appear in Oracle Service Registry.

Figure 10-8 Oracle Service Registry t-model Categories for a WSDL Service

Description of "Figure 10-8 Oracle Service Registry t-model Categories for a WSDL Service"

Figure 10-9 illustrates how two endpoints that are linked to a service in Oracle Enterprise Repository appear in Oracle Service Registry.

Figure 10-9 WSDL Bindings in Oracle Service Registry

Description of "Figure 10-9 WSDL Bindings in Oracle Service Registry"

Figure 10-10 and Figure 10-11 illustrate how the different entities and their relationships appear in the Oracle Enterprise Repository Navigator.

Figure 10-10 Entity Relationship in Oracle Enterprise Repository Navigator

Description of "Figure 10-10 Entity Relationship in Oracle Enterprise Repository Navigator"

Figure 10-11 Another Entity Relationship in Oracle Enterprise Repository Navigator

Description of "Figure 10-11 Another Entity Relationship in Oracle Enterprise Repository Navigator"

10.3.2.1.6 Sample Flow of Metadata from Oracle Enterprise Repository to Oracle Service Registry

Figure 10-12 illustrates the Oracle Enterprise Repository > Oracle Service Registry metadata synchronization described in this section.

Figure 10-12 Flow of Metadata Published from Oracle Enterprise Repository to Oracle Service Registry

Description of "Figure 10-12 Flow of Metadata Published from Oracle Enterprise Repository to Oracle Service Registry"

10.3.2.2.1 Business Entities

Check if the Service asset being received exists and is related to a Business Entity asset, as follows:

• If yes, the same Business Entity relationship is used.

• If no, the Business Entity on the Oracle Service Registry side is used. If the Business Entity does not exist in Oracle Enterprise Repository, it is created.

If the Service asset is newly created, get the default Business Entity asset type for UDDI Business from the Oracle Enterprise Repository configuration:

• If found in the System Settings

• If not, from the orrxu.properties file

Check if an asset exists with that name and type, as follows:

• If yes, simply relate that existing asset to newly created service asset using configured relation.

• If no, create a new asset and relate it to newly created service asset using configured relation.

10.3.2.2.2 Endpoint

Check if the Service asset being received has one or more Endpoint assets related, as follows:

• If yes, create check if the Endpoint assets are the same as the existing Binding Templates using the UUID. If they are same, update the Endpoints.

• If no, create the Endpoints for each Binding Template and relate them to the Service asset.

10.3.2.2.3 Categorizations

Check if Categorizations are present in the Category Bag, as follows:

• If yes, load the Categorization mapping for each of the applied Categorizations from the UDDIMappings.xml file.

• If the mapping is found, set the Categorizations of the Service asset.

10.3.2.2.4 Sample Flow of Metadata from Oracle Service Registry to Oracle Enterprise Repository

Figure 10-13 illustrates the Oracle Service Registry > Oracle Enterprise Repository metadata synchronization described in this section.

Figure 10-13 Flow of Metadata Received from Oracle Service Registry

Description of "Figure 10-13 Flow of Metadata Received from Oracle Service Registry"