Day 1

Introducing Windows Communication Foundation in .NET Framework 4

http://msdn.microsoft.com/en-us/library/ee958158(v=MSDN.10).aspx

service-oriented style

WCF’s most important aspects:

• Unification of the original .NET Framework communication technologies
• Interoperability with applications built on other technologies
• Explicit support for service-oriented development.

Unification of the original .NET Framework communication technologies

older .NET technologies:

• ASMX, also called ASP.NET Web Services, would be an option for communicating with the Java EE-based reservation application and with the partner applications across the Internet. Given that Web services are widely supported today, this would likely be the most direct way to achieve cross-vendor interoperability.

ASMX is:

• • easy and simple to write and configure
  • only available in IIS
  • only callable from HTTP

WCF can be:

• • hosted in IIS, a Windows Service, a Winforms application, a console app - you have total freedom
  • used with HTTP (REST and SOAP), TCP/IP, MSMQ and many more protocols

• .NET Remoting is a natural choice for communication with the call center application, since both are built on the .NET Framework.Remoting is designed expressly for .NET-to-.NET communication, so it would offer the best performance for this situation.
• Enterprise Services might be used by the rental car reservation application for things such asmanaging object lifetimes and defining distributed transactions. These functions could be useful in communicating with any of the other applications in this scenario, but Enterprise Services supports only a limited set of communication protocols.
• Web Services Enhancements (WSE) might be used along with ASMX to communicate with the Java EE-based reservation application and with the partner applications. Because it implements more advanced SOAP-based standards, known collectively as the WS-* specifications,WSE can allow better security and more, as long as all applications involved support compatible versions of these specifications.
• System.Messaging, which provides a programming interface to Microsoft Message Queuing (MSMQ),could be used to communicate with Windows-based partner applications that weren’t always available. The persistent queuing that MSMQ provides is typically the best solution for intermittently connected applications.
• System.Net might be used to communicate with partner applications or perhaps in other ways. Using this approach, developers can create applications that use the HTTP-based communication style known as Representational State Transfer (REST).

Here’s how WCF addresses each of these requirements:

• Because WCF can communicate using SOAP-based Web services, interoperability with other platforms that also support SOAP, such as Java EE application servers, is straightforward.
• To allow optimal performance when both parties in a communication are built on WCF, the wire encoding used in this case is an optimized binary version of SOAP. Messages still conform to the data structure of a SOAP message, referred to as its Infoset, but their encoding uses a binary representation of that Infoset rather than the standard angle-brackets-and-text format of XML. Using this option would make sense for communicating with the call center client application, since it’s also built on WCF, and performance is a paramount concern.
• Managing object lifetimes, defining distributed transactions, and other aspects of Enterprise Services are also provided by WCF. They are available to any WCF-based application, which means that the rental car reservation application can potentially use them with the other applications with which it communicates.
• Because it supports a large set of the WS-* specifications, WCF helps provide reliability, security, and transactions when communicating with any platform that also supports these specifications.
• WCF’s option for queued messaging, built on MSMQ, allows applications to use persistent queuing without needing to use another application programming interface.
• WCF has built-in support for creating RESTful clients and services.

WCF implements a range of Web services standards

WCF supports all the specifications shown in this figure. Grouped by function, those specs are:

• Messaging: SOAP is the foundation protocol for Web services, defining a basic envelope containing a header and a body. WS-Addressing defines additions to the SOAP header for addressing SOAP messages, which frees SOAP from relying on the underlying transport protocol, such as HTTP, to carry addressing information. The Message Transmission Optimization Mechanism (MTOM) defines an optimized transmission format for SOAP messages based on the XML-binary Optimized Packaging (XOP) specification.
• Metadata: The Web Services Description Language (WSDL) defines a standard language for specifying services and various aspects of how those services can be used. WS-Policy allows specification of more dynamic aspects of a service’s behavior that cannot be expressed in WSDL, such as a preferred security option. WS-MetadataExchange allows a client to request descriptive information about a service, such as its WSDL and its policies, via SOAP. Beginning with the .NET Framework 4 release, WCF also supports WS-Discovery. This broadcast-based protocol lets an application find services available elsewhere on its local network.
• Security: WS-Security, WS-Trust and WS-SecureConversation all define additions to SOAP messages for providing authentication, data integrity, data privacy and other security features.
• Reliability: WS-ReliableMessaging defines additions to the SOAP header that allow reliable end-to-end communication, even when one or more SOAP intermediaries must be traversed.
• Transactions: Built on WS-Coordination, WS-AtomicTransaction allows using two-phase commit transactions with SOAP-based exchanges.

The rental car reservation application would likely use several of these more advanced technologies. For example, WS-Addressing is essential whenever SOAP is running over a protocol other than HTTP, which might be the case for communication with the .NET Framework-based call center client application. WCF relies on WS-Policy and WS-MetadataExchange to discover whether the system it’s communicating with is also using WCF and for other things. Reliable communication is essential for most situations, so it’s likely that WS-ReliableMessaging would be used to interact with many of the other applications in this scenario. Similarly, WS-Security and the related specifications might also be used for communication with one or more of the applications, since all would require some kind of security. For the applications that are allowed to use transactions with the rental car reservation system, WS-AtomicTransaction would be essential. Finally, MTOM could be used whenever an optimized wire format made sense, and both sides of the communication supported this option.

Creating a WCF Service

Implementing a Service Class

Defining Service Contracts

Defining Data Contracts

Selecting a Host

Hosting a Service Using IIS or WAS

Hosting a Service in an Arbitrary Process

Defining Endpoints

• An address indicating where this endpoint can be found. Addresses are URLs that identify a machine and a particular endpoint on that machine.
• A binding determining how this endpoint can be accessed. The binding determines what protocol combination can be used to access this endpoint along with other things, such as whether the communication is reliable and what security mechanisms can be used.
• A contract name indicating which service contract this WCF service class exposes via this endpoint. A class marked with ServiceContract that implements no explicit interfaces, such as RentalReservations in the first example shown earlier, can expose only one service contract. In this case, all its endpoints will expose the same contract. If a class explicitly implements two or more interfaces marked with ServiceContract, however, different endpoints can expose different contracts, each defined by a different interface.

Predefined Bindings:

• BasicHttpBinding: Conforms to the Web Services Interoperability Organization (WS-I) Basic Profiles 1.2 and 2.0, which specify SOAP over HTTP. This binding also supports other options, such as using HTTPS as specified by the WS-I Basic Security Profile 1.1 and optimizing data transmission using MTOM.
• WsHttpBinding: Uses SOAP over HTTP, like BasicProfileBinding, but also supports reliable message transfer with WS-ReliableMessaging, security with WS-Security, and transactions with WS-AtomicTransaction. This binding allows interoperability with other Web services implementations that also support these specifications.
• NetTcpBinding: Sends binary-encoded SOAP, including support for reliable message transfer, security, and transactions, directly over TCP. This binding can be used only for WCF-to-WCF communication.
• WebHttpBinding: Sends information directly over HTTP or HTTPS—no SOAP envelope is created. This binding first appeared in the .NET Framework 3.5 version of WCF, and it’s the right choice for RESTful communication and other situations where SOAP isn’t required. The binding offers three options for representing content: text-based XML, JavaScript Object Notation (JSON), and opaque binary encoding.
• NetNamedPipesBinding: Sends binary-encoded SOAP over named pipes. This binding is only usable for WCF-to-WCF communication between processes on the same machine.
• NetMsmqBinding: Sends binary-encoded SOAP over MSMQ, as described later in this paper. This binding can only be used for WCF-to-WCF communication.

Specifying Endpoints

Using Endpoints: An Example

To get a more concrete sense of how endpoints can be used, think once more about the rental car reservation application. To meet the diverse communication requirements of its clients, this application, implemented in the RentalReservations service class, will probably choose to expose several endpoints, each with a different binding:

• • For communication with the call center client application, high performance and full functionality including strong security and transactions are required.Since both the RentalReservations class and the call center client are built on WCF, a good binding option for the endpoint this client accesses would beNetTcpBinding. It’s the most efficient choice, and it also provides a full set of communication behaviors, including reliable transfer, strong security, and transactions.
  • For communication with the Java EE-based reservation application, a binding that uses standard SOAP on the wire is required. If the application and the platform it runs on support some or all of the WS-* specifications, the endpoint used by this client might choose WsHttpBinding. This would allow reliable, secure, and transactional communication between the two applications. If this application and the platform it runs on support only standard SOAP matching the WS-I Basic Profile, however, the endpoint it uses to access the rental car reservation application would use BasicHttpBinding. If transport security is required, this binding could be configured to use HTTPS instead of plain HTTP.
  • For communication with the various partner applications, different endpoints might be used depending on the binding requirements. For example, the a simple Web services client could access an endpoint that used BasicHttpBinding, while one that also supported transport security might use this same binding configured to use HTTPS. A partner application that was capable of using the WS-* technologies could instead use an endpoint with WsHttpBinding. It’s worth pointing out, however, that even a partner application built on WCF would find the NetTcpBinding problematic to use across the Internet. Communication with this binding uses a port other than port 80, so traffic using it cannot easily get through most firewalls.

Creating a WCF Client

Because it unifies different approaches to communication, WCF can simplify the creation of distributed applications on Windows. Because it implements SOAP and the most important WS-* specifications, along with RESTful communication, WCF provides broad interoperability with other platforms. And because it offers explicit support for a service-oriented approach, WCF gives developers a natural environment for building modern software.

Service-oriented applications are becoming the norm, and WCF is now a mainstream technology for Windows. For anyone who creates software in this world, this shift qualifies as a significant step forward.