Saturday, September 16, 2006

When Should You Use an ESB?

With all the hype around ESBs, a lot of people think that you need an ESB to build an SOA. That isn't always the case. I'm getting tired of seeing boilerplate SOA architecture diagrams with an ESB in the center. As with any other product, you should only use it if you require the functionality provided by it. Though there's no firm definition of what exactly is an ESB, you often see a core set of functionality that's provided by all ESB products. I talk about them in this posting. They are:
  • Protocol Adaptors
  • Data Transformation
  • Routing
  • Orchestration
  • Synchronous/Asynchronous Messaging
  • Endpoint virtualization

So when might you need such functionality? For example, if you're working in an environment with legacy systems and not all of them can support SOAP/HTTP. Or perhaps if you're building some type of automated workflow system or BPM. Or some event-driven system that requires asynchronous messaging and routing. If you just required some data transformation or endpoint virtualization I probably would not go with an ESB--it would be a bit overkill. Anyways, the point is look at your requirements and your environmental constraints first to see if you need the functionality that's provided by an ESB before you throw an ESB into your architecture.

,

No comments: