JMS, RMI and synchronous request-response

Discussion in 'Java' started by marlow.andrew, Aug 10, 2008.

  1. I worked on a java CORBA project once where I was asked to replace
    CORBA with JMS. I queried this because the software was using
    synchronous request-response which CORBA is very good at. Well the
    change went ahead anyway and I don't think the JMS approach was
    better. In fact, IMHO in some ways it was worse. Now I find myself on
    a java project that is also considering using JMS for synchronous
    request-response. My concern is the same issues will be there. The
    issues were:

    cannot tell when connection between client and server is broken
    cannot tell when server is not there
    cannot tell the difference between a very busy server and a server
    that isnt there
    performance issues when large XML messages are exchanged

    Yet when I google I find that people do use JMS for request-response.
    They point out that JMS can be used for synchronous messaaging. Well,
    yes, I do know that. I used it on this CORBA project. But just because
    you can do something doesn't mean you should. And then there is lingo
    project in codeHaus that offers request-response using JMS. This also
    encourages people to look to JMS for solve their request-response

    So I was wondering, what is other peoples experience of implementing
    request-response systems in java. Do you use RMI? CORBA? JMS? Lingo?
    Or something else?

    RMI seems to have only superficial appeal - it looks to me like it
    won't handle large numbers of connections well, nor handle fault
    tolerance and load balancing. Std CORBA doesnt either but most
    implementations provide extensions in these areas.

    CORBA seems to have gone out of fashion. I think this is a pity coz I
    reckon its the closest thing to a solution right now.


    Andrew Marlow
    marlow.andrew, Aug 10, 2008
    1. Advertisements

  2. marlow.andrew

    Arne Vajhøj Guest

    You should only use message queue (via JMS) for async.

    For request-response:

    Java-Java (simple) : RMI

    Java-Java (advanced) : EJB

    nonJava-Java : SOAP/HTTP

    CORBA is still supported in Java, but not much used.

    If it is Java-Java, then EJB should provide the same features
    as CORBA and be easier to use.

    Arne Vajhøj, Aug 10, 2008
    1. Advertisements

  3. marlow.andrew

    Tom Anderson Guest

    I haven't really done anything like this, so my knowledge is entirely
    academic. But i'd agree that JMS really seems like the wrong tool here.
    You can run RMI over IIOP, such that is basically becomes a facade over
    CORBA, although i think the ORBs need to support some specific extensions
    ('objects by value', possibly something else). Would that let you use the
    enterprisey features you want from RMI, without the interface complexity
    of raw CORBA?
    I think you're right. There are installations of CORBA doing some pretty
    serious work out there in the wild that are the living proof of this. I
    know CORBA isn't perfect, and i understand why it didn't become a roaring
    success, but what really confuses me is that we've ended up with
    alternatives which are more complex and less powerful. What happened?

    Tom Anderson, Aug 11, 2008
  4. marlow.andrew

    EJP Guest

    Err, it's used by practically every J2EE container except JBoss.
    EJP, Aug 11, 2008
  5. marlow.andrew

    Arne Vajhøj Guest

    It is present in every Java EE container including JBoss, but
    not used much.

    Arne Vajhøj, Aug 11, 2008
  6. marlow.andrew

    EJP Guest

    Really? It's the specified standard protocol for EJBs.
    EJP, Aug 11, 2008
  7. marlow.andrew

    Arne Vajhøj Guest

    I thought they used IIOP which is a transport protocol while
    CORBA is a distributed component framework (that
    also uses IIOP).

    I am talking about the CORBA stuff that the Java EE
    standard mandates.


    J2EE.5.8 ORB References
    Some J2EE applications will need to make use of the CORBA ORB to perform
    certain operations. Such applications can find an appropriate object
    the ORB interface by looking up the JNDI name java:comp/ORB. The
    container is
    required to provide the java:comp/ORB name for all components except
    Any such reference to a ORB object is only valid within the component
    instance that
    performed the lookup

    J2EE applications need to use an instance of org.omg.CORBA.ORB to perform
    many Java IDL and RMI-IIOP operations. The default ORB returned by a call to
    ORB.init(new String[0], null) must be usable for such purposes; an
    application need not be aware of the implementation classes used for the
    ORB and
    RMI-IIOP support.

    Nobody uses that.

    And my understanding is that the app server vendors often have
    huge problems with that part when they need to get certified.

    Arne Vajhøj, Aug 11, 2008
  8. I am still learning about some of this stuff, as I am new to java. EJB
    seems to me to be a large collection of API specifications. Which part
    did yoy have in mind? I see there is a part for remote procedure calls
    using RMI-IIOP. Is that what you meant?

    I am reluctant to jump into EJB since it seems to have a record of
    being overly complex. There are tales of other developers being
    reluctant for the same reason. Spring is an example of a lightweight
    framework developed as an alternative to EJB complexity. It seems much
    more popular to me than EJB. Unfortunately I do not know much about
    spring either, apart from the IoC and dependency injection ideas.


    Andrew Marlow
    marlow.andrew, Aug 11, 2008
  9. I will consider it. In the previous project I raised the same question
    in this ng and jini was mentioned then. I did take a quick look and it
    seemed to me that it was not mature enough. That was only around 6
    months ago so the situation may be unchanged. I will take another,
    longer look though.


    Andrew Marlow
    marlow.andrew, Aug 11, 2008
  10. marlow.andrew

    Arne Vajhøj Guest

    It is a standard so it is documented.

    There are several types of EJB:
    - session bean
    - entity bean
    - message driven bean

    It is session bean that is relevant for you.
    That is just the transport. Unless you want to write your own server,
    then you will not care.

    But most of it is just bullshit.

    EJB's are not complex.

    For session beans:

    You write 1 or 2 interfaces a class implementing those and put some
    annotations on it.

    That is about it.

    For EJB versions before 3 you needed to write 2 or 4 interfaces
    and for some bizarre reason the implementation class should only
    implement the methods but not formally the interface. And the
    stuff in annotations where in a XML file instead.

    Not really a big deal.

    And most IDE's have excellent tools support for it.

    Not complex.

    Maybe heavyweight.

    EJB's comes with a bunch of services: transactions, security,
    clustering etc..

    If you don't need any of those, then you don't need an
    EJB container.

    That could be called heavyweight.
    Spring and EJB are not mutually exclusive.

    And it will take you a lot longer to learn everything in Spring
    than to learn EJB's.

    But there are some useful pieces in Spring - no doubt about that.

    Arne Vajhøj, Aug 12, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.