Omar AL Zabir blog on ASP.NET Ajax and .NET 3.5 : WWF

Web 2.0 AJAX Portal using jQuery, ASP.NET 3.5, Silverlight, Linq to SQL, WF and Unity

oazabir — Wed, 08 Apr 2009 18:32:00 GMT

Dropthings – my open source Web 2.0 Ajax Portal has gone through a technology overhauling. Previously it was built using ASP.NET AJAX, a little bit of Workflow Foundation and Linq to SQL. Now Dropthings boasts full jQuery front-end combined with ASP.NET AJAX UpdatePanel, Silverlight widget, full Workflow Foundation implementation on the business layer, 100% Linq to SQL Compiled Queries on the data access layer, Dependency Injection and Inversion of Control (IoC) using Microsoft Enterprise Library 4.1 and Unity. It also has a ASP.NET AJAX Web Test framework that makes it real easy to write Web Tests that simulates real user actions on AJAX web pages. This article will walk you through the challenges in getting these new technologies to work in an ASP.NET website and how performance, scalability, extensibility and maintainability has significantly improved by the new technologies. Dropthings has been licensed for commercial use by prominent companies including BT Business, Intel, Microsoft IS, Denmark Government portal for Citizens; Startups like Limead and many more. So, this is serious stuff! There’s a very cool open source implementation of Dropthings framework available at National University of Singapore portal.

Visit: http://dropthings.omaralzabir.com

I have published a new article on this on CodeProject:

http://www.codeproject.com/KB/ajax/Web20Portal.aspx

Get the source code

Latest source code is hosted at Google code:

http://code.google.com/p/dropthings

There’s a CodePlex site for documentation and issue tracking:

http://www.codeplex.com/dropthings

You will need Visual Studio 2008 Team Suite with Service Pack 1 and Silverlight 2 SDK in order to run all the projects. If you have only Visual Studio 2008 Professional, then you will have to remove the Dropthings.Test project.

New features introduced

Dropthings new release has the following features:

Template users – you can define a user who’s pages and widgets are used as a template for new users. Whatever you put in that template user’s pages, it will be copied for every new user. Thus this is an easier way to define the default pages and widgets for new users. Similarly you can do the same for a registered user. The template users can be defined in the web.config.
Widget-to-Widget communication – Widgets can send message to each other. Widgets can subscribe to an Event Broker and exchange messages using a Pub-Sub pattern.
WidgetZone – you can create any number of zones in any shape on the page. You can have widgets laid in horizontal layout, you can have zones on different places on the page and so on. With this zone model, you are no longer limited to the Page-Column model where you could only have N vertical columns.
Role based widgets – now widgets are mapped to roles so that you can allow different users to see different widget list using ManageWidgetPersmission.aspx.
Role based page setup – you can define page setup for different roles. For ex, Managers see different pages and widgets than Employees.
Widget maximize – you can maximize a widget to take full screen. Handy for widgets with lots of content.
Free form resize – you can freely resize widgets vertically.
Silverlight Widgets – You can now make widgets in Silverlight!

Why the technology overhauling

Performance, Scalability, Maintainability and Extensibility – four key reasons for the overhauling. Each new technology solved one of more of these problems.

First, jQuery was used to replace my personal hand-coded large amount of Javascript code that offered the client side drag & drop and other UI effects. jQuery already has a rich set of library for Drag & Drop, Animations, Event handling, cross browser javascript framework and so on. So, using jQuery means opening the door to thousands of jQuery plugins to be offered on Dropthings. This made Dropthings highly extensible on the client side. Moreover, jQuery is very light. Unlike AJAX Control Toolkit jumbo sized framework and heavy control extenders, jQuery is very lean. So, total javascript size decreased significantly resulting in improved page load time. In total, the jQuery framework, AJAX basic framework, all my stuffs are total 395KB, sweet! Performance is key; it makes or breaks a product.

Secondly, Linq to SQL queries are replaced with Compiled Queries. Dropthings did not survive a load test when regular lambda expressions were used to query database. I could only reach up to 12 Req/Sec using 20 concurrent users without burning up web server CPU on a Quad Core DELL server.

Thirdly, Workflow Foundation is used to build operations that require multiple Data Access Classes to perform together in a single transaction. Instead of writing large functions with many if…else conditions, for…loops, it’s better to write them in a Workflow because you can visually see the flow of execution and you can reuse Activities among different Workflows. Best of all, architects can design workflows and developers can fill-in code inside Activities. So, I could design a complex operations in a workflow without writing the real code inside Activities and then ask someone else to implement each Activity. It is like handing over a design document to developers to implement each unit module, only that here everything is strongly typed and verified by compiler. If you strictly follow Single Responsibility Principle for your Activities, which is a smart way of saying one Activity does only one and very simple task, you end up with a highly reusable and maintainable business layer and a very clean code that’s easily extensible.

Fourthly, Unity Dependency Injection (DI) framework is used to pave the path for unit testing and dependency injection. It offers Inversion of Control (IoC), which enables testing individual classes in isolation. Moreover, it has a handy feature to control lifetime of objects. Instead of creating instance of commonly used classes several times within the same request, you can make instances thread level, which means only one instance is created per thread and subsequent calls reuse the same instance. Are these going over your head? No worries, continue reading, I will explain later on.

Fifthly, enabling API for Silverlight widgets allows more interactive widgets to be built using Silverlight. HTML and Javascripts still have limitations on smooth graphics and continuous transmission of data from web server. Silverlight solves all of these problems.

Read the article for details on how all these improvements were done and how all these hot techs play together in a very useful open source project for enterprises.

http://www.codeproject.com/KB/ajax/Web20Portal.aspx

Don’t forget to vote for me if you like it.

Memory Leak with delegates and workflow foundation

oazabir — Sat, 14 Mar 2009 09:37:15 GMT

Recently after Load Testing my open source project Dropthings, I encountered a lot of memory leak. I found lots of Workflow Instances and Linq Entities were left in memory and never collected. After profiling the web application using .NET Memory Profiler, it showed the real picture:

It shows you that instances of the several types are being created but not being removed. You see the “New” column has positive value, but the “Remove” column has 0. That means new instances are being created, but not removed. Basically the way you do Memory Profiling is, you take two snapshots. Say you take one snapshot when you first visit your website. Then you do some action on the website that results in allocation of objects. Then you take another snapshot. When you compare both snapshots, you can see how many instances of classes were created between these two snapshots and how many were removed. If they are not equal, then you have leak. Generally in web application many objects are created on every page hit and the end of the request, all those objects are supposed to be released. If they are not released, then we have a problem. But that’s the scenario for desktop applications because in a desktop application, objects can remain in memory until app is closed. But you should know best from the code which objects were supposed to go out of scope and get released.

For beginners, leak means objects are being allocated but not being freed because someone is holding reference to the objects. When objects leak, they remain in memory forever, until the process (or app domain) is closed. So, if you have a leaky website, your website is continuously taking up memory until it runs out of memory on the web server and thus crash. So, memory leak is a bad – it prevents you from running your product for long duration and requires frequent restart of app pool.

So, the above screenshot shows Workflow and Linq related classes are not being removed, and thus leaking. This means somewhere workflow instances are not being released and thus all workflow related objects are remaining. You can see the number is same 48 for all workflow related objects. This is a good indication that, almost every instance of workflow is leaked because there were total 48 workflows created and ran. Moreover it indicates we have a leak from a top Workflow instance level, not in some specific Activity or somewhere deep in the code.

As the workflows use Linq stuff, they held reference to the Linq stuffs and thus the Linq stuffs leaked as well. Sometimes you might be looking for why A is leaking. But you actually end up finding that since B was holding reference to A and B was leaking and thus A was leaking as well. This is sometimes tricky to figure out and you spend a lot of time looking at the wrong direction.

Now let me show you the buggy code:

ManualWorkflowSchedulerService manualScheduler = 
  workflowRuntime.GetService<ManualWorkflowSchedulerService>();

WorkflowInstance instance = workflowRuntime.CreateWorkflow(workflowType, properties);
instance.Start();

EventHandler<WorkflowCompletedEventArgs> completedHandler = null;
completedHandler = delegate(object o, WorkflowCompletedEventArgs e)
{
    if (e.WorkflowInstance.InstanceId == instance.InstanceId) // 1. instance
    {
        workflowRuntime.WorkflowCompleted -= completedHandler; // 2. terminatedhandler

        // copy the output parameters in the specified properties dictionary
        Dictionary<string,object>.Enumerator enumerator = 
            e.OutputParameters.GetEnumerator();
        while( enumerator.MoveNext() )
        {
            KeyValuePair<string,object> pair = enumerator.Current;
            if( properties.ContainsKey(pair.Key) )
            {
                properties[pair.Key] = pair.Value;
            }
        }
    }
};

Exception x  = null;
EventHandler<WorkflowTerminatedEventArgs> terminatedHandler = null;
terminatedHandler = delegate(object o, WorkflowTerminatedEventArgs e)
{
    if (e.WorkflowInstance.InstanceId == instance.InstanceId) // 3. instance
    {
        workflowRuntime.WorkflowTerminated -= terminatedHandler; // 4. completeHandler
        Debug.WriteLine( e.Exception );

        x = e.Exception;
    }
};

workflowRuntime.WorkflowCompleted += completedHandler;
workflowRuntime.WorkflowTerminated += terminatedHandler;

manualScheduler.RunWorkflow(instance.InstanceId);

Can you spot the code where it leaked?

I have numbered the lines in comment where the leak is happening. Here the delegate is acting like a closure and those who are from Javascript background know closure is evil. They leak memory unless very carefully written. Here the delegate keeps a reference to the instance object. So, if somehow delegate is not released, the instance will remain in memory forever and thus leak. Now can you find a situation when the delegate will not be released?

Say the workflow completed. It will fire the completeHandler. But the completeHandler will not release the terminateHandler. Thus the terminateHandler remains in memory and it also holds reference to the instance. So, we have a leaky delegate leaking whatever it is holding onto outside it’s scope. Here the only thing outside the scope if the instance, which it is tried to access from the parent function.

Since the workflow instance is not released, all the properties the workflow and all the activities inside it are holding onto remains in memory. Most of the workflows and activities expose public properties which are Linq Entities. Thus the Linq Entities remain in memory. Now Linq Entities keep a reference to the DataContext from where it is produced. Thus we have DataContext remaining in memory. Moreover, DataContext keeps reference to many internal objects and metadata cacahe, so they remain in memory as well.

So, the correct code is:

ManualWorkflowSchedulerService manualScheduler = 
    workflowRuntime.GetService<ManualWorkflowSchedulerService>();

WorkflowInstance instance = workflowRuntime.CreateWorkflow(workflowType, properties);
instance.Start();
var instanceId = instance.InstanceId;

EventHandler<WorkflowCompletedEventArgs> completedHandler = null;
completedHandler = delegate(object o, WorkflowCompletedEventArgs e)
{
    if (e.WorkflowInstance.InstanceId == instanceId) // 1. instanceId is a Guid
    {
        // copy the output parameters in the specified properties dictionary
        Dictionary<string,object>.Enumerator enumerator = 
                e.OutputParameters.GetEnumerator();
        while( enumerator.MoveNext() )
        {
            KeyValuePair<string,object> pair = enumerator.Current;
            if( properties.ContainsKey(pair.Key) )
            {
                properties[pair.Key] = pair.Value;
            }
        }
    }
};

Exception x  = null;
EventHandler<WorkflowTerminatedEventArgs> terminatedHandler = null;
terminatedHandler = delegate(object o, WorkflowTerminatedEventArgs e)
{
    if (e.WorkflowInstance.InstanceId == instanceId) // 2. instanceId is a Guid
    {
        x = e.Exception;
        Debug.WriteLine(e.Exception);
    }
};

workflowRuntime.WorkflowCompleted += completedHandler;
workflowRuntime.WorkflowTerminated += terminatedHandler;

manualScheduler.RunWorkflow(instance.InstanceId);
// 3. Both delegates are now released
workflowRuntime.WorkflowTerminated -= terminatedHandler;
workflowRuntime.WorkflowCompleted -= completedHandler;

There are two changes – in both delegates, the instanceId variable is passed, instead of the instance. Since instanceId is a Guid, which is a struct type data type, not a class, there’s no issue of referencing. Structs are copied, not referenced. So, they don’t leak memory. Secondly, both delegates are released at the end of the workflow execution, thus releasing both references.

In Dropthings, I am using the famous CallWorkflow Activity by John Flanders, which is widely used to execute one Workflow from another synchronously. There’s a CallWorkflowService class which is responsible for synchronously executing another workflow and that has similar memory leak problem. The original code of the service is as following:

public class CallWorkflowService : WorkflowRuntimeService
{
    #region Methods

    public void StartWorkflow(Type workflowType,Dictionary<string,object> inparms, 
           Guid caller,IComparable qn)
    {
        WorkflowRuntime wr = this.Runtime;
        WorkflowInstance wi = wr.CreateWorkflow(workflowType,inparms);
        wi.Start();
        ManualWorkflowSchedulerService ss = 
             wr.GetService<ManualWorkflowSchedulerService>();
        if (ss != null)
            ss.RunWorkflow(wi.InstanceId);
        EventHandler<WorkflowCompletedEventArgs> d  = null;
        d = delegate(object o, WorkflowCompletedEventArgs e)
        {
            if (e.WorkflowInstance.InstanceId ==wi.InstanceId)
            {
                wr.WorkflowCompleted -= d;
                WorkflowInstance c = wr.GetWorkflow(caller);
                c.EnqueueItem(qn, e.OutputParameters, null, null);
            }
        };
        EventHandler<WorkflowTerminatedEventArgs> te = null;
        te = delegate(object o, WorkflowTerminatedEventArgs e)
        {
            if (e.WorkflowInstance.InstanceId == wi.InstanceId)
            {
                wr.WorkflowTerminated -= te;
                WorkflowInstance c = wr.GetWorkflow(caller);
                c.EnqueueItem(qn, new Exception("Called Workflow Terminated", 
                  e.Exception), null, null);
            }
        };
        wr.WorkflowCompleted += d;
        wr.WorkflowTerminated += te;
    }

    #endregion Methods
}

As you see, it has that same delegate holding reference to instance object problem. Moreover, there’s some queue stuff there, which requires the caller and qn parameter passed to the StartWorkflow function. So, not a straight forward fix.

I tried to rewrite the whole CallWorkflowService so that it does not require two delegates to be created per Workflow. Then I took the delegates out. Thus there’s no chance of closure holding reference to unwanted objects. The result looks like this:

public class CallWorkflowService : WorkflowRuntimeService
{
    #region Fields

    private EventHandler<WorkflowCompletedEventArgs> _CompletedHandler = null;
    private EventHandler<WorkflowTerminatedEventArgs> _TerminatedHandler = null;
    private Dictionary<Guid, WorkflowInfo> _WorkflowQueue = 
       new Dictionary<Guid, WorkflowInfo>();

    #endregion Fields

    #region Methods

    public void StartWorkflow(Type workflowType,Dictionary<string,object> inparms,
        Guid caller,IComparable qn)
    {
        WorkflowRuntime wr = this.Runtime;
        WorkflowInstance wi = wr.CreateWorkflow(workflowType,inparms);
        wi.Start();

        var instanceId = wi.InstanceId;
        _WorkflowQueue[instanceId] = new WorkflowInfo { Caller = caller, qn = qn };

        ManualWorkflowSchedulerService ss = 
           wr.GetService<ManualWorkflowSchedulerService>();
        if (ss != null)
            ss.RunWorkflow(wi.InstanceId);
    }

    protected override void OnStarted()
    {
        base.OnStarted();

        if (null == _CompletedHandler)
        {
            _CompletedHandler = delegate(object o, WorkflowCompletedEventArgs e)
            {
                var instanceId = e.WorkflowInstance.InstanceId;
                if (_WorkflowQueue.ContainsKey(instanceId))
                {
                    WorkflowInfo wf = _WorkflowQueue[instanceId];
                    WorkflowInstance c = this.Runtime.GetWorkflow(wf.Caller);
                    c.EnqueueItem(wf.qn, e.OutputParameters, null, null);
                    _WorkflowQueue.Remove(instanceId);
                }
            };
            this.Runtime.WorkflowCompleted += _CompletedHandler;
        }

        if (null == _TerminatedHandler)
        {
            _TerminatedHandler = delegate(object o, WorkflowTerminatedEventArgs e)
            {
                var instanceId = e.WorkflowInstance.InstanceId;
                if (_WorkflowQueue.ContainsKey(instanceId))
                {
                    WorkflowInfo wf = _WorkflowQueue[instanceId];
                    WorkflowInstance c = this.Runtime.GetWorkflow(wf.Caller);
                    c.EnqueueItem(wf.qn, 
                      new Exception("Called Workflow Terminated", e.Exception), 
                      null, null);
                    _WorkflowQueue.Remove(instanceId);
                }
            };

            this.Runtime.WorkflowTerminated += _TerminatedHandler;
        }
    }

    protected override void OnStopped()
    {
        _WorkflowQueue.Clear();

        base.OnStopped();
    }

    #endregion Methods

    #region Nested Types

    private struct WorkflowInfo
    {
        #region Fields

        public Guid Caller;
        public IComparable qn;

        #endregion Fields
    }

    #endregion Nested Types
}

After fixing the problem, another Memory Profile result showed the leak is gone:

As you see, the numbers vary, which means there’s no consistent leak. Moreover, looking at the types that remains in memory, they look more like metadata than instances of classes. So, they are basically cached instances of metadata, not instances allocated during workflow execution which are supposed to be freed. So, we solved the memory leak!

Now you know how to write anonymous delegates without leaking memory and how to run workflow without leaking them. Basically, the principle theory is – if you are referencing some outside object from an anonymous delegate, make sure that object is not holding reference to the delegate in some way, may be directly or may be via some child objects of its own. Because then you have a circular reference. If possible, do not try to access objects e.g. instance inside an anonymous delegate that is declared outside the delegate. Try accessing instrinsic data types like int, string, DateTime, Guid etc which are not reference type variables. So, instead of referencing to an object, you should declare local variables e.g. instanceId that gets the value of properties (e.g. instance.InstanceId) from the object and then use those local variables inside the anonymous delegate.

Strongly typed workflow input and output arguments

oazabir — Sat, 27 Dec 2008 15:23:00 GMT

When you run a Workflow using Workflow Foundation, you pass arguments to the workflow in a Dictionary form where the type of Dictionary is Dictionary<string, object>. This means you miss the strong typing features of .NET languages. You have to know what arguments the workflow expects by looking at the Workflow public properties. Moreover, there’s no way to make arguments required. You pass parameter, expect it to run, if it throws exception, you pass more arguments, hope it works now. Similarly, if you are running workflow synchronously using ManualWorkflowSchedulerService, you expect return arguments from the Workflow immediately, but there again, you have to rely on the Dictionary key and value pair. No strong typing there as well.

In order to solve this, so that you could pass Workflow arguments as strongly typed classes, you can establish a format that every Workflow has only two arguments named "Request” and “Response” and none other. Whatever needs to be passed to the Workflow and expected out of it, must be passed via Request and must be expected via Response properties. Now the type of these arguments can be workflow specific, it can be any class with one or more parameters. This way, you could write code like this:

The advantages of these strongly typed approach are:

Compile time validation of input parameters passed to workflow. No risk of passing unexpected object in Dictionary’s object type value.
Enforce required values by creating Request objects with non-default constructor.
Establish a fixed contract for Workflow input and output via the strongly typed Request and Response classes or interfaces.
Validate input arguments for the Workflow directly from the Request class, without going through the overhead of running a workflow.

If we follow this approach, we create workflows with only two DependencyProperty, one for Request and one for Response. Showing you an example from my open source project Dropthings, which uses Workflow for the entire Business Layer. Below you see the Workflow that executes when a new user visits http://dropthings.omaralzabir.com, creates a new user and setups all the pages and widgets for the user. It has only two Dependency property – Request and Response.

The Request parameters is of type IUserVisitWorkflowRequest. So, you can pass any class as Request argument that implements the interface.

Here I have used fancy inheritance to create Request object hierarchy. You don’t need to do that. Just remember, you can pass any class. You don’t even need to use interface for Request parameter. It can be a class directly. I use all these interfaces in order to facilitate Dependency Inversion.

Similarly, the Response object is also a class.

The Response returns quite some properties. So, it’s kinda handy to wrap them all in one property.

So, there you have it, strongly typed Workflow arguments. You can attach properties of the Request object to any activity directly form the designer:

There’s really no compromise to make in this approach. Everything works as before.

In order to make workflow execution simpler, I use a helper method like the following, that takes the Request and Response object and creates the Dictionary for me. This Dictionary always contains one “Request” and one “Response” entry.

This way, I can run Workflow in strongly typed fashion:

Here I can specify the Request, Response and Workflow type using strong typing. This way I get strongly typed return object as well as pass strongly type Request object. There’s no dictionary building, no risky string key and object type value passing. You can ignore the ObjectContainer.Resolve() stuff, because that’s just returning me an existing reference of WorkflowRuntime.

Hope you like this approach.

My first book - Building a Web 2.0 Portal with ASP.NET 3.5

oazabir — Sun, 13 Jan 2008 20:23:00 GMT

My first book "Building a Web 2.0 Portal with ASP.NET 3.5" from O'Reilly is published and available in the stores. This book explains in detail the architecture design, development, test, deployment, performance and scalability challenges of my open source web portal http://dropthings.omaralzabir.com. Dropthings is a prototype of a web portal similar to iGoogle or Pageflakes. But this portal is developed using recently released brand new technologies like ASP.NET 3.5, C# 3.0, Linq to Sql, Linq to XML, and Windows Workflow foundation. It makes heavy use of ASP.NET AJAX 1.0. Throughout my career I have built several state-of-the-art personal, educational, enterprise and mass consumer web portals. This book collects my experience in building all of those portals.

Disclaimer: This book does not show you how to build Pageflakes. Dropthings is entirely different in terms of architecture, implementation and the technologies involved.

You learn how to:

Implement a highly decoupled architecture following the popular n-tier, widget-based application model
Provide drag-and-drop functionality, and use ASP.NET 3.5 to build the server-side part of the web layer
Use LINQ to build the data access layer, and Windows Workflow Foundation to build the business layer as a collection of workflows
Build client-side widgets using JavaScript for faster performance and better caching
Get maximum performance out of the ASP.NET AJAX Framework for faster, more dynamic, and scalable sites
Build a custom web service call handler to overcome shortcomings in ASP.NET AJAX 1.0 for asynchronous, transactional, cache-friendly web services
Overcome JavaScript performance problems, and help the user interface load faster and be more responsive
Solve various scalability and security problems as your site grows from hundreds to millions of users
Deploy and run a high-volume production site while solving software, hardware, hosting, and Internet infrastructure problems

If you're ready to build state-of-the art, high-volume web applications that can withstand millions of hits per day, this book has exactly what you need.

Synchronously execute and get return parameters from Workflow

oazabir — Mon, 22 Oct 2007 02:59:00 GMT

In my DropThings project, I have used Workflows to develop the business layer that run synchronously and do most of the work in the middle-tier. The business layer facade named DashboardFacade has no code but to call different workflows. Each of the workflow serve a particular operation like new user visit, existing user visit, adding a tab, moving a widget from one column to another etc. ASP.NET page calls DashboardFacade for each user action and DashboardFacade inturn calls a workflow to respond to that user action.

“This is insane!” you are thinking. I know. Please hear me out why I went for this approach:

Architects can “Design” business facade functions in terms of Activities and developers can just fill in small amount of unit code in each activity.

This is a really good reason because Architects can save time in writing Word Documents explaining how things should work. They can directly go into Workflow Designer, design the activities, connect them, design the flow, and verify whether all input and output are properly mapped or not. This is lot better than drawing flow-charts, writing pseudocode, explaining in stylish text how an operation should work. It is also helpful for developers because they can see the workflow and easily understand how to craft the whole operation. They just open up each activity and write small amount of very specific reusable code. They know what will be the input to the Activity (like function parameters) and they know what to produce (return value of function). This makes the activities reusable and architects can reuse one activity in many workflows. Workflows can be debugged right on Visual Studio Workflow Designer. So, developers can easily find out defects in their implementation by debugging the workflow. Architects can enforce many standards like validations, input output check, Fault handling on the workflow. Developers cannot but comply with those and thus produce really good code. Another great benefit for both architect and developer is that there’s no need to keep a separate technical specification document up-to-date because the workflow is always up-to-date and it speaks for itself. If someone wants to study how a particular operation works, one can just printout the workflow and read it through.

“But what about performance”, you say? Both you and I have heard workflow foundation is a pretty big library and can be memory hog. Also the workflow runtime is quite big and takes time to start up. I did some profiling on the overhead of workflow execution and it is very fast for synchronous execution. Here's proof from the log you get in Visual Studio output window:

   1: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get User Guid        0.078125

   2: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get User Pages       0.0625

   3: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get User Setting     0.046875

   4: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get Widgets in page: 189 0.0625

   5: b030692b-5181-41f9-a0c3-69ce309d9806 Total: Existing user visit     0.265625

First four entries are the time taken by individual activities during data access only, not the total time taken to execute the whole activity. The time entries here are in seconds and the first four entries represent duration of database operations inside activities. The last one is the total time for running a workflow with the four activities shown above and some extra code. If you sum up all the individual activity execution time for database operations only, it is 0.2500 which is just 0.015625 sec less than the total execution time. This means, executing the workflow itself along with overhead of running activities takes around 0.015 sec which is almost nothing compared to the total effort of doing the complete operation.

An example of such workflow is as following:

   1: public void MoveWidgetInstance( int widgetInstanceId, int toColumn, int toRow )

   2: {

   3:   using( new TimedLog(this._UserName, "Move Widget:" + widgetInstanceId) )

   4:   {

   5:     var properties = new Dictionary<string,object>();

   6:     properties.Add("UserName", this._UserName);

   7:     properties.Add("WidgetInstanceId", widgetInstanceId);

   8:     properties.Add("ColumnNo", toColumn);

   9:     properties.Add("RowNo", toRow);

10:

  11:     WorkflowHelper.ExecuteWorkflow( typeof( MoveWidgetInstanceWorkflow ), properties );

  12:   }

  13: }

MoveWidgetInstance is a method in DashboardFacade. It just calls a workflow named MoveWidgetInstanceWorkflow which does the job for moving a widget from one column to another, rearrange the widgets on the new column, pull up widgets on the old column to remove the empty space, and update all widgets positions. If I wrote all these code in one function, it becomes quite a big function and requires documentation. But having a workflow means I have a flowchart of what's going on and I have some handy reusable Activities which I can reuse in other operations.

Implementing business layer as workflows has three important requirements:

Execute workflow synchronoulsy within the ASP.NET request thread
Get output parameters from workflow which is returned as return value from Business Facade methods
Get exceptions raised from Activities in a synchronous manner inside the same request thread

WorkflowHelper is a handy class I made, which makes use of Workflow a breeze, especially from ASP.NET. In the business layer, I need synchronous execution of workflow where the default implementation of Workflow Foundation is to work asynchronously. Moreover, I need return values from Workflows after their execution complete, which is not so easily supported due to asynchronous nature of workflow. Both of these require some tweaking with workflow runtime in order to successfully run in ASP.NET environment. You will find the source code of WorkflowHelper in the code zip file from www.dropthings.com.

WorkflowHelper.Init function initializes Workflow Runtime for ASP.NET environment. It makes sure there’s only one workflow runtime per Application Domain. Workflow Runtime cannot be created twice in the same application domain. So, it stores the reference of the Workflow Runtime in Application Context.

   1: public static WorkflowRuntime Init()

   2: {

   3:   WorkflowRuntime workflowRuntime;

4:

   5:   // Running in local mode, create an return new runtime

   6:   if( HttpContext.Current == null )

   7:     workflowRuntime = new WorkflowRuntime();

   8:   else

   9:   {

  10:     // running in web mode, runtime is initialized only once per

  11:     // application

  12:     if( HttpContext.Current.Application["WorkflowRuntime"] == null )

  13:       workflowRuntime = new WorkflowRuntime();

  14:     else

  15:       return HttpContext.Current.Application["WorkflowRuntime"] as WorkflowRuntime;

  16:   }

The initialization takes care of both ASP.NET and Console/Winforms mode. After the initialization, it registers ManualWorkflowSchedulerService, which take care of synchronous execution of Workflow. Activities.CallWorkflowService is a handy service that executes workflow synchrnously from another workflow. Read this post for details. These two services make Workflow Foundation usable from ASP.NET environment for practical scenarios.

   1: var manualService = new ManualWorkflowSchedulerService();

   2: workflowRuntime.AddService(manualService);

3:

   4: var syncCallService = new Activities.CallWorkflowService();

   5: workflowRuntime.AddService(syncCallService);

6:

   7: workflowRuntime.StartRuntime();

8:

   9: // on web mode, store the runtime in application context so that

  10: // it is initialized only once. On dekstop mode, ignore

  11: if( null != HttpContext.Current )

  12:   HttpContext.Current.Application["WorkflowRuntime"] = workflowRuntime;

13:

  14: return workflowRuntime;

15:

Workflow Runtime is initialized from Application_Start event in Global.asax. This ensures the initialization happens only once per App Domain.

   1: void Application_Start(object sender, EventArgs e)

   2: {

   3:   // Code that runs on application startup

4:

   5:   DashboardBusiness.WorkflowHelper.Init();

   6: }

The runtime is disposed from Application_End event in Gloabal.asax:

   1: void Application_End(object sender, EventArgs e)

   2: {

   3:     //  Code that runs on application shutdown

   4:     DashboardBusiness.WorkflowHelper.Terminate();

   5: }

The most interesting function is the ExecuteWorkflow function which does the following:

Execute workflow synchronously
Pass parameters to workflow
Upon completion, get output parameters from workflow and return them
Handle exceptions raised in Workflow and raise to ASP.NET exception handler

First ExecuteWorkflow creates an instance of Workflow and passes input parameters to it:

   1: public static void ExecuteWorkflow( Type workflowType, Dictionary<string,object> properties)

   2: {

   3:   WorkflowRuntime workflowRuntime = Init();

4:

   5:   ManualWorkflowSchedulerService manualScheduler = workflowRuntime.GetService<ManualWorkflowSchedulerService>();

6:

   7:   WorkflowInstance instance = workflowRuntime.CreateWorkflow(workflowType, properties);

   8:   instance.Start();

ManualWorkflowSchedulerService service executes the workflow synchronously. Next step is to hook WorkflowCompleted and WorkflowTerminated events of Workflow Runtime so that I can capture output parameters and exceptions and handle them properly.

   1: EventHandler<WorkflowCompletedEventArgs> completedHandler = null;

   2: completedHandler = delegate(object o, WorkflowCompletedEventArgs e)

   3: {

   4:   if (e.WorkflowInstance.InstanceId ==instance.InstanceId)

   5:   {

   6:     workflowRuntime.WorkflowCompleted -= completedHandler;

7:

   8:     // copy the output parameters in the specified properties dictionary

   9:     Dictionary<string,object>.Enumerator enumerator = e.OutputParameters.GetEnumerator();

  10:     while( enumerator.MoveNext() )

  11:     {

  12:       KeyValuePair<string,object> pair = enumerator.Current;

  13:       if( properties.ContainsKey(pair.Key) )

  14:       {

  15:         properties[pair.Key] = pair.Value;

  16:       }

  17:     }

  18:   }

  19: };

When workflow completes, WorkflowCompletedEventArgs gives me the OutputParameters dictionary. It contains all the public properties of Workflow. I read all the entries in the OutputParameters and update the input parameters Dictionary with the new values. This is required in the AddWidget function of DashboardFacade where I need to know the widget instance created by the workflow.

WorkflowTerminated fires when there’s an exception. When any activity inside the workflow raises exception, this event fires and workflow execution aborts. I capture this exception and throw it again so that ASP.NET can trap this exception using its default exception handler.

   1: Exception x  = null;

   2: EventHandler<WorkflowTerminatedEventArgs> terminatedHandler = null;

   3: terminatedHandler = delegate(object o, WorkflowTerminatedEventArgs e)

   4: {

   5:   if (e.WorkflowInstance.InstanceId == instance.InstanceId)

   6:   {

   7:     workflowRuntime.WorkflowTerminated -= terminatedHandler;

   8:     Debug.WriteLine( e.Exception );

9:

  10:     x = e.Exception;

  11:   }

  12: };

  13: workflowRuntime.WorkflowCompleted += completedHandler;

  14: workflowRuntime.WorkflowTerminated += terminatedHandler;

15:

  16: manualScheduler.RunWorkflow(instance.InstanceId);

17:

  18: if (null != x)

  19:   throw new WorkflowException(x);

This helps me get exceptions shown in ASP.NET Exception handler like this:

The WorkflowHelper is a reusable class that you can use in your work project. Just copy the class file out of my project and add in your own.