Monday, December 17, 2007

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.

3 comments:

  1. I don't know - I hear about federated esbs lots, but as if soa isn't abstracted enough?

    ReplyDelete
  2. You missed some considerations - check out Loraine Lawson's excellent post on ESBs:Defining ESB: Why It Matters to Your SOA

    ReplyDelete
  3. A few more points:

    Commercial SOA infrastructure products that contain ESB technology are optimized for
    uniform application design scenarios or for integration scenarios, but no currently
    available product does both well.

    • Vendors that get substantial revenue from application servers generally produce SOA
    infrastructure products that optimize uniform application design scenarios, while vendors
    that get little or no revenue from application servers generally offer products that
    optimize for integration scenarios.

    • Most SOA scenarios blend uniform application design and integration, but architects
    must determine which requirement dominates their environment to decide which type of
    SOA infrastructure product to use.

    ReplyDelete