Contents


Integrating IBM Integration Bus with WebSphere Service Registry and Repository

Part 2: WebSphere Service Registry and Repository nodes in IBM Integration Bus

Comments

Content series:

This content is part # of # in the series: Integrating IBM Integration Bus with WebSphere Service Registry and Repository

Stay tuned for additional content in this series.

This content is part of the series:Integrating IBM Integration Bus with WebSphere Service Registry and Repository

Stay tuned for additional content in this series.

IBM® Integration Toolkit (formerly known as WebSphere® Message Broker Toolkit) provides explicit support for WSRR by providing the Endpoint Lookup node and the Registry Lookup node. These nodes can be included in message flows to dynamically retrieve metadata from WSRR according to the search criteria defined on the node. Alternatively, the search criteria can be specified programmatically by inserting elements into the local environment tree prior to the WSRR node.

The Endpoint Lookup node is used to retrieve service endpoints for a WSDL defined web service from WSRR. The node inserts the retrieved service endpoints into the local environment tree for use by subsequent SOAP or HTTP Request nodes to call the web service.

The Registry Lookup node is a general purpose node that can be used to query and retrieve any document or metadata from WSRR, for example, WSDL, XML schema, XSLT, policy documents, and so on. The node inserts the retrieved artifacts into the local environment tree for use in subsequent processing of the message flow.

These nodes are provided with IBM Integration Toolkit and can be found in the Web Services folder of the message flow node palette. This article describes these nodes in detail.

Node Terminals

The terminals for both the Endpoint Lookup and Registry Lookup nodes are the same and are shown in . The terminals are described in .

WSRR node terminals
WSRR node terminals
WSRR node terminals
Terminals on the Endpoint Lookup and Registry Lookup nodes
TerminalDescription
InThe input terminal that accepts a message for processing by the node.
FailureThe output terminal to which the message is routed if an error occurs within the node's processing.
OutThe output terminal to which the unmodified input message and updated local environment containing the matched registry data is sent.
NoMatchThe terminal to which the input message is sent if no matching entity is found based on the specified search criteria.

Endpoint Lookup node

The Endpoint Lookup node is used to retrieve service endpoint information from WSRR specifically for services that are described by WSDL documents. A WSDL document defines a service in terms of an interface (referred to as a portType) made available at a specified port. The WSDL port defines the endpoint information required to access the service. The Endpoint Lookup node retrieves the WSDL ports from WSRR that implement a specific portType. shows an example of how these objects are modeled in WSRR.

Relationship in WSRR between the WSDL Port and WSDL Port Type
Relationship in WSRR between the WSDL Port and WSDL Port Type
Relationship in WSRR between the WSDL Port and WSDL Port Type

To retrieve the service endpoint information from WSRR the Endpoint Lookup node performs a graph query using the WSRR web service API. This query takes the form of an XPath expression that is generated based on the properties that are defined on the node. These properties can also be specified programmatically using a compute node earlier in the message flow to insert elements into the local environment tree. Any properties specified programmatically override those that are specified on the node. The properties that can be defined on the Endpoint Lookup node are shown in .

Endpoint Lookup Node Properties
PropertyDescription
PortType NameThe name of the PortType that is exposed on the required endpoint.
PortType NamespaceThe namespace of the PortType that is exposed on the required endpoint.
PortType VersionThe version of the PortType that is exposed on the required endpoint.
User PropertiesAllows properties of the required WSDLPort to be specified on the query. The properties that are defined on the WSDLPort object in WSRR are as follows:
  • bsrURI
  • name
  • namespace
  • version
  • description
  • owner
  • lastModified
  • lastModifiedBy
  • creationTimestamp
Typically, the namespace and version will be the same on both the WSDLPort and WSDLPortType objects in WSRR. The Property Type can be:
  • a String (the default), in which case the Property Value is a character string to be matched with the property value in WSRR.
  • XPATH, or ESQL, in which case the Property Value is an XPath or ESQL expression which locates a field in the message tree that contains the character string to be matched with the property value in WSRR.
Classification

Allows classifications on the required WSDLPort to be specified on the query.

WSRR allows you to define ontologies that can be used to classify the objects that are registered. Classifications can help to make objects easier to find and can also be used to group a number of related objects together. For example, you might define an Ontology that represents the various business units in your organization. You could then group together all of the services owned by a specific business unit by classifying them in the same way.

Ontologies are defined using the Web Ontology Language (OWL). Each classifier is a class in OWL, and has a Uniform Resource Identifier (URI). When adding a classification you must specify the fully qualified OWL URI for the class.

Match PolicyThe query that is performed against WSRR could result in multiple matching entities being returned. If Match Policy is set to One, the first entity in the result set is used by the Endpoint Lookup node. If Match Policy is set to All, all matching entities are used by the Endpoint Lookup node.

The properties are edited using the Properties editor in IBM Integration Toolkit.

Endpoint Lookup Node Basic Properties Tab
Endpoint Lookup Node Basic Properties
Endpoint Lookup Node Basic Properties

When the Endpoint Lookup node receives a message the following steps occur in sequence:

  1. The Endpoint Lookup node retrieves the service data from the WSRR by using the specified search criteria.
  2. If one or more matches are found, the Endpoint Lookup node adds a representation of those endpoints to the local environment tree. Each representation of an endpoint is inserted as an ITService entry in the local environment under the ServiceRegistry entry.
    • If Match Policy is set to One, the first entity returned by WSRR is added to the local environment tree. WSRR does not guarantee the order of the results returned by a query so, if WSRR contains more than one entity that matches the specified search criteria, it is not possible to determine which one will be selected by the Endpoint Lookup node each time the query is issued.

      In addition, the retrieved endpoint value is set as the local environment override for the destination URL used by SOAP Request, SOAP Asynchronous Request, or HTTP Request nodes. That is, the retrieved endpoint value is written to both of the following locations in the local environment tree:

      • LocalEnvironment.Destination.HTTP.RequestURL
      • LocalEnvironment.Destination.SOAP.Request.Transport.WebServiceURL
    • If Match Policy is set to All, all matching entities returned by WSRR are added to the local environment tree. The destination URL used by SOAP Request, SOAP Asynchronous Request, or HTTP Request nodes is not set. Instead, you must add a compute node to your message flow to select the required address and set up the local environment settings required by those nodes.
    The input message is propagated unchanged to the Out terminal. The local environment tree is also propagated to the Out terminal, where it is available for further processing by subsequent nodes in the message flow.
  3. If no matches are found, the Endpoint Lookup node propagates the input message to the NoMatch terminal.
  4. If a processing error occurs, for example, if the connection to the WSRR server configured on the DefaultWSRR configurable service fails, or the connection times out, the Endpoint Lookup node propagates the input message unchanged to the Failure terminal. The ExceptionList is populated with details of the error.

The following example shows the typical structure of the local environment tree that is generated by the Endpoint Lookup node with a Match Policy of One. Other entries might exist in the local environment tree depending on previous processing that has been performed in the flow.

Typical output of the Endpoint Lookup node
<LocalEnvironment>
  <Destination>
    <HTTP>
      <RequestURL>http://localhost:7800/MathServer1/services/MathServer
      </RequestURL>
    </HTTP>
    <SOAP>
      <Request>
        <Transport>
          <HTTP>
            <WebServiceURL>http://localhost:7800/MathServer1/services/MathServer
            </WebServiceURL>
          </HTTP>
        </Transport>
      </Request>
    </SOAP>
  </Destination>
  <ServiceRegistry>
    <ITService>
      <Endpoint>
        <Address>http://localhost:7800/MathServer1/services/MathServer</Address>
        <PortType>
          <name>MathServerPortType</name>
          <namespace>http://math.pot.ibm.com</namespace>
          <version>1.0</version>
        </PortType>
        <Classification>http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3
          /LifecycleDefinition#Online</Classification>
      </Endpoint>
    </ITService>
  </ServiceRegistry>
</LocalEnvironment>

Registry Lookup node

The Registry Lookup node is a general purpose node that can be used to query and retrieve any document or metadata from WSRR. The node works in a very similar manner to the Endpoint Lookup node, generating an XPath expression based on the specified search criteria and then using this expression to perform a graph query against WSRR using the WSRR web service API. The main difference between the two nodes is in the XPath expression that the Registry Lookup node generates. While the Endpoint Lookup generates an XPath expression that selects WSDLPort objects from WSRR, the Registry Lookup node does not restrict the type of objects that are selected from WSRR in any way. This allows you to use the Registry Lookup node in your message flows to retrieve any type of entity from WSRR.

The properties that can be defined on the Registry Lookup node are shown in .

Registry Lookup Node Properties
PropertyDescription
NameThe name of the entities or artifacts that you want to retrieve from WSRR.
NamespaceThe namespace of the entities or artifacts that you want to retrieve from WSRR.
VersionThe version of the entities or artifacts that you want to retrieve from WSRR.
User Properties

Allows properties other than name, namespace or version to be specified on the query. If the required property is defined on a type in a WSRR business model then the name specified must be the programmatic name of the property, including the relevant prefix for the model. For example, if you wanted to include the Consumer Identifier property in the query then you would need to specify a property name of gep63_consumerIdentifier. The Property Type can be:

  • a String (the default), in which case the Property Value is a character string to be matched with the property value in WSRR.
  • XPATH, or ESQL, in which case the Property Value is an XPath or ESQL expression which locates a field in the message tree that contains the character string to be matched with the property value in WSRR.
Classification

Allows classifications on the entities or artifacts that you want to retrieve from WSRR to be specified on the query.

WSRR allows you to define ontologies that can be used to classify the objects that are registered. Classifications can help to make objects easier to find and can also be used to group a number of related objects together. For example, you might define an Ontology that represents the various business units in your organization. You could then group together all of the services owned by a specific business unit by classifying them in the same way.

Ontologies are defined using the Web Ontology Language (OWL). Each classifier is a class in OWL, and has a Uniform Resource Identifier (URI). When adding a classification you must specify the fully qualified OWL URI for the class.

Match PolicyThe query that is performed against WSRR could result in multiple matching entities being returned. If Match Policy is set to One, the first entity in the result set is used by the Registry Lookup node. If Match Policy is set to All, all matching entities are used by the Registry Lookup node.
Depth PolicyWSRR allows clients to specify the depth of the object graph that is returned when performing a graph query. This provides clients with some level of control over how much data is returned by the query. The depth that is passed to WSRR when performing the graph query is controlled by specifying a suitable Depth Policy on the Registry Lookup node (available on the Advanced tab). Valid values for the Depth Policy are:
  • Return matched only (Depth = 0) to use a WSRR query depth of 0, and to return only the matched entities.
  • Return matched plus immediate related entities (Depth = 1) to use a WSRR query depth of 1, and to return the matched entities and the immediate related child entities.
  • Return matched plus all related entities (Depth = -1) to use a WSRR query depth of 1, and to return the matched entities and the immediate related child entities.
The Return matched showing immediate relationships (For compatibility only) value is also available but this has been deprecated and should not be used.

The properties are edited using the Properties editor in IBM Integration Toolkit.

Registry Lookup Node Basic Properties Tab
Registry Lookup Node Basic Properties
Registry Lookup Node Basic Properties

If you wanted to use the Registry Lookup node to retrieve specific types of object from WSRR you can do one of the following:

  1. Specify a User Property with a property name of primaryType and a property value that is the OWL URI of the required type. For example, to generate a query that only returns Business Services from WSRR you would add a primaryType property with a value of http://www.ibm.com/xmlns/prod/serviceregistry/profile/v6r3/GovernanceEnablementModel#BusinessService.
  2. Specify the OWL URI for the required type in the list of Classifications.

When the Registry Lookup node receives a message the following steps occur in sequence:

  1. The Registry Lookup node retrieves the data from WSRR using the specified search criteria.
  2. If one or more matches are found, the Registry Lookup node adds a representation of those entities to the local environment tree. Each representation of a matching entity is inserted as an Entity entry in the local environment under the ServiceRegistry entry. The ServiceRegistry is owned by the XMLNSC parser.
    • If Match Policy is set to One, the first entity returned by WSRR is added to the local environment tree. WSRR does not guarantee the order of the results returned by a query so, if WSRR contains more than one entity that matches the specified search criteria, it is not possible to determine which one will be selected by the Registry Lookup node each time the query is issued.
    • If Match Policy is set to All, all matching entities returned by WSRR are added to the local environment tree.
    The input message is propagated unchanged to the Out terminal. The local environment tree is also propagated to the Out terminal, where it is available for further processing by subsequent nodes in the message flow. The exact representation of an entity in the local environment tree depends on the Depth Policy that was specified.
  3. If no matches are found, the Registry Lookup node propagates the input message to the NoMatch terminal.
  4. If a processing error occurs, for example, if the connection to the WSRR server configured on the DefaultWSRR configurable service fails, or the connection times out, the Registry Lookup node propagates the input message unchanged to the Failure terminal. The ExceptionList is populated with details of the error.

The following XML shows an example of the ServiceRegistry entry that might be generated in the local environment tree by the Registry Lookup node. This was generated using a Depth Policy of Return matched plus immediate related entities (Depth = 1).

Example output of the Registry Lookup node
<ServiceRegistry>
  <Entity
    bsrURI="de3116de-6db2-422f.9d14.baee05ba14cc"
    name="CalculatorApplication"
    namespace=""
    version="1.0"
    description="Version 1.0 of the CalculatorApplication."
    owner="wasadmin"
    lastModified="1382700226780"
    creationTimestamp="1379085488592"
    lastModifiedBy="wasadmin"
    primaryType="">
    <classificationURIs>
      http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3
        /LifecycleDefinition#Realized
    </classificationURIs>
    <classificationURIs>
      http://www.ibm.com/xmlns/prod/serviceregistry/profile/v6r3
        /GovernanceEnablementModel#ApplicationVersion
    </classificationURIs>
    <userDefinedProperties name="ale63_ownerEmail" value=""/>
    <userDefinedProperties name="ale63_guid" value=""/>
    <userDefinedProperties name="ale63_assetType" value=""/>
    <userDefinedProperties name="ale63_remoteState" value=""/>
    <userDefinedProperties name="ale63_fullDescription" value=""/>
    <userDefinedProperties name="ale63_assetOwners" value=""/>
    <userDefinedProperties name="gep63_versionTerminationDate" value="2019-09-13"/>
    <userDefinedProperties name="ale63_communityName" value=""/>
    <userDefinedProperties name="gep63_consumerIdentifier" value=""/>
    <userDefinedProperties name="gep63_versionAvailabilityDate" value="2013-09-13"/>
    <userDefinedProperties name="ale63_requirementsLink" value=""/>
    <userDefinedProperties name="ale63_assetWebLink" value=""/>
    <userDefinedProperties name="ale63_owningOrganization" value=""/>
    <userDefinedRelationships name="ale63_owningOrganization">
      <targetEntities>
        <Entity
          bsrURI="d2d6c2d2-3d69-4975.b47d.d26767d27d38"
          name="IT Department"
          namespace=""
          version=""
          description=""
          owner="wasadmin"
          lastModified="1379084875512"
          creationTimestamp="1379084873049"
          lastModifiedBy="wasadmin"
          primaryType="">
          <classificationURIs>
            http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
              LifecycleDefinition#Governed
          </classificationURIs>
          <classificationURIs>
            http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ALEModel#Organization
          </classificationURIs>
          <userDefinedProperties name="ale63_contact" value="Martin Smithson"/>
          <userDefinedProperties name="ale63_contactEmail" value="msmiths@uk.ibm.com"/>
        </Entity>
      </targetEntities>
    </userDefinedRelationships>
    <userDefinedRelationships name="ale63_artifacts">
      <targetEntities>
      </targetEntities>
    </userDefinedRelationships>
    <userDefinedRelationships name="gep63_interfaceSpecifications">
      <targetEntities>
      </targetEntities>
    </userDefinedRelationships>
    <userDefinedRelationships name="gep63_providedSCAModules">
      <targetEntities>
      </targetEntities>
    </userDefinedRelationships>
    <userDefinedRelationships name="gep63_providedWebServices">
      <targetEntities>
      </targetEntities>
    </userDefinedRelationships>
    <userDefinedRelationships name="ale63_dependency">
      <targetEntities>
      </targetEntities>
    </userDefinedRelationships>
    <userDefinedRelationships name="gep63_provides">
      <targetEntities>
      </targetEntities>
    </userDefinedRelationships>
    <userDefinedRelationships name="gep63_providedRESTServices">
      <targetEntities>
      </targetEntities>
    </userDefinedRelationships>
  </Entity>
</ServiceRegistry>

Programmatically overriding the node properties

As mentioned above, the values for the properties that are used by the Endpoint Lookup and Registry Lookup nodes when querying WSRR can be specified programmatically. This is achieved by inserting fields into the local environment tree using a transformation node, such as a Java Compute node. The fields must be set in the ServiceRegistryLookupProperties entry of the local environment tree. The transformation node must be placed into the flow before the Endpoint Lookup or Registry Lookup node.

Programmatically Setting Search Criteria
Programmatically Setting Search Criteria
Programmatically Setting Search Criteria

The fields that can be set in the ServiceRegistryLookupProperties entry of the local environment tree are shown in .

erviceRegistryLookupProperties Fields
FieldDescription
NameThis field overrides the PortType Name on the Endpoint Lookup node or the Name on the Registry Lookup node.
NamespaceThis field overrides the PortType Namespace on the Endpoint Lookup node or the Namespace on the Registry Lookup node.
VersionThis field overrides the PortType Version on the Endpoint Lookup node or the Version on the Registry Lookup node.
UserPropertiesThis field overrides the User Properties on the Endpoint Lookup or the Registry Lookup nodes.
ClassificationThis field overrides the Classification property on Endpoint Lookup and Registry Lookup nodes.
MatchPolicyThis field overrides the Match Policy property on the Endpoint Lookup and Registry Lookup nodes. Valid values when setting this property programmatically are One and All.
DepthPolicyThis field overrides the Depth Policy property on the Registry Lookup node. Valid values when setting this property programmatically are:
  • MatchOnly for Return matched only (Depth = 0)
  • MatchPlusImmediate for Return matched plus immediate related entities (Depth = 1)
  • MatchPlusAll for Return matched plus all related entities (Depth = -1)
The MatchShowRel value corresponds to the Return matched showing immediate relationships (For compatibility only) value that can be specified in the Properties editor for the node. As discussed previously, this value has been deprecated and should not be used.

provides an example of setting these properties programmatically using ESQL.

Dynamically specifying search criteria using ESQL
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.Name = 'MathServerPortType';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.Namespace
  = 'http://math.pot.ibm.com';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.Version = '1.0';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.UserProperties.prop1
  = 'value1';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.Classification
  = 'http://www.ibm.com/xmlns/prod/serviceregistry/8/0/visibilitytaxonomy#Internal';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.MatchPolicy = 'One';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.DepthPolicy = 'MatchOnly';

provides an example of setting these properties programmatically using Java. The XPath implementation in IBM Integration Bus provides a number of custom XPath functions that can be used to modify the message tree. The example Java code shown in makes use of these functions to reduce the amount of code that is required to create the fields in the local environment tree. For more information about these custom XPath functions please follow the Updating a message by using XPath extensions link in the Related topics section.

Dynamically specifying search criteria using Java
MbMessage environment = new MbMessage(inAssembly.getLocalEnvironment());
MbElement envRoot = environment.getRootElement();
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?Name"
                     + "[set-value('MathServerPortType')]");
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?Namespace"
                     + "[set-value('http://math.pot.ibm.com')]");
envRoot.evaluateXPath("?ServiceRegistryLookupProperties/?Version[set-value('1.0')]");
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?UserProperties/?prop1"
                     + "[set-value('value1')]");
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?Classification"
                     + "[set-value('http://www.ibm.com/xmlns/prod/serviceregistry/8/0/"
                     + "visibilitytaxonomy#Internal')]");
envRoot.evaluateXPath("?ServiceRegistryLookupProperties/?MatchPolicy"
                     + "[set-value('One')]");
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?DepthPolicy"
                     + "[set-value('MatchOnly')]");

Both the User Properties and Classification properties on the Endpoint Lookup and Registry Lookup nodes can be configured with multiple values. It is possible to specify multiple values for these properties programmatically in the local environment tree. provides an example of how this can be done using ESQL.

Specifying multiple properties and classifications using ESQL
-- Create multiple properties
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.UserProperties.prop1
  = 'value1';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.UserProperties.prop2
  = 'value2';

-- Create multiple classifications
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.Classification[1]
  = 'http://www.ibm.com/xmlns/prod/serviceregistry/8/0/visibilitytaxonomy#Internal';
SET OutputLocalEnvironment.ServiceRegistryLookupProperties.Classification[2]
  = 'http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Staging';

provides an example of how this can be done using Java.

Specifying multiple properties and classifications using Java
// Create multiple properties
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?UserProperties/?prop1"
                     + "[set-value('value1')]");
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?UserProperties/?prop2"
                     + "[set-value('value2')]");

// Create multiple classifications
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?Classification"
  + "[set-value('http://www.ibm.com/xmlns/prod/serviceregistry/8/0/visibilitytaxonomy#"
  + "Internal')]");
envRoot.evaluateXPath( "?ServiceRegistryLookupProperties/?$Classification"
  + "[set-value('http://www.ibm.com/xmlns/prod/serviceregistry/6/1/"
  + "GovernanceProfileTaxonomy#Staging')]");

The ability to programmatically override the properties on the Endpoint Lookup and Registry Lookup nodes allows you to work around a limitation that exists on these nodes. IBM Integration Toolkit forces you to specify a value for at least one of the name, namespace or version properties on these nodes. If you do not specify a value for any of these properties you will get an error message when you save the message flow and you will be unable to deploy it. To work around this limitation you can simply specify a dummy value for one of these properties and then programmatically clear the value earlier in the flow. shows an example of specifying a value of dummy for the name property on a Registry Lookup node.

Specifying A Dummy Name
Specifying A Dummy Name
Specifying A Dummy Name

provides an example of how to programmatically clear this value using Java.

Programmatically clearing the name property using Java
envRoot.evaluateXPath("?ServiceRegistryLookupProperties/?Name[set-value('')]");

Generated XPath expressions

As mentioned above, both the Endpoint Lookup and Registry Lookup nodes generate the XPath expressions that are used to query WSRR based on the properties that are specified on the node or programmatically in the local environment tree. The XPath expression that is generated by the Endpoint Lookup node is of the form shown in .

XPath query generated by Endpoint Lookup node
/WSRR/WSDLService/ports[binding/portType[
    @name='<PORTTYPE_NAME>' and 
    @namespace='<PORTTYPE_NAMESPACE>' and 
    @version='<PORTTYPE_VERSION>'] and 
    @<PROPERTY_NAME_1>='<PROPERTY_VALUE_1>' and
        ...
    @<PROPERTY_NAME_N>='<PROPERTY_VALUE_N>' and
    exactlyClassifiedByAllOf(., '<CLASSIFICATION_URI_1>', ... ,'<CLASSIFICATION_URI_N>')]

Where:

  • <PORTTYPE_NAME> is the value of the PortType Name property.
  • <PORTTYPE_NAMESPACE> is the value of PortType Namespace property.
  • <PORTTYPE_VERSION> is the value of the PortType Version property.
  • <PROPERTY_NAME_1> is the value of the first User Property specified, if any.
  • <CLASSIFICATION_URI_1> is the OWL URI of the first Classification specified, if any.

The XPath expression that is generated by the Registry Lookup node is of the form shown in .

XPath query generated by Registry Lookup node
//*[@name='<NAME>' and 
    @namespace='<NAMESPACE>' and 
    @version='<VERSION>' and 
    @<PROPERTY_NAME_1>='<PROPERTY_VALUE_1>' and
        ...
    @<PROPERTY_NAME_N>='<PROPERTY_VALUE_N>' and
    exactlyClassifiedByAllOf(., '<CLASSIFICATION_URI_1>', ... ,'<CLASSIFICATION_URI_N>')]
  • <NAME> is the value of the Name property.
  • <NAMESPACE> is the value of Namespace property.
  • <VERSION> is the value of the Version property.
  • <PROPERTY_NAME_1> is the value of the first User Property specified, if any.
  • <PROPERTY_VALUE_1> is the value of the first User Property specified, if any.
  • <CLASSIFICATION_URI_1> is the OWL URI of the first Classification specified, if any.

If no value has been specified for a given property then the corresponding predicate for that property is omitted from the generated XPath expression. For example, if you included the Registry Lookup node in a message flow and only specified a value of MyTestService for the Name property, the XPath expression that would be generated is as follows:

Example XPath
//*[@name='MyTestService']

It is also worth noting that the XPath expressions that are generated by both the Endpoint Lookup and Registry Lookup nodes make use of the exactlyClassifiedByAllOf custom XPath function provided by WSRR. This function will return objects that have been classified by all of the specified OWL URIs and does not consider any child classifications. For example, if you want to return all of the endpoints for a service that have been classified with an environment classification, you cannot specify the OWL URI of the Environment classification, as shown in the following example, because the child classifications are not considered:

http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Environment

Instead, you would need to explicitly include all of the environment classifications for the objects that you wanted to be included in the query results. For example, out of the box WSRR defines the following child classifications of the environment classification:

http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Development
http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Production
http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Staging
http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Test

Performance and caching

The calls made to WSRR from within a message flow are synchronous. Obviously, this can have impact on the performance of a message flow at runtime. To improve the performance of message flows that make use of the Endpoint Lookup and Registry Lookup nodes, IBM Integration Bus provides a cache that is used to store the results of the queries performed by these nodes. This cache is discussed in more detail in Part 7: Configuring the WSRR Cache in IBM Integration Bus.

Conclusion

This article has described the Endpoint Lookup and Registry Lookup nodes that are provided with IBM Integration Bus in detail. This information provides a solid foundation that will help with your understanding of how the nodes are used in each of the sample message flows described in the remaining articles of this series.

Acknowledgements

Thank you to the following people for all of their help with the development of the sample messages flows in this series:

  • John Hosie
  • Ben Thompson
  • Matt Golby-Kirk
  • Trevor Dolby
  • Andreas Martens
  • Graham Haxby
  • Andrew Coleman
  • John Reeve

An additional thank you to the following people for their help with reviewing this article:

  • David Seager
  • Arnauld Desprets
  • Anna Maciejkowicz

Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Middleware
ArticleID=969919
ArticleTitle=Integrating IBM Integration Bus with WebSphere Service Registry and Repository: Part 2: WebSphere Service Registry and Repository nodes in IBM Integration Bus
publish-date=04302014