Windows Application Server Extensions

Click here to download a PDF of this article.

Do not be fooled by the word "Extensions" in Windows Application Server Extensions (codenamed Dublin). The enhancements that Dublin adds to the combination of Microsoft IIS 7, Windows Process Activation Service (WAS), and .NET 4 provide the much longed-for standard host for Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) services. The goal of Dublin is to simplify the management of services and to add capabilities to the core services host (WAS) so that services can be inherently resilient and scalable. The management aspects of Dublin consist of about a dozen UIs in the form of IIS Manager Extensions as well as Dublin PowerShell cmdlets that deliver a centralized configuration and monitoring experience for WF and WCF services. For resilience and scale, Dublin has features that support and enhance the availability, reliability, and scalability of hosted services: high-performance event tracing, instance restart, lock retry, and autostart as well as a configurable response to unhandled exceptions in workflow services.

In this article, we'll take an overview of Dublin installation process, then see Dublin features in action as they support service deployment, post-deployment configuration, monitoring, and control.

Dublin Installation and Configuration
Dublin is available as a web download that consists of a single 5MB executable, AseSetup.exe. Much of the functionality that Dublin exposes or enhances is ultimately provided by other features of Windows or the .NET Framework. For this reason, it is important to understand the Dublin prerequisites. To begin with, Dublin will run only on Windows 7, Windows Vista, or Windows Server 2008 or Server 2008 R2. In addition, the autostart feature requires the autostart service activation functionality that's available only in Windows 7 or Server 2008 R2.

Dublin builds upon the hosting feature set of IIS and WAS's message-based activation of hosted services and so requires that IIS 7.0 and the IIS 7.0 Administration Pack (which provides UI editing of ASP.NET configs within IIS Manager) be installed. Dublin also requires that the .NET Framework 4 be installed—in fact, Dublin's management features only support .NET 4–based WF and WCF services. Microsoft .NET 3.5 apps will need to be migrated to leverage the new functionality. Windows PowerShell V2 is also required because PowerShell cmdlets are central to Dublin's management and monitoring functionality (as we'll see momentarily). Monitoring and workflow instance persistence data are stored in a SQL Server database, so at minimum SQL Server 2008 Express is required. Finally, for development purposes, one needs Visual Studio 2010.

Let us now briefly examine what it takes to install Dublin. After downloading and running AseSetup, you'll be presented with a wizard that allows you to control the feature selection and most importantly configure Dublin's persistence and monitoring stores. That's all there is to installing Dublin using the UI approach; it's quite an easy process.

Service Deployment
Now that you've installed Dublin, let's assume you a have a workflow service developed, and you want to deploy and install the service and its configuration into Dublin. (For guidance on how to build such a workflow service, see "Introducing .NET 4.0 Workflow Services.") The deployment scenario in Dublin leverages MS Deploy client components and synchronization agents and adds a plug-in to IIS Manager, which provides UI support for package import and export. To initially get your workflow service from Visual Studio installed in Dublin, within Visual Studio 2010 go to the Project Properties and click the Package/Publish tab, as Figure 1 shows.

Ensure that Create MSDeploy package as a ZIP file is checked and save your project. Next, in Solution Explorer, right-click your project, and choose Package, Create Package, as Figure 2 shows. The .zip file representing your package will be the package location specified on the Package/Publish tab.

Now, on your Dublin box open IIS Manager and click a website to import your application into (or create a new website, just make sure it is configured with a .NET 4 AppPool). In the Actions pane, under Manage Packages, choose Import Application, as Figure 3 shows.

In the dialog box that appears, browse to your package .zip file, click Next and Next again. You'll then see a window, which Figure 4 shows, that lets you name the import location and, effectively, the application as well. Enter an appropriate value and click Next, then click Finish. Your package should now appear as an application under the selected website.

Exporting an application from IIS Manager is equally trivial. Basically, select your application in the Connections pane, choose Export Application from the Actions pane (Figure 3), and step through the wizard. The end result will be a package like the one created by Visual Studio. This process lets you capture changes you might make post-development in a form that can later be redistributed to production servers or other servers in a web farm. Note that currently no automated process for synchronizing all nodes in the farm exists—you must manually import packages to each node.

Service Configuration
Dublin setup provides many defaults in the root web.config available to all child sites and applications. These settings are overrideable in the web.configs of the latter. The configuration of services hosted in Dublin amounts to the editing of settings defined in this hierarchy of configuration files and can be accomplished in one of two ways: graphically by using the IIS Manager Extensions or at the command line via Dublin PowerShell cmdlets.

IIS Manager extensions. Dublin adds many new screens to IIS that provide interfaces for performing WCF configuration editing. These extensions make editing much simpler than using SvcConfigEditor and ensure that configuration is correctly scoped to the server, site, application, and service levels, depending on what is currently selected in IIS Manager. In addition, these extensions provide functionality for features that previously had no editor, such a configuration of SQL Persistence for workflows. Most of these are visible in the center panel of IIS Manager, grouped under the Application Server Extensions for .NET 4 header. Figure 5 shows the options available at the Server scope (Dashboard, Endpoints, Monitoring DB, Persistence DB, Services, and System Services).

In addition to the options available in the center pane, the Actions pane on the right includes a .NET WF and WCF section that has one hyperlink: Configure. This link will display a context sensitive dialog for configuring .NET 4 features at the selected scope. Figure 6 shows the dialog that appears at the Server scope. Note that the Configure option is also available by right-clicking a node in the Connections pane and selecting .NET 4 WF and WCF, Configure.

The following is a listing of all the configuration-related IIS Manager Extensions, to give you a feel for just how much Dublin enables you to configure through the IIS Manager UI:

• Endpoints: listing of endpoints and configuration of endpoint address.
• Services: listing of services, configure monitoring, persistence, autostart, throttling, certificates and endpoints for a selected service.
• Website: configure monitoring, persistence, throttling and certificates for a website.
• Application: configure monitoring, persistence, autostart, throttling, and certificates for a web application.
• Persistence database: manage connection strings and initialize a persistence database.
• Monitoring database: manage connection strings and initialize a monitoring database.
• System Services: allows you to configure the accounts used by the ETW Event Collector and Workflow Management Services as well as modify the default Event Collector settings.

Many of the aforementioned listings let you navigate between related entities. For instance, with a service selected, you can navigate to its related endpoints and configure them as well as vice versa.

Dublin PowerShell cmdlets. PowerShell cmdlets are at the heart of Dublin, providing the functionality for controlling, querying, and configuring service instances, services, applications, and servers. All IIS Manager Extensions ultimately call through to the Dublin cmdlets. It's useful to think of there being three categories of cmdlets in Dublin:

• Service Management cmdlets: act on the configuration of services and configuration as well as control of service instances. These cmdlets will include the term "service" or "instance" in their name.
• Application Management cmdlets: configure and list applications. These will include the term "application" in their name.
• Server Management cmdlets: configure the persistence and monitoring databases as well as the ETW Event Collector and Workflow Management Service system services. These will include the term "database" or "event collector" in their name.

Figure 7 summarizes all the Dublin cmdlets; the full name of the cmdlet is the result or combining a verb, a dash, and a noun—for example, Get-ASAppServiceInstance.

To run Dublin cmdlets, you'll need to load PowerShell V2, then import the single module Microsoft.ApplicationServer.Management.dll. For example, to view all registered connection strings in the default website, you would run the following two commands:

Import-Module ApplicationServer\Microsoft.ApplicationServer.Management.dll
Get-ASConnectionString "Default Web Site"

The commands' output will be similar to that in Figure 8.

Finally, it's worth noting that Dublin ships with support for remote management from both PowerShell cmdlets and IIS Manager. In IIS Manager's case, the IIS Web Management NT service is required. In the case of remote cmdlets, the Windows Remote Management Service must be running.

Service Monitoring and Control
Dublin functionality extends into the area of controlling applications, services, and service instances as well as monitoring the state of service instances, supporting drill down into tracked events for a service instance, and custom querying of the monitoring store through the IIS Manager Extensions and Dublin cmdlets. The control features let you resume, suspend, terminate, cancel, and delete a workflow service instance. These controls are often used in combination. For example, one might use the dashboard to drill down into a suspended workflow instance and resume it. Or, one might query for an active workflow instance with a specific variable value and suspend it. (For more information about Dublin monitoring, see "Monitoring and Troubleshooting .NET 4 Services.")

Robust Hosting Functionality
Beyond the configuration and monitoring experience provided by the IIS Manager Extensions and cmdlets, Dublin also provides some features that themselves provide for more robust hosting. We've mentioned two of these in passing and will now explore what they offer.

Workflow Management Service (WMS). The first of these is WMS, which is installed by default as a Windows service named Application Server Workflow Management Service. WMS is the workhorse process for many of Dublin's workflow features. When a host crashes while executing a service instance, that instance is abandoned. WMS monitors for these abandoned instances and resumes their execution starting from their last persistence point. In addition, WMS restarts workflows persisted after a graceful shutdown or those whose durable timers have expired (e.g., resulting from a delay activity whose duration has elapsed).

Dublin also transparently introduces an internal endpoint, called the Instance Control Endpoint (ICE), for workflows that are configured to use persistence. WMS, control functions in IIS Manager Extensions, and the Dublin cmdlets all communicate with the endpoint via named pipes and use the endpoint to resume, suspend, cancel, or terminate a workflow service instance.

SQL Workflow Instance Store. The SQL Workflow Instance Store is provided by Dublin, unlike previous versions of the .NET Framework, which included a SQL Persistence Provider out of the box. Used in process by the workflow service host, the sqlWorkflowInstanceStore class implements the persistence provider functionality that loads from and saves workflow instances to a SQL Server 2008 database. The majority of features enabled by this class are illustrated by the Advanced Persistence Settings in the service configuration, as Figure 9 shows.

The first feature is lock retry (shown in the screen as Action on instance lock exception). This handles the condition that can result when multiple serviceHosts are attempting to resume the same service instance from persistence. Without lock retry, an InstanceLockedException would be thrown and the operation would immediately fail. Lock retry offers two different approaches to the retry interval: one that retries in a linear fashion and another that retries in interval that grows exponentially where the initial interval is very short, but grows quickly. Only when the number of retries is exceeded is the InstanceLockedException thrown.

The next is unhandled exceptions. This is behavior configured on the service that instructs the SQL Workflow Instance Store what to do when a service instance encounters an unhandled exception. The options are to abandon (discarding in memory state and rolling back to the last persisted state; can be automatically recovered by the WMS); abandon and suspend (rolls back to last persist point but waits for an explicit resume); terminate (forces completing the workflow; it cannot be resumed later); and cancel (completing the workflow but allowing cancellation handlers defined in the workflow to execute and thereby close the instance gracefully).

The functionality for unload on idle and persist on idle have been decoupled in .NET 4, enabling you to configure a workflow service instance to persist on idle but keep it loaded in memory. This is useful for checkpoint workflow execution, such that if the host later crashes, the workflow can be resumed from this latest persistence point.

Workflow state in its serialized form can get fairly large. To address this issue, it's now possible to compress state data by using GZip in persistence store, as shown by the Encode instances option. In addition, one can now elect to keep instance state data after the workflow instance completion (ordinarily, the state of completed instances would be purged upon completion).

Application Server Event Collector. The last major feature is the Application Server Event Collector. This provides a high-performance, low-overhead mechanism for collecting ETW traces and writing them to the Dublin monitoring database.

Extensive Extensions
I've attempted to show you just how compelling the "Extensions" provided by Dublin are. These Windows Application Server Extensions effectively pull together a lot of services-related functionality and make it manageable from one central location. These extensions for services and workflows, together with the existing Web Platform and application server capabilities, provide a compelling general-purpose platform to build, run, and manage distributed applications on Windows Server.

Zoiner Tejada ([email protected]) is passionate about workflows and the future of implementing connected systems with them. He's the chief software architect at Hershey Technologies, is recognized as a Microsoft Industry Influencer, and is an advisor to Microsoft's Connected Systems Division. Zoiner has a degree in computer science from Stanford University and blogs at TheWorkflowElement.com.

Figure 7: Dublin cmdlets

Figure 8: Output of a Dublin PowerShell cmdlet

Name:                      :DefaultApplicationServerExtensions
ConnectionString           :Data Source=localhost\SQLEXPRESS;Initial>
Catalog=ApplicationServerExtensions;Integrated Security=True
ProviderName               :System.Data.SqlClient
IsLocallyStored            :False
SqlConnectionStringBuilder : \\{\\[Data Source, localhost\SQLEXPRESS\\]…
Server                     :localhost\SQLEXPRESS
Database                   :ApplicationServerExtensions