| Abhishek Srivastava |
Hello all,
Why does the .Net remoting framework use two proxies (transparent and real)
to connect to a remote object? The same thing can be achived in one proxy as
well.
regards,
Abhishek.
|
|
|
| |
| |
| Ingo Rammer |
Abhishek,
> Why does the .Net remoting framework use two proxies (transparent and
real)
> to connect to a remote object? The same thing can be achived in one proxy
as
> well.
Not really ... the TransparentProxy is the object which "masquerades" as the
remote object and which create the necessary MessageData object so that the
IMessage can be filled. (And btw. in reality, at least three proxies are
part of a remoting call: TransparentProxy, RealProxy and the
RealProxy-descendent RemotingProxy)
When (after applying a correct configuration file that specifies TestSAO as
a remote type) the following code is executed:
------------------
1: TestSAO obj = new TestSAO();
2: obj.doSomething();
------------------
After Line 1, obj really referes to a TransparentProxy (TP) (which is
provided by the execution engine as it implements features which are not
"implementable" using IL alone). This TransparentProxy holds a reference to
the RealProxy (which is a RemotingProxy in this case). The TransparentProxy
will "masquerade" as TestSAO: it will allow all of TestSAO's methods to be
called upon it.
When line 2 is executed, the TP (using some heavy black magic outside of IL
;)) generates a MessageData object which contains some internal pointers and
calls a private function of RealProxy (PrivateInvoke()). This function in
turn creates a new Message object and passes the MessageData to its
InitFields() method. The Message object now populates its internal
dictionary by de-refing the MessageData's pointers.
Only after this, the call will be forwared to the RemotingProxies Invoke()
method.
So you need those three proxies for this reasons:
*) one object, which can masquerade "as any other object" (TransparentProxy)
*) one object, which can generate the necessary message data
(TransparentProxy)
*) one object, which really generates the Message object (RealProxy)
*) one object that "processes" the message (aka. contain the Invoke()
method) (a RealProxy descendent like RemotingProxy)
And yes, in theory (when we only talk about "Remoting" as a base for
distributed applications) a single "full-power" TransparentProxy would have
been sufficient.
But as soon as ContextBoundObjects or ServicedComponents enter the game, the
real power of this multi-proxy approach can be seen. These other techs rely
heavily on message-based processing, even when run within a single process -
but they don't (necessarily) use RemotingProxy ...
-Ingo
http://www.dotnetremoting.cc
|
|
|
| |
| |
| | |
