Java: RMI vs Web Services

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. B开发者_开发知识库ut, 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.

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.

Be careful here, I developed a similar solution recently and found that sockets were the most efficient and perfomant way to transfer files, while RMI was good for simple method calls (like queries). I also had a hard time setting up RMI, the configuration can be confusing sometimes and there is not much documentation out there on the subject.

I certainly believe RMI will give you better performance over web services; but web services will probably be more maintainable and flexible for future requirements.

What makes you think that RMI is faster? From my experience, it can be slow, difficult to configure, difficult to secure and generally unpleasant to work with.

Since web services are generally just XML over HTTP, you can generally architect a solution that will scale better.

If the API you want to support with the service does not map nicely to HTTP, I would probably choose for RMI (but beware of unnecessary roundtrips.)

If it does map onto HTTP nicely, I would chose to go with REST which is essentially HTTP Servlets implementing your API as actions. If most of the traffic is the uploading / downloading of the files you mention combined with a few API calls, this is probably the way to go.

Btw, your experience that RMI is faster than web-services coincides with mine. (Both can be implemented with slow performance as a result, mainly to do with roundtrips in a poorly designed API.)

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).

RMI is basically for small applications . Yes it is faster but over the time you will feel that in order to do more enhancement in your application when the traffic increases , webservice is more maintainable than RMI and if you choose REStFull webservice that will be the best option.

Thanks