the significance of java RMI please? [closed]

Question

Why do people use RMI, or when should I use RMI? I read those tutorials about RMI on oracle's website. But it doesn't provide enough practical examples.

To my understanding, software should have its modules as "unrelated and separated" as possible. RMI somehow seems to be an example of high coupling to me. Why is this not a bad coding practice? I thought the client should only fire instructions, whereas all the actually manipulations of the object were done by the server.

Curvaceous

Any technology is going to suffer from some form of coupling. You could chose to use sockets directly, that's a form of coupling - or HTTP or FTP - you've narrowed yourself to the capabilities of protocol. RMI is A solution, one that was designed to allow the transfer of objects and object states, without the need for a translation layer. If you only need to communicate with with other Java services, RMI isn't a bad solution. If, however, you need to (or you service wants to) communicate with other languages, then there are other choices available. It will depend on your requirements. – Margaritamargarite

This is what it was designed for, but it is not what it actually accomplishes. The dream of transparently searializing arbitrary object graphs is long dead and gone. What RMI actually promotes is embarassing amounts of boilerplate, called Data Transfer Objects, which in effect simulate document-oriented interprocess communication, but at a ridiculous cost. – Appassionato

Good question @Will. Keep asking those kind of questions throughout your career to identify all these bullshit technologies that exist only because some marketing guy thought it was a good idea – Barehanded

IMO, the best badge you can get for a question is that it was closed as not constructive :D – Barehanded

Answer 1

You really should not be using RMI for any application you build today, basically for the reasons you just laid out.

In some cases (diving into legacy or "enterprise" applications) you just have no choice.

However, if you are starting a new project, other options are:

REST + JSON over HTTP

The de-facto standard for communicating to remote services. The biggest advantage it has it that it is lightweight and easy to grasp the concept.

In theory it should require more work than RMI because you have to manually craft the available URL's, accepted verbs in each URL etc. In practice, I would say that RMI's boilerplate does not really help anybody.

Sticking with java, Jersey is a brilliant library to write your own RESTful web services.

If you want a batteries included solution for RESTful web services with java, Dropwizard by the nice guys at Yammer gives you a full server and framework ready to just plug in your business logic, and provides logging, database connectivity, serialization, request routing, and even metrics gathering out of the box.

SOAP

The previous standard for communicating to remote services. Unless you have a reason to use it, I would stick to REST.

Thrift

Thrift will create a client and a server stub, basically doing much of the work. The communication is in an efficient binary protocol. It's gaining popularity in the Java world as it is used by many open source projects in the "Big Data" field. Examples, Cassandra, HBase (switching to Avro). Scrooge is a twitter project to create idiomatic thrift stubs for scala.

Akka actors

Akka is framework that implements the Actor model for Scala and Java. Includes provisions for inter-service communication, and takes care of many of the details under the hood. I

---

Depending on your needs, some will be more suitable than others.

Hillside

Updated my answer to show that sometimes, there is no way around it :) – Hillside

If i want to build a client-server application where client and server are written in java. Should i also use REST, JSON ? – Goddard

Even if your client and server are written in java, I would still stick with HTTP + JSON. What if, some time down the line, you want an Android or iOS app? What if you need to expose the service to another service not written in Java? Even if you will never need to do any of those, RMI is a pain, its basic premise is flawed and I would not use it. – Hillside

Answer 2

Any time you have a function that requires some large centralized computing power or some expensive resource (a huge database for example), but your output needs to be many places where such a workload can't be deployed then you would look at Remote Method Invocation. Consider the web, you don't have a copy of Google on your desktop for any search you may want to compute, you remotely invoke Google's servers the instant you want a result. RMI is a protocol/system for distributing your application across servers and separating out clients that need access to the results of that code.

RMI can also act as a way to secure aspects of your application (like a proprietary algorithm). RMI is not the only approach, you can also use HTTP, SOAP, etc. Many of these other approaches offer other things like true language transparency, easier and more efficient implementations, and better decoupling.

Here is the stated goals of RMI from the documentation

The goals for supporting distributed objects in the Java programming language are:

• Support seamless remote invocation on objects in different virtual machines
• Support callbacks from servers to applets
• Integrate the distributed object model into the Java programming language in a natural way while retaining most of the Java programming language's object semantics
• Make differences between the distributed object model and local Java platform's object model apparent
• Make writing reliable distributed applications as simple as possible
• Preserve the type-safety provided by the Java platform's runtime environment
• Support various reference semantics for remote objects; for example live (nonpersistent) references, persistent references, and lazy activation
• Maintain the safe environment of the Java platform provided by security managers and class loaders Underlying all these goals is a general requirement that the RMI model be both simple (easy to use) and natural (fits well in the language).

Disapprove

Sry, your post sounds way too positive about RMI. Voting you down to emphasize the skeptic voices from the other answers – Barehanded

If I could talk to my 2013 self I would have said mostly the same thing :) – Disapprove

Haha, made my day :D – Barehanded

Answer 3

You are right, RMI is an example of way too-tight coupling between the service provider and service consumer. And it's even worse than it looks like at first glance: you never know what exception you may get pushed to the client side, resulting in a ClassNotFoundException that masks the real error that occurred. RMI, and similarly, EJB, are technologies of the past, a past which believed in the delusion of "transparently distributed objects".

Today's remote services are based on the complete opposite of RMI's approach: REST and JSON.

Appassionato

Answer 4

RMI is for exactly the opposite case, where you want tight binding, so tight as to appear to be a local method call. If you don't want that, don't use it. The whole RPC paradigm isn't for everybody, including me, even though I wrote a book on RMI, but every tool has its uses. Java EE is built on the RMI model for example.

Counterclaim

> 'Java EE is built on the RMI model' that sounds a bit debatable. I mean, Java EE consists out of many parts and most of them have nothing to do with RMI. Even EJB that originally was build as a higher level RMI abstraction nowadays rarely uses it, up to the point that the Java EE sped lead has proposed to remove it completely. – Exasperate

@ArjanTijms OK, was built on the RMI model, at least as far as EJBs are concerned. Still a very major piece of work with until numbers of deployments. I'm not aware of the proposal you cite: do you have a reference? – Counterclaim

at least as far as EJB are concerned - that's already a bit more accurate ;) Again, Java EE is much more than just EJB. Anyway, this is the reference: java.net/jira/browse/JAVAEE_SPEC-16 it's part of pruning CORBA, and as collateral the entire @Remote and thus RMI/IIOP is on the table for pruning. – Exasperate

@ArjanTijms Broken link. – Counterclaim

yeah, all those links broke :( New one is here: github.com/javaee/javaee-spec/issues/16 – Exasperate

@ArjanTijms You are completely misrepresenting the situation. The proposal is to remove the requirement for CORBA interoperability. There is nothing in your link about removing it completely, or removing @Remote: the actual proposal, which meets with considerable resistance in your link, is to 'significantly simplify EJB remoting'; and the statement 'Current CORBA use is so small that it makes the most sense to prune CORBA support going forward' is pure speculation. – Counterclaim

Doesn't this count as a proposal of removing @Remote: " Implementations need not support remote EJBs at all"? – Exasperate

I don't see where Rest and Soap couple less tightly than RMI, only difference is, that RMI couples behind the scenes and has the compiler check the client-server interface whereas Rest and Soap make you couple and check in application code. If the client-server interface is not met in Json or XML it breaks your application, so you have to check everything in code or xsd. – Deathless

If I remember correctly, the RMI / DCOM binary communication protocols started to lose traction when the internet at large realized the greater flexibility and interoperability of using text-based format in data communication that passes through well-known accepted ports 80 and 443. This greatly reduced the need for infrastructure firewall configuration. This realization was realized when html was booming and CORBA was not gaining traction. – Whirligig

@typelogic Surely you mean HTTP, not HTML, but in general your comment reads like pure 1980s fact-free megatrending. – Counterclaim

@Deathless As this answer mentioned neither REST nor SOAP, and the comments on it ditto, and the question ditto, I fail to see the relevance of your comment. – Counterclaim

@Counterclaim the answer was about tight binding and I argued that RMI's binding is no more or less tight than the obvious alternatives. – Deathless

@Deathless It is considerably tighter than either REST or SOAP. For a start it defines the implementation language at both ends. – Counterclaim