Why RMI Stub depends On Concrete Remote Class?

[narke]

i am learning rmi. after read the tutorial and specification, some
thing come up to confuse me: to get a stub, one on client has to rmic
from a concrete remote
class. this seems unreasonable since i think the stub should only
depends the remote interface instead of any underlying concrete class.

image the case that a client got a batch of servers to access (up to
the user choice in the runtime), each of those servers running a remote
object which implemented a common public interface. so in this
circumstance, one should reasonablly suppose that the client should be
cooperative with any server object for the simple reason that their
interface are same.

by the rmi specification, howver, a stub was generated from the
concrete remote class, so for n different remote classes, we simply get
n different stubs, and i consequencely have to put all those stubs on
the client side. is it true? Even i like to do so, i am afraid that the
Naming.loopup(...) will be confused for it would definitely find there
are so many stubs for an interface, how does it know which one should
to pick up?

-
narke/[email protected]

 

[Esmond Pitt]

i am learning rmi. after read the tutorial and specification, some
thing come up to confuse me: to get a stub, one on client has to rmic
from a concrete remote
class. this seems unreasonable since i think the stub should only
depends the remote interface instead of any underlying concrete class.

The application builder/deployer has to do this, not the client.

The reason the sub is generated from the concrete class is that the
concrete class may implement multiple remote interfaces. You really
don't want a stub per interface for such a class, you want a single stub
which has all the same remote methods as the concrete class.

image the case that a client got a batch of servers to access (up to
the user choice in the runtime), each of those servers running a remote
object which implemented a common public interface. so in this
circumstance, one should reasonablly suppose that the client should be
cooperative with any server object for the simple reason that their
interface are same.

The stub is just a proxy for the remote object and to the client appears
more or less the same.

If you are saying that you have multiple classes all implementing the
same remote interface I would only ask why. If the implementations are
all the same why have multiple classes, surely you would just export
multiple instances of the same class, or at the extreme just export a
single instance? If the implementations are different, why are they
different?

by the rmi specification, howver, a stub was generated from the
concrete remote class, so for n different remote classes, we simply get
n different stubs, and i consequencely have to put all those stubs on
the client side. is it true? Even i like to do so, i am afraid that the
Naming.loopup(...) will be confused for it would definitely find there
are so many stubs for an interface, how does it know which one should
to pick up?

Naming.lookup doesn't do this step. By the time an object is bound to
the Registry it is already a stub. The export step does the association
of class to stub: it has the concrete class, so all it has to do is add
_Stub to the class name.

 

[narke]

If you are saying that you have multiple classes all implementing the

same remote interface I would only ask why. If the implementations are
all the same why have multiple classes, surely you would just export
multiple instances of the same class, or at the extreme just export a
single instance? If the implementations are different, why are they
different?

i know it sounds a little weird, but our team is making a demostrating
app, every one in charge of writing a chatroom client and chatroom
server. to make sure every one coding correctly, on the final stage i
hope one's client program can call another one's server object (a
message board). all these runable message boards adhere to a same
interface defined in the first time.

Naming.lookup doesn't do this step. By the time an object is bound to
the Registry it is already a stub. The export step does the association
of class to stub: it has the concrete class, so all it has to do is add
_Stub to the class name.

but IMHO the Registry actually run on the server side, if you said it
is the registry who bound the remote interface with its stub, i would
deduce that it is the registry insteading of client object who need a
stub. this leads to another question: why we have to put stubs on
client side rather than server?

-
narke

 

[Remi Bastide]

narke wrote: ....

The stub is just a proxy for the remote object and to the client appears
more or less the same.

If you are saying that you have multiple classes all implementing the
same remote interface I would only ask why. If the implementations are
all the same why have multiple classes, surely you would just export
multiple instances of the same class, or at the extreme just export a
single instance? If the implementations are different, why are they
different?

This is called "Polymorphism" ...

 

[narke]

Is there anyone here can answer my question? Thanks.

i know it sounds a little weird, but our team is making a demostrating
app, every one in charge of writing a chatroom client and chatroom
server. to make sure every one coding correctly, on the final stage i
hope one's client program can call another one's server object (a
message board). all these runable message boards adhere to a same
interface defined in the first time.

but IMHO the Registry actually run on the server side, if you said it
is the registry who bound the remote interface with its stub, i would
deduce that it is the registry insteading of client object who need a
stub. this leads to another question: why we have to put stubs on
client side rather than server?

-
narke

 

[Esmond Pitt]

i know it sounds a little weird, but our team is making a demostrating
app, every one in charge of writing a chatroom client and chatroom
server. to make sure every one coding correctly, on the final stage i
hope one's client program can call another one's server object (a
message board). all these runable message boards adhere to a same
interface defined in the first time.




but IMHO the Registry actually run on the server side, if you said it
is the registry who bound the remote interface with its stub, i would
deduce that it is the registry insteading of client object who need a
stub. this leads to another question: why we have to put stubs on
client side rather than server?

You have to put them everywhere: client, registry, server, unless you
use the codebase feature.

 

[Esmond Pitt]

Is there anyone here can answer my question? Thanks.

I thought I did!

 

[narke]

I thought I did!

oh, sorry, i just thought i did not grasp your idea. did you mean
that: if A and B implemented an common remote interface X, so A.class
and B.class together with X.class are all required to put on both
client end and server ends?

If so, I am thinking about another question. supposing X has a method
, say X.m, which claims to return a object with interface RX. so, in
the implementation of A, which return a RX_A as concrete object while
the B returns RX_B. in this situation, do i also need to put both
RX_A.class and RX_B.class on the client end?

Regards,
narke

 

[Esmond Pitt]

oh, sorry, i just thought i did not grasp your idea. did you mean
that: if A and B implemented an common remote interface X, so A.class
and B.class together with X.class are all required to put on both
client end and server ends?

No, you need A_Stub.class, B_Stub.class, and X.class at the client &
registry, and all of these plus A.class and B.class at the server.

If so, I am thinking about another question. supposing X has a method
, say X.m, which claims to return a object with interface RX. so, in
the implementation of A, which return a RX_A as concrete object while
the B returns RX_B. in this situation, do i also need to put both
RX_A.class and RX_B.class on the client end?

Yes, or their stubs instead if they are remote objects.

 

[narke]

No, you need A_Stub.class, B_Stub.class, and X.class at the client >

& registry, and all of these plus A.class and B.class at the server.

yes, its a typo, i actually mean A_Stub.class instead of A.class.
and, I now understand your point. but the original question keep
not going away. i devote the next paragraph to it.

i can not figure out what are the essential differences between
contents inside A_Stub.class and B_Stub.class. they did not implement
any method, they just carry method calls over to the server, those
method calls on the other hand should not has any apparent difference (
according to the fact that only those stuff defined in the common
remote interface have to be exposed hence need a hook in their
respective stub).

from the client point of view, the only difference i can image is the
registry name of a remote object, but this was handled in the
lookup(...), after the lookup(...) got return, the difference should
going away. so, from then on, why A.class and B.class each still need
a dedicated stub, why they do not simply share some common one, such as
X_stub.class?

Yes, or their stubs instead if they are remote objects.

thanks. the concerns are same as above.

 

[Esmond Pitt]

You are right, in this case there is no difference.

Java could base the stub either on the remote interface or on the
implementing class. If there is only one of each there is only one stub
so it makes no difference which is chosen from that point of view.
Basing stubs on the implementing class conserves the number of stub
classes in the case where the remote object implements > 1 remote
interface. In your case where there is one interface and > 1
implementing object this means that the number of stub classes is not
conserved. The former is the more common case, in fact I have never
encountered your case before in eight years of using RMI except maybe in
some experiment of my own.

The good news is that if you are using JDK 1.5 throughout you don't need
stubs at all. Just don't call UnicastRemoteObject.super(), make sure you
provide a port number, 0 will do.

Another way you could get to only one stub in any JDK is by having a
common abstract class for your implementations which just extends
UnicastRemoteObject, implements the remote interface(s), and has no
methods other than the constructor. The stubs will then be generated
from this & will be identical for all derived implementing classes.

 

[narke]

thank you Esmond! this time your explaination really sort me out.
since we are not ready to embrace 1.5, so the later solution of using
abstract base class comes into sight as most likely adoptable.

-
narke