Java: RMI vs Web Services

Question

I need to create a distributed application consisting of multiple clients that send files (plus info about files) to one server, also query that server.

Clients must access to that Web Server from inside the company for sending the files. But, occasionally some specific queries must run outside the company.

I think, given what I know, that RMI is a faster(operating performance) way to connect the desktop client with the indexing engine plus the storage engine. And I believe that making a Web Service that provide an access layer to the search engine is also a good decision, because it will be running outside company's network.

What do you think about it? Is a good approach or do you have some alternatives must be considered.

Thank you in advance.

Answer 1

It's never ending debate anyway. Here is my humble opinion:

• The web services do allow a loose coupled architecture. With RMI, you have to compile everything even if there was smallest change (because of class serial UUIDs and whatever).
• WS allow easier coexistence with other enterprise components (ESB, SSO, Identity Management, load balancing, security filters, security certificates) as HTTP is underlying network protocol.
• Reflection in RMI (and in EJB) seems to be more expensive than HTTP protocol itself.

If you are thinking of EJB as more suitable for application server environment and easyer to compare with WS and CORBA according your article, (EJB supports transaction management, bean management; WS have WS+ extensions (security, transactions)):

• EJB are slower than WS according article: Remote EJB is 3x slower than WebService in 7.1
• when compiling/building EJBs we had to use exactly same version of application server including patches on dev and production to avoid dubious production run-time errors (this only looks easy - production (datacenter) team doesn't always say which patch they have, when we make fixes for application we always have to re-ask exact version of server).
• partial fixes of application are not so easy, if EJB is rebuilt due to small fix, client jars has to be rebuilt, therefore applications that use client jars needs redeployment.

(These were problems from my experience, maybe other people were more lucky)

I would conclude that WebServices are more flexible, use less reflection, and hopefully faster if designed carefully. If RESTful is used in MVC controller as result, ESB can help with both offering transformations (less code, just transform) and security injection straight into HTTP headers (e.g. ivheader, ivgroup - if using ibm web seal, Tivoli access manager). Using SAML XACML is possible only when using WS as assertions work with XML. Therefore for distributed and dislocated enterprise applications WS are more flexible due to above mentioned.

Article you refer says that WS have no transactions but only proposals. The article is wrong or too old. See OASIS WSAT 1.0 and WSAT 2.0. Microsoft, JBoss, Oracle and few others support technology out of the box in their application servers. Apache Metro seems to support it was well (please verify).

Answer 2

RMI can be tunnelled over HTTP (see here), so don't let that influence your decision too much.

If both ends can talk RMI, then RMI is probably what you should use; it's a lot easier to get working than a web service.