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:
Microsoft ESB
BizTalk Server 2006 R2
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:
Microsoft ESBBizTalk Server 2006 R2
Comments
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.
vtd-xml