Download PDF (1.3 MB) - IBM Redbooks

Minimizing cross-component asynchronous invocations within a
module
Asynchronous invocations are intended to provide a rich set of qualities of service, including
transactions, persistence, and recoverability. Therefore, think of an asynchronous invocation
as a full messaging hop to its target. When the intended target of the invocation is in the same
module, a synchronous invocation yields better performance.
Some qualities of services (such as event sequencing and store-and-forward) can only be
associated with asynchronous SCA calls. Consider the performance impact of asynchronous
invocations when setting these qualities of service.
Performance considerations for asynchronous invocation of
synchronous services in a FanOut/FanIn block
Do not select asynchronous (deferred response interaction) service invocations for services
with synchronous bindings (for example, web services) unless there is an overriding need and
the non-performance implications for this style of invocation are understood.
Apart from the performance implications of calling a synchronous service asynchronously,
you must consider reliability and transactional aspects. Generally, use asynchronous callouts
only for idempotent query type services. If you need to guarantee that the service is called
only once, do not use asynchronous invocation. Provide complete guidance on the functional
applicability of using asynchronous callouts in your mediation flow is beyond the scope of this
paper.
More information is in the Integration Designer help documentation and Business Process
Manager V8.0 Information Center:
http://pic.dhe.ibm.com/infocenter/dmndhelp/v8r0mx/index.jsp?topic=%2Fcom.ibm.wbpm.
main.doc%2Fic-homepage-bpm.html
Assuming that asynchronous callouts are functionally applicable for your configuration, there
might be a performance reason for starting a service in this style. However, understand that
asynchronous processing is inherently more expensive in terms of processor cycles because
of the additional messaging resources incurred by calling a service this way.
Additional operational considerations in choosing synchronous or asynchronous mode might
apply. For example, asynchronous invocations use the service integration bus messaging
infrastructure, which in turn uses a database for persistence. Synchronous invocations
perform well with basic tuning of the JVM heap size and thread pools, but for asynchronous
invocations, SCA artifacts require review and tuning. This requirement includes tuning the
SCA messaging engine (see 4.3.7, “Messaging engine properties” on page 56), data sources
(see 4.3.6, “Java Database Connectivity data source parameters” on page 55), and the
database itself. For the data source, the tuning for JMS bindings in this paper can provide
guidance as the considerations are the same.
If multiple synchronous services with large latencies are called, asynchronous invocations
can reduce the overall response time of the mediation flow, but at the expense of increasing
the internal response time of each individual service call. This reduction of overall response
time and increase of internal response time assume that asynchronous callouts are
configured with parallel waiting in the FanOut section of the flow under the following
conditions:
►
►
With iteration of an array when configuring the FanOut to check for asynchronous
responses after all or N messages are fired
With extra wires or FlowOrder primitive (by default)
Chapter 3. Development best practices 41