Explain how COM interface pointers can be
marshalled/unmarshalled to establish a proxy/stub connection
Another section will look at custom marshalling in order for
the reader to understand how to bypass the context mechanism when
it is not required.
We have seen that objects must be accessed indirectly when they
live in a different context than the caller. Simply passing
objects around from one context to another by value is
usually not correct, as it breaks the notion of object identity.
Rather, objects are left in their own context and object interface
references are passed around from context to context instead.
Objects are therefore passed by reference. These object
interface references can be exported from one context and
imported into another in such a way that they can be used
to make cross-context method calls on the object.
Remoting is the technique of making method calls on an
object in a different execution context. Typically it relies on a
well-defined request/response protocol, which is used to forward
method calls from one context to another and harvest the results.
Normally a proxy/stub pair is used to make the use of this
request/response protocol transparent to both the caller and the
object. The proxy is a local representation of the object
in the caller's execution context. The caller need not know that
it is not the real object. The proxy marshalls the call context
(e.g., input parameters) of each method and forwards them on the
stub as a request message. The stub receives the request,
unmarshalls the call context, and calls the object in its
execution context. Any results, exceptions, and output parameters
are marshalled and sent back to the proxy in a response message.
Finally, the proxy takes the response, unmarshalls the return
value and output parameters, and gives them back to the caller.
Marshalling is the technique of serializing
memory-based entities into a buffer suitable for transmission
across context boundaries. Typically marshalling is used to encode
method parameters and return values during the remoting process.
In order for this to work well in heterogeneous networking
environments, marshalling relies on a well-defined data
transmission format that is unambiguous on different
platforms.
The crucial part of being able to remote objects is the ability
to marshall and unmarshall interface pointers, just like other
data types, and in such a way that a proxy/stub connection is
automatically established on marshall/unmarshall.
Note also, that as well as just exchanging messages and
marshalling/unmarshalling call context, the proxy must be aware of
the policies of the caller's context and the stub must be aware of
the policies of the object's context. Between them they must map
one to the other transparently. Because the caller is dealing with
a proxy that looks just like the target object and knows the
policies of the caller's context, the caller is under the illusion
that the target object is executing locally in the caller's
context. Because the object is being called in its context by a
stub that knows the policies of the object's context, the object
thinks the caller has made the call in the object's context.
There has to be a well-defined protocol for interaction between
a proxy and stub. In the case of COM it is an extension to the
Distributed Computing Environment's Remote Procedure Call (DCE
RPC) called Object RPC or ORPC. Broadly speaking, ORPC
formalizes the object semantics of RPC. The DCOM 1.0 specification says that ORPC defines
"how calls are made on an object and how object references are
represented, communicated, and maintained."
Essentially, ORPC defines a protocol for the exchange of
request and response messages that represent method calls on a
'remote' object (an object in a different context than the
caller). The proxy and stub are loosely coupled in as much as they
understand ORPC.
The proxy and stub have to use a shared communication mechanism
to exchange messages. In the case of COM standard marshalling, the
communication mechanism is abstracted away by something called the
channel. The channel chooses the communication most
acceptable for crossing from one context to another. The proxy and
stub are loosely coupled in as much as they understand how to use
the channel.
To ensure that the data transmitted between proxy and stub is
not platform dependent, there has to be a well understood and
neutral data format used to describe the types that get passed
around. Otherwise, the proxy and stub would not be able to encode
and decode the details of each method call reliably on different
platforms. In the case of COM, it is an extension of the
Distributed Computing Environment's (DCE) Network Data
Representation (NDR) - a platform-neutral argument/parameter
marshalling format. Importantly, it adds a neutral data format for
describing interface references that allows them to be passed as
parameters in COM method calls. The proxy and stub are loosely
coupled in as much as they understand NDR.
They proxy and stub are tightly coupled in as much as they have
a shared understanding of all details of every method in the
interface. Whatever the proxy marshalls into the message passed to
the stub, the stub must be able to unmarshall and vice versa. We
have also said that the channel between the proxy/stub must be
intelligent in the sense that it must be aware of the policies of
the caller's context and the object's context, and how to map
between them.
| Marshalling interface
references : Remoting interfaces |
Interface Definition Language (IDL) describes the basic set of
types that can be used as COM interface method parameters. For
example, Boolean, byte, float, short, long etc or arrays of any of
these. From these it is also possible to build more complex
parameter types, for instance, structures and unions. You can
specify any of the basic or more complex types as input or output
parameters, passed by value or by reference. NDR encodes
(marshalls) all of these simple and complex types to be
transmitted as part of an ORPC request/response message and then
decodes (unmarshalls) them at the other end.
Because interfaces are the common currency of COM, you would
expect to be able to pass interface references as parameters in
the same way that you can pass other IDL types
- and you would be right.
As mentioned before, the DCOM 1.0 specification defines ORPC. It
specifies "how calls are made on an object and how object
references are represented, communicated, and maintained."
Specifically the DCOM protocol extends the NDR standard by
defining a new primitive data type that can be encoded - an
interface reference to an object.
The type used to describe such an encoded (marshalled) object
interface reference is called an
OBJREF. This is the only extension to NDR made
by ORPC. The OBJREF for a given interface contains enough
information to allow proxies to simulate the interface on the
object in a foreign execution context and, if necessary, to
connect back to the stub and forward method requests on to it.
What would you expect to happen when an interface reference
gets marshalled and unmarshalled? Consistent with the
"pass-by-reference semantics," COM will establish a proxy/stub
connected pair between the caller and the object. This will either
be the first proxy/stub connection between the caller and the
object in question, or it will 'widen' an existing set of
proxy/stub connections between the caller and the object. This
does seem to imply that we can only pass objects by
reference. Can we pass them by value also if we
really need to? Due to the flexibility of the COM
remoting and marshalling architecture, discussed next, we can
do both.
