Windows Server AppFabric provides a runtime and
hosting services for WF and WCF services built for version 4.0 of the
.NET framework. It is best viewed as an extension to the application
server available on Windows Server 2008 (and Windows Server 2008 R2).
The purpose of Windows Server AppFabric is to make it easier to build,
scale, and manage WCF and WF service compositions that are hosted in
IIS/WAS.
Its primary features include:
configurable hosting environment
workflow persistence
in-memory application cache platform
manageability extensions
application server event collection
distributed caching services
Figure 1 shows how Windows Server AppFabric builds upon and extends the functionality in Windows Server and the .NET framework.
Configurable Hosting Environment
Let’s
begin by explaining how Windows Server AppFabric extends the
functionality of the Windows Process Activation Service (WAS).
Essentially, it enables services hosted in AppFabric to still have
messaging-based activation, application, and worker recycling, while
also supporting centralized administration and support for both HTTP
and non-HTTP protocols. This allows services to take advantage of
specific WCF features, such as unnamed endpoints and default
configuration (which reduces the amount of configuration that has to be
specified by applying reasonable default values when explicit values
are not provided).
Windows
Server AppFabric also enables the hierarchical combination of
configuration files (which is actually similar to the functionality
that has existed in ASP.NET for many years). Values can be defined once
at the machine level and changed only when needed by a particular
application. This effectively relieves us of the need to continually
specify values for endpoints and behaviors. The default values for a
service allow you to communicate with your service using a contract
derived from the public interface over basicHttpBinding.
These default values result in a simpler Web.Config file for WCF services. In Visual Studio 2010, the default template for the system.serviceModel part in Web.Config only defines entries for serviceMetadata and serviceDebug.
Workflow Persistence (with AppFabric)
Workflow persistence
represents Windows Server AppFabric’s ability to capture and store the
state of a workflow to durable storage, independent of any machine or
process information. When a workflow is persisted, it provides a
well-known point of recovery in the event of machine failure. The
workflow logic can be later removed from memory to free resources, when
required.
The .NET framework 4.0 includes the SQLWorkflowInstanceStore
class used to persist workflow state. It also contains the Workflow
Management Service (WMS), which provides management tasks for workflow
services.
Installing Windows Server AppFabric automatically installs WMS and configures it as a service.
This installation routine also provides the option to:
create the persistence database
add an sqlWorkflowInstanceStore element to the appropriate configuration file (root, site, application, or service)
store the connection information in the configuration file
Windows Server AppFabric uses sqlStoreProvider to communicate with the database. The following example shows the connectionStrings and sqlWorkflowInstanceStore elements that can be added to a Web.Config file to take advantage of the workflow persistence extension:
Example 1.
<connectionStrings>
<add name="WorkflowPersistenceStore"
connectionString="..." />
</connectionStrings>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<sqlWorkflowInstanceStore
connectionStringName="WorkflowPersistenceStore"
hostLockRenewalPeriod="00:30:00"
instanceEncodingOption="None"
instanceCompletionAction="DeleteAll"
instanceLockedExceptionAction="NoRetry"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
|
Windows
Server AppFabric contains tools that can be used to view and control
workflow instances. For example, a dashboard is provided so that you
can display WCF call history, WF instance history, and the number of
persisted WF instances. Using these tools, you can also view tracked WF
instances and, in some cases, suspend, resume, cancel, or terminate a
workflow instance.
In-Memory Application Cache Platform
One method of scaling
services to handle larger workloads is to cache non-volatile data close
to the services that use the data. Windows Server AppFabric provides a
distributed in-memory application cache that establishes a unified data
view while automatically synchronizing the data across all of the
servers participating in the distributed cache. The primary server is
responsible for updating the additional secondary servers.
|
In-memory application
caching can be fully leveraged as a primary state deferral mechanism
when applying the Service Statelessness
principle. AppFabric Caching Services are comparable to the
system-provided utility services that generally result from Stateful
Services and the synchronization feature is comparable to the application of Service Data Replication
in support of state data replication. The configuration control made
available by the Windows Server AppFabric caching extensions allow for
potential increases in individual service autonomy, as per the Service
Autonomy principle.
|
The in-memory application cache (Figure 2)
can scale to hundreds of servers and provides automatic load balancing
and fail-over to a secondary node if the primary node is unavailable.
Policies that govern cache eviction ensure that unneeded data can be
removed from the cache after a specified time period, or when the cache
is full and the data has not been accessed in a while. This cache runs
in a separate cache host process. A named cache is created that can
span multiple machines
and cache host processes. The service stores name value pairs in the
named cache and if you need greater control over the allocation of
cache resources, you can create a region.
Each service is responsible
for managing its own cache and the items in the cache. The following
example shows how to create a cache named “orders” and add an Order object to it:
Example 2.
DataCacheFactory fac = new DataCacheFactory();
DataCache orders = fac.GetCache("orderscache");
orders.Put("order1", new Order(...));
|
The cache host process is created by calling the GetCache method on a DataCacheFactory object. A new order is then added with the key order1.
Manageability Extensions
Due
to their distributed nature, service compositions can present special
management challenges, especially when they involve services hosted on
a large number of different machines. Windows Server AppFabric extends
existing management and monitoring tools by providing the set of IIS
Manager applets listed in Table 1.
Table 1. IIS Applets provided by Windows Server AppFabric.
| Applet | Description |
|---|
| Dashboard | provides a graphical view of WF workflows and WCF services |
| Endpoints | used to manage endpoints declared in configuration files |
| Services | used to view and configure WCF and WF services |
Windows Server AppFabric
further provides a Windows PowerShell management interface that you can
use to script changes to the default configurations and to run scripts
across multiple machines. You can further create custom applets and
PowerShell cmdlets.
Application Server Event Collector
Another way to monitor
actively running services is to collect and analyze event information.
WCF or WF services can emit event data that is sent to a high
performance Event Tracing for Windows (ETW) session. Windows Server
AppFabric includes an Event Collector Service that can collect the
events and send them to a monitoring database. Analysis tools can then
be used to query the data for monitoring purposes.
