This chapter is from the book
This chapter is from the book
This chapter is from the book
In-Out Example and Implementation Options
There are two variations on the In-Out pattern: synchronous and asynchronous. In the synchronous pattern, the service consumer (the Subscriber in the example) waits for the response from the service provider (the Newspaper). In the asynchronous variation, the service consumer does not have to wait for the response. Since there are significant differences between these variations in both behavior and implementation options, they will be discussed separately.
Synchronous Variation
The subscribe In-Out process, implemented as a synchronous interaction, is shown in Figure 11-9. The subscriber is invoking the subscribe() operation on the newspaper, sending a SubscribeRequest and expecting a SubscribeResponse in return. In the synchronous variation, the subscriber is actively waiting for the response.
){kind=link}
Figure 11-9 Synchronous Subscribe Process
If both subscriber and newspaper were to be implemented as ActiveMatrix components, the result would be a design similar to Figure 11-10.
){kind=link}
Figure 11-10 ActiveMatrix Design for Subscribe Process
For this design you have four transportation options in ActiveMatrix:
- SOAP over HTTP
- SOAP over JMS
- SOAP over ActiveMatrix Virtualization
- XML over JMS
For this synchronous variation, the assumption is that both parties are active for the duration of the exchange. The loss of communications or the restart of either party may cause exceptions, and both parties should be designed to handle these exceptions gracefully.
There are five implementation types that would be appropriate for the subscriber: BusinessWorks, Java, C++, Spring, and WebApp. There are four that would be appropriate for the Newspaper: BusinessWorks, Java, C++, and Spring. Note that WebApp would not be appropriate since its input is just the raw HTTP protocol.
Asynchronous Variations
There are actually two asynchronous variations for a request-reply exchange. One is the checkpoint pattern shown in Figure 11-11. In this pattern the requestor does not necessarily wait for the reply, but generally must take steps to ensure that, when the reply arrives, it is in a position to handle it. This generally means creating a checkpoint, a recoverable snapshot of the requestor's state. In addition, the requestor (in this case the Subscriber) must be implemented in such a way that, should the requestor be halted for any reason, it is resurrected from the checkpoint and is ready to receive the response. Optionally, the process may be suspended to free up resources while waiting for the response.
){kind=link}
Figure 11-11 Checkpoint Asynchronous In-Out Pattern
The checkpoint asynchronous In-Out pattern is typically used when the performance of the requested service is expected to take significant time (minutes or longer). The idea is that, because of the long wait, there is a reasonable possibility that the requestor may be interrupted and you do not want the interruption to adversely impact the execution of the business process. Note, however, that this pattern ties up some resources for each outstanding request.
The other major variation is the third-party asynchronous In-Out pattern shown in Figure 11-12. Here the response is handled by a third party, either a different thread in the requesting process or a completely independent application. In this case there is usually a need for some additional communications between the party sending the request and the party receiving the response.
){kind=link}
Figure 11-12 Third-Party Asynchronous In-Out Pattern
This additional communication conveys the context information required to handle the response. The content of this context varies from solution to solution, but typically includes information such as:
- Notification that there is an outstanding request. This information (in conjunction with a response-time SLA) enables the response handler to determine when responses are missing or overdue.
- An identifier for the request that will be returned as part of the response. This allows the response handler to correlate a particular request-response pair.
- Information about the nature of the request needed to properly handle the response. This can be the information itself or a reference to a location (database, file, etc.) in which this information can be found.
The communication of the context information is a design task that should not be overlooked when selecting this pattern. It always requires design and implementation work.
At present the only transport in ActiveMatrix that can support these asynchronous interaction patterns is XML over JMS. When using this transport, the JMSCorrelationID should be used in the request to uniquely identify the request. The value for this field is provided by the requestor and should be returned in the JMSCorrelationID field of the response. Also required is the JMSReplyTo field in the request. Its value should indicate the JMS destination to which the response should be sent.
There are four implementation types that would be appropriate for the subscriber: BusinessWorks, Java, C++, and Spring. The Business Works implementation type is particularly well suited to implementing the request side (e.g., the subscriber) of the checkpoint asynchronous In-Out pattern, as all the mechanisms required for checkpointing and recovery are provided as part of the product. There are four that would be appropriate for the Newspaper: BusinessWorks, Java, C++, and Spring. Note that WebApp would not be appropriate for either role since its input is just the raw HTTP protocol.