Chapter 11. Basic Interaction Patterns
This chapter examines the simplest possible interactions between two parties. The architecture pattern for these discussions (Figure 11-1) is, as you would expect, trivial. It consists of the two parties, here referred to as the service consumer and service provider. Despite the fact that we are referring to services, the patterns being discussed can be generalized to represent any interactions between two parties.
Figure 11-1. Architecture Pattern for Two-Party Interactions
The examination of interactions will consider four of the most common ActiveMatrix protocol and transport options: SOAP over HTTP, SOAP over JMS, SOAP over ActiveMatrix Virtualization, and XML over JMS.
Basic Interaction Pattern Overview
There are four basic message exchange patterns between the two parties: In-Only, In-Out, Out-Only, and Out-In. The In-Only pattern is shown in Figure 11-2. In it, the service consumer sends a single message to the service provider and expects no response. The intent is generally that the arrival of the input will trigger the service provider to do something useful. Common examples of this pattern include e-mails and text messages.
The In-Out pattern (Figure 11-3), also referred to as the request-reply pattern, is a simple extension of the In-Only pattern that adds a response (the output) from the service provider. Here the intent is a bit more explicit: The service consumer provides the input and expects the arrival of the input to trigger the service provider to do something and then send a response. This is the pattern you encounter when you execute a search online: You submit the search terms (the input) and expect a list of “hits” as a response (the output).
The Out-Only pattern (Figure 11-4) is very similar to the In-Only pattern, the distinction being that the single message is an output going from the service provider to the service consumer. Common examples of this pattern include announcements of various sorts. It is common in this pattern for there to be many service consumers for a given input (this will be discussed further in Chapter 12). When the service provider is a system of record for some information, this pattern is suitable for announcing changes to this information.
The Out-In pattern (Figure 11-5) extends the Out-Only pattern to include a response back to the service provider. A common example of this is an automobile recall notice: The manufacturer sends you a notification that there is a defect in your automobile that requires correction. The manufacturer expects a response from you to schedule an appointment and get the defect corrected. Another example is an offer that requires a response.
Example Case Study: A Newspaper
To illustrate these four interaction patterns and their implementation options we will use a simple example based on a newspaper business (Figure 11-6). In this example there are three participants: the newspaper itself, a party acting as a news source, and a customer of the newspaper.
Figure 11-6. Newspaper Example Architecture Pattern
We will examine four use cases (processes) involving these participants:
• The news source delivering a news tip to the newspaper (In-Only)
• The customer subscribing to the newspaper (In-Out)
• The newspaper sending the news electronically to the customer (Out-Only)
• The newspaper sending an offer to the customer that requires a response (Out-In)
In-Only Example and Implementation Options
The In-Only example from the newspaper is the news source sending a news tip to the newspaper (Figure 11-7). Here the news source invokes a receiveTip() operation provided by the newspaper’s service interface.
If you were to implement both the news source and the newspaper as ActiveMatrix components and indicate the news source’s reference of the newspaper’s service, the result would be a design similar to that shown in Figure 11-8.
Figure 11-8. ActiveMatrix Design for Send Tip Process
For this design you have four transportation options in ActiveMatrix:
• SOAP over HTTP
• SOAP over JMS
• SOAP over ActiveMatrix Virtualization
• XML over JMS
The first of these options uses HTTP as a transport. The implication is that both parties need to be active simultaneously in order for an interaction to occur. The SOAP over JMS and XML over JMS options, because they use a JMS server as a communications intermediary, make it possible for the news source to send the tip when the newspaper is not actively receiving communications. The JMS server will forward the message when the newspaper becomes active.
Despite the fact that ActiveMatrix Virtualization also uses JMS as its underlying communications mechanism, it will not be able to forward a message if the newspaper is not active at the time it is sent. For an explanation, see the “ActiveMatrix Virtualization Transport Limitations” sidebar.
There are five implementation types that would be appropriate for the News Source: TIBCO ActiveMatrix 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.
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.
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.
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.
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.
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.
Out-Only Example and Implementation Options
The process for delivering the newspaper is shown in Figure 11-13. This Out-Only interaction is inherently asynchronous—the Subscriber is not actively waiting for the paper to be delivered.
Figure 11-13. Deliver Paper Process
The only ActiveMatrix transport that can support this pattern today is XML over JMS.
The Out-Only pattern is, unfortunately, not well represented in the current version of the SCA notation.1 The closest you can come in the present notation is the design shown in Figure 11-14. There are two problems with this representation. One is that the diagram implies that it is the subscriber providing the service and the newspaper referencing the service, when in reality the opposite is true. The other is that, for most publications, it is unlikely that the wiring between the Out-Only service provider and service consumer would be done at design time. In other words, it is unlikely that you would ever show both the service provider and service consumer in the same SCA composite. Instead, this wiring would be done either at deployment time or at run time.
Figure 11-14. Inappropriate Attempt to Represent Out-Only Pattern in Present SCA Notation
What you would create in ActiveMatrix today (until such time as the SCA Event Processing Specification is completed) is a composite containing just the service provider (Figure 11-15). Note that the composite shows a reference to the service; the reason is that when you generate implementations, references generate outbound calls, which is consistent with the design intent. This structure (the component referencing the service) can be incorporated into any composite wishing to send Out-Only notifications.
Figure 11-15. SCA Approximation of an Out-Only Service Provider
Similarly, you would create the service consumer as a composite with a promoted service (Figure 11-16). From an implementation perspective, this is appropriate since, when you generate the implementation, the generated structure will be appropriate for an inbound call. This structure (the service and its association with a component) can be incorporated into any composite that wishes to receive Out-Only notifications from a service provider.
Figure 11-16. SCA Approximation of an Out-Only Service Consumer
There is a bit of hidden JMS administrative configuration required to connect the two parties in this pattern. The JMS destination must be created (or the JMS server must be configured to auto-create destinations), and both parties must be configured to use the same destination. This is generally straightforward when the configuration is done at deployment time, but dynamic connection at runtime will require extra design work. For example, if you wanted to have a subscriber dynamically create the subscription, the subscribe() operation would have to return the JMS destination and the subscriber would have to have code to alter its configuration to receive messages from this destination.
There are five implementation types that would be appropriate for the newspaper: BusinessWorks, Java, C++, Spring, and WebApp. There are four that would be appropriate for the subscriber: BusinessWorks, Java, C++, and Spring. Note that WebApp would not be appropriate for the subscriber since its input is just the raw HTTP protocol.
Out-In Example and Implementation Options
The process of the newspaper making an offer to a subscriber and then handling the response is shown in Figure 11-17. The interactions here are, by definition, asynchronous: Neither party is actively waiting for an input. Furthermore, the service provider (the newspaper) will likely have separate threads (or applications) for sending the offers and processing the responses. Consequently, there will likely be a need to communicate context information between these two threads as was discussed in the earlier asynchronous In-Out example.
Figure 11-17. Make Offer Process
As with the Out-Only pattern, the only suitable protocol and transport combination available in ActiveMatrix is XML over JMS. The SCA design would be similar to that discussed in the Out-Only example, and the JMSCorrelationID and JMSReplyTo properties would have to be used as described in the Asynchronous In-Out example.
There are five implementation types that would be appropriate for the newspaper: BusinessWorks, Java, C++, and Spring. There are four that would be appropriate for the subscriber: BusinessWorks, Java, C++, and Spring. Note that WebApp would not be appropriate for either role since its input is just the raw HTTP protocol.
Summary
There are four basic message exchange patterns between two parties: In-Only, In-Out, Out-Only, and Out-In. The In-Only pattern and the synchronous variation of the In-Out pattern have many protocol and transport options in ActiveMatrix, including SOAP over HTTP, JMS, and ActiveMatrix Virtualization as well as XML over JMS. The BusinessWorks, Java, C++, Spring, and WebApp implementation types are all suitable for the service-consumer side of these interactions, while the BusinessWorks, Java, C++, and Spring implementation types are appropriate for the service-provider side.
The asynchronous variation of the In-Out pattern and the Out-Only and Out-In patterns all involve asynchronous interactions. At present, the only suitable protocol and transport combination in ActiveMatrix for asynchronous interactions is XML over JMS. For the asynchronous In-Out and Out-In, the JMSCorrelationID and JMSReplyTo properties should be used to correlate the request and reply messages and indicate the JMS destination to which the replies should be sent. For these patterns, the BusinessWorks, Java, C++, and Spring implementation types are all suitable for both parties.