Normally a j2ee application implements the pull model, where the client asks the server for information. The application I am developing does the same, but in some cases the client needs to be notified on an event in the server.
For example when an EJB changes to a certain state, there should be an alert message going to the client, so the client can show this alert message to the screen. One way to implement this is by letting the client poll the server all the time to see if the state of the EJB has changed. This is not very efficient and nice.
Is there another way to implement this behaviour?
My first thought was RMI, but I don’t think an EJB can act as a RMI client that communicates with a RMI server (=the client) that lives outside the container, because RMI uses socket communication, and you can’t use sockets in EJB.
Does anybody has any idea on how to do this?
Rene de Jong
You can use JMS - make a special topic and create a listener on the client side. Whenever EJB feels like alerting client it would send a message, and client's listener will react.
You have said "because RMI uses socket communication, and you can’t use sockets in EJB."
Well... every method invocation inside EJB container is a RMI-IIOP invocation (except posible Local invocation via LocalInterface or LocalHome Interface in EJB 2.0) and use socket internaly. So, a EJB object can take as parameter a RMI client (your class in the GUI side) and make invocation on it. This client class must be a RMI object.