---

January 2009

Volume 24 Number 01

First Look - WCF and WF Services in .NET Framework 4.0 and "Dublin"

By Aaron Skonnard | January 2009

This article is based on a prerelease version of the .NET Framework 4.0 and "Dublin." All information is subject to change.

This article discusses: WF activity library and designer WCF improvements in the .NET Framework 4.0 A guide to the “Dublin” extensions Building and deploying services with “Dublin”

This article uses the following technologies: .NET Framework 4.0, “Dublin”

Contents

Moving toward the .NET Framework 4.0
WF Base Activity Library
WF Activity Programming Model
More New WCF Features in the .NET Framework 4.0
The Need for "Dublin"
A Guide to "Dublin"
Building a WCF Workflow Service for "Dublin"
Deploying Applications with "Dublin"
Managing Running Applications
Updating Running Applications
Monitoring Running Applications
From "Dublin" to "Oslo"?
What about BizTalk Server?

At the Professional Developer's Conference(PDC) in October 2008, Microsoft released the details around numerous improvements that will ship in the Microsoft .NET Framework 4.0, specifically in the areas of Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF). Microsoft also debuted some extensions to Windows Server—code-named "Dublin"—that provide an improved hosting and management experience for WCF and WF applications.

The integration of WF and WCF in the .NET Framework 4.0 will make it simpler to develop distributed service-oriented apps. You will be able to build stateful workflow services using a completely declarative model that offers more flexibility and business agility.

The new hosting and management extensions introduced by "Dublin" complement these framework advances. The combination of advances in the framework itself and in the operational tools that support the framework means that the application server capability in Windows Server will make a significant leap forward.

In this article, I will explore some of the key new WCF and WF features in the .NET Framework 4.0 as well as the new application server capabilities provided by the "Dublin" extensions.

Moving toward the .NET Framework 4.0

WCF and WF are complementary technologies. If you are unfamiliar with them, a simple way to think about the pair is: WCF on the outside, WF on the inside. WCF is used to expose the external service interface of an application, and WF is used to describe the internal flow, states, and transitions of an application.

The .NET Framework 3.5 introduced some compelling integration between the two, specifically in the form of the WF Send and Receive activities. With these activities, you can employ WF to simplify the process of coordinating multiple service interactions to fulfill complex, long-running workflows. You can also use these activities to extend the reach of your WF workflows by enabling them with WCF endpoints (see Figure 1). This essentially allows you to employ WF as the implementation for your WCF services, what I will call WCF workflow services throughout this article.

Figure 1 WCF Workflow Services

Although it's possible to implement WCF workflow services in the .NET Framework 3.5, it isn't easy. For starters, the integration layer between WCF and WF leaves something to be desired. In the .NET Framework 3.5, the WCF artifacts have to be defined and configured using the WCF programming and configuration model, while the workflow is defined using a different model. Ultimately, you end up with multiple artifacts that need to be deployed, configured, and managed separately.

Another reason for the difficulty is that the current base activity library concentrates on flow-control and logic activities and doesn't provide much in the way of work activities. So you must write a library of custom activities before you can implement real-world workflow services with WF. Given the complexity of that job, some developers have given up before they are able to experience the benefits of WF.

In addition to these issues, current WF also lacks tool support for eXtensible Application Markup Language (XAML)-only workflows, which are also referred to as declarative workflows because they're completely described in an XML file without any codebehind files. The XAML-only approach creates some compelling workflow hosting and deployment possibilities. The powerful thing about a declarative workflow is that it's just data that can be stored anywhere and executed within a WF runtime environment that knows about the activities being used.

A declarative workflow can be deployed to a runtime in the cloud or to a workstation under your desk (assuming the activities have been deployed to the runtime host). Declarative workflows are also easier to version, and they can be used in partial-trust scenarios (think "cloud"). The XAML-only model is also easier to build tools around since the tools are just working with XML files.

In general, the XAML-only model has always been the ultimate vision for WF as a technology, which is evident in the early writings by its architects. However, the current WF tool support doesn't fully realize that vision. While it's possible to build XAML-only workflows with the .NET Framework 3.5, you have to work around the current Visual Studio templates and give up important features, such as debugging.

The main goal for WCF and WF in the .NET Framework 4.0 is to simplify the developer experience around declarative workflows and services, fully embracing a XAML-only model. In addition, Microsoft wanted to take things one step further by making it possible to define declarative workflow services. That is, WCF services that are completely defined in terms of XAML, including the service contract definitions, endpoint configurations, and the actual service implementation (in the form of a XAML-based workflow).

To accomplish this, Microsoft has made numerous improvements in the .NET Framework 4.0, including an extended base class activity library, a simpler programming model for custom activities, a new flowchart workflow type, and numerous WCF-specific improvements.

WF Base Activity Library

The .NET Framework 4.0 comes with an enhanced base activity library containing several new activities (see Figure 2). Microsoft also plans to begin making additional WF activities available through CodePlex between major .NET Framework releases. You'll also begin to see more work activities (such as the PowerShell­Command activity) appear in future releases (or on CodePlex), thereby reducing the need for custom activity development. And because Microsoft is using CodePlex, you have a good opportunity to make your opinion heard on what additional activities you'd like to see.

The .NET Framework 4.0 introduces a few core activities that provide more flow-control options, including the FlowChart, For­Each, DoWhile, and Break activities. The new FlowChart activity is one of the most interesting additions because it offers a nice middle ground between the Sequential and StateMachine flow-control models. FlowChart lets you use a step-by-step approach, enhanced with simple decisions and switches, but it also allows you to return to previous activities in the workflow. Flowcharts in general seem more intuitive to many users. Figure 3shows what the FlowChart designer looks like in the new workflow designer in Visual Studio 2010 (see "The New Workflow Designer" sidebar for more).

Figure 3 The New FlowChart Activity Designer

The .NET Framework 4.0 also introduces some new runtime activities for invoking CLR methods (MethodInvoke), for assigning values to workflow variables (Assign), and for explicitly persisting a running workflow instance (Persist).

Finally, the .NET Framework 4.0 comes with a new set of WCF-based activities that simplify the process of exposing workflows as services, or consuming services from within your workflows. The .NET Framework 3.5 provided two activities—Send and Receive—for sending and receiving messages through WCF. In version 4.0, you'll find SendMessage and Receive­Message activities—meant for sending and receiving one-way messages (similar to Send and Receive in version 3.5)—as well as a higher-level abstraction for request/response operations through the Client­Operation and Service­Operation activities. A workflow that wants to expose a service operation should use the ServiceOperation activity. Whereas a workflow that wants to consume an external service should use the ClientOperation activity.

In addition to these core WCF activities, the .NET Framework 4.0 also provides support for correlation across different one-way operations to ensure that a particular message makes it back to the correct workflow instance. It comes with an activity for defining a new correlation scope (CorrelationScope) and for initializing the correlation values (InitializeCorrelation) before sending an outbound message through WCF.

The New Workflow Designer

A new workflow designer added to Visual Studio 2010 provides a compelling graphical user experience for many of the key WCF and WF features discussed in this article. It provides features such as improved workflow navigation (drilling into composite activities) with bread-crumb trails for going back in scope, in-place activity editing (reducing the need for the Properties window), zoom capabilities, and overview navigation. In addition, the new designer provides an improved model for customization and re-hosting. Visual Studio 2010 will also offer a suite of new or improved project templates that make it easy to get started quickly with flowcharts and XAML-only workflows, and it will provide full support for XAML-based debugging when working with declarative workflows and services.

WF Activity Programming Model

Even with these improvements, you may still need to write custom activities sometimes. So to make it easier, Microsoft redesigned the base classes for custom activities. The new base class for custom activities is called Workflow­Element, and there's another class that derives from it called Activity. The Activity class makes it easy to create new custom activities from existing activities without writing much, if any, code.

Figure 4, for example, shows how to define a new custom activity called CopyFile by deriving from Activity and overriding CreateBody. The implementation creates a customized PowerShell­Command instance configured to use the built-in copy-item command. You can also easily build custom activities like this one using the new workflow designer in Visual Studio 2010, through the graphical activity designer, if you'd rather avoid this type of code altogether.

Figure 4 A Custom CopyFile Activity

class CopyFile: Activity { public InArgument < string > Source { get; set; } public InArgument < string > Destination { get; set; } protected override WorkflowElement CreateBody() { return new PowerShellCommand { CommandText = "copy-item", Parameters = { { "path", new InArgument < string > (Source) }, { "destination", new InArgument < string > (Destination) }, { "recurse", new InArgument < bool > (false) } }, }; } }

When you need to define a custom activity from scratch (something not based on existing activities), you must derive from Workflow­Element and override the Execute method. This approach requires a little more code, and it's similar to how it works today when deriving from Activity. However, Microsoft has further simplified things around writing these custom activities.

One of the things that makes writing a custom activity difficult is managing data flow into and out of the activity. For example, today it is not possible to define a set of typed arguments that get passed into and out of an activity. Normally, developers write custom classes that serialize and deserialize arguments from a workflow queue (for more, see Michael Kennedy's article, " Web Apps that Support Long-Running Operations.") Writing this plumbing code isn't difficult, but it is extra work that distracts from the central goal of modeling application flow. The .NET Framework 4.0 extends the activity programming model with three new data flow concepts that promise to simplify things significantly: arguments, variables, and expressions.

You use arguments to define the way data flows in and out of an activity. Each argument has a specified binding direction such as input, output, or input/output. The following example shows how to author a simple Audit activity with a single input argument called "AuditMessage":

public class Audit: WorkflowElement { public InArgument < string > AuditMessage { get; set; } protected override void Execute(ActivityExecutionContext context) { WriteToEventLog(AuditMessage.Get(context)); } }

Variables provide a way for declaring named storage for data. You can define variables in code as well as in XAML-based workflows. Variables can also be defined at different scopes within a workflow (within nested workflow elements), and they are part of the workflow program definition at design time, while the values are stored in the workflow instance at run time.

The following example shows how to write a XAML workflow that defines a variable named message, assigns it a value (using the new Assign activity), and then passes the variable's value into the custom Audit activity defined previously:

<Sequence xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel" xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema" xmlns:s="clr-namespace:Samples;assembly=Samples" xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"> <Sequence.Variables> <Variable Name="message" x:TypeArguments="p:String" /> </Sequence.Variables> <Assign x:TypeArguments="p:String" To="[message]" Value="Audit message: something bad happened" /> <s:Audit Text="[message]" /> </Sequence>

An expression is a construct that takes one or more input arguments, performs some operation or behavior on those input arguments, and then returns a value. Expressions are defined by deriving a class from ValueExpression, which itself derives from WorkflowElement, so expressions can be used anywhere an activity can be used. Expressions can also be used as a binding to another activity's argument. This example defines a simple Format expression:

public class Format: ValueExpression < string > { public InArgument < string > FormatString { get; set; } public InArgument < string > Arg { get; set; } protected override void Execute(ActivityExecutionContext context) { context.SetValue(Result, String.Format(FormatString.Get(context), Arg.Get(context))); } }

You can incorporate this expression into your XAML workflows like any other activity. For example, the following workflow illustrates how to pass the result of the Format expression into the Audit activity to write the result to the event log (this assumes that Audit's content maps to the message argument):

<Sequence xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel" xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema" xmlns:s="clr-namespace:Samples;assembly=Samples" xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"> <Sequence.Variables> <Variable Name="message" x:TypeArguments="p:String" /> </Sequence.Variables> <s:Audit> <s:Format FormatString="Audit message: {0}" Arg="[message]"/> </s:Audit> </Sequence>

Another thing to note is that there's nothing special about the root activity. Anything that derives from Workflow­Element can be used at the root or anywhere within the workflow. This lets you arbitrarily compose different workflow styles within one another (for example, a state machine within a flowchart within a sequence).

Most of these programming model changes help make declarative workflows first-class citizens because you no longer need imperative codebehind files for defining data-flow properties—it can all be done declaratively in XAML now. However, since these are pretty fundamental changes, they required some significant changes to the WF runtime that ultimately break compatibility with your .NET Framework 3.x activities (see the sidebar on migrating workflows for more information). Despite that, though, Microsoft believes that simplifying the WF programming model will greatly benefit WF developers over time.

Migrating Workflows to .NET 4.0

The new .NET Framework 4.0 activity programming model required some significant changes to the core WF runtime. As a result, custom activities designed for the .NET Framework 3.0 and 3.5 won't be able to run within a .NET Framework 4.0 workflow host without some special care.

To facilitate interoperability, the .NET Framework 4.0 comes with a special Interop activity that makes it easy to wrap a custom .NET 3.x activity within a .NET 4.0 host. This approach doesn't work for all .NET 3.x activities—it specifically does not work for root activities. Hence, when moving to Visual Studio 2010, you'll need to redesign your workflows using the new workflow designer (because it has also changed extensively), then you can wrap custom .NET 3.x activities using the new Interop activity within your new workflow definitions.

More New WCF Features in the .NET Framework 4.0

It's easy to see how you might implement a WCF service with a workflow, but to truly produce a declarative workflow service, you will also need a way to define service contracts and to configure endpoint definitions using the declarative XAML-only model. This is precisely what WCF in the .NET Framework 4.0 brings to the table. Suppose you have this WCF service contract definition:

[ServiceContract] public interface ICalculator { [OperationContract] int Add(int Op1, int Op2); [OperationContract] int Subtract(int Op1, int Op2); };

In the .NET Framework 4.0, you can define the same contract declaratively using the following XAML definition:

<ServiceContract Name="ICalculator"> <OperationContract Name="Add"> <OperationArgument Name="Op1" Type="p:Int32" /> <OperationArgument Name="Op2" Type="p:Int32" /> <OperationArgument Direction="Out" Name="res1" Type="p:Int32" /> </OperationContract> <OperationContract Name="Subtract"> <OperationArgument Name="Op3" Type="p:Int32" /> <OperationArgument Name="Op4" Type="p:Int32" /> <OperationArgument Direction="Out" Name="res2" Type="p:Int32" /> </OperationContract> </ServiceContract>

Now that you have the service contract defined in XAML, the next step is to define how you want to project the contract onto the wire. The .NET Framework 4.0 introduces the concept of a contract projection to separate the logical contract definition from the representation of the messages that are sent and received. This allows you to define a single-service contract that can be projected differently to support different messaging styles.

For example, you can have one contract projection for SOAP-based messaging and another projection for REST/POX messaging, but both are based on the same logical service contract. Here's how you can define a SOAP contract projection for the service contract just defined:

<Service.KnownProjections> <SoapContractProjection Name="ICalculatorSoapProjection"> <!-- service contract definition goes here --> </SoapContractProjection> </Service.KnownProjections>

With this contract definition and projection in place, you are able to implement the service logic in XAML. The root element for the XAML service definition is Service. The Service element holds the contract and projection definitions in the Service.KnownProjections child element. The service implementation goes in the Service.Implementation element (which is a declarative workflow). And finally, the service's endpoint configuration goes in the Service.Endpoints element. Figure 5shows the complete declarative service definition in XAML.

Figure 5 Declarative WCF Service

<Service xmlns="clr-namespace:System.ServiceModel;assembly=System.WorkflowServiceModel" xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema" xmlns:ss="clr-namespace:System.ServiceModel;assembly=System.ServiceModel" xmlns:sw="clr-namespace:System.WorkflowServiceModel;assembly=System.WorkfowServiceModel" xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml" xmlns:x2="https://schemas.microsoft.com/netfx/2008/xaml"> <Service.KnownProjections> <SoapContractProjection x:Name="ICalculatorSoapProjection"> <ServiceContract x:Name="ICalculatorContract" <OperationContract Name="Add" x:Name="Add"> <OperationArgument Name="Op1" Type="p:Int32" /> <OperationArgument Name="Op2" Type="p:Int32" /> <OperationArgument Direction="Out" Name="Result" Type="p:Int32" /> </OperationContract> </ServiceContract> </SoapContractProjection> </Service.KnownProjections> <Service.Implementation> <sw:WorkflowServiceImplementation> <!-- place service implementation here --> </sw:WorkflowServiceImplementation> </Service.Implementation> <Service.Endpoints> <Endpoint Uri="https://localhost:8080/calc" ContractProjection="{x2:Reference ICalculatorSoapProjection}"> <Endpoint.Binding> <ss:BasicHttpBinding /> </Endpoint.Binding> </Endpoint> </Service.Endpoints> </Service>

One downside at this early stage is that there is no visual designer to help in building services declaratively. I hope that as the Community Technology Previews (CTPs) roll out, Microsoft will deliver a developer-friendly designer experience for working with the XAML definition.

In addition to the declarative service support and the WCF-based activities mentioned earlier, the .NET Framework 4.0 comes with several other lower-level WCF improvements. Some of these features make it possible to manage workflow services with the new "Dublin" extensions. These features include improved configuration, message correlation, durable duplex communication, durable timers, and Event Tracing for Windows (ETW) tracing integration. Other capabilities that add value when hosting your services in a managed environment include standard control endpoints and auto-start. You will hear more about these features in the months ahead.

The Need for "Dublin"

In the real world, another challenging aspect of working with WCF and WF is figuring out where to host your services and workflows in a server environment. For WCF, the answer is usually pretty easy—the most common choice is IIS and the Windows Process Activation Service (WAS) in Windows Server 2008.

Today, the combination of IIS and WAS provides several key features including process activation in response to incoming messages, process monitoring and health management, process recycling, CLR AppDomain integration, built-in security, and some basic management capabilities made available through IIS Manager and Windows PowerShell cmdlets. These combined features typically make IIS/WAS the right choice for hosting WCF services in a server environment because most folks don't want to build that kind of stuff themselves.

Although IIS/WAS provides a foundation for hosting WCF applications, it falls short in a few important areas. Its biggest shortcoming is in the area of service manageability. IIS/WAS doesn't really provide any WCF-specific service management capabilities such as service tracing, monitoring, and diagnosing running service instances. For example, an administrator cannot currently list all the WCF services that are configured in IIS—it's not possible to query the status of all the hosted services. IIS/WAS also doesn't provide built-in support for simplifying scale-out deployments or common WCF configuration tasks, which turns out to be a sore spot for WCF.

The hosting challenges are worse for WF applications in server environments because of the inherently stateful model required to support long-running workflows across server farms. Because of these complexities, Microsoft didn't ship a WF server host in the .NET Framework 3.0—developers had to write this themselves. It wasn't until the .NET Framework 3.5, with the introduction of the WorkflowServiceHost class, that it was possible to host WF workflows as WCF services out of the box, thereby making it possible to host your WF workflows within IIS/WAS as well.

WorkflowServiceHost was a good start, but it didn't come with any tool support for managing stateful workflows across an entire Web server farm, nor did it provide tools for monitoring and managing running workflow instances at run time.

In terms of service and workflow management features, most developers expect an experience similar to what's provided by Biz­Talk Server, yet simpler. Many organizations want the BizTalk management experience, but they don't need the integration capabilities or the reliability semantics (and corresponding performance hit) that's inherent in the BizTalk Server MessageBox. A lighter-weight model, specifically designed for WCF and WF applications, is more appropriate.

A Guide to "Dublin"

Microsoft has been working on a new set of extensions to Windows Server—code-named "Dublin"—that provides valuable hosting and management features for your WCF and WF applications. "Dublin" is essentially a set of service management extensions built on top of IIS/WAS that will ship as part of Windows Server. When using the "Dublin" extensions, you'll still be hosting your service and workflows in IIS/WAS, but your applications will enjoy additional WCF and WF-specific management capabilities and tools that don't currently exist in IIS/WAS.

The various "Dublin" extensions will ship in a future version of Windows Server as part of the Windows Server Application Server role. Hence, the set of features is often referred to as the Windows Application Server, although that's not the official name sanctioned by Microsoft. For the rest of this article, I'll refer to the new Windows Server Application Server extensions as simply "Dublin."

The key capabilities provided by the "Dublin" extensions include management support for reliable and durable services and long-running workflows. "Dublin" makes it possible to deploy an application to individual servers across a farm, and it provides the tools you need for specific service management tasks. I will be discussing these capabilities in more detail throughout the following sections, but first let's take a look at the overall architecture, which is illustrated in Figure 6.

Figure 6 The “Dublin” Architecture

As you can see, "Dublin" provides several runtime databases that lay a foundation for service persistence and monitoring. There is a layer of runtime components and services provided by the .NET Framework that build on top of these databases. "Dublin" further extends these runtimes to provide integrated hosting, persistence, monitoring, and messaging capabilities. This layer, in conjunction with the underlying runtime databases, constitutes what is referred to as "Dublin."

The top two layers in the architecture are what make "Dublin" usable by humans. There's a management API layer that makes the various capabilities scriptable via Windows PowerShell cmdlets. On top of that there is an IIS Manager experience that should feel familiar to today's IIS administrators because it actually builds on the Windows PowerShell cmdlets. So everything you can do in IIS Manager you can also do in Windows PowerShell.

Microsoft has added numerous UI extensions to IIS Manager for performing the various hosting and management tasks described in this section. There are extensions for deploying and configuring applications, managing applications, and monitoring applications. These extensions also provide a runtime dashboard of your system showing things such as running, suspended, and persisted workflow instances.

Building a WCF Workflow Service for "Dublin"

Visual Studio 2010 makes it really easy to build services that target the "Dublin" extensions through a new project template (see Figure 7). This project template gives you a web.config preconfigured with the "Dublin"-provided persistence provider and durable timer service.

Figure 7 Creating a New “Dublin” Service Library

Once you've generated the project, you can focus on implementing the WCF workflow service using the various techniques described earlier in this article. The new workflow designer experience makes it possible to implement your entire service using the graphical workflow development approach. Once you're finished building your complete workflow service, you're ready to deploy the service to a Windows Server enabled with the "Dublin" extensions.

You can deploy your services to IIS/WAS using whatever technique you normally use for Web applications (you can deploy it directly from Visual Studio if your environment allows that). You can also use Windows PowerShell cmdlets to automate these tasks. (These cmdlets allow you to build automated deployment scripts for your WCF and WF environments. If you want to try using any of these cmdlets, simply open Windows Power­Shell on a Windows Application Server and type "help <command>" to learn how to get started with that particular command.) Once deployed, you can begin using IIS Manager to access the various "Dublin" extensions highlighted in Figure 8.

Figure 8 The “Dublin” Extensions in the IIS Manager

Deploying Applications with "Dublin"

Many environments do not allow developers to deploy services directly to their managed servers for security and isolation reasons. "Dublin" provides an alternate solution for deploying services through its application export/import features.

You can package up WCF and WF applications for deployment on other servers by selecting the Application Export feature in IIS Manager. This will bring up a dialog that asks you to select a specific application to export. Once you've specified a location, pressing Export will generate a file package with a .zip extension containing all the WCF and WF code as well as all the metadata and configuration settings for a single application. This package can then be moved and imported onto another server through the "Dublin" extensions. Now you can simply send the .zip file to the IT professional who manages your servers and let him take care of it.

The Windows PowerShell Export-Application cmdlet accomplishes the same thing. This Application Export capability is also very nice for system test and validation environments.

You can import a WCF and WF application by selecting the Application Import feature or by using the Import-Application cmdlet (you can also view the contents of a package by using the Get-PackageManifest cmdlet). The import feature will then prompt you to select the package (.zip file) that you want to import.

During the process, you can specify the application name, the application pool, and the physical path for the application, if desired. And since "Dublin" provides centralized persistence configuration, when you deploy your workflow services to another server, you don't need to worry about changing the persistence configuration at the application level. It will simply use the new persistence database associated with the new server. These features make the process of deploying WCF and WF applications in a server environment very approachable for the system administrator responsible for those tasks.

Once you've successfully deployed an application, you can begin configuring your services through the other extensions provided by "Dublin." For example, in some situations, the system administrator may need to manually reconfigure the runtime configuration for the persistence and tracking databases. With the "Dublin" extensions, this is quite simple. Simply select Services from the default view and then you'll see a list of all managed services, along with a right-hand pane that exposes various service configuration options (see Figure 9). These options allow you to easily change the persistence settings, tracking settings, and other WCF settings related to security and throttling. And you never have to touch a WCF configuration file.

Figure 9 Viewing and Configuring Services with the “Dublin” Extensions

There are multiple Windows PowerShell cmdlets for performing these tasks, including the Get-ServicePersistence, Set-Service­Persistence, Enable-ServiceTracking, and Get-TrackingParticipant. This means it is much easier to automate the setup and configuration of an application server environment.

Managing Running Applications

During the lifecycle of an application, developers and system administrators need the ability to monitor the application's health, to identify and view problematic workflow instances, and to terminate them when necessary. "Dublin" provides numerous extensions that target these common management needs.

If you select the Persisted Instances option in IIS Manager (see Figure 8), you'll be taken to a dashboard view that provides an overview of the running workflow instances that have been persisted and potentially suspended (see Figure 10). The Overview box displays the total number of applications and services deployed to the server, site, or application (depending on the selected scope).

Figure 10 Viewing Persisted Workflow Instances

The Persisted Instances box displays a summary of the running and persisted workflow instances, calling out those that may be blocked or suspended (meaning they ended in an error). Since the suspended instances are the ones that humans will typically have to deal with directly, they provide several other boxes that make it easy to isolate specific suspended instances based on virtual path, service name, or type of exception.

You can click on any of the links (shown in blue) to display the list of persisted instances and to view their details. At this point, you can suspend, terminate, or abort service instances manually by selecting from the actions shown in the right-hand pane (see Figure 11). Suspending a service instance stops the execution of the instance and prevents it from receiving new messages. Suspended instances can later be resumed, at which point they'll begin receiving messages again. Terminating a service instance stops the execution of the instance and removes it from the persistence store, which means it cannot be resumed. Finally, aborting a service instance clears the in-memory state pertaining to the given instance and reverts back to the last persistent point (which is stored in the persistence store).

Figure 11 Viewing Individual Persisted Instances

The Windows PowerShell Get-ServiceInstance and Stop-ServiceInstance cmdlets offer equivalent capabilities from the command-line; they provide numerous command-line options for identifying specific service instances.

Updating Running Applications

One of the particularly troublesome aspects of working with real systems is the need to periodically update them. For most complex distributed applications, this can be tricky to do correctly when the necessary changes require updates to the database, business logic, and service code simultaneously. Usually, it's not possible to apply significant updates atomically while the application is running.

One way to approach this problem is to take the application offline while you are performing the update. However, if you really think about it, there's not an easy way to take an IIS/WAS application offline while simultaneously performing an update to a Web site. This is another area where the "Dublin" extensions add value through a simple offline feature.

You can select an application in the IIS Manager and then select the Disable Protocols command in the right-hand pane shown in Figure 8(it is important to note that this will likely be renamed in a future release). Doing so causes all instances of the application's services to end in a blocked state or to finish their execution naturally, without allowing any new incoming requests to be processed in the meantime.

At this point you have basically stopped the message flow for this application, meaning that clients will no longer be able to send messages to services without receiving errors (they won't be queued up like they otherwise would be in BizTalk Server). The way this works behind the scenes is quite simple: the "Dublin" extension simply removes all of the protocol handlers for this particular application and saves them so they can easily be restored once you are finished with the update.

Once the application is offline, you can perform whatever updates are required. When you are finished with the updates and are ready to bring the application back online again, you can then select the Restore Protocols command. The Windows PowerShell Disable-Application­MessageFlow and the Enable-Application­MessageFlow cmdlets can also be used to perform these same tasks from the command line.

Monitoring Running Applications

Businesses also need the ability to monitor running applications in order to see how the business is functioning and what changes might be necessary. The WCF and WF runtimes already come with a built-in tracking infrastructure that the "Dublin" extensions build on, making it easy to enable monitoring within your WCF and WF applications.

Figure 12 Configuring Basic Tracking

There are two main players in the .NET Framework 4.0 tracking architecture: tracking profiles and tracking participants. Developers define tracking profiles that tell the runtime what events to track, and then tracking participants can subscribe to those events.

"Dublin" comes with some built-in tracking profiles that make it easy to track to a common set of useful events. You can easily enable tracking for your application by navigating to a particular service in IIS Manager and selecting Tracking in the right-hand pane.

Then you'll see the dialog shown in Figure 12, which allows you to configure some basic tracking capabilities for your workflows and services. Once you've configured this, the appropriate updates will be made to your configuration and the WCF/WF tracking infrastructure will kick in.

If you would like, you can also view tracking data through the "Dublin" extensions. You can select View Tracking Data while inspecting persisted service instances (see Figure 11), which will run a SQL query against the monitoring store to produce a list of tracking events for you to view (see Figure 13). When you want to track custom events, you can define custom tracking profiles and configure them through the Tracking Profiles option on the main IIS Manager view.

Figure 13 Viewing Tracking Data

I don't have space to cover all of the "Dublin" features here—there are several other compelling features that merit further discussion (see the "Additional Dublin Features" sidebar for more)—but I hope you have a clearer understanding of the role of "Dublin" and some of the key features it will provide.

From "Dublin" to "Oslo"?

If you've heard about the platform code-named "Oslo," you're probably wondering at this point how "Dublin" relates to that initiative. First, "Oslo" is a new modeling platform being developed by Microsoft to simplify the way you design, build, and manage distributed applications. The modeling platform consists of three main components: the "Oslo" modeling language (also known as "M"), the "Oslo" repository, and the "Oslo" modeling tool (also known as "Quadrant"). "Oslo" is indeed a platform that other applications and technologies can build on to simplify the user experience through a model-driven approach.

Additional “Dublin” Features

"Dublin" comes with several other features I didn't have space to cover in detail in this article. But one worth calling out is support for scale-out deployments across server farms that integrate with existing load-balancing solutions such as those for managing persisted service instances across the farm through a centralized persistence database. The built-in error handling logic allows persisted instances to execute on any node in the farm and prevents race conditions when multiple nodes compete for the same instance.

The other important component is the Forwarding Service. This service makes it possible to intercept all incoming messages in order to perform central routing based on message content. In particular, this feature provides a nice foundation for building sophisticated service versioning solutions.

"Dublin" also comes with several key services for managing the lifecycle of service instances including the Durable Timer Server and the Instance Restart Service. "Dublin" also knows how to take advantage of the Instance Control Endpoint provided by the .NET Framework 4.0 and the new IIS/WAS auto-start feature, which enables you to start services when the machine starts up rather than waiting for the first message. More articles about these features will be appearing in the next several months.

"Dublin" will be one of the first technologies to leverage the "Oslo" modeling platform. You will be able to export "Oslo" apps from the repository and easily deploy them to "Dublin," where they can benefit from the various hosting and management features discussed in this article. Using models to describe and automate application deployments seems like a win for complex IT environments.

As both "Dublin" and "Oslo" continue to mature, it's likely that the integration between the two technologies will continue to grow. Microsoft has stated its intention that the two technologies will be very complementary to each other.

What about BizTalk Server?

Another common question is how "Dublin" relates to BizTalk Server. In a lot of ways, BizTalk Server inspired many of the features you see in "Dublin" today. Although both technologies provide similar management capabilities, there's a big difference between the two in terms of their focus. "Dublin" adds hosting and management extensions to Windows Server designed specifically for WCF and WF applications, whereas BizTalk Server is focused on application integration with non-Microsoft systems using a variety of different message formats, transports, and mapping techniques.

The primary focus of BizTalk Server has always been and will continue to be integration with non-Microsoft systems (line-of-business applications, legacy systems, RFID devices, and business-to-business protocols). BizTalk Server will remain focused on these core strengths in the years ahead. In general, you'll want to continue using BizTalk Server when you're focused primarily on these types of enterprise application integration (EAI) scenarios.

However, since many WCF and WF apps don't need these kinds of integration capabilities, BizTalk Server can often feel like overkill. This is precisely where "Dublin" fits into the picture—as a simpler alternative that provides similar management capabilities. In the end, "Dublin" will be more cost-effective for these scenarios than BizTalk Server since the "Dublin" extensions will ship as a core part of Windows Server and won't require you to buy integration adapters you don't need. It's likely that a future version of BizTalk Server will build upon the "Dublin" extensions in order to leverage the core management investments being made to Windows Server.

A special thanks to Eileen Rumwell, Mark Berman, Dino Chiesa, Mark Fussell, Ford McKinstry, Marjan Kalantar, Cliff Simpkins, Kent Brown, Kris Horrocks, and Kenny Wolf for their helpful assistance with this article.

Aaron Skonnard is a cofounder of Pluralsight, a premier Microsoft .NET training provider that offers both instructor-led and online training courses. Aaron is the author of numerous books, white papers, and articles as well as Pluralsight's training courses on REST, Windows Communication Foundation, and BizTalk Server.