The Problem Solver : WCF

Activity correlation using a RequestReplyCorrelationInitializer

Maurice — Thu, 03 Dec 2009 18:16:59 GMT

In my previous post about Windows Workflow Foundation 4 I used the CorrelationScope activity to arrange for the activity correlation between a Send and the related ReceiveReply activities. That is quite easy to do and personally I find things nice and easy to arrange with both messaging activities nested in the CorrelationScope activity . The default templates use a slightly different approach though and use a RequestReplyCorrelationInitializer. The end result is the same though so just use what you think best.

Just for comparison below is the code to create the same workflow with a RequestReplyCorrelationInitializer.

static Activity CreateWorkflow()

    var getDataResult = new Variable<string>();

    var handel = new Variable<CorrelationHandle>();

    var send = new Send()

        CorrelationInitializers =

            new RequestReplyCorrelationInitializer()

                CorrelationHandle = handel

},

        OperationName = "GetData",

        ServiceContractName = "IService1",

        Endpoint = new Endpoint()

            Binding = new BasicHttpBinding(),

            AddressUri = new Uri("http://localhost:8080/GetDataService/")

},

        Content = new SendParametersContent()

            Parameters =

                {"value", new InArgument<int>(42)}

};

    var receive = new ReceiveReply()

        Request = send,

        Content = new ReceiveParametersContent

            Parameters =

                {"GetDataResult", new OutArgument<string>(getDataResult)}

};

    var workflow = new Sequence()

        Variables = { getDataResult, handel },

        Activities =

            send,

            receive,

            new WriteLine() { Text = getDataResult }

};

    return workflow;

The workflow is even a little simpler because there are fewer activities involved. And this is effectively the same as the SendAndReceiveReply and ReceiveAndSendReply templates generate in WF4.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Activity correlation in Windows Workflow Foundation 4

Maurice — Wed, 02 Dec 2009 17:57:49 GMT

There are two types of correlation to think about in Windows Workflow Foundation:

Message correlation
Basically sending multiple requests to the same workflow.
Activity correlation
Making sure two activities work together.

In this post I am going to show activity correlation

Activity correlation is used when multiple activities form a single logical action. Think about the Send and ReceiveReply activities. Two distinct activities but they work together because the first, the Send activity, send a WCF request somewhere and the second, the ReceiveReply activity, receives the response. The same goes when receiving messages.

The good thing is that when we use the ReceiveAndSendReply or SendAndReceiveReply templates everything will be done for us and the required activity correlation will be configured automatically. However sometimes we might need to do so ourselves because we create a workflow in a different way, like using regular code.

So when we start using the Send and ReceiveReply or the Receive and SendReply activities from code we need to do a bit more work. How much varies and depends on both the workflow and the hosting environment we use. The big exception to the rule is when we use the WorkflowServiceHost and no parallel or overlapping messaging activities. In that case life is simple and the WorkflowServiceHost takes care of all required correlation for us. Nice

That does leave for quite a few scenarios where we do need to add activity correlation though. The obvious one is using the WorkflowApplication or WorkflowInvoker to run our workflows. Fortunately this produces an System.InvalidOperationException with a message like:

The Send activity is configured with a request/reply Operation 'GetData', however, there is no ReceiveReply activity paired with it. Please pair Send with ReceiveReply and correlate them using a CorrelationHandle.

There are different ways to configure activity correlation but the easiest way is to wrap the activity pair in a CorrelationScope activity. The CorrelationScope will automatically create the required correlation handle and the messaging activities will use this handle.

Show me the code

The code below calls a very standard and basic WCF service passing in the value if 42 and prints the result. The important part is that the send are receive actions are done inside of a CorrelationScope activity so this workflow can run in any host.

static Activity CreateWorkflow()

    var getDataResult = new Variable<string>();

    var send = new Send()

        OperationName = "GetData",

        ServiceContractName = "IService1",

        Endpoint = new Endpoint()

            Binding = new BasicHttpBinding(),

            AddressUri = new Uri("http://localhost:8080/GetDataService/")

},

        Content = new SendParametersContent()

            Parameters =

                {"value", new InArgument<int>(42)}

};

    var receive = new ReceiveReply()

        Request = send,

        Content = new ReceiveParametersContent

            Parameters =

                {"GetDataResult", new OutArgument<string>(getDataResult)}

};

    var workflow = new Sequence()

         Variables = { getDataResult },

         Activities =

            new CorrelationScope()

                Body = new Sequence()

                    Activities = { send, receive }

},

            new WriteLine() { Text = getDataResult } }

};

    return workflow;

Update: See here for the code when using a RequestReplyCorrelationInitializer.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Online Workflow 4 presentation

Maurice — Tue, 01 Dec 2009 16:29:00 GMT

Attached are the PowerPoint sheets and samples from my online Window Workflow Foundation 4 presentation today.

Let me know if you have any questions.

WF4Demo.zip

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Creating complex activities in the workflow designer

Maurice — Mon, 30 Nov 2009 12:31:18 GMT

In Windows Workflow Foundation 4 there are a number of “activities” in the designer that aren’t really activities but activity templates. The most obvious of there are the ReceiveAndSendReply and the SendAndReceiveReply in the Messaging section of the toolbox.

If you search for either of these activities you are not going to find them. Their real name is ReceiveAndSendReplyFactory and SendAndReceiveReplyFactory respectively and they aren’t activities but activity templates.

So how to create an activity template?

Quite simply create a class and implement the IActivityTemplateFactory interface. This interface is simple and consists of a single Create function that returns the activity to be added to the workflow. Need to create multiple activities like the messaging activities do? Just wrap them in a Sequence activity and return that.

So what does that look like? Well in the case of the ReceiveAndSendReplyFactory the Create() looks like this according to Reflector:

public Activity Create(DependencyObject target)

    string str = ActivityDesignerHelper.GenerateUniqueVariableNameForContext(target, "__handle");

    Variable<CorrelationHandle> variable = new Variable<CorrelationHandle>

        Name = str

};

    VisualBasicSettings settings = new VisualBasicSettings

        ImportReferences =

            new VisualBasicImportReference

                Assembly = requiredAssemblyName,

                Import = requiredNamespace

};

    Receive receive = new Receive

        OperationName = "Operation1",

        ServiceContractName = XName.Get("IService", "http://tempuri.org/"),

        CorrelationInitializers =

            new RequestReplyCorrelationInitializer

                CorrelationHandle = new VisualBasicValue<CorrelationHandle>

                    ExpressionText = str,

                    Settings = settings

};

    return new Sequence

        Variables = { variable },

        Activities =

            receive,

            new SendReply

                DisplayName = "SendReplyToReceive",

                Request = receive

};

Nice to know what is happening behind the scenes and IActivityTemplateFactory is a nice interface to have when you start creating your own complex activities.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Nederlandse CodeCamp 2009

Maurice — Mon, 19 Oct 2009 10:26:00 GMT

Op 21 november 2009 organiseren de SDN, Stichting dotNed en VBcentral samen het derde Nederlandse Code Camp. Dit is een dag lang met code, code sharing, freaking en gezellig samenzijn. Een evenement door ontwikkelaars, voor ontwikkelaars. De regie ligt voor een belangrijk deel bij de deelnemers! Het aantal plaatsen voor deelnemers is wel beperkt tot maximaal 150. Wacht dus niet te lang met beslissen want voor je het weet is er geen plaats meer. Vergeet bij je aanmelding niet op te geven welke onderwerpen je interesse hebben. Bovendien nodigen we iedereen graag uit om zelf een sessie in te vullen.

Op de website, www.codecamp.nl, vind je meer informatie en kan je je aanmelden.

WF4&WCF and message correlation

Maurice — Wed, 02 Sep 2009 15:27:34 GMT

In the previous blog posts, here, here and here, I demonstrated how to use WCF from WF4. This same some more about sending multiple messages to the same workflow, AKA Workflow Correlation.

One of the ugly parts of Windows Workflow Foundation 3 was the message correlation part when you used WCF to send multiple messages to the same workflow.

When using WF3 you where forced to use one of the context bindings like BasicHttpContextBinding or WSHttpContextBinding. Not only that but you also had to retrieve and set the correlation context using the IContextManager and set it to some arcane guid. This guid was the workflow instance ID but having to use that on the client means the client had to be very aware of the server technology used, something that goes against the principals of WCF. Using something in the message itself as to route the message to the correct workflow was just not possible with the build-in activities.

Fortunately the WF4 story is much better. No longer do we need to use the “context” bindings but the standard WCF bindings will do just fine. And the client doesn’t have to work with the workflow instance id but can pass some more logical data, like an invoice number, that will be mapped to the correct workflow. Much better!

To demonstrate this we first need to expand the workflow so it can receive multiple messages for the same workflow. The input for both Receive activities will still be the same person class from the previous example and we will use the persons ID to route the messages.

The new workflow definition looks like this:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    var input = new Variable<Person>();

    result.Variables.Add(input);

    XNamespace ns = "http://tempuri.org";

    var handle1 = new Variable<CorrelationHandle>();

    result.Variables.Add(handle1);

    var handle2 = new Variable<CorrelationHandle>();

    result.Variables.Add(handle2);

    var receive1 = new Receive()

        OperationName = "Operation1",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle1)}

},

        CorrelationQuery = CreateCorrelationQuery(),

        CanCreateInstance = true

};

    result.Activities.Add(receive1);

    var write1 = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write1);

    var reply1 = new SendReply()

        Request = receive1,

        Value = new InArgument<string>("The result")

};

    result.Activities.Add(reply1);

    var receive2 = new Receive()

        OperationName = "Operation2",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle2)}

},

        CorrelationQuery = CreateCorrelationQuery()

};

    result.Activities.Add(receive2);

    var write2 = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called again with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write2);

    var reply2 = new SendReply()

        Request = receive2,

        Value = new InArgument<string>("The second result")

};

    result.Activities.Add(reply2);

    return result;

This is very similar to the previous workflow except we have two Receive activities and only the first is configured to allow the message to create a new instance.

The trick in getting the second message routed to the same workflow is by setting the CorrelationQuery on the two Receive activities. This is done in the CreateCorrelationQuery() function as follows:

private static CorrelationQuery CreateCorrelationQuery()

    var result = new CorrelationQuery();

    var xpath = new XPathMessageQuery()

        Namespaces = new XmlNamespaceManager(new NameTable()),

        Expression = "//sample:Person/sample:Id"

};

    xpath.Namespaces.AddNamespace("sample", "urn:WF4Sample:person");

    var messageQuerySet = new MessageQuerySet()

        Name = "RequestCorrelation"

};

    messageQuerySet.Add("PersonId", xpath);

    result.Select = messageQuerySet;

    return result;

The important part here is that the MessageQuerySet key value and the related Expression XPath must produce the same result for both request. Something that is easy here as I am sending in the same person object twice.

So the regular client has hardly any changes. All that is needed is the addition of the second operation to the ServiceContract like this:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Person request);

    [OperationContract]

    Operation1Response Operation2(Person request);

And calling the second operation like this.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Person()

        Id = 23,

        FirstName = "Joe",

        LastName = "Regular",

        BirthDate = new DateTime(1975, 7, 1)

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    //request.Id = 99;

    request.FirstName = "Maurice";

    request.LastName = "Chevalier";

    request.BirthDate = new DateTime(1888, 9, 12);

    result = proxy.Operation2(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

Note that I cam completely free to change the person object as long as I use the same Id. Should I change the Id the WorkflowServiceHost would try and find an existing workflow with the changed person Id, fail and throw a FaultException with message “The requested operation could not complete because instance key '4d7e998a-4cff-4743-3dd4-2afd5578383c' could not be found.”. Not quite sure where the Guid comes from but there is no workflow with that instanceId.

The good thing here is that the client doesn’t need to be aware of the workflow implementation on the server and the server can use “regular” message data to determine the correct workflow to send the message to.

The Workflow client has about the same change. In this case the Send activity is duplicated but other that that there is very little change and certainly no code that makes the client workflow aware of the service workflow.

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    XNamespace ns = "http://tempuri.org";

    var endpoint = new Endpoint()

        Uri = new Uri("http://localhost:8090/Sequence1/Operation1"),

        Binding = new BasicHttpBinding()

};

    var response = new Variable<string>();

    result.Variables.Add(response);

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var person = new Person()

        Id = 7,

        FirstName = "Maurice",

        LastName = "de Beijer",

        BirthDate = new DateTime(1962, 8, 24)

};

    var request = new Send()

        OperationName = "Operation1",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request);

    var reply = new ReceiveReply()

        Request = request,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply);

    var write = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write);

    var delay = new Delay()

        Duration = TimeSpan.FromSeconds(5)

};

    result.Activities.Add(delay);

    var request2 = new Send()

        OperationName = "Operation2",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request2);

    var reply2 = new ReceiveReply()

        Request = request2,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply2);

    var write2 = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write2);

    return result;

Conclusion.

The WF3/WCF marriage in Wf3.5 left quite a bit to be desired and fortunately live has become a lot simpler with WF4.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Sending your own objects to a WF4 workflow

Maurice — Thu, 20 Aug 2009 13:11:00 GMT

In the previous two blog posts (here and here) I showed how to create and expose a Windows Workflow Foundation 4 workflow via WCF and have both a workflow and a regular C# client work with it. But the parameter and return value where real simple with just a string each. So how about passing some more complex data.

To show how to do so I will replace the singe string with a person object. Admittedly not the most complex person with only an id, first and last name and their birth date but enough to demonstrate the principal.

The main of the service, which uses a WorkflowServiceHost, stays exactly the same so see the first blog post for that part. The CreateWorkflow() function will change now reflecting the fact that the service will no longer expect a string but a person object.

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    var input = new Variable<Person>();

    result.Variables.Add(input);

    XNamespace ns = "http://tempuri.org";

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var receive = new Receive()

        OperationName = "Operation1",

        ServiceContractName = ns + "MyService",

        Value = new OutArgument<Person>(input),

        AdditionalCorrelations = {

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        CanCreateInstance = true

};

    result.Activities.Add(receive);

    var write = new WriteLine()

        Text = new InArgument<string>(env => string.Format("\tThe workflow was called with '{0}'.", input.Get(env)))

};

    result.Activities.Add(write);

    var reply = new SendReply()

        Request = receive,

        Value = new InArgument<string>("The result")

};

    result.Activities.Add(reply);

    return result;

Not a big change really as we only have to change the input variable from Variable<string> to Variable<Person> and do the same with the Value property of the Receive activity which goes from new OutArgument<string>(input) to new OutArgument<Person>(input).

That leaves the Person class and this is just straightforward WCF work by turning the basic class into a data contract.

[DataContract(Namespace = "urn:WF4Sample:person")]

public class Person

    [DataMember]

    public int Id { get; set; }

    [DataMember]

    public string FirstName { get; set; }

    [DataMember]

    public string LastName { get; set; }

    [DataMember]

    public DateTime BirthDate { get; set; }

    public override string ToString()

        return string.Format("{0} {1} was born on {2} (ID: {3})", FirstName, LastName, BirthDate, Id);

Again no big deal

So with the service done we need to make the same changes to the two client applications. First the workflow client using the Send activity.

The Person class is exactly the same as on the server so just copy the code as is. Again the main in the workflow client doesn’t change, see the first blog post for that part. The part that does change a little is the CreateWorkflow() function so it creates and sends a Person instead of a string. The code goes as follows:

private static WorkflowElement CreateWorkflow()

    var result = new Sequence();

    XNamespace ns = "http://tempuri.org";

    var endpoint = new Endpoint()

        Uri = new Uri("http://localhost:8090/Sequence1/Operation1"),

        Binding = new BasicHttpBinding()

};

    var response = new Variable<string>();

    result.Variables.Add(response);

    var handle = new Variable<CorrelationHandle>();

    result.Variables.Add(handle);

    var person = new Person()

        Id = 7,

        FirstName = "Maurice",

        LastName = "de Beijer",

        BirthDate = new DateTime(1962, 8, 24)

};

    var request = new Send()

        OperationName = "Operation1",

        Endpoint = endpoint,

        AdditionalCorrelations =

           {"ChannelBasedCorrelation", new InArgument<CorrelationHandle>(handle)}

},

        ServiceContractName = ns + "MyService",

        Value = new InArgument<Person>(person)

};

    result.Activities.Add(request);

    var reply = new ReceiveReply()

        Request = request,

        Value = new OutArgument<string>(response)

};

    result.Activities.Add(reply);

    var write = new WriteLine()

        Text = new InArgument<string>(response)

};

    result.Activities.Add(write);

    return result;

Again a very minor change.

So how about the C# console client from the second blog post?

The service contract changes a little and is now:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Person request);

The person class is very different from the service though and looks like this:

[MessageContract(WrapperNamespace = "urn:WF4Sample:person")]

internal class Person

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public int Id { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public string FirstName { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public string LastName { get; set; }

    [MessageBodyMember(Namespace = "urn:WF4Sample:person")]

    public DateTime BirthDate { get; set; }

But besides the difference from using a message contract as opposed to a data contract this isn’t a big deal.

The main program changes a bit but not a whole lot. Again the only changes are due to the fact we are passing in a Person instead of a string.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Person()

        Id = 23,

        FirstName = "Joe",

        LastName = "Regular",

        BirthDate = new DateTime(1975, 7, 1)

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

All together not bad.

But so far we have only used a very simple workflow with a single message send to it. Suppose you want to send multiple messages to the same workflow? Well in that case we need to use message correlation as we will see next time.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Using Windows Workflow Foundation 4 Receive from an non WF client

Maurice — Wed, 19 Aug 2009 10:09:23 GMT

In a previous blog post I described how to use the WorkflowServiceHost and host a workflow with a Receive activity that waits for WCF messages. I also added a WF4 client that called the service and received a response. However a lot of clients out there are not going to be workflows but “regular” code that calls into out workflow. So what does it take to have a simple console application talk to our WF4 service?

The first thing we need is an service contract describing the operation we can call. In our workflow the operation is named “Operation1” and our service contact name was “MyService” with the default namespace of “http://tempuri.org”. So our service contract looks like this:

[ServiceContract]

interface MyService

    [OperationContract]

    Operation1Response Operation1(Operation1Request request);

Next up are the request and response objects. In this case I am using just two strings so they are pretty simple as well.

[MessageContract(IsWrapped = false)]

public class Operation1Request

    [MessageBodyMember(

        Namespace = "http://schemas.microsoft.com/2003/10/Serialization/",

        Name = "string")]

    public string Value { get; set; }

[MessageContract(IsWrapped = false)]

public class Operation1Response

    [MessageBodyMember(

        Namespace = "http://schemas.microsoft.com/2003/10/Serialization/",

        Name = "string")]

    public string Value { get; set; }

The interesting to note here is that I have to use a MessageContact instead of a DataContract and I have to make sure the data isn’t wrapped in an extra element. Also interesting is the fact that the data is send across using the name “string”, not the easiest C# identifier to work with so I called them “Value” instead.

Using these WCF definitions creating a simple console app that calls the workflow is a breeze.

static void Main(string[] args)

    var binding = new BasicHttpBinding();

    var endpoint = new EndpointAddress("http://localhost:8090/Sequence1/Operation1");

    var factory = new ChannelFactory<MyService>(binding, endpoint);

    var proxy = factory.CreateChannel();

    var request = new Operation1Request()

        Value = "Test from a console."

};

    var result = proxy.Operation1(request);

    Console.WriteLine(result.Value);

    Console.WriteLine("Regular client is done.");

    Console.ReadLine();

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Combined DevelopMentor instructors blog feed.

Maurice — Wed, 19 Aug 2009 07:37:12 GMT

Michael Kennedy, one of the co instructors from DevelopMentor, has created a combined feed from all the blogs of the various DevelopMentor. An awesome group of people with a lot of knowledge to share. Highly recommended in you RSS reader.

http://feeds.feedburner.com/DevelopmentorInstructors

If you want to check out a list of the individual blog feeds look here.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

.NET RIA Services and data communication

Maurice — Mon, 06 Apr 2009 13:55:02 GMT

I was working on an article about the .NET RIA Services and decided to fire up Fiddler to take a close look at the data actually passed around. I was sort of expecting to see a WCF REST based approach with XML messages. Turns out I was wrong, though I expect this option will be added in the future.

It turns out the .NET RIA Services use JSON as their serialization format. This is actually kind of nice as the DataContractJsonSerializer is part of the System.ServiceModel.Web assembly and therefore usable by all .NET clients.

The good part is that a .NET RIA Service is also usable from a JavaScript browser based client. So the same .NET RIA Services library gives us lots of client options. Now this was always the plan but it is nice to see that the default already enable it.

And the best thing?

Well that is that I was already using the .NET RIA Services and never even needed to know how the messages where actually send across the wire, something I shouldn't have to worry about when developing a RIA style application. Which is exactly the goal of the .NET RIA Services.

Cool stuff and highly recommended if you want to create browser based LOB apps

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

And now on Twitter at http://twitter.com/mauricedb.

Want to download all MIX sessions?

Maurice — Tue, 31 Mar 2009 06:52:40 GMT

Then you should check Mike Swanson’s blog post here. He has two batch files, the first downloads all MIX session recordings with in the format you like, the second renames them so it is easier to make sense of all the media file names.

If you just want a list of all sessions with download links this page might be the thing for you.

So much better than downloading them by hand. Not as good as going to the MIX itself but if you, like me, couldn’t go it is still a nice way to see all the content.

Enjoy!

Software Development Event march 30th

Maurice — Mon, 23 Mar 2009 15:40:29 GMT

Just one week to go to the next Software Development Event. The schedule with all the sessions is looking good. But this time there is even more!

We will have a Microsoft Surface machine somewhere in the common area for people to try our. And if you have never played, oops tested, with a Surface machine before this is a truly exiting machine!

Just goes to show, the SDN will go to extraordinary efforts to please all attendees

You can see the full schedule here. And don’t forget, we are not in Ede this time but in a great new location in Driebergen.

Hope to see everyone there next week Monday.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

And now on Twitter at http://twitter.com/mauricedb.

Using Windows Workflow Foundation with Windows Communication Foundation

Maurice — Sat, 21 Mar 2009 06:05:00 GMT

Attached are the PowerPoint presentation and samples from my WF with WCF presentation in Timisoara, Romania. Thanks to Ineta for providing the funding for this.

Download the PowerPoint and samples

Samples and PowerPoint from my WCF talk

Maurice — Wed, 11 Mar 2009 04:25:00 GMT

Attached is are the samples and slides I used for my intro into WCF talk yesterday at the VB Central meeting in the Netherlands.

Download samples

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Now also on twitter at http://twitter.com/mauricedb

Using a TransactionScopeActivity with a WCF ReceiveActivity revisited

Maurice — Tue, 10 Mar 2009 12:42:15 GMT

Last year Marcel and I worked on a problem using a TransactionScopeActivity inside a WCF ReceiveActivity. I blogged a number of time about our finding, for example here.

Last week I heard from Marcel that a hotfix was finally available that solves this problem. He blogged about it here. Great work to see there is a fix for this serious problem.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

And now on Twitter at http://twitter.com/mauricedb.

Looking back at the MVP Summit

Maurice — Sat, 07 Mar 2009 11:08:09 GMT

Last week lots of MVP, myself included, where in Redmond visiting Microsoft on our yearly MVP pilgrimage. The MVP Summit is always a great event. Not only do we get to talk to the MS team members who actually design and build all the software we love and use but we also get to meet each other. And with MVP’s being located around the world that is kind of rare as well.

Despite this being a great event I still have very mixed feelings about this last MVP summit. The problem isn’t the events itself or the people I met, that was al great . No the problem was in some of the technological decisions made in product groups. Unfortunately I can’t divulge details yet because I have signed an NDA but as soon .NET 4.0 as beta 1 is made public I will be able to blog about some of these decisions. And rest assured I will!

The reason we really need to is the way these important changes are communicated. Or should I say not communicated. Some very important changes where not communicated at all and could only be derived by bullet points missing from PowerPoint slides. Only when directly asked about the missing bullet point would someone say “Yes that is right, we decided to …. NDA … because … NDA …”. Sorry about the NDA part .

I can only say that these decisions are a big problem and I know several MVP’s who decided to skip other sessions on the same product as a result. I didn’t, as far as I am concerned ignoring a problem is not going to make it go away, but I really think this product team needs to reevaluate this decision and the general future trend.

Despite this hiccup I am very exited about lots of the things I got to see and am really looking forward to .NET 4 and Visual Studio 2010. Now if we only could have a beta today . When we will have a first beta is still a big question though. If a date was announced I missed it, the best I heard was a quarter and is quite a time span.

Enjoy.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Presenting at VB Central

Maurice — Tue, 03 Mar 2009 13:46:17 GMT

Next week, on march 10th, I will be doing a presentation on getting started with WCF at the VB Central user group in the Netherlands. Its a free event so if you are in the neighborhood feel free to drop by. They do ask you register beforehand. Besides my session on WCF there will also be a session on using WPF and data binding.

Mode details and the registration page can be found here.

Hope to see you there.

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Handling HTTPS SSL certificate errors

Maurice — Sat, 21 Feb 2009 20:19:05 GMT

When using self created SSL certificates with HTTPS WCF endpoints you might run into certificate validation errors. The best solution of to make sure all your certificates are fully trusted but sometimes that might not be an easy thing. The next best thing is to the the ServicePointManager.ServerCertificateValidationCallback and have add your own function to validate the certificate. This way you can ignore invalid certificates and keep going as if everything is well.

Take care though as this might open up a can of worms in a production environment.

Enjoy!

www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu

Lazy loading using Ninject

Maurice — Tue, 10 Feb 2009 06:13:00 GMT

In my previous blog post I demonstrated how you can use Ninject in your Silverlight application to automatically inject dependencies and make live easier. In the sample I injected the dependency, the PingService, inside my PageModel constructor. That worked just fine because the PingService is lightweight and stateless. However suppose creation is much more involved and you don’t need it all the time so you really want to divert creation until you really need the PingService. Well we can by just a few simple changes.

Changing the PageModel to defer loading of the PingService

This is actually a very easy change. All we need to do is change to constructor from expecting a PingService to expecting a IKernel. The IKernel is the Ninject main object and Ninject will take care of injecting itself. Kind of cool as the Page, which creates and uses the PageModel , doesn’t even need to be aware of the change, Ninject will do all the work here .

Now we can change the ExecutePing() function to use the kernel to create the PingService when needed and we are done. The new PageModel looks like this:

using System;
using System.ComponentModel;
using System.Threading;
using Ninject.Core;
 
namespace NinjectSample
{
    public class PageModel : INotifyPropertyChanged
    {
        public PageModel(IKernel kernel)
        {
            _kernel = kernel;
            _context = SynchronizationContext.Current;
        }
 
        private IKernel _kernel;
        private SynchronizationContext _context;
        public DateTime TheResult { get; set; }
 
        public void ExecutePing()
        {
            PingService.PingService proxy = _kernel.Get<PingService.PingService>();
            proxy.BeginPing(proxy_PingCompleted, proxy);
        }
 
        void proxy_PingCompleted(IAsyncResult result)
        {
            PingService.PingService proxy = (PingService.PingService)result.AsyncState;
            _context.Post(state =>
                {
                    TheResult = proxy.EndPing(result);
 
                    if (PropertyChanged != null)
                        PropertyChanged(this, new PropertyChangedEventArgs("TheResult"));
                }, null);
        }
 
        public event PropertyChangedEventHandler PropertyChanged;
    }
}

The normal generated WCF PingService will work just fine as will the Page, no changes there. The only other change we need to make is to the TestPingService as this was a very simple implementation before. Not that it is very complicated now but it needs to work with a dummy IAsyncResult. The complete fake code looks like this:

using System;
 
namespace NinjectSample
{
    public class TestPingService : PingService.PingService
    {
        public IAsyncResult BeginPing(AsyncCallback callback, object asyncState)
        {
            TestAsyncResult result = new TestAsyncResult() { AsyncState = asyncState };
            callback(result);
            return result;
        }
 
        public DateTime EndPing(IAsyncResult result)
        {
            // Birthdate Charles Babbage
            return new DateTime(1791, 12, 26);
        }
    }
 
    class TestAsyncResult : IAsyncResult
    {
        public object AsyncState { get; set; }
        public System.Threading.WaitHandle AsyncWaitHandle { get; set; }
        public bool CompletedSynchronously { get; set; }
        public bool IsCompleted { get; set; }
    }
}

Easy right

Conclusion

Even though we are now using lazy loading instead of eager loading Ninject still makes live easy for us.

Enjoy!

Download source code

Using Ninject with Silverlight to make you code more testable

Maurice — Mon, 09 Feb 2009 12:16:13 GMT

One useful feature when developing more complex code is using an inversion of control (IOC) container to do dependency injection. The basic principal of inversion of control, or dependency injection, is to pass in any dependencies when an object is created and not create them when needed. This way the code is much more decoupled and much easier to unit test.

Dependency injection with Silverlight

When developing regular .NET code there are plenty of IOC containers to choose from. However when it comes down to Silverlight the choice isn’t quite as big. I am aware of only two IOC containers you can use with Silverlight, Ninject and Unity. In this example I am going to use Ninject but the same approach would be perfectly valid using Unity.

The basic application

I am going to use a very basic application to demonstrate using Ninject with Silverlight. Just a TextBlock and Button on the form and when the button is called we are going to call a WCF service and call a ping method returning the current time.

The page is real simple. All I do is create a PageModel, make it the DataContext for the form and call the ExecutePing function when the button is clicked.

     using System.Windows;

    using System.Windows.Controls;

    namespace NinjectSample

    {

        public partial class Page : UserControl

        {

            private PageModel _model;

            public Page()

            {

                InitializeComponent();

                _model = new PageModel();

                DataContext = _model;

            }

            private void Button_Click(object sender, RoutedEventArgs e)

            {

                _model.ExecutePing();

            }

        }

    }

The PageModel class is also very straightforward and looks like this:

    using System;

    using System.ComponentModel;

    using NinjectSample.PingService;

    namespace NinjectSample

    {

        public class PageModel: INotifyPropertyChanged

        {

            public DateTime TheResult { get; set; }

            public void ExecutePing()

            {

                PingServiceClient proxy = new PingServiceClient();

                proxy.PingCompleted += proxy_PingCompleted;

                proxy.PingAsync();

            }

            void proxy_PingCompleted(object sender, PingCompletedEventArgs e)

            {

                TheResult = e.Result;

                if (PropertyChanged != null)

                    PropertyChanged(this, new PropertyChangedEventArgs("TheResult"));

            }

            public event PropertyChangedEventHandler PropertyChanged;

        }

    }

So this works but there is a problem. This code is not very testable as it creates the PingServiceClient, which calls the server, while executing. Lets see how we can refactor this using Ninject to create a bit more maintainable and testable code.

Adding Ninject

First make sure you download the Silverlight version of Ninject from the website here. And add a reference to the DLL’s from the Silverlight project.

So lets do the minimum work to use Ninject and have it insert the dependency. Instead of using the new operator to create the PageModel we are going to let Ninject handle this using the following code:

IKernel kernel = new StandardKernel();

_model = kernel.Get<PageModel>();

And to have Ninject inject the dependency on the WCF service we are going to change it to receive he proxy object in the constructor like this:

    public class PageModel : INotifyPropertyChanged

    {

        public PageModel(PingServiceClient proxy)

        {

            _proxy = proxy;

        }

        private PingServiceClient _proxy;

        public DateTime TheResult { get; set; }

        public void ExecutePing()

        {

            _proxy.PingCompleted += proxy_PingCompleted;

            _proxy.PingAsync();

        }

        void proxy_PingCompleted(object sender, PingCompletedEventArgs e)

        {

            _proxy.PingCompleted -= proxy_PingCompleted;

            TheResult = e.Result;

            if (PropertyChanged != null)

                PropertyChanged(this, new PropertyChangedEventArgs("TheResult"));

        }

        public event PropertyChangedEventHandler PropertyChanged;

    }

A few small changes and everything still works exactly as before.

So what did we gain? Only the fact that the dependency between the PageModel and the PingServiceClient is slightly decoupled. However because we are still using concrete classes and the PingAsync() is not virtual we have gained very little.

Making the code more testable

In order to make the code more testable we need to start using the PingService interface instead of the PingServiceClient concrete type. So lets make some changes to the code. First of all we need to change the PageModel class to use the interface. This means we can no longer use the PingAsync function and PingCompleted event as they are part of the concrete class. Instead we have to use the BeginPing() and EndPing() functions.

One extra complication here is that the standard generated proxy makes sure the callback event is raised on the right thread, something we now have to take care of using a SynchronizationContext.

The new PageModel looks like this:

    using System;

    using System.ComponentModel;

    using System.Threading;

    namespace NinjectSample

    {

        public class PageModel : INotifyPropertyChanged

        {

            public PageModel(PingService.PingService proxy)

            {

                _proxy = proxy;

                _context = SynchronizationContext.Current;

            }

            private PingService.PingService _proxy;

            private SynchronizationContext _context;

            public DateTime TheResult { get; set; }

            public void ExecutePing()

            {

                _proxy.BeginPing(proxy_PingCompleted, null);

            }

            void proxy_PingCompleted(IAsyncResult result)

            {

                _context.Post(state =>

                    {

                        TheResult = _proxy.EndPing(result);

                        if (PropertyChanged != null)

                            PropertyChanged(this, new PropertyChangedEventArgs("TheResult"));

                    }, null);

            }

            public event PropertyChangedEventHandler PropertyChanged;

        }

    }

With this in pace we need to configure Ninject a bit so it knows which object to create as the PingService. If we forget to do so we will see a Ninject.Core.ActivationException with the following message:

Error activating PingService: no matching bindings are available, and the type is not self-bindable (or implicit binding is disabled).
Activation path:
1) active request for PingService

Configuring Ninject

The way to configure Ninject is to create a module loader class derived from StandardModule and implement the Load() function specifying the dependencies like this:

    using Ninject.Core;

    using NinjectSample.PingService;

    namespace NinjectSample

    {

        public class PingModule : StandardModule

        {

            public override void Load()

            {

                Bind<PingService.PingService>().To<PingServiceClient>();

            }

        }

    }

Next we need to tell Ninject which module to use by passing it into the constructor like this:

public Page()

    InitializeComponent();

    IKernel kernel = new StandardKernel(new PingModule());

    _model = kernel.Get<PageModel>();

    DataContext = _model;

And again everything is working again

Adding a test service

Now we have fully decoupled the pageModel from the service we can create a test service so we execute the code without actually calling the WCF service.

First we need to create a test service like this:

    using System;

    namespace NinjectSample

    {

        public class TestPingService : PingService.PingService

        {

            public IAsyncResult BeginPing(AsyncCallback callback, object asyncState)

            {

                callback(null);

                return null;

            }

            public DateTime EndPing(IAsyncResult result)

            {

                // Birthdate Charles Babbage

                return new DateTime(1791, 12, 26);

            }

        }

    }

The code is simple and just returns a fixed date.

Next we need to tell Ninject which implementation to use. There are several ways to do this. I suppose the best is to create a specific module for testing but in this case I have taken the route of conditionally binding dependencies in a single module like this:

    using Ninject.Core;

    using NinjectSample.PingService;

    namespace NinjectSample

    {

        public class PingModule : StandardModule

        {

            private bool _testMode;

            public PingModule(bool testMode)

            {

                _testMode = testMode;

            }

            public override void Load()

            {

                Bind<PingService.PingService>().To<PingServiceClient>()

                    .OnlyIf(p => _testMode == false);

                Bind<PingService.PingService>().To<TestPingService>()

                    .OnlyIf(p => _testMode == true);

            }

        }

    }

Now I can vary the behavior by just passing in true or false when creating the Ninject module.

Conclusion

Using Ninject, or another IOC container, makes it easier to test code. Of course Ninject isn’t a silver bullet here, the same effect could be achieved with manual injection. But thinking about dependencies this way makes code easier to develop and test. And why do dependency inject by hand if an IOC container like Ninject can do it for you!

Enjoy!

Source code download