Windows Communication Foundation

From Wikipedia, the free encyclopedia

Jump to: navigation, search
This subsystem is a part of .NET Framework

Windows Communication Foundation, or just WCF, is a programming framework used to build applications that inter-communicate. WCF is the part of the .NET Framework dedicated to communications.

Originally tagged with the code name "Indigo", WCF is one of the four new application programming interfaces introduced with .NET Framework 3.0, which was released in December 2006. The .NET Framework is Microsoft technology that ships in Windows operating systems (client, server and mobile platforms). The .NET Framework v3.0 is included in Windows Vista and Windows Server 2008; It is available as a free download for Windows XP and Windows Server 2003, and a similar but separate version is also available for .NET Compact Framework version 3.5.

Because WCF is part of the .NET Framework, applications that use WCF can be developed in any programming language that can target the .NET runtime.

Contents

[edit] Overview

The WCF unifies the various communications programming models supported in .NET 2.0, into a single model. Released in November 2005, .NET 2.0 provided separate APIs for SOAP-based communications for maximum interoperabilllity (Web Services), binary-optimized communications between applications running on Windows machines (.NET Remoting), transactional communications (Distributed Transactions), and asynchronous communications (Message Queues). WCF unifies the capabilities from these mechanisms into a single, common, general service-oriented programming model for communications.

WCF can use SOAP messages between two processes, thereby making WCF-based applications interoperable with any other process that communicates via SOAP messages. When a WCF process communicates with a non–WCF process, XML-based encoding is used for the SOAP messages but when it communicates with another WCF process, the SOAP messages can be encoded in an optimized binary format. Both encodings conform to the data structure of the SOAP format, called Infoset.

WCF uses a pluggable encoding system, allowing developers to write their own encoders[1]. With the release of the .NET Framework 3.5 in November 2007, Microsoft released an encoder that added support for the JSON serialization format to WCF[2]. This allows WCF service endpoints to service requests from AJAX-powered web pages.

[edit] Service oriented architecture

WCF is designed in accordance with Service oriented architecture principles to support Distributed computing where services are consumed by consumers. Clients can consume multiple services and services can be consumed by multiple clients. Services typically have a WSDL interface which any WCF client can use to consume the service, irrespective of which platform the service is hosted on. WCF implements many advanced web services (WS) standards such as WS-Addressing, WS-ReliableMessaging and WS-Security. While Microsoft is a board member of WS-I it is not clear how many WS-I profiles they are committing to support completely.

[edit] WCF Service

A WCF Service is composed of three parts — a Service class that implements the service to be provided, a host environment to host the service, and one or more endpoints to which clients will connect. All communications with the WCF service will happen via the endpoints. The endpoints specify a Contract that defines which methods of the Service class will be accessible via the endpoint; each endpoint may expose a different set of methods. The endpoints also define a binding that specifies how a client will communicate with the service and the address where the endpoint is hosted.

WCF provides Windows Activation Services which can be used to host the WCF service. Otherwise the WCF service can also be hosted in IIS or in any process by using the ServiceHost class, which is provided by WCF. Services can also be self-hosted, in a console-based application or a Windows-forms application for example.

[edit] Defining WCF services

In programming code, a WCF Service is implemented as a class. The class typically implements a Service Contract - a specially annotated interface whose methods stipulate the operations that the service performs. Typically, the methods on the interface accept inputs and output messages, which conform to Data Contracts, described with specially annotated classes. Think of these as Data Transfer Objects.

The Data and Service Contracts are defined using annotations in programming code, known formally in .NET as Attributes. Any class that is to be exposed as a WCF service must be either marked with the ServiceContract attribute, or implement an interface marked with it. All methods in the class or interface that a client can invoke using SOAP messages must be marked with OperationContract attribute. All classes or structures that define the data to be passed into or out of the operations are marked with the DataContract attribute. The attributes support the automatic generation of WSDL descriptions for the exposed methods, which can then be accessed by clients, or advertised to them.

A service can expose multiple Service Contracts. This can be done by defining multiple .NET interfaces, each marked as a Service Contract. The service class can then implement all the interfaces.

The ServiceContract and OperationContract attributes also allow an interface to reference a previously existing contract, thus providing an option for supporting interface versioning.

All Service Contracts have an associated implicit or explicit Data Contract which defines the data that the service works on. If the parameters accepted and returned by the service methods consist of primitive types (integer, double, boolean, etc), then the Data Contract is defined implicitly by WCF. If, on the other hand, the data is of a complex type like an object or a struct, then it must be defined explicitly by the programmer via attributes. Data contracts specify how the data is serialized and de-serialized, allowing for custom representation of objects passing in and out.

A Data contract is defined by using a DataContract attribute on a class or structure. Members of the data structure which will be used by the service need to be marked with the DataMember attribute. Only those members will be transferred between the service and its client. In the same way that different classes can implement the same interface, different classes can implement the same Data Contract, and can serialize and de-serialize the same data. Taking the idea further, a .NET class defined in C# or VB can implement a Data Contract, and serialize to a data packet, that can then be de-serialized by a Java class or a PHP class.

The behavior of the Service in general and the operations in particular can be controlled using the ServiceBehavior and the OperationBehavior attributes respectively. The ServiceBehavior attribute has different properties. The ConcurrencyMode property specifies whether the service will be concurrent, i.e., whether it will support simultaneous clients or not. Similarly, the InstanceMode property specifies whether a single instance of the service will serve all requests or a new instance of the service will be created for each request, or a new instance of the service will be created for each session.

[edit] Defining Endpoints

A WCF client connects to a WCF service via an endpoint.

Each Service exposes its Contract via one or more endpoints. An endpoint has an address, which is a URL specifying where the endpoint can be accessed, and binding properties that specify how the data will be transferred.

The mnemonic "ABC" can be used to remember Address / Binding / Contract. Binding specifies what communication protocols are used to access the service, whether security mechanisms are to be used, and the like. WCF includes predefined bindings for most common communication protocols such as SOAP over HTTP, SOAP over TCP, and SOAP over Message Queues etc.

When a client wants to access the service via an endpoint, it not only needs to know the Contract, but it also has to adhere to the binding specified by the endpoint. Thus, both client and server must have compatible endpoints.

[edit] Communication with the service

A client can communicate with a WCF service using any of the RPC-based mechanisms in which the service can be invoked as a method call. Using synchronous communications, any call to the service will be blocking - that is, it will halt the execution of the client until the service processes the request. The client has to connect to a service using a proxy object, which is connected to the specified endpoint of the service and abstracts the service as an object. All method calls to the proxy object will be routed to the service and the proxy will return the results returned by the service to the caller.

Tools shipped with the .NET Framework SDK can consume WSDL and create client-side proxy classes for use with WCF. Such classes handle the serialization and data transmission to and from the service, as well as faults and exceptions.

WCF also supports non-blocking (asynchronous) calls between client and service, via several mechanisms. One option is to use Message Queues as the transport for the delivery and receipt of the messages. (Keep in mind that the use of Message Queues does not imply a change to a Put/Get style programming model. Even with the use of persistent queues, the programming model still uses friendly proxy classes.) A second mechanism for supporting asynchronous communications is via multiple threads - there is a simple mechanism to do this in the generated client-side proxies for WCF. (see Calling WCF Services asynchronously)

In addition to the higher-level programming model supported by the tool-generated proxy classes, WCF exposes a lower-level programming model where applications manually construct and pass messages to services. Communicating using messages does not require the use of the proxy object, and provides more control, although lower usability, to the programmer.

[edit] REST Support in WCF

In the .NET Framework 3.5, WCF added support for REST-style communications. Developers can specify URL Templates on Operation Contracts, to allow methods to be invoked when requests on specific URLs are received. Parameters from the URLs can be automatically extracted and passed to the method. JSON and plain-old-XML data serialization is supported, as well as alternative mechanisms for binary return types (such as JPG).

[edit] Adoption

Microsoft partners are supporting WCF. SAP delivers add-ins to the Visual Studio tool that can generate WCF client-side proxies that connect to SAP Enterprise systems. IBM is producing a WCF Channel for MQ. Microsoft has also delivered The WCF Line of Business Adapter SDK to enable developers to create WCF-based communication connectivity to virtually any external system. The WCF LOB Adapter SDK is what enables JNBridge, for example, to build the JMS Adapter for .NET.

[edit] References

[edit] See also

[edit] Additional Resources about WCF

  • Craig McMurtry, Marc Mercuri, and Nigel Watling: Microsoft Windows Communication Foundation: Hands-On, SAMS Publishing, May 26 2006, ISBN 0-672-32877-1
  • Steve Resnick, Richard Crane, Chris Bowen: Essential Windows Communication Foundation (WCF): For .NET Framework 3.5, Addison-Wesley, February 11 2008, ISBN 0-321-44006-4
  • Craig McMurtry, Marc Mercuri, Nigel Watling, Matt Winkler: Windows Communication Foundation Unleashed (WCF), Sams Publishing, March 6 2007, ISBN 0-672-32948-4
  • Juval Löwy: Programming WCF Services, O'Reilly Media, Inc., February 20, 2007, ISBN 0-596-526997

[edit] External links

Personal tools