JAVA EE中的并发处理

Question

I'm working in a Java EE application and I want that some WebServices are executed in parallel.

I would like to know the pros and cons of 2 different approaches:

1. Use JMS queues and MDBs , so each message I put in the queue would be executed in parallel. This way the application part that put the message into the queue would have a while, that waits the MDBs to response in a RS Queue.
2. Use the java concurrent API (Future / Callable) .

---

ADDED

This is what the application needs to do:

The application already does it via an MDB, but I was thinking about a refactoring.

TODAY'S SCENARIO:

//CALLER CLASS
FOREACH INTEGRATION
    PUT MESSAGE INTO A QUEUE AND STORE AN ARRAY OF CORRELATION_IDs
END

THREAD.SLEEP(X) // SOMETIME FOR INTEGRATION TO FINISH

WHILE (true){
    GET RESPONSE FROM THE RESPONSE QUEUE FOR EACH INTEGRATION USING THE CORRELATION PREVIOUSLY STORED
}


//MDB CLASS
HAS A HUGE SWITCH CASE THAT PROCESS EACH INTEGRATION

RETURN THE RESULT INTO THE RESPONSE QUEUE;

Questions:

1. Is it ok to use the concurrent API in java? In my opinion using the concurrent API will eliminate a layer of failure ( JMS ).
2. My deployment environment is Websphere . Is it a good practice to create your own threads with the concurrent java API.

Thanks in advance

Answer 1

jms pros: you can have persistence, you can connect to existing infrastructure jms cons: seems to heavy to be used only as a dispatcher

manual concurrency cons: well, it's manual. and parallel programming is difficult. some webservers (especially clouds) may forbid to create your own threads

not sure what exactly you want to do but webserver by default processes requests in parallel, so maybe you don't need anything else?

Answer 2

Whatever solution you go with, you will eventually need to cope with a burst of traffic. The JMS/MDB the burst is controlled by the queue effectively. Also a point to consider is that the queue can be made persistence, so it will survive a server restart. Also a queue can be distributed across many servers, giving you horizontal scalability.

The thread approach is of course quicker to develop, test and deploy. However, I would consider using a BlockingQueue so that your threads do not run amock.