- Basic Interaction Pattern Overview
- Example Case Study: A Newspaper
- In-Only Example and Implementation Options
- In-Out Example and Implementation Options
- Out-Only Example and Implementation Options
- Out-In Example and Implementation Options
- Summary
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.