Hosting Services

Figure 13-2 gives an overview of the architectural components provided with AppFabric and shows the services and components used to host and manage workflows as services; however, these capabilities have related instrumentation for managing them within AppFabric and are provided out of the box. Hosting workflows as services rely on WAS and take advantage of its hosting functionality and managing workflows through the Workflow Management Service (WMS). The tooling that is provided reduces the need to manually change configuration files that would normally have to be done through custom workflow management solutions.

Figure 13-2 illustrates that AppFabric resides within IIS, which provides for hosting web applications like ASP.NET; however, the goal for AppFabric is to provide a way to easily deploy WCF and WF solutions as long running services through persistence and monitoring.

• ASP.NET:  Ability to receive WCF and WF messages over HTTP.
• WCFand WF: The primary focus of AppFabric, it provides the foundation for building SOA applications, which support long-running processes and interoperability with other technologies.
• Runtime Databases: Provides a data store that is secure, scalable, and reliable for storing data about SOA applications.

Some of the familiar capabilities that are provided within WF include

• Persistence: Preserves data across system failures or restarts. AppFabric provides its own preconfigured database for persisting workflows within SQL Server.
• Hosting: Integrates with the WorkflowServiceHost provider within IIS and WAS.
• Monitoring: Provides tooling for controlling the level of transparency for managing execution data for workflow instances. AppFabric provides its own preconfigured database for monitoring workflows within SQL Server.  

IIS Manager

The IIS Manager within AppFabric provides the user interface for managing and configuring WCF and WF services, including MSDeploy for deploying services that need to be hosted within WAS. Functionality exposed through the IIS manager can be driven by scripting custom PowerShell cmdlets, commands that are executed from the PowerShell command prompt to perform configuration and other tasks within an operating system or application.

AppFabric Windows Services

There are two services that are installed after AppFabric is installed.

• AppFabric EventCollection Service: Collects Event Tracing for Windows (ETW) events that are subscribed to during WCF and WF service execution, and stores them within the monitoring store.
• AppFabric Workflow Management Service: Manages the activation of workflow instances that are ready to be activated within the durable instance store.

Persistence Data Stores

AppFabric provides one data store by default for persisting and monitoring workflow instances within SQL Server; however, as demand grows for the services hosted within AppFabric, the data store can become a bottleneck for performance as a correlation of database inserts updates and deletes occur within a short time span (see Figure 13-3 ).

By providing multiple persistence and monitoring databases, performance can be increased to handle larger volumes of activity. Each instance store can be routed to a certain service or logically related services that have been deployed within AppFabric (see Figure 13-4).

Monitoring Data Stores

When service monitoring is executed, a SQL Agent job checks for new events, loads the event data, and writes the events to the monitoring data store. Database views are then used to retrieve the events to be viewed with the AppFabric Dashboard or other custom reporting solutions.

Single Server Deployment

Single server deployment installs and executes everything on a single computer and can be used for prototyping and developing different types of applications that should be hosted. Single server deployment is often inappropriate when applications must scale flexibly. A local installation of SQL Server can be used for monitoring and persistence, but remember because it is single server, the environment forfeits high availability (HA). If the server goes down, all the deployed applications go down as well. Also, more resources have to be shared between the hosting and the instance and monitor store. Although persistence exists for workflow instances, it should not be solely relied upon as a disaster recovery solution.

Figure 13-5 illustrates a single server deployment where multiple clients can connect to clients through a single server hosting AppFabric. Figure 13-5 also illustrates that the persistence and monitoring databases are installed on a separate server from the server where AppFabric is installed.

Server Farm Deployment

Production environments, on the other hand, need to be scalable for increasing performance and providing high availability, so they usually incorporate multiple servers within a server farm. There is usually more than one server dedicated to SQL Server for persisting and monitoring long-running services using clustering for failover protection, load balancers for managing available resources, and queuing for incoming messages. Figure 13-6 illustrates a server farm that hosts AppFabric (which is clustered for reliability) for clients subscribing to the services hosted.

Upgrading

There is good news if you need to upgrade from AppFabric 1.0: Microsoft does provide support for doing so. However, make sure you read the possible and known issues (found in the release notes from the same link that provides the installation setup). The other option is to use the uninstall tool that can be downloaded from http://go.microsoft.com/fwlink/?LinkId=188172. The uninstall tool provides a cleanup utility that removes AppFabric 1.0 so a fresh installation of AppFabric 1.1 can be installed.

Hardware Requirements

There are two setups provided from the link. The setup file WindowServerAppfabricSetupx64.exe is obviously for 64-bit systems and WindowServerAppfabricSetupx32.exe is for 32-bit systems. The minimum hard disk space is 2GB and single processors require a computer with an Intel Pentium-compatible CPU that is 1GHz or faster. Dual processors require 900GHz or faster, and quad processors require 700 MHz or faster.

Software Requirements

Both 32- and 64-bit setups can be installed on the following operating systems:

• Windows 7
• Windows Server 2008 Service Pack 2
• Windows Server 2008 R2
• Windows Vista Service Pack 2

Microsoft .NET Framework 4 needs to be installed as a prerequisite along with the following:

• Internet Information Service (IIS) 7

• Hotfix #980423

• IIS Web Deployment tool
• Windows PowerShell 2.0 (final version)

• Not required for Windows 7 and Windows Server 2008 R2

All features of AppFabric require Microsoft .NET Framework 4, but some features like the caching service can use Microsoft .NET Framework 3.5. The cache client can also use .NET Framework 3.5 with Service Pack 1.  

Installation and Configuration

There are different types of installations and configurations that can be performed. I will walk through a single server installation using the wizard for installing specific features on a machine running Windows 7. Configuration can be done later for an initial installation using the same wizard. Another option is using script-based automation for installing and configuring AppFabric 1.1.

Action Pane

The Action pane is located in the right side panel of the dashboard, and based on which screen within AppFabric is up, it dynamically changes menu items. For instance, while an application is selected within the left-handed Connections pane, the Actions pane resembles Figure 13-36. A couple of menu items that are worth mentioning are the following:

• Browse *:80 (http): Selecting this from the Actions menu allows the service to be viewed within an Internet browser, so information about a service can be gathered, including the URL that needs to be used within a client application.
• Advanced Settings: WF services require net.pipes to be used, so clicking on Advanced Settings from the Actions menu allows the Enabled Protocols property to be set.
• Import Application: Selecting this from the Actions menu allows service packages to be installed.
• Configure: Selecting this from the Actions menu allows configuration for functionality like persistence and monitoring that AppFabric will use as metrics within the dashboard.

Persisted WF Instances

The data store for persisting workflows can be configured for the entire server, sites, or applications hosted within the left-handed Connections pane. Figure 13-37 illustrates that an application has been deployed onto the server.

Instead of configuring persistence at the HYPERVWINSEVEN2 server or the default web site level, persistence has been set up at the Workflow.JeepParts service application level. Although the choice has to be made to share a persistence store at higher levels than the application service level, it is nice to have the flexibility to dedicate a persistence store per service if required. Sharing a persistence store might be a good option if there aren’t many service applications sharing the same persistence store.

Persistence is configured by either right-clicking on a service and selecting “Manage WCF and WF Services” or by using the Configure menu within the Actions pane. Once the Configure WCF and WF for Application screen appears, selecting Workflow Persistence allows you to change the configuration for persistence. Even though the persistence data store was configured and initialized, the services deployed onto the server still have to be configured to use the new persistence data store. Figure 13-38 illustrates selecting a SQL Server Store that was configured in the first exercise after installing AppFabric.

Figure 13-38 also shows another persistence store that was configured (although this was not done in the first exercise). Using the configuration tool for AppFabric only allows the configuration of one default persistence store. Within the first exercise you may recall checking the setting Register AppFabric persistence store in root web.config, illustrated within Figure 13-21. What this setting does is build the configuration for the persistence store within the web.config within the root directory for the .NET runtime. The file can be found at C:WindowsMicrosoft.NETFrameworkv4.0.30319Config.

Opening the file within Visual Studio 2012 and scrolling down towards the bottom of the file, Listing 13-2 represents the configuration for persistence, which includes both SQL Server stores that can be used for persisting workflow instances for the service. There is also the configuration for initializing the monitoring data store.

Listing 13-2.  Initialized Instance and Monitoring Stores

 <instanceStores>
                  <add name="defaultSqlPersistenceStore" provider="SqlPersistenceStoreProvider" connectionStringName="ApplicationServerWorkflowInstanceStoreConnectionString" />
<add name="CustomPersistStore" provider="SqlPersistenceStoreProvider" connectionString="Data Source=HYPERVWINSEVEN2;Initial Catalog=AppFabPersist2;Integrated Security=True" />
 </instanceStores>

<connectionStrings>
        <add connectionString="Data Source=HYPERVWINSEVEN2;Initial Catalog=AppFabMonitor;Integrated Security=True" name="ApplicationServerMonitoringConnectionString" />
        <add connectionString="Data Source=HYPERVWINSEVEN2;Initial Catalog=AppFabPersist;Integrated Security=True" name="ApplicationServerWorkflowInstanceStoreConnectionString" />
    </connectionStrings>

Monitoring WF Instances

Monitoring can also be configured at a server, site, or site application level, just like persistence. Once monitoring as an initialized instance data store, a service can be configured to use an initialized monitoring instance data store (see Figure 13-42).

Figure 13-42 illustrates a couple of features and settings that can be applied to monitor WF events. The first feature that can be turned on or off is writing events to a database. If the checkbox is not checked, then events will not be stored within the monitoring database that was initialized earlier. The Connection string property refers to the connection string that was configured after AppFabric was installed. There are two other connection strings, LocalSqlServer and ApplicationServerWorkflowInstanceStoreConnectionString, that might be selectable; however, make sure that ApplicationServerMonitoringConnectionString is selected, as illustrated in Figure 13-42.

A monitoring level can also be selected based on how much monitoring information needs to be applied to monitor a service. There are five different levels of monitoring, including a level for turning monitoring off. Other than turning monitoring off, the following monitoring levels can from the minimal amount of monitoring available out of the box to the most that can be tracked within AppFabric.

• Errors Only: This setting only reports on errors and critical warning events.
• Health Monitoring: This setting is the default setting for monitoring and should be used for populating metrics within the AppFabric Dashboard. Error events are inherited from the Errors Only profile.
• End-to-End Monitoring: This setting subscribes to the flow of events within workflows and between other WCF services. Health monitoring events are inherited from the Health Monitoring profile.
• Troubleshooting: This setting is required for subscribing to events that can assist with application-level diagnostics. This setting should not be left running within production applications because it can affect performance of the application. End-to-end monitoring events are inherited within this setting as well.

Each of these profiles is just a predefined tracking profile (covered in Chapter 9). The profiles reside within the root web.config located at C:WindowsMicrosoft.NETFrameworkv4.0.30319Config. Listing 13-3 shows the each of the tracking profiles that are stored within the root web.config.

Listing 13-3.  AppFabric Monitoring Profile Settings

<tracking>
   <profiles>
       <trackingProfile name="ErrorsOnly Tracking Profile">
            <workflow activityDefinitionId="*">
                <workflowInstanceQueries>
                     <workflowInstanceQuery>
                          <states>
                                <state name="UnhandledException" />
                                <state name="Aborted" />
                        </states>
                </workflowInstanceQuery>
        </workflowInstanceQueries>
        <faultPropagationQueries>
                <faultPropagationQuery faultSourceActivityName="*" faultHandlerActivityName="*" />
        </faultPropagationQueries>
 </workflow>
 	</trackingProfile>
 	<trackingProfile name="HealthMonitoring Tracking Profile">
                <workflow activityDefinitionId="*">
                        <workflowInstanceQueries>
                                <workflowInstanceQuery>
                                        <states>
                                                <state name="Started" />
                                                <state name="Completed" />
                                                <state name="Terminated" />
                                                <state name="Canceled" />
                                                <state name="Unsuspended" />
                                                <state name="Persisted" />
                                                <state name="Aborted" />
                                                <state name="UnhandledException" />
                                       </states>
                                </workflowInstanceQuery>
                        </workflowInstanceQueries>
                        <activityStateQueries>
                                <activityStateQuery activityName="*">
                                   <states>
                                           <state name="Closed" />
                                  </states>
                          </activityStateQuery>
                  </activityStateQueries>
                  <faultPropagationQueries>
                          <faultPropagationQuery faultSourceActivityName="*" faultHandlerActivityName="*" />
                  </faultPropagationQueries>
                  <customTrackingQueries>
                  <customTrackingQuery name="*" activityName="*" />
                  </customTrackingQueries>
          </workflow>
  </trackingProfile>
  <trackingProfile name="EndToEndMonitoring Tracking Profile">
          <workflow activityDefinitionId="*">
                  <workflowInstanceQueries>
                          <workflowInstanceQuery>
                                   <states>
                                           <state name="*" />
                                  </states>
                          </workflowInstanceQuery>
                     </workflowInstanceQueries>
                     <activityStateQueries>
                             <activityStateQuery activityName="*">
                                     <states>
                                             <state name="Executing" />
                                             <state name="Closed" />
                                    </states>
                             </activityStateQuery>
                     </activityStateQueries>
                     <faultPropagationQueries>
                             <faultPropagationQuery faultSourceActivityName="*" faultHandlerActivityName="*" />
                     </faultPropagationQueries>
                     <customTrackingQueries>
                             <customTrackingQuery name="*" activityName="*" />
                     </customTrackingQueries>
             </workflow>
     </trackingProfile>
     <trackingProfile name="Troubleshooting Tracking Profile" implementationVisibility="All">
             <workflow activityDefinitionId="*">
                     <workflowInstanceQueries>
                             <workflowInstanceQuery>
                                      <states>
                                              <state name="*" />
                                     </states>
                          </workflowInstanceQuery>
                    </workflowInstanceQueries>
                    <activityStateQueries>
                            <activityStateQuery activityName="*">
                                    <states>
                                            <state name="*" />
                                   </states>
                     </activityStateQuery>
                </activityStateQueries>
                <activityScheduledQueries>
                        <activityScheduledQuery activityName="*" childActivityName="*" />
                </activityScheduledQueries>
                <cancelRequestedQueries>
                       <cancelRequestedQuery activityName="*" childActivityName="*" />
                </cancelRequestedQueries>
                <faultPropagationQueries>
                        <faultPropagationQuery faultSourceActivityName="*" faultHandlerActivityName="*" />
                </faultPropagationQueries>
                <bookmarkResumptionQueries>
                        <bookmarkResumptionQuery name="*" />
                </bookmarkResumptionQueries>
                <customTrackingQueries>
                        <customTrackingQuery name="*" activityName="*" />
                </customTrackingQueries>
        </workflow>
</trackingProfile>
</profiles>
 	</tracking>

Understanding WF Metrics

Now that persistence and monitoring have been set up successfully, the AppFabric Dashboard should be showing metrics not only for persisted workflow instances, but also tracking events based on the tracking profile that was selected. By default, Health Monitoring is selected so services that are hosted within AppFabric that are called by client applications should reflect metrics about service activity.

Figure 13-54 shows that there is one service deployed within the default web site called Workflow.JeepParts. The dashboard shows that there is some tracking information that already exists. One WCF service call has been made to the Workflow.JeepParts service indicated by the Completed metric within the WCF Call History section of the dashboard. There is a workflow instance that has been activated based on the Activation metric and it has been persisted, as indicated by the Idle metric. All of this information is based on the Workflow.JeepParts service13.

Using the Refresh link located at the top right of the dashboard, new information about the workflow instance indicates that it is no longer persisted and that it has completed successfully because the Completions metric within the WF Instance History section now shows 1 (see Figure 13-55).

Clicking on metrics within the WCF Call History does not show as much monitoring information since there is not as much to a plain WCF service compared to a WF service since the service uses a workflow and more information needs to be tracked to add transparency for managing the workflow service.

Clicking on either the Activation or Completion metric drills into the service by opening the Tracked WF Instances screen. There is a search feature at the top of the screen that can be used for filtering tracked instances. Clicking the Completion metric automatically puts the filter criteria in for filtering Statuses that have the value Completed. Clicking the tracked instance adds additional menu choices within the left Actions pane (see Figure 13-56). Clicking “View Tracked Events” opens the Tracked Events screen, which has all of the tracked events logged for the workflow instance.

All of the events that have been subscribed to from the default Health Monitoring tracking profile are logged within the Tracked Events screen. Figure 13-57 shows the list of tracked events for the workflow instance service.

Purging Tracked Events

Monitoring data can be purged for a monitoring data store using PowerShell. In fact, tracking data can be archived within another data store using PowerShell as well; this way data can be retained for historical reporting and the AppFabric Dashboard can be cleared out (see Figure 13-58).

Workflow Host Management

Workflow management can be configured within custom applications using either an app or web configuration file. The same configuration can be managed within AppFabric (see Figure 13-59). The options are as follows:

• Enable instance control: Enables commands that can be signaled to workflow instances from within AppFabric like cancel, suspend, and resume.
• Unload instance when idle: Indicates if workflow instances should be unloaded after they become idle. Number of seconds can be entered through the list box for how long after an idle a workflow instance should be unloaded.
• Persist instance when idle: Indicates if workflow instances should be persisted after they become idle. Number of seconds can be entered through the list box for how long after an idle a workflow instance should be persisted after being idle.
• Action on unhandled exception: Indicates the type of action that should be performed for unhandled exceptions. The choices are as follows:

• Abandon
• Abandon and suspend
• Cancel
• Terminate

Auto-Start Feature

The auto-start feature for AppFabric is built on top of IIS 7.5 and provides better performance by improving host responsiveness. By setting services to auto-start, services are initialized within applications to start before a client initiates the first call to a hosted service. Setting the auto-start for all services within an application can be done in three different ways:

• PowerShell cmdlet: Using the AppFabric Windows PowerShell console and using the Set-ASApplication command with the –AutoStartMode parameter and setting it to either All for all services within the application or Custom for specific services within the application.
• IIS Manager: Clicking on an application within Manager for starting all services within the application.
• Configured: Certain services can be configured to auto-start using the web.config.

Another scenario for setting services to auto-start is for unforeseen conditions like a server that has been restarted. As the server restarts, services that are configured to auto-start are automatically started when a server reboots (see Figure 13-60).