Use Case Description
The use case is transferring personal info to healthcare provider. A business process is invoked as a SOAP service which receives the necessary information in XML messages according to the service interface and in turn invokes two services: the Google’s Distance Matrix service which finds the healthcare provider and a wsdl interface exposed by the provider for receiving information.
Description of selected patterns
Here only a small subset of SOA patterns are implemented using Biztalk 2010 . For a meaningful comparison, patterns from the same category have been selected, namely business process messaging patterns.
Aggregator Pattern.The function of an Aggregator is to collect and store individual messages required by a business process until the complete set of related messages has been received. Then, the Aggregator creates a single message from the individual input messages. An Aggregator can be implemented in two variants, Sequential Convoy or Parallel Convoy.
In the Sequential Convoy the messages are received in a predefined ordered sequence. The first message initializes the correlation set while the other messages use it. A correlation set is data unique to a message or set of messages that can be used to tie together the messages that needs to be processed together by a particular process instance. The sequential convoy variant is applied when ordered delivery of messages is important. In the Parallel Convoy the arriving order for messages does not matter but the further processing can continue only when all messages are received. The message that arrives first initializes the correlation set and the rest will use it. The Parallel Convoy can be applied when ordered delivery of messages is not important.
Content Based Router examines the message content and routes the message onto a different channel based on the data contained in it. This pattern can applied when the message content contains destination information or the destination address is determined based on data item(s) carried by the message.
Message Translator is used to translate one data format into another. The Message Translator is the messaging equivalent of the Adapter pattern, which converts the interface of a component into another interface so it can be used in a different context. In the context of web services, message translation usually involves expensive XML processing. This pattern is often used, as business processes normally deal with different message formats that require extracting data from one and converting to another. For example, if an inbound message is not in XML format, it is converted to XML for processing inside the process.
Applying the Patterns
First, the two variants of the Aggregator pattern are implemented. The process obtained after applying the Sequential Convoy is shown in Fig.1 and the Parallel Convoy in Fig.2. The graphical notation depicts the biztalk orchestration, in and out ports for receiving inbound messages and sending outbound messages. Each port may have one or more operations, and each operation has a request and a response interface. The Fig1 process receives two messages sequentially on the respective interfaces, calls the Google Distance Matrix API (REST call)
Figure 1. Sequential Convoy
| 
Figure 2. Parallel Convoy
|
service to find the provider, aggregates the two messages into a single unified message and forwards it to the provider's web service interface. The process in Fig.2 differs from Fig.1 differs by the fact that the two inbound messages are received in parallel.
To improve the response time by avoiding calling the Google Distance Matrix service every time the process is invoked, two approaches were used. First, the Content Based Router as described Fig.3. The two inbound messages combined into one on the client side (avoiding Aggregation), so instead of having two receive interfaces, there is only one. The web service URL of the provider is included by the client in the inbound XML message. The process in this case does not need to call the Distance Matrix API, but instead retrieves the URL of the provider's service from the inbound message, configures the dynamic send port and routes the outbound message.
In the second approach, message is aggregated on the client side as before, but employs a caching mechanism now. In Fig.4 business process, when a requests arrives for the very first time, the Google Matrix API is called to find the provider and the result is cached in a local data structure.
 Figure 3. Content-based routing pattern |  Figure 4. Caching |
For future requests, the Distance Matrix API is not called and the cached result is used instead. The cache is based on a .Net collection.
References:
http://www.eaipatterns.com/
References:
http://www.eaipatterns.com/
