Interception-based Aspect-Oriented Programming under .NET

1. Interception-basedAspect-Oriented Programming under .NET Presented by: Ramaswamy Krishnan-Chittur Advisor: Dr. James Fawcett

2. Contents • Background • AOP • .NET Channels • Messages • Contexts • Conclusion • Reference

3. Background • .Net provides three levels of environment for execution of programs: • Process – normal execution environment for Windows • AppDomain • Every process has one or more AppDomains • Each AppDomain provides fault isolation from other AppDomains. • Communication between AppDomains requires a channel transmitting messages formed by a proxy. • Each AppDomain has one or more contexts. • A context is a collection of attributes that are shared by a particular execution, e.g., threading model, security model, or transaction model. • Communcation between contexts supports interception – the act of intercepting a channel message to add services or modify its meaning. • This talk presents Aspect-Oriented Programming as a model for program design that uses .Net channels to provide services through interception.

4. What are Aspects? • An Aspect is a property of the system that tends NOT to be a unit of the system’s functional decomposition, but rather one that affects the performance or semantics of the components in Systemic ways; like memory access patterns and synchronization of concurrent objects. [1]

5. Aspect-Oriented Programming (AOP) • The primary goal of AOP is to extract functionality scattered throughout the whole application such as logging, transaction management, or security management into a separate module, [1] so that the resultant client-code is more purpose-specific, more readable, and less tangled. • AOP is a way of executing arbitrary code orthogonal to a module’ s primary purpose.[2]

6. AOP way – the better way? • AOP facilitates: • Isolation of ‘aspects’, • Less tangled code, • Better code encapsulation, and • Better code reusability.

7. .NET ChannelsChannel ArchitectureMessages: Units of data transferChannel SinksCustom SinksSink ProvidersConfiguring the custom sinks

8. 1] Channel Architecture in .NET

9. 2] Messages: Units of data transfer • When we construct a proxy and make a method call, we generate a Message object, which travels through a series of sinks as it makes round-trips to the server. • The Message class, which is referenced through the IMessage interface within the sinks, contains a dictionary that holds the data representing the call. • The Remoting framework exposes a number of IMessage implementing classes, which represent different messages passed along either during construction (Construction Call, Construction Response) or during a method call (Method Call, Method Response).

10. 3] Channel Sinks • There are two important sinks through which the remoted message passes: • Formatter Sink • Transport Sink • The Formatter Sink does the job of serializing the message into a stream and creating transport headers. • The Transport Sink converts the transport headers into protocol-specific headers and transfers the stream over the wire using the chosen protocol. Default Formatter Sinks • Remoting channels are associated with a default chain of sinks. • By default: • The HttpChannel is associated with SoapFormatterSink. • The TcpChannel with is associated with the BinaryFormatterSink.

11. 4] Custom Sinks

12. 4] Custom Sinks • We can put custom sinks both before and after the Formatter Sink. • We can develop Custom Channel Message Sinks, where we can manipulate messages in their raw form. • We can develop Custom Formatter Sinks, where we provide our custom formatting to the messages. • We can also develop Custom Channel Sinks, where we manipulate the serialized messages. 4.1] Custom Message Sinks: • We can develop Custom Channel Message Sinks, where we can manipulate messages in their raw form. • Such sinks have to implement the IMessageSink interface, and may derive from IClientChannelSink / IServerChannelSink interface.

13. 4] Custom Sinks 4.2] Custom Formatter Sinks • We can develop Custom Formatter Sinks, where we provide our custom formatting to the messages. • The custom formatter sinks have to implement IClientFormatterSink or the IServerFormatterSink interface. • The formatter sink on the client side receives the message on IMessageSink, serializes it, and forwards it on to client channel sinks. • On the server side, it reverses this process, deserializing the message and forwarding it to the stack builder sink. 4.3] Custom Channel Sinks: • In the Custom Channel Sinks, where we manipulate the serialized messages. • Custom Channel Sinks implement both IMessageSink and IClientChannelSink / IServerChannelSink by implementing IClientFormatterSink on the client side and IServerFormatterSink on the server side.

14. 5] Sink Providers • Using a configuration file, we can override the sink chain by providing a reference to custom sink providers. • A sink provider implements IClientChannelSinkProvider for creating client-side channel sinks and implements IServerChannelSinkProvider for creating server-side channel sinks. • The provider chain is initialized when the config file is read and the channel initialized. • The order in which the providers are placed in the chain depends on the order in which they are defined in the config file. • The CreateSink method of the provider is called when the proxy is created. It should forward the call to the next provider in the provider chain, and then chain the next sink (obtained after its own channel sink). This order sets up the sink chain through which the message passes.

15. 6] Configuring the custom sinks <configuration> <system.runtime.remoting> <application> <channels> <channelref="http"> <clientProviders> <formattertype="ClientInterceptor.MyFormatterClientSinkProvider, ClientInterceptor"/> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration>

16. MessagesWhat are messages? What tells apart a message object?What are the types of messages? When are messages invoked?Can we invoke a message explicitly? Can we create a message object?Where can we intercept messages? Why intercept the messages?What all info do the messages carry? Can we manipulate a message?

17. 1] What are messages? • Messages are the fundamental unit of data transfer across .NET boundaries.

18. 2] What tells apart a message object? • All Message objects derive from theIMessageinterface. 3] What are the types of messages?

19. 4] When are messages invoked? • Messages are invoked whenever a construction call or a method call occurs. • The response to the method call and the construction call also occur as response messages. • // invokes a construction call message. • MyClass M = new MyClass( ); • // invokes a method call message. • M.TestFunc( );

20. 5] Can we invoke a message explicitly? • No. • We can, however, override the invocation functionality by customizing the proxies, and making the object context bound.

21. 5] Can we invoke a message explicitly? Overriding message invocations using proxies.

22. 6] Can we create a message object? • There is just one system class –ReturnMessage, which lets us create message objects explicitly.ReturnMessageobjects hold the return message in response to a method call on a remote object. This class is defined in the namespace System.Runtime.Remoting.Messaging • It has two constructors: 1. Initializing a new instance of the ReturnMessage class, which holds an exception with it. public ReturnMessage(Exception, IMethodCallMessage); 2. Initializing a new instance of the ReturnMessage class with all the information returning to the caller after the method call. publicReturnMessage(object, object[], int, LogicalCallContext, IMethodCallMessage);

23. 7] Where can we intercept messages? • We can intercept messages in message sinks, classes derived from the IMessageSink interface. 8] Why intercept the messages? • Messages carry all the information about the method call, the parameters, the return value, info about the parent class, the custom attributes (if any), and many other useful metadata. • We can expose these metadata using reflection, if we intercept the messages in a message sink.

24. 9] What all info do the messages carry?

25. 10] Can we manipulate a message? • Yep!We can manipulate a message in the message sink. • .NET provides two classes,MethodCallMessageWrapperandMethodReturnMessageWrapper, which facilitate manipulating messages in the sink stack. • These classes are defined in theSystem.Runtime.Remoting.Messaging namespace.

26. Contexts1] AppDomain 2] Contexts 3] Cross-context architecture 4] Inter-Context Interception

27. 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. • AppDomains are divided into one or more contexts.

28. 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.

29. 3] Cross-context architecture • Cross-context member access • is message – based. • supports interception. • is completely pluggable. • Cross-Context access requires a proxy

30. 3] Cross-context access • Objects in an AppDomain are either Context-agile or Context-bound. • 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. • 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.

31. 3] Cross-context access Context-Agile object: Context-Bound object:

32. 4] Inter-Context Interception

33. 4] Inter-Context Interception

34. 3] Inter-Context Interception Context Property: • 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. Context Attribute: • 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. Interceptor Sink: • 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.

35. Interception and AOP: Code Samples? • Let us see a sample validation application implemented using aspect-oriented approach.

36. Conclusion From the AOP-based validation application, we can draw the following conclusions: • AOP helps reduce client code complexity. • lessif-then-elses in the client code. • AOP captures the purpose of the code better. • [Range (Lower = 0.0)] double radius at the function declaration is more explicit and elegant than if (radius < 0.0) throw new ArgumentOutOfRangeException (“..."); in the body of the function. • AOP enhances abstraction and encapsulation. • The validation check is isolated as a separate module. Any change to validation check handling can be made at this ONE place. • AOP promotes reusability. • The range-checker attribute provides a common point where the out-of-range exceptions can be handled. • The range-checker can be applied to a variety of classes which need range-checks, like: class Geometry, class Stock_Market etc.

37. References • Aspect-Oriented Programming - Kiczales et al; • Aspect-Oriented Programming with C# and .NET - Wolfgang Schult and Andreas Polze • Aspect-Oriented Programming in C#/.NET - Edward Garson • Advanced .NET remoting – Ingo Rammer. • Essential .NET, volume 1 – Don Box, Chris Sells. • Microsoft .NET Remoting - Kim Williams, James Naftel, Scott McLean • Remoting with C# and .NET: Remote Objects for Distributed Applications – David Conger • Visual C# .NET – Jason Price, Mike Gunderloy. • MSDN Documentation