ESBs vs Services

Question

I'm new to Java EE and have been struggling with some basic middleware concepts for several days now and believe I might have just had a breakthrough in my understanding of "how tings work"; a part of this question is a request for confirmation of my findings, and the other part is a legitimate question ;-).

Please confirm/clarify: My understanding of service buses/MOM (message-oriented middleware) is that they are by nature intended to process client requests asynchronously. This, as opposed to the normal request-response cycle, which is synchronous, which is usually implemented by some kind of service. In Java, such a bus/MOM could be something like Apache Camel, and the synchronous service could be something like an EJB(3). So if the client needs a request processed right away, the HttpRequest may go to a web service which then forwards the request on to the correct EJB; that EJB process the message and returns the result to the service, which then returns the HttpResponse to the client. As such, if the client has a request that does not block them and which simply needs to be processed, the web service forwards their HttpRequest on to some endpoint on a service bus and the request is treated like a message and is handled by various processors (filters, transformers, etc.).

So first off, please correct me if I am wrong in stating that an ESB/MOM solution is best suited for handling asynchronous requests, and that EJBs (again, 3.x) are best suited for responding to synchronous requests in real-time; or confirm that I am correct.

In that case, it seems to me that big applications would need both types of backends to handle synchronous (blocking) and asynchronous (non-blocking) client requests alike. So my theory would be to have my backend implemented as follows:

• Use a full-blown app server like JBoss or GlassFish
• In the app server's web container have two WARs: WebServices.war and ESB.war ; which represent the backend "gateway" and service bus respectively
• In the app server's business container have all my EJBs
• Now, the WebService.war (gateway) can detect whether to relay the request on to the ESB or the EJBs

My second question is: am I way off-base here and have I missed the basic concepts of Middleware 101, or is this a half-way decent approach?

Edit: From the initial responses I already see that I was wrong in two areas: (1) that ESBs and EJBs can in fact be either synchronous or asynchronous, and (2) that, when using MDBs, EJBs can be wired up like an ESB.

So these correction pose some new mental obstacles for me:

• When to go with an ESB, vs. when to go with a MDB/EJB solution; and
• I really like Apache Camel's Processors API (implementation of EIPs); could I use MDB/EJBs but inside every EJB just use a Camel processor ( Filter , WireTap , etc.)?

Answer 1

This is a big question and it deserves a big answer.

ESB's can handle synchronous or asynchronous requests and messages are typically used asynchronously.

However your backend implementation theory is pretty wrong.

JAX WS web services can run straight our of an EJB jar or an EAR and can do it that way in any app server. The EJB can put a message onto a queue or even be asynchronous.

You should not be relaying requests to the ESB but the other way around.

The ESB should be relaying and transforming requests and responses between clients and backends. One of the big ideas with ESB is that if a backend changes the client does not know or care since their contract is with the ESB not the backend.

All this said, if your application is already exposing web services, then you probably don't need an ESB and remember there is no one RIGHT or WRONG way to do something.

I do suggest that you write a more defined question that covers your specific problem, you will probably get a wealth of advice on how to solve it.

UPDATE

You also get message driven EJBs which would indeed let EJB's be chained together in a bus like fashion.

FURTHER UPDATE

So one scenario when I would use an ESB is if I need to expose non standards based services in legacy systems as a SOAP service. However there is more to consider, you should also implement a data dictionary for your organization, this will allow a greater chance that the ESB exposed services can remain the same even if your legacy system is replaced.

So as a concrete example, the organization should define in its data dictionary what a customer entity looks like, the ESB could expose a service to retrieve a customer. The ESB will perform some call on a legacy based system and then transform the result. If in future the backend system storing customers changes, the ESB exposed service can probably remain the same, and just the backend call and transformation needs to be updated.

Now hopefully with that in mind the next bit will make sense. All of this is possible with a "traditional" ESB such as JBoss ESB or Mule ESB BUT it is also possible using EJB + Camel (or other things).

The advantage of the out of the box ESB are the provided connectors, listeners and transformers. However if none of the out of the box features helps you then there is very little difference in the direction that you choose.

An advantage in home growing your ESB would be maintainability, it is much easier to find a resource who knows EJB well and can learn Camel quickly if they need to, than finding a specialized ESB resource or training a resource.

I hope that helped!

Answer 2

As you have noticed, the world of middleware/integration is kind of a mess in definitions and terminology. Let me clarify a bit.

A service is just a concept of "something" that delivers a capability. There are multiple ways to expose a service.

When refering to EJBs below, I mean EJBs except MDB (Message Driven Beans), which implement asychronous messaging.

• Synchronously request/reply - where the reply is expected "rather soon" after the request. Usually implemented via Web Services and EJBs (RMI,etc).
• As a published message to a number of subscribers that consume the data (typically price-lists are pushed out from a price-master system to various systems needing the information, such as the order system).
• As a fire-and-forget message from one application to the other. Typcially, the order system needs to send an order to the invocing system, then the invocing system exposes a service to create invoices.

Conceptually, an ESB, is a soft thing. It's a concept/agreement on how a companys business services should be exposed so that applications across the company can consume/use those services. This could essentially just be a set of contraints "Only request/reply services are allowed using SOAP/WebServices and all messages should conform to the OAGIS XML standard". However, in most cases, the application/server/system environment at most companies are not homogenous. There are COTS products, mainframes with COBOL applications, .NET apps as well as Java EE applications. Therefore a common approach is to use an ESB software suite to implement the service bus in technology, or to construct adapters towards the bus. Apache Camel could be part of an ESB implementation to setup routing, transformation, conversion etc.

One thing that is tightly integrated with ESB is Message Oriented Middleware, which you speak ok. It's typically just a server that implements message queuing. The benefits from MOMs are a few in contrast to just ivoking EJBs/Web Services directly.

• If asynchronous patterns (publish/subscribe, fire and forget and async. request/reply, then a relay server that has a high up time and is very stable will make it possible to, overall, have less failed transmissions of business messages.
• MOMs, ususally makes it rather easy to implement adapters and an ESB that is very resilient to load peaks, network disturbances and hardware/software failure. Messages are often persistent and are stored to disk before relayed. Also transactions are often available, specifically in JMS compliant implementations. That guarantees that data is not lost on the way.

I hope I did not mess things up more than before. This is my view of this at least.