Web Services Architecture and Its Building Blocks

The Web services architecture is a technology stack that identifies standards-based application components, which ensures interoperability among Web services providers and requesters. It adopts service-oriented architecture (SOA) concepts using standards-based messages and communication protocols. Web-services architecture consists of many layers of interrelated logical components built using standards-based technologies. The logical components representing the layers provide standardized components and communication for defining and describing the services, discovering and subscribing to the services, transporting for service communication, aggregating a set of services, and collaborating with services. They also facilitate standards-based mechanisms for building end-to-end security, services provisioning and management, and delivering other QoS such as reliability, scalability, manageability, and availability.

Figure 6-1 depicts the Web services architecture technology stack with its different layers.

Figure 6-1. Technology stack of Web services architecture

Before jumping into the core standards and technologies of the technology stack, let's take a look at the fundamental operational model of Web services.

Web Services Operational Model

Web services can be conceptualized as a simple operational model with a standards-based communication model. The communication model uses three distinct roles and relationships that define Web-service providers and users. Figure 6-2, illustrates these relationships.

Figure 6-2. Web services operational model

The operational roles and relationships are defined as follows:

• Service provider: The service provider hosts the Web services and is primarily responsible for developing and deploying the Web services. The provider also defines the services and publishes them with the service registry.

• Service registry: The service registry hosts the lookup information and descriptions of published services and is primarily responsible for service registration and discovery of the Web services. The registry stores and lists the various service types, descriptions of the services, and locations of the services that help the service requesters find and subscribe to the required services.

• Service requester: The service requester acts as the Web services client, who is responsible for the service invocation. The requester locates the Web service using the service registry, invokes the required services, and executes them from the service provider.

Core Web Services Standards

A typical Web services architecture-based solution relies on de facto Web-services standards such as XML, SOAP, WSDL, and UDDI, and on industry-standard protocols such as HTTP and SMTP. These standards-based technologies form the foundation for building a Web services architecture and enabling Web services. Let's take a closer look at these standards, their role, and how they are represented in Web services architecture.

Extensible Markup Language (XML)

XML forms the basis for all Web-services standards. XML is endorsed by the W3C (World Wide Web Consortium) as a standard data format for structuring data and content, and for exchanging electronic documents. XML has already been widely accepted as the de facto universal language for exchanging information between applications, systems, and devices across the Internet. In the Web-services architectural model, XML plays a vital role as the common wire format in all forms of communication for expressing complex data structures. Another substantial benefit of XML is its ability to handle international character sets.

Simple Object Access Protocol (SOAP)

The Simple Object Access Protocol (SOAP) is a standard for a lightweight XML-based messaging protocol. In the core of Web-services communication, SOAP enables the exchange of information between two or more peers. SOAP enables them to communicate with each other in a decentralized, distributed application environment. SOAP provides transport bindings on top of various Internet protocols such as HTTP, SMTP, and FTP. SOAP uses XML as the message format and uses a set of encoding rules for representing data as messages. Although SOAP is used as a messaging protocol in Web services, it can also operate on a request-response model by exposing the application functionality using SOAP/RPC-based remote procedural calls. Like XML, SOAP is independent of the application object model, language, and running platforms or devices.

The structural format of a SOAP message contains the following elements, as illustrated in Figure 6-3:

• Envelope

• Header (optional)

• Body

• Attachments (optional)

Figure 6-3. Structure of a SOAP message

Figure 6-3 represents the structure of a SOAP message with attachments. Typically, a SOAP message is represented by a SOAP envelope and with zero or more attachments. The SOAP message envelope contains the header and body of the message, and the SOAP message attachments enable the message to contain data such as XML and non-XML data (like text or binary files). In a SOAP message, the SOAP header represents the processing semantics and provides mechanisms for adding features and defining high-level functionalities such as security, transactions, priority, and auditing. The SOAP body contains information defining an RPC call or business documents in XML, and any XML data required to be part of the message during communication. It is important to note that a SOAP message package is constructed using the MIME Multipart/Related structure to separate and identify the different parts of the message.

SOAP is endorsed by the W3C and key industry vendors such as Sun Microsystems, IBM, HP, SAP, Oracle, and Microsoft. These vendors have announced their support by participating in the W3C's XML Protocol Working Group. To find out the current status of SOAP from the activities of this group, refer to the W3C Web site at http://www.w3.org/2000/xp/Group/.

Web Services Definition Language (WSDL)

The Web Services Definition Language (WSDL) standard is an XML representation for describing the services as a collection of operations and its access information. In the core of the Web services architecture, WSDL plays a vital role as a metadata language for defining Web services. It describes how service providers and requesters communicate with one another. WSDL describes the Web-services functionalities offered by the service provider, where the service is located, and how to access the service. Usually, the service provider creates Web services by generating WSDL from its exposed business applications. A WSDL definition represents the following about a Web service:

• Operations and interfaces describing the exposed functions.

• Data types to represent the requests and responses of messages.

• Binding information about the protocol to be used for accessing the specified Web service.

• Address for locating and invoking the specified Web service.

Once the WSDL definition is created, the public WSDL address for lookup is published in a Web-services registry such as UDDI (see the following section) so that potential users of the Web service can determine the location of the Web service, the function calls that it supports, and how to invoke these calls. The Web-service requesters use this WSDL information to build the SOAP requests or any other type of request based on the supported binding protocol to invoke the Web service. WSDL is endorsed by the W3C as a standard. To find out more about WSDL and its current status, refer to the official W3C Web site for WSDL at http://www.w3c.org/TR/wsdl/.

Universal Description, Discovery, and Integration (UDDI)

Universal Description, Discovery, and Integration (UDDI) defines standard interfaces and mechanisms for use by the electronic registries that store and publish descriptions of XML-based Web services. UDDI is quite similar to the "Yellow Pages" or a telephone directory in which business services and products are classified and listed. UDDI allows the registering and categorizing of Web services in a general-purpose registry that users communicate with to discover and locate registered services. Querying a UDDI registry for a service returns the location of the WSDL descriptions that set forth the service interfaces of a Web services provider. Using the WSDL description, the service requester can construct a SOAP client interface that can communicate with the service provider. By communicating with UDDI registries, the service requesters query for services, locate services, and then invoke them by sending SOAP messages. The UDDI registries can be either private (within an organization) or public (servicing the whole Internet community). UDDI is endorsed by OASIS as a standard. To find out more information about UDDI and its current status, refer to the official OASIS Web site for UDDI at http://www.oasis-open.org/committees/uddi-spec/tcspecs.

Web Services Communication Styles

The Web services architecture revolves around the interaction models based on the message representation and interaction. The message representation and interaction models focus on the message structure in terms of mechanisms for message routing and delivery using RPC or document-based communications. These interaction models use synchronous or messaging-based synchronous or asynchronous communication, which need to be understood before Web services are designed and implemented.

RPC Style Web Services

The RPC-based communication model defines a requestresponse-based synchronous communication. When the client initiates a request, the client sends a SOAP message that provides parameters in method calls to the services exposed by the server. The clients invoke the services by sending parameter values to the services that execute the required methods in the server, which then sends back the return values. The server receiving the request translates it into the back-end application method or object. The client waits until a response is sent back before continuing any operation. It is quite similar to implementing CORBA or RMI communication.

Document Style Web Services

With document style interaction, XML documents are transmitted between the client service requester and the services provider. The XML documents exchanged do not map to back-end method calls of the service provider or the requester. In a typical scenario, the client service requester sends a message that include the business document to the Web service provider rather than sending a set of parameters or procedural calls. The service provider receives the document, processes it, and then may or may not return a message. The document style communication is typically used in conjunction with asynchronous messaging protocols to provide guaranteed and reliable message delivery and to support multi-hop communication based on intermediaries.