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!!!