Java RMI: Is Anyone Using This Commercially?

[Clayton Cramer]

I ask because I have been finding getting the Oracle Java RMI example working (reliably) astonishingly difficult -- and I can't find any recently published books on the subject. The absence of recently published books could mean that it is so simple that there is no need for them, but I also see that the problems that I am having about security appear in vast numbers of web pages.

So, is anyone developing any commercial products using Java RMI, or is everyone just using this for school projects?

[Paul Clapham]

(Puts hand up)

Well, actually we have an RMI project which we use where I work. And it's being developed in the sense that we add more request/response types to it as the need requires.

However it was written about ten years ago. If we were going to implement the same functionality today, we wouldn't use RMI. If we had IBM come in and advise us about what we should do today (as they did back then) they would probably tell us to use Web Services with some heavy-duty architecture, but if it was my decision I would use something simple like REST web services.

[Pat Farrell]

It is astonishingly difficult. But your question is a bit too broad to get useful feedback.

Of course, there are design cases where RMI makes sense. So you will find "anyone" out there. What you won't find is many people chosing to use RMI. It is obsolete in general.

Ask instead things like:

1) what design cases make sense to use RMI?
2) what do people use instead of RMI?
3) is RMI still a mainstream technology?


What you will find is that RMI is taught as if it were still a mainstream technology, which it was back in 1996. Today, it rare to use it.

Rather than using distributed objects and remote invocation of methods, modern designs simply pass messages of data (often using REST) and
then process the data, and return response data.

[Ivan Jozsef Balazs]

RMI still might be used under the hoods between the parts of an application server.

[Pat Farrell]

Ivan Jozsef Balazs wrote:RMI still might be used under the hoods between the parts of an application server.

"might" being the operative word here, with "still" being second most important. For legacy applications, I'll believe anything might be there. But RMI has no place in modern software.

[surlac surlacovich]

Pat Farrell wrote:
"might" being the operative word here, with "still" being second most important. For legacy applications, I'll believe anything might be there. But RMI has no place in modern software.

RMI is JVM specific kind of IPC. I thought that RMI less redundant (for example if we compare RMI call and web-service call) than sending a message to another JVM. Please put me right if I'm wrong.

[Pat Farrell]

surlac surlacovich wrote: I thought that RMI less redundant (for example if we compare RMI call and web-service call) than sending a message to another JVM.

What do you mean by less redundant and why is that good?

The whole concept of remote method invocation, remote objects, etc, which is what RMI and CORBA are built to provide are obsolete. They were tried and failed to deliver much in the way of effective engineering. Modern systems pass messages. There are lots of ways to send the messages, and a good implementation will isolate the application from the details of how the message is delivered. Messages can be simple text, or JSON or any of a number of similar and simple formats.

Large scale systems must be able to be deployed in any of a number of physical boxes, from everything on one box, to thousands of boxes scattered all over the world. You can't rely on any implicit knowledge of the JVM, which machine it the JVM is on, how many JVMs are in use, etc.

[Stefano Rossi]

Rather than using distributed objects and remote invocation of methods, modern designs simply pass messages of data (often using REST) and
then process the data, and return response data.

If I don't want or can't use a web application server / container in my client-server application, what viable alternative to RMI(or CORBA) do I have to exchange message as you suggest?
Apache River? Apache Thrift? some JMS implementation?

[Pat Farrell]

Stefano Rossi wrote:If I don't want or can't use a web application server / container in my client-server application, what viable alternative to RMI(or CORBA) do I have to exchange message as you suggest? Apache River? Apache Thrift? some JMS implementation?

What do you mean, precisely, by client-server application? For the past decade, the general definition of client server is a browser application showing HTML with CSS and Javascript, talking HTTP protocols to a webserver. For these applications you can NOT use RMI or Corba because you can't get anything besides HTTP through corporate firewalls. If you mean something else, please elaborate.

Messages between a browser and a webserver are done using POST or GET

This really deserves its own topic and thread.

[Stefano Rossi]

What do you mean, precisely, by client-server application? For the past decade, the general definition of client server is a browser application showing HTML with CSS and Javascript, talking HTTP protocols to a webserver. For these applications you can NOT use RMI or Corba because you can't get anything besides HTTP through corporate firewalls. If you mean something else, please elaborate.

Sorry for being unprecise, what I mean, for instance, is a Swing GUI running on a client, which need to communicate across a network (LAN) to an application server which expose some service/method, (e.g to access data).
If I dont wan't that server to be an http server, so I can't use web services, I think that RMI is still a good solution.
I was asking what alternative does the market offers today?
or, as you said

2) what do people use instead of RMI?

I'm asking cause I've happily used RMI in the past and I'm about to start a new project which may require something similar, not to polemize.
regards.

[Pat Farrell]

Stefano Rossi wrote:If I dont wan't that server to be an http server, so I can't use web services, I think that RMI is still a good solution.

RMI is still obsolete, even in your case.

Its an engineering tradeoff, but I see no reason not to have the application server be an HTTP server. You may alway change your mind and not want the Swing client, and if you are already an HTTP server, you are done.

2) what do people use instead of RMI?

You send messages. Most of the time, I send messages that are human readable ASCII. Often in CSV format. Sometimes JSON is a good message format. The key is that you stop the whole "remote object" philosophy. You don't need it, you don't need the complexity.

Your application programmer should not care about how the messages are delivered, that is a very low level detail. Things like any of the many reliable message queueing and delivery systems are suitable. Provide a local API that your application programmer calls, all you need are two functions: send() and receive()

[Jayesh A Lalwani]

RMI doesn't really compare to HTTP. RMI operates at an object level, whereas HTTP is operating at the message level. Or to put it in other words, with HTTP you are passing messages around, whereas in RMI you are passing objects around. When you make an RMI call, RMI manages transporting not only the object but also the definition of the object. It will also take care of remotely classloading the objects being passed. If you are implementing a service that exposes a web service interface, you are introducing a limitation:- The interface is fixed. The client and the server should have an agreement on the interface. You cannot just implement a new class on the client, and pass an object of that class to the server over HTTP. HTTP doesn't provide that service. RMI does. You can think of RMI has a layer over HTTP or IIOP with HTTP/IIOP providing the raw transport of messages, and RMI providing advanced functionality like remote class loading and method invocation. For most applications, you don't need these services, which is why web service frameworks (SOAP, REST) do not provide that functionality.

In distributed computing world, OTH, the idea of having a a RPC that passes Java objects around is not dead. It's alive and well. If you are building a framework that can distribute tasks over a grid of JVMs, you really don;t want to deploy the classes every time you implement a new kind of task. You need to be able to dynamically load classes as they appear on the grid. However, what has happened is that different frameworks have implemented their own RPC rather than use RMI. Hadoop uses it's home grown Hadoop IPC. I believe even Gridgain folks implemented their own thing. I know Gigaspaces uses JINI, but they have their own implementation of a lightweight RMI

RMI might be dead, but the problem that RMI was trying to solve is not. Most developers don't need to worry about it though

[Pat Farrell]

Jayesh A Lalwani wrote:For most applications, you don't need these services, which is why web service frameworks (SOAP, REST) do not provide that functionality.

Is SOAP still alive? It seemed to have its own problems, so much so that they changed the name. Originally, the S in Soap stood for Simple, and SOAP was anything but simple.

The idea of passing objects and doing remote method invocation has some initial appeal. It could be cool, but the practical implications of it greatly outweigh the cool factor. I have not seen any applications that need those services. I have seen some that thought they needed them. I'd be interested in a real world use case where remote method invocation is actually justified.

[Jayesh A Lalwani]

Pat Farrell wrote:

The idea of passing objects and doing remote method invocation has some initial appeal. It could be cool, but the practical implications of it greatly outweigh the cool factor. I have not seen any applications that need those services. I have seen some that thought they needed them. I'd be interested in a real world use case where remote method invocation is actually justified.

Like I said in my previous post, grid computing frameworks use RPCs under the hood heavily. They need to pass class definitions around and class load the objects remotely. Like I was saying, if you have a general purpose grid computation framework, you don't want your clients to deploy jars everytime they change them. They have to be able to deploy it one places, and automagically have them appear on all machines on the grid.

Hadoop uses it's homegrown IPC for it's internal signalling, although I am not sure if they classload user objects in the IPC. Gridgain allows you to put an annotation on a method to indicate that the method should be executed remotely. Behind the scenes, Gridgain passes the class definitions of the call that has to execute on the grid, along with any other classes that the function needs, to the worker JVM. Gridgain implemented this on their own, and decided not to use RMI. Gigaspaces has this notion of firing events (like in JMS), and executing tasks remotely(like in Gridgain). Behind the scenes, it uses RMI to send events/tasks to the grid.

Yes, all 3 are very specialized applications living in a very niche part of the industry. 95% of developers don't work in grid computing, and the rest of 4.99% that do usually build on one of these frameworks, so the complexity is hidden under the hood. For the few developers who are building these frameworks, it's important to understand RMI, even if they don't use it.

[Ulf Dittmer]

SOAP is simple. What's not simple is all the frameworks and standards that have grown all around it.

[Pat Farrell]

Ulf Dittmer wrote:SOAP is simple. What's not simple is all the frameworks and standards that have grown all around it.

Now, we are way off topic.

Java is simple. What's not simple is all the frameworks that have grown around it in efforts to solve real world problems. J2EE is a classic disaster. Applets another.

[Ulf Dittmer]

Pat Farrell wrote:Now, we are way off topic.

Not really. In a discussion of RMI, SOAP comes up naturally. Applets, Java in general and J2EE in general would be off topic.

[surlac surlacovich]

Pat Farrell wrote:
What do you mean by less redundant and why is that good?

I mean size (in bytes) of RMI "call" that pass through network. I suspect SOAP message will be much more verbose that RMI call from network traffic standpoint (thus slower from speed standpoint). Is this true?

[Pat Farrell]

surlac surlacovich wrote:I mean size (in bytes) of RMI "call" that pass through network. I suspect SOAP message will be much more verbose that RMI call from network traffic standpoint (thus slower from speed standpoint). Is this true?

First, I would never use this as a criteria for engineering a solution. In a world of gigabyte ethernet, whether a message is 200 bytes or 400 bytes is irrelevant.

Second, one does not engineer based on suspections. If you care about message size, you should measure it.

Third, I was not suggesting using SOAP, others did. I recommended a simple ASCII message.

If you need to pass messages, do so. If you think you need remote method invocation, you need to justify it before you engineer to it. I believe, IMHO, etc. that you will never justify remote method invocation.

[surlac surlacovich]

Pat Farrell wrote:If you care about message size, you should measure it.

Thanks Pat, very good suggestion. A little bit off topic: what do you personally use to measure message size? Some application that can observe the socket and count traffic passes through it.

[Marilyn de Queiroz]

Jayesh A Lalwani wrote:
In distributed computing world, OTH, the idea of having a a RPC that passes Java objects around is not dead. It's alive and well. If you are building a framework that can distribute tasks over a grid of JVMs, you really don;t want to deploy the classes every time you implement a new kind of task. You need to be able to dynamically load classes as they appear on the grid. However, what has happened is that different frameworks have implemented their own RPC rather than use RMI. Hadoop uses it's home grown Hadoop IPC. I believe even Gridgain folks implemented their own thing. I know Gigaspaces uses JINI, but they have their own implementation of a lightweight RMI

RMI might be dead, but the problem that RMI was trying to solve is not. Most developers don't need to worry about it though

We have a distributed application (at IBM) that still uses RMI in production. It is about 8 years old.

[surlac surlacovich]

RMI as a technology still evolute or forbidden? I mean is there any modifications/fixes in the new versions of JDK?

[Ulf Dittmer]

RMI has come to an evolutionary dead end some years ago.

[Mr. C Lamont Gilbert]

I have used message passing. In fact, message passing predates RMI. I found the idea of remote objects much easier to work with than messages. As someone that oversees communication, I'd rather pass the objects. I would pass messages only when the bandwidth was limited or some other efficiency reason.

Exactly why is RMI and object passing viewed as dead in an OO world? Or are you suggesting we are pulling back from the OO concept to some degree?

[Pat Farrell]

Mr. C Lamont Gilbert wrote:Exactly why is RMI and object passing viewed as dead in an OO world? Or are you suggesting we are pulling back from the OO concept to some degree?

We are saying that remote object passing and remote method invocation was considered a good idea in the mid 1990s, and in practice we have found that it is not a good idea. Message passing is simple and easy to understand. Passing objects means that there are tons of issues with variable marshaling, object versions, etc. that add complexity and bring no benefit to the design.

It has nothing to do with general OO concepts, they are well loved and widely used.

Long term, I predict that OO will be replaced by something new, as sequential programming doesn't scale well to multi-CPU systems. These days, even ordinary cell phones have quad core processors.

[Mr. C Lamont Gilbert]

You seem to feel very strongly this way but you haven't really given any reasons. Can you provide any imagined example of how passing a message is superior to passing an object?

[Jayesh A Lalwani]

Again, people are mixing concepts here. RMI is not passing objects. RMI is Remote Method Invocation. The idea behind RMI was that objects should be able to call methods on objects that are hosted by remote JVMs. The RMI protocol itself doesn't care how the parameters are passed. Internally, you could serialize the java objects OR you can marshal them as SOAP messages or JSON objects. RMI operates at a layer above HTTP. IIRC, there was some effort to have an implementation of RMI that works over HTTP, although I don't exactly know what came of that.

[Pat Farrell]

Mr. C Lamont Gilbert wrote:You seem to feel very strongly this way but you haven't really given any reasons.

You seem to have strong opinions here, and you have failed to read the reasons that I've already given.

With RMI, you have to marshal the data, because the concept of a remote object is a facade. You actually transmit the data between hosts and then execute the same code on each end of the connection. Marshalling is a complex process and its easy to have problems with it. The bigger problem is that changes to the object version have to be coordinated to all uses.

[Mr. C Lamont Gilbert]

I haven't offered any strong opinions. Just one anecdote that working with objects has been easier for me than with messages. Mostly I have been asking why because I can't understand your position.

I think it holds for any protocol that if you change it, both ends will require knowledge of that. I don't see how a message structure can deal with this more easily than an object structure.

[Pat Farrell]

Oh, its easy to make messages handle different versions.

The problem with RMI is that the objects must be identical. They are compiled with the 'rmic' into stubs.

With a message, all you have to do is pass a version number, say as the first field, and then write your code to read the version number and dispatch to the right code. The cool thing about this is that once you have the version number 1 code, you can ignore changes until you really need version 2. And you can be sure that you will have a version 2.

[Jayesh A Lalwani]

Whoa! Pat. When did you last read about RMI? From J2SE 5.0 RMI release notes

Dynamic Generation of Stub Classes
This release adds support for the dynamic generation of stub classes at runtime, obviating the need to use the Java(tm) Remote Method Invocation (Java RMI) stub compiler, rmic, to pregenerate stub classes for remote objects. Note that rmic must still be used to pregenerate stub classes for remote objects that need to support clients running on earlier versions.
When an application exports a remote object (using the constructors or static exportObject methods1 of the classes java.rmi.server.UnicastRemoteObject or java.rmi.activation.Activatable) and a pregenerated stub class for the remote object's class cannot be loaded, the remote object's stub will be a java.lang.reflect.Proxy instance (whose class is dynamically generated) with a java.rmi.server.RemoteObjectInvocationHandler as its invocation handler.

[Mr. C Lamont Gilbert]

Pat Farrell wrote:Oh, its easy to make messages handle different versions.

The problem with RMI is that the objects must be identical. They are compiled with the 'rmic' into stubs.

With a message, all you have to do is pass a version number, say as the first field, and then write your code to read the version number and dispatch to the right code. The cool thing about this is that once you have the version number 1 code, you can ignore changes until you really need version 2. And you can be sure that you will have a version 2.

So you changed the version number sent by the server. Then you also changed the client to evaluate the version number? You changed it on both ends? How is that different? Not to mention you can always add more objects. Say, a version "2" of a particular object. Its all the same to me.

[Pat Farrell]

Jayesh A Lalwani wrote:Whoa! Pat. When did you last read about RMI?

Long ago, last century. Its been obsolete at least that long.

[Mr. C Lamont Gilbert]

Pat Farrell wrote:

Jayesh A Lalwani wrote:Whoa! Pat. When did you last read about RMI?

Long ago, last century. Its been obsolete at least that long.

This is clearly your very strong opinion. I don't know what the industry is doing so I can't argue with you. Still, I have not been given any reason why RMI would be obsolete. Certainly not replaced by something like message passing.

[Paul Clapham]

Mr. C Lamont Gilbert wrote:I don't know what the industry is doing so I can't argue with you. Still, I have not been given any reason why RMI would be obsolete.

But "obsolete" refers pretty specifically to what the industry is doing. It doesn't matter whether technology X is useful or practical, if the majority of designers have decided that they would rather use some other technology then that means that technology X is obsolete. Remember that technical decisions aren't made primarily on the basis of technology, they are also made based on a context. So once a technology starts to fall out of favour, fewer designers will use it, and then other designers will notice that it is being used less and therefore decide not to use it.

[Mr. C Lamont Gilbert]

I haven't said that it isn't obsolete. I've only asked why. Perhaps the answer is as simple as people just didn't get it or wanted something different. I can't change that. But I'm having trouble with the idea that message passing is superior. Could be, but I don't see any reason why. I don't mind learning a new technology. If there is something superior I'd like to try it out. But I certainly would not do that just because the guy sitting next to me did it. Kinda of a weak reason for a technical person to make a choice.

[Paul Clapham]

And that's what I said. It's obsolete because people have decided it's obsolete. You still seem to be stuck on the idea that technical superiority has something to do with that.

You may not think that "Most people do X instead of Y" isn't a good reason to choose X, but in fact it is. By choosing X instead of Y you have more people to ask questions of when you run into problems, you have more chances that bugs in X will be fixed in a timely fashion, and it's more likely that X will be improved in the future. Those may not be "technical" reasons in your mind but they are reasons which you shouldn't dismiss.

[Tim Holloway]

RMI is much more efficient than things like SOAP, REST, and AJAX, and unlike the web-based technologies, it can be configured in callback mode so that conversations can flow in both directions.

I was using RMI in the mid-2000's in order to dissociate a very-long-running process from my webapps. For that particular task, if I had it to do all over again, RMI would probably still be my choice.

More recently, I worked with a client who'd had a really wonderful application developed circa 1998 in CORBA, back when everyone was required to have 15 years CORBA experience. I felt sorry for him, because CORBA is effectively dead.

Neither CORBA nor RMI are good technology choices over the open Internet. CORBA, in particular, was hostile to firewalls, since like Microft's CORBA-era DCOM, it did not listen in on a fixed port, so setting up firewall rules was virtually impossible, Somewhere around 2005 an effort was made to make CORBA more firewall-friendly, but it was too late. Everyone had jumped on the AJAX bandwagon.

RMI is much easier to work with in a firewall environment, but its performance comes with some serious limitations. First, it's a binary protocol. Most of the successful Internet protocols are text based, for a number of reasons. Secondly, I don't recall it having much in the way of actual security, so it would be at risk for SQL Slammer-style attacks on the open Internet. Third, the binary protocol (actually, the serialized object format) is extremely dependent on the version of Java you are using. Using mismatched client and server Java versions doesn't work. Fourth, the rule of the day is tying multiple system products together, and not all of them may be Java. RMI, unlike CORBA, requires both sides of the conversation to be Java (and, as I mentioned, compatible versions of Java).

CORBA, incidentally, used to be used extensively in certain Linux desktop architectures, but has since been supplanted by mechanisms such as dbus. That's going beyond the extent of this topic, though.

So, in sum, if you need Java-to-Java high-performance connectivity in-house, RMI may be a good fit. Possibly, even remote EJBs, since these days they use RMI-IIOP. However, for more general cross-communications or things like store-and-forward or other message-based communications, it's not what you'd want.

[Mr. C Lamont Gilbert]

Nice summary. Only disagree with the RMI requiring the same java version on both ends part. I went to 1.5 on the server because it offered nice enhancements over 1.4. The client however stayed 1.4. I'm not needing pregenerated stubs and skeletons though.

[surlac surlacovich]

Thanks Tim. So RMI has better performance because it's binary? I mean every method that needs to be invoked requires less network traffic, no need to process incoming/outgoing messages (like in case of SOAP messages; only native Java serialization/deserialization), thus works much faster.