Discussions

EJB design: Design of a partially a-synchronous web application

  1. Hi all, right now I'm working on application which has some tricky things in it. An alpha release containing some ideas has already been developped and one major problem we encountered was the application begin partially asynchronous.

    The application consists of the following:

    - a web client accessing the application through an HTML interface.
    - An application server (currently Weblogic 5.1) containing logic and access to databases through entity beans.
    - Another backend platform which provides the actual data. This platform is linked in an asynchronous way to the application server.

    Common situations include the following:

    A user enters the application, sends some requests, which are put in the database for later reference. The requests are also sent to the backend providing the logic. This platform provides (after an unknown amount of time) the results of the operations it has performed on the request data. Of course, the user want to see these results.

    What we're doing right now is having two tables ina database. On for requests and one for results. Generally we let the user just poll for his/her results. In some circumstances we just block the calling thread of the user (yeah yeah I know it's completely forbidden!!!) and we wait for the results to come in before proceeding. But we know this isn't the solution.

    It just seems not right to let the user poll and of course thread blocking is completely out of the question.

    Does anyone have an opinion on how to connect a web application to an asynchronous backend using an application server, while still, the results come in as fast as possible sometimes without interaction of the user? Is an (j1.0) applet a possible solution or does somebody have better ideas???????



    Second question? How to make this backend contactable bythe app.server. Is it hard to make it contactable by JNDI? Is some sort of driver-situation possible. Can it be done with some sort of entitybean solution? More generally, how do you design a ASYNCHRONOUS link to a completely different platform (not adhering to J2ee standards, but written in Java) in a transparent, reusable and good performing way? JMS?

    Thnx alot in advance!!!

    Alef Arendsen



  2. You cannot do thread synchronization in EJBs, but you can block/unlock all you want anywhere else, so, for example, in your servlet you can update your database data using entity beans and invoke the 'backend' by some other means - at this point you can either block until backend returns some results, or execute this logic on a worker thread and store the request currently executing in the servlet session - that way your servlet can respond with page which reloads itself every N seconds saying "please wait..." until your servlet gets results from the backend.
  3. Ok, I always thought thread blocking in normal Java Objects in a J2EE env. wasn't permitted, but ok...

    Right now we're already implementing some kind of polling to realize a certain task-console contains tasks and their states. This is also done by polling. But this has also some drawback, like network traffic... But on the other hand, an applet is also not really friendly to the network-traffic is it...

    ok, so now the only thing left is the 'backend'. You're right, not really a good name for it, but ok...

    thnx!!

    A.A.
  4. Don't you want JMS for the asynchronous needs? This other backend unit can do all its processing and then notify your main backend via a JMS message, which is asynchronous in nature.
  5. We have done something similar for a request/reply kind of interaction from a web-client for accesing information from a backend DB system using an asynchronous call.

    We used a messaging software (MQ Series from IBM )to do that. We post a message from the EJB component and do an in-definite wait on the "return Queue" for a response message. Once we post the message in the "in Queue", we have an adapter software in the backend DB system listening for message request, which processes the request and posts a response to the "return Queue".

    Regards

    Pugal
  6. If you are interested in using asynchronous messaging with an application server, you should look at what vendors are planning to support message driven beans in the EJB 2.0 spec in the near future. I know (since I work there) that Bluestone is releasing a GA version of message driven beans in a few weeks (there is a beta out now) based on the public draft on the EJB 2.0 spec. It's likely to change alittle as the spec changes, but the spec is stable enough that the changes should be minor. The Bluestone implementation will work with any JMS compliant messaging server. I'm not current on what other application server vendors are planning in this area and what release timing they have planned, but they can probably answer that question for you if you ask them directly.
  7. As far as support for EJB 2.0 goes-

    BEA WebLogic has had a service pack upgrade available for download since June for version 5.1 that implements the pending version of the EJB 2.0 spec.
  8. Hi Pugal,
    Your setup seems to be similar to what I'm looking for - could you please elaborate what your design looked like.

    I have posted a thread called Java Messaging & EJBs-Design. If you can, could you please suggest any ideas with regards to using MQ with EJB1.1? What problems you faced & what workarounds you made to receive messages from the returnQueue?

    I'd appreciate any pointers on this topic.
    Thanks,
    --Das
  9. You may even look at the following option.
    Spawn a seperate application which does the asynchronous processing and returns the output.
         What you can do is write a separate application in java or if possible native(C++) the better, which takes a text file as input parameter(if input is small, it can be passed in command prompt also) and writes the output in a text file. The following piece of code may be helpful.
                            
    // Spawn an application
    try {
     Process spawn =
           Runtime.getRuntime).exec("asy process Command");
      spawn.waitFor(); // THis will wait until the process is
                          completed.
    }
    catch (IOException ex) {
            // catch the exception here
    }

    After the waitFor() is being released, you can read the output of the process and send it to the user.

    I don't know what I understood is the correct scenario. But still, you can look at this option also, just a food for your thought.

    Let me know if you have any questions.
    -Prabhu
    kkprabhu@hotmail.com
  10. I did an chapter in the Professional JSP book published by Wrox Press that demonstrates this capability. The real question is what's happening with your customer while the task is running...

    Basically the example (Chapter 13), lanuches a request VIA a servlet. I get a response from the Java Application backend (which can be anything) and the result says pending response. The Servlet does a sendRedirect to the client displaying a "Waiting JSP page." This page does an HTML refresh every few seconds. This request is forwarded to the controller servlet which makes the request again. The result can determine the next step. I've waited x number of times so send an error JSP page, or I've finally received the answer so display the results, or display the "still waiting page." It's a really cool example. If you want a copy of the source code send me an email. It's not the most efficient (i.e. doesn't use JMS or EJB, but it's effective).
  11. Alef,

    I have a very simular issue. I have messages being received into a queue. When the message arrives I need to notify the client via an applet that they have messages. Currently I to have the applet polling and I just hate doing that. I am experimenting with HTTPTunneling using HTTPSessionBindingEvents to notify me when I lose a connection due to the Session timing out. I then instruct the applet to re-connect to the server. I havn't totally got this working yet but maybe this will spark so more conversation.

    If you found a solution I'd like to hear it.

    Thanks,
    Walt