Current best practice for distributed programs in Java

Question

I am interested to implement some processes that span over machines i.e. form a distributed program. It is the functionality that these processes provide that I want to distribute and not data.
So what is currently the norm for distributed programming in Java?
Is it still RMI? Or some kind of messaging system?
I originally thought RMI and a little JMX for remote management but would like to know what is the current best practice. Seems like RMI is always "burried" under another layer (e.g. EJBs right?)

Update:
After answers and comment it seems that the current trend is to go for messaging systems? Doesn't this introduce a "centralized" component in a distributed design?

Jaeger

You might want to look at message brokers like ActiveMQ. – Hovis

@BrendanLong:So you opt for messaging.And why specifically ActiveMQ and not something else? – Jaeger

ActiveMQ is one of the simplest to get started with. – Semifinal

@PeterLawrey:Does it support JMX? – Jaeger

Also why a messaging system which contains a centralized component (the queue) is more suitable for distributed programming? – Jaeger

I believe there is a way to do JMX over JMS, but I wouldn't use JMX for anything other than System Management. Ideally, I wouldn't use it at all directly. You are better of creating a component to do the JMX for you. – Semifinal

Answer 1

I do not think RMI is the way to go anymore, if RMI is suitable for your task just do it with EJB as you will get many features from the application server such as security/access control, transaction management, database management, etc. implementing those in RMI is painful and waste of time.

Another option for distributed programming is to use GridGain, a powerful framework you can use to easily run your program on a cluster of commodity machines. similarly you might consider Apache Hadoop

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

Edit

RMI and Messaging system are bit different because the use of synchronous vs. asynchronous communication should depend on the overall system architecture and how different component interact with each other. For example, asynchronous communication might be more suitable when a service invocation takes long time to finish e.g. do batch operation or archive large data. In this case, the service client does not hold system resources (e.g. sockets and threads)

On the other hand, synchronous communication might be more appropriate when the service/function take short time to finish and each remote service depends on the result of the previous one.

Weakfish

Isn't Hadoop for distributing data?Or am I wrong here?And why so pesimistic on RMI? Because it is "low-level" e? – Jaeger

As I said, RMI gives you very basic mechanism for remote service invokation, it is simply bit higher-level than plain sockets. But in real system it is very often you will need to implement other services e.g. security which you get it for free from EJB. – Weakfish

Hadoop mainly distributes jobs to run near the data, to avoid moving large data across the cluster. – Weakfish

A note about async vs sync. One of the primary benefits of async messaging over sync calls is loose coupling. The calling system does not need to care about possible limits in processing power or number of listener threads in the other system. Actually, it does also function as an implicit load balancer, where there are multiple consumers on a specific queue along with other things. Typically, I would say that short vs long time is not really the primary factor. – Rather

Answer 2

I recently used the Cajo project to do remoting among several instances of java desktop (Swing) apps. The project hasn't seen an update in a while, but it's been really easy to use, and just works, with a minimum of fuss.

It's a thin wrapper around RMI, so it's very lightweight, and very fast.

For some examples, see the article "Cajo, the easiest way to accomplish distributed programming in Java"

Halves

Why didn't you use RMI directly? – Jaeger

Cajo makes it dead simple to do a number of things that would require a lot of custom development/testing with straight RMI - like discoverability over UDP, client ability to find a remote object via a partial interface, etc. Also, really minimal code required to use it, vs. the amount of code you'd need for RMI. You remote POJOs too - no need to extend a Remote interface. Very non-intrusive. – Halves

Interesting.My concern is the statement project hasn't seen an update in a while. I checked the mailing lists and it mentions around 30 subscriptions. Wouldn't want to use an "unsupported" project – Jaeger

@Crayfus One of those subscriptions is mine, and I've never used it at all, just reviewed it for the author. I could never tell what he actually had in mind. – Medellin

@EJP:So the trend for distributed programs is using messaging systems?Isn't this approach though somewhat "centralized"? – Jaeger

Answer 3

Best practice is typically EJB, given you run inside an app server/Java EE stack.

I like asynchronous messaging solutions. I.e. using JMS. You could easily set up ActiveMQ as a network of brokers, and then rely on publish subscribe patterns. In that case, there would be no central component. There are other brokers that does this also.

Have you looked at AKKA? It is not anything near a standard, but a nische concept usefull if your application is very distributed in it's nature.

Another trend, perhaps too data centric for you, is to use distributed memory/data grids. Such as hadoop etc.

Rather

EJB if you deploy in an application server.What if you don't deploy in a container?Also is EJB-3 still on top of RMI? – Jaeger

Out of container, EJB is not really going to work. Go for RMI or similar if all you want is remote method invocation. – Rather

Well that's my OP. Is RMI nowadays the best way to go? – Jaeger