On reading a bit more on this, i guess Message Driven POJOs are specific to JBoss' EJB3.0 as mentioned at:
While message driven bean is very powerful and flexible, it is perhaps too flexible for many messaging-based remote procedure call (RPC) applications. The client and the bean must agree on the message queue to use and the exact message exchange format. That is a bit of hassle for developers who just want to make reliable asynchronous RPCs over message channels. It is also a source of potential runtime errors as the coupling between the client and the message end point is not checked by the compiler. In addition, the EJB 3.0 message driven bean is still a "component" that has to implement the MessageListener interface -- it is not a POJO.
In JBoss's EJB 3.0 application server, there is an easier way to implement message driven RPCs. You can use POJOs as message end-points (message driven POJO). The RPC caller retrieves a automatically generated stub of the POJO and make regular calls against the POJO methods. The JBoss message driven POJO works very much like an EJB 3.0 session bean, except that all calls are tunneled via a message queue.
Originally posted by Paul Sturrock: "Message Driven POJO"?
Are you saying you need to implement something using JMS? If so, what?
Thanks for active participation to my topic. I have tried to write Message Driven POJO(MDP) implementing javax.jms.MessageListener. you can also use org.springframework.jms.listener.SessionAwareMessageListener.I have studied MDP & decided to follow some steps to introduce support of MDP in a framework. Steps are written below:-
* In a fashion similar to a Message-Driven Bean (MDB) in the EJB world, the Message-Driven POJO (MDP) acts as a receiver for JMS messages. * ListenerContainer is to be added. * ListenerContainer is responsible for all threading of message reception and dispatch into "Message Driven POJO" for processing. * A message Listener Container is the intermediary between "Message Driven POJO" and a mesaging provider. It takes care of registering to receive messages,participating in transactions,resource aquisition and release etc. * This allows an application developer to write complex business logic associated with receiving messages.
But I am stuck at a point. I have written Abstract Message processor class.As i am framework developer, not a application developer.so application developer will write sub class of Abstract Message processor.MDP will invoke process methods(eith no operation) of Abstract Message processor class. if i load subclass object by : Thread.currentThread().getContextClassLoader().loadClass(msgProcessorClassName); it will become memory issue.bcoz for every message sub class of Abstract Message processor will be loaded. what will be perfect design. can any body give idea of Object pooling related to this issue.