Pattern 11: Request with referral.
Description. Party A sends a request to party B indicating that any follow-up response should be sent to a number of other parties (P1, P2, ..., Pn) depending on the evaluation of certain conditions. While faults are sent by default to these parties, they could alternatively be sent to another nominated party (which may be party A).
Solution. At the messaging level, this pattern is addressed in part by WS-Addressing which defined (among others) two fields that can be included in SOAP message headers, namely reply-to and fault-to. Using these fields, it is possible to specify the service endpoint(s) to which replies and faults should be sent. The information allowing the referred service to correlate the incoming message with its internal processes may be transferred in one of two ways depending of the adopted state representation style (Fielding 2000): (i) it may be encoded in the endpoint reference itself (as per the REST architectural style); or (ii) it may be encoded somewhere else in the message (e.g. in the message body). In the supplier-shipper-customer example, the supplier passes to the transport service, a reference to the customer's procurement service endpoint. In the first style above, this endpoint reference would contain a data item (e.g. the original purchase order ID) allowing the customer to correlate the message with its internal activities (e.g. the activity that expects shipment status notifications for that purchase order), while in the second style, this data item would be encoded inside the shipment status notification.
At the service composition level (specifically in BPEL), endpoint references can be manipulated as ordinary data. In particular they can be included in the contents of a message. They can also be dynamically bound with partner links (e.g. the partner link defined between the transport service and the customer). In addition, BPEL offers a notion of correlation set, which corresponds to information sent along a message that is used on the receiver's end to correlate that message with its internal activities. Correlation sets can thus be used to encode correlation-related information that it not included as part of the endpoint reference.
Pattern 12: Relayed request.
Description. Party A makes a request to party B which delegates the request to other parties (P1, ..., Pn). Parties P1, ..., Pn then continue interactions with party A while party B observes a "view" of the interactions including faults. The interacting parties are aware of this "view" (as part of the condition to interact).
Solution. This pattern, just like the Request with Referral pattern, involves indirection through delegation (party B passes party A's endpoint service reference to delegated parties for further interactions) and can be effected through WS-Addressing or exchanged message data as previously discussed. The correlation strategies similarly apply. The comparative requirement for relayed requests is representing party B's view and enforcing it, including changing it, as interactions execute - as identified through the second and third issues above.
The WS-Addressing strategy conjures up the possibility of including party B in interactions through a "Cc" field. Apart from the fact that WS-Addressing currently does not support a "Cc" field, this suggestion compromises an important requirement of the pattern. The messages passed between party A and the delegated parties would be exactly the same as what party B sees. Of course, not all messages have to be "Cc-ed" to party B, but this remains a rather limited solution since whole message, not filtered messages, are transmitted to B. It is furthermore possible that B do the filtering rather than pushing this up to the level where interactions are generated. We argue, however, that view filtering decoupled from interaction generation, is deficient since party A and the delegated parties no longer have an understanding what they are obliged to reveal to B, as required by the pattern. A corollary of this requirement is that some message content between the parties remains oblivious to B.
This brings us to the core issue of how to specify "views" such that they could be deployed and utilized as part of the interaction cycle. Simple views could be specified through a querying language like XPATH while more sophisticated ones could be supported through XQuery. Party A and the delegated parties would either have static "view" definitions prior to run-time or they would be passed at run-time when B establishes delegation.
For dynamically modified views, B would issue new "views". Of course, these need to be coordinated with A, so that both ends of interactions are subject to the new "view" version. An obvious solution is to accompany a send in an interaction with a second send for party B, conditional upon the view filter applied to the message passed through the first sent. The two sends would need to be atomic.
Pattern 13: Dynamic routing.
Description. A request is required to be routed to several parties based on a routing condition. The routing order is flexible and more than one party can be activated to receive a request. When the parties that were issued the request have completed, the next set of parties are passed the request. Routing can be subject to dynamic conditions based on data contained in the original request or obtained in one of the "intermediate steps".
Solution. The requirements for dynamic routing are outside the scope of direct support through BPEL. Hand-crafted BPEL solutions are possible by allocating structured fields for deriving routing conditions. Routing could then be expressed as a (central) BPEL workflow and events could be defined to be matched against an incoming document from the current step of routing. Permutations of events will have to be coded for the different roles at different steps and the state of the routing thus far. The next roles in routing can be assessed through events, and activities are triggered for these. Of course, this is an convenient solution, to say the least, due to sheer permutation of events by different in different routing states. Furthermore, application coding for document synchronization needs to be provided, noting that this, while required by dynamic routing, is orthogonal to it.
WS-Routing (a proposal not yet under standardization) can serve to implement some aspects of this pattern. Parallel routing, but not interleaved parallel routing, is possible. Static, but not dynamic, conditions are supported, although this and the relevant routing role matching becomes supplementary coding for the full solution. Thus, WS-Routing can support simple dynamic orders, like those of "routing slip". However, the complex dynamic routes required by our examples above, cannot currently be supported.
Up: Patterns Previous: Multi-transmission interaction patterns
Site created and maintained by:
Alistair Barros, SAP, Brisbane Research Centre, alistair.barros at sap.com
Marlon Dumas, BPM Research Group, Queensland University of Technology, m.dumas at qut.edu.au
Arthur ter Hofstede, BPM Research Group, Queensland University of Technology, email@example.com
Part of a joint initiative by SAP and Queensland University of Technology, co-funded by Queensland State Government.