Current Best Practices for Distributed Java Programs

Question

I am interested in implementing some of the processes that span machines, i.e. form a distributed program. It is the functionality of these processes that provides what I want to distribute, not the data.
So what is the current norm for distributed Java programming?
Is it still RMI? Or some kind of messaging system?
I originally thought of RMI and a small JMX for remote control, but would like to know what the current best practice is. It seems that RMI always "loops" under another layer (for example, EJBs?)

Update:
After the answers and comments, it seems that the current trend is to switch to messaging systems? Doesn't that introduce a “centralized” component in a distributed project?

Answer 1

I don’t think that RMI is the way anymore if RMI is suitable for your task, just do it with EJB, as you will get many functions from the application server, such as security / access control, transaction management, database management, etc. .d. RMI adoption is a painful and empty time.

Another option for distributed programming is to use GridGain , a powerful structure that you can use to easily run your program in the machine’s product cluster. Similarly, you can consider Apache Hadoop

I would start with GridGain because it is very easy to install, just unzip and run, and also relatively easy to integrate with your application.

Edit

The RMI and Messaging systems are slightly different, since the use of synchronous and asynchronous communication should depend on the overall system architecture and how the different components interact with each other. For example, asynchronous communication may be more appropriate if the service call is time consuming, for example, performing a batch operation or archiving large data. In this case, the service client does not support system resources (for example, sockets and threads).

On the other hand, synchronous communication may be more appropriate when the service / function takes a short time, and each remote service depends on the result of the previous one.

Answer 2

Best practice is usually EJB, since you are working inside the application stack / Java EE.

I like asynchronous messaging solutions. That is, using JMS. You can easily configure ActiveMQ as a network of brokers , and then rely on publishing subscription templates. In this case, there will be no central component. There are other brokers who do this.

Have you watched AKKA ? This is not something close to the standard, but the nische concept is useful if your application is very common in nature.

Another trend, perhaps too important for you, is to use distributed memory / data networks. For example, hadoop, etc.

Answer 3

I recently used the Cajo project to make remote access to multiple instances of java desktop (Swing) applications. The project did not see the update at the time, but it was very easy to use and just worked, with minimal fuss.

This is a thin wrapper around RMI, so it is very light and very fast.

For some examples, see "Cajo, the easiest way to do distributed programming in Java."