Windows Communication Foundation (WCF), formerly code-named "Indigo," is a new distributed messaging platform released with Windows Vista as part of the .NET Framework 3.0. The .NET Framework 3.0, formerly code-named "WinFX," includes four pillars: Windows Presentation Foundation (WPF), Windows Workflow Foundation (WF), Windows Communication Foundation (WCF), and Windows CardSpace. As Figure 1-1 illustrates, .NET 3.0 relies on the .NET Framework 2.0 (.NET 2.0) and is supported on Windows XP, Windows Vista, Windows Server 2003, and Windows "Longhorn" Server platforms.
Figure 1-1. Platform support for WCF
Why release yet another technology for distributed messaging? Unlike its predecessors, WCF is a truly service-oriented, loosely coupled, and interoperable platform. It simplifies service-oriented system design by removing the design dependencies that traditionally exist between how you access business functionality and the actual implementation of that business functionality. WCF promotes loose coupling not only between services and the functionality they expose, but also for choice of protocol, message encoding formats, and hosting environment. For example, services can be accessed over a variety of supported protocols, including named pipes, TCP, HTTP, and MSMQ. WCF also supports all of the core and emerging web service standards, which makes it a highly interoperable platform. Messages can always be represented in a format consistent with a set of well-adopted standards to communicate with other platforms.
Besides these modern characteristics, what's even more interesting is that you can now choose a single communication stack to gain access to the system services necessary to build a distributed system. WCF unifies the disparate programming paradigms you have previously used on the Windows platform to achieve similar goals--namely .NET Remoting, ASP.NET Web Services (ASMX), and Enterprise Services. WCF provides all of the plumbing for security, transactions, and reliable messaging over any protocol. Only Enterprise Services came close to providing all of these features in a single stack, but your component design was coupled to the technology and limited to TCP communication (thus, not interoperable).
This chapter will be your introduction to the programming model of WCF. I'll start by reviewing the principals of a Service Oriented Architecture and how WCF supports those principals. I'll also describe some practical deployment scenarios for WCF in distributed enterprise systems and then summarize some of the fundamental WCF concepts that will be discussed first in this chapter and then elaborated on throughout this book. After introducing core WCF concepts, I'll walk you through labs that exercise certain techniques and features. Instead of boring you with a bunch of "Hello World" examples, I plan to kick things up just a notch in this introductory chapter by enforcing good practices from the start while I teach you core concepts. Each of the labs you complete in this chapter will become successively more complex, and each will expose a new layer of detail. After each lab I will explain the relevant techniques and features you applied, discuss their relevance, and comment on recommended practices.
The labs in this chapter will cover the following topics:
Manually creating and consuming WCF services without the help of Visual Studio templates and related tools. This will provide you with a picture of the bare necessities you need to create, host, and consume a WCF service so that you understand the underlying programming model.
Creating WCF services using various Visual Studio project and service templates, leveraging configuration tools, and generating code to consume services.
Approaches to assembly allocation and service hosting over various protocols.
The importance of service metadata for publishing and consuming services.
By the end of this chapter you will be familiar with many core concepts including service contracts, endpoints, bindings, behaviors, hosting, metadata, channels, and proxies. Of course, throughout this book, the same concepts as well as additional ones will be discussed at length as you dive more deeply into specific WCF features.
What is Service Oriented Architecture (SOA)? There have been so many interpretations of this throughout the years that it seems important to establish a common understanding before I discuss WCF as an SOA platform. The Organization for the Advancement of Structured Information Standards, better known as OASIS (http://www.oasis-open.org), provides this official definition in its Reference Model for Service Oriented Architecture:
Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.
You can find the OASIS SOA Reference Model documentation at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.
You might add to this definition by stating that SOA relies on the ability to access chunks of business functionality, potentially owned by different applications, departments, companies, or industries. Notice that this description does not specify the mechanism through which those chunks of functionality are accessed. In fact, the term "service" isn't even mentioned, although it is implied.
From OOP to SOA
The road to SOA has been a progressive one--driven by the need to improve how developers build complex enterprise systems. The principals behind enterprise system design are far-reaching: from object-oriented programming to component-oriented programming to service-orientation. All three approaches share the common goal of encapsulation and reuse. With object-oriented programming, classes encapsulate functionality and provide code-reuse. To share classes between distinct applications or binaries, however, you have to copy the code, as shown in Figure1-2.
Figure 1-2. Duplicating types between components
Component-oriented programming introduces the concept of sharing binaries that encapsulate reusable classes. Initially, this was limited to the same machine until distribution was made possible with technologies like COM and DCOM, CORBA, and later Enterprise Java Beans (EJBs) and .NET Remoting. Although these technologies accomplish distribution in different ways the result is the same--binary components are activated over process and machine boundaries (see Figure 1-3 ).
Component-oriented programming has many limitations, but the most obvious is tight coupling to a specific technology. How can a Java client call a COM component? How can a .NET assembly invoke an EJB? It all boils down to protocols and messaging formats. Invoking a remote component of any kind requires serializing a message and passing it across applicable process or machine boundaries. Bridge technologies and adapters exist to transform messages from one technology into another, so that when the message arrives it can be understood and processed. The reverse happens as responses are fed back to the caller. This approach is cumbersome, however, sometimes introducing multiple transformations between clients and components--and sometimes not even possible. Instead of exposing components directly, components can be accessed through service boundaries to alleviate some of this pain (see Figure 1-4).
Figure 1-4. Exposing function through a service boundary
So, does service-orientation solve the problems inherent to component-oriented programming? It depends on where you sit on the meaning of service-orientation. I would definitely agree that in its purest form, service-orientation delivers a solution to these problems by introducing (via web services) the concept of contracts, policies, and interoperability. In that respect, applications can communicate with one another's services, as shown in Figure 1-5, without concern over the technology each employs. But you could also argue that service-orientation is an approach to development that implies the encapsulation of business components, data access, and data storage such that access is controlled through a top-level entry point. The package is a service, accessible over whatever protocols are supported, even if it lacks interoperability.
Figure 1-5.Consuming interoperable services
No matter how you define a service, the underlying point here is that to build an enterprise system, developers must be able to distribute chunks of functionality across process and machine boundaries to deal with performance bottlenecks, to introduce security boundaries, and to facilitate reuse. In addition, these chunks of functionality may be important to expose to other applications in a corporate ecosystem--which implies the potential need for interoperability on top of the rest.
This is an important question—and the answer varies depending on the context of the discussion. For example, a service is a logical term to SOA, but it has physical meaning to WCF. I’ll focus on the former in this section. According to the high-level definition of SOA, business functionality must be distributable and accessible in some way. The term service in this case refers to the entry point or “window” through which business functionality can be reached. Consider the application architecture illustrated in Figure 1-6. The client application represents an Agency Management System that includes many chunks of business functionality such as Certificate Issuance, General Ledger, CRM, and Reporting. In Figure 1-6, the client application coordinates access to these features by consuming business components directly. In this case, components are not distributable in such a way that they can be location transparent, thus they are not services.
Figure 1-6. Directly invoking business components
So, what constitutes a service in SOA terms? It could be a serviced component exposed using Enterprise Services, a .NET Remoting component, an ASMX web service, or a WCF service. Any of these technologies can be useful in exposing the business logic in such a way that the client can reach that functionality at remote locations in a distributed environment, without communicating directly with business components. Figure 1-7 illustrates the same services beneath the Agency Management System example from Figure 1-6, but this time each feature is exposed via one of the aforementioned technologies. Serviced components are reached using DCOM over TCP, .NET Remoting components via RPC over TCP, ASMX web services via SOAP over HTTP, and WCF services via SOAP over any protocol.
The point is that services are not necessarily web services—they are merely chunks of business functionality exposed in some way such that they respect the tenets of SOA.
Figure 1-7. Service boundaries implemented with different technologies
Although there is no official standard for SOA, the community seems to agree on four basic tenets as the guiding principles for achieving an SOA. They are:
Service boundaries are explicit.
Services are autonomous.
Clients and services share contracts, not code.
Compatibility is based on policy.
Let’s look at each of these in greater detail.
Service boundaries are explicit
Services are responsible for exposing a specific set of business functionality through a well-defined contract, where the contract describes a set of concrete operations and messages supported by the service. Services completely encapsulate the coordination of calls to business components in response to operations it exposes to clients, as Figure 1-8 illustrates. Implementation details behind the service are unknown to clients so that any technology platform could be invoked behind the service without impact to the client. In addition, the location of the service isn’t important to the client as long as the client knows where to reach it.
Enterprise Services, .NET Remoting, ASMX, and WCF all support this tenet. With Enterprise Services and .NET Remoting, the boundary and contract are defined by the public operations of the serviced component or remote component, respectively.
In the case of Enterprise Services, the contract is described as a type library, while with .NET Remoting the contract is a shared CLR interface. As for ASMX and WCF, contracts are described in Web Services Description Language (WSDL), an interoperable standard. All of these technologies also support location transparency in one respect or another. That is, the contract is independent of the location of the service in all cases.
Figure 1-8. Services encapulate business components and data access
Where WCF improves on earlier technologies in support of explicit boundaries is in the way contract design and deployment are handled. With WCF, you explicitly define the contract and opt-in every operation and data element that you intend to expose publicly. WCF also goes beyond location transparency with protocol transparency, meaning you can expose services over any number of protocols.
Services are autonomous
Services encapsulate business functionality, but they must also encapsulate other dependencies of the business tier. In this way the entire service should be moveable or even replaceable without impact to other services or system functionality as illustrated in Figure 1-9. As I mentioned before, a service represents a major chunk of business functionality that owns its own business components, data access components and data storage if applicable. It should be able to perform key functions without external dependencies. This is what is meant by atomicity.
Figure 1-9. Services are location transparent
Part of atomicity also dictates the following:
The service boundary must act as an independent unit for versioning. Changes to business components may require versioning the service contract, for example.
The service boundary is the deployment boundary for callers.
The service must operate in isolation and be fault-tolerant. That is, exceptions behind the service tier should not impact other services.
Atomicity is largely influenced by design, but WCF does enable atomicity by providing a clear approach to contract versioning, a flexible approach to deployment, and certainly handles fault isolation if services are hosted by the same process.
Clients and services share contracts, not code
Given the first SOA tenet, that service boundaries are explicit, it only makes sense that this boundary be the law as far as how clients interact with services. That means that the contract must not change once published, or must at a minimum remain backward compatible to existing clients—and this requires discipline.
In theory, contracts are not tied to a particular technology or platform, but this is not actually an official requirement of SOA—only a strong tendency. Thus, you could say that serviced components, ASMX web services, and WCF services all support this tenet since they all are capable of publishing a contract that is consumed by clients without sharing code (type libraries or WSDL, respectively). This is where .NET Remoting falls down, since it relies on sharing CLR types, a .NET-specific construct.
The beauty of WCF is that it uses interoperable contract definitions (WSDL) for all types of services--regardless of the communication protocols used to reach those services.
Compatibility is based upon policy
While contracts describe the business functionality available at a service boundary, policy describes other constraints, such as communication protocols, security requirements, and reliability requirements. Enterprise Services and .NET Remoting don't really have a way to publish such policy requirements, but ASMX with Web Services Enhancements (WSE) and WCF do. Policy is actually an extension to WSDL that can describe access constraints in a way that clients can be aware of them and invoke services in a compatible manner.
WCF support for policy is completely hidden from the developer--it is automatically included with the WSDL document based on how you configure WCF service for features such as security and reliability.
Please check back next week for the continuation of this article.
Introduction to WCF Concepts
