Under The Influence(of code)

T4 template consuming a WCF service

2009-10-18T00:06:49-07:00:00

It’s been a while since I’ve blogged and but I have a valid excuse; I moved to WA state recently and things have been crazy busy. I finally decided to kick myself and do a post so without further ado, the problem at hand:
A co-worker of mine asked me whether its possible to dynamically create a type from some data he is receiving from a WCF service (over HTTP).
My natural response was, why would you need to do that since Visual Studio creates a proxy from the metadata exposed by the service and the return types would typically be DataContracts.
Well, it turns out that instead of returning a strongly typed domain specific object, the service is returning a Dictionary<string,string> where the Key represents an attribute and the Value represents the value of the attribute.

This has obvious problems:

Nothing is strongly typed
No contract versioning
The service could return a variable number of fields

A naive approach is to inspect the data returned by the service and hand code a class with properties based on the type of each key in the Dictionary.
For example, if the Dictionary contained the following KeyValuePairs.
{“Name”,”Jon Smith”}
{“Age”,”20”}
{“Zip”,”90876”}

The class definition would look something like this:

public class User
{
public string Name {get;set;}
public int Age {get;set;}
public int Zip {get;set;}
}

That’s fine when you have a couple of KeyValuePairs but what if you had 10 or 20, it gets unwieldy very quickly.
Enter T4 templates, a slick way to generate code for repetitive tasks. I'd never written a T4 template before so I figured this would be a nice excuse to dabble in it a little.

Let’s create a simple service to simulate some data, nothing too fancy

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
namespace T4WCFService
{
[ServiceContract]
public interface IT4WCFService
{
[OperationContract]
Dictionary<string,string> GetUser(string userID);
}
}

and its implementation...

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
namespace T4WCFService
{
public class T4Service : IT4WCFService
{
#region IT4WCFService Members
public Dictionary<string, string> GetUser(string userID)
{
if (userID == "jsmith")
{
return new Dictionary<string, string>
{
{ "Name", "Jack smith" },
{ "Age", "30" },
{ "City", "San francisco" },
{ "State", "CA" },
{ "Zip", "94061" },
{ "Country", "USA" }
};
}
if (userID == "jasmith")
{
return new Dictionary<string, string>
{
{ "Name", "Jane smith" },
{ "Age", "28" },
{ "City", "Portland" },
{ "State", "OR" },
{ "Zip", "98685" },
{ "Country", "USA" }
};
}
return new Dictionary<string, string>();
}
#endregion
}
}

The service just simulates returning some dummy users based on a userID and returns an empty Dictionary if no matching user is found, and it’s exposed using

WSHttpBinding

The <system.servicemodel> looks as follows:

<system.serviceModel>
<services>
<service behaviorConfiguration="T4WCFService.Service1Behavior"
name="T4WCFService.T4Service">
<endpoint address="WsHttpT4Service" binding="wsHttpBinding" name="WsHttpT4Service"
contract="T4WCFService.IT4WCFService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<endpoint address="basicHttpTService" binding="basicHttpBinding"
name="basicHttpTService" contract="T4WCFService.IT4WCFService" />
<host>
<baseAddresses>
<add baseAddress="http://WCFServices" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="T4WCFService.Service1Behavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>

If you(like me) have never created a T4 template before, I’d strongly suggest reading this article first.

Welcome back, now that you know how to create a simple T4 template, let’s get started.
T4 enables writing reusable modules that can be consumed from other T4 modules. For the purpose of this exercise I decided to create a template which encapsulates invoking a WCF service and returning the result back to the caller.

Create a new Console Application and add a service reference to the service we created above, also add a new T4 file to your project called WCFServiceInvoker.tt

Double click on WCFServiceInvoker.tt and the file should open up in markup mode.Delete the default code in the .tt file and add the following code:

<#@ template language="C#v3.5"#>
<#@ output extension=".cs"#>
<#@ assembly name ="System.ServiceModel" #>
<#@ import namespace="System.Collections.Generic"#>
<#@ import namespace="System.Reflection"#>
<#@ import namespace="System.ServiceModel.Channels"#>
<#@ import namespace="System.ServiceModel"#>
<#+
public class WCFServiceInvoker<TInterfaceType,TReturnType> where TReturnType:class
{
public string EndPointAddress {get;set;}
public string EndPointName {get;set;}
public Type ServiceInterfaceType {get;set;}
public Binding Binding {get;set;}
public string MethodName {get;set;}
public object[] Parameters {get;set;}
public TReturnType InvokeMethod()
{
EndpointAddress endpoint = new EndpointAddress(EndPointAddress);
Type typeDef = typeof(ChannelFactory<>).MakeGenericType(typeof(TInterfaceType));
var typeInst = Activator.CreateInstance(typeDef,new object[]{Binding,endpoint});
var channel = typeInst.GetType().InvokeMember("CreateChannel", BindingFlags.InvokeMethod,null, typeInst, null);
var results = channel.GetType().InvokeMember(MethodName, BindingFlags.InvokeMethod, null,channel, Parameters);
return results as TReturnType;
}
}
#>

There is a lot going on here.

The template and output directives indicate that the code is written in C# and the generated file needs to be have an extension of .cs.
The <#@assembly> directive is similar to an “Add Reference” in Visual Studio, it allows for referencing external assemblies.
The <#@import> directive is similar to a “using” statement, in that it brings the types in the specified namespace in scope so that the template can avail of them.
The <#+ #> directive is called Class feature block and it allows for writing class definitions within the template.
This allows for encapsulating reusable logic.
NOTE: The class definitions in this block are not emitted out to the final .cs file.
The WCFServiceInvoker class contains a bunch of properties, whose values(when set) are used for invoking a specified service dynamically.
The type parameters “TInterfaceType” represents the type of the interface on which the method specified in the "MethodName" parameter will be invoked.
The type parameter “TReturnType” represents the type of the result returned from the method call.

Using “TInterfaceType” we dynamically create a type definition for ChannelFactory<T> using reflection, and then create an instance of it, on which we then call CreateChannel which in turns returns us an instance of a type which implements TInterfaceType. Once we have a “TInterfaceType” instance we then go ahead and invoke the specified “MethodName” with the parameters specified in the “Parameters” object[] property and get the result back which is typed to “TReturnType” and returned to the caller.

Phew! that’s a mouthful and we are not done yet. For now just keep in mind that this template is merely a helper which encapsulates the details on dynamically invoking a WCF service in a strongly typed manner.

Now onto the main task of writing a template to solve our problem.

Add another T4 template to the project and call it UserClass.tt

As before delete the code from the .tt file and add the following:

<#@ assembly name ="System.ServiceModel" #>
<#@ assembly name ="T4WCFService.dll" #>
<#@ assembly name ="System.ServiceModel" #>
<#@ import namespace="System.Collections.Generic"#>
<#@ import namespace="System.Reflection"#>
<#@ import namespace="System.ServiceModel.Channels"#>
<#@ import namespace="System.ServiceModel"#>
<#@ import namespace="T4WCFService"#>
<#@ include file="WCFServiceInvoker.tt" #>
using System.Collections.Generic;
namespace T4ClassFromDict
{
public class User
{
<#
WCFServiceInvoker<IT4WCFService,Dictionary<string,string>> invoker = new WCFServiceInvoker<IT4WCFService,Dictionary<string,string>>();
invoker.EndPointAddress = "http://localhost:24551/Service1.svc/WsHttpT4Service";
invoker.EndPointName = "WsHttpT4Service";
invoker.ServiceInterfaceType = typeof(IT4WCFService);
invoker.Binding = new WSHttpBinding();
invoker.MethodName = "GetUser";
invoker.Parameters = new object[]{"jsmith"};
Dictionary<string,string> result = invoker.InvokeMethod();
#>
<#foreach(KeyValuePair<string,string> item in result){
#>
public <#= item.Key.GetType().Name.ToLower()#> <#=item.Key#>
{
get;
set;
}
<#}#>
public static User GetUser(Dictionary<string,string> dict)
{
var user = new User();
foreach(KeyValuePair<string,string> kvp in dict)
{
typeof(User).GetProperty(kvp.Key).SetValue(user,kvp.Value,null);
}
return user;
}
}
}

We've included the template file we created before so that we can reuse it to invoke any WCF Service.
We then proceed to create an instance of WCFServiceInvoker and set it's properties to invoke the WCF service we've created.
The result of "invoker.InvokeMethod()" is a Dictionary<string,string> which we then loop through creating public properties.

We use the type of the Key as the type of the property and the Key itself as the property name.

We've also created the definition of factory method which accepts a Dictionary<string,string> and returns a User object.

Note that we've added a direct reference to the service assembly in this template so that we can get a reference to IT4WCFService.
This is just to keep the example simple, ideally you would want to seperate the interface and implementation assemblies and have a reference to just the interface assembly.

T4 templates are executed typically when saved or by right clicking on the .tt file and selecting "Run Custom Tool".
Before running the template, ensure that the WCF service is up and running.

On running/saving the template, the following class definition is generated.

using System.Collections.Generic;
namespace T4ClassFromDict
{
public class User
{
public string Name
{
get;
set;
}
public string Age
{
get;
set;
}
public string City
{
get;
set;
}
public string State
{
get;
set;
}
public string Zip
{
get;
set;
}
public string Country
{
get;
set;
}
public static User GetUser(Dictionary<string,string> dict)
{
var user = new User();
foreach(KeyValuePair<string,string> kvp in dict)
{
typeof(User).GetProperty(kvp.Key).SetValue(user,kvp.Value,null);
}
return user;
}
}
}

A client can then use the generates class as follows:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.IO;
using System.ServiceModel;
using T4WCFService;
using System.Reflection;
namespace T4ClassFromDict
{
class Program
{
public string Foo { get; set; }
static void Main(string[] args)
{
var client = new T4Service.T4WCFServiceClient("WsHttpT4Service");
var data = User.GetUser(client.GetUser("jsmith"));
}
}
}

NOTE: The console app hosting the project has a direct project reference to WCF service project since it needs the IT4WCFService definition. and since T4 engine is running inside Visual studio it locks the assembly, so rebuilding the WCF service after template generation does not work.
As mentioned previously the solution to this is to have seperate assemblies for the interface and service implementation.
Download Code

Why no Anonymous Iterators in C#

2009-08-24T21:55:53-07:00:00

Yes I’m a language geek and yes the awesome Eric Lippert is my idol when it comes to anything C# and the CLR, I’ve been following his blog for a long time and recently Eric wrote an awesome series on the how and why of Iterator Blocks. The entire series is very well worth a read, but then again I’d read almost anything Eric writes from why the sky is blue to why the Falkirk Wheel has horns.

I had posed a question on this post about why there are no anonymous iterators in C#. Eric provided a very good answer to that comment and I was highly flattered when he did a follow up post on this very question here.

Thanks Eric!

Creating Higher Level APIs with TPL

2009-08-23T15:46:02-07:00:00

The BCL has a bunch of APIs which provide asynchronous versions of operations in the form of either Beginxxx/Endxxx or XyzCompleted, the former known as Asynchronous Programming Model(APM) and the latter known as Event Based Asynchronous Pattern (EAP). TPL provides a nice abstraction for performing asynchronous operations as Tasks using delegates, but what can you do for working with these existing BCL classes which already have an async version?

Here is an example.
Let's say we need to download some data from the web and save it to a file, you would typically use the WebClient class and write something like this today (wrapped in a method of course)

WebClient client = new WebClient();
client.DownloadDataAsync(new Uri("http://www.bing.com"));
client.DownloadDataCompleted += new DownloadDataCompletedEventHandler((s, e) =>
{
if (e.Error != null)
{
throw e.Error;
}
if (!e.Cancelled)
{
using (FileStream fs = new FileStream("bing.htm", FileMode.CreateNew))
{
fs.Write(e.Result,0,e.Result.Length);
fs.Flush();
fs.Close();
}
}
}
);
Console.Read();

Yuck not very pretty is it! It's kinda smelly and looking at the code, it doesn't really capture the essense of what we are trying to do, besides if the client were to call a method which does this work, we'd have to ensure that the client thread blocks till the continuation completes or conversely provide a mechanism such as a WaitHandle that the client can wait on, not very expressive is it?

Let's see how we can achieve the same results using the Task API.

private static TaskCompletionSource<byte[]> CreateSource(object state)
{
return new TaskCompletionSource<byte[]>(state);
}
private static void SetCompletionSource<T>(
TaskCompletionSource<T> tcs,
AsyncCompletedEventArgs e,
Func<T> getResult)
{
if (e.UserState == tcs)
{
if (e.Cancelled)
tcs.TrySetCanceled();
else
if (e.Error != null) tcs.TrySetException(e.Error);
else
tcs.TrySetResult(getResult());
}
}
public static Task<byte[]> DownloadBytesTask(this WebClient webClient, string uri)
{
var source = CreateSource(uri);
DownloadDataCompletedEventHandler handler = null;
handler = (object s, DownloadDataCompletedEventArgs e) =>
{
SetCompletionSource(source, e, () => e.Result);
webClient.DownloadDataCompleted -= handler;
};
webClient.DownloadDataAsync(new Uri(uri), source);
webClient.DownloadDataCompleted += handler;
return source.Task;
}

We've wrapped up the async network operation into a Task as an extension method.
Let's dig in a little...

In DownloadBytesTask, we first create a TaskCompletionSource which provides a mechanism to create a Task to hand out to consumers such that the only legal state modification to the Task can be performed via the methods available on the TaskCompletionSource itself and not on the instance of the Task directly, this is precisely the behavior needed for a Task that is downloading content from the web asynchronously;it doesn't make sense for the client to explicitly start such a Task which has already started downloading data and such an operation should really be considered illegal, TaskCompletionSource enables this behavior.

In the callback we call SetCompletionSource which is responsible for transitioning the state of the Task based on the results of the asynchronous operation such as whether it errored out, or completed or whether it was cancelled.

We then proceed to start the asynchronous download by calling DownloadDataAsync method of the WebClient instance.

Couple of things to note:

The callback has been unhooked from the event in the callback to ensure that we don't have a memory leak.
The Task has already started since "DownloadDataAsync" has already been invoked, and it is this started Task that we return from the method.

The client can now perform the asynchronous download and saving of content like so:

public class Program
{
public static Task WriteToFileTask(string fileName, byte[] bytes)
{
FileStream fs = new FileStream(fileName, FileMode.CreateNew);
var task = Task.Factory.FromAsync(fs.BeginWrite, fs.EndWrite, bytes, 0, bytes.Length, null);
return task;
}
static void Main(string[] args)
{
WebClient wc = new WebClient();
var task = wc.DownloadBytesTask("http://www.bing.com/");
var continuationTask = task.ContinueWith(a => WriteToFileTask("bing.htm", a.Result));
continuationTask.Wait();
}
}

The DownloadBytes extension method on the WebClient returns a Task which has already started, we then specify a continuation to execute "after" the Task completes by calling the "ContinueWith" method on the Task instance which in this case is itself a Task which works on the result of the antecedent task (a byte[]) obtained by calling the "WriteToFileTask" method which is responsible for writing out the byte[] to a file.

It's important to note that we have to wait for the "continuation" to complete by calling continuationTask.Wait(), otherwise the process will terminate since we are running on a console app. The same would hold true in case of a Webforms client since the calling Page would continue processing and not wait for the Task to complete.

Notice how the client code seems pretty terse in terms of expressing the intent. One can easily read the code and figure out what's going on.
As always happy coding!

CLR via C# 3rd Edition

2009-08-16T15:06:25-07:00:00

Some book news…Jeff Richter is one of my favorite authors and I’ll read just about anything he writes. His last book CLR via C#, 2nd Edition left me wanting more, luckily Jeff has signed into a contract for writing a 3rd edition of the book updated for C#3.0/4.0 and .NET 4.0

Retrieving Added Entities from the ObjectStateManager to avoid duplication

2009-07-23T01:41:23-07:00:00

Let's say we neede to process a bunch of entities coming from an XML file, create EDM entites for each XML element and eventually persist them. Very trivial to accomplish using a little bit of LINQ.

<Roles>
<Role name="Admin"/>
<Role name="Reader"/>
<Role name="Writer"/>
</Roles>

var doc = XDocument.Load("Roles.xml");
var roles = doc.Element("Roles").Elements("Role").Select(x => new Role { RoleName = (string)x.Attribute("name") });
PermissionsAPIContext context = new PermissionsAPIContext();
foreach (var role in roles)
{
context.AddToRoleSet(role);
}
context.Savechanges()

But wait, let's make this a little interesting...

<Roles>
<Role name="Admin"/>
<Role name="Reader"/>
<Role name="Writer"/>
<Role name="Reader"/>
</Roles>

See the problem now? If we process the above XML using the code from before, we end up adding the same entity twice!
So what do we do now?
ObjectStateManager to the rescue, let's rewrite the piece of code as follows:

var doc = XDocument.Load("Roles.xml");
var roles = doc.Element("Roles").Elements("Role").Select(x => (string)x.Attribute("name"));
PermissionsAPIContext context = new PermissionsAPIContext();
foreach (var role in roles)
{
Role roleEntity = GetRole(role, context);
if (roleEntity.EntityState == EntityState.Added || roleEntity.EntityState == EntityState.Detached)
{
context.AddToRoleSet(roleEntity);
}
}
context.SaveChanges();
private static Role GetRole(string roleName,PermissionsAPIContext context)
{
//NOTE: we could have used string.Compare(r.RoleName,roleName,true) == 0 inside the body of the lambda as a cleaner
//way to do this but this translates to some pretty snarly and inefficient SQL!
var roleEntity = context.RoleSet.FirstOrDefault(r => r.RoleName.Trim().ToLower() == roleName.Trim().ToLower());
if (roleEntity == null)
{
var stateEntries = context.ObjectStateManager.GetObjectStateEntries(EntityState.Added | EtityState.Modified | EntityState.Unchanged);
var roleEntityEntries = stateEntries.Select(s => s.Entity).OfType<Role>();
roleEntity = roleEntityEntries.FirstOrDefault(r => r.RoleName.Trim().ToLower() == roleName.Trim().ToLower());
if (roleEntity == null)
{
return new Role { RoleName = roleName };
}
}
return roleEntity;
}

A few of things note worthy here
1) In GetRoles() we first query the ObjectContext to check whether there is already a role present with the given name, if so we
simply return a reference to the existing entity instance
2) If the role is not existing then we check to see whether a role with the given name was added to the context, if so then we just
get a handle to this previously added(but not yet persisted) role and return that.
3) If the role is not existing and was not added previously then we create a new Role entity and return.
4) The caller checks whether the returned entity is an existing one and if not it's added to the ObjectContext.

After we are done processing all entities, we save all entities and we are done.

The above mechanism allows us to safely sidestep duplicates while processing based on some equality rule(which in this case happens to be the role name).

Hope this helps.

Inside TPL video

2009-07-17T14:36:56-07:00:00

No code today. Instead, here is a link to a great video from Channel9 I found, which takes a deep dive into the underlying mechanics of how TPL does what it does and some of the enhancements that the thread pool has undergone. Albeit a year old, this video goes into details of the work stealing algorithm and local thread queues that helps increase throughput.

From the perspective of being a consumer of TPL, you can be blissfully ignorant of what happens behind the scenes, but understanding the mechanics and some of the design decisions that the team made can help gain a deeper appreciation of TPL which ultimately can help write more thoughtful code.

I was impressed by the clarity in which the concepts were presented and explained. Plan on setting aside about an hour to watch this video, but every minute is time well spent!

Performing multiple Asynchronous Actions using TPL

2009-06-17T00:50:50-07:00:00

I finally had a chance to install VS2010 Beta 1.Full instruction on how to here
VS2010 has undergone a major overhaul since VS 2008, a peek are some of the cool new eye candy can be found here
I've been waiting to get my hands on the TPL/PLINQ stuff and the Beta was definitely worth the wait. In a previous post we talked about using asynchronous actions for performing long running operations.

I was anxious to see how the new TPL stuff would help in achieving the same thing.

Interestingly enough, the TPL API is based on Actions as well, allowing both the generic and non-generic versions to be used for creating a Task(also supports Funcs).

The Thread pool has undergone some major rework, especially the scheduling algorithm is much more smarter now than the current implementation in.NET 3.5

The unit of abstraction is a Task as opposed to a Thread, so let's dive in and see how this looks and feels as opposed to the abstraction we previously built for asynchronous Actions. In the simplest form, the equivalent declaration for creating a Task that can execute an Action asynchronously looks like so:

public static void SomeMethod()
{
// do something here....
Console.WriteLine("In some method");
}
static void Main(string[] args)
{
var task = Task.Factory.StartNew(SomeMethod);
task.Wait();
}

You start a task and Wait for it to complete. Lets create a bunch of these tasks to execute on the GetUsers(), GetCountries() and GetLanguages() method from the previous post.

Task[] tasks = new Task[]
{
Task.Factory.StartNew(() => countries = GetCountries()),
Task.Factory.StartNew(() => countries = GetUsers()),
Task.Factory.StartNew(() => countries = GetLanguages())
};
Task.WaitAll(tasks);

This looks fairly similar from a usage persepctive to what we had for executing asynchronous actions

List<Action> actions = new List<Action>()
{
() => countries = GetCountries(),
() => users = GetUsers(),
() => languages = GetLanguages(),
};
actions.ExecAsync();

One obviously noticeable difference in using the Task is that you use the Factory method StartNew to create and execute the task at the point of declaration, and what you get back is a handle to the executing Task. So the Task[] contains a handle to all the executing tasks.
The ExecAsync extension method on the other hand is passed a collection of Actions to execute. I find the idea of being able to create and execute the Task in one statement very useful and terse.

Let's now compare the performance of executing Actions using Tasks v/s executing Actions using The ExecAsync()

public static class Extensions
{
public static void ExecAsync(this IEnumerable<Action> actions)
{
int count = 0;
AutoResetEvent[] events = new AutoResetEvent[actions.Count()];
IAsyncResult[] results = new IAsyncResult[actions.Count()];
for (int i = 0; i < events.Length; i++)
{
events[i] = new AutoResetEvent(false);
}
foreach (var action in actions)
{
int localCount = count;
results[count++] =
action.BeginInvoke((r) =>
{
try
{
if (r.IsCompleted)
{
Action act = r.AsyncState as Action;
act.EndInvoke(results[localCount]);
}
}
finally
{
//set the event regardless of whether there is an exception so that the main thread
//is not blocked indefinitely.
events[localCount].Set();
}
}, action);
}
WaitHandle.WaitAll(events);
}
}
public class Program
{
public static string[] GetUsers()
{
//simulate a long running operation
Thread.SpinWait(3000);
Console.WriteLine("Current Thread:{0}", Thread.CurrentThread.ManagedThreadId);
return new[] { "Jack", "Jon", "Jim" };
}
public static string[] GetCountries()
{
//simulate a long running operation
Thread.SpinWait(3000);
Console.WriteLine("Current Thread:{0}", Thread.CurrentThread.ManagedThreadId);
return new[] { "US", "UK", "Canada" };
}
public static string[] GetLanguages()
{
//simulate a long running operation
Thread.SpinWait(3000);
Console.WriteLine("Current Thread:{0}", Thread.CurrentThread.ManagedThreadId);
return new[] { "English", "French", "German" };
}
static void Main(string[] args)
{
string[] countries;
string[] users;
string[] languages;
List<Action> actions = new List<Action>()
{
() => countries = GetCountries(),
() => users = GetUsers(),
() => languages = GetLanguages(),
};
Console.WriteLine("Running Actions Asynchronously");
Console.WriteLine("----------------------");
Stopwatch watch = Stopwatch.StartNew();
actions.ExecAsync();
watch.Stop();
Console.WriteLine("Total time taken:{0} milliseconds", watch.ElapsedMilliseconds);
Console.WriteLine();
Console.WriteLine("Running Actions using Tasks");
Console.WriteLine("----------------------");
watch.Reset();
watch.Start();
Task[] tasks = new Task[]
{
Task.Factory.StartNew(() => countries = GetCountries()),
Task.Factory.StartNew(() => countries = GetUsers()),
Task.Factory.StartNew(() => countries = GetLanguages())
};
Task.WaitAll(tasks);
watch.Stop();
Console.WriteLine("Total time taken:{0} milliseconds", watch.ElapsedMilliseconds);
}
}

Let's give it a spin and see the numbers:

The version using Tasks is almost 5 times faster! which suggests that TPL is doing a far superior job under the covers in effectively scheduling and executing the Actions.
TPL has a host of goodness which I've barely started exploring.Among other goodies, is the ability to have parent-child relationships between tasks and support for cancellation using a CancellationToken.
I hope to do more frequent posts especially around TPL since this has piqued my interest.
As always happy coding!

Using multiple Object Contexts in a Transaction

2009-05-13T23:58:54-07:00:00

The scenario: You have 2 Entity Models, and you need to call operations on the ObjectContext of each of them, the operations should be atomic, in that either both operations should succeed or fail so that your databases are consistent.
This is fairly straightforward to accomplish using a TransactionScope.
ObjectServices is smart enough to detect if the ObjectContext is in a surrounding TransactionScope and if so,use that scope.
NOTE:If a scope is not specified, then ObjectContext by default creates a new scope internally when saving changes.

using (TransactionScope scope = new TransactionScope())
{
using (RequestDBContext context = new RequestDBContext())
{
RequestType rt = new RequestType
{
Name="Test-2",
};
context.AddToRequestTypeSet(rt);
context.SaveChanges();
}
using (RequestDBContext context = new RequestDBContext())
{
Status stat = context.StatusSet.First(s => s.Name == "Pending Approval");
context.DeleteObject(stat);
context.SaveChanges();
}
scope.Complete();
}

In the above code I'm using the same EDM for both ObjectContexts, but I could very well use different EDMs.
If we reach the end of the 2nd using statement, then we can complete the transaction and persist all our changes.
If an exception is thrown then nothing is changed in the database and the transaction aborts.
Hope this helps.

UPDATE:5/16/09
Using TransactionScope requires MSDTC, the following links have good information to help setup/troubleshoot MSDTC for various environments
How to Enable MSDTC on a Web Server
New functionality in the Distributed Transaction Coordinator service in Windows Server 2003 Service Pack 1 and in Windows XP Service Pack 2
Thursday, February 19, 2009 5:08 PM mmazur How to configure and troubleshoot MSDTC

Handling WorkflowRuntime events for IIS hosted WCF + WF services

2009-04-26T22:38:11-07:00:00

The WorkflowRuntime class has a host of interesting methods and useful events. Events such as Completed, Perssited, Idled are invaluable when debugging and in understanding how a workflow instance is behaving.
These events are easily accessible when self hosting the runtime since you can just hook up event handlers for these events and react to these events as you see fit.
But, when the workflow runtime is hosted in IIS/WAS/Cassini host, you don’t have a direct handle to the runtime for hooking up these events.
The .svc file for the WCF service contains the WorkflowServiceHostFactory that WCF uses for servicing workflow service requests.

<%@ ServiceHost Language="C#"
Debug="true"
Service="RequestWFServiceLib.ApprovalWorkflow"
Factory="System.ServiceModel.Activation.WorkflowServiceHostFactory"%>

We can easily subclass WorkflowServiceHostFactory and replace the Factory attribute in the .svc file with a custom implementation of this class where in we override the CreateServiceHost Method and get a handle to the WorkflowRuntime and hook up the event handlers we need.

public class CustomWorkflowServiceHost : WorkflowServiceHostFactory
{
public override System.ServiceModel.ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)
{
ServiceHostBase hostBase = base.CreateServiceHost(constructorString, baseAddresses);
WorkflowRuntimeBehavior runtimeBehavior = hostBase.Description.Behaviors.Find<WorkflowRuntimeBehavior>();
WorkflowRuntime runtime = runtimeBehavior.WorkflowRuntime;
runtime.WorkflowIdled += runtime_WorkflowIdled;
runtime.Started += runtime_Started;
runtime.Stopped += runtime_Stopped;
runtime.WorkflowStarted += runtime_WorkflowStarted;
runtime.WorkflowSuspended += runtime_WorkflowSuspended;
runtime.WorkflowUnloaded += runtime_WorkflowUnloaded;
runtime.WorkflowCreated += runtime_WorkflowCreated;
runtime.WorkflowTerminated += runtime_WorkflowTerminated;
runtime.WorkflowResumed += runtime_WorkflowResumed;
runtime.WorkflowPersisted += runtime_WorkflowPersisted;
runtime.WorkflowLoaded += runtime_WorkflowLoaded;
runtime.WorkflowCompleted += runtime_WorkflowCompleted;
runtime.WorkflowAborted += runtime_WorkflowAborted;
return hostBase;
}
void runtime_WorkflowAborted(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Aborted", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowCompleted(object sender, WorkflowCompletedEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Completed", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowLoaded(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Loaded", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowPersisted(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Persisted", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowResumed(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Resumed", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowTerminated(object sender, WorkflowTerminatedEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Terminated", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowCreated(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Created", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowUnloaded(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Unloaded", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowSuspended(object sender, WorkflowSuspendedEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Suspended", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_WorkflowStarted(object sender, WorkflowEventArgs e)
{
Debug.WriteLine(string.Format("WorkflowInstance {0} Started", e.WorkflowInstance.InstanceId.ToString()));
}
void runtime_Stopped(object sender, WorkflowRuntimeEventArgs e)
{
Debug.WriteLine("Workflow runtime Stopped");
}
void runtime_Started(object sender, WorkflowRuntimeEventArgs e)
{
Debug.WriteLine("Workflow runtime Started");
}
void runtime_WorkflowIdled(object sender, WorkflowEventArgs e)
{
Debug.WriteLine("Workflow runtime Idled");
}
}

the .svc file is updated to include the name of our custom implementation. That’s all there is to it.

<%@ ServiceHost Language="C#"
Debug="true"
Service="RequestWFServiceLib.ApprovalWorkflow"
Factory="RequestWFServiceLib.CustomWorkflowServiceHost"%>

ASP.NET Caching

2009-04-24T23:22:07-07:00:00

I needed a quick way to cache some data for a feature I’m currently working on. The scenario is that the user should be able to type ahead and be presented with a list of matching options (AJAX auto complete). This data is coming from an external web service and is exposed via the core API of the application which in turn is exposed over WCF. So for AJAX to be able to get to this data it must talk to the WCF service, but this is not directly possible since cross site scripting is not allowed in the browser(at least not directly). So for AJAX to be able to consume this data I had to create a proxy WCF service implemented in the same project as the web application which in turn invokes the core WCF service to return this data.

Hence the proxy WCF service acts as an intermediary to fetch the data for auto complete. Now, the data is fairly static for the most part and might change every now and then. Moreover the data set is arguably large(approx 1000 items), so we now have 3 service layers (1 for the proxy WCF service, one for the core API WCF service and one for the external service which provides the actual data) to navigate through before the data is sent to the browser, clearly this is a performance bottleneck since I can’t afford to have this chatty behavior every single time a user types something in.

This leads us to caching the data, I could cache the data either in the core API object which invokes the remote service, OR in the core WCF service OR in the proxy WCF service.

Each has its own caveats. If I cache in the core API object or in the core WCF service I would need to either implement a custom caching mechanism or use an out of the box caching API such as the Enterprise Library Caching Application Block, I would also need to implement a expiration policy to ensure that the cache is flushed periodically, this would help provide some performance boost but there is still the overhead involved in marshalling this data to the client itself on every call.

If I cache at the client side (ASP.NET) then I can use the ASP.NET Cache object out of the box, and set up a time/file based dependency to periodically purge the cache, the downside is that when other clients invoke the core WCF service then the core API will invoke the external service every single time, and we could end up swamping both, the core WCF service and also the external service.

So, to address this we can cache at 2 levels; on the client side we can leverage ASP.NET Cache object and on the core API side we can use local caching.

The proxy WCF service has ASPNET compatibility mode turned on so that its invocable by Javascript/AJAX, this also allows us to tie into the ASP.NET execution pipeline and hence access the Cache object,

   1: [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

   2: public class Service1 : IService1

   3: {

4:

   5:     public string[] GetList(string prefixText, int count)

   6:     {

   7:         if (HttpContext.Current.Cache["items"] == null)

   8:         {

   9:             Debug.WriteLine("Adding Item to Cache");

  10:             var items = Enumerable.Range(1, 10).Select(i => i.ToString()).ToArray();

  11:             HttpContext.Current.Cache.Insert

  12:                 (   "items",

  13:                     items,

  14:                     new CacheDependency(HttpContext.Current.Server.MapPath("Web.config")),

  15:                     DateTime.UtcNow.AddMinutes(int.Parse(ConfigurationManager.AppSettings["CacheExpirationInMinutes"])),

  16:                     Cache.NoSlidingExpiration

  17:                 );

  18:             return items;

  19:         }

  20:         else

  21:         {

  22:             Debug.WriteLine("Read Item from Cache");

  23:             return HttpContext.Current.Cache["items"] as string[];

24:

  25:         }

  26:     }

  27: }

Basically we’ve set up a dependency to changes in web.config and also to a time interval in minutes specified in web.config as an AppSetting, this means that if the time specified elapses or web.config changes, the cache is invalidated.

This does the trick for now, if I get a chance I’ll put in the caching mechanism in the core API as well. My primary choice is using the Caching application block, but that is a post for another day.

Happy coding.