remote and dynamic proxy

Question

1. i understand that ,once, developing remote proxy included generating stub/skeleton , though today this is no longer needed thanks to reflection. (dynamic proxy)

i want to get a clear explanation as to why and how reflection replaces this need. for example i understood the stub was suppose to handle the communication over the network (in case the the remote object is on a different computer) , plus in charge of serialization/deserialization , etc... who's in charge of that now ?

maybe i got the concept of dynamic proxy all wrong.

1. in addition i read about that subject regarding Java and Rmi, how would i implement remote proxy in C++, i probably can use DCOM, is there another, maybe easier, way ? (and do i need stub/skeleton in DCom or like java no more ? )

thanks

Answer 1

say you have an interface A, and class B implements A.

the server VM has one instance of B; it's associated with a name; the server listens on a TCP port for client communication. something like this:

Server server = new Server(localhost, port);
server.bind("bbbb", new B() );

on the client VM, you want to access that B object residing on the server VM. You need to obtain a reference (of type A) to it

A bb = lookup(serverIp, port, "bbbb");

bb is a subclass of A, created with java.lang.reflect.Proxy. any method call on bb is handled by an InvocationHandler, which encodes the invocation in whichever way, and send it to ther server over the wire. the server receives a request of "calling this method of this name [with these arguments] on the objected named bbbb", and the server has no problem performing that task with reflection. then the return value is sent back to client in the similar way.

So it is really not hard to do this by yourself. Sun's RMI is probably doing the same thing (RMI has some other features, like remote garbage collection). see http://java.sun.com/j2se/1.5.0/docs/guide/rmi/relnotes.html

Answer 2

If I'm not mistaking, the stub/skeleton was statically created by the rmic tool while now the whole process is dynamic.

Its not that its necessarily 'better', but just removes the hassle of compiling a stub and skeleton. In both cases, the request parameters and response is serialized in the same way pretty much at the same level.

As for question #1: Some implementation of RMI uses Corba, so if the code is available, you may want to look at that.

All you would need is to interface your C++ code with the Corba layer as the stub/skeleton did.