I have two jee web apps that are going to be published on the same physical server, but on different network addresses.

APP A: Listens to a port on a public IP address and makes synchronous invocations to app B if necessary.

APP B: Listens to a port on a private IP address and makes synchronous invocations to app A if necessary.

enter image description here

For connecting APP A with APP B, I am considering the following alternatives.

  • RMI
  • Message Queue
  • Lightweight ESB

Please tell me if you see any clear advantage supported by facts on any of them, or if there's another technology I should consider.


I've done HTTP/REST-ish using JAX-RS almost exclusively for inter-service communication a while (barring some JMX for monitoring), but here's my memory of the arguments:

  • EJB is a convenience wrapper for RMI

  • RMI is a slick, but proprietary Java protocol.

  • SOAP has some very serious supporters, but is struggling under the weight of XSD strictness, and can create tight coupling between client and server if you're not really, really careful.

Which is why JSON over HTTP has been emerging as a popular choice for inter-service comminication. It's also officially part of JEE with the JAX-RS spec, so that RMI/EJB isn't the only official answer anymore.

  • EJB has the disadvantage that you need a full-blown enterprise container rather than a smaller, free application container like Jetty or even Tomcat

  • RMI has the disadvantage that it's a proprietary Java protocol, so you can only talk from Java to Java. I have a memory that you can bridge other technologies using an underlying CORBA implementation, but it's been 15 years since I had that conversation.

  • Also, since RMI relies on object serialization, it can be prone to really tight coupling between client and server. Meaning that if you compile a new version of the server, you have to compile and deploy a new version of all clients. I could be way off base on that, though.

Since JAX-RS is part of the JEE spec now, and there are nice implementations like Jersey or RestEasy, the shops I've been at for the last decade have just gravitated toward that as the solution (even before it was part of the spec).

In addition, with an standard protocol like OAuth, you can expose the same interface on the public internet as your internal network, so you don't have to provide separate technologies for your internal vs. external APIs.

Also, even before that, I was at a shop that recognized all the benefits of running an application inside a container. So rather than rolling our own application framework, it was more convenient, standard, and maintainable to just drop our functionality into an application container and let it take care of the system concerns. EJB & and an enterprise container provide the same benefits, but you can pay a lot of $$$$ for licensing compared to what you can download and deploy for free.

Like I say, it's been a long time since I had those conversations, so I might get some downvotes. All due apologies.

  • 1
    RMI is actually a JAVA wrapper around CORBA. RMI is about as tightly coupled as its possible to get you need to match up executables for RMI to work. SOAP applications are fairly tightly coupled to the WSDL but implementation is completely independent. JSON is tightly coupled to an imaginary JSDL i.e. there is no formal service definition but both sides need adhere to an informal service definition. – James Anderson Mar 5 '14 at 8:17
  • 1
    +1 @James Anderson Fascinating. I remember the conversations from 15 years ago where we were building RMI on top of IIOP & some of the key guys were CORBA guys. I think the goal was to get the legacy C/IIOP code and JAVA/RMI/IIOP to talk, but it all kind of disintegrated into a religious war. That's not the technologies fault; I still found it fascinating, but there are scars. – sea-rob Mar 5 '14 at 8:23
  • @James Anderson (sorry, I'm showing off now) good point; because of the open nature of JSON specification, you can gain tremendous DE-coupling by enforcing the "MUST IGNORE" rule and ONLY up-versioning your service for truly breaking changes. And minimizing breaking changes stringently -- perhaps to never. lol I remember a good article on the Jackson web site about that. Anyway. – sea-rob Mar 5 '14 at 8:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.