S
Sony Antony
These are a set of questions, I have been trying to get answers to,
since yesterday. It will be very helpful even if you could answer them
partially.
1. In the case of ordinary ( JRMP ) RMI, every object that is passed
from the remote side to the client side, will have to go through
serialization
2. If the remote side returns a *non Remote* object that is actually
the subclass of the declared object, and if the class definition for
this subclass does not exist in the client, it will be sent from the
server side over the wire.
3. There is no mechanism in RMI to do a version control. ( Like
different versions of the same interface )
4. If the Remote interface is later changed to *add one more method*,
and if the server is recompiled to implement this method along with
all the old ones, the client will continue to work for all the methods
it was written for originally.
5. As described in the case 4. above, if the server is rewritten to
add one more method and if a reference to one such object is returned
from the server ( as a result of another method invocation ), the
client will get a stub object with only the old methods available. (
Since its class definition for the object only contains the original
methods )
6. In the case of RMI-IIOP, object serialization is not used at all.
Instead it uses CORBA's CDR encoding.
7. among JRMP & IIOP, which one is faster and efficient ( efficient in
terms of the number of bytes for the call overhead )
8. What is the relevance of RMI-IIOP. Does it exist only to bridge
with CORBA/other languages clients. Or does it serve any special
purpose in an EJB container's context. ( Is it only coincidental that
I started to hear more about RMI-IIOP about the time EJBs started to
become popular.
Thanks in advance
--sony
since yesterday. It will be very helpful even if you could answer them
partially.
1. In the case of ordinary ( JRMP ) RMI, every object that is passed
from the remote side to the client side, will have to go through
serialization
2. If the remote side returns a *non Remote* object that is actually
the subclass of the declared object, and if the class definition for
this subclass does not exist in the client, it will be sent from the
server side over the wire.
3. There is no mechanism in RMI to do a version control. ( Like
different versions of the same interface )
4. If the Remote interface is later changed to *add one more method*,
and if the server is recompiled to implement this method along with
all the old ones, the client will continue to work for all the methods
it was written for originally.
5. As described in the case 4. above, if the server is rewritten to
add one more method and if a reference to one such object is returned
from the server ( as a result of another method invocation ), the
client will get a stub object with only the old methods available. (
Since its class definition for the object only contains the original
methods )
6. In the case of RMI-IIOP, object serialization is not used at all.
Instead it uses CORBA's CDR encoding.
7. among JRMP & IIOP, which one is faster and efficient ( efficient in
terms of the number of bytes for the call overhead )
8. What is the relevance of RMI-IIOP. Does it exist only to bridge
with CORBA/other languages clients. Or does it serve any special
purpose in an EJB container's context. ( Is it only coincidental that
I started to hear more about RMI-IIOP about the time EJBs started to
become popular.
Thanks in advance
--sony