Löwy J. - Programming WCF Services: Design and Build Maintainable Service-Oriented Systems

WCF Essentials

This chapter describes the essential concepts and building blocks of Windows Communication Foundation (WCF) and its architecture enabling you to build simple services. You will learn the basic terms regarding addresses, bindings, contracts, and endpoints; see how to host a service; learn how to write a client; understand related topics, such as in-process hosting (in-proc) hosting, reliability, and transport sessions; and see how to utilize WCF in Visual Studio. Even if you are already familiar with the basic concepts of WCF, I recommend that you give this chapter at least a cursory reading, not only to ensure that you have a solid foundation, but also because some of the helper classes and terms introduced here will be used and extended throughout the book.

WCF is a software development kit for developing and deploying services on Windows. I will describe what a service is in the next section. But WCF is much moreit is literally a better .NET. WCF provides a runtime environment for your services, enabling you to expose Common Language Runtime (CLR) types as services and to consume other services as CLR types. Although in theory you could build services without WCF, in practice, building services is significantly easier with WCF. WCF is Microsofts implementation of a set of industry standards defining service interactions, type conversions, marshaling, and the management of various protocols. Consequently, WCF provides interoperability between services.

WCF provides developers with the essential off-the-shelf plumbing required by almost all applications and, as such, it greatly increases productivity. The first release of WCF (as part of .NET 3.0) provided many useful facilities for developing services, such as hosting, service instance management, asynchronous calls, reliability, transaction management, disconnected queued calls, and security. The second release of WCF (as part of .NET 3.5) provided additional tools and extended the original offering with additional communication options. The third release (as part of .NET 4.0) included configuration changes, a few extensions, and the new features of discovery (discussed in Appendix C) and routers (not discussed in this book). With WCFs fourth release (as part of .NET 4.5), WCF has several new simplification features and additional bindings, including UDP and WebSocket bindings. WCF has an elegant extensibility model you can use to enrich the basic offering. In fact, WCF itself is written using this extensibility model. This book is dedicated to exploring these aspects and features.

WCF is part of .NET 4.5, so it can run only on operating systems that support it. Presently, this list consists of Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server and Windows 8 or later.

Most of the WCF functionality is included in a single assembly called System.ServiceModel.dll, located in the System.ServiceModel namespace.

Azure Service Bus

Microsoft originally designed the Azure Service Bus to solve the broad and challenging connectivity issues of consuming web services over the Internet.

The Azure Service Bus has since established itself as an indispensable tool for the modern developer who is creating connected systems on any platform. The Azure Service Bus has grown into a fully-fledged connectivity platform with a diverse set of features.

Recognizing that the challenges of providing service connectivity are not limited to the Internet, Microsoft has released an Intranet version of the Azure Service Bus named Service Bus for Windows Server. This version of the Service Bus targets the on-premises versions of Windows Server and SQL Server.

As a connectivity platform, the Service Bus offers a wide array of options for distributed computing solutions. These include service relay features, event publishing and subscription, persistent queues, and topics (queued events). The Service Bus also supports a modern, federated security model through claim-based access control. The Service Bus now supports a variety of programming models including classic WCF, REST-based and even AMQP (Advanced Message Queuing Protocol). From this set of building blocks developers can create even more sophisticated patterns that enhance the scalability, throughput, discoverability, availability and security of their solutions. The previous edition of this book devoted an in depth chapter and a number of appendix sections to the Service Bus, along with several extensions and original enhancements.

We consider the Service Bus nothing short of a fundamentally disruptive, essential platform for modern distributed computing. There is no question the Service Bus now merits a book in its own right to fully explore its many features and patterns in depth. We have therefore removed the chapters on the Service Bus from this edition. The material from those chapters will appear in greater and up-to-date detail in our forthcoming book dedicated to the Service Bus platform.

A service is a unit of functionality exposed to the world. In that respect, it is the next evolutionary step in the long journey from functions to objects to components to services. Service orientation (SO) is an abstract set of principles and best practices for building service-oriented applications. Appendix A provides a concise overview and outlines the motivation for using this methodology. The rest of this book assumes you are familiar with these principles. A service-oriented application aggregates services into a single logical application, similar to the way a component-oriented application aggregates components and an object-oriented application aggregates objects, as shown in .

Figure 1-1. A service-oriented application

The services can be local or remote, can be developed by multiple parties using any technology, can be versioned independently, and can even execute on different timelines. Inside a service, you will find concepts such as languages, technologies, platforms, versions, and frameworks, yet between services, only prescribed communication patterns are allowed.

The client of a service is merely the party consuming its functionality. The client can be literally anythingfor instance, a Windows Forms, WPF, Silverlight, or Windows Store App class, an ASP.NET page, or another service.

Clients and services interact by sending and receiving messages. Messages may be transferred directly from the client to the service or be sent via an intermediary such as the Azure Service Bus. With WCF, messages are SOAP messages. These messages are independent of transport protocolsunlike web services, WCF services may communicate over a variety of transports (not just HTTP). WCF clients may interoperate with non-WCF services, and WCF services can interact with non-WCF clients. That said, if you develop both the client and the service, you can typically construct the application so that both ends require WCF in order to utilize WCF-specific advantages.

Because the making of the service is opaque from the outside, a WCF service typically exposes metadata describing the available functionality and possible ways of communicating with the service. The metadata is published in a predefined, technology-neutral way, such as using WSDL (Web Services Description Language) over HTTP-GET or an industry standard for metadata exchange over any protocol. A non-WCF client can import the metadata to its native environment as native types. Similarly, a WCF client can import the metadata of a non-WCF service and consume it as native CLR classes and interfaces.