RMI server does not make unmarshalling from client _Stubs!!!
Hello,
When I pass java.rmi.Remote object from client to server as a function parameter or as a field of Serializable object, server DOES NOT make unmarshalling of the _Stub object into it's server implementation!!!
That means the server instead of using native object instances, accesses them through _Stub proxies the same way a client does! And every _Stub call loads the network and processor (by serializing and deserializing of parameters)
Do I something wrong? I always thought that _Stubs are only reflected at client side and server must always operate with native objects.
Anton
[620 byte] By [
throwablea] at [2007-10-1 23:54:31]
Hi Anton,
When you use the terms 'client' and 'server' you are using them in the context of your high-level application architecture. That is OK, but RMI doesn't know anything about that.Your architecture appears to RMI as peer-to-peer, while you think of it, also correctly, as client/server.
Assuming I understand your question correctly; let me try to explain some RMI basics.
In RMI; any VM that passes a remote reference to one of its objects to another VM is a 'server'. Correspondingly; any VM that uses a remote object reference is an RMI 'client'.
If you want an object to appear local to the VM receiving it, client or server, do not use Remote, simply make sure the object is serialisable.
John
https://cajo.dev.java.net
cajoa at 2007-7-15 15:46:21 >
No, this is how it is supposed to work.
ejpa at 2007-7-15 15:46:21 >
Thank You for your ansewer but I mean a little other thing.
As I understand objects in RMI are separated to two classes: Remote and Serializable. Serializable objects are symmetrically in both sides and used as local objects. Remote objects are asymmetrically and have the implementation that hosted as local object in one side (I call it Server) and proxy _Stub that used by remote system (I call it Client).
My problem may be explained in this sample:
We have Remote interface ServerControl that has methods:
Service getService( String path )
void stopService( Service service )
Service is a Remote interface too. Implementation instances of both interfaces ServerControl and Service are hosted locally in a server in the same VM.
Client receives an interface ServerControl through registry and then gets a Service instance via getService(). It receives _Stub proxy of Service.
Then client calls stopService( service ). What really receives server as a parameter?
I thought that it must be a real object that implements Service interface and hosted locally in server in the same VM (object that we returned by getService() implementation). But instead of it server receives serialized _Stub object of a Service. Well, it is logically when objects are hosted on different VMs, but inside the same VM it is more efficient to operate with local implementation of running objects.
Well, at least the RMI code works ;-)
Anton
OK, I think I know what you are asking Anton.
When you call stopService, your client is passing a remote stub as an argument. The server accepts it, and doesn't know that it is a remote reference to one of its own services, it thinks it could just as likely be a service reference from some other VM.
Perhaps you may want to consider putting the stopService method in the remote interface to Service. That way the client could shut the service down remotely by calling that, and would not need to pass the remote object reference back to the server.
John
cajoa at 2007-7-15 15:46:21 >
> Thank You for your ansewer but I mean a little other thing.
I understand what you mean but it's not how RMI works.
> Well, it is logically when objects are hosted on
> different VMs, but inside the same VM it is more
> efficient to operate with local implementation of
> running objects.
More efficient but it would violate the RMI specification if it worked that way, because arguments would get passed by reference instead of via deep copy which is what the RMI spec says.
(NB Lurkers, please don't let's have the discussion about whether there is pass by reference in Java again. It has always seemed entirely futile to me to distinguish between passing objects by reference and passing references to objects by value. Down at the silicon it is the same thing and semantically it is the same thing as well.)
ejpa at 2007-7-15 15:46:21 >
