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