Tuesday, July 11, 2006 4:42 PM
In this post I will be taking a high level look at what a possible SOA implementation architecture scenario and what it might look like giving an indication of what technologies are involved.
This example scenario is a SOA implementation for call-centres using Microsoft Technologies, some you may have heard of, and others that are sadly as yet unsung.
A few things to note,
I haven’t come across a medium to large organisation that doesn’t use Citrix for the UI deployment so this is why I have included it in the implementation example. Other products and options are available.
Down the right hand side I’ve placed the layers from the logical model so you can understand how it maps to the implementation architecture scenario.
I’ve included a mainframe. It seems the most common reason for building a SOA is to reduce the influence of the mainframe, to reduce cost and development time.
(In a future post I will be asking the question about hosting an ESB on the mainframe)
In the logical model you will notice that the Business process logic layer is split into two parts, the synonymous service and the asynchronous service.
The asynchronous service is Biztalk. Biztalk is an idea platform for message orchestration, composition, guaranteed delivery and workflow. Biztalk can also be used for long running transactions which IMHO is a very under-rated feature. Biztalk can handle 140 straight through transitions a second. Impressive but the target number of transactions a second for this architecture is 2000 per second which is not unreasonable in a call-centre scenario. The Customer Care Framework offers a lightweight solution and primarily based at synchronous transactions but does not offer many of the same features as Biztalk. So, a simple selection criteria can be created to decide on which route to take.
A quick note on the future of Biztalk: Some of Biztalk’s recognised features are breaking out of the product and becoming features in their own right and these features are, workflow which will now be in the Workflow Foundation and the communication adapters will form part of the Window Communication Framework. Both of these new products are aimed at the Vista timeframe and should be in-place ready for the next version of Biztalk.
The adapter servers are in recognition the communication adapters are moving out of Biztalk providing a layer of abstraction between your data and the business logic, which Biztalk did up to now in-product. Having the adstraction means that you can scale your Entity services without reliance on the rest of Biztalk. Also allows you to pick another product(s) in the future or makes it less painful to upgrade because of the service façade between the two layers.
The SQL server cluster is used for Biztalk message box and as a semi-permanent for long running transactions. To improve performance and reduce the number of hopes backwards and forwards from the data transport and the existing systems the SQL server here can be used as a cache for frequently used reference data. Creating this cache is an article in itself as are many other topics this article would raise which gives me plenty of inspiration for future posts.
I had spoken about unsung Microsoft technologies; one of them is the Customer Care Framework or CCF. I would actually like to dedicate a future post on this topic so for fear of stealing my own thunder I will give you a brief overview.
CCF is a modular XML Web Services architecture for rapid development and deployment and is aimed at the call centre environment. It includes many pre-packaged feature built for speeding up the efficiency and robustness of data delivery and improving the UI experience. By this I mean multiple-channel offerings such as interactive voice response/speech, instant messaging (IM)/chat, Web, kiosk, e-mail, and retail are pre-canned .Net libraries ready to go, taking a lot of the leg work out of creating these services from scratch.