Asynchronous integration for service oriented integration using Biztalk Server 2006

Three different strategies among asynchronous integration using biztalk server 2006.

1. Client-side asynchrony
2. Asynchronous integration with polling
3. Asynchronous integration with callback

Although option 1 may be the easiest to construct, it is essentially a synchronous SOAP interaction that just appears to be asynchronous to the client code because the connection between the client and the service remains active throughout the whole interaction. Option 1 is therefore not a good choice.

The difference between option 2 and 3 is more about where you want to hold the state. Option 2 holds the state on server-side, in this case Biztalk Server. Option 3 holds the state on the web server using the global cache. Both servers are multithreaded and quite efficient at keeping state for many concurrent requests. Both options are good choice and is more about where you have your skills and limitations and which area you're focusing on.

Option 2 requires a little extra work on the BizTalk Server to ensure proper correlation and to allow the concurrent servicing of multiple requests. Option 3 requires additional coding effort in the Web server to maintain and to clear the global cache.

I will highlight option 2 in more detail and discuss a few aspects you have to take care of.

1. First the client request with a customer id and server responds with a unique correlation id. An import detail here is to initialize the correlation set on the Send shape so the server knows which client should be correlated to the future poll request. Furthermore the process makes asynchronous requests to host systems. (The parallell branch is not true asynchronous, see "Parallel shape behaviour in BizTalk 2004 and >2006" of Yossi Dahan. A better choice for true asynchronues design is using self correlated ports and Start orchestration). The responses from the host systems aggregates into one message and is ready to be sent out. I'm using atomic scope to ensure transactional consistentency when adding the responses to the list.
   
2. The client polls the server with the actual correlation id. The request shape follows the initialized correlation set to correlate the correct instance. If the service has completed its work the server responds with the result otherwise it responds with an empty message. If not a correct correlation id is sent in the server responds with a soap exception. The left branch uses infinite looping to ensure listening for client polling requests. One important thing to mention is that you have to set the orchestration to long running and a corresponding timeout(in my case 60 seconds), otherwise you could increase the actual instances and bloating the server resources.