To get a sense of the problems that WCF addresses, suppose that a car rental firm decides to create a new application for reserving cars. Since this application will run on Windows, the firm chooses to build it on the .NET Framework 4. The architects of this rental car reservation application know that the business logic it implements will need to be accessible by other software running both inside and outside their company. Accordingly, they decide to build it in a service-oriented style, with the application’s logic exposed to other software through a well-defined set of services. To implement these services, the new application will use WCF. Figure 1 illustrates this situation.
Over its
lifetime, the rental car reservation application will likely be accessed by a
range of other applications. When it’s designed, however, the architects of the
rental car reservation application know that its business logic will be
accessed by three other kinds of software:
- A client application running on Windows desktops that will be used by employees in the organization’s call center. Created specifically for the new reservations system, this application will also be built using the .NET Framework 4 and WCF. (In some sense, this application isn’t truly distinct from the new rental car reservation application, since its only purpose is to act as a client for the new system. Still, from a service-oriented perspective, it’s just another client for the reservation system’s business logic.)
- An existing reservation application built on a Java Platform, Enterprise Edition (Java EE) server running on a non-Windows system. Due to a recent merger with another car rental firm, this existing system must be able to access the new application’s logic to provide customers of the merged firms with a unified experience.
- Partner applications running on a variety of platforms, each located within a company that has a business arrangement with the car rental firm. Partners might include travel agencies, airlines and others that are required to make car rental reservations.
The diverse
communication requirements for the new rental car reservation application
aren’t simple. For interactions with the call center client application, for
instance, performance is paramount, while interoperability is straightforward,
since both are built on the .NET Framework. For communication with the existing
Java EE-based reservation application and with the diverse partner
applications, however, interoperability becomes the highest goal. The security
requirements are also quite different, varying across connections with local
Windows-based applications, a Java EE-based application running on another operating
system, and a variety of partner applications coming in across the Internet.
Even transactional requirements might vary, with only the internal applications
being allowed to use distributed atomic transactions. How can these diverse
business and technical requirements be met without exposing the creators of the
new application to unmanageable complexity?
The answer to
this question is WCF. Designed for exactly this kind of diverse but realistic
scenario, WCF is becoming the default technology for Windows applications that
expose and access services. This paper introduces WCF, examining what it
provides and showing how it’s used. Throughout this introduction, the scenario
just described will serve as an example. The goal is to make clear what WCF is,
illustrate the problems it addresses, and show how it solves those problems.
WCF is
implemented primarily as a set of classes on top of the .NET Framework’s Common
Language Runtime (CLR). This lets .NET developers build service-oriented
applications in a familiar way. As Figure 2 shows, WCF allows creating clients
that access services. Both the client and the service can run in pretty much
any Windows process—WCF doesn’t define a required host. Wherever they run, clients
and services can interact via SOAP, via a WCF-specific binary protocol, and in
other ways.
As the
scenario described earlier suggests, WCF addresses a range of problems for
communicating applications. Three things stand out, however, as WCF’s most
important aspects:
- Unification of the original .NET Framework communication technologies
- Interoperability with applications built on other technologies
- Explicit support for service-oriented development.
The following
sections describe what WCF offers in each of these areas.
Unification of Microsoft’s Distributed Computing Technologies
Think about
the team of developers implementing the rental car reservation application
described earlier. In the world before WCF, this team would need to choose the
right distributed technology from the multiple choices originally offered by
the .NET Framework. Yet given the diverse requirements of this application, no
single technology would fit the bill. Instead, the application would probably
use several of these older .NET technologies. For example:
- ASMX, also called ASP.NET Web Services, would be an option for communicating with the Java EE-based reservation application and with the partner applications across the Internet. Given that Web services are widely supported today, this would likely be the most direct way to achieve cross-vendor interoperability.
- .NET Remoting is a natural choice for communication with the call center application, since both are built on the .NET Framework. Remoting is designed expressly for .NET-to-.NET communication, so it would offer the best performance for this situation.
- Enterprise Services might be used by the rental car reservation application for things such as managing object lifetimes and defining distributed transactions. These functions could be useful in communicating with any of the other applications in this scenario, but Enterprise Services supports only a limited set of communication protocols.
- Web Services Enhancements (WSE) might be used along with ASMX to communicate with the Java EE-based reservation application and with the partner applications. Because it implements more advanced SOAP-based standards, known collectively as the WS-* specifications, WSE can allow better security and more, as long as all applications involved support compatible versions of these specifications.
- System.Messaging, which provides a programming interface to Microsoft Message Queuing (MSMQ), could be used to communicate with Windows-based partner applications that weren’t always available. The persistent queuing that MSMQ provides is typically the best solution for intermittently connected applications.
- System.Net might be used to communicate with partner applications or perhaps in other ways. Using this approach, developers can create applications that use the HTTP-based communication style known as Representational State Transfer (REST).
If it were
built on an earlier version of the .NET Framework, the rental car reservation
application would need to use more than one of these communication
technologies, and maybe even all of them, to meet its requirements. Although
this is technically possible, the resulting application would be complex to
implement and challenging to maintain. A better solution is needed.
Enterprises
today typically have systems and applications that were purchased from a range
of vendors. In the rental car application, for instance, communication is required
with various other software applications written in various languages and
running on various operating systems. This kind of diversity is a reality in
many organizations, and it will remain so for the foreseeable future.
Similarly, applications that provide services on the Internet can be built on
any platform. Clients that interact with them must be capable of communicating
in whatever style is required.
WCF-based
applications can work with other software running in a variety of contexts. As
shown in Figure 4, an application built on WCF can interact with all of the
following:
- WCF-based applications running in a different process on the same Windows machine
- WCF-based applications running on another Windows machine
- Applications built on other technologies, such as Java EE application servers, that support standard Web services. These applications can be running on Windows machines or on machines running other operating systems, such as Sun Solaris, IBM z/OS, or Linux.
To allow more than just basic communication, WCF implements Web services technologies defined by the WS-* specifications. All of these specifications were originally defined by Microsoft, IBM, and other vendors working together. As the specifications have become stable, ownership has typically passed to standards bodies such as the Organization for the Advancement of Structured Information Standards (OASIS). As Figure 5 shows, these specifications address several different areas, including basic messaging, security, reliability, transactions, and working with a service’s metadata.
Sign up here with your email
ConversionConversion EmoticonEmoticon