Long running webservice architecture

Question

We use axis2 for building our webservices and a Jboss server to run the logic of all of our applications. We were asked to build a webservice that talks to a bean that could

Answer 1

I don't think stateful session beans are the answer to your problem, they're designed for long-running conversational sessions, which isn't your scenario.

My recommendation would be to use a Java5-style ExecutorService thread pool, created using the Executors factory class:

1. When the web service server initializes, create an ExecutorService instance.
2. Web service call comes in, the handler creates an instance of Callable. The Callable.call() method would make the actual invocation on the business logic bean, in whatever form that takes.
3. This Callable is passed to ExecutorService.submit(), which immediately returns a Future object representing the eventual result of the call. The Executor will start to invoke your Callable in a separate thread.
4. Generate a random token, store the Future in a Map with the token as the key.
5. Return the token to the web service client (steps 1 to 4 should happen immediately)
6. Later, he web service client makes another call asking for the result, passing in the token
7. The server looks up the Future using the token, and calls get() on the Future, with a timeout value so that it only waits a short time for the answer. The get() call will return the execution result of whatever the Callable invoked.
   • If the answer is available, return it to the client, and remove the Future from the `Map.
   • Otherwise, tell the client to come back later.

It's a pretty robust approach. You can even configure the ExecutorService to limit the number of calls that can be in execution at the same time, if you so desire.

Answer 2

Another approach you could take is to make use of JMS and a DB.

The process would be

1. In web service call, put a message on a JMS Queue
2. Insert a record into a DB table, and return a unique id for that record to the client
3. In an MDB that listens to the Queue, call the bean
4. When the bean returns, update the DB record with a "Done" status
5. When the client calls for status, read the DB record, return "Not Done" or "Done" depending on the record.
6. When the client calls and the record indicates "Done", return "Done" and delete the record

This process is a bit heavier on resource usage, but has some advantages

• A Durable JMS Queue will redeliver if your bean method throws an Exception
• A Durable JMS Queue will redeliver if your server restarts
• By using a DB table instead of some static data, you can support a clustered or load balanced environment