Understanding the Service Invoke Primitive

I find that folks are sometimes confused by the Service Invoke primitive available in WebSphere ESB Mediation Modules. It’s best to explain this with a bit of history.

In the first two versions of WebSphere ESB (6.0.1 and 6.0.2), only one invocation of a back-end reference (i.e. an import or an outbound adapter) was possible per mediation flow – at least without some custom coding. The part of the mediation flow that is executed before the invocation is done is called the request flow, and looks like this:

request1

The part of the mediation that is executed after the invocation is called the response flow, and looks like this:

response

The response flow is visible once you’ve dragged the arrow across to define which back-end operation and partner reference is to be used:

arrow

However, as of WebSphere ESB 6.1, a Service Invoke primitive was also made available. This allows invocations ‘in-line’ inside a flow. It looks like this:

serviceinvoke

This means that more than one invocation can be made per mediation flow, by using multiple Service Invoke primitives. However, it is also still possible to use the request and response flows as well. This can lead to confusion, where one of invocations is done via the request/response mechanism, and one or more other invocations via Service Invoke primitives. It’s important to remember that the Service Invoke is essentially the equivalent of the Callout node on the request flow combined with the Callout Response node on the response flow.

In general, I would recommend using either the request / response style of invocation, or the Service Invoke node with no response flow (the response to the original invoker going into the Input Response node on the request flow). If you are determined to mix both, try to make the request / response invocation your ‘primary’ one, conceptually.

WebSphere ESB v6.2 Available

Dave has already beaten me in laying out the details, but it’s worth pointing out that WebSphere ESB 6.2 (together with its tooling environment, WebSphere Integration Developer, and larger business-process-choreographing cousin, WebSphere Process Server), are now available. There’s some good stuff in there; check out the DeveloperWorks articles on Integration Developer and Process Server to find out more.