Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

WCF Essentials—A Developer's Primer

WCF is an SDK for building service-oriented applications on Windows, letting you use classic CLR programming constructs, such as classes and interfaces, to deploy and consume services. The programming model is declarative and largely attribute-driven.


advertisement
indows Communication Foundation (WCF) provides a runtime environment for your services, enabling you to expose CLR types as services and to consume services as CLR types.

Although in theory you can build services without it, in practice, WCF significantly simplifies this task. WCF is Microsoft's implementation of a set of industry standards defining service interactions, type conversion, marshaling, and various protocols' management. Because of that, WCF provides interoperability between services, and it promotes productivity, including the essential off-the-shelf plumbing required by almost any application. This article describes the essential concepts and building blocks of WCF and its architecture, enabling you to build simple services. Future articles in this series will address specific aspects, such as transaction management and security.

What Are WCF Services?
A service is a unit of functionality exposed to the world. In that respect, it is the next evolutionary step in the long journey from functions to objects to components to services. Service-orientation (SO) is an abstract set of principles and best practices for building SO applications, which are largely beyond the scope of this article.

WCF provides a runtime environment for your services, enabling you to expose CLR types as services and to consume services as CLR types.
A service-oriented application (SOA) aggregates services into a single logical application (see Figure 1), similar to the way a component-oriented application aggregates components or an object-oriented application aggregates objects. The services can be local or remote, developed by multiple parties using any technology, they can be versioned independently, and even executed on different timelines. Inside a service, you will find concepts such as languages, technologies, platforms, versions, and frameworks, yet between services, only prescribed communication patterns are allowed.

 
Figure 1: Service-oriented Application: The figure shows s a sketch of a service-oriented application.
Clients and services interact by sending and receiving messages. Messages may transfer directly from client to service or via an intermediary. With WCF, all messages are SOAP messages. Note that the messages are independent of transport protocols—unlike Web services, WCF services may communicate over a variety of transports, not just HTTP.

With WCF, the client never interacts with the service directly, even when dealing with a local, in-memory service. Instead, the client always uses a proxy to forward the call to the service. WCF allows the client to communicate with the service across all execution boundaries. On the same computer (see Figure 2), the client can consume services in the same application domain, across application domains in the same process, or across processes. Across computer boundaries (Figure 3), the client can interact with services in its intranet or across the Internet.

 
Figure 2. Same-machine Communication: The figure shows same-machine communication using WCF.
 
Figure 3. Cross-machine Communication: Here's an example of cross-machine communication using WCF.
Because all interactions are done via a proxy, WCF maintains the same programming model for the local and remote cases, thus not only enabling you to switch locations without affecting the client, but also significantly simplifying the application programming model. Most all of the WCF functionality is included in a single assembly called System.ServiceModel.dll in the System.ServiceModel namespace.

Service Address
In WCF, every service is associated with a unique address. The address provides two important elements: the location of the service and the transport protocol used to communicate with the service. The location portion of the address indicates the name of the target computer, site, or network, a communication port, pipe, or queue, and an optional specific path or URI. As for transports, WCF 1.0 supports the following:

  • HTTP
  • TCP
  • Peer network
  • IPC (Inter-Process Communication over named pipes)
  • MSMQ
Addresses always have this format:

[base address]/[optional URI]


The base address is always in this format:

[transport]://[machine or domain][:optional port]


Here are a few possible addresses for services:



http://localhost:8001 http://localhost:8001/MyService net.tcp://localhost:8002/MyService net.pipe://localhost/MyPipe net.msmq://localhost/private/MyService


Service Contract
In WCF, all services expose contracts. The contract is a platform-neutral and standard way of describing what the service does. WCF defines four types of contracts.

  • Service contracts describe which operations you can perform on the service.
  • Data contracts define which data types are passed to and from the service. WCF defines implicit contracts for built-in types such as int and string, but you can easily define explicit opt-in data contracts for custom types.
  • Fault contracts define which errors are raised by the service, and how the service handles and propagates errors to its clients.
  • Message contracts allow the service to interact directly with messages. Message contracts can be typed or untyped, and are somewhat analogous to late-binding invocation in the CLR. Message contracts are rarely used by SOA developers.
Of the four types of contracts, this article focuses on the service contract.

WCF allows the client to communicate with the service across all execution boundaries.
You define a service contract using the ServiceContractAttribute and you can apply the attribute on an interface or a class, as shown in Listing 1.

Service contracts are independent of the interface or class visibility—public or internal visibility is a CLR concept, not WCF. Applying ServiceContractAttribute on an internal interface exposes that interface as a public service contract, ready to be consumed across the service boundary. Without the ServiceContractAttribute, the interface is not visible to WCF clients, in line with the service-oriented tenet that service boundaries are explicit. To enforce that, all contracts must be strictly opt-in.

The OperationContractAttribute can be applied only on methods (not properties, indexers, or events, which are CLR concepts). OperationContractAttribute exposes a contract method as a logical operation to perform on the service contract. Other methods on the interface that do not have the OperationContractAttribute will not be part of the contract. This enforces the explicit service boundary and maintains an opt-in model for the operations themselves. Note that contract operations are independent of the method visibility. Listing 1 demonstrates the best practice of separating the service contract from its implementation by defining a contract interface.

You can also apply the ServiceContractAttribute and the OperationContractAttribute on the class directly, in which case, WCF infers a service contract out of the class and the methods with OperationContractAttribute. This is a technique to avoid:

//Avoid [ServiceContract] class MyService { [OperationContract] //Visibility //does not matter string MyMethod(string text) { return "Hello " + text; } public string MyOtherMethod(string text) { return "Cannot call this method over WCF"; } }


The ServiceContractAttribute maps the CLR interface (or inferred interface) to a technology-neutral WCF contract. A single class can support multiple contracts by deriving and implementing multiple interfaces decorated with the ServiceContractAttribute. The class can implement the interfaces implicitly or explicitly because the method visibility has no bearing on WCF. There are, however, a few implementation constraints: Avoid parameterized constructors because only the default constructor will ever be used by WCF. Although the class can use internal properties, indexers, and static members, no WCF client will ever be able to access those.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap