NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Remoting Object Model Architecture

Runtime object types are categorized into 4 categories.

Objects and Type hierarchy

Logical and actual class model

The logical hierarchy is:

Figure 1: Logical class hierarchy.

In summary, Objects may be agile (Unbound or App-Domain bound) or Context-bound. Agile objects can be accessed through a direct reference from anywhere in the App-domain whereas access to a Context-bound object one would via a proxy.

Figure 1 shows the inheritance type hierarchy for all runtime classes. With respect to contexts, only Context-bound classes and agile classes are interesting. Objects belonging to context-bound class are guaranteed to be called only inside the context in which they were born. On the other hand, objects belonging to agile classes are guaranteed to be called in the context of their caller.

The logical class hierarchy is unaffected, with Object as the root. But the actual class hierarchy doesn't have Object as the root. Object is the root of all Unbound classes. MarshalByRefObject is the root of all AppDomain-bound classes. ContextBoundObject is the root of all Context-bound classes.

Context-bound classes are in a separate section of the hierarchy.

Once a class is marked as Unbound, AppDomain-bound or Context-bound, all its subclasses are similarly constrained. This falls out naturally from considering Agility to be a location in the class hierarchy.

The class hierarchy yields the following benefit:

  1. Compiler need not invent new keywords for defining Context-bound and Appdomain-bound classes. A class is context-bound if it derives from ContextBoundObject and Appdomain-bound if it derives from MarshalByRefObject.

Objects are never shared across app-domains. Another way of picture the hierarchy is to think that context-bound objects are proxied outside of their context, AppDomain-bound objects are proxied outside of their AppDomain, and unbound objects are copied by value outside of their AppDomain.

Hierarchy and System.Object

The System.Object class is ambiguous with respect to agility as it is the root of both context-bound and agile classes. A similar argument holds for interfaces as they can be implemented both by context-bound and agile classes. The implementation hierarchy for runtime objects is shown below, in Figure 2

The Virtual Root Object is conceptual. Treating System.Object class as agile, optimizes for a world where most of the classes are agile. For example, the Class Libraries (System.*) contains mostly agile classes. Cross-context transparent proxies are not agile.

Instance Fields and Accessors

There are three cases:

Statics

Static fields and methods are agile regardless of the class they are on. That means they are never remoted and field access is via direct memory.

Static fields are like instance fields of Agile objects - they don’t imply any context crossings. For example, accesses to a static field of a class that requires (Context-style) synchronization will not be synchronized.

Passing Objects as Parameters

Agile objects may be transmitted and received by value (unbound) or by reference (AppDomain bound). Context-bound (i.e. non agile) objects must be transmitted by reference (by proxy) only.

Non-virtual Instance Methods

Virtual methods don’t require special checks for proxies. The VTable of the proxy automatically handles this case. However non-virtuals need to be deal with differently. Here’s the set of non-virtual instance method cases:

Delegates

Delegates are Unbound (Marshaled by Value). Address and Code (thunk or direct pointer) as appropriate.