Aspect Oriented Programming in WCF - The Solution

I feel a great sense of satisfaction with myself.. It seems I have solved a problem which no one else can even think of.. i mean.. i don't see any comments on the blog.. so the only resolution that i can up is this.

The Problem:

Anyways, going on with the issue, the exact problem was "Transaction Management". You see as explained before, a single command was designed to perform a single operation. So, the logical decision was to keep the transaction at the command level. Ah!! Now do you see the problem?Initially this might be the best approach but then bringing reusability into the picture, this turns out to be a nightmare. You save a person data, the person name gets committed but his employment details address may get lost because both these are placed in 2 different commands, which translates to 2 transaction.

The Solution:

Well, how do you solve it.. Just Mix and match some technical jargons and voila you ge tthe solution :). Seriously, the approach for solving the issue would be

1. Either introduce a new layer in between to handle the transactions.

2. or even better introduce AOP.

The concept of AOP is to introduce the cross cutting concerns in a common place or to be specific in an interceptor so that this gets executed auomatically for each operation. So, how is it exactly implemeted. For that you would have to know the following.

1. IOperationBehavior: Contains the methods to control, modify and extend the behavior for operation wide execution.

2. IContractBehavior: Contains the methods to control, modify and extend the behavior for contract wide execution.

3.IOperationInvoker: Contains the methods to execute the operation in either synchronous or asynchronous mode.

Define a class implementing IOperationInvoker with ur new implementation of the operation i.e. perform your custom operation before the invoke method is triggered or after the operation is executed. So, you can create the transaction as a pre process and committ / rollback as post process.

Next step is to plug this new Invoker behavior into the operation behavior. For this create a custom class implementing IOperationBehavior and mention the new invoker as the operation invoker in the ApplyDispatchBehavior(). Similarly, nmake this class implement the IContractBehavior interface and register this class to the list of operation behavior in the ApplyDispatchBehavior().

// IOperation Behavior Method implementation

public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)

{

dispatchOperation.Invoker= new CustomInvoker(dispatchOperation.Invoker);

}

// IContractbehavior Method implementation

public void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)

{

foreach (OperationDescription opDescription in contractDescription.Operations)

{

opDescription.Behaviors.Add(this);

}

}

The CustomInvoker is the custom class that defines the cross cutting operation prefix / suffix. You are done with the basic infrastucture set up. So, how do you apply this to your WCF Service. Simple, make the behavior custom class that we created inherit the Attribute class thereby, you can provide this AOP implementation to Service classes which has this custom class name as an attribute like

[CustomBehaviorAttribute]

public class YourWCFService : IYourWCFServiceContract

{}

So, just with the addition of 2 classes (Custom Inovker & Custom Operation and Contract behavior classes), you are ready to implement your custom operation before / after calling your service operation. Isn't it easy enough.

Desire!!! Indulge!!! Inspire!!!

Aspect Oriented Programming in WCF

Aspect Oriented Programming provides a mechanism of modularizing the application by separating to cross cutting concerns from the application. For implementing an AOP paradigm, you would want to know the following:

Aspect: A concern that cuts across multiple objects like Transaction, logging, exception handling etc…

Join Point: An execution point in the application like a method execution or catch of exception etc…

Advice: Action to be performed in an aspect at a particular join point.

Pointcut: Pointcut determines join points of interest for us to execute the advice. For example, conditions like Function Name or all public functions etc…

In our project or for that matter in any project, we can see a more common problem – dilution of the design guidelines. The project was designed with certain principles in mind. Unfortunately, as time passes by and new team members contribute towards the code, these guidelines get evaporated. One such case in our project was the usage of Command classes.

In order to understand the actual issue, we might have to go back a few years when Raj was designing the application. The architecture was designed like

1. There will be a WCF service exposed by the client for their business operation.
2. Each operation in the service will perform one action requested by the user.
3. The action to be performed will be delegated to a command class.
4. Each command class will perform one and only operation.

Seems a fair enough guideline. But as the team started working on the application, they saw that there were some pieces of code being written again and again. Bling!!! What about code reuse... Brilliant!! Let us have common code written in a separate command and reuse the command. So, what eventually happened was each service operation started comprising of multiple commands, which went on to become a separate command for certain logic even when not reused.

But what is the problem:

I see no harm in reusing, I mean, didn’t we learn that reusability increases code quality.

Come on people!!! What do you think might have been the problem with this? Please post in your comments on the same. I would request the project members not to comment on this as they very well know the issue.

As I would not want to make you read too much of content in 1 post, we will discuss the issue and the solution in the next blog.

Desire!!! Indulge!!! Inspire!!!

How Many Design Pattern You Know?

Each time I have been asked this question only few of the design pattern names I used to remember. Even if I go through again I not sure to remember for more than one day. So I thought to come up with simple statement which will make me to remember the name of design pattern( Atleast name :-))

I decided to create single sentence for each type of patterns.

1. Creational

Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist

sentence to remember
builder used prototype to build single abstract factory.

2. Structural

Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object

sentence to remember
abcd proxy is flying facade.

3. Behavioral

Chain of Responsiblity. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change

sentence to remember
Interpreter commands mediator to iterate template of memento and Visitor observes state and strategy of chain.

Now I am able to remember all the design pattern names which are given above easily :-).