Callback Patterns...


EJB programming & troubleshooting: Callback Patterns...

  1. Callback Patterns... (3 messages)


    are there any usefull callback patterns for statfull session beans?

    I know two solutions

    1) Client side proxy (method call delegation) connected to JMS
    2) Client side proxy (method call delegation) using a timer thread to "ask" the server side for changes.

    Any idea?

    Michael (Germany)

    Threaded Messages (3)

  2. Callback Patterns...[ Go to top ]

    i tried both. the best i think will be having a temporary and unique JMS topic create dynamically everytime when the client call the session bean.

    1) client (create an topic_id)...

    2) client call session bean with the topic_id
    3) session bean create the jms topic
    2) client create jms topic
    3) client call session bean with the jndi string for the
       jms topic

    4) client subscribe to the jms topic to receive feedback.
    5) client get message .. do the work.. and then
       kill the jms topic

    basically the idea is to not:

    - having a single jms topic for the client and
      session bean to communicate to prevent 2 clients
      retrieving same messages ..

    - call back object (observer pattern?) is bad since
      you have to kick back an rmi call or something else.

    if you have doubt and may want to change the way how the session bean and client should communicate, off load these
    part of code to a "Command" object.. and have the "Command"
    object passed by the client (or created in the session bean by default?) to the session bean. The session bean doesn't care what the "Command" object will do, but just triggers some methods in the "Command" object.

    For example, like "Command.onStart()" when the session bean starts the work.. "Command.onEnd()" when the session bean finishs the work...

    // communcator Impl:
      public interface Communicator {
        public void onStart();
        public void onEnd();

    // the client
     String JMSTOPIC = "jms" + getRandomNumber();
     // JMSCommuncator extends Communicator
     JMSCommunicator jCom = new JMSCommunicator(JMSTOPIC);
     SessionBean sbean = getSessionBean();
     sbean.setCommunicator( jCom );

    // in the session bean:
      public void doWork(Communcator pCom)
      throws RemoteException {
        // on start..
        // on end..

    this way you can implement different ways to communcate between the session bean and the client..

    It keeps the code clean in the session bean and give us the flexibility to change the way to communicate in the future..

    hope it helps... use JMS if possible.. callback is good as long as both client -- sessionbean lives within the same JVM.

  3. Callback Patterns...[ Go to top ]

    Thank you.

    I tried to use RMI-Callbacks, it works but I am not
    sure if this is "allowed" in the ejb-specification.

    I need it not only for the client -> stateful session bean communication. Other components/clients should be able to send notification messages to a specific client too.
    (it behaves somehow like a chat)

    I agree, JMS seems to be the best choice.

    - Client starts
    - Client connects to stateles session bean.
    - the bean creates a jms topic for the client
      and returns any kind of description of the topic
      to the client (jndi-name for example)
    - Client connects to the created topic
    - and so on...

  4. Callback Patterns...[ Go to top ]

    Be aware that depending on the JMS implementation your idea will allocate quite a few ressources. We made heavy use of JMS Temporary Queues/Topics once (for callbacks) and the service killed itself during high load (high number of threads and sometimes deadlocks ;).

    Also: If you have HA requirements - to my knowledge cluster capable JMS Servers are still pretty expensive.