asynchronous session objects (long)


EJB design: asynchronous session objects (long)

  1. asynchronous session objects (long) (4 messages)

    I was wondering if anyone had made an attempt to create an asynchrounous object within EJB. We are trying to port our terminal emulation software to a web based product and we are planning to use EJB. Not sure if this a good idea. The protocol to our legacy host does not follow a request-response model. It can receive multiple responses per request as well as unsolicited responses. Our existing communication object (uses sockets) is asynchronous (creates threads) and we cannot port that to EJB since EJB does not allow us to create threads. Is there a way or workaround to this problem? We cannot block on othe socket calls and I dont like the idea of polling. Any suggestions/ideas will be appreciated.


  2. I think the answer to your problem is JMS. I am pretty sure that JMS allows you to do asynchronous messaging.
  3. Note that in EJB 2.0 (which is now has beta support in WebLogic 5.1) there are message-driven beans. This is a new kind of bean, associated with a JMS topic (yes, JMS support is mandated by the EJB 2.0 spec). The message-driven bean is activated when a message arrives. The middleware takes care of activation.

    This could be the right architecture for you, if you can wait for commercial release of this stuff (as far as I understand, in the fall timeframe).

    Gene Florintsev
    gene at ejbility dot com

  4. The fact that you get back multiple responses to a request and that you you get unsolisted responses doesn't really mean you have broken the request response architecture. We had a full request response server (in C++) that had both of these features. Use a composite pattern for both requests and responses and you can get around this.

    The multi - threading issue: the point of ejb is that the container manages the threads and not the objects themselves. So it is not really true that EJB's are not able to be used in a multiple threaded environment it is just that you don't have as much control. I created a class that spons 500 threads that call the "same" ejb and it works fine. If they are session beans the app server will spawn new instances to service your request.

    I am not sure if I have understood your question the way you intended but I hope that helps
  5. I have a similar issue, and haven't seen a solution to it
    in the discussion.

    Q: I need "something" (avoiding saying threads) on my server side to be monitoring modems for inbound calls.
    Each modem can have different logic that should be used
    when the call comes in.

    To my knowledge there is no way of handling this in EJB
    or EJB 2. The messaging solution doesn't seem to work
    because nothing is listening to the inbound call.

    Normally the modems are used for outbound calls which
    are triggered from user events.