Hosting in Windows Process Activation Service

The Windows Process Activation Service (WAS) manages the activation and lifetime of the worker processes that contain applications that host Windows Communication Foundation (WCF) services. The WAS process model generalizes the IIS 6.0 process model for the HTTP server by removing the dependency on HTTP. This allows WCF services to use both HTTP and non-HTTP protocols, such as Net.TCP, in a hosting environment that supports message-based activation and offers the ability to host a large number of applications on a given machine.

For more information about building a WCF service that runs in the WAS hosting environment, see How to: Host a WCF Service in WAS.

The WAS process model provides several features that enable applications to be hosted in a way that is more robust, more manageable, and that uses resources efficiently:

Message-based activation of applications and worker process applications start and stop dynamically in response to incoming work items that arrive using HTTP and non-HTTP network protocols.

Robust application and worker process recycling to maintain the health of running applications.

Centralized application configuration and management.

Allows applications to take advantage of the IIS process model without requiring the deployment footprint of a full IIS installation.
Windows Server AppFabric works with IIS 7.0 and Windows Process Activation Service (WAS) to provide a rich application hosting environment for NET4 WCF and WF services. These benefits include process life-cycle management, process recycling, shared hosting, rapid failure protection, process orphaning, on-demand activation, and health monitoring. For detailed information, see AppFabric Hosting Features and AppFabric Hosting Concepts.

Elements of the WAS Addressing Model

Applications have Uniform Resource Identifier (URI) addresses, which are the code units whose lifetime and execution environment are managed by the server. A single WAS server instance can be home to many different applications. Servers organize applications into groups called sites. Within a site, applications are arranged in a hierarchical manner that reflects the structure of the URIs that serve as their external addresses.

Application addresses have two parts: a base URI prefix and an application-specific, relative address (path), which provide the external address for an application when joined together. The base URI prefix is constructed from the site binding and is used for all the applications under the site. Application addresses are then constructed by taking application-specific path fragments (such as, «/applicationOne») and appending them to the base URI prefix (for example, «net.tcp://localhost») to arrive at the full application URI.

The following table illustrates several possible addressing scenarios for WAS sites with both HTTP and non-HTTP site bindings.

Desktop hosting service

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2019, Windows Server 2016

This article will tell you more about the desktop hosting service’s components.

Tenant environment

As described in Remote Desktop service roles, each role plays a distinct part in the tenant envrionment.

The provider’s desktop hosting service is implemented as a set of isolated tenant environments. Each tenant’s environment consists of a storage container, a set of virtual machines, and a combination of Azure services, all communicating over an isolated virtual network. Each virtual machine contains one or more of the components that make up the tenant’s hosted desktop environment. The following subsections describe the components that make up each tenant’s hosted desktop environment.

Active Directory Domain Services

Active Directory Domain Services (AD DS) provides the domain and forest information, such that the tenant’s users can sign in to the desktops and applications to carry out their workloads. This also enables you to set up or connect to required file shares and databases that may be required for Windows applications.

The tenant’s forest does not require any trust relationship with the provider’s management forest. A domain administrator account may be set up in the tenant’s domain to allow the provider’s technical personnel to perform administrative tasks in the tenant’s environment (such as monitoring system status and applying software updates) and to assist with troubleshooting and configuration.

There are multiple ways to deploy AD DS:

1. Enable Azure Active Directory Domain Services in the tenant’s virtual networking environment. This will create a managed AD DS instance for the tenant based on the users and groups that exist in Azure AD.
2. Set up a stand-alone AD DS server in the tenant’s virtual networking environment. This gives you all of the full control of the AD DS instance running on virtual machines.
3. Create a site-to-site VPN connection to an AD DS server located on the tenant’s premises. This allows the tenant to connect to their existing AD DS instance and reduce duplication of users, groups, organizational units, and so on.

For more information, see the following articles:

SQL database

A highly-available SQL database is used by the Remote Desktop Connection Broker to store deployment information, such as the mapping of current users’ connections to the host servers.

There are multiple ways to deploy an SQL database:

1. Create an Azure SQL Database in the tenant’s environment. This provides you with the functionality of a redundant SQL database without you having to manage the servers themselves. This also allows you to pay for what you consume instead of investing in infrastructure.
2. Create an SQL Server AlwaysOn cluster. This allows you to leverage existing SQL Server infrastructure and gives you complete control over the SQL Server instances.

For more information about how to set up a highly-available SQL database infrastructure, see the following articles:

File server

The file server uses the Server Message Block (SMB) 3.0 protocol to provide shared folders. These shared folders are used to create and store user profile disk files (.vhdx) to back up data and let users share data with each other within the tenant’s cloud service.

The virtual machine that deploys the file server must have an Azure data disk attached and configured with shared folders. Azure data disks use write-through caching, guaranteeing that writes to the disk will not be erased whenever the virtual machine is restarted.

Small tenants can reduce costs by combining the file server and RD Licensing role on a single virtual machine in the tenant’s environment.

For more information, see the following articles:

User profile disks

User profile disks allow users to save personal settings and files when they are signed in to a session on an RD Session Host server in one collection, then access the same settings and files when signing in to a different RD Session Host server in the collection. When the user first signs in, the tenant’s file server creates a user profile disk that gets mounted to the RD Session Host server that the user is currently connected to. For each subsequent sign-in, the user profile disk is mounted to the appropriate RD Session host server, and it is unmounted with each sign-out. Only the user can access the profile disk’s contents.

Hosting services

To become active, a service must be hosted within a run-time environment that creates it and controls its context and lifetime. Windows Communication Foundation (WCF) services are designed to run in any Windows process that supports managed code.

WCF provides a unified programming model for building service-oriented applications. This programming model remains consistent and is independent of the run-time environment in which the service is deployed. In practice, this means that the code for your services looks much the same whatever the hosting option.

These hosting options range from running inside a console application to server environments such as a Windows service running within a worker process managed by Internet Information Services (IIS) or by Windows Process Activation Service (WAS). Developers choose the hosting environment that satisfies the service’s deployment requirements. These requirements might derive from the platform on which the application is deployed, the transport on which it must send and receive messages, or on the type of process recycling and other process management required to ensure adequate availability, or on some other management or reliability requirements. The next section provides information and guidance on hosting options.

Hosting options

Self-Host in a Managed Application

WCF services can be hosted in any managed application. This is the most flexible option because it requires the least infrastructure to deploy. You embed the code for the service inside the managed application code and then create and open an instance of the ServiceHost to make the service available. For more information, see How to: Host a WCF Service in a Managed Application.

This option enables two common scenarios: WCF services running inside console applications and rich client applications such as those based on Windows Presentation Foundation (WPF) or Windows Forms (WinForms). Hosting a WCF service inside a console application is typically useful during the application’s development phase. This makes them easy to debug, easy to get trace information from to find out what is happening inside of the application, and easy to move around by copying them to new locations. This hosting option also makes it easy for rich client applications, such as WPF and WinForms applications, to communicate with the outside world. For example, a peer-to-peer collaboration client that uses WPF for its user interface and also hosts a WCF service that allows other clients to connect to it and share information.

Managed Windows Services

This hosting option consists of registering the application domain (AppDomain) that hosts a WCF service as a managed Windows Service (formerly known as NT service) so that the process lifetime of the service is controlled by the service control manager (SCM) for Windows services. Like the self-hosting option, this type of hosting environment requires that some hosting code is written as part of the application. The service is implemented as both a Windows Service and as a WCF service by causing it to inherit from the ServiceBase class as well as from a WCF service contract interface. The ServiceHost is then created and opened within an overridden OnStart(String[]) method and closed within an overridden OnStop() method. An installer class that inherits from Installer must also be implemented to allow the program to be installed as a Windows Service by the Installutil.exe tool. For more information, see How to: Host a WCF Service in a Managed Windows Service. The scenario enabled by the managed Windows Service hosting option is that of a long-running WCF service hosted outside of IIS in a secure environment that is not message-activated. The lifetime of the service is controlled instead by the operating system. This hosting option is available in all versions of Windows.

Internet Information Services (IIS)

The IIS hosting option is integrated with ASP.NET and uses the features these technologies offer, such as process recycling, idle shutdown, process health monitoring, and message-based activation. On the Windows XP and Windows Server 2003 operating systems, this is the preferred solution for hosting Web service applications that must be highly available and highly scalable. IIS also offers the integrated manageability that customers expect from an enterprise-class server product. This hosting option requires that IIS be properly configured, but it does not require that any hosting code be written as part of the application. For more information about how to configure IIS hosting for a WCF service, see How to: Host a WCF Service in IIS.

IIS-hosted services can only use the HTTP transport. Its implementation in IIS 5.1 has introduced some limitations in Windows XP. The message-based activation provided for a WCF service by IIS 5.1 on Windows XP blocks any other self-hosted WCF service on the same computer from using port 80 to communicate. WCF services can run in the same AppDomain/Application Pool/Worker Process as other applications when hosted by IIS 6.0 on Windows Server 2003. But because WCF and IIS 6.0 both use the kernel-mode HTTP stack (HTTP.sys), IIS 6.0 can share port 80 with other self-hosted WCF services running on the same machine, unlike IIS 5.1.

Windows Process Activation Service (WAS)

Windows Process Activation Service (WAS) is the new process activation mechanism for the Windows Server 2008 that is also available on Windows Vista. It retains the familiar IIS 6.0 process model (application pools and message-based process activation) and hosting features (such as rapid failure protection, health monitoring, and recycling), but it removes the dependency on HTTP from the activation architecture. IIS 7.0 uses WAS to accomplish message-based activation over HTTP. Additional WCF components also plug into WAS to provide message-based activation over the other protocols that WCF supports, such as TCP, MSMQ, and named pipes. This allows applications that use communication protocols to use the IIS features such as process recycling, rapid fail protection, and the common configuration system that were only available to HTTP-based applications.

This hosting option requires that WAS be properly configured, but it does not require you to write any hosting code as part of the application. For more information about how to configure WAS hosting, see How to: Host a WCF Service in WAS.

Choose a Hosting Environment

The following table summarizes some of the key benefits and scenarios associated with each of the hosting options.

Hosting Environment	Common Scenarios	Key Benefits and Limitations
Managed Application («Self-Hosted»)	— Console applications used during development. — Rich WinForm and WPF client applications accessing services.	— Flexible. — Easy to deploy. — Not an enterprise solution for services.
Windows Services (formerly known as NT services)	— A long-running WCF service hosted outside of IIS.	— Service process lifetime controlled by the operating system, not message-activated. — Supported by all versions of Windows. — Secure environment.
IIS 5.1, IIS 6.0	— Running a WCF service side-by-side with ASP.NET content on the Internet using the HTTP protocol.	— Process recycling. — Idle shutdown. — Process health monitoring. — Message-based activation. — HTTP only.
Windows Process Activation Service (WAS)	— Running a WCF service without installing IIS on the Internet using various transport protocols.	— IIS is not required. — Process recycling. — Idle shutdown. — Process health monitoring. — Message-based activation. — Works with HTTP, TCP, named pipes, and MSMQ.
IIS 7.0	— Running a WCF service with ASP.NET content. — Running a WCF service on the Internet using various transport protocols.	— WAS benefits. — Integrated with ASP.NET and IIS content.

The choice of a hosting environment depends on the version of Windows on which it is deployed, the transports it requires to send messages and the type of process and application domain recycling it requires. The following table summarizes the data related to these requirements.

Hosting Environment	Platform Availability	Transports Supported	Process and AppDomain Recycling
Managed Applications («Self-Hosted»)	Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008	HTTP, net.msmq	No
Windows Services (formerly known as NT services)	Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008	HTTP, net.msmq	No
IIS 5.1	Windows XP	HTTP	Yes
IIS 6.0	Windows Server 2003	HTTP	Yes
Windows Process Activation Service (WAS)	Windows Vista, Windows Server 2008	HTTP, net.msmq	Yes

It is important to note that running a service or any extension from an untrusted host compromises security. Also, when opening a ServiceHost under impersonation, an application must ensure that the user is not logged off, for example by caching the WindowsIdentity of the user.