EJB notification message to the client?


EJB design: EJB notification message to the client?

  1. EJB notification message to the client? (5 messages)

    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
  2. You don't describe the nature of the client. Is your client an http client accessing the EJB via a servlet or is it a Java application? The difference is important. As http is a request/response protocol, the Servlet won't run without a stimulus from the client's browser.

    If the client is a Java application, you have several possibilities. I would have thought that a message oriented solution using JMS would be your best bet. What you could do is for your EJB to establish a message queue (using Pub/Sub) with an "Alert" topic on which it publishes any alerts. Your client applications (and there could be many of these) subscribe to that queue/topic and all will be sent the alerts. This is quite nice, as the EJB doesn't need to know who is interested in the alerts, and subscribers can come and go as they please.

    The trouble with your RMI solution, even if you could make it work, is that the server needs to know all consumers of the alerts, and would need changes (OK - maybe only config) if a new consumer arrived or an existing one departed.

    Hope this makes sense, and that it helps.
  3. Could you use JMS?

    -- Les
  4. You can use RMI from within a session bean. The EJB spec doesn't prohibit using ALL sockets, it only prohibits an EJB listening on a socket or accepting connections on a socket (basically the functionality offered by the ServerSocket class). The spec also prohibits setting the socket factory.

    A quote from section 24.1.2 "The EJB architecture allows an enterprise bean to be a network socket client, but it does not allow it to be a network server".

    If your EJB acts as an RMI client then it will only need to open a Socket, not a ServerSocket, so you'll be OK.
  5. Rene,

    You put this help request on 3 forums. The concensus on all 3 is that you should use JMS. This confirms my first thoughts on it.

    Alerts are an infrequent ocurrance. The last think you want to do is poll for an event that may NEVER OCCUR.

    This is the ideal application for Messaging. The other poster on this thread has explained that you can use RMI if you want. I'm sure he's right, but I'd always use MOM for something like this.
  6. Hi David,

    You are absolutely correct. JMS is the way to attack this problem. I wasn't trying to advocate using RMI as the solution, I was just clarifying that RMI *can* be used from an enterprise bean if need be.