Enterprise Service Bus Considerations

An Enterprise service bus (ESB) is a messaging backbone used to
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
  

ESBs provide a standards-based way on increasing flexibility. Also, they tend to scale well. If built properly, they make integration easier because they enforce loose coupling. On the other hand, they introduce management overhead, they can increase latency, they can be difficult to implement, and they won't provide any benefit if the SOA layer underneath is poorly-built.

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.