Windows Workflow Foundation

Getting WCF to work with Azure

paulschapman — Thu, 08 Jan 2009 05:04:11 GMT

Silverlight makes creating compelling Rich Internet Applications fairly easy. That said the cut down version of .Net means some things that you would do within an application have to be relegated to Web Services which can benefit from the full .Net library. One of these is of course Azure, after all that is the whole point - an online store of Business Logic and data.

The application I'm working on uses Silverlight on the front end, and Azure will provide the bulk of the backend. There are reasons for this; my budget for the site is not that large, adopting Azure means first off that it will be free during development, but almost as important - hosting costs will be related to the success of the site.

Thing is dealing with pre-beta software has meant an increase in grey hairs and those that are left are getting fewer. One of the parts that needs looking at is in WCF. If you run the Azure Labs the WCF lab does not work. This is because the Development Fabric is not hosting the service correctly, and WCF metadata is not being returned correctly.

Thanks must go to David Burela and his House-o-blog. In it he describes a way to get WCF working despite the problems with the Development Fabric. So what I thought I would do is write a version of the Azure Services Training Kits Exercise 3: Hosting a WCF Service

So the following is Exercise 3, but with the changes made to ensure it works

1. Open the project you created in Exercise 2 or open the begin.sln solution file located in C:\AzureServicesKit\Labs\BuildingWindowsAzureServices\Ex03-HostingWCFService\begin\.

Note:

If you closed Visual Studio, be sure to open it elevated as Administrator, from Start | All Programs | Microsoft Visual Studio 2008 right-click Microsoft Visual Studio 2008 and choose Run as Administrator.

2. Add the WCF service file. To do this, right-click the RDCompute_WebRole node in Solution Explorer, point to Add and select New Item. In the Add New Item dialog, select the WCF Service template, change the Name to MessageLogger.svc, and then click Add.

Note:

The template adds an IMessageLogger interface, which defines the service contract and a MessageLogger class that implements the contract.

3. Update the contract interface to define a method to send messages to the service. Open the IMessageLogger.cs file in the text editor. This file contains the generated IMessageLogger interface, which includes a single method named DoWork. Delete this method, and insert a LogMessage method to replace it (shown highlighted in bold text below.)

[ServiceContract]
public interface IMessageLogger
{
[OperationContract]
void LogMessage(string message);
}

4. Implement the contract interface in the MessageLogger service. Open the MessageLogger.svc.cs file in the text editor. This file contains the service implementation and includes a skeleton DoWork method. Again, delete this method and insert the following code that implements the LogMessage method in its place.

public void LogMessage(string message)
{
MessageHelper.SaveMessage(message);
}

5. Change the binding of the IMessageLogger endpoint to use a basicHttpBinding. Open the Web.config file in the text editor and locate the RDCompute_WebRole.MessageLogger service configuration in the services section inside system.serviceModel. This should be towards the end of the file. Change the binding attribute of the single endpoint contained in this section from wsHttpBinding to basicHttpBinding. The endpoint configuration after the change should be as follows:

<endpoint address="" binding="basicHttpBinding" contract="RDCompute_WebRole.IMessageLogger">
  <identity>
    <dns value="localhost" />
  </identity>
</endpoint>

 
6. Right click on the ASP.Net project (AzureWCFDemo_WebRole) and set it as the startup project
 
7. Right click on the MessageLogger.svc file and select View in Browser
 
8. When IE starts copy the address displayed in the Address Bar to the clipboard
 
9. Start a new instance of Visual Studio
 
10. Create a console client project by select File, New Project
 
 

 
11. Add a reference to the message logging service. In Solution Explorer, right-click the MessageGenerator project node, and select Add Service Reference. 
Paste the address you copied from the IE instance into the Add Service Reference dialog and click Discover. Change the Namespace to RDService and click OK
 
12. Add the following code to the main function
 
using (RDService.MessageLoggerClient client = new RDService.MessageLoggerClient())
  {
    Console.WriteLine("Enter your messages ('quit' to exit)");
    while (true)
    {
      try
      {
        string message = Console.ReadLine();
        if (message.Equals("quit", StringComparison.CurrentCultureIgnoreCase))
          break;
        client.LogMessage(message);
      }
      catch (Exception ex)
      {
           Console.WriteLine(ex.Message);
      }
    }
  }

 
13. Return to the instance of Visual Studio running the ASP.Net application and stop debugging the ASP.Net Application
 
13. Right click the Azure project and set as the Start-up project, then start debugging. The Dev Fabric should start running and hosting the WCF service. 
When IE starts note the port number. More than likely this will be 81.
 
14. Finally, go back to our client project. Open the app.config file and change the endpoint address so that is the port number found in the previous step.
 
15. Now run the client project. It should be able to call the WCF Service hosted within the Development Fabric
 
If everything worked you should have completed Exercise 3. Hopefully a fix to the problem will be forthcoming. Excercise 4 should be fun, since in this instance 
we will be calling the Web Service from within Azure (rather than a standard Windows Application) and so this technique may need adapting.

A first attempt with Windows Workflow Foundation #2

paulschapman — Fri, 04 Jul 2008 03:30:19 GMT

The form I need to model with Workflow is split into sections. Depending on what section it will be filled in by anyone of three different groups of people. However at the moment I am trying to deal with the communication between the host application and the workflow itself.

First part of that is to define the Arguments that will be passed to our Event

Imports System
Imports System.Collections
Imports System.Collections.Generic
Imports System.Text
Imports System.Workflow.Activities
Imports System.Workflow.ComponentModel

Namespace FormularyWorkflow

     <Serializable> _
     Public Class SectionA_ApplicantEventArgs
          Inherits ExternalDataEventArgs
          Dim _Applicant As String
          Dim _Email As String
          Dim _ApplicationDate As Date = Date.Now
          Dim _Signed As Boolean = False

          Public Sub New(ByVal InstanceId As Guid)
               MyBase.New(InstanceId)
          End Sub

          Public Property Applicant() As String
               Get
                    Return _Applicant
               End Get

               Set(ByVal value As String)
                    _Applicant = value
               End Set

End Property

          Public Property Email() As String
               Get
                    Return _Email
               End Get

               Set(ByVal value As String)
                    _Email = value
               End Set
          End Property

          Public Property ApplicationDate() As Date
               Get
                    Return _ApplicationDate
               End Get

               Set(ByVal value As Date)
                    _ApplicationDate = value
               End Set
          End Property

          Public Property Signed() As Boolean
               Get
                    Return _Signed
               End Get

               Set(ByVal value As Boolean)
                    _Signed = value
               End Set
          End Property
     End Class
End Namespace

There is not much to say about this bit of code. First we import the workflow namespaces; Workflow.Activities and Workflow.ComponentModel. Our class inherits from ExternalDataEventArgs. Finally we define a constructor for the class which simple calls the base class constructor with an indentifier for the workflow.

To define the way that our workflow exchanges data we now create the actual interface.

Imports System
Imports System.Collections
Imports System.Collections.Generic
Imports System.Text
Imports System.Workflow.Activities
Imports System.Workflow.ComponentModel

Namespace FormularyWorkflow

<ExternalDataExchange> _

     Public Interface IFormularyDataExchange
          Event ApplicationEventHandler As EventHandler(Of SectionA_ApplicantEventArgs)
     End Interface
End NameSpace

A first attempt with Windows Workflow Foundation #1

paulschapman — Thu, 03 Jul 2008 04:08:09 GMT

One of my current clients has a need for a workflow and document management system to manage applications. This has prompted me to look at Windows Workflow Foundation to manage this application process.

The workflow has a number of advantages over writing the whole thing from scratch;

Most businesses have processes; be that purchasing, selling, staff applications. Once a process has been determined the workflow can be designed graphically - and this graphical design drives the code generation, meaning the process is always going to be closer to the users requirements.
The workflow system manages the running of the process, rules can be defined and this process will always be the same
In addition to controlling and managing a workflow, a workflow process can be tracked - it is possible to find out exactly where a workflow is, but also the stages it went through before.

Because most of our workflows involve humans who do not always want to do the stages when the computer does; the workflow must therefore wait. Easiest way of doing this is to use a State Machine Workflow; which moves from state to state as each stage is done.

In order for the workflow to work however we need to define the parameters that will drive it. So what we do first is define a class that inherits from ExternalDataEventArgs. and then define an interface with each of our events defined within it. Once we have done that we can then use a tool called 'Windows Communications Activities Generator to generate the classes that will define our communications.

When could run the wca tool from within Visual Studio in which case it will pick up it's parameters from the solution currently loaded. We set this up by using the Tools, External tools option of the Visual Studio IDE. Clicking on the 'Add' button allows you to add another tool to the menu.

My settings for the Windows Communications Activities are as follows;

Title: Workflow Communications Activities
Command: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\WCA.exe
Arguments: $(TargetName)$(TargetExt) /o:$(ProjectDir) /l:vb
Intial directory: $(TargetDir)

I've also checked 'Use Output window' - so I can see the wca tools output but have left 'Prompt for arguments' and Treat output as Unicode' clear.