title: ESBs vs Services
body: <p>I'm new to Java EE and have been struggling with some basic middleware concepts for several days now and <em>believe</em> 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 ;-).</p>
  
  <p><strong>Please confirm/clarify:</strong> 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 <code>HttpRequest</code> 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 <code>HttpResponse</code> 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 <code>HttpRequest</code> 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.).</p>
  
  <p>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.</p>
  
  <p>In that case, it seems to me that big applications would need <em>both</em> 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:</p>
  
  <ul>
  <li>Use a full-blown app server like JBoss or GlassFish</li>
  <li>In the app server's web container have two WARs: <code>WebServices.war</code> and <code>ESB.war</code>; which represent the backend "gateway" and service bus respectively</li>
  <li>In the app server's business container have all my EJBs</li>
  <li>Now, the <code>WebService.war</code> (gateway) can detect whether to relay the request on to the ESB or the EJBs</li>
  </ul>
  
  <p>My second question is: <strong>am I way off-base here and have I missed the basic concepts of Middleware 101, or is this a half-way decent approach?</strong></p>
  
  <p><strong>Edit:</strong> From the initial responses I already see that I was wrong in two areas: (1) that ESBs and EJBs can in fact be <em>either</em> synchronous or asynchronous, and (2) that, when using MDBs, EJBs can be wired up like an ESB.</p>
  
  <p>So these correction pose some new mental obstacles for me:</p>
  
  <ul>
  <li>When to go with an ESB, vs. when to go with a MDB/EJB solution; and</li>
  <li>I <em>really</em> like Apache Camel's Processors API (implementation of EIPs); could I use MDB/EJBs but inside every EJB just use a Camel processor (<code>Filter</code>, <code>WireTap</code>, etc.)?</li>
  </ul>