Contexts

1. Contexts Presented by: Ramaswamy Krishnan Chittur

2. Contents 1] AppDomain 2] Contexts 3] Context Attributes 4] Context Properties 5] Context sinks 6] Reflection 7] Contexts and Interception 8] Sample code 9] Reference

3. 1] AppDomain Many programming technologies and environments define their own unique models for scoping the execution of code and the ownership of resources: -- For Java VM, it is based on Class loaders -- For IIS and ASP, the scoping model is Virtual directory. -- For the CLR, the fundamental scope is an AppDomain.[1]

4. 1] AppDomain • AppDomains are divided into one or more contexts.

5. 2] Contexts • Every CLR application is divided into one or more contexts. • Contexts are themselves objects that are instances of System.Runtime.Remoting.Contexts.Context type. • Contexts help to group together objects that have similar execution requirements. • Normally, the runtime creates contexts as needed.

6. 2] Contexts: cross-context architecture • Cross-context member access • is message – based. • supports interception. • is completely pluggable.

7. 2] Contexts: cross-context access • Cross-Context access requires a proxy

8. 2] Contexts: cross-context access • Objects in an AppDomain are either Context-agile or Context-bound.

9. 2] Contexts: Context-agile objects • Context-agile objects can be accessed directly from anywhere in an AppDomain. • Types derived from MarshalByRefObject are context-agile. • ‘Context-agile’ implies pass-by-ref, if between AppDomains.

10. 2] Contexts: Context-bound objects • Context-bound objects are accessed through proxies from outside the home context. • Types derived from ContextBoundObject are context-bound. • Context-bound implies pass-by-ref between contexts.

11. 3] Context Attributes • provide a facility to explicitly request context-based services • are instantiated at the runtime, just before the type that is using it is instantiated. • Participate in the decision to create a new context ( or not) • At instantiation time, install context properties and context sinks to provide service.

12. 4] Context Properties • Provide on-demand services to the developers. • Can contribute the instantiation of interceptors (sinks), that can intercept the messages intended to the target object. • Can be programmatically accessed from within a type’s methods. • Provide an interface that allows developers to control sink behavior.

13. 5] Context Sinks (Interceptors) • The context-properties can be programmed to provide sinks, on-demand. • Sinks provide services by intercepting calls into and out of the context. • .NET supports context-wide and object-specific interception. • Method calls on context-bound object types are converted into messages that pass through sinks, where interception can be employed if needed. • By employing interception at the sinks, we can modify the messages, or can even create a return-value thereby “short-circuiting” the method call.

14. 6] Reflection • A powerful feature of .NET, which • Provides access to type-metadata. • Supports late-binding. • Provides facility to create types at run-time!

15. 7] Contexts and Interception

16. 7] Contexts and Interception

17. 8] Sample code: custom attribute class // made applicable to classes, interfaces and structures only. [AttributeUsage( AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Interface)] public class DebuggerContextAttribute : ContextAttribute { public DebuggerContextAttribute() : base ("DebuggerInterception") { } public override bool IsContextOK(Context M1, IConstructionCallMessage M2) { return false; } public override void GetPropertiesForNewContext(IConstructionCallMessage M) { MyConstructor.ContextProperties.Add(new DebuggerContextProperty()); } }

18. 8] Sample code: custom property class public class DebuggerContextProperty : IContextProperty, IContributeObjectSink { public bool IsNewContextOK (Context MyNewContext) { return true;} public void Freeze (Context MyNewContext) { } public string Name { get { return "Interception";} } public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink N) { return new DebuggerSink ( N );} }

19. 8] Sample code: custom sink class We may choose to do custom processing on the method call over here. public class DebuggerSink : IMessageSink { private IMessageSink _nextSink; public DebuggerSink(IMessageSink nextSink) { _nextSink = nextSink; } public IMessage SyncProcessMessage(IMessage msg) { return _nextSink.SyncProcessMessage(msg); } public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink) { return _nextSink.AsyncProcessMessage(msg, replySink); } public IMessageSink NextSink { get { return _nextSink; } } }

20. 8] Sample code: using Reflection Exposing metadata via Reflection

21. 8] Sample code: Client The client class has to derive from this class to be context bound, thus enabling interception when operating between contexts. The Custom Attribute that we developed to enable interception. [DebuggerContext ( )] public class MyClient : System.ContextBoundObject { // class implementation }

22. 9] Reference • http://msdn.microsoft.com/msdnmag/issues/02/03/AOP-Dharma Shukla, Simon Fell, and Chris Sells • Essential .NET, volume 1- Don Box, Chris Sells. • Context– Mike Woodring. • Advanced .NET Remoting- Ingo Rammer. • MSDN documentation. • Microsoft .NET Remoting - Scott McLean, James Naftel, Kim Williams. • Remoting with C# and .NET- David Conger. • Visual C# .NET– Jason Price, Mike Gunderloy.