WCF 4.0 Multi-tier Services Development with LINQ to Entities

By Mike Liu
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Free Chapter
    Introducing Web Services and Windows Communication Foundation

About this book

WCF is the Microsoft model for building services, whereas LINQ to Entities is the Microsoft ORM for accessing underlying data storage. Want to learn both? You would normally have to dig through huge reference tomes—so wouldn't you agree that a simple-to-follow practical tutorial on WCF and LINQ to Entities is the way to get ahead?

This book is the quickest and easiest way to learn WCF and LINQ to Entities in Visual Studio 2010. WCF and LINQ to Entities are both powerful yet complex technologies from Microsoft—but you will be surprised at how easily this book will get you get up and running with them.

Mastery of these two topics will quickly enable you to create Service-Oriented applications, and allow you to take your first steps into the world of Service Oriented Architecture without becoming overwhelmed.

Through this book, you will learn what's going on behind the scenes with WCF, and dive into the basic yet most useful techniques for LINQ to Entities. You will develop three real-world multi-tiered WCF services from beginning to end, with LINQ to Entities being used in the data access layer of the services. Various clients including windows console applications, the WCF Test Client, Windows Form applications and WPF applications will be created to test these WCF services. By the end of this book, you will be 100% confident that you know WCF and LINQ to Entities, not only in theory, but with sound real-world experience.

Publication date:
June 2010
Publisher
Packt
Pages
348
ISBN
9781849681148

 

Chapter 1. Introducing Web Services and Windows Communication Foundation

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

  • What is SOA?

  • What is a web service and how is it related to SOA?

  • What standards and specifications are there for web services?

  • What is WCF?

  • Use of WCF for SOA.

  • WCF architecture.

  • Basic WCF concepts.

 

What is SOA?


SOA is the acronym for Service Oriented Architecture. As it has come to be known, 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?

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 use 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:

Web services were invented to solve the interoperability problem between 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 it to communicate with other applications. It was the development of XML that made it possible to share data between 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 <QuoteRequest><GetPrice Symble='XYZ'/> </QuoteRequest>. The requested URL is actually the Internet address of a web service, which, upon receiving the above quote request, gives a response—<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.

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.

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 pass the required parameters to the web service method. Each web service method will also give a response package to tell the caller the execution results.

Besides new applications being developed specifically as web services, legacy applications can also 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.

Web service WSDL

In order to be called by other applications, each web service has to supply a description of itself so that other applications will know how to call it. This description is provided in a language called WSDL.

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 data types of the web service.

For a Microsoft ASMX web service, you can see the WSDL by adding ?WSDL to 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 stub class between a web service and a client. It is normally autogenerated by a tool such as Visual Studio IDE, according to the WSDL of the web service. It can be reused by any client application. The proxy contains 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 could be generated for a specific language. For example, there could be a proxy class for Java clients, a proxy class for C# clients, and yet another proxy class for COBOL clients. A proxy class could also be generated in a commonly understood way such as in XML format. Different clients written in different languages can reuse 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.

SOAP, now, is a protocol for exchanging 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 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 there are 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.

Web service standards and specifications are occasionally referred to as "WS-*" although there is not 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 capable of reading the metadata.

WS-Security

WS-Security describes how to handle security issues within SOAP messages. It attaches signature and encryption information as well as security tokens to 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 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 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.

There are several Delivery Assurance options for WS-ReliableMessaging, including AtLeastOnce, AtMostOnce, Exactly Once, and InOrder.

WS-Coordination and WS-Transaction

WS-Coordination describes an extensible framework for providing protocols that coordinate the actions of distributed applications. The framework enables 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 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 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 applications that require consistent agreement on the outcome of long-running distributed activities.

 

WCF: Windows Communication Foundation


WCF is the latest technology from Microsoft for building services, including web services. In this section, we will explain what WCF is and what it is composed of. We will also explain 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 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 latest technology that enables applications in a distributed environment to communicate with each other.

WCF is Microsoft's unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments. WCF is built on the Microsoft .NET Framework and simplifies the development of connected systems. It unifies a broad array of 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, that 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, transacted data exchange, and a broad choice of transport and encoding options.

Let us take an example to see 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 transactional requests.

With these complex requirements, it is not easy to build the desired service with any single existing technology. For example, 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 object lifetimes and defining 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 shows how WCF addresses each of these requirements:

  • Because WCF can communicate 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 Windows Communication Foundation (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 explain 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 to specify 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. 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 for 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 aspect 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 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 system-provided bindings:

BasicHttpBinding, WSHttpBinding, WSDualHttpBinding, WSFederationHttpBinding, NetTcpBinding, NetNamedPipeBinding, NetMsmqBinding, NetPeerTcpBinding, and 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, the BasicHttpBinding uses HTTP as the transport for sending 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 define 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 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. Normally, a WCF service has at least one service contract.

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) data type 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 operation-level settings such as the transaction flow of the operation, the directions of the operation (one-way, two-way, or both ways), 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.

The following is a message contract example:

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

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

Data contract

Data contracts are data types of the WCF service. All data types 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) data types, 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>
  [WcfSerialization::DataContract(Namespace = "http://MyCompany.com/ProductService/EasyWCF/2008/05", Name = "Product")]
  public partial class Product 
  {
    private int productID;
    private string productName;
    [WcfSerialization::DataMember(Name = "ProductID", IsRequired = false, Order = 0)]
    public int ProductID
    {
      get { return productID; }
      set { productID = value; }
    }
    [WcfSerialization::DataMember(Name = "ProductName", IsRequired = false, Order = 1)]
    public string ProductName
    {
      get { return productName; }
      set { productName = value; }
    }
  }
}

In this example, the namespace of the data contract is MyWCF.EasyNorthwind.DataContracts, 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>
  [WcfSerialization::DataContract(Namespace = "http://MyCompany.com/ProductService/EasyWCF/2008/05", Name = "ProductFault")]
  public partial class ProductFault 
  {
    private string faultMessage;
    [WcfSerialization::DataMember(Name = "FaultMessage", IsRequired = false, Order = 0)]
    public string FaultMessage
    {
      get { return faultMessage; }
      set { faultMessage = value; }
    }
  }
}

In this example, the namespace of the fault contract is MyWCF.EasyNorthwind.FaultContracts, 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 (WCF ABC).

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 or 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. Behaviors are configured in the WCF service configuration file. We will configure several specific behaviors in the chapters that follow.

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 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 enterprise-level WCF services.

Windows Activation Services hosting

The IIS hosting method, however, comes with several limitations in the service-orientation world, the dependency on HTTP being the main culprit. With IIS hosting, many of WCF's flexible options can't be utilized. This is the reason why Microsoft specifically developed a new method called Windows Process Activation Services (WAS) to host WCF services.

WAS is the new process activation mechanism for Windows Server 2008 that is also available on Windows Vista and Windows 7. It 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 uses WAS to accomplish 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 HTTP-based applications.

This hosting option requires WAS to be properly configured, but it does not require you to write any hosting code as part of the application. (Microsoft MSN, Hosting Services, retrieved on 3/6/2008 from http://msdn2.microsoft.com/enus/library/ms730158.aspx.)

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 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 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 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 is .NET 3.0. To develop and run WCF services, Microsoft .NET Framework 3.0 or above is required.

Visual Studio is the preferred IDE for developing WCF service applications. Both Visual Studio 2008 and Visual Studio 2010 support WCF service application development. Visual Studio 2008 also supports application development for .NET Framework 2.0, 3.0, and 3.5 (this is called multi-targeting), and Visual Studio 2010 supports application development for .NET Framework 2.0, 3.0, 3.5, and 4.0.

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.0

Parallel Computing

   

2010

      
 

.NET 3.5 SP1

ASP.NET

MVC

LINQ

Entity Framework

LINQ to Entities

Cloud Computing

2008,2010

      

CLR 2.0

.NET 3.5

LINQ to SQL

LINQ to XML

LINQ to Objects

ASP .NET AJAX

REST

RSS

2008,2010

      
 

.NET 3.0

WCF

WPF

WF

CardSpace

      
 

.NET 2.0

Winforms

ASP.NET

ADO.NET

 

2005,2008,2010

     

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. The key points in this chapter are:

  • SOA is an architectural design pattern

  • Web services are the most popular and practical way of realizing SOA today

  • There are many standards and specifications for web services, including (but not limited to) WSDL, SOAP, WS-I Profiles, and various WS-* standards

  • WCF is a better technology for developing SOA services

  • A WCF service has at least one service endpoint

  • A WCF service endpoint has an address, a binding, and a service contract

  • A WCF service can be self-hosted or can be hosted in a managed or an unmanaged application

  • A WCF service can publish metadata and communicates with client applications through channels

  • .NET Framework 3.0 or above is required to develop and run WCF service applications

  • Visual Studio 2008 and 2010 are the preferred IDEs for WCF service application development

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
WCF 4.0 Multi-tier Services Development with LINQ to Entities
Unlock this book and the full library FREE for 7 days
Start now