Previous | Table of Contents | Next |
A scalability issue known as proxy explosion arises when passing object references among clients and servers across object
systems. For example, an object reference is received from a CORBA server and is encapsulated in a DCOM view. This view is
passed to a different DCOM server. This server then attempts to pass the object to a CORBA server. Without prior knowledge
that the object was originally a CORBA object, a CORBA view would be built for what appeared to be a DCOM object (but which
was really a view). This means that when the CORBA server attempts to call an operation on this object, it passes through
a chain of views until the request is delivered to the real implementation instead of the call being direct CORBA to CORBA.
In order to resolve the proxy explosion view chain problem, an efficient mechanism must be provided for interworking solutions
to determine whether any object is a view or a native object and, if the object is a view, what is the original object behind
the view. The problem or proxy explosion is not specific to COM/CORBA interworking. Instead, it can occur between CORBA and
any other system where bidirectional interworking is supported.
The COM/CORBA Part A specification defines a mechanism to help avoid proxy chains using IForeignObject::GetForeignReference.
However, calling this operation remotely on each object reference to avoid proxy chains would have introduced a significant
performance problem.