WCF 4.5 Multi-Layer Services Development with Entity Framework

By Mike Liu
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Web Services and Windows Communication Foundation

About this book

WCF is Microsoft's recommended model for building services and Entity Framework is Microsoft’s preferred ORM for accessing underlying data storages. Learning WCF and Entity Framework has become essential and critical for every software developer to survive in this SOA world.

WCF and Entity Framework are two powerful yet complex technologies, and there are huge reference tomes out there in the market for these two technologies. With this book, you won’t get overwhelmed or scared away by tons of references; instead, you will be given a simple, easy-to-follow approach to get started. For the code solutions within this book, unlike many other WCF and EF books, where you have just one code snippet after another code snippet, all solutions in this book are fully working and completely finished. These solutions are independent of each other, yet built on top of each other, and get more and more sophisticated as the book progresses, so you can learn more advanced WCF and EF techniques easily and quickly.

This book is a step-by-step tutorial to guide you through learning WCF, Entity Framework, LINQ, and LINQ to Entities. You will be guided to create six WCF and Entity Framework solutions from scratch, of which three are multi-layered real-world WCF service solutions, so you will not only be reading, but also be coding through the book, to gain practical experience of WCF and Entity Framework.

Various test clients will be associated with each solution and all solutions can be built and run independently of other solutions. Clear instructions and relevant screenshots will make sure you won't get lost in the world of WCF and Entity Framework. Configuration files, host applications, test clients, and WCF services for each solution will also be available for download for you to examine, modify, and debug from the outside in.

The book focuses on the essentials of using WCF and Entity Framework, rather than providing a reference to every single possibility. It leaves the reference material online where it belongs, and concentrates instead on practical examples, code, and advice.

Publication date:
December 2012
Publisher
Packt
Pages
394
ISBN
9781849687669

 

Chapter 1. Web Services and Windows Communication Foundation

A web service is a software system designed to support interoperable machine-to-machine interaction over a network. Web services have been around for a while, but it is the service-oriented architecture (SOA) that makes web services much more popular today. Now with Windows Communication Foundation (WCF), a new era has begun for developing services, including web services, on the Microsoft platform.

In this chapter, we will learn concepts and definitions related to SOA, web services, and WCF. We will discuss each of the following in detail:

  • What is SOA?

  • Web service and its relation to SOA

  • Standards and specifications for web services

  • What is WCF?

  • Use of WCF for SOA

  • WCF architecture

  • Basic WCF concepts

  • WCF production and development environments

 

What is SOA?


SOA is the acronym for service-oriented architecture. SOA is an architectural design pattern by which several guiding principles determine the nature of the design. Basically, SOA states that every component of a system should be a service, and the system should be composed of several loosely-coupled services. A service here means a unit of a program that serves a business process. Loosely-coupled here means that these services should be independent of each other so that changing one of them should not affect any other services.

SOA is neither a specific technology nor a specific language. It is just a blueprint or a system design approach. It is an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise system. The key concepts of SOA are services, high interoperability, and loose coupling.

 

Web services


There are many approaches to realizing SOA, but the most popular and practical one is using web services.

What is a web service?

As mentioned in the beginning of this chapter, a web service is a software system designed to support interoperable machine-to-machine interaction over a network. A web service is typically hosted on a remote machine (provider) and called by a client application (consumer) over a network. After the provider of a web service publishes the service, the client can discover it and invoke it. The communications between a web service and a client application to be used can be done by sending XML messages. A web service is hosted within a web server and HTTP is used as the transport protocol between the server and the client applications. The following diagram shows the interaction of web services:

The reason it is called a web service is that it is designed to be hosted in a web server such as Microsoft Internet Information Server, and called over the Internet, typically through the HTTP or HTTPS protocols. This is to ensure that a web service can be called by any application, using any programming language, and under any operating system, as long as there is an active Internet connection, and of course, an open HTTP/HTTPS port, which is true for almost every computer on the Internet.

Web services were invented to solve the interoperability problem between various applications. In the early 90s, along with the LAN/WAN/Internet development, it became a big problem to integrate different applications. An application might have been developed using C++ or Java, and run on a Unix box, a Windows PC, or even a mainframe computer. There was no consistent way that was standardized across the industry for one application to communicate with other applications. It was the development of XML that made it possible to share data between the applications across hardware boundaries and networks or even over the Internet.

For example, a Windows application might need to display the price of a particular stock. With a web service, this application can make a request to a URL and/or pass an XML string such as the following:

<QuoteRequest><GetPrice Symble='XYZ'/> </QuoteRequest>

The requested URL is actually the Internet address of a web service, which upon receiving the preceding quote request, gives a response as follows:

<QuoteResponse><QuotePrice Symble='XYZ'>51.22</QuotePrice> </QuoteResponse/>

The Windows application then uses an XML parser to interpret the response package and display the price on the screen.

Each web service has a unique URL and contains various methods. When calling a web service, you have to specify which method you want to call, and then you need to pass the required parameters to the web service method. Each web service method will also give a response package to provide the execution results to the caller.

Not only can new applications, such as web services, be developed, but also the legacy applications can be wrapped up and exposed as web services. So, an IBM mainframe accounting system might be able to provide external customers with a link to check the balance of an account.

WSDL

In order for a web service to be invoked by other applications, the invoking system must know how to call the method in the web service. WSDL is a language that provides the ability for a web service to be able to give a description of the methods available through the web service.

WSDL stands for Web Services Description Language. It is an XML format that defines and describes the functionalities of the web service, including the method names, parameter names and types, and returning datatypes of the web service.

For a Microsoft ASMX web service, you can see the WSDL by adding ?WSDL at the end of the web service URL, say http://localhost/MyService/MyService.asmx?WSDL.

Web service proxy

A client application calls a web service through a proxy. A web service proxy is a subclass between a web service and a client. It is normally autogenerated, according to the WSDL of the web service, by a tool such as Visual Studio IDE. It can be re-used by any client application. The proxy contains the stub methods mimicking all the methods of the web service so that a client application can call each method of the web service through these stub methods. It also contains other necessary information required by the client to call the web service such as custom exceptions, custom data and class types, and so on.

The address of the web service can be embedded within the proxy class, or it can be placed inside a configuration file. A proxy class of a web service can be created for a specific language. For example, there could be a proxy class for the Java clients, a proxy class for the C# clients, and yet another proxy class for the COBOL clients. A proxy class can also be generated in a commonly understood way such as in XML format. Different clients written in different languages can re-use this same common proxy class to communicate with the web service.

To call a web service from a client application, the proper proxy class first has to be added to the client project. Then, with an optional configuration file, the address of the web service can be defined. Within the client application, a web service object can be instantiated and its methods can be called just as for any other normal method.

SOAP

There are many standards for web services—SOAP is one of them. SOAP was originally an acronym for Simple Object Access Protocol and was designed by Microsoft. As this protocol became popular with the spread of web services and its original meaning was misleading, the original acronym was dropped with version 1.2 of the standard. It is now merely a protocol, maintained by W3C.

Now, SOAP is a protocol for exchanging the XML-based messages over computer networks. It is widely used by web services and has become its de facto protocol. With SOAP, the client application can send a request in XML format to a server application, and then the server application will send back a response in XML format. The transport for SOAP is normally HTTP/HTTPS, and the wide acceptance of HTTP is one of the reasons why SOAP is also widely accepted today.

 

Web services: standards and specifications


Because SOA is an architectural style, and web service is now the de facto standard for building SOA applications, we need to know what standards and specifications are available for web services.

As discussed in previous sections, there are many standards and specifications for web services. Some have been well developed and widely accepted, some are being developed, and others are just at the proposal stage. These specifications are in varying degrees of maturity, and are maintained or supported by various standards and entities. Specifications may complement, overlap, and compete with each other. As most of these standards' committees and specifications are for future web services, not all of them are implemented in current web service frameworks.

The web service standards and specifications are occasionally referred to as WS-* , although there is neither a single managed set of specifications that this consistently refers to nor a recognized owning body across all of them. The reference term WS-* is more of a general nod to the fact that many specifications are named with WS- as their prefix.

Besides XML, SOAP, and WSDL, here is a brief list of some other important standards and specifications for web services.

WS-I Profiles

The Web Services Interoperability Organization (WS-I) is an industry consortium chartered to promote interoperability across the stack of web services specifications. It publishes web service profiles, sample applications, and test tools to help determine profile conformance. One of the popular profiles it has published is the WS-I Basic Profile. WS-I is governed by a Board of Directors, and Microsoft is one of the board members. The web address for the WS-I Organization is http://www.ws-i.org.

WS-Addressing

WS-Addressing is a mechanism that allows web services to communicate addressing information. With traditional web services, addressing information is carried by the transport layer, and the web service message itself knows nothing about its destination. With this new standard, addressing information will be included in the XML message itself. A SOAP header can be added to the message for this purpose. The network-level transport is now responsible only for delivering that message to a dispatcher that is capable of reading the metadata.

WS-Security

WS-Security describes how to handle security issues within the SOAP messages. It attaches the signature and encryption information as well as the security tokens to the SOAP messages. In addition to the traditional HTTP/HTTPS authentications, it incorporates extra security features in the header of the SOAP message, working in the application layer. Also, it ensures the end-to-end security.

There are several specifications associated with WS-Security, such as WS-SecureConversation, WS-Federation, WS-Authorization, WS-Policy, WS-Trust, and WS-Privacy.

WS-ReliableMessaging

WS-ReliableMessaging describes a protocol that allows SOAP messages to be delivered reliably between the distributed applications.

The WS-ReliableMessaging model enforces reliability between the message source and destination. If a message cannot be delivered to the destination, the model must raise an exception or indicate to the source that the message can't be delivered.

WS-Coordination and WS-Transaction

WS-Coordination describes an extensible framework for providing protocols that coordinate the actions of distributed applications. The framework enables the existing transaction processing, workflow, and other systems for coordination, to hide their proprietary protocols, and to operate in a heterogeneous environment. Additionally, this specification provides a definition for the structure of the context and the requirements for propagating context between the cooperating services.

WS-Transaction describes coordination types that are used with the extensible coordination framework described in the WS-Coordination specification. It defines two coordination types—Atomic Transaction (AT) for individual operations and Business Activity (BA) for long-running transactions.

WS-AtomicTransaction provides the definition of the atomic transaction coordination type that is used with the extensible coordination framework described in the WS-Coordination specification. This protocol can be used to build the applications that require consistent agreement on the outcome of short-lived distributed activities that have all-or-nothing semantics.

WS-BusinessActivity provides the definition of the business activity coordination type that is used with the extensible coordination framework described in the WS-Coordination specification. This protocol can be used to build the applications that require consistent agreement on the outcome of long-running distributed activities.

 

Windows Communication Foundation (WCF)


WCF is the latest technology from Microsoft for building services, including web services. In this section, we will learn what WCF is and what it is composed of. We will also learn various .NET runtimes, .NET frameworks, Visual Studio versions, the relationships between them, and what is needed to develop or deploy WCF services. You will see some code snippets that will help you to further understand the WCF concepts although they are not in a completed WCF project. Once we have grasped the basic concepts of WCF, we will develop a complete WCF service and create a client application to consume it, in the next chapter.

What is WCF?

WCF is the acronym for Windows Communication Foundation. It is Microsoft's unified programming model for building the service-oriented applications. It enables developers to build the secure, reliable, and transacted solutions that integrate across platforms and are interoperated with the existing investments. WCF is built on the Microsoft .NET Framework and simplifies the development of the connected systems. It unifies a broad array of the distributed systems capabilities in a composable, extensible architecture that supports multiple transports, messaging patterns, encodings, network topologies, and hosting models. It is the next generation version of several existing products—ASP.NET's web methods (ASMX) and Microsoft Web Services Enhancements (WSE) for Microsoft .NET, .NET Remoting, Enterprise Services, and System.Messaging.

The purpose of WCF is to provide a single programming model, which can be used to create services on the .NET platform, for organizations.

Why is WCF used for SOA?

As we have seen in the previous section, WCF is an umbrella technology that covers ASMX web services, .NET Remoting, WSE, Enterprise Service, and System Messaging. It is designed to offer a manageable approach to distributed computing, broad interoperability, and direct support for service orientation. WCF supports many styles of distributed application development by providing a layered architecture. At its base, the WCF channel architecture provides asynchronous, untyped message-passing primitives. Built on top of this base are protocol facilities for secure, reliable, and transacted data exchange, and a broad choice of transport and encoding options.

Let us take an example that shows why WCF is a good approach for SOA. Suppose a company is designing a service to get loan information. This service could be used by the internal call center application, an Internet web application, and a third-party Java J2EE application such as a banking system. For interactions with the call center client application, performance is important. For communication with the J2EE-based application, however, interoperability becomes the highest goal. The security requirements are also quite different between the local Windows-based application and the J2EE-based application running on another operating system. Even transactional requirements might vary with only the internal application being allowed to make the transactional requests.

With these complex requirements, it is not easy to build the desired service with any single existing technology. For example, the ASMX technology may serve well for the interoperability, but its performance may not be ideal. .NET Remoting is a good choice from the performance perspective, but it is not good at interoperability. Enterprise Services could be used for managing the object lifetimes and defining the distributed transactions, but Enterprise Services supports only a limited set of communication options.

Now with WCF, it is much easier to implement this service. As WCF has unified a broad array of distributed systems capabilities, the get loan service can be built with WCF for all of its application-to-application communication. The following list shows how WCF addresses each of these requirements:

  • Since WCF can communicate by using web service standards, interoperability with other platforms that also support SOAP, such as the leading J2EE-based application servers, is straightforward.

  • You can also configure and extend WCF to communicate with web services using messages not based on SOAP, for example, simple XML formats such as RSS.

  • Performance is of paramount concern for most businesses. WCF was developed with the goal of being one of the fastest-distributed application platforms developed by Microsoft.

  • To allow for 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 an XML Information Set. Using this option makes sense for communication with the call center client application because it is also built on WCF and performance is an important concern.

  • Managing object lifetimes, defining distributed transactions, and other aspects of Enterprise Services are now provided by WCF. They are available to any WCF-based application, which means that the get loan service can use them with any of the other applications that it communicates with.

  • Because it supports a large set of the WS-* specifications, WCF helps to provide reliability, security, and transactions, when communicating with any platform that supports these specifications.

  • The WCF option for queued messaging, built on Message Queuing, allows applications to use persistent queuing without using another set of application programming interfaces.

The result of this unification is greater functionality and significantly reduced complexity.

WCF architecture

The following diagram illustrates the principal layers of the WCF architecture. This diagram is taken from the Microsoft website (http://msdn.microsoft.com/en-us/library/ms733128.aspx):

  • The Contracts layer defines various aspects of the message system. For example, the Data Contract describes every parameter that makes up every message that a service can create or consume. The Service runtime layer contains the behaviors that occur only during the actual operation of the service, that is, the runtime behaviors of the service. The Messaging layer is composed of channels. A channel is a component that processes a message in some way, for example, in authenticating a message.

  • In its final form, a service is a program. Like other programs, a service must be run in an executable format. This is known as the hosting application.

In the next section, we will learn these concepts in detail.

Basic WCF concepts – WCF ABCs

There are many terms and concepts surrounding WCF such as address, binding, contract, endpoint, behavior, hosting, and channels. Understanding these terms is very helpful when using WCF.

Address

The WCF address is a specific location for a service. It is the specific place to which a message will be sent. All WCF services are deployed at a specific address, listening at that address for incoming requests.

A WCF address is normally specified as a URL, with the first part specifying the transport mechanism, and the hierarchical parts specifying the unique location of the service. For example, http://www.myweb.com/myWCFServices/SampleService is an address for a WCF service. This WCF service uses HTTP as its transport protocol, and it is located on the server www.myweb.com, with a unique service path of myWCFServices/SampleService. The following diagram illustrates the three parts of a WCF service address:

Binding

Bindings are used for specifying the transport, encoding, and protocol details required for clients and services to communicate with each other. Bindings are what WCF uses to generate the underlying wire representation of the endpoint (an endpoint is a place where clients can communicate with a WCF service; more details will follow). So, most of the details of the binding must be agreed upon by the parties that are communicating. The easiest way to achieve this is by having clients of a service to use the same binding that the service uses.

A binding is made up of a collection of binding elements. Each element describes some aspects of how the service communicates with clients. A binding must include at least one transport binding element, at least one message encoding binding element (which can be provided by the transport binding element by default), and any number of other protocol binding elements. The process that builds a runtime out of this description, allows each binding element to contribute code to that runtime.

WCF provides bindings that contain common selections of binding elements. These can either be used with their default settings or the default values can be modified according to the user requirements. These system-provided bindings have properties that allow direct control over the binding elements and their settings.

The following are some examples of the system-provided bindings:

  • BasicHttpBinding

  • WSHttpBinding

  • WSDualHttpBinding

  • WS2007HttpBinding

  • WSFederationHttpBinding

  • WS2007FederationHttpBinding

  • NetTcpBinding

  • NetNamedPipeBinding

  • NetMsmqBinding

  • NetPeerTcpBinding

  • WebHttpBinding

  • MsmqIntegrationBinding

Each one of these built-in bindings has predefined required elements for a common task, and is ready to be used in your project. For instance, BasicHttpBinding uses HTTP as the transport for sending the SOAP 1.1 messages, and it has attributes and elements such as receiveTimeout, sendTimeout, maxMessageSize, and maxBufferSize. You can use the default settings of its attributes and elements, or overwrite them as needed.

Contract

A WCF contract is a set of specifications that defines the interfaces of a WCF service. A WCF service communicates with other applications according to its contracts. There are several types of WCF contracts such as service contract, operation contract, data contract, message contract, and fault contract.

Service contract

A service contract is the interface of the WCF service. Basically, it tells others what the service can do. It may include the service-level settings such as the name of the service, the namespace of the service, and the corresponding callback contracts of the service. Inside the interface, it can define a bunch of methods or service operations for specific tasks. A WCF service has to contain at least one service contract to service requests.

Operation contract

An operation contract is defined within a service contract. It defines the parameters and return type of an operation. An operation can take data of a primitive (native) datatype such as an integer as a parameter, or it can take a message, which should be defined as a message contract type. Just as a service contract is an interface, an operation contract is a definition of an operation. It has to be implemented in order for the service to function as a WCF service. An operation contract also defines the operation-level settings such as the transaction flow of the operation, the directions of the operation (one-way request/reply or duplex callbacks), and the fault contract of the operation.

The following is an example of an operation contract:

[FaultContract(typeof(ProductFault))]
GetProductResponse GetProduct(GetProductRequest request);

In this example, the operation contract's name is GetProduct and it takes one input parameter, which is of the type GetProductRequest (a message contract) and has one return value, which is of the type GetProductResponse (another message contract). It may return a fault message, which is of the type ProductFault (a fault contract), to the client applications. We will cover message contract and fault contract in the following sections.

Message contract

If an operation contract needs to pass a message as a parameter or return a message, the type of these messages will be defined as message contracts. A message contract defines the elements of the message as well as any message-related settings such as the level of message security, and also whether an element should go to the header or to the body.

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.

The following is a message contract example:

namespace MyWCF.EasyNorthwind.MessageContracts
{
  /// <summary>
  /// Service Contract Class - GetProductResponse
  /// </summary>
  [System.ServiceModel.MessageContract(IsWrapped = false)] 
  public partial class GetProductResponse
  {
    private MyWCF.EasyNorthwind.DataContracts.Product product;
    [System.ServiceModel.MessageBodyMember(Name = "Product")] 
    public MyWCF.EasyNorthwind.DataContracts.Product Product
    {
      get { return product; }
      set { product = value; }
    }
  }
}

In this example, the message contract's name is GetProductResponse and this message contract has one member, which is of the type Product.

Data contract

Data contracts are datatypes of the WCF service. All datatypes used by the WCF service must be described in metadata to enable other applications to interoperate with the service. A data contract can be used by an operation contract as a parameter or return type, or it can be used by a message contract to define elements. If a WCF service uses only primitive (native) datatypes, it is not necessary to define any data contract.

The following is an example of data contract:

namespace MyWCF.EasyNorthwind.DataContracts
{
  /// <summary>
  /// Data Contract Class - Product
  /// </summary>
  [System.Runtime.Serialization.DataContract(
  Namespace = "http://MyCompany.com/ProductService/EasyWCF/2008/05",Name = "Product")]
  public partial class Product 
  {
    private int productID;
    private string productName;
    [System.Runtime.Serialization.DataMember(
    Name= "ProductID")]
    public int ProductID
    {
      get { return productID; }
      set { productID = value; }
    }
    [System.Runtime.Serialization.DataMember(
Name = "ProductName")]
    public string ProductName
    {
      get { return productName; }
      set { productName = value; }
    }
  }
}

In this example, the namespace of the data contract is http://MyCompany.com/ ProductService/EasyWCF/2008/05, the name of the data contract is Product, and this data contract has two members (ProductID and ProductName).

Fault contract

In any WCF service operation contract, if an error is returned to the caller, the caller should be warned of that error. These error types are defined as fault contracts. An operation can have zero or more fault contracts associated with it.

The following is a fault contract example:

namespace MyWCF.EasyNorthwind.FaultContracts
{
  /// <summary>
  /// Data Contract Class - ProductFault
  /// </summary>
  [System.Runtime.Serialization.DataContract(
  Namespace = "http://MyCompany.com/ProductService/EasyWCF/2008/05", Name = "ProductFault")]
  public partial class ProductFault 
  {
    private string faultMessage;
    [System.Runtime.Serialization.DataMember(
    Name = "FaultMessage")]
    public string FaultMessage
    {
      get { return faultMessage; }
      set { faultMessage = value; }
    }
  }
}

In this example, the namespace of the fault contract is http://MyCompany.com/ ProductService/EasyWCF/2008/05, the name of the fault contract is ProductFault, and the fault contract has only one member (FaultMessage).

Endpoint

Messages are sent between endpoints. Endpoints are places where messages are sent or received (or both), and they define all of the information required for the message exchange. A service exposes one or more application endpoints (as well as zero or more infrastructure endpoints). A service can expose this information as the metadata that clients process to generate the appropriate WCF clients and communication stacks. When needed, the client generates an endpoint that is compatible with one of the service's endpoints.

A WCF service endpoint has an address, a binding, and a service contract (sometimes referred as WCF ABCs).

The endpoint's address is a network address where the endpoint resides. It describes, in a standard-based way, where messages should be sent. Each endpoint normally has one unique address, but sometimes two or more endpoints can share the same address.

The endpoint's binding specifies how the endpoint communicates with the world, including things such as transport protocol (TCP, HTTP), encoding (text, binary), and security requirements (SSL, SOAP message security).

The endpoint's contract specifies what the endpoint communicates, and is essentially a collection of messages organized in the operations that have basic Message Exchange Patterns (MEPs) such as one-way, duplex, or request/reply.

The following diagram shows the components of a WCF service endpoint:

Behavior

A WCF behavior is a type of settings to extend the functionality of the original type. There are many types of behaviors in WCF such as service behavior, binding behavior, contract behavior, security behavior, and channel behavior. For example, a new service behavior can be defined to specify the transaction timeout of the service, the maximum concurrent instances of the service, and whether the service publishes metadata or not. Behaviors are configured in the WCF service configuration file. We will configure several specific behaviors in the next chapters.

Hosting

A WCF service is a component that can be called by other applications. It must be hosted in an environment in order to be discovered and used by others. The WCF host is an application that controls the lifetime of the service. With .NET 3.0 and beyond, there are several ways to host the service.

Self hosting

A WCF service can be self-hosted, which means that the service runs as a standalone application and controls its own lifetime. This is the most flexible and easiest way of hosting a WCF service, but its availability and features are limited.

Windows services hosting

A WCF service can also be hosted as a Windows service. A Windows service is a process managed by the operating system and it is automatically started when Windows is started (if it is configured to do so). However, it lacks some critical features (such as versioning) for WCF services.

IIS or Windows Activation Services hosting

A better way to host a WCF service is to use IIS. This is the traditional way of hosting a web service. IIS, by its nature, has many useful features such as process recycling, idle shutdown, process health monitoring, message-based activation, high availability, easy manageability, versioning, and deployment scenarios. All of these features are required for the enterprise-level WCF services.

Starting from IIS 7.0, Windows Activation Services (WAS) is the process activation mechanism for hosting WCF services. WAS retains the familiar IIS 6.0 process model application pools and message-based process activation and hosting features (such as rapid failure protection, health monitoring, and recycling), but it removes the dependency on HTTP from the activation architecture. IIS 7.0 and above use WAS to accomplish the message-based activation over HTTP. Additional WCF components also plug into WAS to provide message-based activation over the other protocols that WCF supports, such as TCP, MSMQ, and named pipes. This allows applications that use the non-HTTP communication protocols to use the IIS features such as process recycling, rapid fail protection, and the common configuration systems that were only previously available to the HTTP-based applications.

Channels

As we have seen in the previous sections, a WCF service has to be hosted in an application on the server side. On the client side, the client applications have to specify the bindings to connect to the WCF services. The binding elements are interfaces and they have to be implemented in the concrete classes. The concrete implementation of a binding element is called a channel. The binding represents the configuration and the channel is the implementation associated with that configuration. Therefore, there is a channel associated with each binding element. Channels stack on top of one another to create the concrete implementation of the binding—the channel stack.

The WCF channel stack is a layered communication stack with one or more channels that process messages. At the bottom of the stack, there is a transport channel that is responsible for adapting the channel stack to the underlying transport (for example, TCP, HTTP, SMTP, and other types of transport). Channels provide a low-level programming model for sending and receiving messages. This programming model relies on several interfaces and other types collectively known as the WCF channel model. The following diagram shows a simple channel stack:

Metadata

The metadata of a service describes the characteristics of the service that an external entity needs to understand in order to communicate with the service. Metadata can be consumed by the ServiceModel Metadata Utility Tool (Svcutil.exe) to generate a WCF client proxy and the accompanying configuration that a client application can use to interact with the service.

The metadata exposed by the service includes XML schema documents, which define the data contract of the service, and WSDL documents, which describe the methods of the service.

Though WCF services always have metadata, it is possible to hide the metadata from outsiders. If you do so, you have to pass the metadata to the client side by other means. This practice is not common, but it gives your services an extra layer of security. When enabled through the configuration settings through metadata behavior, metadata for the service can be retrieved by inspecting the service and its endpoints. The following configuration setting in a WCF service configuration file will enable metadata publishing for HTTP transport protocol:

<serviceMetadata httpGetEnabled="true" />
 

WCF production and development environments


WCF was first introduced in Microsoft's .NET Common Language Runtime (CLR) version 2.0. The corresponding framework at that time was .NET 3.0. To develop and run the WCF services, Microsoft .NET Framework 3.0 or above is required.

Visual Studio is Microsoft's IDE for developing the WCF service applications. Visual Studio 2008 and above support WCF service application development.

The following table shows all of the different versions of the .NET runtimes, .NET Frameworks, and Visual Studios, along with their relationships:

CLR

.NET Framework

Components

Visual Studio

CLR 4.0

.NET 4.5

Metro

HTML5

Portable Class Libraries

2012

.NET 4.0

Parallel Computing

Dynamic

Covariance and Contravariance

2010 or above

CLR 2.0

.NET 3.5 SP1

ASP.NET MVC

Entity Framework

LINQ to Entities

Cloud Computing

2008 or above

.NET 3.5

LINQ

ASP .NET AJAX

REST

RSS

2008 or above

LINQ to SQL

LINQ to XML

LINQ to Objects

.NET 3.0

WCF

WPF

WF

CardSpace

.NET 2.0

Winforms

ASP.NET

ADO.NET

2005 or above

CLR 1.0

.NET 1.1

Winforms

ASP.NET

ADO.NET

2003

.NET 1.0

2002

 

Summary


In this chapter, we have learned and clarified many concepts related to SOA, web services, and WCF. Now, we know that SOA is an architectural design and WCF is Microsoft's unified programming model for building the service-oriented applications.

In the next chapter, we will develop our first WCF service with Visual Studio 2012, so you can have a better understanding of WCF.

About the Author

  • Mike Liu

    Mike Liu studied Mathematics and Software Engineering at Nanjing University and Brandeis University, where he graduated with a Bachelor's degree and a Master's degree, respectively. He is a Sun Certified Java Programmer (SCJP), Microsoft Certified Solution Developer for Visual Studio 6.0, and Microsoft Certified Solution Developer for .NET. He has been working as a software engineer/architect on various platforms (DOS, Unix, and Windows) using C/C++, Java, VB/VB.NET, and C#.

    Mike started using C# for production development back in the year 2001 when C# was still in beta stage, and he is now working as a senior software engineer for an investment management firm in Boston, Massachusetts, US.

    Mike had his first book, MITT: Multi-user Integrated Table-processing Tool Under Unix, Beijing Hangtian University Press, published in 1993, and second book, Advanced C# Programming, Tsinghua University Press, published in 2003. The previous three versions of this book were published in 2008, 2010, and 2012.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now