TechTalk Genome Wire Object Protocol v4.2

Marshalling aspects of Genome persistent objects

Persistent objects in Genome provide an abstraction of a strongly typed bookmark towards a database record. Any change performed on Genome persistent objects will be applied directly on the set of underlying database records. Genome intercepts all access to persistent state and routes it trough the active Context governing data retrieval, caching and transactioning strategies relevant to the current database access session. The interception mechanism in Genome wraps persistent objects into object proxies whenever it returns persistent state to the caller either as a result of a query or as a result of a call to DataDomain.New.

Persistent objects implement a similar concept to MarshalByRefObject. Real "instances" of persistent objects reside in the underlying Data Domain, represented as records in relational tables. These objects can be retrieved from their native Data Domain by means of OQL queries. When the result of a data retrieval operation is sent across the AppDomain boundary between the Data Domain and the client AppDomain persistent objects are marshaled by reference. As a result the client AppDomain receives a proxy to the persistent object instead of receiving the entire object state itself. While the proxy itself is independent of the underlying Context that created it access to such a proxy requires the presence of a configured Context on the calling thread.

To make a persistent object serializable one has to use the [Serializable] attribute just like with other CLR classes as in the following example:

public class Person : Persistent
    public abstract Guid Id { get; set; }
    public abstract string Name {get; set; }

As a natural consequence of the above defined concept Persistent objects retain similarly to MarshalByRefObjects in terms of serialization as well. When a persistent object is being serialized across AppDomains only the bookmark to the database record (object reference) is written into the stream. On the other end of the communication wire the same object proxy is deserialized. This also means that passing a persistent object between two AppDomains over remoting would not transmit state of the object but only a reference to it. The remote AppDomain would have to use a Context to query the underlying database for the state of the persistent object. To pass the entire state of a persistent object to a remote AppDomain one would have to pass the Context instance itself that was used to retrieve the persistent object from the database (not supported by the current Genome framework).

This serialization concept suits well in situations where all components of a distributed application have direct access to the relational database server and use proxies to exchange referential data - location of records in the database to be processed - on the wire protocol.

The above architecture imposes however certain limitations and constraints: