calling a method in which way?

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?

the picture of the system is below.(Message handler and Transaction processor)

Answer 1

There's quite a lot to answer there. Briefly:

1. If your program is split up into a client/server, you can't use a normal method call.
2. Queuing would possibly work if your method calls are one-way (have no return value). However if you want to return values synchronously then what do you do ? Have two queues - one for outgoing and one for incoming results ? And what do you do re. exceptions. It's not a natural fit.
3. Web services will work. However they're often used for bridging between client/servers on different platforms and written in different languages, so it may be a lot of unnecessary work here. The same applies to CORBA, btw.
4. A TCP socket solution would work, but requires quite a lot of extra work to set up (if you want to invoke separate methods etc.). Note (also) that TCP and UDP are fundamentally different and for reliability purposes I wouldn't use UDP normally for this sort of stuff.
5. RMI is pretty straightforward to set up in Java, and that would probably be a good first step. Check out the RMI tutorial here.

Answer 2

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.

Answer 3

Option (2) will only work if both parts of your program are running in the same JVM.

Options (3) and (4) only work if you don't mind the calls being asynchronous, i.e. not returning a result directly to the caller.

Options (5) and (6) take a lot of work to set up, you'd be better off with (1).