transport data as messages. The concept isn't vendor-specific and it's
not an alternative to SOA; It's just an architectural integration
pattern that serves as an entry point for SOA connectivity. It is abstracted from underlying protocols and asynchronously brokers messages between applications.
In the Microsoft world, ESBs are typically built using the Windows Communication Foundation (WCF) with BizTalk server. I personally think this is an interesting solution based on some good
experiences with the WCF - It brings Web Services, .NET Remoting, Distributed Transactions, and Message Queues into one model, so it's a great candidate to use for this type of communication backbone.
On the J2EE side, BEA, IBM, Oracle, and several Open Source solutions are usually used to create ESBs.
ESBs can be generally be broken down into 5 components:
- SOA Hardware
- Service registry
- Service orchestration
- Service monitoring
- Universal transformation
The decision on using an ESB for an organization is a big one; The trick is weighing the costs and benefits to determine whether the flexibility they provide is worth the (big) implementation costs.