views:

1449

answers:

6

When developing distributed applications, all written in Java by the same company, would you choose Web Services or RMI? What are the pros and cons in terms of performance, loose coupling, ease of use, ...? Would anyone choose WS? Can you build a service-oriented architecture with RMI?

+5  A: 

I'd try to think about it this way:

Are you going for independent services running beneath each other, and those services may be accessed by non-java applications some time in the future? Then go for web services.

Do you just want to spread parts of an application (mind the singular) over several servers? Then go for RMI and you won't have to leave the Java universe to get everything working together tightly coupled.

Thorsten79
Good approach to think about it. Also do not forget the additional complexity and hassle that is involved with having to have an RMI Registry running for looking up services. That is at the very least an addition port open and at worst problems with hosting that registry.
Boris Terzic
A: 

RMI has bandwidth overhead whereas Web Services is going to have processing overhead. Pick one. All in all, it won't really matter that much in terms of overhead. With RMI you're constricting both ends to Java whereas otherwise you can use any preferred choice.

Joe Philllips
WS has bandwidth overhead as well, possibly more than RMI, since WS uses XML typically.
davetron5000
+4  A: 

I would choose WS.

  • It is unlikely that WS/RMI will be your bottleneck.
  • Why to close the door for other possible technologies in the future?
  • RMI might have problem if version of classes on client/server get out of sync.

And... I would most likely choose REST services.

Vilmantas Baranauskas
+1  A: 

my choices are:

standard java serialization - pros : imho offers the most performance, simple to implement (I'm using Spring to expose local interface as remote one); cons : serialization doesn't work between different jvm versions

binary serialization (for example hessian from jetty) - pros : same performance as with java serialization and works between different jvm versions

WS: only if there is a need in interoperability between different platforms java + .net , otherwise it is just too haveweight.

mtim
A: 

RMI is a great rapid-development transport, but I would advise against using it in a production environment. The serialization compatibility problem can make things awkward, you have to coordinate your deployments very carefully.

WebServices are inefficient, yes, but just through hardware at it. Alternatively, use plain, lightweight XML-over-HTTP, rather than full-fat SOAP/WSDL.

skaffman
+1  A: 

If You Aren't Gonna Need It (interop with non-Java), and you probably aren't, RMI is going to be better; less code, less configuration, less bandwidth overhead.

An option if you are scared that you Are Gonna Need It is to use EJB3; it uses RMI, is very easy to setup and deploy, but also allows you to turn your calls into Web Services easily if you need them.

Whatever you do, do not create your own thing; stick to a standard.

davetron5000