WCF: Application Deployment Scenarios

Production Application Scenarios

WCF is a platform rich in features that can be employed in numerous application scenarios – the most common of which are listed in Table 1.

Table1: Common production application scenarios for WCF

Scenario	Description
Enterprise Web Services	Support for simple web services based on SOAP protocol or advanced implementations that rely on WS*.
Web 2.0 Services	A web programming model that supports POX, REST, JSON, RSS and Atom.
Intranet Applications	Classic client-server applications and distribution of services behind the firewall.
Queued Messaging	Asynchronous calls, disconnected calls and publish and subscribe patterns.
Workflow Services	Coordinating calls from a workflow, exposing a workflow as a service, and durable services.

This whitepaper summarizes the value proposition of each of these production application scenarios for WCF, the implementation characteristics of each scenario, a summary of important development considerations, and answers to typical questions related to each scenario.

Scenario: Enterprise Web Services

Since the late 1990's application developers have relied on web services based on SOAP protocol and other advanced web service protocols (collectively known as WS*) to support interoperable messaging across heterogeneous platforms. Although interoperability is the primary value proposition, web service technologies have other singular advantages. For example, most platforms provide tools for creating services; for producing a Web Service Description Language (WSDL) document to describe service metadata and policy; and for generating client code from the WSDL to call services – which is great for productivity. Web services make distributed communication over the Internet easy to achieve, but also can be useful in safely sending messages through firewalls within an organization domain.

WCF provides built-in support for the latest web service protocols. As Figure 1 illustrates WCF services are interoperable with Java platforms supporting early or recent versions of web service protocols, but can also be consumed by .NET 2.0 clients, Web Services Enhancements (WSE) 3.0 clients and .NET 3.0 clients. In a related point it is also possible to replace ASP.NET web services (ASMX) and WSE 3.0 web services with WCF services – without impact to existing clients.

Figure 1: WCF services support a wide range of protocols for interoperability with many platforms

Compatibility of WCF services with other platforms is ultimately decided by protocol support. Developers should configure their WCF services to support the appropriate protocols compatible with known clients, or provide options for unknown clients. The sections to follow will summarize the protocol options, then describe typical production application scenarios for exposing enterprise web services with WCF – describing the typical hosting environment, protocol support and relevant configuration settings.

Protocol Support

SOAP protocol is at the heart of web services. WS* protocols were introduced as extensions to SOAP to solve specific problems related to distributed communications such as passing binary data, addressing, security, reliability, and transactions – in an interoperable way. WCF supports all of the core protocols within WS* - some are ratified by W3C (www.w3c.org), some by OASIS (www.oasis-open.org), and some are simply well adopted standards approaching ratification by either standards body. The list of supported protocols within WCF is shown in Table 2.

Table 2: Core protocol support in WCF

Category	Protocol Support
Messaging	SOAP, WS-Addressing, MTOM
Metadata	WSDL, WS-MetadataExchange, WS-Policy
Security	WS-Security, WS-SecureConversation, WS-Trust
Reliability	WS-ReliableMessaging
Transactions	WS-Coordination, WS-AtomicTransaction

Fortunately, WCF hides the implementation details of these protocols from the developer – leaving them to select configuration settings according to the protocols they need to support. The choice of protocols to support can be narrowed based on the application scenario:

• Services to be consumed by specific client platforms should employ protocols according to what that client can support.
• Services to be consumed by unknown client platforms can employ protocols that reach the lowest common denominator.
• Services to be consumed by other WCF clients can be configured to take advantage of the latest protocols appropriate for the scenario.
• Services can be configured so that they support several protocol configurations so that the same service can be reached by a multitude of client platforms.

Simple Web Services

The fundamental purpose of web services is to control how business functionality is exposed to the Internet and how client applications can interact with that functionality. Interoperability is an important part of this, as is the ability to safely send requests through firewalls. In its simplest form a web service receives SOAP messages over HTTP that target specific operations exposed by the service boundary. Figure 2 illustrates a client application calling two distinct WCF services hosted in IIS – where each WCF service encapsulates specific functionality.

Figure 2: WCF services encapsulate application functionality

To secure public-facing web services, the majority of applications today choose from the following options:

• Username and password over SSL
• Username and password using SOAP message security

Both configurations are interoperable with the majority of platforms today, making them a natural choice to gain wider platform reach.

Implementation Characteristics

Web services exposed to the Internet usually share a few common characteristics – regardless of the chosen model for security. Services are hosted in IIS over HTTP, messaging is based on SOAP protocol, and client applications rely on generated proxies to communicate with services (see Figure 3).

Figure 3: WCF services hosted in IIS usually support SOAP messaging over HTTP

While this core implementation remains the same there are always variations to the configuration based on SOAP and WS* protocol selection – specifically for security. Most web services rely on username and password security. The most popular choice is still to rely on SSL certificates to secure messages transferred between clients and services – so that messages are sent over HTTPS.

The implementation characteristics of a service configured for username and password over SSL are listed in Table 3.

Table 3: Implementation characteristics for username and password over SSL

Characteristic	Description
Hosting	IIS 6 on Windows Server 2003, IIS 7 on Windows Server 2008
Transport Protocol	HTTPS
Messaging Protocol	SOAP + WS-Addressing
Authentication	Username and password are provided as part of the SOAP message based on WS-Security and the UsernameToken Profile.
Authorization	A custom credential store is typically used since users are not usually part of a Windows domain.
Transfer Protection	An SSL certificate is provided to protect (sign and encrypt) messages.

Typical implementations of username and password over SSL are based on the latest released versions of SOAP and WS-Addressing, clients pass a UsernameToken according to the WS-Security specification, and SSL certificates are used to secure message transfer between clients and services. This configuration is illustrated in Figure 4.

Figure 4: Username and password over SSL

Another configuration typical of simple web services is to use message security to protect message transfer, instead of SSL. The implementation characteristics for this configuration are shown in Table 4.

Table 4: Implementation characteristics for username and password over message security

Characteristic	Description
Hosting	IIS 6 on Windows Server 2003, IIS 7 on Windows Server 2008
Transport Protocol	HTTP
Messaging Protocol	SOAP + WS-Addressing
Authentication	Username and password are provided as part of the SOAP message based on WS-Security and the UsernameToken Profile.
Authorization	A custom credential store is typically used since users are not usually part of a Windows domain.
Transfer Protection	WS-Security protocols rely on an X.509 certificate provided for the service to protect (sign and encrypt) messages.

With message security, WS-Security protocol is used to protect the actual SOAP message – preventing any intermediate services from inspecting message contents unless they are trusted. The configuration is otherwise the same as for username and password over SSL. Figure 5 illustrates the message security scenario.

Figure 5: Username and password over message security

For both configurations a username and password is sent in a standards-based way (UsernameToken Profile) to authenticate the caller and a custom credential store is usually used for authentication and authorization.

Service Configuration

Developers follow a similar set of steps to create and host a WCF service, regardless of the application scenario. Here is a summary of those steps:

• Developers apply the ServiceContractAttribute to create a service contract, and apply the OperationContractAttribute to each method that should be accessible to clients as service operations.
• A service type implements the service contract and handles calls to business components.
• Operations associated with a service contract are made available to clients at a particular address, over a chosen set of protocols.

This approach is common to all service implementations so the distinguishing factor for each scenario is a matter of protocols and runtime behaviors specific to the scenario.

To configure services for username and password over SSL as described in Figure 4 developers can use standard features of WCF as follows:

• Configure the service endpoint to use WSHttpBinding which is an interoperable binding that supports the latest SOAP and WS-Addressing standards by default.
  1. Use transport security (SSL) to protect messages during transfer.
  2. Use message security to pass the username and password credentials.
  3. Disable the service credential negotiation feature since it is not interoperable.
  4. Disable the secure sessions feature since it is an advanced standard.
• Configure authentication and authorization behaviors for the service to use a custom credential store.
• Provide an SSL certificate for IIS.

To configure services to use message security instead of SSL (as shown in Figure 5) the following differences apply to the configuration:

• Change the following WSHttpBinding options:
  1. Do not use transport security, use message security for both credentials and message protection.
• Provide an X.509 certificate for the service.

Choosing SSL or Message Security

The choice between SSL or message security is a simple binding configuration for transport or message security. SSL is often a more popular choice for web services because the HTTPS address inspires confidence in data transfer. In fact, message security is equally secure, but since the address uses HTTP instead of HTTPS some environments will not allow it. Outside of an administrative mandate to use HTTPS, the following factors should be considered when choosing SSL or message security:

• SSL security protects messages from point-to-point (see Figure 6). The client application sending the message cannot guarantee that no other proxies or routers will decrypt the message prior to forwarding to the service. Unless all hops are secured with SSL or some other mechanism, data can end up in the open.
• Message security protects messages from end-to-end (see Figure 7). Since the actual SOAP message is encrypted and signed, there is no doubt that only a trusted network node can process the message.
• SSL better supports the transfer of large messages. SSL accelerators are available to improve performance of secure messaging.

Figure 6: Transport security protects messages point-to-point

Figure 7: Message security protects messages end-to-end

Working with Username and Password Credentials

Requiring client applications to send a username and password is a simple binding configuration. The UsernameToken format is based on a standard protocol – client applications typically use a proxy to set the values and let the platform format the SOAP message according to the protocol.

Developers must configure the service to perform authentication and authorization against a custom credential store – since the default behavior of WCF is to rely on the Windows domain. Developers can set the authentication and authorization behaviors to one of the following settings to achieve this:

• Developers can use the built-in ASP.NET provider model, which provides a set of tables for users and roles. This provider model can be configured to talk to SQL Server, Oracle and other database platforms.
• Developers can use the built-in ASP.NET provider model, but provide a customized implementation of the membership and roles providers to go against a custom set of tables formatted for the business domain.
• Developers can use a custom password validator component that relies on custom code to authenticate calls against the selected data store. This implementation is usually preferred when a custom set of tables is involved, rather than building a custom membership and roles provider.

Hosting Environment

Web services exposed to the Internet are usually hosted in IIS 6 or IIS 7, depending on the Windows server platform. In either case, they can be accessed via HTTP or HTTPS protocol. Figure 8 illustrates the hosting environment.

Figure 8: WCF services hosted in IIS are addressed by a .svc extension

The way activation works for a WCF service hosted in IIS is as follows:

• Messages are directed to a .svc file that is associated with the actual service type.
• If a worker process is not available to handle the request, IIS initializes a worker process according to application pooling configuration and then forwards the request to that process.
• The service type associated with the .svc address is initialized and the appropriate operation is executed according to the request.

Proxy Generation

A Web Service Description Language (WSDL) document can be generated for any WCF service. WSDL is an interoperable standard for describing the following information about a web service:

• The address where it can be reached.
• The protocols it supports.
• The operations available for clients to call.
• The message schema associated with each operation – which ultimately maps to parameters or return values from operations.

Client applications usually rely on WSDL to generate proxies to call services – reducing the development effort significantly. For WCF clients, proxy generation can be automated through the Visual Studio environment. The result is that a copy of the service contract and any related complex types (usually data contracts) are generated for the client so that they get a similar object model for communicating with services. A client configuration file is usually generated as well, supplying the proxy with the correct protocols for communication. Figure 9 illustrates this flow.

Figure 9: Proxy generation for WCF clients

An alternative to using WSDL to generate proxies is to use WS-MetadataExchange protocol. This protocol allows clients to dynamically query a service for the information that would be represented in a WSDL document.

Common Questions

Q. Can web services also be hosted in a Windows NT Service?

WCF services can be hosted in a Windows NT Service and made available over any protocol, including HTTP or HTTPS. This does not take advantage of the hosting features only IIS and WAS provide as discussed in the section "Flexible Hosting Model" but it can be useful if IIS is not an option.

Q. Can a single WCF service support clients that use both the SSL and Message Security scenario?

Yes, this is discussed in the section "Supporting Multiple Configurations" later on.

Q. What other credential types are supported for web services?

Although username and password are the most common format for a web service, it is possible to use these other credential types:

Windows credentials are appropriate only if all users will be managed by the Windows domain.

Certificate credentials are sometimes appropriate for business partner exchanges.

Issued tokens, such as SAML tokens used in federated scenarios, are appropriate for advanced scenarios.

Q. Do most platforms support UsernameToken Profile?

Almost all platforms today support WS-Security and UsernameToken Profile since they have been available as early as 2003, and have been fully ratified since 2004. These protocols provide a standards-based way to pass username and password credentials in a secure manner. Developers rarely, if ever, have to inspect the related XML.

Q. What happens if the UsernameToken format is not compatible with another platform?

Although platforms have support for UsernameToken, there are times when the token format can be incompatible. By default, WCF requires that the UsernameToken includes a timestamp and nonce for message replay detection. Some other platforms do not send this information by default, but they do have a simple switch to support it. The WCF default is the more secure one, it is best to make sure callers are sending this information. However, WCF can be configured to disable verification of timestamps to interoperate with callers that do not support them.

Q. What is the purpose of the service credential negotiation feature in WSHttpBinding?

WSHttpBinding, WS2007HttpBinding, WSFederationHttpBinding and WS2007FederationHttpBinding all support negotiation by default. This feature makes it possible for a client to dynamically request the service certificate in order to secure messages exchanged with the service. Negotiation is not an interoperable feature but it is very useful when the client is also WCF because it removes the need for the client to have prior access to the service certificate. This feature is easily disabled, but without negotiation the client requires a copy of the service certificate in advance.

Q. How can the client get the service certificate in advance?

Information about the service certificate is provided in the WSDL document. When proxies are generated for WCF clients, a copy of the certificate is included in the client configuration – which means that there is no need to install the service certificate into a certificate store in order to access it. Other platforms may handle this in different ways.

Advanced Web Services

Although it may not be mainstream for interoperable scenarios today, some of the advanced web service protocols under the WS* umbrella can be very useful for specific scenarios – and they are indeed interoperable. Table 5 lists the WCF features associated with these protocols.

Table 5: WCF features that enable advanced web service protocols

Feature	Description
Secure Sessions	WS-SecureConversation and WS-Trust are protocols used in combination to negotiate a "secure session" between clients and services. When secure sessions are enabled, only the first call from the client need be authenticated. Subsequent calls within the session need only be authorized. This reduces the overhead of the authentication step for each call, and can also reduce the overhead of message transfer size since a negotiated symmetric key is used to encrypt and sign messages – instead of a larger, asymmetric key.
Reliable Sessions	WS-ReliableMessaging is a protocol that provides a "reliable session" delivery guarantees. Each message sent within a reliable session must be acknowledged by the service, or it will be resent by the client using a retry mechanism built-in to the platform. This allows message delivery to survive transient interruptions in network connectivity. In-order delivery can also be guaranteed – which is helpful if messages must arrive in order – for example, to recompose a large file that was broken into chunks for delivery.
Transactions	WS-AtomicTransaction and WS-Coordination are protocols to support transactional programming. This makes it possible to perform a distributed transaction through firewalls or across platforms.

Web services that implement these features typically use the same configuration as discussed for username and password over message security – they simply enhance communication performance and reliability by adding on these features. For platforms that support the latest web service protocols, secure sessions and reliable sessions are a desirable feature to enable. Transactions are less commonly exposed to the Internet.

Implementation Characteristics

Web services that take advantage of advanced web service protocols are still fundamentally based on the username and password over message security scenario. WCF services will still be hosted in IIS, rely on username and password authentication and authorization against a custom credential store, and use message security instead of SSL. The assumption here is that client applications will be capable of leveraging advanced protocols and the benefits they bring. Specifically, it is becoming more popular to enable secure sessions and reliable sessions to optimize communications and improve reliability over HTTP. Table 6 lists the implementation characteristics for WCF services that add these features.

Table 6: Implementation characteristics web services with secure sessions and reliable sessions enabled

Characteristic	Description
Hosting	IIS 6 on Windows Server 2003, IIS 7 on Windows Server 2008
Transport Protocol	HTTP
Messaging Protocol	SOAP + WS-Addressing
Authentication	Username and password are provided as part of the SOAP message based on WS-Security and the UsernameToken Profile. WS-SecureConversation is enabled to optimize authentication.
Authorization	A custom credential store is typically used since users are not usually part of a Windows domain.
Transfer Protection	WS-Security protocols rely on an X.509 certificate provided for the service to protect (sign and encrypt) messages.
Reliability	WS-ReliableMessaging protocol is enabled.

This implementation still relies on the latest released versions of SOAP and WS-Addressing, clients still pass a UsernameToken according to the WS-Security specification, and a service certificate is still used to secure message transfer between clients and services. The addition of secure sessions and reliable sessions simply adds a layer to this functionality, as illustrated in Figure 10.

Figure 10: Username and password over message security with secure sessions and reliable sessions enabled

Service Configuration

To configure services for username and password over message security with secure sessions and reliable sessions enabled, developers take the following steps:

• Configure the service endpoint to use WSHttpBinding
  1. Do not use transport security, use message security for both credentials and message protection.
  2. Disable the negotiation feature since it is not interoperable.
  3. Leave the secure sessions feature enabled, since that is the default.
  4. Enable reliable sessions since it is disabled by default.
• Configure authentication and authorization behaviors for the service to use a custom credential store.
• Provide an X.509 certificate for the service.

This configuration enables any client that implements the pre-released version of WS-SecureConversation and WS-ReliableMessaging to call the service successfully. The pre-released version is already implemented in many platform stacks. The final version of these protocols was released in 2007, and is also supported by WCF. There are also a growing number of platforms with implementations for the released version. To achieve the same result with the latest version of the protocols developers would use the WS2007HttpBinding instead of WSHttpBinding – using the same configuration options. The binding switch merely updates the protocol format.

Hosting Environment

The hosting environment for this scenario is much the same as described in the section "Simple Web Services": WCF services are still hosted in IIS 6 or IIS 7 depending on the Windows server platform, and are accessed via HTTP protocol. There are some hosting implications relevant to this scenario since secure sessions and reliable sessions are enabled. Specifically, since WCF maintains the state of a secure session and a reliable session in memory, it is important that requests from the same client sessions (the proxy instance) are returned to the same server machine and application domain where the session lives (see Figure 11). Software load balancers and network load balancing devices can be configured for sticky sessions.

Figure 11: The relationship between client and service with secure sessions and reliable sessions

Common Questions

Q. How do I know which version of the protocol to support?

With prior knowledge of the client applications that will call WCF services it is possible to determine if they support these protocols, or which versions of the protocols they can support for compatibility. If the client applications are unknown, it is best to provide some options – to be discussed in a later section called "Supporting Multiple Configurations".

Q. What is the adoption of secure sessions, reliable sessions and transactions?

Protocols for secure sessions, reliable sessions and transactions have been implemented in a variety of platforms since 2005, and early interoperability tests were performed using versions of the protocols before they were actually ratified by OASIS in 2007. WCF supports the earlier versions of these protocols, but also supports the latest released version of each as of 2007. Many other platforms support the earlier versions of the protocols, and there are a growing number that have begun to support the latest release. Interoperability is widely attainable with early versions of secure sessions and reliable sessions. Interoperable transactions are less common across platforms, although attainable.

Q. When should I use a secure session?

Secure sessions reduce overhead when a client will make multiple calls to a service within the same context. It is always a good idea to enable this feature for client applications that support the protocol.

Q. When should I use a reliable session?

Reliable sessions make it possible to guarantee delivery even in the face of transient network interruptions. It is always a good idea to enable this feature for client applications that support the protocol, in particular for externally facing web services where network connectivity cannot be guaranteed.

Q. Are there any limits to the number of secure sessions or reliable sessions a service can handle?

There is a service throttling behavior that by default only allows 10 transport sessions including secure sessions or reliable sessions. After 10 clients have connected to a particular service within a particular process, subsequent requests will queue waiting for one of the other sessions to release. Developers and operations personnel should estimate the number of users expected to communicate with services to come up with a proper setting for this throttle. It can be easily increased or decreased as needed on production servers to meet demand.

Q. When should I use interoperable transactions?

It is always best to support transactions behind the firewall, rather than exposing web services that let client applications enlist your services in a distributed transaction. In particular when client applications are not known, this can cause transactional resources to be held longer than expected, and can increase the likelihood of transaction timeouts or in-doubt transactions. For WCF services hosted within the application domain, transactions play an important role in guaranteeing system consistency. Enabling interoperable transactions is particularly useful for system messaging between WCF and other platforms.

Q. Is WSDualHttpBinding interoperable?

WSDualHttpBinding is used for two-way communication over HTTP and leverages many of the protocols already discussed. The communication mechanism to enable two-way calling is not, however, interoperable. This binding can be useful in WCF-to-WCF scenarios for two-way messaging over HTTP and through firewalls.

WCF to WCF

In controlled environments where WCF is used for both the client and service, there are fewer restrictions on the choice of protocols used for web services. The assumption here is that the WCF service is exposed to the Internet for remote clients to consume – but that they need not necessarily be interoperable since the client will be WCF as well.

Implementation Characteristics

WCF services exposed to Internet clients also built with WCF would still be hosted in IIS over HTTP, are still likely to rely on username and password credentials that are authenticated and authorized against a custom credential store. For this scenario services are also likely to use message security instead of SSL, and support the advanced protocols discussed in "Advanced Web Services" to take advantage of secure sessions and reliable sessions. Table 7 lists the implementation characteristics for this scenario.

Table 7: Implementation characteristics web services in a WCF-to-WCF scenario

Characteristic	Description
Hosting	IIS 6 on Windows Server 2003, IIS 7 on Windows Server 2008
Transport Protocol	HTTP
Messaging Protocol	SOAP + WS-Addressing
Authentication	Username and password are provided as part of the SOAP message based on WS-Security and the UsernameToken Profile. The released version of WS-SecureConversation is enabled to optimize authentication.
Authorization	A custom credential store is typically used since users are not usually part of a Windows domain.
Transfer Protection	WS-Security protocols rely on an X.509 certificate provided for the service to protect (sign and encrypt) messages.
Reliability	The released version of WS-ReliableMessaging protocol is enabled.

The illustration in Figure 10 still captures this implementation.

Service Configuration

For WCF clients it is possible to leverage the released versions of the advanced protocols, and to enable the negotiation feature to distribute the service certificate to clients dynamically. As such, developers would use the following configuration:

• Configure the service endpoint to use WS2007HttpBinding
  1. Do not use transport security, use message security for both credentials and message protection.
  2. Leave the negotiation feature enabled since interoperability is not an issue.
  3. Leave the secure sessions feature enabled, since that is the default.
  4. Enable reliable sessions since it is disabled by default.
• Configure authentication and authorization behaviors for the service to use a custom credential store.
• Provide an X.509 certificate for the service.

The main difference here is that the latest protocols can be employed, and negotiation can be enabled without concern for interoperability.

Common Questions

Q. Should I use proxy generation if both sides are WCF?

If both sides are controlled by the same development team, it is very common for client applications to use shared libraries (see Figure 12) instead of proxy generation (illustrated in Figure 9) to communicate with services. Developers can then work with a familiar object model on both the client and server, which is good for productivity and maintenance efforts. This also makes it possible to write common validation code for entities that can be shared by clients and services if applicable.

Figure 12 illustrates this architecture.

Figure 12: Sharing contract assemblies between clients and services

To support this possibility, developers should factor their assemblies so that contracts and entities can be shared without sharing service or business logic.

Backward Compatibility

Although most web service platforms today can at least support the scenario described earlier in "Simple Web Services", there are times when services must support earlier protocols, for example:

ASP.NET Web Services (ASMX), for example, support SOAP 1.1 or SOAP 1.2 but do not support WS-Addressing. WCF services can be configured to use SOAP 1.1 without addressing just by selecting the defaults for BasicHttpBinding. To support SOAP 1.2 without addressing a CustomBinding can be used.

WSE 3.0 supports only the very early, non-ratified versions of WS-Addressing, WS-SecureConversation and WS-Trust protocols. By default, WSHttpBinding supports a later version of these protocols. To support WSE 3.0 compatibility a CustomBinding can be used to select these earlier protocol versions.

Non-Microsoft platforms also have platform implementations for very early versions of the protocols discussed thus far, and so the same WCF configuration would apply to achieve interoperability with those platforms.

Supporting Multiple Configurations

If web services are being developed for public consumption – given the choice of protocols available it is important to provide a few different options for unknown clients. This increases the likelihood of compatibility with different platforms. For example, to gain wider reach developers may expose both "Simple Web Services" for the lowest common denominator, and "Advanced Web Services" to support secure sessions and reliable sessions. To support backward compatibility the service may also support SOAP 1.1 as discussed in "Backward Compatibility".

With WCF, the same service can be configured for multiple protocol configurations through different endpoint addresses as shown in Figure 13. Each of these endpoints will be included in the WSDL document so that clients can choose the endpoint most suitable to their platform capabilities.

Figure 13: A WCF service supporting different protocols through multiple endpoints

Scenario: Web 2.0 Services

Web 2.0 programming paradigms have become increasingly popular for building Rich Internet Applications (RIA) or mash-ups that rely on JavaScript as in AJAX, Silverlight and other similar client technologies to produce graphical web interfaces rich in media and interactive content. Traditional web services based on SOAP protocol and WS* are simply not an appropriate selection for this scenario – proxy generation tools aren't available, SOAP messages carry overhead, and enterprise messaging features provided by WS* protocols are not required.

Web 2.0 clients require a different approach that simplifies access to content from browser applications. Table 8 lists alternate messaging protocols are available for Web 2.0 clients.

Table 8: Messaging protocols for Web 2.0 clients

Protocol	Description
POX	Simplified XML messaging without the formality of SOAP protocol.
REST	An alternative to SOAP that often relies on POX at its core. It is an architectural style that leverages a URI-based pattern for accessing resources over the Internet.
JSON	A lightweight messaging format that is an alternative to XML. It is specifically useful for JavaScript clients to exchange data with services with less transfer and processing overhead.
RSS/ATOM	Syndication formats based on XML. They are specifically useful for sharing sequentially updated data feeds such as blog entries.

By taking advantage of WCF's extensibility features, it was technically possible to create WCF services that supported these protocols in .NET 3.0. As of .NET 3.5, however, WCF provides built-in support for these protocols – greatly simplifying things for developers, while still providing the same consistent programming model to implement services. While these messaging styles lack the secure, reliable and transactional delivery semantics of enterprise web services – they do simplify access to content from JavaScript and other Web 2.0 clients, while reducing overhead – and they are interoperable with other platforms.

The following sections will discuss these implementation scenarios in greater detail.

POX and REST

Before SOAP protocols existed, systems were still able to exchange XML data according to an agreed upon format often described by XSD Schema. Plain-Old-XML (POX) is a term used to describe this simple XML messaging style – which is still used today for backward compatibility with pre-SOAP systems, and when simple XML messaging is considered good enough.POX is usually used for sending messages over HTTP protocol, although this is not a requirement for passing XML between all systems that employ it.  

Representational State Transfer (REST) is an architectural style for interacting with resources and providing a representation of those resources for clients. It is particularly useful for CRUD (create, read, update and delete) commands that interact with system resources. Although REST does not require it, the underlying messaging format is usually XML over HTTP protocol – thus, for the purpose of this discussion REST can be thought of as an extension to POX which describes semantics for how systems should expose functionality. Using classic HTTP verbs (PUT, GET, POST, and DELETE) RESTful implementations are able to distinguish CRUD calls that interact with system resources.

To provide some context, Figure 14 illustrates how a POX and REST implementation to interact with resources might differ.

Figure 14: How POX and REST implementations interact with service operations

This is by no means the only way that POX or REST might be used, but it illustrates a few differences between the two approaches. POX makes no statement about how the available URI should be structured, which HTTP verbs to use, or any other details about the interaction with a system. Thus, a system can make one or more URI available, possibly using HTTP GET and POST, and define system actions as HTTP headers, XML elements, or different URI. REST over HTTP suggests that each URI points to a collection of resources or a specific resource, and that the HTTP verb indicates the action to be taken on the resource. In this way a client application may infer some patterns for interacting with the system, even without the help of proxy generation and supporting documentation.

In either case, there are some common factors:

• Neither approach relies on SOAP or WS* protocols.
• Neither approach provides proxy generation to support clients.
• Both approaches rely on unique URI to access system resources and functionality.
• Both approaches use XML messaging format (though, REST does not require this).
• Both approaches are usually based on HTTP and may use several different HTTP verbs to achieve a result.

The following sections will explain the WCF implementation characteristics and features assuming these common factors.

Implementation Characteristics

The implementation characteristics for POX and REST services are fundamentally the same – with the exception of URI and HTTP verb semantics. Figure 15 illustrates a WCF service hosted in IIS that exposes a POX endpoint to Windows and browser client applications.

Figure 15: A WCF service exposing a POX endpoint

POX and REST services will typically be hosted in IIS and exposed to the Internet over HTTP, although this is not a requirement. These types of services are often intended for wide community reach and to support social networking sites – thus are not always secured – but there are a few options for securing communications over HTTP protocol. Table 9 lists these characteristics.

Table 9: Implementation characteristics of POX and REST services

Characteristic	Description
Hosting	IIS 6 on Windows Server 2003, IIS 7 on Windows Server 2008
Transport Protocol	HTTP or HTTPS
Messaging Protocol	XML
Authentication	Basic authentication (username and password) would be the typical choice, however digest, Windows integrated security and certificates are also supported.
Authorization	A custom credential store unless Windows credentials are requested.
Transfer Protection	If required, SSL is supported.

Clients can be Windows client applications, or browser applications using JavaScript (AJAX), Silverlight, Flash or other RIA technologies. Although they don't use traditional web service proxies to call services, each client has a programming model available to them for calling POX and REST services. This usually involves working directly with the XML for both requests and responses.

Service Configuration

WCF services designed for POX or REST implementations should take advantage of new features in .NET 3.5 to simplify the development effort.

• Developers apply the WebGetAttribute and WebInvokeAttribute to each operation in the service contract in order to specify the URI and HTTP verb for the operation, in addition to the messaging format – in this case XML.
• The template-based mapping feature gives developers the flexibility to specify many formats for application URI that map to operations. URI templates support parameters including query strings and pass them as parameters to operations for a productive programming model.
• POX and REST endpoints must use WebHttpBinding and WebHttpBehavior to bypass traditional SOAP message filtering. This ensures that messages directed to specific URI reach the appropriate operation.

Otherwise, the programming model is the same as with other WCF service implementations. Developers implement the service contract on a service type, working with parameters and return values rather than directly with XML.

Figure 16 illustrates a POX implementation exposing four operations: GetCustomers(), NewCustomer(), UpdateCustomer(), and DeleteCustomer(). The URI and HTTP verb mapped to each operation is indicated by the associated WebGetAttribute or WebInvokeAttribute.

Figure 16: Simplified view of a POX service contract

Figure 17 illustrates the same functionality exposed as a RESTful contract. The main difference being the choice of URI pattern, and HTTP verb used to map operations.

Figure 17: Simplified view of a RESTful service contract

Hosting Environment

POX and REST services can be hosted in any Windows application, but are typically hosted in IIS and exposed to the Internet. In either case only HTTP or HTTPS protocols are supported for this type of WCF service today. Since POX and REST services do not support session, requests do not require affinity to a particular server machine and can be easily distributed across a server farm as shown in Figure 18.

Figure 18: POX or REST services distributed across a server farm

Security

Unlike SOAP web services, POX and REST services do not support message security. Developers can secure calls to POX and REST services using the following techniques:

• To protect messages during transfer, SSL certificates can be used to secure communications with the service.
• Credentials can be provided in HTTP headers thus are limited to basic, digest, Windows integrated security or certificates (the latter of which would be less common).

Client Programming Model

POX and REST services do not have an equivalent to WSDL, or any proxy generation tools. Client applications must build HTTP requests to call services directly. There are various programming models available to do this, each of them requiring developers to supply an address to the service operation, an HTTP verb, various HTTP headers, and the actual XML data to be sent along if the request is a POST or PUT instruction.

Common to most of these models is the XmlHttpRequest object which is ultimately responsible for sending requests to services. In fact this object can support sending requests to SOAP (not WS*), XML or JSON services as shown in Figure 19.

Figure 19: The XmlHttpRequest object can be used to call SOAP, XML or JSON services

Common Questions

Q. Can REST services be used as an alternative to SOAP and WS*?

SOAP and WS* protocols exist to solve enterprise messaging needs with their rich security features and support for reliable messaging, transactions and other protocols. The industry has invested years coming to agreement to these protocols so that the various platforms can agree and be interoperable. These protocols are very useful in rich enterprise messaging scenarios.

POX and REST have existed for about the same number of years, but still do not have proxy generation tools, nor do they support many enterprise messaging scenarios. That said they are simple to implement and quite appropriate for Web 2.0 client applications and simpler enterprise application implementations.

Q. Can the same service implementation be used for SOAP or POX/REST implementations?

Yes, it is possible to host the same WCF service so that it supports SOAP and WS* protocols or POX and REST messaging. The difference is in the binding and behavior configuration of the service.

Q. Are POX and REST services implemented with WCF interoperable?

POX and REST services are interoperable, but there are differences in the default implementation compared to other platforms. Using the WebGetAttribute and WebInvokeAttribute developers are able to specify if they want the XML to be wrapped or unwrapped. If wrapped is chosen, an extra XML element that correlates the name of the service operation is always present in the request and response XML. If unwrapped is chosen, this element is not present however there is an XML element indicating the data type of each operation parameter or return type. In either case, other platforms can easily format messages to send the correct XML and parse the XML response.

Other platforms differ in that they usually send parameters as content type "application/x-form-url-encoded". To support this, developers must design their service operations to receive a Stream or NameValueCollection parameter.

Q. What is the WebServiceHostFactory?

Instead of manually configuring a WCF service so that it bypasses SOAP message filtering, the service can be hosted using the WebServiceHostFactory which automatically enables the WebHttpBehavior for the service. In addition, this factory will create a default endpoint for the service if one is not provided in the configuration settings for the host application. This is known as a configuration free service.

You will usually provide an endpoint configuration regardless, to customize binding and behavioral settings.

Q. What are ADO.NET Data Services?

ADO.NET Data Services are a feature of ASP.NET 3.5 Extensions that enable RESTful access to data through WCF services as follows:

• A WCF Service template is provided that can be associated with an Entity Framework or LINQ to SQL data model, and other types that support queries.
• The base implementation of the service provides a contract that can support requests over HTTP using PUT, GET, POST and DELETE verbs.
• The URI syntax to reach the service is derived from the chosen data source – providing basic CRUD operations and rich query support. A consistent URI pattern is provided for interacting with all resources.

JSON

JavaScript Object Notation (JSON) is a messaging format specifically designed to support JavaScript clients. Like POX and REST, JSON is useful primarily for web programming over HTTP. Compared to XML, JSON carries less overhead, is more simplistic, and there are many supporting features of the Web 2.0 client programming model that naturally work with JSON to streamline development efforts.

Here are some similarities and differences exist between POX and REST implementations and JSON implementations:

• JSON, POX and REST all rely on unique URI to interact with application functionality.
• JSON is an alternative messaging format to XML, but like POX makes no statement about URI formats.
• Some client programming models support proxy generation for JSON, unlike for XML.
• REST implementations can use JSON instead of XML as the messaging format.
• The following sections will explain the WCF implementation characteristics for JSON applications.

Implementation Characteristics

The implementation characteristics for JSON services are fundamentally the same as POX or REST services – with the exception of the messaging format. Figure 20 illustrates a WCF service hosted in IIS that exposes a JSON endpoint to browser-based clients.

Figure 20: A WCF service supporting JSON

As with POX and REST services, JSON services are not always secured. The same options exist for JSON services as shown in Table 10.

Table 10: Implementation characteristics of JSON services

Characteristic	Description
Hosting	IIS 6 on Windows Server 2003, IIS 7 on Windows Server 2008
Transport Protocol	HTTP or HTTPS
Messaging Protocol	JSON
Authentication	Basic authentication (username and password) would be the typical choice, however digest, Windows integrated security and certificates are also supported.
Authorization	A custom credential store unless Windows credentials are requested.
Transfer Protection	If required, SSL is supported.

JSON services will typically be hosted in IIS and exposed to the Internet. Although a Windows client could feasibly communication with a JSON service, it is an unlikely scenario since browser applications that rely on JavaScript (AJAX), Silverlight, Flash or other RIA technologies are the target client application for JSON. Unlike with XML messaging, JSON greatly simplifies the development effort for clients – particularly when a JavaScript proxy can be generated to call JSON services.

Service Configuration

The new features of .NET 3.5 make it easy to support JSON messaging format from a WCF service. In fact, the implementation is very similar to POX and REST with only a few differences. Here is a summary of the configuration steps noting those differences:

• Developers apply the WebGetAttribute and WebInvokeAttribute to each operation in the service contract in order to specify the URI and HTTP verb for the operation. Unlike POX and REST, the messaging format should be JSON instead of XML.
• JSON endpoints also use WebHttpBinding and WebHttpBehavior to bypass traditional SOAP message filtering. This ensures that messages directed to specific URI reach the appropriate operation.
• JSON endpoints can also use a special behavior called WebScriptEnablingBehavior which specifically targets ASP.NET clients to significantly reduce the client development effort.

The programming model is once again the same as with other WCF service implementations. Developers implement the service contract on a service type, working with parameters and return values rather than directly with JSON. The illustrations for POX and REST service implementations in Figure 16 and Figure 17 can also be representative of a JSON service – since the only difference would be in the format of the messages exchanged between client and service.

ASP.NET Applications and JSON Services

There are some features supplied with .NET 3.5 that are specifically geared at simplifying how ASP.NET applications communicate with JSON services. Applying the WebScriptEnablingBehavior instead of the WebHttpBehavior to a JSON service endpoint enables a proxy generation feature whereby the /js suffix can be added to the service address to produce a JavaScript proxy. This proxy encapsulates JavaScript functions to call service operations – ultimately using the XmlHttpRequest object.

Although developers can save a copy of the resulting JavaScript file, the ASP.NET ScriptManager control can instead be used to reference this script and dynamically produce the proxy to make it available to page code. The result is that developers can work with a friendly object model to call service operations – passing parameters and receiving return values without having to parse JSON. Figure 21 illustrates this communication flow.

Figure 21: A JavaScript proxy dynamically generated for JSON services

Hosting Environment

The hosting environment for JSON services is the same as is described for POX and REST services in the section "POX and REST".

Security

JSON supports the same security features as POX and REST services – as described in the section "POX and REST".

Client Programming Model

Other than specific support for ASP.NET applications (discussed in the section "ASP.NET Applications and JSON Services"), clients that communicate with JSON services do not typically have proxy generation tools. Client applications must build HTTP requests to call services directly using available programming models that usually rely on XmlHttpRequest at their core. The simplicity of JSON lies in the reduced effort building up a request message, and parsing the response – which is much less work than with XML.

Common Questions

Q. Are JSON services implemented with WCF interoperable?

There are two techniques for implementing JSON services in WCF. The first technique is to use the WebHttpBinding with WebHttpBehavior, the second technique is to use WebHttpBinding with WebScriptEnablingBehavior. Both messaging formats are interoperable with any JavaScript client however the JavaScript proxy is specifically intended for ASP.NET clients.

Q. Should I use WebHttpBehavior or WebScriptEnablingBehavior?

Using WebScriptEnablingBehavior is preferred for ASP.NET client applications.

Q. What is the WebScriptServiceHostFactory?

Instead of manually configuring the WebScriptEnablingBehavior developers can host JSON services using the WebScriptServiceHostFactory which automatically enables the behavior. It simplifies configuration steps required to host the service.

Q. Can the same service support XML and JSON?

Since the messaging format is selected as part of the service contract, it is not possible to design a single service contract that supports both XML and JSON messaging. You can, however, expose the same service contract for SOAP and WS* or JSON.

There are ways to work around this limitation. For example, developers can manipulate message properties to change the format of an outgoing message. It is also possible to create a more general service contract whose service implementation does the following:

• Check the HTTP request's content-type header to see if the incoming request is SOAP, JSON or XML.
• Check the HTTP request verb to determine if the request is a PUT, GET, POST or DELETE command.
• Check the HTTP request's accept header to see if the response should be SOAP, JSON or XML.
• Handle request processing according to these requirements.

ADO.NET Data Services (discussed briefly in the section "POX and REST") handle requests in this manner.

RSS and Atom

Really Simple Syndication (RSS) and Atom are common syndication formats that enable client applications to access content that is typically chronographic in nature with potentially frequent updates. This makes it possible for applications to aggregate the latest content from many sources and present it, without having to explicitly revisit the site that produces the content. The latest versions of these syndication formats are RSS 2.0 and Atom 1.0. RSS has been around longer, and has a larger following – but Atom improves on RSS and is growing in popularity.

Although syndication may frequently be associated with news feeds or blogs, syndication feeds can be created for any type of content an application would like to share that fits the model. Using new features released with .NET 3.5 developers can easily create WCF services that expose syndication feeds using these standard syndication formats.

Implementation Characteristics

POX, REST, JSON and syndication services have many characteristics in common however syndication services have some subtle differences in the way they are implemented. Typical characteristics for syndication services include the following:

• Hosted in IIS and accessible over HTTP, although this is not a requirement.
• Are usually designed to rely on unique URI similar to the approach with POX services.
• Syndication feeds can be formatted as RSS or Atom with are both based on XML – but it is also possible to return either type of feed using JSON messaging format.
• The client programming model does not usually rely on proxy generation to access feed data – instead there are other programming models available to work with feeds.

Table 11 summarizes these characteristics.

Table 11: Implementation characteristics of syndication services

Characteristic	Description
Hosting	IIS 6 on Windows Server 2003, IIS 7 on Windows Server 2008
Transport Protocol	HTTP or HTTPS
Messaging Protocol	XML or JSON
Authentication	Basic authentication (username and password) would be the typical choice, however digest, Windows integrated security and certificates are also supported.
Authorization	A custom credential store unless Windows credentials are requested.
Transfer Protection	If required, SSL is supported.

As Figure 22 illustrates, the implementation of a WCF service operation controls the type of syndication feed returned to calling clients. Service operations can explicitly return RSS 2.0 or Atom 1.0 feeds – or dynamically decide what type of feed to return based on the URI or a query string parameter.

Figure 22: WCF service operations can return a specific type of feed or determine the appropriate type dynamically

While the feed format determines the properties of the feed returned to clients (RSS or Atom) the format of the return can be XML-based or JSON. Figure 23 illustrates two distinct WCF services – one returning XML, the other JSON. Windows clients are able to interact with RSS and Atom formats using the new syndication programming model available in .NET 3.5, and browsers typically have a mechanism built-in to present feeds to users. Web 2.0 clients usually prefer to work with JSON.

Figure 23: WCF services can return syndication feeds as XML or JSON

In fact, the same service can also return either XML or JSON formatted feeds – it isn't necessary to distinguish service endpoints to achieve this result.

Service Configuration

Designing a WCF service to support syndication feeds is similar to working with POX services but also requires developers to work with the syndication programming model that is part of .NET 3.5. Steps to create a WCF service supporting syndication are as follows:

• Define service operations that return the type of feed you want to support: RSS, Atom or either. The return type indicates the feed format and should be Rss20FeedFormatter, Atom20FeedFormatter, or SyndicationFeedFormatter – the latter of which supports returning either feed format.
• Use the WebGetAttribute to specify the URI that will call the service operation, as in POX services.
• In the service implementation, developers use the syndication programming model to return the appropriate feed content in the desired format. This code can also optionally format the result as JSON instead of using the default XML-based RSS or Atom format.
• Syndication feeds usually bypass traditional SOAP message filtering with WebHttpBinding and WebHttpBehavior as discussed in the section "POX and REST".

The primary difference in the developer experience is working with the syndication programming model to build the appropriate feed content.

Hosting Environment

The hosting environment for syndication services is the same as is described for POX and REST services in the section "POX and REST".

Security

Syndication feeds that are hosted using WebHttpBinding and WebHttpBehavior support the same security features as described in the section "POX and REST". If they are hosted as traditional SOAP and WS* services it is also possible to use the richer security features described in the various sections under "Scenario: Enterprise Web Services".

Client Programming Model

Windows clients can work with RSS and Atom feeds using the new syndication programming model introduced with .NET 3.5. This model greatly simplifies the development effort for any application working with syndication feeds. Browsers typically have built-in mechanisms for presenting RSS or Atom content, if users browse directly to the address of the feed. Web 2.0 clients working with syndication feeds programmatically may prefer to receive JSON formatted feeds to simplify their coding experience as discussed in the section "JSON".

Common Questions

Q. Can I mix POX, JSON and syndication in the same service contract?

Yes. Each operation can be individually configured to work with XML or JSON messaging format and each operation can have unique return types, thus the ability to support RSS or Atom as well. All operations in a single service contract must agree on how they will be hosted, however. That means they must all agree on the type of binding and behavior. For a mixed interface this would likely be WebHttpBinding and WebHttpBehavior.

Scenario: Intranet Services

WCF supersedes .NET Remoting and Enterprise Services as the preferred technology for distributing functionality across process and machine boundaries behind the firewall. With WCF, business functionality can be distributed as services and configured to support the appropriate protocols that satisfy performance, reliability and security requirements for the application. Intranet services live behind the firewall and do not rely on interoperable protocols for communication, thus WCF is used on both ends of the communication between clients and services. The following are common scenarios where intranet services may be employed:

• Classic client-server applications where Windows clients communicate with services within their domain.
• ASP.NET web applications that rely on services behind the firewall that expose business functionality to the application.
• Distribution of services across any process or machine boundary as part of a service-oriented system design.

The sections to follow will discuss these implementation scenarios for intranet services – describing the typical hosting environment, protocol support and relevant configuration settings.

Client-Server Applications

In a classic client-server application scenario, client applications typically access services that are hosted on remote server machines within the domain. A database server is usually part of the configuration, but is accessed by services – not directly by client applications. WCF makes it easy for developers to expose functionality to remote clients within an intranet.

Implementation Characteristics

For this scenario WCF services are likely to be called over TCP protocol using binary encoding to optimize communications – since interoperability is not a concern. Since the application is also likely to be part of a Windows domain, clients can pass Windows credentials for authentication and authorization to services. Figure 24 illustrates this scenario.

Figure 24: Classic client-server application architecture

To protect data during transfer, the communication channel between proxy and service handles encryption and signing, but this is only secure from point-to-point – as discussed with transport security in the section "Choosing SSL or Message Security".

WCF services for this scenario typically share the characteristics listed in Table 12.

Table 12: Characteristics common to intranet services

Characteristic	Description
Transport Protocols	TCP
Messaging Protocols	SOAP + Binary
Hosting	Windows NT Services on Windows Server 2003, Windows Activation Service (WAS) on Windows Server 2008
Authentication	Windows credentials authenticated against the Windows domain.
Authorization	Windows credentials authorized against the Windows domain.
Transfer Protection	Windows credentials are leveraged to generate keys to secure communications. X.509 certificates are not required.

Although communications are binary, developers work with the same programming model as they would for WCF services that rely on XML protocols.

Service Configuration

To configure WCF services as intranet services developers can leverage many of the default configuration settings of WCF as follows:

• Expose a service endpoint with NetTcpBinding which by default uses binary encoding, requires clients to provide Windows credentials, and protects data during transfer using encryption and signing.
• Use the default configuration for authentication and authorization behaviors which rely on the Windows domain.

Hosting Environment

WCF services that are part of a client-server deployment can be hosted in a Windows NT Service for Windows Server 2003 machines, or in WAS for Windows Server 2008 machines. Both of these hosting environments can host services over named pipes, TCP and MSMQ and Windows NT Services can also support HTTP protocol if IIS hosting is not desirable.

WAS hosting relies on a .svc file to map requests to the correct WCF service type (see Figure 25). WCF services hosted in a Windows NT Service, on the other hand, can be directly addressed (see Figure 26).

Figure 25: WCF services hosted in WAS can support named pipes, TCP and MSMQ

Figure 26: WCF services hosted in a Windows NT Service

WCF services hosted over TCP behind the firewall have similar hosting implications to those illustrated in Figure 27 for secure sessions and reliable sessions – clients must be directed back to the same server machine where the TCP socket was created. Software load balancers and network load balancing devices can be configured for sticky IP to address this.

Figure 27: The relationship between client and services when TCP sockets are used for communication

Common Questions

Q. Are there any drawbacks for hosting with Windows NT Services?

The execution model of WCF is robust and it is very unlikely that a service request, executing on its own thread, can cause any problems for the host process. If the host process is a Windows NT Service, it can be configured to start automatically when unattended server machines are rebooted, and they can also be configured to restart in the event of failure. For this reason, Windows NT Services are a very reliable choice for hosting WCF services.

The drawbacks to Windows NT Services compared to WAS are as follows:

• If the service configuration is updated, Windows NT Service hosts must be restarted to reflect those changes.
• While a Windows NT Service is being restarted, requests sent to its WCF services will be rejected. There isn't a queuing mechanism built-in like there is for WAS.
• Windows NT Services do not have support for pooling, health monitoring, recycling, or idle-time management to conserve resources.

Q. Is there any reason to use a Windows NT Service instead of WAS on Windows Server 2008?

For service-oriented applications hosted behind the firewall within an owned environment, WAS hosting is the best possible option for the benefits it provides. However, if the application is licensed and may be deployed to uncontrolled environments, it is sometimes easier to rely on Windows NT Services rather than mandating the installation of IIS 7 and WAS.

Q. When would I use named pipes instead of TCP?

Named pipes are intended for calls to WCF services either in-process or across process boundaries on the same machine. Named pipes are restricted to the same machine in the context of a WCF application. Thus, if the client application is on the same machine as the service, the following configuration could be used:

Expose a service endpoint with NetNamedPipeBinding which by default requires clients to provide Windows credentials, and uses an optimized binary encoding format.

Use the default configuration for authentication and authorization behaviors which rely on the Windows domain.

Q. Do I need to configure WCF services for transfer protection if they are on an IPSec or TLS network?

By default, NetNamedPipesBinding and NetTcpBinding will encrypt and sign messages between client and service. This is independent of any network configuration for IPSec or TLS, thus on secure networks such as these there will be packet protection during transfer in addition to WCF protection on the communication channel. It is always better to leave WCF protection enabled but it is possible to turn it off if there are no concerns about messages being transferred outside of the secure network.

Q. Is a domain always required for Windows authentication?

A WCF service that relies on Windows credentials will use the Kerberos domain if it is present, otherwise it will try to use NTLM to authenticate callers. It is also possible for client applications to require a domain, and disallow NTLM.

Q. Can client credentials be impersonated?

Impersonation can be enabled for WCF services.This should be done by requiring impersonation for each operation of the service, and by enabling impersonation behavior for the service in a simple configuration setting. With this configuration the service implementation will require a Windows credential – so the same service will not likely be useful in other scenarios. 

Q. Can client applications prevent impersonation and delegation?

Client applications can specify the level of impersonation they allow when they call service operations. This is a simple setting on the client proxy which defaults to allow only identification of the client credential – no impersonation or delegation will be allowed in this case. Clients can opt-in to allow either impersonation or delegation if they trust the environment.

Q. Are there features of Remoting that WCF does not support?

Remoting supports communication with distributed objects across application domain, process and machine boundaries without serialization – using object references (the feature is called "marshal by reference" as opposed to "marshal by value"). The advantage of this approach is reduced serialization overhead since the entire object state is not passed through serialization.

WCF was designed for SOA which relies on the contracts to define messaging requirements to support platform independence. This cannot be achieved with Remoting.

Calling Services from ASP.NET Web Applications

In a service-oriented application, ASP.NET web applications can leverage WCF services behind the firewall to access business functionality encapsulated by those services. Although it is possible for an ASP.NET application to call business assemblies directly, using WCF services provides the following benefits:

• Services provide necessary encapsulation for reusability of business logic across multiple potential client applications.
• Introducing a process boundary between ASP.NET pages and business logic can serve as a security boundary for the application, reducing the attack surface if malicious code were to gain access to the worker process.
• In many environments a DMZ is required which means that business logic is distributed to application servers behind a second firewall. WCF services make it possible for the ASP.NET client to reach that functionality.

Implementation Characteristics

In the scenario where an ASP.NET application calls services across process boundaries on the same machine, calls are likely to be made over named pipes, relying on Windows credentials to authenticate the calling process (the ASP.NET application). In this case, WCF services will likely share the characteristics listed in Table 13.

Table 13: ASP.NET application calling WCF services across a process boundary

Characteristic	Description
Transport Protocols	Named pipes
Messaging Protocols	SOAP + Binary
Hosting	Windows NT Services on Windows Server 2003, Windows Activation Service (WAS) on Windows Server 2008
Authentication	Windows credentials used to authentication the calling application.
Authorization	Windows credentials used to authorize the calling application.
Transfer Protection	Windows credentials are leveraged to generate keys to secure communications.

From the browser, users will authenticate to the ASP.NET application in order to access functionality. Page then in turn authenticate to services providing the Windows credential of the worker process to authenticate. This design assumes that services behind the firewall supporting the ASP.NET application do not require access to the user account to perform work. Figure 28 illustrates this architecture.

Figure 28: ASP.NET application authenticating to WCF services across a process boundary using named pipes

When a Demilitarized Zone (DMZ) is introduced into the architecture, the ASP.NET application must traverse another firewall to reach business functionality hosted on application servers. In this scenario the ASP.NET application calls WCF services across machine boundaries within the domain, calls will be made over TCP and rely on a client certificate to authenticate the calling application (the ASP.NET application). In this case, WCF services have characteristics as listed in Table 14.

Table 14: ASP.NET application calling WCF services across a machine boundary

Characteristic	Description
Transport Protocols	TCP
Messaging Protocols	SOAP + Binary
Hosting	Windows NT Services on Windows Server 2003, Windows Activation Service (WAS) on Windows Server 2008
Authentication	X.509 certificates used to authentication the calling application.
Authorization	X.509 certificates used to authorize the calling application.
Transfer Protection	An X.509 certificate provided for the service to protect (sign and encrypt) messages.

As in the previous configuration, users authenticate to the ASP.NET application first and pages then authenticate to services – this time providing a certificate credential. This design also assumes that services supporting the ASP.NET application do not require access to the user account. Figure 29 illustrates this architecture.

Figure 29: ASP.NET application authenticating to WCF services across a machine boundary using TCP

Service Configuration

To configure WCF services for named pipes communication as illustrated in Figure 28, developers can leverage configuration defaults as follows:

• Expose service endpoints with NetNamedPipeBinding which restricts calls to the same machine, requires Windows credentials to authenticate and authorize access, and relies on the Windows domain.
• Use default authentication and authorization behaviors which rely on the Windows domain.

To configure WCF services for TCP communication across machine boundaries as illustrated in Figure 29, developers should follow these configuration steps:

• Expose service endpoints with NetTcpBinding and change the configuration so that it requires certificate credentials.
• Install the client certificate in the Trusted People store of the application server machine to authorize access.
• Configure service behaviors to look in the Trusted People store to authenticate and authorize certificate access.

Common Questions

Q. Can Windows credentials be used to authenticate calls across machine boundaries?

ASP.NET applications hosted in IIS usually run with a low privilege Windows account such as NETWORKSERVICE. It is possible to authenticate calls from the ASP.NET host process to a WCF service using that credential, but using a certificate to authenticate calls is more granular to the calling application, as opposed to the process. Any code running within the ASP.NET worker process can authenticate with the Windows credential, only code that knows about the certificate can use it to call services. This reduces the attack surface.

Q. How do I pass user credentials from the ASP.NET application to WCF services?

Users typically authenticate to an ASP.NET application using a username and password that is authenticated and authorized against a custom credential store. WCF services may need information about the user in order to further authorize access to operations or to execute business rules. Although the ASP.NET application uses its own Windows account or a certificate to authenticate to WCF services in the described scenarios – additional information about the user, including their roles, can be passed in a few ways:

• A custom message header can be created to flow this information to the service. These headers should be signed to ensure they are not tampered with in transit.
• A security token, such as a SAML token, can be generated during the authenticate step in the ASP.NET application. This token is usually signed by a trusted certificate, and can be flowed to the service as part of the security headers. This is an advanced scenario.

Q. Should I create a new proxy for each service call?

ASP.NET applications may have many concurrent threads executing – each calling to a WCF service to reach business functionality. The natural model for this would be to create a new proxy for the page request, make one or more calls to the service as part of the request, and then destroy the proxy when the request is completed. The underlying functionality of a proxy is to create a channel factory based on the configuration requirements of the service, and then create a channel to call the service. Developers can optimize calls from ASP.NET applications by caching the channel factory – so long as the factory configuration is the same for all callers. Figure 30 illustrates two browser instances initiating two separate request threads – each using the same channel factory to create a channel to call services. The result is that each channel gets its own TCP socket.

Figure 30: Caching the channel factory to optimize performance

Caching the actual channel is not a good idea in this scenario because this will impact scalability – every call using that channel will then be issued to the same server over the same TCP socket. WCF supports connection pooling so that connections can be reused even when the channel is closed after each call.

Distributed Service Communications

One of the benefits of a service-oriented design is that it facilitates distribution of services according to scalability requirements for the application. The first tier of business services within a system are typically called by intranet client applications or ASP.NET applications. Another tier of WCF services may also exist to encapsulate shared functionality across business services, or to facilitate distribution of a specific set of functionality separate from the main web server and application server machines.

Implementation Characteristics

Figure 31 illustrates an architecture where a second tier processing service is distributed to a different set of physical servers – separate from the web server or application server. This is useful when the function performed by the second tier service relies on significant memory, IO or other server resources that may need to horizontally scale out to support load. For example, if the service were to generate documents, perform heavy calculations, or load large images into memory for processing.

Figure 31: Distributing second tier services to improve overall system scalability

Service Configuration

To implement the configuration shown in Figure 31, services hosted in the application server and processing server tiers would use the TCP configuration listed in Table 14 and shown in Figure 29. The assumption here is that all WCF services behind the firewall rely on TCP protocol with certificate authentication.

Common Questions

Q. What Windows identity should my services run under?

It is common to provide a different identity to each logically related group of services – granting that identity rights only to specific database tables and system resources.

Q. Can Windows credentials be used to authenticate calls?

As with ASP.NET applications calling first tier services, Windows credentials can also be used to authenticate calls to second tier services. The identity of the calling host process may vary based on the calling service. Using certificates to authenticate service-to-service calls is usually preferred.

Q. Should I pass user credentials from service-to-service?

The ASP.NET application, or first tier services are usually responsible for authorization semantics based on the application user that initiated the call. First tier services should ensure that the user is entitled to access business logic for the executing operation. Second tier services should be able to trust that they are only called from first tier services that have performed this authorization – thus should not require access to information about the application user. In special cases if this is required, the same recommendations discussed in the section "Calling Services from ASP.NET Web Applications" can be applied for this scenario.

Q. Should I create a new proxy for each service call?

As with ASP.NET applications, first tier WCF services may have many concurrent threads executing – each calling to a second tier WCF service. Calls can be optimized by caching the channel factory as discussed in the section "Calling Services from ASP.NET Web Applications".

Q. When should I use transactions?

Although it is rare to support transactions outside the firewall, distributed transaction capabilities can be a very important part of a service-oriented system. When two or more services must be coordinated as part of a single atomic operation, developers can enable transaction support for those services, and the service operations involved in the transaction. WCF transactions are supported over named pipes, TCP, MSMQ and HTTP – the latter of which is very useful to distribute a transaction through a firewall.

Q. Is message security relevant behind the firewall?

Message security is useful anywhere there is concern over guaranteeing that messages are secured through intermediaries, and anywhere that rich credential types are required that can't be passed with transport headers.

Scenario: Queued Messaging

Asynchronous, disconnected messaging patterns facilitate loosely coupled communications within a service-oriented application making it possible to execute long running processes without waiting on a response; to provide load leveling; and to guarantee message delivery even if services, equipment or networks are temporarily offline. Microsoft Message Queuing (MSMQ) is a messaging platform that supports these scenarios. WCF supersedes queued components supported by Enterprise Services, and in some scenarios removes the need to access raw functionality provided by System.Messaging.With WCF, clients can send messages to a queue and services can receive messages from a queue – using the same familiar programming model provided for other WCF clients and services. The key difference is that clients and services interact with a queue, instead of connecting directly to one another.  

The following are common scenarios where queued messaging may be employed:

• Guaranteed asynchronous message delivery
• Disconnected messaging
• Publish and subscribe scenarios

The following sections will discuss these implementation scenarios for queued messaging – describing the typical hosting environment, protocol support and relevant configuration settings.

Asynchronous Messaging

Calls from clients to services are typically synchronous – which means the client sends a request message and awaits a response message, which may or may not indicate an exception occurred when the service processed the message. WCF also supports asynchronous messaging through one-way operations. The challenge is in guaranteeing that the request message was received, and that it was successfully processed. By leveraging the plumbing provided by MSMQ, WCF services can provide delivery guarantees for asynchronous operations.

Implementation Characteristics

Guaranteed asynchronous message delivery is useful in many scenarios. It makes sense to offload any operation where the client does not depend on an immediate reply, but does want to guarantee that the operation executes. Any time functionality is offloaded to an asynchronous process it can improve overall application throughput. For example, Figure 32 illustrates an example where a service offloads logging and document generation activities to queued WCF services. In the case of logging, the operation may not be long running but it puts additional burden on the database – queues can control that flow without losing any entries. In the case of document generation, the process is memory and IO intensive and should be distributed to another server machine that can be horizontally scaled to handle load requirements. This makes it possible for any available server machine to process the next document generation request. In both cases these operations will not hold up sending a response to the client for the initial request – because they are asynchronous.

Figure 32: Leveraging queued services to improve throughput

Queued WCF services hosted as part of this type of asynchronous scenario typically share the characteristics listed in Table 15.

Table 15: Characteristics common to queued services.

Characteristic	Description
Transport Protocols	MSMQ (native, SRMP or SRMPS)
Messaging Protocols	SOAP + Binary
Hosting	Windows NT Services on Windows Server 2003, Windows Activation Service (WAS) on Windows Server 2008
Queue Authentication	X.509 certificates used to authentication the caller to the queue.
Queue Authorization	X.509 certificates used to authorize the caller to the queue.
Queue Transfer Protection	The caller's X.509 certificate signs messages sent to the queue. Encryption is usually handled at the message level.
Message Authentication	X.509 certificates used to authentication the original message sender.
Message Authorization	X.509 certificates used to authorize the original message sender.
Message Transfer Protection	The X.509 certificate for the service is used to protect messages placed in the queue.

There are two possible MSMQ platforms for this scenario:

• MSMQ 3.0 on Windows Server 2003
• MSMQ 4.0 on Windows Server 2008

Service Configuration

WCF makes it very easy for developers to write code that processes MSMQ messages. To configure a WCF service to listen on a message queue the following steps apply:

• The service contract must contain only one-way operations due to the nature of asynchronous calls.
• Expose a service endpoint with NetMsmqBinding providing an address for the queue and the following configurations:
  1. Set transport security to require certificate credentials and set the MSMQ authentication and authorization mode to match.
  2. Set message security to require certificate credentials.
  3. Provide a service certificate for message protection within the queue.
  4. Set properties of the binding to handle failed messages.

The message queue to support this should be created as a transactional queue in order to support delivery guarantees.

Hosting Environment

Queued WCF services are typically hosted in a Windows NT service on Windows Server 20003 machines and in the WAS on Windows Server 2008 machines. In either case client applications send messages directly to a queue, not to the WCF service – so the service can be temporarily offline and it has no impact on the client's ability to deliver that message.

The physical distribution of MSMQ storage and queued services plays an important role in the performance of an application. For server deployments like that shown in Figure 32, queues should be offloaded from the web server tier to a separate SAN drive to reduce IO contention on the web server. In addition, since logs and document generation messages are asynchronous, they can be processed whenever there are server resources available to do so. Hosting the services that listen on those queues on a separate physical tier from the web server support horizontal scaling of the system where additional document generation servers can be brought on line to handle load. Figure 33 illustrates this architecture.

Figure 33: Physical distribution of queues and queued services

Security

Queued messaging has two layers of security to configure:

• Transport Security: The message queue must authenticate and authorize callers placing messages in the queue, and this transfer should at least be signed to make sure that the message is not tampered with.
• Message Security: The service receiving the message from the queue must authenticate and authorize the original message sender as well.

The default settings for transport security default to Windows credentials and rely on the presence of a Windows domain (NTLM is not supported). If the system has a domain, this is an option – but certificates are usually preferred to verify the identity of the calling application.

The default setting for message security also expects a Windows credential. For the scenario shown in Figure 32 it makes more sense to use certificates to identify the calling application – since the client application user is not relevant to the logging or document generation services. If the user is relevant to the queued service it is possible to send any supported message credential. The service can use this credential to authenticate and authorize access to operations.

If encryption is important to the application, it is best to sign messages transported to the queue, and encrypt and sign the actual message within the queue. This way only trusted applications can pull the message from the queue and process it.

Common Questions

Q. Does the queue have to be transactional?

If a non-transactional queue is used, message delivery cannot be guaranteed. Non-transactional queues are useful in the case where message delivery requires best effort but need not be absolutely guaranteed. This also reduces overhead thus increases overall messaging throughput. An example where non-transactional queues can be best applied is for notification messages in a publish and subscribe scenario.

Q. What is the difference between MSMQ 3.0 and MSMQ 4.0?

One of the main features that MSMQ 4.0 provides to WCF services is greater control over how failed messages are handled – removing the need to work with System.Messaging. In addition, MSMQ 4.0 supports remote transactional receive which means that WCF services can process messages from a remote queue as part of a transaction, for distributed processing guarantees.

Q. Is there any overhead writing to the queue?

At a minimum it is usually best to store the queue on its own drive, separate from the drives belonging to the web or application server machines in a system. This reduces IO contention on the machines that handle the bulk of client requests.

Q. What happens if the server machine with the queue crashes?

If the queue is configured to be durable, messages are stored to disk and will survive server restarts. To survive hard-drive failure it is best to have the queue clustered and replicated. These are features supported by MSMQ.

Disconnected Messaging

Using WCF with MSMQ for asynchronous messaging improves system throughput and scalability. Another feature that MSMQ can provide, however, is disconnected messaging so that those asynchronous calls can be guaranteed even in the face of service, server machine, or network failure. This further increases system reliability since you can guarantee that you never lose a message using the appropriate WCF and MSMQ configurations. This can be useful in a few scenarios:

• End-user applications sending messages to queued services while they are offline.
• Any client application sending messages to queued services where an unexpected problem occurs.

Implementation Characteristics

When queues are located on remote machines, MSMQ clients can be configured so that messages are written directly to the remote queue, or first written to a local queue and then asynchronously forwarded to the remote queue. Figure 34 illustrates the former case which requires the remote queue to be online for messages to be written to the queue. In the latter case, messages are always written to a local queue first. This way, if the remote queue is not available, messages are stored locally as shown in Figure 35. When the remote queue comes back online the local queue will forward the message to the remote queue for processing as shown in Figure 36. In either case, assuming the WCF service is listening on that remote queue messages will begin to be processed.

Figure 34: Client applications writing directly to a remote queue

Figure 35: Client applications writing to a local queue when the remote queue is offline

Figure 36: A local queue writing to a remote queue when the latter is back online

Disconnected messaging is a feature of MSMQ and so other characteristics of this scenario related to service configuration, hosting and security are the same as discussed in the section "Asynchronous Messaging".

Common Questions

Q. Do client machines have to have MSMQ?

Yes, if client machines are communicating with queued WCF services they must have MSMQ installed to support disconnected messaging. MSMQ 3.0 is a feature of Windows XP, and MSMQ 4.0 is a feature of Windows Vista. Because these features must be installed it is more common to rely on queued messaging between client and server machines in controlled environments within the same domain.

This is usually not an issue for server-side scenarios since production machines are within a controlled environment.

Q. What happens when a message can't be delivered?

Every message has an expiry after which the message is moved to a special queue called the dead letter queue. This queue should be monitored for messages that expire. Expiry can be controlled by WCF configuration settings at the client.

Q. What happens when a message fails when processed by the WCF service?

So long as transactional queues are used, you can configure things so that you never lose a message. Messages will be moved to a retry queue and resent in intervals according to WCF configuration settings for the queue. After the retries have been exhausted, the message should be either returned to the queue in a faulted state, or moved to a dead letter or poison queue according to WCF configuration settings.

On MSMQ 3.0 the best option to avoid losing a message is to return messages back to the original queue in a faulted state – which means that no other messages in the queue will be processed until this poison message is removed using System.Messaging features. On MSMQ 4.0 the best option is to move the faulted message to a poison queue where another WCF service can easily listen and forward alerts to administrators.

Q. How can I retrieve messages from the dead letter or poison queue?

With MSMQ 3.0 the dead letter queue will possibly hold messages for many different types of WCF service contracts. The safest way to handle these messages is to use System.Messaging.

With MSMQ 4.0 a custom dead letter queue can be configured, and a custom poison queue is provided. This means that you can provide WCF services to safely handle messages from those queues and notify administrators.

Publish and Subscribe

There are two important implementation patterns available to developers with MSMQ and WCF. Queue subscription is the most common pattern – which means that one or more WCF services can listen on a queue and as they have resources free, process messages from that queue. In this pattern, each message is sent to only one service – the first available to process the request – which is great for distribution of work across a server farm. The second pattern is topic subscription – which supports durable, reliable publish and subscribe scenarios. In this case subscribing services indicate which messages they are interested in – the idea being that when a message is published to a queue, all subscribing services should receive that message, not just the first to pull it from the queue. MSMQ does not have built-in support for the latter scenario – which borders on Enterprise Service Bus (ESB) functionality – but it can be implemented easily, and in some cases is more appropriate than licensing a full-blown ESB to handle topic notifications.

It is possible to implement publish and subscribe scenarios without queued messaging, however this lacks the reliabilityand scalability of the queued implementation. The next sections will discuss both implementations to provide a comparison and the appropriate WCF configurations for each. 

Implementation Characteristics

WCF provides built-in support for asynchronous calls, callbacks and notifications. Asynchronous calls are merely one-way operations that return control to the client without waiting for the operation to execute. Callback contracts allow a service to publish a set of operations that a client can receive as notifications from the service. In some cases those notifications are simply callbacks to indicate an asynchronous operation has completed – but this can also be used to implement out-of-band notifications as in publish and subscribe.

Figure 37 and Figure 38 illustrate a simple subscription and publishing scenario using callback contracts. In Figure 37, clients subscribe to service notifications, each passing their own instance of a callback object which will later receive notifications. The address of the callback object is passed along to the service, and the service saves it in a list stored in memory within the application domain where the service is hosted.

Figure 37: Clients subscribing to a service

Figure 38 illustrates how a notification trigger can handle publishing to all subscribing clients. This process relies on the list of subscribers stored in the application domain.

Figure 38: Sending notifications to subscribing clients

Although the implementation is quite simple there are some drawbacks to this implementation. First, the subscriber list is volatile – its lifetime is tied to the host process thus it will not survive application domain recycling or server restarts. Second, the subscriber list is coupled to a particular server machine and process which means that the machine is coupled to a specific list of subscribing clients – this model will not scale. Using a queued publish and subscribe implementation lifts these limitations.

Implementing a durable publish and subscribe scenario is a design exercise that leverages existing capabilities of WCF and MSMQ to provide the necessary durability, reliability and scalability. Figure 39 and Figure 40 illustrate a possible architecture for publish and subscribe where a centralized PublishSubscribe service handles subscriptions from clients as well as notifications to clients from the Publisher service. Figure 39 illustrates the following features of the architecture:

Client applications provide a WCF service to receive notifications. The address of this service is provided during subscription.

The PublishSubscribe service stores client subscriptions and related service addresses in a database. Clients can subscribe to any PublishSubscribe service in the server farm since the database is shared.

Figure 39: Subscription using a decoupled architecture for publish and subscribe

Figure 40 illustrates the publishing process which has these characteristics:

• The Publisher service, based on an application trigger, sends notifications to a publishing queue.
• All instances of the PublishSubscribe service within the server farm listen on that queue. The first available service to process the notification handles notifications to all subscribers.

Figure 40: Queued notifications using a decoupled architecture for publish and subscribe

This architecture improves on the transient publish and subscribe architecture in the following ways:

• Clients provide a fixed service endpoint, not just a transient callback object tied to the lifetime of the proxy instance.
• The callback list is a list of durable service endpoints rather than a callback instance that can only stored in memory and cannot be saved in a central database.
• Notification messages are sent to a durable queue, and processed as part of a transaction, thus never lost. All clients will receive the notification insofar as the PublishSubscribe service ensures all client notifications are delivered to the queue as part of a transaction. This can be further guaranteed if the client Subscriber service also processes messages from the queue as part of a transaction.
• Any available PublishSubscribe service can handle notifications, thus improving the scalability of the application.

Service Configuration

To implement the transient publish and subscribe scenario with WCF, as illustrated in Figure 37 and Figure 38, developers can use the following configuration:

• The service contract is associated with a callback contract that describes possible notifications. The callback contract contains only one-way operations.
• The service configuration can use NetNamedPipeBinding, NetTcpBinding or WSDualHttpBinding to support callbacks – the latter of which is the only way to perform callbacks and notifications over HTTP.
• The client provides a callback type to handle notifications and associates this type with the client proxy. This special proxy creates an endpoint for services to send messages to clients – transparent to the developer.
• When the service receives calls from the client, it can store the callback instance within the application domain for later use.

To implement the queued publish and subscribe implementation, developers can use the following configuration:

• Client applications also host a service endpoint to receive notifications. Assuming the client is remote this endpoint can be configured with NetTcpBinding, WSHttpBinding or NetMsmqBinding – depending on the applications protocol requirements.
• When clients subscribe to the PublishSubscribe service, information about their service endpoint and the required protocols must be passed along to be saved to a database. This allows the PublishSubscribe service to create a proxy with the correct settings to call each client.
• Publishers need not be online when the client subscribes since they are decoupled from the PublishSubscribe service.
• Publishers send notifications to a transactional queue that the PublishSubscribe service listens on. Thus, notifications are guaranteed to be delivered to the PublishSubscribe service when the next one is available to process a message. WCF configuration for the queue should follow settings described in the section "Asynchronous Messaging".
• When processing notifications, the PublishSubscribe service traverses the list of subscriptions to ensure each client gets the notifications they requested.

Common Questions

Q. When are callbacks or notifications useful?

Callbacks are useful for notifying clients that an asynchronous call has completed – presumably a long running operation that was configured as one-way to allow clients to be released with the promise of this asynchronous notification. In this case coupling to the specific server that executed the operation is usually acceptable.

Out-of-band notifications implemented with callback contracts are only viable in scenarios where the publishing process does not need to scale to a large number of clients or notifications. In addition, there is an assumption that the client will have to re-subscribe if its communication channel with the service has been terminated.

Q. Is WSDualHttpBinding interoperable?

Although messaging is based on SOAP protocol this is not an interoperable binding. There are some WS* standards evolving for notification semantics but they are not yet implemented for any platform.

Q. What if the PublishSubscribe service is offline?

Figure 39 illustrates a scenario where the subscribing client does not rely on queued messaging to subscribe. The assumption here is that within the server farm one of the PublishSubscribe services will be available to handle subscription. This removes the need to have MSMQ configured at the client.

To allow client applications to subscribe even if the PublishSubscribe service is not available subscription can also be queued. This requires client machines to install MSMQ and so this is a more likely scenario when the environment is owned. In this case, the first available PublishSubscribe service will process subscriptions from the queue.

Q. What if a subscribing client is offline?

If delivery of notifications must be absolutely guaranteed to all subscribing clients, even in the face of network connectivity issues or client application restarts, there are two options:

• Each client could expose services that listen on a unique queue. This implementation does not scale well if there are a significant number of clients.
• The PublishSubscribe service can implement additional code to track which subscribers successfully received each notification (noting exceptions) and implement a custom retry mechanism for undelivered notifications.

In scenarios where the client is another service as opposed to an end-user application on a client machine, the first option is more desirable.

Q. How does this implementation compare to an ESB implementation?

A full-blown ESB has built-in functionality to handle queue subscription and topic subscription semantics. This implementation usually comes with a high price tag, and potentially more overhead given the required logic to handle durable subscriptions, topic subscription and messaging in an implementation-agnostic manner. An ESB is usually very appropriate for facilitating extensive messaging between many (sometimes heterogeneous) applications.

Q. Can MSMQ interoperate with other messaging systems?

There are bridge technologies available to map messages to and from MSMQ message format and other platforms such as JMS or MQSeries. This is where BizTalk Server or Host Integration Server can be helpful since they provide adapters for many platforms.

Scenario: Workflow Services

Within a service-oriented system there are usually many business services that encapsulate a specific set of functionality – making that functionality available either behind the firewall or on the Internet. This is excellent for reuse, maintenance, isolation, fault tolerance, distribution and scalability. WCF makes it easy to wrap business functionality behind a service boundary but does not make any assumptions about the order in which service operations will be called – coordination is up to the application. In .NET 3.0 Windows Workflow Foundation (WF) was introduced to provide a workflow and rules engine that could be hosted in any Windows application. Workflows provide visibility into a business process which makes it easier to align business requirements with the technical implementation. This is an ideal way to coordinate calls to WCF services as part of a long running business process.

In .NET 3.5 new features were introduced to provide better integration between WF and WCF. Specifically, workflows can easily make calls out to WCF services and workflows can be exposed as WCF services making it easier for remote client applications to send messages that interact directly with a workflow instance and associated service operations. In addition, .NET 3.5 WCF introduced durable services – so that the state of a service instance is automatically saved between calls. This makes it possible to rehydrate the same service instance on different machines and survive server restarts.

The following sections will discuss these implementation scenarios in greater detail.

Coordinating Service Calls from Workflow

Applications may use workflow for many reasons, one of which is to provide greater visibility into a long running business process that coordinates calls to business functionality relevant to the process. In a service-oriented system, that business functionality is likely to be exposed as services, which means that the ideal scenario is for workflows to coordinate calls to those services. Using the new features of .NET 3.5, WF can easily be used to design workflows that invoke WCF service operations at the appropriate execution points within a workflow. Using a workflow to describe the business process provides visibility not only into the process, but into the service operations the process depends on. This approach also makes it easier to reorganize the order of service calls, inject additional business rules around those calls, and simplify the necessary maintenance of the business logic associated with the long running process.

Implementation Characteristics

Figure 41 illustrates a workflow for processing data uploaded to a service.

Figure 41: A sequential workflow coordinating calls to WCF service operations

The workflow receives data and subsequently coordinates calls to save that data, generate a document from the data, send the document via email to some recipient list, and update the status of the process along the way for reporting purposes. Rather than coordinating each step in code, the workflow designer makes it easier to visualize the flow of calls to the various WCF services to complete the work. In either case, the flow of communication can be illustrated as shown in Figure 42.

Figure 42: Flow of communication for the document generation workflow

Adding new functionality to the business process, or shuffling order, is greatly simplified by workflow. For example, it would be easy to visualize where to add data scrubbing functionality to the workflow in Figure 41, resulting in a new workflow that calls the scrubbing service as shown in Figure 43.

Figure 43: Adding functionality to the document generation workflow to support data scrubbing

Workflow Designer Tools 

Visual Studio 2008 includes many tools to help developers design workflows including:

• Several templates for creating sequential or state machine workflows.
• A Workflow Designer which makes it easy to design, maintain and visualize workflows.
• A selection of workflow activities in the Toolbox. Developers drag and drop these activities directly into the design surface and then set properties and handle events to introduce workflow functionality.

Figure 44 illustrates the workflow designer and the selection of built-in workflow activities in the toolbox for WF 3.0 and WF 3.5.

Figure 44: Visual Studio 2008 and the Workflow Designer

Service Configuration

Workflows can coordinate calls to WCF services using any number of configurations. Services may be hosted on the same machine or remote, and they may be in-process or out-of-process.

Hosting Environment

Workflow can be hosted in any Windows application including the following:

• A Windows client application can leverage workflow to coordinate calls to remote WCF services hosted in IIS, WAS or in Windows NT Services.
• An ASP.NET application can start a workflow to coordinate calls to WCF services hosted in WAS or in Windows NT Services behind the firewall.

In either case, only a single instance of the workflow runtime is loaded into the application domain. When user interaction triggers a long running process, a workflow instance is created to handle the request asynchronously.

Common Questions

Q. Is there any overhead to adding workflow?

For each application domain there can only be a single workflow runtime loaded – thus there is a one-time hit for loading that runtime for the application domain. For each call that interacts with a workflow the overhead is in constructing or loading the workflow instance. For a Windows client application this overhead has little to no impact since the workflow will execute asynchronously on another thread. For ASP.NET applications each workflow will use a thread from the ASP.NET thread pool which means appropriate measures must be taken to allot enough threads, worker processes and machines at the web server tier – according to the specific application. Generally speaking, the overhead of workflow should be weighed against the benefits of visibility into the business process for accuracy, productivity and easier maintenance.

Q. How many workflows can execute concurrently?

By default workflows execute asynchronously on a worker thread taken from the .NET thread pool for the process. If the thread pool threads are all taken, subsequent requests will queue waiting a free thread pool thread. The thread pool is shared by all applications running within the process. It is important to be aware of the allocation of threads to the number of applications, services and workflows that may share those threads within a process.

Q. Can a workflow be executed synchronously?

The default workflow scheduler is responsible for executing a workflow instance on a thread from the .NET thread pool. A manual scheduler can be used to modify this behavior and execute the workflow synchronously if desired.

Q. Can WCF services start a workflow instance?

Yes, a WCF service can start a workflow instance however it may make more sense to expose the workflow as a WCF service. New features were released with .NET 3.5 to better facilitate this.

Exposing Workflow as a Service

Although a WCF service operation can initiate a workflow for a long running business process, this couples workflow initialization logic to the business service. In addition, numerous steps are required to initiate a workflow manually from a WCF service. As of .NET 3.5 a workflow can be directly exposed as a WCF service which means that the workflow is automatically initialized as part of a service call – without any cumbersome initialization code.

Implementation Characteristics

Figure 45 illustrates the same document generation workflow, this time exposed as a WCF service.

Figure 45: A sequential workflow exposed as a WCF service

In this case the UploadData activity is associated with a WCF service operation that initializes the workflow when called – no workflow initialization code is required. As shown in Figure 46 the flow of communications once the workflow is started is identical to that shown in Figure 42.

Figure 46: Flow of communication with a document generation workflow service

Designing a Workflow Service

A new ReceiveActivity was introduced with .NET 3.5 to streamline how workflows are initialized from calls to WCF service operations. In addition, this new activity makes it possible to define the WCF service contract for a workflow service as the workflow is designed. Using the Workflow Designer developers can create a workflow service using a number of techniques:

• Several templates are provided for creating for creating sequential or state machine workflow services. These templates create a WCF service contract associated with a workflow ReceiveActivity, and related service configuration settings.
• From the Workflow Designer developers can add new ReceiveActivity items and associate them with other service operations.
• New service contracts can be created while designing the workflow and associating ReceiveActivity with new operations, rather than defining the service contract up front.
• Existing service contracts can also be imported to associate with each ReceiveActivity.

Service Configuration

Workflow services are configured like any other WCF service. Typically the service configuration section provides an endpoint per service contract – which describes the address and binding configuration required to invoke the workflow service. Clients can generate a proxy like they would for any other service. As they call operations, the workflow is initialized by passing operation parameters to the workflow.

Workflow services can be hosted in any Windows process like any other WCF service, and support any number of protocol configurations.

Hosting Environment

Workflow services may be exposed directly to the Internet or live behind the firewall to support a service-oriented application design. Internet workflow services will likely be configured to support the scenarios discuss in earlier sections: "Enterprise Web Services" and "Web 2.0 Services". 

Workflow services behind the firewall may be called by an ASP.NET application or by a classic Windows client application. These services would follow configuration settings discussed earlier in the sections: "Intranet Services" and "Queued Messaging".

Common Questions

Q. Is there any reason to invoke workflows from a service operation without using workflow services?

Workflow services greatly simplify the developer experience for initializing workflow from a WCF service. Thus, this is the preferred path to reduce coding effort if the operation always kicks off a workflow. If a runtime decision must be made before deciding if a workflow should be initialized, or if the workflow is initialized by business components and not by the WCF service operation directly, then traditional workflow initialization means should be used.

Durable Services

Workflow provides persistence services which allow the state of a long running process to be stored in a database while the workflow is idle – waiting for input. This allows system resources associated with the workflow to be released and reloaded when clients interact with the workflow instance once again. Durable services are WCF services that leverage the persistence services of workflow so that services supporting sessions can automatically save state after an operation is called, and recapture that state when a new call arrives for the same session. This makes it possible for a session to survive server restarts, and be potentially distributed across a server farm.

Implementation Characteristics

When a WCF service supports sessions, clients are directed to the same service instance which means that the in-memory state of the service is available across multiple calls. Figure 47 illustrates this.

Figure 47: WCF services supporting sessions

As the diagram suggests, this design requires that clients are always interacting with a specific server machine where their particular service instance is hosted. Furthermore, the lifetime of the service instance lasts only as long as the client proxy is kept alive, as long as the transport session has not timed out, as long as the application domain is not recycled, and as long as the communication channel is not faulted. Durable services help to overcome this limitation by saving the service state with workflow services between calls, as shown in Figure 48.

Figure 48: WCF services supporting durable session state

In this case, the client application can create a new proxy in response to a session timeout, an application domain recycling event, or communication fault and still access the service instance from its last state. In addition, the new proxy could be redirected to a different machine in the server farm.

Persistence Services

Durable services are supported by workflow persistence services. To enable persistence, developers must follow these steps:

• A SQL script is provided to install the required tables and stored procedures used to store state for workflows and durable services. This script can be executed on any standard database platform, but the default persistence provider is a SQL Server provider.
• Provide a connection string for the persistence provider.
• If necessary, create a custom persistence provider for an alternate database store and configure the new provider instead of the default SQL Server provider.

Explicit code is not required to interact with the provider. Workflow services and durable services will automatically leverage the configured provider if persistence is enabled.

Service Configuration

WCF clients and services require a few specific steps to enable durability, including:

• Service instancing must be based on sessions. This is the default behavior for InstanceContextMode.
• The service must enable durability. This is achieved by applying the DurableServiceAttribute to the service type, and by applying the DurableOperationAttribute to each operation that should trigger persistence services to save state after each call.
• Services must expose endpoints that support durability. The new context-aware bindings in .NET 3.5 can be used including: BasicHttpContextBinding, WSHttpContextBinding, and NetTcpContextBinding. By selecting one of these bindings, information can flow between client and service that properly indicates the durable service instance to be retrieved from the database.
• Client applications should save context information so that they can create a new proxy if necessary and still reach the same durable service instance.

Hosting Environment

Durable services may be exposed directly to the Internet or live behind the firewall in any scenario where services support sessions. This also means that the hosting environment is completely flexible: IIS, WAS, Windows NT Services or any other Windows applications.

Clients should save contextual information for the durable session and pass that to a new proxy to reconnect to the same service instance. By saving the context, the service instance can still be reached even if a new proxy must be generated to recreate the communication channel for any reason.

Common Questions

Q. Are sessions recommended?

Generally speaking sessions are not recommended for services deployed in high throughput environments. This is due to the overhead in constructing a session, and the potential overhead with memory usage by service instances that hold references to significant state information.

Q. Are durable services better than writing custom code to handle state management?

Durable services simplify the effort necessary to manage service instance state, assuming state is necessary. In most cases, services are designed so that each operation manages its own state by interacting with application-specific data stores. This model yields more flexibility in how state is stored, while the durable service approach will use generic tables for state storage.

Q. Why would the application domain be recycled?

When services are hosted in IIS or WAS, the application domain in which the service is hosted may be periodically recycled to reflect new configuration settings, to release server resources, or in response to health monitoring indicators. As such, it isn't possible to guarantee any in-memory state for a service or workflow. Durability between calls ensures that no state information is lost.

Q. Can transport sessions be distributed across a server farm along with the service application session?

In the presence of a transport session, a client proxy must send requests to the same server machine in order to reach the same session. This includes: TCP sockets, reliable sessions and secure sessions. Thus, if the same proxy is used to call a durable service, it still requires server affinity despite the fact that the service instance has been persisted.

The benefit of durable services is that if the client creates a new proxy, the new proxy can still reach the same service instance based on its last state. In that case, a new TCP socket, reliable session or secure session (according to the service configuration) will be created, but it can be create on a different server and still successfully construct the correct service instance.

Q. What if multiple threads try to access the same service state?

The persistence provider can be configured to lock the service state when a particular thread or machine has accessed that state to execute a request. This prevents another thread from accessing the same service state to execute a different request.

Reference:

http://msdn.microsoft.com/en-us/library/cc512374.aspx