@Asynchronous(Future class) vs JMS

[Kaleeswaran Karuppusamy]

Can we use EJB @Asynchronous annotation in distribute environment. I know we can use it but I want to know its Advisable or not. Because It's not advisable to manage user thread in Distribute environment like EJB container .

Earlier if we want to make Asyn call then we use JMS. But now they added @Asynchronous annotation with Future Class to achieve the same result.


Please advise me.

[Henry Wong]

Kaleeswaran Karuppasamy wrote:Can we use EJB @Asynchronous annotation in distribute environment. I know we can use it but I want to know its Advisable or not. Because It's not advisable to manage user thread in Distribute environment like EJB container .

Earlier if we want to make Asyn call then we use JMS. But now they added @Asynchronous annotation with Future Class to achieve the same result.

EJB and JMS have completely different APIs. They serve different use cases -- the first is like a remote procedure call, the later is publish / subscribe or queuing (depending on how you are using it).

With the exception of IBM, who has popular commercial products for both, their commercial implementations are from different vendors. And in many companies, messaging is such a specialized field, that application servers and messaging environments have different system administrators.


I don't think that you can fairly say that an annotation and a class of one can achieve the same result of the other...

Henry

[Rob Spoor]

Kaleeswaran Karuppasamy wrote:Can we use EJB @Asynchronous annotation in distribute environment. I know we can use it but I want to know its Advisable or not. Because It's not advisable to manage user thread in Distribute environment like EJB container .

If you use @Asynchronous, you're not managing threads yourself. You're just telling your container to do something in another thread. Which one is up to the container. It can either use a thread of the general purpose thread pool, or use a specific thread pool.

Earlier if we want to make Asyn call then we use JMS. But now they added @Asynchronous annotation with Future Class to achieve the same result.

Sounds fair enough, I've had to do the same (replace JMS with @Asynchronous for asynchronous calls). The main difference in a distributed environment is that with @Asynchronous, I believe you are stuck to the same JVM, whereas JMS allows the processing to be done in another one (as long as it can receive the JMS messages).

Note that @Asynchronous is not meant as a replacement for JMS for all purposes. Only where JMS is used for asynchronous processing can it be replaced with @Asynchronous.

[Jaikiran Pai]

Like Henry and Rob have noted, there's a lot more to messaging systems than just asynchronous processing. Message selection, persistence to name a few common features. Having said that, before @Asynchronous was introduced in Java EE, developers used to rely on JMS to handle asynchronous processing in their application. Many times, it was more as a workaround than a real need for messaging systems. If your application was using JMS just to achieve asynchronous behaviour, then yes you could think of replacing that part with the new @Asynchronous business methods. But in general, @Asynchronous is not meant to be a replacement to JMS.