Microsoft's Enterprise Service Bus (ESB) Strategy - Part 3/4
About: This post is the third in a series of four about Microsoft’s strategy for Enterprise Service Bus. This post discusses the various tangible manifestations that an ESB can take; the fourth and final part will discuss Microsoft offerings in this area
Greetings,
Let me start by thanking all the people who have expressed their views on the first two postings by sending emails and postings on their blogs. The number of emails I have received about the ESB postings have been overwhelming, one of my favorite ones was a criticism of my position by Udi Dahan who stated that the word ‘Bus’ and ‘Broker’ are not synonyms and that “SOA is not about hooking together poorly design, hastily shipped legacy systems. Each service is responsible for its own communications with other services. If it needs to "transform" messages, whatever that means, it should do it by itself”. I do agree with the majority of what Udi has written (including the differences he points between Bus and Broker), I respectfully disagree with his position on SOA as I think that in addition to a number of other advantages and building the ‘new’ services right, SOA can enable an organization to encapsulate its legacy systems, that is an important part of the reality in the field and typically is a critical component of adoption of SOA in an organization. Microsoft has technologies like WCF that greatly helps an organization in realizing SOA in the manner described by Udi but we also need to take a realistic perspective in terms of market needs and current state.
Getting back to what ESB can mean to you, when thinking about the ESB the first thing you should try to do is determine the capabilities that are relevant to your organization, ask questions like ‘Why do I want an ESB’ and ‘How does it help improve our offering as an IT group to our internal and external customers”?. If you cannot determine the how having an ‘ESB’ would make your offerings faster, better and/or cheaper then I suggest that you take a step back and reassess your needs.
Depending on what you want to get out of an ESB, it can take various shapes and forms, please note that they are not necessarily mutually exclusive but different ways of thinking about an ESB, you may end up with an implementation that is a combination of these ideas
- ESB as a pattern
ESB can be thought-of as an architectural integration pattern, irrespective of which technologies you choose to implement it, you can think of ESB as a middle tier concept that connects the various end points in a bus topology.
- ESB in a box
Personally, I do not think that it is possible to have an ESB-in-a-box solution that fulfils your needs. Whether it is Microsoft or Sonic or Tibco, it is unlikely that the ESB-in-a-box would resolve all the issues that you are attempting to resolve through this mechanism. However, in most of the cases the ESB-in-a-box, when chosen based on your organizational needs, can provide value and through customization and extensions you can reach the desired outcome. This is especially true if one of your main needs around ESB is to externalize translations, transformations and business logic from individual systems and for having centralized interaction and connection mechanisms between systems implemented in different technologies
- Messaging software + Web Services
In some cases the outcome you desire can be achieved through building web services on top of your messaging layer, i.e. you may not need to buy a COTS ESB solution.
- Legacy integration
If your primary purpose of having an ESB is to encapsulate and expose your legacy system and make them part of the new architecture in your organization, you can achieve that goal through specialized software designed for exposing/integrating particular types of legacy system (e.g. exposing mainframe assets through Host Integration Server).
In the fourth and final post, I will be discussing Microsoft’s offerings in the area of ESB and how you can use these technologies and best practices to implement an ESB in your organization.
Best regards,
Mohammad
