| Previous | Table of Contents | Next |
The ideal solution to the performance issues would be to have DCOM able to pass CORBA pseudo objects with similar semantics
to CORBA, and to have Automation support structs and unions natively. However, this is not likely to occur and cannot be implemented
adequately using DCOM standard marshaling. In addition, since Part B is not required to be implemented, COM/CORBA Part A compliant
solutions must still interoperate with solutions that also support the COM/CORBA Part B extensions. Thus, another mechanism
needs to be defined in order to avoid the performance and scalability problems while still maintaining compatibility.
To handle all of these cases using a standard mechanism, a category of DCOM objects called “DCOM value objects? was defined.
DCOM value objects are DCOM objects that have little or no behavior other than accessors for their underlying data. Proxies
for DCOM value objects act as local caches for the information in the original object. The Automation and COM views of CORBA
pseudo objects, as well as the Automation views of CORBA structs and unions, are all DCOM value objects.
Note – CORBA objects-by-value will be able to be viewed in DCOM as DCOM value objects.
When DCOM value objects are passed across DCOM systems the data of the DCOM value object (called the “value data?) is also
passed. Systems that support DCOM value objects can use the passed data to improve performance. However, when a DCOM
July 2002 CORBA, v3.0: Extent Definition
value object is passed to a system that does not support it as a value object, then the DCOM value object is accessed remotely
just as any other DCOM object would be. There are two types of DCOM value objects to support these semantics:
• A “primary DCOM value object,? which is the real; that is, original instance of the value object, and
• “Local DCOM value objects,? which are the local proxies for the primary value object and caches for the values data of the primary value object.
Note that the local DCOM value objects are essentially DCOM proxies with some methods (the ones that access the value data)
implemented locally.
To implement DCOM value objects while still providing compatibility with systems that do not support DCOM value objects, the
value data needs to be passed as, essentially “out-of-band? data. DCOM allows out-of-band data to be passed with requests
in DCOM extents. DCOM extents are a standard DCOM feature used to pass additional data with a request. On the receiving end,
if a handler is not available for the extent, it is ignored. Extents are similar to CORBA service contexts except that they
are not propagated through a chain of calls.
DCOM value objects are passed in a DCOM extent. Receivers that recognize the extent can take advantage of the data it provides.
Receivers that do not recognize the extend safely ignore it. This occurs with no changes at all to the standard marshaling
packet. This allows DCOM developers to use standard DCOM tools and services instead of entirely custom special purpose solutions.