| Previous | Table of Contents | Next |
Servers, which support the extent, can retrieve the information from the extent during unmarshaling to get the value data
for the local DCOM value objects (DCOM proxies). If the unmarshaling of the data within the extent fails with an error, this
error is returned in a corresponding reply extent containing the error that occurred. If the unmarshaling is successful, the
request is processed and an extent is added to the reply. Any out parameter or return DCOM value objects are included in the
reply extent. The statusCode member should be NO_ERROR. Even when the outgoing request does not contain any DCOM value objects,
the callee must still add the extent (consisting of just the statusCode member in this case).
If the receiver of a DCOM value object passes a reference to the object to another client/server, the object reference of
the primary DCOM value object should be marshaled in the request, not the object reference for the local DCOM value object.
If the client supports the DCOM value object semantics for a given object reference, then an in-process copy of the value
data is created using the data from the extent, and all read accesses are performed with no network calls.
When all clients and servers support the DCOM value object semantics, changes made to a local copy of the object can then
be passed to other clients or servers. However, since the implementation of this specification is optional, it cannot be assumed
that all clients and servers support this feature.
If the client of a DCOM value object does not support the extent, or the appropriate support for a given DCOM value object
to be unmarshaled locally, then all reads or writes to members of the object are transmitted over the network to the server,
which originally provided the object reference.
In cases where the receiver modifies the local copy of the object, these changes must be propagated back to the server to
maintain consistency between systems that support the DCOM value object and those that do not.
The interfaces used to manage consistency were designed so that applications on homogenous networks (where every interworking
solution supports Part B) can disable the synchronization used to maintain consistency. Applications running on heterogeneous
networks can control the synchronization behavior to best suit the needs of the application.
In cases where the receiver modifies the local DCOM value object, these changes must be propagated back to the server to maintain
consistency between systems that support DCOM value objects and those that do not. To maintain consistency, three additional
DCOM interfaces are defined:
[
object,
pointer_default(unique),
uuid(c9362b80-14bd-11d1-8a22-006097cc044d)]interface IValueObject : IUnknown
{HRESULT GetValue( [out] unsigned long *length,[out, size_is(,*length)] byte**data);
HRESULT PutValue( [in] unsigned long length,[in, size_is(length)] byte *data);};
typedef enum tagSyncronizeMode
{kNeverSync,kSyncOnSend,kSyncOnChange
} SyncronizeMode;
[object,pointer_default(unique),uuid(c82fb800-14bd-11d1-8a22-006097cc044d)
]interface ISynchronize : IUnknown{
HRESULT get_Mode([out, retval] SyncronizeMode *mode);HRESULT put_Mode([in] SyncronizeMode mode);HRESULT SyncNow();HRESULT ReCopy();
};
[odl,dual,oleautomation,uuid(c8c84e80-14bd-11d1-8a22-006097cc044d)
]interface DISynchronize : IDispatch{
[propget] HRESULT Mode([out, retval] SyncronizeMode
*mode);[propput] HRESULT Mode([in] SyncronizeMode mode);HRESULT SyncNow();HRESULT ReCopy();
};