Michael Stephenson

keeping your feet on premise while your heads in the cloud

posts - 257, comments - 277, trackbacks - 11

My Links

News

Twitter

michael_stephen @LizzieSheLives 2 more at b@1 if you guys get here before closing about 21 hours ago

michael_stephen Tick tick... Ring ring... Is that mojito time? about 23 hours ago

michael_stephen @pluralsight id love a feature in the ipad app to have a list of my own where i can add courses i want to do in order. Like a training plan about 1 day ago

michael_stephen @BizTalk360 nicely put on the comparison! about 1 day ago

michael_stephen @wearsy i agree about 1 day ago

michael_stephen Needs a good night out next week! about 1 day ago

michael_stephen taking AJ to see star wars followed by wagamammas!!!! about 2 days ago

michael_stephen @neilwa30 thanks mate about 2 days ago

michael_stephen @SamVanhoutte what about mechano? about 2 days ago

michael_stephen @SamVanhoutte bit like training the dog to fetch the newspaper but possibly cheaper about 2 days ago

Post Categories

Image Galleries

BizTalk

Mates

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

BizTalk Anti Pattern: The plug and play SOA

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:

Share This Post:

Print | posted on Monday, December 18, 2006 5:20 PM | Filed Under [ BizTalk ]

Feedback

# re: BizTalk Anti Pattern: The plug and play SOA

I see this a lot it, usually when Architects decide to use an ESB pattern and route all point to point Web Service calls through BizTalk. Bad idea it's expensive and it won't perform as well as developing a proper SOA architecture in WCF or other WS framework. I think it's best to treat BizTalk as just another application in your Enterprise SOA architecture not the all encompassing layer everything has to pass through.

I have also seen BizTalk used a lot to perform ETL logic moving data between databases which should really be done in SSIS or another ETL.

Like the anti-patterns.
Rob

1/10/2007 9:17 PM | Rob A