Sunday, June 08, 2008

Microsoft ESB Guidance

Since November 2007 Microsoft ESB Guidance 1.0 is out there. Recently a customer asked what ESB actually is and if it runs in a production environment. I am talking here about Microsoft ESB implementation. During DevDays 2008 in Holland Christian Weyer in his talk about BizTalk Services pointed out that ESB is a super pattern, which can be implemented with a variety of technologies. Again I hear somebody saying it is a pattern or architectural style and not a product. I posted a question on linkedin asking people in and outside my network, if they think ESB is a well known (super)pattern and when to apply.

And I got some answers that it is a way to bring all of the technologies within a company, entity, or enterprise together. Depending on the magnitude of what that could encompass, it *could* mean a simple product that "maps" everything together. Usually, though, it is a way -- and therefore, an architectural pattern as you stated -- to bring all of the different software’s, databases, and knowledge within an entity together to allow mutual communication (Mike Borner).

Or I agree with visualizing ESB as an architectural pattern. The implementation of the pattern (the BUS concept) can be found in middleware off the shelf products. ESB by itself doesn't provide any business value as explained very nicely by Bobby Woolf (Link below), it is a capabaility you must have to implement an SOA strategy. Especially when services you are enablinng are over many disparate legacy systems (Santhosh Soudamini).

The most important concept is that an ESB is a architecture pattern (mostly related with SOA technologies) and not a tool. In that aspect I totally agree with you (and Christian Weyer... I think). An ESB establish a messaging bus that provides elements like: thrust messaging, support of all kind of communication technologies, QoS, or/and message rutting. And one of the main characteristics is the central administration. This pattern (and the products that implements it) offers to enterprise application an integration support. So, the scenario where the patterns apply is an enterprise or business application where the interoperation of all kind of systems (ie. new applications technologies and legacy systems) and its integration is the key aspect (Alvarro Gareppe).

And I got more answers more less like the ones above stating the same arguments that ESB is a (super)pattern and nobody claims that is a product or technology dependent on one software vendor or technology. And if one wants an ESB implemented than Microsoft ESB Guidance can provide that, bringing in technologies from Microsoft like BizTalk Server 2006 R2 and .NET. And professionals in the field (not me) have implemented an ESB.

On linkedin I also asked who had experience implementing an ESB with Microsoft and runs one in production. I got an answer from Jonathan Gurevich:
I've implemented the ESB Guidance and have not come across any specific performance issues. More important, in my opinion, is to look at what the ESB Guidance actually is (and, maybe even more important, what it isn't):

-It's not a product, meaning no official support from Microsoft. It's open source so you'll have to rely on the community (which does of course consist of several MS employees as well).

-It's not an ESB in a box.

And an answer from Micheal Kleinberg saying:
We do in fact run Microsoft ESB via BizTalk 2006 in a production environment. It performs well in a mildly high transaction environment, but we've limited it's scope of use to it's strengths of Orchestration, providing file I/O transactions and some minor ETL. As we move more towards a SOA architecture we're considering more robust solutions that can provide the necessary transaction processing load and performance, governance, security and management for a site that serves millions of page views per hour.

As you can read Microsoft ESB Guidance has been adopted (I do not know apart from these two people, how much project are going on in the world with ESB Guidance, and so on). It performs and runs in production. It is not a product, not a toolset and ESB pattern can be implemented with Microsoft technology and products. So more in depth information can be found at Microsoft itself or Wrox PDF (see previous post).

Technorati:

2 comments:

Nilay Parikh said...

Recently I come across Microsoft ESB Guidance (on codeplex) and in my recent company people have implemented ESB, I don't find any issues with Performance. But yes it is constricting developer or designer in many ways with flexibility compare to only BizTalk solution and with ESB - BizTalk solution. Microsoft ESB Guidance implementation don't allow you to administrate your messages inside management studio, for every fault routing we need to relay on management portal (ESB Guidance) because, to avoid duplicate messages into our solution we must to terminate the message inside BizTalk, every fault message must re-ramped in ESB through SOAP or WCF on-ramp services (you can create your own on-ramp services but I am not much confident over it). Also not clear with some EDI messages with HIPPA, etc.. which requires ordering implementation, and I don't have good experience with re-sequencing implementation and it's exception handling within ESB Guidelines...

I think we should make clear break even point when this could tern into profitable solution, it's all about requirement specific. I believe so..

Thanks,
Nilay.

Anonymous said...

you may want to look at vtd-xml, the latest and most advanced xml processing api that is a must have for high perfomrance ESB

vtd-xml