WCF 4.5 Multi-Layer Services Development with Entity Framework

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.

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.

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.

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.

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

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.

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:

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

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

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

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:

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

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; }
    }
  }
}

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; }
    }
  }
}

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; }
    }
  }
}

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:

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:

<serviceMetadata httpGetEnabled="true" />