Thoughts on Enterprise Service Bus

Editorial architecture visual showing service interaction, data flow, contract boundaries, retries, and sync versus async paths

The bus, is definitely definitely a popular word now. If you want to show off, told them you build ‘the bus’.

What is it and its relationship to ESB toolkit, in my opinion, is totally not related. The messaging bus is nothing more than a design pattern concept. It does not mean you have to tie up with ESB toolkit to use it in any sense. In fact, in my opinion, ESB toolkit by Microsoft is a failed attempt. It is just too complicated to use.

image

Stolen from EAI website, the service bus, is nothing more, nothing less, but exactly a routing slip pattern implementation. Which in the core of Microsoft ESB toolkit, the itinerary is fulfilled in the clumsy visual studio itinerary designer.

In the recent project, we end up with similar concept with the ESB toolkit, rather, I put the itinerary designer somehow in the rules engine (inRule by the way, is much user friendly comparing to BizTalk BRE) This way, the business user can actually do something about the itinerary, i.e. design the itinerary step sequence themselves

I am not saying ESB toolkit is useless, its concept is good, I ‘borrowed’ quite a few technics from it. The way I see it, is a good reference for implementing a custom ESB solution, but as a commercial product as a deploy and go model I don’t see it is practical just use it as is.

Next step

Need this reviewed in a real system?

Use the article as a starting point, then bring the actual decision, constraints, and failure paths into an architecture review.

Join the discussion

Sign in to comment. Signed-in comments appear immediately.

Join the discussion