Geeks With Blogs

News View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn
Michael Stephenson keeping your feet on premise while your heads in the cloud

I've been meaning to write a blog post for a while about how we implemented a scatter gather pattern at one of my clients. Ive recently been reading Richard and the gangs new book which discusses a very similar pattern but with a different design decision. Based on that I have decided to expand on the original planned post to talk about what we did and our decision process using the decision framework discussed in the book.

The aim here is to show that the "it depends" principle means that there is rarely a 100% right answer for everything and a solution that works best for one organisation may not be optimal for another.

Before getting into this, if you haven't already read the book it's on the below link:

https://www.packtpub.com/applied-architecture-patterns-on-the-microsoft-platform/book

Use Case

In this scenario we have a situation where we have a customer with internal applications that will use a service provided by another internal application to generate quotes. In the old style use of this process we have an application developed many years ago which makes web service call via COM Interop to a newer .net application which exposes a quote service.

There are many different varieties of quotes which can be obtained so the old application makes many calls for a given call centre user to get all of the quotes required by the customer on the end of the phone. This can result in 10-50 (or in exception cases there have been 150) synchronous request response calls made sequentially. It is not unusual for a user to wait a number of minutes from clicking the button to getting control of the application again due to the latency of these calls.

The primary aim is to improve performance.

Key Requirements

The key requirements were as follows:

  • We want to be able to significantly lower the latency of the end to end calls
  • We can only implement minimal change to the old style application
  • We can not make any significant changes to the .net application in the project timescale

Other Requirements

Based on some analysis we also found the additional requirements and considerations:

  • The customer has 2 applications which could be the source of quotes for different systems (but the 2nd quote source is not involved in this specific scenario)
  • The 2nd quote application is scheduled for longer term deprecation to be replaced by the .net application
  • There is no analysis or BI information available for the use of either service but in the longer term this would be desirable
  • We would like to be able to improve the security of the process longer term
  • The back-end .net application service is capable of supporting many concurrent users with low response times
  • The organisation would like to allow other applications to request quotes. These may be older style applications, .net applications or Java applications.
  • The backend quote service on the .net application has some interoperability challenges

        

Options

In the style used by Richard et al, I will describe some of the options we considered and some of the factors which relate to that option in our context and finally provide some comparison and justification to the decision we went with.

   

Option 1: BizTalk

In this option we would implement a brokered integration solution using BizTalk. We would allow the application to submit a batch of requests for quotes and then use the scatter gather pattern to break up the batch and make many concurrent requests to the back-end application. We would then gather up the responses and return them as a batch in a request response manner.

In this case BizTalk as an enterprise level hosting environment is able to use its ability to concurrently process many messages at once.

Solution Design Aspects

In BizTalk there are a number of ways you could implement the scatter gather pattern. In this case in order to get good performance we have chosen to use the In-Line pattern meaning we would use .net code within an orchestration to call the web service to get lower latency and we do not need the retry capabilities of a send port.

To implement the scatter gather we will use the asynchronous methods on a web service proxy and the delegate within the class will handle gathering the responses.

By doing the above technique we have made a trade off on normal BizTalk design but the trade off is encapsulated which is an important thing to try and do in these kind of situations.

So having addressed the key requirement of being able to improve the latency of the scenario we also have to consider what BizTalk offers for some of the longer term requirements and opportunities. Firstly BizTalk has introduced a layer of abstraction which means we now have an opportunity to look at plugging in the second quote service. Being able to do content based routing as part of this scenario we could introduce a migration strategy for applications currently using the older quote service to eventually use the newer one.

In terms of the front end of the service exposed by BizTalk well we now have some choices here. The old application was always planned to have some minimal changes anyway to batch up the request, but now the application developers have some choices around their preferred protocol for making the call. Traditionally this application has always used HTTP Post which they could revert back to, or they could continue to use COM Interop (which was something they had lots of issues with in the past). The receive location offered by BizTalk means that applications which started using the service could use different protocols and different message formats but with a small amount of work could easily participate in this integration scenario.

I think the key point around the design is that although the core requirement was fairly straightforward, by using BizTalk we have suddenly for free opened up a lot of possible options which the organisation could use to help with their longer term requirements.

Solution Delivery Aspects

In terms of delivery for BizTalk projects we have a very well defined delivery process which is relatively agile and has proven success. For our organisation this would just be another BizTalk deliverable and people would know what to do and what to expect.

Although there would be other teams involved in the creation of the end to end solution we have created ways of working that although have some issues still get the job done in delivering integrated solutions.

I feel that for this solution option the delivery process would be a key factor to success.

Solution Operations Aspects

Like delivery, our organisation has been supporting integration solutions developed on the BizTalk platform for a number of years. We have a reasonably powerful platform with capacity to add this solution without any scalability issues.

Our support teams know how to support these kind of solutions and how to manage them.

Organisational Aspects

While the BizTalk solution comfortably delivers on the core requirements of this use case, the platform upon which this solution is built would offer other future opportunities to get more out of this solution. Firstly we know there could be future requirements to have other applications use this service, or we may wish to expose this service externally to the organisation. The BizTalk adapter set offers an easy way to plug consumers with different capabilities into this service. We would also be able to use other features like BAM if we wanted to develop a better understanding of the usage and success of this service.

BizTalk also has a scalable platform which could be grown as potential usage increased.

Option 2: WF & App Fabric

In this option we would develop a .net 4.0 workflow which would implement a scatter gather pattern. We would then host this in AppFabric/IIS7.

Solution Design Aspects

This option offers similar design considerations to the BizTalk one. One of the key advantages this option has is the ability to remove persistence if it is not required.

AppFabric is also considered to be a lightweight hosting platform than BizTalk which could be appealing to some people.

Solution Delivery Aspects

For the organisation there is currently no story around the delivery of WF and AppFabric solutions. For the areas we do have delivery capability for we usually have well defined process including many of the common good practices.

To be able to deliver on this option we would also need to ensure we had a solid delivery capability including a development and testing environments suitable equipped to handle this. This would introduce quite a bit of additional work

Solution Operations Aspects

The organisation currently has no capability to host, deploy or manage WF solutions or solutions on AppFabric. This is not to say that these could not be introduced. This would involve a fairly significant training requirement to get the appropriate skills to ensure the organisation can live with this solution.

In terms of capability the platform of AppFabric and WF offers a lot of features to help deployment and management and this is certainly something the organisation should be looking at longer term.

Organisational Aspects

The organisational aspects of this option revolve around two key areas. Firstly, what does WF and AppFabric as a platform offer elsewhere. Secondly what future expansion to the use of this quotes service are offered.

On the first point then AppFabric is certainly something that could help the organisations solution development projects.

On the second point this option is certainly scalable to support expansion to the use of the service, but its debatable how easy it is to open up the service to applications who can not easily talk WCF, and you are likely to want to put a broker in front of the workflow to handle any differences between either protocol/message format or security requirements other consumers may have

Option 3: Façade Web Service

In this option we would host a class very similar to the scatter gather class we would have used with the BizTalk implementation but instead of hosting it in an orchestration we would host it behind a custom web service. The client would call the web service which would broker the integration capability and use the asynchronous methods on the web service proxy to call the back end quote service the responses would then be batched up and returned to the client.

Solution Design Aspects

From a design perspective this solution encapsulates the scatter gather implementation like the others but you are sacrificing a number of management, monitoring and other capabilities which you would not get with AppFabric and BizTalk. If you host the service in IIS7 with AppFaric you could get some of the WCF monitoring capabilities.

One of the key factors here is the restriction of the access protocol to the brokered service. Previously I mentioned that we would want other applications to be able to use this service with a combination of different capabilities. With this solution it would be difficult to extend the service to support other protocols and security approaches without implementing a multiple end point pattern and a reasonable amount of custom development.

Solution Delivery Aspects

From a delivery aspect this solution is pretty straight-forward. It uses things we already have such as IIS, .net, WCF or ASMX web services. The skillset to develop this would be C# and we had lots of C# development capability. From a delivery aspect this is probably the least risk approach in terms of affect on project timescales and cost.

Solution Operations Aspects

The deployment side of this solution is easy, but there would be challenges with the management and monitoring side of things because there would be no obvious tooling or management utilities to give you visual ways to interact with the service. You would get the standard IIS console . This organisation has plans to implement Windows 2008 but not in the timescales of this project so we would only have IIS6 capabilities for management.

Organisational Aspects

This solution offers little in terms of organisational benefit outside of the functional requirements. If the project was used as a driver to also implement IIS7 and AppFabric there would be longer term advantages, but on the current technology stack there are few organisational benefits.

Option 4: Non Brokered Client Side Proxy

In this option we would move the scatter gather component to be wrapped inside of a more complex client side proxy. The code would be similar for the consuming application in that it submits a batch and gets a batch in response but internally in the proxy it would do the scatter gather.

Solution Design Aspects

This approach removes the brokering of the integration solution which is perceived as a performance benefit because of the removal of a "hop" from the call stack, but what is not as obvious is that it would actually perform worse because by default a client application would only make 2 concurrent connections to the service so the web service calls would be throttled. It is not really a good idea to go opening up lots of concurrent connections from clients all over the organisation to the services as this would seemingly be in an uncontrolled manner. In a brokered solution the server side implementation of the scatter gather would be to take advantage of controlled server side opening of many connections to the same server and you could also scale the middle-tier as required to get the throughput requirements.

In this approach the solution would still encapsulate the scatter gather implementation but by moving it to the client machine you would have a different operating system (probably) running the code and you have the two systems more closely coupled than in other options.

Solution Delivery Aspects

This options delivery really depends on the capabilities of the client consuming the service. For one client (a .net application) it would be easy, but for others you would have more work and risk due to the combination of interoperability issues which a java client may have and also the Com Interop challenges which one of our other applications may have to experience to use this component.

Solution Operations Aspects

Because this is client side almost all of you capability to manage and monitor this solution is gone. Hopefully some kind of discovery option would be in place to help mitigate changes to the service location. This would also require a deployment to all desktops of a new component.

Organisational Aspects

Again this option offers few organisational benefits outside of the functional requirements

Solution Summary

We applied a rating (out of 10) to each solution for the different aspects and came up with the below figures.

  

Design

Delivery

Operations

Organisation

BizTalk

8

6

8

8

WF & AppFabric

7

2

6

7

Custom Web Service Broker

5

8

4

3

Enhanced Client-side Proxy

5

6

3

1

To help visualise the comparison of the options I have produced the below graph.

   

   

BizTalk

In the BizTalk solution all areas looked pretty good. Delivery was not given quite as high a score because in general successful BizTalk development is quite challenging even for smaller projects, but we had well defined processes which would make this work.

WF & AppFabric

On a number of aspects this was quite an appealing solution. The key place where it would be challenging for our organisation was around the delivery aspect. We had little in the way of capability to deliver a WF solution on AppFabric in this organisation.

In terms of the core requirements this solution was a perfect fit and could be considered a lighter-weight solution than BizTalk, however the WF option isn't quite as appealing as the BizTalk option in terms of ability to cover some of the potential future directions for this solution.

Custom Web Service Broker

The delivery aspect of this solution was very straight-forward. It can be made to deliver all of the main requirements and we have the capability to develop this solution in quite a short timescale. Where this solution is let down is on the design and particularly operations aspects. In terms of operations this there is no story for monitoring and little for management. Any management features would need to be build from scratch. If we had AppFabric available we could have viewed this as a custom coded alternative to the WF solution and would have for free for the IIS7 monitoring features for WCF but we didn't have that either and bringing this into play would have had a sizable effect on the delivery requirements.

Enhanced Client-Side Proxy

This solution is very similar to my thoughts on the custom web service broker. Easy to deliver but no monitoring and little strategic value. This design also breaks some of the key principles of abstraction and encapsulation.

Summary

In this article I have attempted to reinforce the point Richard was making in the book about "it depends". We have two organisations with sort of similar requirements but we end up with a very different solution.

In the book the example covers an organisation with what sounds a very vanilla .net application developer skillset. For that organisation the WF and AppFabric choice was perfect because they could introduce some new skills and get some productivity savings along with some platform level features which would help the operations of the solution.

Our situation was different in that we already had a well established integration capability. From most aspects the BizTalk and WF/AppFabric decision was very close with the big exception that we didn't have an existing delivery capability for WF/AppFabric so in the end the choice was fairly straightforward.

In the end the decision for both organisations really came down to a choice of what technology was the lower risk approach for them to deliver and manage the solutions.

As a side note I wonder which decision we would have made if our organisation did have AppFabric. I guess in some organisations it can come down to the delivery team and where in the organisation they are. This is a good argument for an central integration centre of excellence to help your organisation make the most of its assets and to have some governance and consistency.

In a follow up post I will probably do a sample of how we implemented this pattern.

   

   

Posted on Sunday, November 14, 2010 1:20 PM BizTalk | Back to top


Comments on this post: Scatter Gather Design Decision

# re: Scatter Gather Design Decision
Requesting Gravatar...
This is an excellent overview! Thank you for spending the time documenting your thoughts.
Left by Philippe on Dec 22, 2010 5:33 PM

# re: Scatter Gather Design Decision
Requesting Gravatar...
Have you considered how to implement on Azure? I am trying to implement scatter gather using worker roles and queues in Azure and I have been looking for some other .net implementations to review. Your post has been quite useful, I have been thinking something along the line of http://www.openspaces.org/download/attachments/4784607/distributed-gather.pdf?version=1 would be good for Azure.
Left by Nikolai on Mar 05, 2011 2:19 AM

# re: Scatter Gather Design Decision
Requesting Gravatar...
nice info Virgo love Horoscope thansk
Left by ruby singh on Apr 21, 2017 7:10 PM

Your comment:
 (will show your gravatar)


Copyright © Michael Stephenson | Powered by: GeeksWithBlogs.net