Routing patterns

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).

Examples.

• Referral to single party: As part of a purchase order processing, a supplier sends a shipment request to a transport service. Subsequently, the transport service reports shipment status (e.g. as per RosettaNet's PIP 3B1) directly to the customer who then correlates these with its initial purchase order.
• Referral to multiple parties: After processing its inventory re-stocking for a week, a supermarket's warehouse contacts a supplier for order and dispatch of goods, notifying it of the different transport services available (different services specialize in transport of different sorts of goods). The supplier directly interacts with these transport services regarding the scheduled dispatch times (arranged by the supermarket). Faults related to order fulfillment are sent by the supplier to the warehouse, while faults related to delivery are sent by the corresponding transport services to the warehouse.

Issues/design choices.

• Party B may or may not have prior knowledge of the identity of the other parties. The information transferred from A to B must therefore allow B to fully identify and to interact with the other parties.
• The referred parties (P1, ..., Pn) and the party nominated to process faults (if different from A) may receive messages related to interactions that they did not initiate. These messages should then be related to internal processes/activities at these parties. Sometimes, messages received through referral trigger new process instances, while other times, they will be routed to an activity within an already running process instance. The data transferred between the parties must allow the referred parties to route the message to the correct internal process/activity.

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.

Related pattern.

• Channel mobility. Channel mobility in pi-Calculus [Milner 1999] refers to the ability for a process X to pass a channel name to another process Y. Passing channel names along with requests, and associating this channel name with "action identifiers" (like the "reply-to" field in WS-Addressing) provides a means of realizing the "request with referral pattern". In fact, this is the way the pattern is captured in BPEL, where channels names are coded as endpoint references and correlation data.

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).

Example.

• Some supportive work of managing regulatory provisions outsourced by government agencies to external agencies fits this pattern. Party A is a client seeking some outcome pending regulation, e.g. obtaining particular land tenure. Party B is the government authority concerned with the regulation. e.g. lands department. Parties P1, ..., Pn are outsourced service providers from the government authority's regulation process, e.g. brokers who validate applications and external land management experts who can provide independent audit of applications. The government authority stipulates that interactions between the client and outsourced service providers associated with key points of processing, such as the start and end of activities, and key reports, be sent to it.

Issues/design choices.

• The delegated parties (P1, ..., Pn) may or may not have prior knowledge of the identity of the request originator, party A. The information transferred from party B to the delegated parties must therefore allow these to fully identify and interact with A.
• A mechanism is needed to express party B's "view" of interactions between party A and the delegated parties. This may include all interactions or specific ones deemed to be of interest as indicated by the content of the messages exchanges.
• Party B could apply referrals for monitoring interactions or faults to other parties, however this issue is orthogonal to this pattern (and has been covered in request with referral, pattern 11).
• The view will be defined during design time, but could be modified at run-time (party B may adjust what it needs to see depending on progress of activities).
• Party B could apply referrals for monitoring interactions or faults to other parties, however this issue is orthogonal to this pattern (and has been covered in request with referral, pattern 11).

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.

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".

Synonyms. Routing slip [Kumar & Zhao 2002], [Hohpe & Woolf 2003]; Content-based router [Chaterjee 2004].

Example.

• Flexible order fulfillment. After processing an order, the sales department sends a request to the finance department to process the invoicing and payment receipt for the order. This request contains a reference to the customer's procurement service and possibly also to a shipping service nominated by the customer. After arranging invoicing and payment by interacting directly with the customer, the finance service forwards the order to the warehouse service. If the order is marked "for pick-up", the warehouse eventually sends a notification of availability for pick-up to the customer's procurement service. Otherwise, the warehouse issues a request to a shipping service which may be either the company's default shipping service, or the one originally nominated by the customer. The shipping service eventually sends a shipping notification directly to the customer.
• Proposal reviews. A project proposal initiated by a project coordinator is required to be passed through its work-package coordinators in any order, one at a time. For each route, all coordinators get copies of the document, however only one, i.e. the first expressing interest, is allowed to do the update. A coordinator updates the document and makes it available for the next coordinators' "read only" copy, out of which one gets "write" access. After an update, a problem may be flagged which requires the proposal to be routed back to the project coordinator. This over-rides the next step of the routing, and a modification of the routing may be issued by the project coordinator.
• Legal case preparation. A legal case preparation service is utilized by law courts to reduce the number of hearing re-schedules. This is a costly problem for the courts and defers justice for litigants due to insufficient information to embark on hearings, decreed by judges typically within the first moments of a hearing. As part of improved preparation, the clerk of the court examines a scheduled hearing, obtains all relevant documents into a formal draft, and determines the relevant legal or administrative actors required to provide examine the draft for verification and additional input of the draft. The clerk determines the first set of actors (defense and prosecution lawyers, and courts jurisdictionally related to the case) to review the draft. After these, expert opinion is canvassed based on issues raised in the investigation, e.g. different departmental solicitors in different categories of expertise.

Issues/design choices.

• The set of parties through which the request should circulate might not be known in advance. Moreover, these parties may not know each other at design/build time.
• The specification of ordering should support service/role late binding flexibility, parallelism and inter-leaved parallel routing, synchronization points between parallel steps, and dynamic conditions.
• A way of providing relevant fragments of documents to different parties needs to be supported.
• A way of controlling read-only and write access of documents provided to parties needs to be supported as does a way for readers to get the "write" token.
• The update of routing should be subject to role access permissions, e.g. only a project coordinator is allowed to re-route a proposal review through work-package leaders.

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.