Develop Reference

ESBs vs Services

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.)?

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!

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.

Java Client-Server communication to register a product

I'm looking for some advice on the simplest way to create some product registration communication. I have a Java desktop application that needs to be re-newed every year. When a user downloads and install this app (through JNLP) they get a limited demo-version. There is code in place on the client to "register" the product and unlock all of the features.
My next step is to build the server-side components. There will be a database with customer ID numbers and other information about the customer. When the user clicks register, some contact information will be sent to the server as well as some product registration ID. The server will check this against the database and then either give the client the o.k. to unlock the features or the user will be informed that the registration id was not valid. This seems like a very standard thing. So what is the standard way to do it?
I have my own VPS and I'm running Tomcat, so I'm really free to implement this any way I choose. I was planning on building some web service, but I have never used REST before.

Use REST; REST is nothing more than using plain HTTP 'better'. Since you are already using HTTP, somehow you are already doing REST like calls and moving these calls to full fledged REST will be easy.
Implementing REST calls is easy. You have two approaches:
Low end: using URLConnection objects on the client, servlets on the server and following some REST conventions on using HTTP methods and 'clean' URLs (see here). Advantage is that you need no 3rd party library and minimize the footprint. Maintenance and evolutions are harder though.
High-end: a framework and specifications like JAX-RS. Using Restlet you can be up in running with a REST server in a couple of hours without having to deploy a servlet container.
Don't use SOAP. The only reason you would want to use SOAP is that you want to contractualise using a WSDL what you are exposing (you can do the same with REST btw, see the Amazon documentation for instance). Trust me, SOAP is way too heavy and confusing for what you are trying to do.

Which Client - Server Communication Approach?

Basically I need a bidirectional client-server communication (Java) where the client calls methods on the server, but also needs to get "callbacks" if certain events in the server occur.
The methods theirselves have quite complex input and output parameters and lateron it would be nice to include authentication to the system.
Which approach would fit my requirements?
I already build a prototype with RMI, but I read that there exists a number of problems especially for "callbacks" when the c/s are in different networks.
Additionally I would like to avoid JAX related technology, becuase of my complex data structures in the parameters.

Have you thought about using JMS. Within this architecture, server and client will register to a queue or topic and are able to send messages to each other. This enables sych and async application behaviour.
Please have a deeper look into JMS here:
http://java.sun.com/developer/technicalArticles/Ecommerce/jms/index.html
And a really nice implementation is ActiveMQ:
http://activemq.apache.org/

I've had lots of luck with using CometD for callbacks for webapps.

How to : Async Callbacks using SOAP/REST Web Services with Java

We have a Java API that needs to be supplemented/fronted with a SOAP/REST Web service Layer.
What does it take to implement Async Calls across process/server boundaries using
a) SOAP Webservices
b) RESTful webservices
Some of the methods might need multiple calls to respond to the request.
We will be using Java/J2ee to implement the SOAP/restful service using a library like CXF or Axis or Jax-RS/WS.
Any examples ? Gotchas ?
Thank you,

The Async Http Client is an open source library that was specifically designed for this type of problem. It utilizes futures and wraps up a lot of the detail and hassle out of making async calls.
The author has a very good getting started guide and there is an active discussion group. The author is a very talented developer and the project is under continuous development.
From the documentation:
The library uses Java non blocking I/O
for supporting asynchronous
operations. The default asynchronous
provider is build on top of Netty
(http://www.jboss.org/netty), the Java
NIO Client Server Socket Framework
from JBoss, but the library exposes a
configurable provider SPI which allows
to easily plug in other frameworks.

Your question is not clear. I am interpreting your question as you want your serverside code to call a remote REST web services in an Async manner. If so then your best bet is to use the Futures feature of java.util.concurrent it will do exactly what you want. If my interpretation of the question is wrong then please update your question with exactly where the async operations need to happen.

Akka http://akka.io/
Great framework, great performance - Here are their claims:
"""
Simpler Concurrency
Write simpler correct concurrent applications using Actors, STM & Transactors.
Event-driven Architecture
The perfect platform for asynchronous event-driven architectures. Never block.
True Scalability
Scale out on multi-core or multiple nodes using asynchronous message passing.
Fault-tolerance
Embrace failure. Write applications that self-heal using Erlang-style Actor supervisor hierarchies.
Transparent Remoting
Remote Actors gives you a high-performance transparent distributed programming model.
Scala & Java API
Scala and Java API as well as Spring and Guice integration. Deploy in your application server or run stand-alone.
"""

#Vivek
GET is async and other HTTP methods
are not.
This isn't true. Please go ahead and read about AJAX :-)

For REST web services (apart from GET) everything else (POST/PUT..) is Async, it returns you the HTTP status code of the opeeration.
If you want to make GET also Async then you will have to use Threads, We did it once in Spring framework using #Async annotation (which internally spawns a thread).
From get return the callback URL as the response and use threads to process the request asynchronously.
Apart from that, For both SOAP / REST once you get the request you can publish it on a JMS queue to make the service Async.

One of the best ways to implement asynch ops is to use callbacks. For REST APIs, design of APIs and Rest client should support this. For instance , client class should pass itself or it's inner class as listner. Rest API on server side should maintain request id and call back listener in map . Once processing is done , it can call method on listener based on request id from map.

Real question: why do you want to call it Async? Having looked at solutions for parallel processing on the Java EE side, it's not recommended that you spawn child threads within a container on your own.
In your case, it looks like the following:
1. you're looking to create a wrapper contract in WSDL (REST or SOAP or both) and if you clients are not just browsers (AJAX)(i mean you'd have adopters from the server-side), then, for JAX-WS -> you could create a #CallBack end-ponint (http://docs.oracle.com/cd/E15051_01/wls/docs103/webserv_adv/callback.html)
or
if it's REST end-point that requires being called from an adopter (server-side), use jAX_RS 2.0 feature
Note: Above assumes it's point to point but in an Async way
Here are a few options:
if you're looking to call REST Or SOAP or some other function asynchronously, you can use workManager API (JSR )
or
use JMS and use a request-reply model if you need it (short running) and calling multiple end-points in parallel
use WS-BPEL (only WSDL end-points) - this is a OASIS standard as well
use SCA (any component with any technology) that can contain assemblies of WS-BPEL component (stateless or stateful) running in BPEL engine like Apache ODE or IBM process server and other components and collaborates. This is a standard

server side RemoteService implementation?

I'm really impressed with the functionality and capability found in the GWT async RPC mechanism which defines
com.google.gwt.user.client.rpc.RemoteService
com.google.gwt.user.server.rpc.RemoveServiceServlet
Due to the extreme limitations in the GAE hosting environment, I'm needing to bridge requests from a GAE server to another non-GAE server.
Is there a way to use the same DTOs and async RPC mechanism I'm using with the browser->server when communicating server->server ?

When you write a GWT/App-Engine App you compile and load the .class files as well as the comiled Javascript to one source. A client comes along downloads your Javascript and GWT does it's magic between the client and server.
Let's assume that now you want to forward some of the RPC calls to another server. You would need to make sure that the Serialization Ids were identical. You now have a problem that will give you fits when you don't keep every thing exactly in sync.
My recommendation to tou would be to use JSON, XML or just text for the calls that you need to forward. It now becomes easy to use the URL Fetch service of GAE.