I d suggest To ESB or not to ESB to start with, written by the creator of Mule.

ESB s are a good way to implement Enterprise Integration Patterns.

Kinds of problems that an ESB helps to solve

• You have a number of protocols you d like to normalize to a single protocol (e.g. FTP, email, SOAP, XMPP, etc. to a messaging system) e.g. ActiveMQ. This lets you decouple the implementation of services from the protocol.
• You want a consistent way to hook services into this architecture so that they can listen for messages, process messages and generate messages (Message Endpoints, Channel Adapters etc.).
• You may want a managed container to deploy these various components into (e.g. ServiceMix, Mule)
• You may want a number of prebuilt components and adapters into various protocols (e.g. ServiceMix, Mule and Camel have a lot of pre-built components).
• You may require long running workflows. Business Process Management is often something that is provided alongside an ESB (Apache ODE plugs into a number of Open Source ESBs).

Alternatives to an ESB

The alternatives really depend on the problem that you re trying to solve.

• To provide distributed services, people often use application servers exposing services via some point to point RPC protocol (like EJBs over RMI or Web Services over HTTP). So, rather than putting a message onto a bus , a client directly calls a server.
• To respond to specific protocols, you could just build a client that responds to that protocol for example writing an application that listens for emails using JavaMail or one that listens to XMPP using Smack. If your problem is constrained to one or two protocols it may not be worth bringing in a full ESB.

What you need to do as a developer to build ESB-compatible systems

This will depend on the ESB you select, although given that most of the good ones are designed to call out into all sorts of protocols as well as host POJOs, there isn t much you should need to do build ESB compatible systems. It is worth trying to make your code asynchronous.

For examples, Apache Camel probably has the most succinct configuration, here s a tutorial.

Three key advantages:

• A bus provides a way for end points to connect to each other without having to directly talk to each other. It simplifies the communications for the end points as they only have to conform to a standard communication interface, the bus. (This is with any technical bus, not just ESBs)
• An ESB provides a single place to get some key end point metrics: frequency, availability, and performance.
• An ESB tends to provide more than one communication interface. However, a developer only needs to choose the easiest one to get and receive the data from the bus.

However, make sure those will provide business value for your situation. Having an ESB is adding yet another complexity to your enterprise. Ideally you shouldn t choose this based on a few applications, but the entire organization. There should be only one production ESB cluster for the organization.

Alternatives:

• Just connect things to each other directly especially if the communication protocols are the same. This is good for simple application clusters and does not require too much thinking. However, as your number of applications grow, maintaining the interconnections becomes difficult.
• Another alternative is an MQ implementation. This will provide you with a way of pushing data around without having complex interconnections, but then you are forced to use only one communication channel. Fortunately for Java, they have the JMS standard.

Practicality:

I have stated the possible alternatives. They may seem lousy at first, but it is not to say you cannot start that way. I personally write things to talk to the remote directly without going through an ESB to make sure it works without worrying too much about integration issues.

If you don t have an ESB, I suggest you try Mule for development and WebSphere ESB for test and production. I tend to use two products that supposedly follow standards to make sure we keep the vendors honest and to make sure your developers are conforming to standards preventing inadvertent vendor lock-in.

In the end, just answer the following question: is the time adding the bit of complexity to simplify other complexities your enterprise worth the cost in the long run?

In addition to the sites that were already mentioned. You should read this article on "Don t use an ESB unless you absolutely have to". It was written by the CTO of MuleSource, one of the most popular open source ESB s available. Not exactly an answer to your question, more of making a point to ask yourself "Do I need an ESB"?

There is a decent 3-part series over at IBM regarding ESB that s pretty concept oriented and vendor agnostic (for the most part). I have found lots of good stuff on ESB by poking around IBM s site. There is also some decent info and videos and stuff over at the BizTalk site.

Check out this Hanselminutes podcast. It answers a few questions that you should really ask yourself before implementing a service bus.

An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.

In essence, ESB does for distributed heterogeneous back end services and applications and distributed heterogenous front-end users and information consumers what middleware is really supposed to do: hide complexity, simplify access, allow developers to use generic, canonical forms of query, access and interaction, handling the complex details in the background. The key to ESB s appeal, and possibly also its future success, lies in its ability to support incremental service and application integration as driven by business requirements, not as governed by available technology.

http://searchsoa.techtarget.com/definition/enterprise-service-bus

WSO2 Enterprise Service Bus(Product)

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentation! WSO2 ESB is a fast, lightweight, 100% open source, and user-friendly ESB distributed under the Apache Software License v2.0. WSO2 ESB allows system administrators and developers to conveniently configure message routing, mediation, transformation, logging, task scheduling, failover, load balancing, and more. It supports the most commonly used Enterprise Integration Patterns (EIPs) and enables transport switching, eventing, rule-based mediation, and priority-based mediation for advanced integration requirements. The ESB runtime is designed to be completely asynchronous, non-blocking, and streaming based on the Apache Synapse mediation engine.

WSO2 ESB is developed on top of the revolutionary WSO2 Carbon platform, an OSGi-based framework that provides seamless modularity to your SOA via componentization. It includes many features and optional components (add-ons) you can install in the ESB, and you can easily remove features not required in your environment, thereby allowing you to fully customize and tailor WSO2 ESB to meet your exact SOA needs.

Architecture Application infrastructure on the enterprises may be inherently complex, comprising hundreds of applications with completely different semantics. Some of these applications are custom built, some are acquired from third parties, and some can be a combination of both and can be operating in different system environments.

Integration among these heterogeneous applications is vital to the enterprise. Different services may be using different data formats and communication protocols. Physical locations of services can change arbitrarily. All these constraints mean your applications are still tightly coupled together. An ESB can be used to loosen these couplings between different services and service consumers.

WSO2 ESB is a full-fledged, enterprise-ready ESB. It is built on the Apache Synapse project, which is built using the Apache Axis2 project. All the components are built as OSGi bundles.

Take a look at my presentation "Spoilt for Choice - How to choose the right ESB".

I explain when to use an ESB, Integration Suite, or just an Integration Framework (such as Apache Camel). I also discuss the differences between open source and proprietary ESBs.

there is zero reason to use an ESB. Don t do it. Needless complexity. Why go through an intermediary when you can go direct? The ESB folks will tell you point to point is bad, yet somehow point to point to and from the ESB is good.

The first question you need to ask yourself is why do you need an ESB?

ESB is usually used in Event SOA distributed architectures, which seem to be a hot buzzword nowadays. Before you jump into ESB let me remind you of Martin s Fowler First Law of distributing Systems:

http://martinfowler.com/bliki/FirstLaw.html

"My First Law of Distributed Object Design: Don t distribute your objects (From P of EAA).

The relevant chapter is available online."

When you re build a new system, the most important aspect is that it is future proof, that means easy scalability and maintainability. If you build your system around the concept of loosed services with static defined contract distributed in a networked environment, you can "hide" the architecture you want for that particular service, because the interfaces are still there.

ESB is close related to asyn messaging systems, so before you start jumping into that kind of implementation, know that an architecture does not have to be homogeneous, that is all services be implemented the same way, don´t start the biggest mistake which is distributing your system from the start, you should only distribute as you need to scale, no before hand. What you need to make sure though, is that your services should be able to be easily distributed should the need arise, without breaking any contracts which would mean, changes to clients of that service.

As for the benefits of ESB, they are the same as SOA, ESB adds the context of asyn messages (events) operations.

First let me explain SOA. It it about building an architecture as a set of reusable software modules exposed as “Services” with well defined interfaces. The services facilitate loose coupling and abstracts its implementation details from the clients.

SOA might end-up messy if each component called on services directly. Therefore it has following common issues.

• How do you find which services are used & which are not?
• How do you find the clients using a particular service?
• How do you roll out updates to a service or expose new versions to existing services without disruption?
• How do you support backwards compatibility for older clients invoking older service interfaces
• How do you perform logging, auditing, security enforcement etc across all services for internal / external traffic?

The ESB is the solution to above issues. ESB…

• Helps brings in order
• Can strictly enforce corporate policies
  • e.g. Security, throttling, auditing etc applied consistently
• Virtualizes service endpoints
  • Facilitate versioning, flexible updates, HA / Load Balancing etc.
• Perform routing, mediation, transformation, etc

Some sample use cases can be found here. Note that they are from AdroitLogic s developer site and strictly coupled with UltraESB, AdroitLogic s ESB.