Level: Intermediate Callum Jackson (callumj@uk.ibm.com), Software Engineer, IBM
Brian Hulse (brian_hulse@uk.ibm.com), Software Engineer, IBM
Peter MacFarlane (prmf@uk.ibm.com), Software Engineer, IBM
27 Mar 2008 IBM® WebSphere® Enterprise Service Bus mediation
primitives are reusable building blocks available to application developers to build
mediation flows. This article, Part 2 of a three-part
series,
takes you through the advanced configuration considerations for the new Service Invoke mediation primitive, which allows a mediation flow to invoke a service from
within a mediation flow.
Introduction
WebSphere Enterprise Service Bus V6.1 now provides the capability for service
invocations to be made within both request and response flows. The response from
each service invocation may be handled by a new instance of the mediation flow.
To understand how to benefit from this new functionality, you need to explore the
invocation styles provided by the underlying Service Component Architecture (SCA)
programming model. This article doesn't attempt to describe the model in detail;
it's intended to give you a basic understanding of the principles so you can
determine the expected behaviour of a mediation flow. In the SCA programming
model, there are three different invocation styles that you can use for
request-response operations:
-
Synchronous: A client invokes a service that then executes on the same
thread of execution as the client. When the service returns, the client
continues processing on the same thread (see Figure 1).
Figure 1. Synchronous SCA
invocation
-
Asynchronous with deferred response: A client invokes a service that
then executes on its own thread, while the thread of execution in the client
continues further processing. Later, the thread on which the client is running
requests a response from the service. After the response is received by the
client, or if the response is already available, the client continues processing
on the original thread (see Figure 2).
Figure 2. Asynchronous with
deferred response SCA invocation
-
Asynchronous with callback: A client invokes a service (providing a
callback reference), then continues further processing. The invoked service runs
on its own thread and, when it completes its processing, the response is sent
back to the calling client, which is received on a different thread. This thread
is then used for any further processing by the calling client (see Figure 3).
Figure 3. Asynchronous with
callback SCA invocation
Now that you have a description of the invocation styles provided by the
underlying SCA programming model, let's look at how these styles are used by a
mediation flow component when using a service invoke primitive or a
Callout node to invoke a service.
Synchronous
In the synchronous invocation, the invoked service uses the same thread of
execution as used by the mediation flow. When the thread returns with the service
response, the execution continues in the mediation flow.
Asynchronous with
deferred response
In the asynchronous with deferred response invocation, the invoked service uses a
new thread of execution. The original thread used by the mediation flow requests
the response and waits for the response from the service. If no response is
received within the timeout period defined for the service invocation, the
mediation flow can perform defined retry invocations. If all the retries are
exceeded without an acceptable response from the service, the timeout output
terminal of the service invoke mediation primitive fires.
Figure 4. WebSphere Enterprise
Service Bus asynchronous with deferred response SCA invocation
Asynchronous with
callback
In the asynchronous with callback invocation, the invoked service uses a new
thread of execution. The original thread used by the mediation flow continues, but
any response returned from the invoked service isn't available to this thread.
When the service sends its response, a new instance of the mediation flow
continues processing from the service invoke primitive that performed the service
invocation. However, on the thread of execution of the original instance of the
mediation flow, any further mediation primitives wired on the input side of the
service invoke primitive are invoked. Therefore, two or more (if more than one
service invoke primitive was contained within the module) threads may be
concurrently active for the same instance of the mediation flow component.
Factors that determine
the default mediation flow behaviour
You've read about the different invocation mechanisms and the behaviour of the
mediation flow component. Now let's look at the factors that determine the default
mediation flow behaviour and how you can change the mediation flow definition to
meet your mediation module requirements.
Factor 1: Preferred
interaction style
Each interface specified within the assembly diagram can have an associated SCA
preferred interaction style defined. This can be used by the invoking component
(in this case the mediation flow component) to influence the invocation mechanism.
The styles available are:
-
Any: Indicates no preference and lets the other factors determine the
real interaction style
-
Synchronous: Indicates synchronous invocation is preferred
-
Asynchronous: Indicates the preferred invocation style is either
asynchronous with deferred response or asynchronous with
callback
For a service invocation from a mediation flow component, the preferred
interaction style is normally specified on the import associated with the remote
service (or on the SCA Java™ component in the same mediation module that
contains the service implementation). If a dynamic endpoint is used in the
mediation flow, the preferred interaction style is derived from a default import
wired to the reference used for the dynamic invocation.
An example of the preferred interaction style window in the WebSphere Integration
Developer tooling is shown in Figure 5.
Figure 5. Websphere Enterprise
Service Bus asynchronous with deferred response SCA invocation
Factor 2: Invocation
style used when invoking the mediation flow component
The style that's used to invoke the mediation flow component itself is important
in determining the style used by the mediation flow component when invoking a
service. For example, if the mediation flow component is invoked synchronously,
then the thread executing this request must be the thread that returns the
response. If, however, the mediation flow component then uses the asynchronous
with callback style for a service invocation, the response from the service is
received by the mediation flow component on a new thread. This would be the wrong
thread to return the response to the calling entity. Similarly, if the mediation
component is invoked by a client using the asynchronous with deferred response
style, the thread used for the request must be the thread that returns the
response. It's therefore not possible for the mediation flow component to invoke a
service using asynchronous with callback.
The invocation style that the mediation flow component sees is partly determined
by the binding used on the mediation module export that receives the request. The
styles that may result from various binding types are listed in Table 1.
Table 1. Binding invocation styles
| Bindings | Style |
|---|
| EIS (OneWay and Performance attributes set to
async) | Asynchronous |
|---|
| EIS (all other settings) | Synchronous |
|---|
| HTTP | Synchronous |
|---|
| WebSphere MQ or WebSphere MQ JMS (OneWay) | Asynchronous |
|---|
| WebSphere MQ or WebSphere MQ JMS (Request-Response) | Asynchronous with callback |
|---|
| SCA | Determined by interaction style used by the invoker of the export |
|---|
| SCA JMS (OneWay) | Asynchronous |
|---|
| SCA JMS (Request-Response) | Asynchronous with callback |
|---|
| Stand-alone reference | Determined by interaction style used by the invoker of the invoker of the
stand-alone reference |
|---|
| Web services (SOAP/HTTP or SOAP/JMS) | Synchronous |
|---|
Factor 3: Service Invoke
force synchronous support
The Service Invoke primitive has a property that, when specified, prevents the
mediation flow component from using the asynchronous with callback style for the
service invocation. This property is referred to as the force synchronous
property. The WebSphere Integration Developer tooling identifies this
property with a check box labelled Require mediation flow to wait for service
response when the flow component is invoked asynchronously with callback.
By setting this property, the mediation developer can ensure that the complete
request or response flow executes under a single thread of execution. This is
useful when an entire mediation flow is required to execute under a single
transaction. Also, the use of this property lets the scope of the transaction
include the wiring on the output side of the Service Invoke primitive (regardless
of the style used to invoke the mediation flow component).
Summary of invocation styles
The invocation style used by the mediation flow component for service invocations
with a Service Invoke primitive is determined by three factors:
- The style used to invoke the mediation flow component
- The preferred interaction style of the target import
- The use of the force synchronous property
Table 2. Service Invoke summary table
| MFC invocation style | Target preferred interaction style | OneWay/Request-Response | Force synchronous | Invocation style used for Service Invoke |
|---|
| invoke(sync) | ANY | OneWay | Any | Async |
|---|
| Request-Response | Any | Sync | | SYNC | Both | Any | Sync | | ASYNC | Both | Any | Async | | invokeAsync | ANY | OneWay | Any | Async |
|---|
| Request-Response | Any | Sync | | SYNC | Both | Any | Sync | | ASYNC | Both | Any | Async | | invokeAsyncWithCallback | ANY | OneWay | Any | Async |
|---|
| Request-Response | True | Async | | False | AsyncWithCallback | | SYNC | Both | Any | Sync | | ASYNC | OneWay | Any | Async | | Request-Response | True | Async | | False | AsyncWithCallback |
The force synchronous property isn't available on a Callout node. The invocation
style used by the mediation flow component for service invocations with a Callout
node is therefore determined by two factors:
- The style used to invoke the mediation flow component
- The preferred interaction style of the target import
The conditions and resulting style are summarised in Table 3.
Table 3. Callout node summary table
| MFC invocation style | Target preferred interaction style | OneWay/Request-Response | Invocation style used for Service Invoke |
|---|
| invoke(sync) | ANY | OneWay | Async |
|---|
| Request-Response | Sync | | SYNC | Both | Sync | | ASYNC | Both | Async | | invokeAsync | ANY | OneWay | Async |
|---|
| Request-Response | Sync | | SYNC | Both | Sync | | ASYNC | Both | Async | | invokeAsyncWithCallback | ANY | OneWay | Async |
|---|
| Request-Response | AsyncWithCallback | | SYNC | Both | Sync | | ASYNC | OneWay | Async | | Request-Response | AsyncWithCallback |
Special behaviour of the
invocation style within a Fan Out or Fan In primitive
Within the aggregation (that is between Fan Out and Fan In primitives), the use
of the asynchronous with callback interaction style is not available. In effect,
the WebSphere Enterprise Service Bus run time enables the force synchronous
property on any Service Invoke primitive within an aggregation boundary.
Special behaviour of the
shared context for asynchronous with callback
As mentioned in the
first article
in this series, the shared context is a thread-based data store that's intended
for use within an aggregation. When a service is invoked with the asynchronous
with callback style, because the callback continues on a new thread, the shared
context is no longer valid. As a result, the callback thread resets for use the
shared context.
Conclusion
This article covered the behaviour of the Service Invoke primitive in depth,
which was introduced as part of WebSphere Enterprise Service Bus V6.1. You should
now have an understanding of the different forms of operation of this primitive
and how it plays in aggregation scenarios.
Resources Learn
Get products and technologies
- Innovate your next
development project with
IBM trial software,
available for download or on DVD.
Discuss
About the authors  | | | Callum Jackson is a software engineer for WebSphere Enterprise Service Bus based in Hursley, United Kingdom, and has worked in the product area since 2005. Prior to this he worked in ISSW on SOA applications for the telecommunication industry. |
| | | Brian Hulse is a senior software engineer for WebSphere Enterprise Service Bus based in Hursley, United Kingdom. He has worked in software development at Hursley for 20 years, the last five of which have been in the SOA arena. |
| | | Peter MacFarlane is a software engineer for the WebSphere Enterprise Service Bus team at the IBM Hursley Lab in the UK. Peter has worked on numerous WebSphere projects, and his current role is in the development of runtime support for mediation components. |
Rate this page
| 
