tags:

views:

1013

answers:

1

As I understand it, once I've set up an RMI communications link between two systems, I can pass an object that implements "Remote" into one of the remote methods that takes an object of that type and the far-end will just get the remote interface for the new object (in other words, it will become a new remote connection as opposed to just serializing the object over.)

Is this correct?

If so, I assume this has something to do with the method signatures--but I'd like to know exactly how it determines that it should create a new remote object instead of simply serializing the entire object.

This is really hard to put into words. Let me try this:

Let's say I have a client and a server system. On the server system I create and publish an RMI object, on the Client system I retrieve the interface and can interact with the Server system.

Client                            Server
Object1 RemoteIface     ----   Object1 Implementation

So far so good. On Client, Object1.remoteMethod() will execute on Server (after serializing over the parameters).

Now, here's the question, on the client I execute code like this:

Object2 object2=new object2(); // Also a remote object
object1.send(object2);

As I understand it, at that point, my system will have a new communications mechanism:

Client                           Server
Object1 RemoteIface    -----    Object1 Implementation
Object2 Implementation -----    Object2 RemoteIface

At this point, if the server calls a method on Object2, that method will actually be executed on the client.

I'm wondering at what point the system decides to do this rather than just serializing it (as it would with any non-remote object).

Or am I completely wrong and it just serializes it over and I need some kind of "getRemoteInterface()" method call to actually create the remote call?

+5  A: 

It's what's called the Proxy Pattern. The thing instantiated at the remote end has generated code to transfer values and activate methods.

java.rmi.Remote itself is just a "tagging interface". You need an implementation to do the actual work. Have a look at this JavaCamp tutorial for more.

Update: okay, going the other direction, yes, you need to serialize the object and pass if over the wire. Probably the best thing is to work through the Java Tutorial on RMI first. But, basically, Serializable is another tagging interface that tells Java the object is prepared to be turned into an internal string format, kind of like XML or YAML. That format can be "rehydrated" into a matching object at the receiving end so long as the class files for that object are available.

Charlie Martin
I'm not sure you understood. I'll try to rephrase it...
Bill K
It sounds like Charlie is interpreting your question just as I did, and is right on target with his answer. If you pass a parameter (or return an object) that implements Remote, a dynamic proxy skeleton is created, and endpoint information addressing that skeleton is sent (sort of like a "reference" rather than a "value"). At the receiver, a dynamic proxy stub is created to talk to the remote object. The decision to remote rather than serialize is based on the Remote interface.
erickson
Okay, It sounds like you did get it right and I just wasted a bunch of time rewriting my question. But could you be more explicit on the "RemoteInterface" part? If I simply cast it to the remote interface, will that cause it to separate the interface from the implementation, or does it have to pass through the method call?
Bill K
To put it in the opposite terms--what would I have to do differently to have it serialize the entire remote object over an existing remote method so it would send the entire thing rather than creating the skeleton? If I passed it as a Serializable instead of a Remote, would that do it?
Bill K
So I think I understand--It really is in how it is cast. Please correct me if I'm wrong, but if you have an object that is both Serializable and Remote, Passing it to a remote method that takes a Serializable will have a completely different effect from passing it to a remote method that takes a "Remote" argument. This makes sense but feels counter-intuitive since you'd think simply casting wouldn't have such a significant effect.
Bill K
Well, sorta. The tutorials can go through in much more detail, but an interface is a contract; if you *cast* to Serializable but haven't actually implemented it, you may get a surprise. In particular, you have to have a default ctor, one that doesn't require any arguments. Have a look at the interface javadoc: http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html But yeah, you have two choices: Remote, which constructs a proxy, and Serializable, which transmits a copy.
Charlie Martin