Understanding the Web Service Framework

Web services represent a significant part of the .NET application architecture. In the .NET vision, developers can construct an application using multiple Web services that work together to provide data and services for the application. The Web service model is a general model for building applications for any operating system that supports communication over the Internet, as illustrated in Figure 9-2. This model is also referred to as a Service Oriented Architecture (SOA) .

Figure 9-2: A connected environment where Web services reach a variety of clients

A Web service is a piece of application logic that is accessible using standard Web protocols. The Web service framework combines the best aspects of component-based development and Web development. As components , Web services represent packaged functionality that can be reused without concern about how the service is implemented. As a Web solution, Web services are not accessed by distributed protocols, such as the Component Object Model (COM), Remote Method Invocation (RMI), or Internet Inter-ORB Protocol (IIOP). Web services are accessed by open Web protocols, such as HTTP(S) and XML.

You define a Web service interface in terms of the messages it sends and receives. You can implement Web service clients on any platform and in any programming language as long as they can send and receive the specified messages.

As mentioned, Web services depend upon a collection of open specifications to interoperate with clients on multiple platforms. These specifications define a standard way to represent data, format messages, describe services, and discover services and their providers.

Exploring the Web Service Specifications

The power behind Web services is in their interoperability with clients and other services existing on different platforms. Web services can achieve this interoperability only through published open standards, as illustrated in Figure 9-3. These standards describe Web services at all functional levels, including communication protocol, service description, and service discovery. (The following sections explain the protocols in Figure 9-3.)

Figure 9-3: Relationships between the Web service protocols

Specifying a Communication Protocol

The Hypertext Transmission Protocol (HTTP) is the fundamental transport technology that carries messages between a Web service and a client. HTTP has been adopted as the default transport protocol largely because of its popularity and flexibility. Because HTTP requests usually channel through socket port 80 for Web browser support, it is an ideal candidate for channeling services. You can also use HTTPS, the securely encrypted variation of HTTP, for Web service communication, but the encryption/decryption process significantly slows down the communication.

Note  

For additional information about the HTTP specification, see http://www.w3c.org/Protocols .

The Simple Object Access Protocol (SOAP) is an XML-based document that contains the messages that exchange data between a Web service provider and client. SOAP specifies the message header for request and response messages as well as the structure for the embedded data. Although SOAP is typically carried by the HTTP(S) protocol, there is no specific requirement for it. That is, any carrier protocol that the Web service client and server both understand can transport a SOAP message. The greatest benefit SOAP offers is that it has already been implemented on many different hardware and software platforms. You can use SOAP to link different systems within and outside of the enterprise. Many attempts to create a common communication protocol that could be used for systems integration have been attempted, but none of them have had the widespread adoption that SOAP has. This is because SOAP uses existing XML parsers and HTTP libraries to do most of the hard work.

Note  

You can find additional information on the SOAP specification on the W3C Web site at http://www.w3c.org/2000/xp/Group .

Describing Available Web Services

The Web Services Description Language (WSDL) is an XML-based document that describes the basic format of Web service requests and responses. WSDL describes what a Web service can do, where it resides, and how to invoke it. WSDL is to SOAP as the Interface Definition Language (IDL) is to the Common Object Request Broker Architecture (CORBA) or COM. However, because WSDL is represented in XML, it is readable and editable. Also, it is language independent and standards based. This makes it ideal for describing XML Web service interfaces that are also accessible from a wide variety of platforms and programming languages. In addition to describing message contents, WSDL defines where the service is available and what communication protocol talks to the service. This means that the WSDL file defines everything required to write a program to work with an XML Web service.

Note  

Additional information on the WSDL specification is available on the W3C Web site at http://www.w3.org/TR/wsdl .

Discovering Other Web Services

Universal Description, Discovery, and Integration (UDDI) is a platformindependent open framework for describing services, discovering businesses, and integrating business services using the Web. It is also referred to as the Yellow Pages of Web services . UDDI is driven by all major platform and software providers, as well as marketplace operators and e-business leaders . These technology and business pioneers are acting as the initial catalysts to quickly develop UDDI and related technologies. The UDDI protocol is the building block that will enable businesses to quickly, easily, and dynamically find and transact with one another using their preferred applications. A directory of Web services based on UDDI also includes several ways to search for the services you need to build your applications. For example, you can search for providers of a service in a specified geographic location or for businesses of a specified type. The UDDI directory will then supply information, contacts, links, and technical data to allow you to evaluate which services meet your requirements.

Note  

Additional information on the UDDI specification is available on the UDDI Web site at http://www.uddi.org/about.html .

Architecting Web Services in .NET

Web service clients are only concerned with the external interfaces of a Web service. As long as a client application can send and receive specified messages, it does not need to know anything about the internal workings of the Web service. From the enterprise developer perspective, a well-planned Web service architecture is critical to offering highly available and reliable Web services. Figure 9-4 shows an abbreviated version of the Web service architecture for the IssueTracker application.

Figure 9-4: The IssueTracker Web service architecture

This view of the IssueTracker application focuses on the five most relevant architectural layers . At the bottom of the architecture is the application database, which persistently manages all enterprise data. Sitting beside the database is the Data Access layer, which manages the data retrieval and storage functions. The Business Rules layer manages internal business objects and processes. The Business Facade layer provides a simple interface that maps Web service methods to internal business objects and processes. The Web Service layer is essentially a wrapper for the Business Facade layer that exposes functionality to Web service clients. The Business Facade layer interacts directly with the Business Rules and Data Access layers to deliver high-level functionality. Web service clients interact with the Web services through the Web service listener. The listener is responsible for receiving incoming messages containing requests for service, parsing the messages, and invoking the appropriate Web service method. If the Web service method returns a response, the listener is also responsible for packaging the response into a message and sending that back to the client. The listener also handles requests for contracts and other details about the Web service.

Note  

An emerging revenue stream for growing enterprises is to wrap existing data and services with a Web service layer and charge subscription access. However, supporting Web services requires a highly available and reliable environment. An enterprise application needs to be architected for sustaining the overwhelming load that Web services will bring.