Michele Leroux Bustamante, IDesign

May 2008

Windows Communication Foundation (WCF) is Microsoft's platform for SOA. It is a rich technology foundation designed for building distributed service-oriented applications for the enterprise and the web that are secure, reliable, transactional and scalable.

WCF Releases and Platform Support

.NET 3.0 was released to manufacturing in November 2006 and officially launched with Windows Vista in January 2007 – introducing WCF along with Windows Workflow Foundation (WF) and Windows Presentation Foundation (WPF). This marked the release of Microsoft's first class web services platform simplifying the design, implementation and deployment of services with essential plumbing for scalability, performance, security, reliable message delivery, transactions, multithreading, asynchronous messaging and more.

With .NET 3.5 – launched with Visual Studio 2008 in November 2007 – additional WCF features were introduced including:

• Built-in support for web programming models such as Plain Old XML (POX), Representational State Transfer (REST), JavaScript Object Notation (JSON) and syndication feeds such as Really Simple Syndication (RSS) and ATOM.
• Support for the latest web service standards
• Better integration with ASP.NET AJAX clients
• Support for some partial trust environments. For example, hosting environments that run ASP.NET with reduced trust can host WCF services, and clients running with reduced trust – such as JavaScript within a browser or ClickOnce applications – can use WCF proxies.
• Support durable, long running services
• Seamless integration between WCF and WF allowing for services to be written as workflows and workflows to invoke services
• Productivity tools directly integrated with Visual Studio 2008

WCF applications can be deployed to the following platforms: Windows XP (SP2 or higher), Windows Vista, Windows Server 2003, and Windows Server 2008.

A Platform for SOA

Service Oriented Architecture (SOA) is the evolution of component-oriented programming making it possible to encapsulate, reuse and distribute business functionality with the added benefit of interoperability across technology platforms. Adopting a service-oriented approach to system design provides a cleaner separation between business logic and the protocols over which that business logic is reached – making systems more flexible, optimized for the deployment scenario, and more easily maintainable. Services provide natural boundaries for security and for distribution and scale-out. Exposing functionality via interoperable services can also open new marketing channels as the system gains a wider reach.

WCF was built with SOA in mind:

• Service design and implementation are naturally decoupled from application business logic, making it easy to migrate existing applications to a service-oriented design without rewriting existing components
• Services expose functionality to remote clients through explicit contracts using an opt-in approach
• Services execute autonomously with no impact to one another in the event of failure
• Services can be deployed over different protocols to satisfy a variety of distributed computing scenarios
• Services support interoperability with major vendors
• Services are transport agnostic – they can be exposed directly on the web, in an intranet, or used in the backend of the enterprise

Unified Programming Model

WCF is the evolution of Enterprise Services/COM+, .NET Remoting, System.Messaging, ASP.NET Web Services (ASMX) and Web Services Enhancements (WSE) – all technologies that in that past were employed to satisfy very different distributed computing scenarios. WCF satisfies all of these scenarios including interoperable web services; Web 2.0 programming models such as POX, REST, JSON and RSS/ATOM; classic client-server scenarios; calls across process and machine boundaries behind the firewall; and durable, reliable queued messaging on top of Microsoft Message Queuing (MSMQ).

A single, unified programming model supports each of these scenarios thus the developer experience is consistent for service design, configuration and deployment. Prior to WCF developers had to learn a different technology and object model to support different distributed computing needs – with WCF they can apply their knowledge of a single platform to satisfy all scenarios. This makes it easy to employ appropriate protocols at each tier to optimize communications in any system. In addition, this is a huge productivity boost for development and maintenance.A service may be designed and implemented once and then exposed in a number of different scenarios. 

Flexible Hosting Model

Services can be hosted in any managed Windows process including Internet Information Services (IIS), Windows Activation Service (WAS), Windows NT Services, and Windows Forms or WPF client applications. Developers can choose the hosting environment appropriate for the application scenario, and where possible take advantage of the built-in hosting features provided by IIS and WAS, including:

• Management: Operations can leverage built-in configuration options available to IIS for application pooling, health monitoring of worker processes, recycling to maintain health, and idle-time management to release system resources when they are not being used.
• Message-based activation: Requests sent to WCF services are queued as needed (not rejected) while IIS loads up an appropriate process to handle the request.

Developer Productivity

There are many aspects of WCF that facilitate developer productivity for building distributed, service-oriented systems, including: 

• Visual Studio 2008 includes a suite of templates and tools for generating WCF projects and services, and for configuring the runtime environment for service deployment.
• WCF provides essential plumbing for building a service-oriented system which means that developers can focus on the business problem at hand instead of writing code related to system features such as security, reliable delivery, transactions, multithreading, and messaging queuing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ca