In the SCA world, the asynchronous invocation is a widely used pattern. In these patterns, the caller can:
- Initiate the call without knowing about the result (one-way).
- Retrieve the result later by itself (deferred-response).
- Be called by the target to receive the result (callback).
The ARM transaction in IBM WebSphere® Process Server V6.1 mirrors the detailed transaction in the SCA invocation, which can present the behaviors of the client and the target service.
In this article, you learn about the multiple SCA invocation patterns and the related ARM observation points, and see some examples of how to debug asynchronous scenarios using Tivoli Composite Management for Response Time Tracking.
SCA invocation pattern in WebSphere Process Server V6.1
In Figures 1 through 6, many patterns are presented according to different invocation, operation, and implementation types. Let's look at these three terms more closely first:
Synchronous and asynchronous invocation
The SCA invocation pattern represents the behavior of the caller. SCA
invocation supports both synchronous and asynchronous patterns. Synchronous
invocation means the caller or client doesn't proceed until the service or
the callee returns, which is the widely used pattern in most programming
languages. As the services being loosely coupled in SCA, asynchronous
invocation is also an important pattern, providing three different modes:
- Asynchronous one-way invocation: The client doesn't wait for any return message from the target; the operation returns directly after invoking, and the invocation is simply finished.
- Asynchronous deferred-response invocation: The client proceeds to work after invocation, later querying the result on its initiative.
- Asynchronous callback invocation: The client proceeds to work after invocation just as in the deferred-response invocation, but the result is notified by the target when calling the client's callback method.
Synchronous and asynchronous implementation:
This is the style regarding the target. When the target is asynchronously
implemented and the client requires the result (using the request-response
operation), the actual result is set in a message other than the first message
that the target returns. In particular, in WebSphere Process Server V6.1,
Java™
Message Service (JMS) binding, long-running
business process, interface mediation, and so on are
asynchronously implemented. In Java,
you can implement the target either synchronously or asynchronously.
One-way and request-response operation:
One-way and request-response are the primitives defined in Web Services
Description Language (WSDL). The difference is whether the endpoint sends a
correlated message after receiving a message. Here you can see it as whether
the client requires or retrieves the execution result after invoking
services.
The WebSphere Process Server V6.1 monitoring ARM observer supports all SCA
invocation patterns. Figures 1 through 6 give you the technical pictures of the relationship between ARM
observation points and transactions, and SCA message flow in different SCA invocation
patterns. The start and stop observation points are marked to show when the
timestamps are recorded. The status is reported within the stop() method, and
tran<number> is the identifier for the
transactions. (For the ARM-related topic, see the first article in this series.)
Check out the meanings and lineages of the transactions in Table 1.
Table 1. The transactions and their lineages in Figures 1-6
| Transaction | Denotation | Parent |
|---|---|---|
| tran1 | Request delivery from client view | (No parent) |
| tran2 | Request delivery from target view | tran1 |
| tran3 | Result retrieval (deferred-response) and callback (callback) | tran2 |
Three parties are involved in these diagrams:
- Caller: The component that initiates the invocation
- Service: The component that executes the requested service
- SCA: Denotes the container that handles the request or response between the caller and the service
Figure 1. Synchronous invocation (one-way operation) over synchronous implementation
Figure 2. Synchronous invocation (one-way operation) over asynchronous implementation
Figure 3. Synchronous invocation (request-response operation)
Figure 4. Asynchronous one-way invocation
Figure 5. Asynchronous deferred-response invocation
Figure 6. Asynchronous callback invocation
This section shows you how to debug the asynchronous one-way, deferred-response, and callback invocations.
The scenario is a simple one as Figure 7 shows. The Stand-alone Reference
invokes the component Invoker by the typical synchronous invocation, which
is the same pattern as the example in Part 1. The component
Invoker invokes the component InvokeeSync (synchronous implemented)
by the asynchronous invocations (one-way, deferred-response, and callback
separately in the example), which are the invocations you focus on here.
Figure 7. Asynchronous invocation scenario
To generate the report, just follow the procedure demonstrated in Part 1 of the series. The environment prerequisite, installation, and data-collecting process here are the same as the previous example.
For the topology report, you can still get the high-level transaction view, as Figure 8 shows.
Figure 8. High-level view of transactions
If you expand the grouped transactions you can see the transactions that parallel the ones in Figures 1 through 6.
Now let's look at each breakdown view of the invocations.
Asynchronous one-way invocation
In the scenario, when the invocation between Invoker
and InvokeeSync
is an asynchronous one-way invocation, you get the breakdown view shown in Figures 9 and
10.
Figure 9. Asynchronous one-way invocation transaction table
Figure 10. Asynchronous one-way invocation breakdown view
The first two transactions are the ones between the Stand-alone Reference and
the component named Invoker, whose pattern is described
in Part 1 of this series. The later two are the ones between Invoker and
InvokeeSync, with the one-way invocation pattern.
Now focus on the last two transaction bars. Compare them to the transactions in Figure 4; they match tran1 and tran2. The first transaction is the one in the client side, which ends directly after the invocation is initiated, and the second transaction starts later in the target side, which ends after the target service has completed all its local tasks.
So in a higher-level scope, if you want to get the local time of the
component, not the detailed transaction, you can draw a local-time view like Figure
11. Here the blue shadow is the local time for the Invoker component, and the red
shadow is the local time for the InvokeeSync component.
Figure 11. Synchronous invocation (one-way operation) over synchronous implementation
The rule that's used to divide the time bar is the same as the one in Part 1:
But the asynchronous invocation isn't as simple as the synchronous one. Table 2 clarifies the meaning of the time in the formula, which applies to both synchronous and asynchronous scenarios.
Table 2. Meaning of the time in the formula
 | The time spent in the local processing in the component added to the time taken in the SCA run time ahead of the component. For Figure 12, (t2-t1)-(t4-t3) is Component B's local time. |
 | The time spent in the SCA run time ahead of the component added to the time in the component (including the waiting time for the downstream service). In the breakdown view, it denotes the lifetime that contains all the transactions for this component. For Figure 12, (t2-t1) is Component B's response time. |
 | The time of a certain downstream transaction that the caller is interacting
with. Note: In the asynchronous scenarios, it's the
time spent in the next transaction rather than the next component. (Look at
another one-way invocation example, shown in Figure 13. Here the
Invoker has other jobs to do after invoking the
next component. You can see the overlap between the blue shadow and the red shadow, which is typical in one-way invocation, indicating that the Invoker doesn't wait for the
InvokeeSync to complete; instead, it continues to run on its own
initiative. |
Figure 12. Response time and local time
Figure 13. Overlap between the local-time shadows in the asynchronous one-way invocation
For the synchronous invocation (one-way operation) over asynchronous implementation scenario (see Figure 2), the breakdown view is similar to the one in this scenario, which can be regarded as a special case for synchronous invocation.
Asynchronous deferred-response invocation
When the invocation between Invoker and InvokeeSync is an asynchronous
deferred-response invocation, you get the breakdown view shown in Figures 14 and 15.
Figure 14. Deferred-response invocation transaction table
Figure 15. Asynchronous deferred-response invocation breakdown view
The last two transactions shown in Figure 15 are in the deferred-response invocation, which parallel tran1 and tran2 in Figure 5. Following the same rule given in the one-way invocation example, the local-time picture is shown in Figure 16.
Figure 16. Asynchronous deferred-response invocation local-time analysis
Asynchronous callback invocation
When the invocation between Invoker and InvokeeSync is an asynchronous
callback invocation, you get the breakdown view shown in Figures 17 and 18.
Figure 17. Asynchronous callback invocation transaction table
Figure 18. Asynchronous callback invocation breakdown view
In the callback invocation, there are three transactions (see the last three transactions in Figure 18):
- The one at the client side to make the invocation
- The one at the target side to execute
- The one at the client side to be called and receive the result
These three parallel the ones shown in Figure 6.
Guided by the same rule, you can draw the local-time picture, as Figure 19 shows.
Figure 19. Asynchronous callback invocation local-time analysis
Now you can identify the transactions and get the graphic estimation of local time for each component in all kinds of SCA invocations.
As mentioned in Part 1 of this article series, WebSphere Process Server V6.1 provides multiple ways to monitor SCA invocation. Among these options, ARM is a good approach to debug the response time for the transactions. By using the proper implementation, such as Tivoli Composite Application Management for Response Time Tracking, various kinds of reports can be generated, enabling the debugging through SCA invocations to observe the health and identify the bottleneck or failure point.
Learn
- Read Part 1 of this series to learn more about
ARM and the way to set up Tivoli Composite Application Management for
Response Time Tracking.
- Visit OpenGroup.org to find ARM
documents and Java interface files.
- Get
relevant skills
for WebSphere Process Server V6.1 and WebSphere
Integration Developer V6.1.
- Visit the IBM Tivoli
information center to get the
IBM Tivoli Composite Application Manager for Response Time Tracking Installation
and Configuration Guide (click Composite Application Manager for Response Time
Tracking > Installation
and Configuration Guide in the left pane).
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts.
- Browse for books on these and other technical topics at the
Safari bookstore.
- Check out a quick Web services on demand demo.
- Get an RSS feed for this series. (Find out more about RSS.)
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
- Get involved in the developerWorks community
by participating in developerWorks blogs.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
