Question

I want to make connection between two parts of my program which can be located in departed places.
I have some choices for making this connection:

1. using PRC/RMI: in every request a calling method will send to second part
2. using normal function call
3. using queue(in memory):every request will be placed in a queue and second part will get that and answer requests
4. using queue(in DB):like number 3 but in DB
5. using socket for sending data(TCP/IP or UDP or …)
6. using web service

can anyone compare these available ways?

Answer 1

Here are my thoughts:

1. RPC/RMI – Requires the RMI/IIOP protocol over the wire, which limits you to using Java for both the client and the server.
2. Normal function call means both objects are resident in the same JVM and cannot be distributed. This will be the fastest option for a single method call. Reusing that object means having to package it in a JAR and redistribute it to all the other apps that need it. Now you’ve got to know where all those JARs are if the code changes. Distribution is an issue.
3. Asynchronous processing, but you’ll have to write all the queue and handling code. This would take strong multi-threading skills. Could be very fastest of all, because it’s all in memory and would allow parallel processing if you had multiple cores. It’s also the most dangerous, because you have to be thread-safe.
4. Don’t understand why you’d have the queue in a database. I’d prefer a Java EE app server for doing this. Not all RDBMS have queues running inside them. If you agree and go with JMS, this will be asynchronous and distributed and robust. It’ll allow topics or queues, which can be flexible. But it’ll be slower than the others.
5. Using a socket is just like RMI, except you have to write the entire protocol. Lots of work.
6. A web service will be similar to RMI in performance. But it’ll use HTTP as the protocol, which means that any client that can formulate an HTTP request can call it. REST or SOAP will give you flexibility about message choices (e.g., XML, JSON, etc.)

Synchronous calls mean the caller and callee are directly coupled. The interface has to be kept constant.

Asynchronous calls mean looser coupling between the caller and callee. Like the synchronous case, the messages have to be relatively stable.

UPDATE: The picture you added makes the problem murkier. The interaction with 3rd party merchant and card handlers makes your error situation dicier. What happens if one of those fails? What if either one is unavailable? If the bank fails, how do you communicate that back to the 3rd parties? Very complicated, indeed. You’ll have bigger problems than just choosing between RMI and web services.