EJB design: Basic Requirments For Client/Server Functionality

  1. It seems to me that there are two basic requirements for Client/Server functionality:

    1 - When the client requests that a task be performed on the server (execute an EJB the server should notify the client with the progress of the task.

    2 - The client should be able to cancel the task.

    Its seems to me that EJBs do not meet either of these requirements. Is that correct?

  2. hello Jamie,

    Most of the solutions architected using EJBs have a browser in the presentation layer and that would imply an HTML page. Under such conditions the HTML page would have calls to either a servlet or a JSP page and the only indication that you have of progress is your browser status bar. That in fact is a very definite indication of status. By the same token a client could cancel the operation by clicking on the stop button of the browser. However this would only stop the transfer of information from the Webserver to the browser and not any server side transactions that might have been triggered by the user action.

    If you have Java running on the browser then it is possible to send signals to the server which can cause it to revoke operations that were triggered earlier from the client.

    So I guess the answer to your question is that the client server functionality that you are looking for can be architected into a EJB solution.


  3. Jamie,

      These basic requirments are extremely difficult and awkward to implmement in an browser based world, due to the statelessness of the HTTP protocol. I personally don't know of any website that has this functionality (real time progress display), and if you know of one let me know.

      Thats not to say that it is impossible to implement with standard web browser>Servlet>EJB. What you would have to do is have a status screen that uses JavaScript to refresh itself every so often. On the server side of things, you would need to write special code in your algorithms that would right status information to the database, so that your status page can poll the database to determine what the current status is. To be able to cancel your job, you would need special code interlaced with your business logic to poll the database to see if a "cancellation" order has been issued.

       Enterprise programming is all about transactions. Once a user iniates a transaction, his work is done. The transaction now either succeeds or fails, and any extra interaction between client and server is highly non-standard and would have to be coded up in a way as I suggested above.

    Hope this helps,