This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Actually, the stub is just a dumb network object that sends the requests across the network to the skeleton, which in turn invokes the method on the actual instance. The instance does all the work, the stub and skeleton just pass the method identity and arguments back and forth across the network.
So, I don't understand how the stub can be passed as an argument.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Joined: Nov 01, 2004
Well, from the point of view of the client, the stub is the remote object.
If I am a client a have a remote stub for remote object A and a remote stub for remote object B, I can pass B to one of A's methods.
B b = getB(); //returns a stub with remote interface B A a = getA(); //returns a stub with remote interface A. a.someMethod(b); //see, here the class of object referenced // by b is a stub implementation: the stub is what //is passed and the stub is what is sent.
On the other hand we could do this:
B b = new SomeClassThatImpelentsRemoteInterfaceB(); export(b); //somehow exports b. This instantiates the stub and makes //it available to the rmi runtime. Note, b is not a reference //to the stub; it is a reference to the actual remote object.
a.someMethod(b); //the object referenced by b (the actual remote object) //is replaced by a stub for the remote object and then sent //over the wire after serialization.
BUT, if b is not exported and SomeClassThatImpelentsRemoteInterfaceB also implements Serializable, the the object referenced by b not be replaced by a stub: it itself will be serialized and sent. At least, that's how I think it works.
The Stub and Skeleton are both references between the client and server [i.e. remote] objects. They are not passed between networks, as the above thread suggests, but are simply used to distribute messages to the correct remote object or returning to the correct invoking client object.
I am assuming that the question related to RMI-IIOP and not RMI-JRMP. The differences are that IIOP can support pass-by-reference and pass by pass-by-value while JRMP supports pass-by-value. JRMP was the original Sun venture into distributed objects but CORBA became an industry standard and Sun decided to extend RMI to use the IIOP extension.
With pass-by-value; a new copy of the remote object is created on the remote server and it modifies the object as requested.
With pass-by-reference; the remote server receives the reference to the original object on the remote server (i.e. not a copy as in pass-by-value)so any modifications are made to the original not a copy of the object.
When using RMI-IIOP and using primary types as arguments they are passed-by-value but when using an object (e.g. DTO or VO) this is passed-by-reference - so long as it is serialised.
Hope this helps!?
Ian Roberts<br />Application Architect<br />SCJP, SCJD, SCEA, OCUP Fundamental
I assume the question refers to IIOP since this is what the EJB containers use.
But as I recall, JRMP is pass-by-value and pass-by-reference. RMI-IIOP also supports both.
Stubs must be passed over the network. What happens when you use JNDI to look up a home interface? You, the client, are getting a stub. Also, the client can have a reference to a stub. You can pass this stub around just like anyother object.
Now that I think about it there are several cases to consider. Assume you have a remote method "void doSomething(Object z) throws RemoteException"
You, the client, calls doSomething and pass in an object z. I'll take an educated guess at the result: I haven't actually tried out all these scenarios. Let me know if something is inaccurate.
1) The class of z does not implement Serializable or Remote. Result: runtime exception.
2) The class of z does implement Serializable but not Remote. Result: z is packaged into a stream of bytes and sent over the wire to the remote object.
3) The class of z implements Remote, but is not Serializable. Futhermore, z has been exported as a remote object in this JVM. Result: a stub is created by the rmi runtime and sent over the wire.
4) The class of z implements Remote, but is not Serializable. Futhermore, z has NOT been exported as a remote object in this JVM. Result: a runtime error?
5) The class of z implements RemoteStub. Result: z is Serialzed and sent over the wire. If it implements RemoteStub then it is a stub object, which is Serializable.
The following scenario is why the original question is misleading:
6) The class of z implements both Serializable and Remote. 6a) z has been exported by to the rmi runtime. Result: Send stub over wire. 6b) z has NOT been exported to the rmi runtime. Result: z is itself serialized and sent over the wire.
Joined: Nov 01, 2004
"When using RMI-IIOP and using primary types as arguments they are passed-by-value but when using an object (e.g. DTO or VO) this is passed-by-reference - so long as it is serialised."
Not sure I understand this quote. A DTO is passed by reference? If it's serialzable shouldn't that be "pass-by-value"?
Joined: Dec 16, 2004
There is very good book called "Mastering Enterprise JavaBeans" that I would recommend anyone wanting to take the SCEA to reference.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com