BizTalk Anti Pattern: The plug and play SOA

Michael Stephenson keeping your feet on premise while your heads in the cloud

<< BizTalk Patterns & Anti Patterns | Home | BizTalk Anti Pattern: More logging than a lumberjack >>

Name:

The Plug and Play SOA

Description:

I have seen occasions where BizTalk has been stuck between two systems simply because it is perceived to decouple them. One case was where System A called an API on System B which was exposed as a set of web services. All BizTalk was planned to do was accept the web service call from System A and forward it to System B. Some of the design thoughts included:

Thought	Other consideration
"We can replace System B and System A is not affected"	Well yes but the other thing is that this is only true if the contract is the same, and the likely hood of System B providing the exact same interface to its admin API is about 0% so there would always be some change if not more likely a lot. Because BizTalk is in the middle you now need to change two things rather than one.
"BizTalk removes the dependency of System A on System B"	Because the communication is a web service call they are not tightly coupled anyway. Sticking BizTalk in the middle
It becomes an SOA	No it doesn’t, its just 2 web service calls and a bunch of additional overhead rather than 1 web service call
Another part of the communication between the to systems used BizTalk so we should here.	The other bit was a valid use of BizTalk where it used asynchronous processes and BizTalk provided features which helped this work.

The planned implementation for this is to generate a schema in BizTalk via a web reference. And then expose this straight out through the receive port. Any requests were simply routed and there were just no real benefits in using BizTalk.

Symptoms:

There are processes in BizTalk which don’t really use any BizTalk features
This usually only applies to synchronous processes within BizTalk

Pain:

Cost - It costs more to develop the solution because you end up doing a bunch of BizTalk development that you don’t need to.
Performance - The performance of the specific processes is affected because BizTalk adds additional overhead to the request
Time - It takes longer to develop the solution because you have a whole bunch of unrequired code which needs to now go through phases like testing, QA, etc etc..

Cure:

I think prevention rather than cure is the most likely solution. When you are designing solutions that will use BizTalk you should really validate that it is appropriate to use BizTalk for your situation. In the instance discussed above it could also be cured by stopping the development of the un required BizTalk artefacts. To System A it is then just a case of re-pointing the endpoint to its web service calls.

Comments:

Posted on Monday, December 18, 2006 5:20 PM BizTalk | Back to top

Comments on this post: BizTalk Anti Pattern: The plug and play SOA