JMS, RMI and synchronous request-response

M

marlow.andrew

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
needs.

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.

Regards,

Andrew Marlow
 
A

Arne Vajhøj

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
needs.

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.

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
 
T

Tom Anderson

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
needs.

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?

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.
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.

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?
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.

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
 
A

Arne Vajhøj

EJP said:
Err, it's used by practically every J2EE container except JBoss.

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

Arne
 
A

Arne Vajhøj

EJP said:
Really? It's the specified standard protocol for EJBs.

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.

Examples:

<quote>
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
implementing
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
applets.
Any such reference to a ORB object is only valid within the component
instance that
performed the lookup
</quote>

<quote>
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.
</quote>

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
 
M

marlow.andrew

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.

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.

Regards,

Andrew Marlow
 
M

marlow.andrew

Does your new system actually require request-response
yes.


I strongly urge you to consider Jini (http://www.jini.org). It
combines the best aspects of CORBA and JMS, resulting in highly
resilient, scalable systems.

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.

Regards,

Andrew Marlow
 
A

Arne Vajhøj

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?

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.
I see there is a part for remote procedure calls
using RMI-IIOP. Is that what you meant?

That is just the transport. Unless you want to write your own server,
then you will not care.
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.

True.

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 is an example of a lightweight
framework developed as an alternative to EJB complexity. It seems much
more popular to me than EJB.

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
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top