Overriding a Web Service Endpoint in WebSphere ESB

When working with Mediation Flows in WebSphere ESB, and you have a Web Service import defined that connects out to an external Web Service, you might want to override the default endpoint. Here’s a (not exhaustive) list of ways to do that (the numbers in brackets indicate the version that the feature is available from):

  • (6.0.2+) The most flexible and long-term way: integrate with the Web Services Registry and Repository product by using the Endpoint Lookup mediation primitive. This allows you to dynamically look up service endpoints (i.e. URLs), by retrieving them from the registry based on criteria you set. The primitive, in some modes, automatically sets the /headers/SMOHeader/Target/address section of the Service Message Object (SMO), which exploits the dynamic callout capability in WebSphere ESB to override the default endpoint when the callout is performed. In other modes, multiple endpoints might be retrieved, so you would to select the appropriate one and populate that section manually.
  • (7.0+) Use the new UDDI Endpoint Lookup primitive, which works in a very similar way to the regular Endpoint Lookup primitive, but instead looks up endpoints from a UDDI registry.
  • (6.0.2+) Use the dynamic callout facilities of WebSphere ESB directly by populating the /headers/SMOHeader/Target/address section of the SMO directly. You could do this by writing your own logic in a custom mediation, for example, or you could populate it with a hardcoded value using a Message Element Setter.
  • (6.0.1+) Override the endpoint statically in the admin console after deploying the application. To do this, you’d first locate the relevant SCA module deployed in the admin console, then select the import binding you are interested in:
    Then, you can modify the endpoint accordingly:

    This might be useful if you are deploying different copies of your mediation flow to different servers, and wanted to use different endpoints in each case. Note that the methods above, which use dynamic endpoint support, will override whatever you set here, so this is only useful if you aren’t using dynamic endpoint support.

(Note: this tip applies equally to WebSphere Process Server)

WebSphere ESB / Integration Developer / Process Server 7.0 Announced

For those already working with WebSphere Integration Developer, WebSphere ESB, or WebSphere Process Server, or those considering using them, you might be interested to know that version 7.0 has just been announced and is scheduled to be available around the end of Q4 2009.

Please look at the official announcement for more information, but some of the new things I think are particularly interesting are:

  • Service Federation Management between WebSphere Services Registry and Repository and WebSphere ESB.
  • More pattern-based development.
  • Exploitation of WebSphere Application Server V7.
  • Improved Service Gateway scenario support.
  • Event sequencing support in WebSphere ESB.

Specifying Transitions for WSRR Promotion

If you’re using the promotion feature of WebSphere Services Registry and Repository (WSRR) to copy content from one registry instance to another on governance state changes, you’ll need to specify which transitions are used for promotion. This is described here. However, what may not be entirely clear are the names to be used for the transitions. These must map to the operation name of the governance transition, and not to the transition name itself. For example, the ‘Plan’ transition of the default governance lifecycle is defined in SACL like this:

<sacl:stateMachineDefinition ...
 targetNamespace="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/governance/DefaultLifecycle">
    ...
    <sacl:transition name="Transition1">
      <sacl:sourceState>InitialState1</sacl:sourceState>
      <sacl:operation name="Plan" portType="_:DefaultLifecycle"/>
      <sacl:targetState>State1</sacl:targetState>
    </sacl:transition>

Therefore, the transition is defined like this in the Promotion Properties:

  <transitions>
    <transition
     name="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/governance/DefaultLifecycle#Plan">
     ...
    </transition>
  </transitions>

Note the use of Plan rather than Transition1.

Thanks to Steve Groeger and Martin Smithson for their help with this tip.

Looking up Governance States in WSRR using WebSphere ESB

Let’s say you want to use the Endpoint Lookup primitive in WebSphere ESB to lookup an endpoint stored in WebSphere Services Registry and Repository (WSRR), but matching against the governance state of the endpoint. For example, you might want to only lookup endpoints which are in the ‘Managed’ state – i.e. they are deployed and ready to work with. How would you do this?

Well, in WebSphere ESB, when you’re specifying the properties of Endpoint Lookup primitive, you get the ability to specify Classifications. These are matched against Classifications in WSRR – including the governance state.

For example, let’s assume that we’ve loaded a WSDL document into WSRR and already transitioned it into the ‘Managed’ state. We’ve specified most of the properties for the Endpoint Lookup primitive already, such as the interface we are looking up. We now need to know what the syntax is for the Classification that we’re going to use. In WSRR, we go to the Configuration perspective in the admin console. Then we navigate to Active Configuration Profile / Classification Systems. We select Life Cycle Classifications and then click Edit. This should look like this:

Now click on Classes, expand out the tree, and you should see something like this:

Click on Managed and you’ll get to see the Class ID:

This is the important value, because this is the value that you’ll need to specify as a classification in your Endpoint Lookup primitive:

Now, when the lookup is performed, only endpoints in the Managed state will be returned.

Note: The classifications are logically ANDed together: if you specify multiple ones, the endpoint must match all of the classifications.

Thanks to Andrew Borley, Bernard Kufluk and David Bell for help with this tip.

WebSphere SOA 6.1 Products Announced

I’m pleased to report that IBM has officially announced WebSphere Enterprise Service Bus 6.1, the product my colleagues in the development team are currently working on. 6.1 versions of its sister product WebSphere Process Server, the associated tool WebSphere Integration Developer, WebSphere Message Broker, and the WebSphere Service Registry and Repository have also been announced. Please see the announcement letter for more information.

Secure connections to WebSphere Service Registry and Repository

If you have a secured instance of WebSphere Service Registry and Repository and you want to use the Endpoint Lookup mediation primitive to use this instance to determine which endpoints you have available, then you may want to check out this technote which describes the configuration steps necessary and an iFix you will require if you are on the 6.0.2.0 level of the WebSphere ESB or WebSphere Process Server.

Importing artifacts from WebSphere Service Registry and Repository

WebSphere Service Registry and Respository is a service metadata repository which can be used to store artifacts such as interfaces (WSDL), business objects and XML structures. If you are developing modules/mediation modules (inside WebSphere Integration Developer) using these artifacts then you will want to be able to import these artifacts directly. The guidance on how to configure WebSphere Integration Developer to connect to WebSphere Service Registry and Repository and how to discover artifacts can be found here in the Information Center.