Smithson PDF

Copyright IBM Corporation 2014 TrademarksIntegrating IBM Integration Bus with WebSphere Service Registryand Repository: Part 2: WebSphere Service Registry andRepository nodes in IBM Integration Bus

Page 1 of 17

Integrating IBM Integration Bus with WebSphereService Registry and Repository: Part 2: WebSphereService Registry and Repository nodes in IBMIntegration BusMartin Smithson ([email protected])ArchitectIBM

30 April 2014

Combining IBM Integration Bus (IIB) with WebSphere Service Registry and Repository (WSRR)lets you dynamically retrieve service metadata from WSRR and use it to modify messageflow behavior at runtime. This article series shows you how to integrate the two products, andprovides samples that address several significant business problems. Part 2 describes theEnpoint Lookup and Registry Lookup nodes in detail.

View more content in this series

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

The Endpoint Lookup node is used to retrieve service endpoints for a WSDL defined web servicefrom WSRR. The node inserts the retrieved service endpoints into the local environment tree foruse 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 anydocument 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 insubsequent processing of the message flow.

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

developerWorks ibm.com/developerWorks/

Integrating IBM Integration Bus with WebSphere Service Registryand Repository: Part 2: WebSphere Service Registry andRepository nodes in IBM Integration Bus

Page 2 of 17

Node TerminalsThe terminals for both the Endpoint Lookup and Registry Lookup nodes are the same and areshown in . The terminals are described in .

WSRR node terminals

Terminals on the Endpoint Lookup and Registry Lookup nodesTerminal Description

In The input terminal that accepts a message for processing by the node.

Failure The output terminal to which the message is routed if an error occurswithin the node's processing.

Out The output terminal to which the unmodified input message andupdated local environment containing the matched registry data is sent.

NoMatch The terminal to which the input message is sent if no matching entity isfound based on the specified search criteria.

Endpoint Lookup nodeNon SOAP/HTTP ServicesIIB can also retrieve service endpoints from WSRR for services that are not defined byWSDL documents, for example, REST services. In order to do this you should use theRegistry Lookup node or HTTP Request node in order to retrieve the endpoint metadata.

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

Relationship in WSRR between the WSDL Port and WSDL Port Type

ibm.com/developerWorks/ developerWorks


Page 3 of 17

Depth Policy For The Endpoint Lookup NodeIt is not possible to specify the depth of the WSRR query that is performed by the EndpointLookup node. The Endpoint Lookup node always performs a graph query against WSRRspecifying a depth of -1, returning all WSDLPort objects that match the specified searchcriteria and all related child entities.

In order to retrieve the service endpoint information from WSRR the Endpoint Lookup nodeperforms a graph query using the WSRR web service API. This query takes the form of anXPath expression that is generated based on the properties that are defined on the node. Theseproperties can also be specified programmatically using a compute node earlier in the messageflow to insert elements into the local environment tree. Any properties specified programmaticallyoverride those that are specified on the node. The properties that can be defined on the EndpointLookup node are shown in .

Endpoint Lookup Node PropertiesProperty Description

PortType Name The name of the PortType that is exposed on the required endpoint.

PortType Namespace The namespace of the PortType that is exposed on the requiredendpoint.

PortType Version The version of the PortType that is exposed on the required endpoint.

User Properties Allows properties of the required WSDLPort to be specified on thequery. The properties that are defined on the WSDLPort object inWSRR are as follows:

bsrURI name namespace version description owner lastModified lastModifiedBy creationTimestamp

Typically, the namespace and version will be the same on both theWSDLPort and WSDLPortType objects in WSRR. The Property Typecan be:

a String (the default), in which case the Property Value is acharacter string to be matched with the property value in WSRR.

XPATH, or ESQL, in which case the Property Value is an XPathor ESQL expression which locates a field in the messagetree that contains the character string to be matched with theproperty value in WSRR.

Classification Allows classifications on the required WSDLPort to be specified on thequery.

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

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



Page 4 of 17

Match Policy The query that is performed against WSRR could result in multiplematching entities being returned. If Match Policy is set to One, the firstentity in the result set is used by the Endpoint Lookup node. If MatchPolicy is set to All, all matching entities are used by the EndpointLookup node.

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

Endpoint Lookup Node Basic Properties Tab

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 specifiedsearch criteria.

2. Order of WSRR Query Results

The order of the results returned when performing a query against WSRR is notguaranteed and might vary between queries.

If one or more matches are found, the Endpoint Lookup node adds a representation of thoseendpoints to the local environment tree. Each representation of an endpoint is inserted as anITService 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 localenvironment tree. WSRR does not guarantee the order of the results returned by a queryso, if WSRR contains more than one entity that matches the specified search criteria, it isnot possible to determine which one will be selected by the Endpoint Lookup node eachtime the query is issued.In addition, the retrieved endpoint value is set as the local environment override forthe destination URL used by SOAP Request, SOAP Asynchronous Request, or HTTPRequest nodes. That is, the retrieved endpoint value is written to both of the followinglocations in the local environment tree:

LocalEnvironment.Destination.HTTP.RequestURL LocalEnvironment.Destination.SOAP.Request.Transport.WebServiceURL



Page 5 of 17

If Match Policy is set to All, all matching entities returned by WSRR are added tothe local environment tree. The destination URL used by SOAP Request, SOAPAsynchronous Request, or HTTP Request nodes is not set. Instead, you must add acompute node to your message flow to select the required address and set up the localenvironment settings required by those nodes.

The input message is propagated unchanged to the Out terminal. The local environmenttree is also propagated to the Out terminal, where it is available for further processing bysubsequent nodes in the message flow.

3. If no matches are found, the Endpoint Lookup node propagates the input message to theNoMatch terminal.

4. If a processing error occurs, for example, if the connection to the WSRR server configured onthe DefaultWSRR configurable service fails, or the connection times out, the Endpoint Lookupnode propagates the input message unchanged to the Failure terminal. The ExceptionList ispopulated with details of the error.

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

Typical output of the Endpoint Lookup node

http://localhost:7800/MathServer1/services/MathServer http://localhost:7800/MathServer1/services/MathServer http://localhost:7800/MathServer1/services/MathServer MathServerPortType http://math.pot.ibm.com 1.0 http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3 /LifecycleDefinition#Online



Page 6 of 17

Registry Lookup nodeThe Registry Lookup node is a general purpose node that can be used to query and retrieve anydocument or metadata from WSRR. The node works in a very similar manner to the EndpointLookup node, generating an XPath expression based on the specified search criteria and thenusing this expression to perform a graph query against WSRR using the WSRR web serviceAPI. The main difference between the two nodes is in the XPath expression that the RegistryLookup node generates. While the Endpoint Lookup generates an XPath expression that selectsWSDLPort objects from WSRR, the Registry Lookup node does not restrict the type of objectsthat are selected from WSRR in any way. This allows you to use the Registry Lookup node in yourmessage 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

Property Description

Name The name of the entities or artifacts that you want to retrieve fromWSRR.

Namespace The namespace of the entities or artifacts that you want to retrieve fromWSRR.

Version The version of the entities or artifacts that you want to retrieve fromWSRR.

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

a String (the default), in which case the Property Value is acharacter string to be matched with the property value in WSRR.

XPATH, or ESQL, in which case the Property Value is an XPathor ESQL expression which locates a field in the messagetree that contains the character string to be matched with theproperty value in WSRR.

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

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

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

Match Policy The query that is performed against WSRR could result in multiplematching entities being returned. If Match Policy is set to One, thefirst entity in the result set is used by the Registry Lookup node. If



Page 7 of 17

Match Policy is set to All, all matching entities are used by the RegistryLookup node.

Depth Policy WSRR allows clients to specify the depth of the object graph that isreturned when performing a graph query. This provides clients withsome level of control over how much data is returned by the query.The depth that is passed to WSRR when performing the graph queryis controlled by specifying a suitable Depth Policy on the RegistryLookup node (available on the Advanced tab). Valid values for theDepth Policy are:

Return matched only (Depth = 0) to use a WSRR query depthof 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 matchedentities and the immediate related child entities.

Return matched plus all related entities (Depth = -1) to use aWSRR query depth of 1, and to return the matched entities andthe immediate related child entities.

The Return matched showing immediate relationships (Forcompatibility only) value is also available but this has beendeprecated and should not be used.

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

Registry Lookup Node Basic Properties Tab

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

1. Specify a User Property with a property name of primaryType and a property valuethat is the OWL URI of the required type. For example, to generate a query that onlyreturns Business Services from WSRR you would add a primaryType propertywith 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.



Page 8 of 17

2. If one or more matches are found, the Registry Lookup node adds a representation ofthose entities to the local environment tree. Each representation of a matching entity isinserted as an Entity entry in the local environment under the ServiceRegistry entry. TheServiceRegistry is owned by the XMLNSC parser.

If Match Policy is set to One, the first entity returned by WSRR is added to the localenvironment tree. WSRR does not guarantee the order of the results returned by a queryso, if WSRR contains more than one entity that matches the specified search criteria, it isnot possible to determine which one will be selected by the Registry Lookup node eachtime the query is issued.

If Match Policy is set to All, all matching entities returned by WSRR are added to thelocal environment tree.

The input message is propagated unchanged to the Out terminal. The local environmenttree is also propagated to the Out terminal, where it is available for further processing bysubsequent nodes in the message flow. The exact representation of an entity in the localenvironment tree depends on the Depth Policy that was specified.

3. If no matches are found, the Registry Lookup node propagates the input message to theNoMatch terminal.

4. If a processing error occurs, for example, if the connection to the WSRR server configured onthe DefaultWSRR configurable service fails, or the connection times out, the Registry Lookupnode propagates the input message unchanged to the Failure terminal. The ExceptionList ispopulated with details of the error.

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

Example output of the Registry Lookup node

http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3 /LifecycleDefinition#Realized http://www.ibm.com/xmlns/prod/serviceregistry/profile/v6r3 /GovernanceEnablementModel#ApplicationVersion



Page 9 of 17

http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/ LifecycleDefinition#Governed http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ALEModel#Organization



Page 10 of 17

Programmatically overriding the node properties

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

Programmatically Setting Search Criteria

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

erviceRegistryLookupProperties Fields

Field Description

Name This field overrides the PortType Name on the Endpoint Lookup nodeor the Name on the Registry Lookup node.

Namespace This field overrides the PortType Namespace on the Endpoint Lookupnode or the Namespace on the Registry Lookup node.

Version This field overrides the PortType Version on the Endpoint Lookup nodeor the Version on the Registry Lookup node.

UserProperties This field overrides the User Properties on the Endpoint Lookup or theRegistry Lookup nodes.

Classification This field overrides the Classification property on Endpoint Lookupand Registry Lookup nodes.

MatchPolicy This field overrides the Match Policy property on the Endpoint Lookupand Registry Lookup nodes. Valid values when setting this propertyprogrammatically are One and All.

DepthPolicy This field overrides the Depth Policy property on the Registry Lookupnode. 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 matchedshowing immediate relationships (For compatibility only) value thatcan be specified in the Properties editor for the node. As discussedpreviously, this value has been deprecated and should not be used.

provides an example of setting these properties programmatically using ESQL.



Page 11 of 17

Dynamically specifying search criteria using ESQLSET 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 XPathimplementation in IIB provides a number of custom XPath functions that can be used to modify themessage tree. The example Java code shown in makes use of these functions in order to reducethe amount of code that is required to create the fields in the local environment tree. For moreinformation on these custom XPath functions please follow the Updating a message by usingXPath extensions link in the Resources section.

Dynamically specifying search criteria using JavaMbMessage 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 RegistryLookup nodes can be configured with multiple values. It is possible to specify multiple values forthese properties programmatically in the local environment tree. provides an example of how thiscan be done using ESQL.

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

-- Create multiple classificationsSET 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.



Page 12 of 17

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

// Create multiple classificationsenvRoot.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 RegistryLookup nodes allows you to work around a limitation that exists on these nodes. IBM IntegrationToolkit forces you to specify a value for at least one of the name, namespace or versionproperties on these nodes. If you do not specify a value for any of these properties you will get anerror message when you save the message flow and you will be unable to deploy it. In order towork around this limitation you can simply specify a dummy value for one of these properties andthen programmatically clear the value earlier in the flow. shows an example of specifying a value ofdummy for the name property on a Registry Lookup node.

Specifying A Dummy Name

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

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

Generated XPath expressionsAs mentioned above, both the Endpoint Lookup and Registry Lookup nodes generate the XPathexpressions that are used to query WSRR based on the properties that are specified on the node



Page 13 of 17

or programmatically in the local environment tree. The XPath expression that is generated by theEndpoint Lookup node is of the form shown in .

XPath query generated by Endpoint Lookup node/WSRR/WSDLService/ports[binding/portType[ @name='' and @namespace='' and @version=''] and @='' and ... @='' and exactlyClassifiedByAllOf(., '', ... ,'')]

Where:

is the value of the PortType Name property. is the value of PortType Namespace property. is the value of the PortType Version property. is the value of the first User Property specified, if any. 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='' and @namespace='' and @version='' and @='' and ... @='' and exactlyClassifiedByAllOf(., '', ... ,'')]

is the value of the Name property. is the value of Namespace property. is the value of the Version property. is the value of the first User Property specified, if any. is the value of the first User Property specified, if any. 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 thatproperty is omitted from the generated XPath expression. For example, if you included theRegistry Lookup node in a message flow and only specified a value of MyTestService for the Nameproperty, 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 EndpointLookup and Registry Lookup nodes make use of the exactlyClassifiedByAllOf custom XPath



Page 14 of 17

function provided by WSRR. This function will return objects that have been classified by all ofthe specified OWL URIs and does not consider any child classifications. For example, if youwanted to return all of the endpoints for a service that have been classified with an environmentclassification, you would not simply be able to specify the OWL URI of the Environmentclassification, as shown below, 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 objectsthat you wanted to be included in the query results. For example, out of the box WSRR defines thefollowing child classifications of the environment classification:

http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Developmenthttp://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Productionhttp://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileTaxonomy#Staginghttp://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 haveimpact on the performance of a message flow at runtime. In order to improve the performance ofmessage flows that make use of the Endpoint Lookup and Registry Lookup nodes, IIB providesa cache that is used to store the results of the queries performed by these nodes. This cache isdiscussed in more detail in Part 7: Configuring the WSRR Cache in IIB.

Conclusion

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

Acknowledgements

The author would like to thank the following people for all of their help with the development of thesample messages flows in this series:

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

The author would also like to thank the following people for their help with reviewing this article:



Page 15 of 17

David Seager Arnauld Desprets Anna Maciejkowicz



Page 16 of 17

Resources

IIB V9 information center IIB V9 information center: Updating a message by using XPath extensions IIB V9 information center: Dynamically defining the search criteria WSRR V8 information center WSRR V8 information center: XPath function reference



Page 17 of 17

About the author

Martin Smithson

Martin Smithson is an Architect working on WebSphere Service Registry andRepository at the IBM Software Lab in Hursley, England. He has 17 years ofexperience working in the IT industry, including both software development andtechnical consultancy roles. His areas of expertise include the architecture, designand development of J2EE applications; he is also an expert on IBM WebSphereApplication Server. He has authored several developerWorks articles and co-authoredseveral Redbooks: WebSphere Application Server V6 System Management andConfiguration Handbook , WebSphere Application Server V6.1: System Managementand Configuration, WebSphere Service Registry and Repository Handbook, and CCF Connectors and Database Connections Using WebSphere Advanced Edition --Connecting Enterprise Information Systems to the Web. Martin also developed theIBM Client Application Tool for JMS.

Copyright IBM Corporation 2014(www.ibm.com/legal/copytrade.shtml)Trademarks(www.ibm.com/developerworks/ibm/trademarks/)

Table of ContentsIntroductionNode TerminalsEndpoint Lookup nodeRegistry Lookup nodeProgrammatically overriding the node propertiesGenerated XPath expressionsPerformance and cachingConclusionAcknowledgementsResourcesAbout the authorTrademarks

Smithson PDF

Documents

thewsrr node

wsrr node terminalsterminals

service metadata

websphereservice registry

theenpoint lookup

nodes processing

ibm integration buspage

message flow node palette