6.4 Web Services Technologies

6.4.1 Introduction

While XML is probably the best-known technology, there are several other technologies in the Web services area that play an integral role in making the services work and making them accessible over the network. In this section, we give a brief overview on SOAP, UDDI, and HTTPR. While SOAP is used for encapsulating messages between heterogenous systems, UDDI is used for the definition of services. While the technical details are not so important for the theme of this book, it is important to know on a high level how they work and what their role is. HTTPR is a new transport protocol, developed by IBM to make the transport more reliable.

6.4.2 SOAP

The Simple Object Access Protocol (SOAP) is a standard for encoding inter-machine function calls in XML so they can be passed among heterogeneous systems. It enables any client application to call a function on any server machine, no matter what operating system each is running or what language each is written in.

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML-based protocol that consists of the following elements:

• Envelope This defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory.

• Header An optional element that contains header information.

• Body The body element contains call and response information.

• Fault An optional element that provides information about errors that occurred while processing the message.

SOAP can potentially be used in combination with a variety of other protocols. IBM's SOAP Security Extensions add an XML Digital Signature for messaging authentication, element-wise encryption for confidentiality, and attribute certificates for authorization.

A SOAP envelope marks the beginning and ending of a SOAP message. It can also specify encoding rules for serializing or marshalling the data over the wire. A SOAP header might contain a mail-to address or addresses, a payment code, or information about an RPC-style ^[37] interaction. There may be several headers in a SOAP envelope or none at all. The SOAP message body carries the data formatted as either a self-describing structure or as an RPC-style interface.

^[37] RPC is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand network details.

Although these components are described together as part of SOAP, they are functionally orthogonal. In particular, the envelope and the encoding rules are defined in different namespaces to promote simplicity through modularity.

6.4.3 UDDI

UDDI (Universal Description, Discovery, and Integration) is a consortium formed by Microsoft, ^[38] IBM, ^[39] and Ariba ^[40] for creating a standard for the description, registration, and discovery of Web services.

^[38] http://www.microsoft.com/

^[39] http://www.ibm.com

^[40] http://www.ariba.com/

Within a more distributed model of the business part of the Internet, a flexible, open , yet comprehensive framework is required to embrace this diversity, encouraging agreement on standards, but also stimulating the innovation and differentiation that fuel the growth of e-business. The framework also needs to allow businesses to describe the business services that their Web sites offer, and how they can be accessed globally over the Web. A global solution must go beyond traditional directories, to also define standards for how businesses will share information, what information they need to make public, and what information they choose to keep private.

The resultant UDDI framework is "a set of databases where businesses can register their Web services as well as locate other Web services." ^[41] Applications use SOAP APIs to read or populate WSDL company profiles associated with UDDI. UDDI is a global, platform-independent, open framework to enable businesses to discover each other, define how they interact over the Internet, and share information in a global registry that will more rapidly accelerate the global adoption of e-business.

^[41] http://www.metagroup.com/cgi-bin/inetcgi/search/displayArticle.jsp?oid=22261

The UDDI specification provides a common set of SOAP APIs that enable the implementation of a service broker. The UDDI specification was outlined to help facilitate the creation, description, discovery, and integration of Web-based services. The motivation behind UDDI.org, ^[42] a partnership and cooperation of more than seventy industry and business leaders , is to define a standard for Business-To-Business (B2B) service interoperability.

^[42] http://www.uddi.org/

UDDI has been organized as a sort of Yellow Pages for the Web, accessed via WSDL (a template for company information). WSDL supports ebXML registry features, which are similar to those of UDDI. In addition to competing with UDDI's database features, the Web services part of ebXML was once considered in competition with the SOAP standard. Fortunately, that debate was settled when OASIS brokered an agreement to integrate SOAP into ebXML. Today, these protocols are both overlapping (UDDI and ebXML) and complementary (SOAP and ebXML).

The solution is the creation of a service registry architecture that presents a standard way for businesses to build a registry, query other businesses, and enable those registered businesses to interoperate and share information globally in a distributed manner, just as the Internet was intended to be used. A Web services framework and public registry will enable buyers and sellers and marketplaces around the world to share information, connect Web services at low cost, support multiple standards, and prosper in the new digital economy.

UDDI is also a framework for Web services integration. It contains standards-based specifications for service description and discovery. The UDDI specification takes advantage of W3C and Internet Engineering Task Force (IETF) standards such as XML, HTTP, and Domain Name System (DNS) protocols. Additionally, cross-platform programming features are addressed by adopting early versions of the proposed SOAP messaging specifications found at the W3C Web site.

6.4.4 HTTPR

As HTTP unfortunately does not provide any QoS, an extension protocol is required to support the reliable transport of messages from one application program to another over the Internet, even in the presence of failures either of the network or the agents on either end. HTTPR is such a protocol. It is layered on top of HTTP. Specifically, HTTPR defines how metadata and application messages are encapsulated within the payload of HTTP requests and responses. HTTPR also provides protocol rules that make it possible to ensure that each message is delivered to its destination application exactly once or is reliably reported as undeliverable. Smart agents can use the HTTPR protocol and some persistent storage capability to provide reliable messaging for application programs.

Layering HTTPR on HTTP in this way has the additional benefit that HTTPR can be used for reliable messaging with enterprises whose only presence on the Internet is a Web server behind a firewall admitting only Web- related traffic. Given the asymmetries of HTTP (client connects to server, client sends request, server sends response), it will be convenient to use the terms "client" and "server" even though messaging agents may, in other senses, regard themselves as peers. The agent initiating an HTTPR interaction does so by sending a POST command, in the HTTP sense, including with it a payload that identifies itself, specifies an HTTPR command and, if the command asks the server to accept messages, includes a batch of messages.

The server sends back a response, whose payload includes status information and, if the client requested , a batch of messages intended for that client. The messages, and any accompanying meta data, are uninterpreted bytes as far as HTTPR is concerned and are assigned no other meaning by it.

Each batch is assigned an identifier by its sender (either client or server), which is sent along as HTTPR metadata with the batch. Correctly functioning messaging agents will, in accordance with the specification, store this identifier and the state of their processing of that batch of messages, in stable storage at the appropriate times. In the event of a failure, this information can be recovered from stable storage and used by the messaging agents, through specified interchanges of that state information, to resolve the status of the batch of messages, thereby achieving exactly-once delivery.

6.4.5 BEEP

BEEP (Blocks Extensible Exchange Protocol) is an Internet standardstrack protocol framework for Internet applications. BEEP can be considered a turbocharger for Internet applications that offers advanced features such as a standard application layer that supports dynamic, pluggable application "profiles." It has peer-to-peer, client-server, or server-to-server capabilities, and supports multiple channels over a single authenticated session. It also provides support for arbitrary MIME payloads, including XML.

BEEP gives network developers what they've long needed. It is a standard toolkit for building protocols quickly and conveniently. This means that new standard protocols can be easily developed and introduced. If you need to design a protocol that really fits your application, BEEP can create it. BEEP provides a readily available set of building blocks for use in designing network protocols, solving common issues and letting developers focus on the specifics of their own protocol rather than reinventing the wheel.

6.4.6 Summary

If you look at the different applications based on XML, you can see how they lay the foundation for me-centric computing by providing a lot of base services that are required to support the service and information exchange on a platform-independent level.