Over a number of years I have been considering, cajoling, driving, arguing and mostly thinking about BizTalk in a SOA world and Microsoft's messaging around SOA. A number of things have struck me:
1. Achieving a SOA based on BizTalk is not just about exposing various BizTalk applications as Services.
2. Services shouldn't be simply request/response
3. Messaging is at the core of SOA but which form? Command, Event or document?
4. If BizTalk is to play a significant role it is not just simply the Bus that connects Services
5. What really is 'loose-coupling' ?
So let's look as a real problem in a SOA world and think about a BizTalk solution. Consider a call centre for an insurance company. The call centre application in this case can be considered pretty much as a basic CRM. It's purpose is for matching the caller to their policy and recording information of some form against that person or creating a new policy for someone based on the info supplied.
In our SOA world for this example we can consider a number of services that need to be provided over and above the CRM functions. Let us assume that the CRM is at least fed with the main customer database as a norm. In considering Services it is sensible to consider a scenario the will support.
Scenario 1 - Policy hold wishes to change car details
In this scenario an existing customer wishes to change the car details having changed cars. In this case the customer has made the switch and needs to update the policy. The process may be along the following lines:
1. Get customer existing details - held in the CRM
2. Gather new details
3. Get new quote information
4. Relay info to customer
At this point the customer may say yes I'll go with that or want time to consider 'other offers' elsewhere. If they decide to commit there and then payment could be either Credit card or some form of finance agreement.
What is happening at the CRM is that we are initially creating a new case for this customer and then subsequently updating it.
The supporting services may be:
1. Policy Service - get quote
2. Credit Card Service - Do sale
3. Finance Service - Do sale
4. Policy Service - complete sale
So at this point is where our SOA thinking arrives, and strangely enough where we can get it all wrong! If we think Services are merely Request/Response wrappers for applications we can are missing the point. Consider the highly simplified following diagram
We have created two services for the CRM to use: A Policy Service and a Payment Service. The payment Service now has some logic in it to decide which type of finance is required. And of course we can front these with web services and if by magic we have our SOA. Well maybe, but I think not. For starters we have to make sure that the CRM can call these services - Ok with more BizTalk effort we could provide some CRM integration. But the big problem is we have only handled a fraction of the requirements from the CRM. How do we handle Policy cancellation request? Adding a person for a short time? Advising on speeding convictions? and many more 'cases' that need to be handled. At the moment we have a Request/Response solution what we need to consider is Events and Documents. The CRM needs to understand the workings of the other applications or services so we are probably missing the SOA point.
So lets think again, the user of the CRM can be considered as generating 'Case Events' in the form of 'Case Documents' what we really need is a generic case handler service that publishes specific case documents onto a bus where the application handlers can subscribe to there specific case type. This means we can construct business processes to support specific case types. In the next diagram we have introduced the case handler service. Now this service excepts and case events from the CRM. Processes the case document and generates more granular application specific documents and deposits or publishes them to our bus. A subscribing application event handler will then extract the document and process it based on its content calling the relevant application as required. The result of this will be a Case Update Event returned back to the CRM using the same mechanisms.
By developing our architecture this way we can effectively produce more complex applications. Consider: At the CRM when the customer decides to accept the quote and decides to pay by credit card the CRM could generate a 'complex' event including instructions to both the Policy application and finance application. In this case we could produce a 'sale' handler that wraps the two processes in a transaction - as long as the credit card payment is approved then complete the policy update - for instance. this would allow the 'service' to return to the CRM user for maybe re-application using a different credit card.
What is clear is leaving the world of Request/Response behind and focusing on Events and Documents gives us much greater advantages.
As a byline to this thinking have a look at this article.