-
karthickreddyk
  - Joined on 03-17-2008
- Bangalore
- Posts 7
- Points 30
|
Windows Communication Foundation
Introducing Windows Communication Foundation
KARTHICKREDDYK - ORACLE 26TH January 2010Describing Windows Communication FoundationThe move to service-oriented communication has changed software development. Viewing services as a distinct software abstraction is fundamental to service-oriented architecture (SOA), an approach that many organizations are putting in place today. Whether implemented using SOAP or in some other way, applications that interact through services are becoming the norm.Software development environments must keep pace with these changes. The benefits services bring should be reflected in the tools and technologies that developers use. Windows Communication Foundation (WCF), Microsoft’s technology for service-oriented applications, is designed to address these requirements. First released as part of the .NET Framework 3.0 in 2006, an updated version of this technology is included in the .NET Framework 3.5. For a large share of new software built on .NET, WCF is the right foundation.Illustrating the Problem: A Scenario
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 3.5. 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, and thus communicate with other software, the new application will use WCF. .jpg) 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, as shown in the figure above, by three other kinds of software:
- A call center 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 3.5 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 make transactional requests. 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 will be 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, show what problems it solves, and illustrate how it solves those problems. Addressing the Problem: What WCF ProvidesWCF is implemented primarily as a set of classes on top of the .NET Framework’s Common Language Runtime (CLR). Because it extends their familiar environment, WCF allows .NET developers to build service-oriented applications in a familiar way. As the figure below 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, or in some other way.
.jpg)
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 existing .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 TechnologiesThink 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 existing 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) could be used along with ASMX to communicate with the Java EE-based reservation application and with the partner applications. Because it implements more recently defined Web services agreements, 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 also be used to communicate with partner applications or perhaps in other ways. Using this interface, 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. .jpg) With WCF, this solution is at hand. As the figure above shows, WCF can be used for all of the situations just described. Accordingly, the rental car reservation application can use this single technology for all its application-to-application communication. Here’s how WCF addresses each of these requirements:
- Because WCF can communicate using Web services, interoperability with other platforms that also support SOAP, such as Java EE application servers, is straightforward.
- To allow 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 SOAP. Messages still conform to the data structure of a SOAP message, referred to as its Infoset, but their encoding uses a binary representation of that Infoset rather than the standard angle-brackets-and-text format of XML. Using this option would make sense for communicating with the call center client application, since it’s also built on WCF, and performance is a paramount 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 rental car reservation application can use them with any of the other applications with which it communicates.
- Because it supports a large set of the WS-* specifications, WCF helps provide reliability, security, and transactions when communicating with any platform that also supports these specifications.
- WCF’s option for queued messaging, built on MSMQ, allows applications to use persistent queuing without needing to use another set of application programming interfaces.
- The version of WCF in the .NET Framework 3.5 has built-in support for creating RESTful clients and services.
The result of this unification is greater functionality and, overall, less complexity. Because WCF allows an application to address all the communication requirements listed earlier, it can easily support scenarios that were difficult (or even impossible) with the collection of technologies that preceded it. While Microsoft still supports these earlier technologies, most new applications that would previously have used any of them should instead be built on WCF.Interoperability with Applications Built on Other TechnologiesReflecting the heterogeneity of most enterprises, WCF is designed to interoperate well with the non-WCF world. There are two important aspects of this: interoperability with platforms created by other vendors, and interoperability with the Microsoft technologies that preceded WCF. The following sections describe both.Interoperability with Other Web Services PlatformsEnterprises 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 the figure below, 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.
.jpg)
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 the figure below shows, these specifications address several areas, including basic messaging, security, reliability, transactions, and working with a service’s metadata. WCF supports all the specifications shown in this figure. Grouped by function, those specs are:
- Messaging: SOAP is the foundation protocol for Web services, defining a basic envelope containing a header and a body. WS-Addressing defines additions to the SOAP header for addressing SOAP messages, which frees SOAP from relying on the underlying transport protocol, such as HTTP, to carry addressing information. The Message Transmission Optimization Mechanism (MTOM) defines an optimized transmission format for SOAP messages based on the XML-binary Optimized Packaging (XOP) specification.
- Metadata: The Web Services Description Language (WSDL) defines a standard language for specifying services and various aspects of how those services can be used. WS-Policy allows specification of more dynamic aspects of a service’s behavior that cannot be expressed in WSDL, such as a preferred security option. WS-MetadataExchange allows a client to request descriptive information about a service, such as its WSDL and its policies, via SOAP.
- Security: WS-Security, WS-Trust and WS-SecureConversation all define additions to SOAP messages for providing authentication, data integrity, data privacy and other security features.
- Reliability: WS-ReliableMessaging defines additions to the SOAP header that allow reliable end-to-end communication, even when one or more SOAP intermediaries must be traversed.
- Transactions: Built on WS-Coordination, WS-AtomicTransaction allows using two-phase commit transactions with SOAP-based exchanges.
The rental car reservation application would likely use several of these more advanced technologies. For example, WS-Addressing is essential whenever SOAP is running over a protocol other than HTTP, which might be the case for communication with the .NET Framework-based call center client application. WCF relies on WS-Policy and WS-MetadataExchange to discover whether the system it’s communicating with is also using WCF and for other things. Reliable communication is essential for most situations, so it’s likely that WS-ReliableMessaging would be used to interact with many of the other applications in this scenario. Similarly, WS-Security and the related specifications might also be used for communication with one or more of the applications, since all would require some kind of security. For the applications that are allowed to use transactions with the rental car reservation system, WS-AtomicTransaction would be essential. Finally, MTOM could be used whenever an optimized wire format made sense, and both sides of the communication supported this option.The key point is that WCF implements interoperable SOAP-based Web services, complete with cross-platform security, reliability, transactions, and more. To avoid paying an unnecessary performance penalty, WCF-to-WCF communication can also be optimized—standard XML-based SOAP isn’t always required. In fact, as described later, it’s possible — easy, even — for a single application to expose its services to both kinds of clients.As mentioned earlier, the version of WCF that’s included in the .NET Framework 3.5 also supports the RESTful style of Web services. Rather than sending SOAP messages over HTTP, RESTful communication relies directly on HTTP’s built-in verbs: GET, POST, and others. While SOAP is the right approach in some situations, such as those requiring more advanced security or transactional services, RESTful communication is a better choice in others. Accordingly, WCF supports both approaches.Interoperability with Microsoft’s Pre-WCF TechnologiesMany of Microsoft’s customers have made significant investments in the .NET Framework technologies that WCF subsumes. Protecting those investments was a fundamental goal of WCF’s designers. Installing WCF doesn’t break existing technology, so there’s no requirement that organizations change existing applications to use it. An upgrade path is provided, however, and wherever possible, WCF interoperates with those earlier technologies. For example, both WCF and ASMX use SOAP, so WCF-based applications can directly interoperate with those built on ASMX. Existing Enterprise Services applications can also be wrapped with WCF interfaces, allowing them to interoperate with applications built on WCF. And because WCF’s persistent queuing relies on MSMQ, WCF-based applications can interoperate directly with non-WCF-based applications built using native MSMQ interfaces such as System.Messaging. In the rental car reservations application, software built using any of these earlier technologies could directly connect to and use the new system’s WCF-based services. Interoperability isn’t always possible, however. For example, even though WSE 1.0 and WSE 2.0 implement some of the same WS-* specifications as WCF, these earlier technologies implement earlier versions of the specs. Version 3.0 of WSE 3.0 does allow interoperability with WCF, but earlier versions do not. For more on interoperability with older .NET Framework technologies, see the section Coexistence and Upgrade later in this paper.Explicit Support for Service-Oriented DevelopmentCreating applications in a service-oriented style is becoming the norm. For this to happen, the platforms on which those applications are built must provide the right support for creating service-oriented software. Achieving this is one of WCF’s most important goals.Thinking of an application as providing and consuming services is hardly a new idea. What is new is a clear focus on services as distinct from objects. Toward this end, WCF’s creators kept four tenets in mind during the design of this technology:
- Share schema, not class. Unlike older distributed object technologies, services interact with their clients only through a well-defined XML interface. Behaviors such as passing complete classes, methods and all, across service boundaries aren’t allowed.
- Services are autonomous. A service and its clients agree on the interface between them, but are otherwise independent. They may be written in different languages, use different runtime environments, such as the CLR and the Java Virtual Machine, execute on different operating systems, and differ in other ways.
- Boundaries are explicit. A goal of distributed object technologies such as Distributed COM (DCOM) was to make remote objects look as much as possible like local objects. While this approach simplified development in some ways by providing a common programming model, it also hid the inescapable differences between local objects and remote objects. Services avoid this problem by making interactions between services and their clients more explicit. Hiding distribution is not a goal.
- Use policy-based compatibility. When possible, determining which options to use between systems should rely on mechanisms defined in languages such as WSDL and WS-Policy. The ability for a client to consume a service is based on the intersection of what the client supports and what the service supports.
Service-oriented applications are the successor to the multi-tier applications of the last decade. As the architectural style continues to spread, this approach is becoming the default for a large share of new software. WCF is the foundation for service-oriented applications built on the .NET Framework, which makes it a mainstream technology for Windows-based software.Using Windows Communication Foundation The best way to understand what it’s like to use WCF is to dive in and look at the code. This section shows what’s required to create and consume a simple WCF service. Once again, the service used as an example is drawn from the rental car reservation application described earlier.Creating a WCF ServiceAs the figure below shows, every WCF service has three primary components:
- A service class, implemented in C# or Visual Basic or another CLR-based language that implements one or more methods.
- A host process in which the service runs.
- One or more endpoints that allow clients to access the service. All communication with a WCF service happens via the service’s endpoints.
.jpg) Understanding WCF requires grasping all these concepts. This section describes each one, beginning with service classes.Implementing a Service ClassA service class is a class like any other, but it has a few additions. These additions allow the class’s creator to define one or more contracts that this class implements. Each service class implements at least one service contract, which defines the operations this service exposes. The class might also provide an explicit data contract, which defines the data those operations convey. This section looks at both, beginning with service contracts.Defining Service ContractsEvery service class implements methods for its clients to use. The creator of the class determines which of its methods are exposed as client-callable operations by specifying that they are part of some service contract. To do this, a developer uses the WCF-defined attribute ServiceContract. In fact, a service class is just a class that either is itself marked with the ServiceContract attribute or implements an interface marked with this attribute. Both options make sense in different situations, and both will be described shortly.First, however, here’s a short description of the class, called RentalReservations, that will be used as an example throughout this section. It’s an implementation of the basic functions in the car rental reservation application described earlier, and it has four methods:
- Check, which allows a client to determine the availability of a particular vehicle class at a certain location on specific dates. This method returns a Boolean value indicating whether there is availability.
- Reserve, which allows a client to reserve a particular type of vehicle at a certain location on specific dates. This method returns a confirmation number.
- Cancel, which allows a client to cancel an existing reservation by providing its confirmation number. This method returns a Boolean value indicating whether the cancellation succeeded.
- GetStats, which returns a count of how many reservations currently exist. Unlike the other methods in this class, GetStats can be invoked only by a local administrator, not by clients of the service.
Defining EndpointsAlong with defining operations in a service class and specifying a host process to run those operations, a WCF service must also expose one or more endpoints. Every endpoint specifies the following three things:
- An address indicating where this endpoint can be found. Addresses are URLs that identify a machine and a particular endpoint on that machine.
- A binding determining how this endpoint can be accessed. The binding determines what protocol combination can be used to access this endpoint along with other things, such as whether the communication is reliable and what security mechanisms can be used.
- A contract name indicating which service contract this WCF service class exposes via this endpoint. A class marked with ServiceContract that implements no explicit interfaces, such as RentalReservations in the first example shown earlier, can expose only one service contract. In this case, all its endpoints will expose the same contract. If a class explicitly implements two or more interfaces marked with ServiceContract, however, different endpoints can expose different contracts, each defined by a different interface.
An easy way to remember what’s required for WCF communication is to think of the ABCs of endpoints: address, binding, contract.Addresses are simple to understand—they’re just URLs—and contracts have already been described. Bindings are also a critical part of how communication is accomplished, and they’re worth further explanation. Suppose, for instance, that a service’s creator wishes to allow clients to access that service using either SOAP over HTTP or SOAP over TCP. Each of these is a distinct binding, so the service would need to expose two endpoints, one with a SOAP-over-HTTP binding and the other with a SOAP-over-TCP binding. To make bindings easier to use, WCF includes a set of predefined bindings, each of which specifies a particular group of options. Developers can configure these standard bindings if necessary, and they can also create wholly new custom bindings that provide exactly what a particular situation requires. Still, most applications will use one or more of the standard bindings that WCF provides. Among the most important of these are the following:
- BasicHttpBinding: Conforms to the Web Services Interoperability Organization (WS-I) Basic Profile 1.0, which specifies SOAP over HTTP. This binding can also be configured to use HTTPS as specified by the WS-I Basic Security Profile 1.0. It can also be configured to send either standard text or the optimized form defined by MTOM.
- WsHttpBinding: Uses SOAP over HTTP, like BasicProfileBinding, but also supports reliable message transfer with WS-ReliableMessaging, security with WS-Security, and transactions with WS-AtomicTransaction. This binding allows interoperability with other Web services implementations that also support these specifications.
- NetTcpBinding: Sends binary-encoded SOAP, including support for reliable message transfer, security, and transactions, directly over TCP. This binding can be used only for WCF-to-WCF communication.
- WebHttpBinding: Sends information directly over HTTP or HTTPS—no SOAP envelope is created. This binding is new with the .NET Framework 3.5 version of WCF, and it’s the right choice for RESTful communication and other situations where SOAP isn’t required. The binding offers three options for representing content: text-based XML encoding, JavaScript Object Notation (JSON) encoding, and opaque binary encoding.
- NetNamedPipesBinding: Sends binary-encoded SOAP over named pipes. This binding is only usable for WCF-to-WCF communication between processes on the same Windows-based machine.
- NetMsmqBinding: Sends binary-encoded SOAP over MSMQ, as described later in this paper. This binding can only be used for WCF-to-WCF communication.
Unlike attributes, which are part of a service’s source code, bindings can be different for different deployments of the same service. There are a few situations where this could be problematic, however. As described later, for instance, whether a service can join an existing transaction passed to it by a client is controlled using bindings. This distinction makes sense, since different deployments of the same service might need to set this value differently. But what if a particular service class always requires this behavior? To make sure that it’s available, a developer can mark the class with the BindingRequirements attribute, specifying that the ability to flow transactions must be provided by all bindings this class uses. If the BindingRequirements attribute is present, WCF will check at runtime to make sure that the service’s bindings provide the required behavior.
.jpg)
The figure above shows example values for each of the three elements in an endpoint for the second RentalReservations service class shown earlier. Assuming this service is hosted using either IIS or WAS, installed in the virtual directory reservation, and running on a machine named fabrikam.com, its address might be http://www.fabrikam.com/reservation/reserve.svc. The binding is BasicHttpBinding, and the name of the service’s contract is IReservations, which is the name of the interface that describes this service. Specifying Endpoints Unlike contracts, endpoints aren’t defined using attributes. It can sometimes be useful to specify endpoints in code, however, so WCF provides a way to do this. A service that is explicitly hosted in a ServiceHost object, for instance, can use this object’s AddEndpoint method to create an endpoint.
KARTHICK REDDY K
Software Ast,
ORACLE, Bangalore
|
|