Principles of SOAP Web Services

Unfortunately there is no unique or exact definition which exactly explains what a Web Service really is.

In the UDDI² section in [WAL02], Web Services are defined thus: ``A Web Service is a self-describing, self-contained, modular unit of application logic that provides some business functionality to other applications through an Internet connection. Applications access Web Services via ubiquitous web protocols and data formats, such as HTTP and XML, with no need to worry about how each Web Service is implemented. Web Services can be mixed and matched with other Web Services to execute a larger work flow or business transaction.''

[LIV02] uses a far simpler explanation: ``A Web Service is the name for a method or function that is available for other applications to access over the Internet.''

According to Mark Colan (IBM), Web Services are ``Internet-based modular applications that perform a specific business task and conform to a specific technical format.''

Another definition would be that a Web Service is simply a node of a distributed computing environment. To clarify things, here is a typical example where the use of a Web Service makes sense:

A software company develops a banking application that has to handle multiple currencies. The conventional way would be to implement some kind of currency converter function and store the required exchange rates somewhere in the application as depicted in figure 6. The problem with this approach is that the exchange rates have to be updated regularly, new currencies have to be added from time to time and program code like the conversion algorithms have to be maintained.

Figure 6: Conventional implementation of a banking application with a built-in currency converter.

The Web Service approach offers a different way of dealing with the situation. The programmer does not implement the needed functions himself, but tries to locate an existing and appropriate Web Service that fulfills his needs. Therefore the programmer first looks at a central Web Services registry, called ``UDDI Business Registry''. One can picture this registry as some kind of yellow pages which not only hold information about the business that provides the service but also a technical description and the technical location, such as a URL. Once the software developer has found a Web Service which implements fully functional currency functions, he contacts the company which operates the Web Service and gains the right to use it for his application.

The next step for the programmer is to access the Web Service from his application. The Web Service approach implements a special language, called ``WSDL''³, which is used to define the technical details of a Web Service. Special tools can directly generate source code from these definitions. Hence the programmer downloads the WSDL file and generates the needed code which he can then integrate into his application.

In this manner, the banking application uses the Web Service for all currency issues as shown in figure 7, which greatly reduces the maintenance and therefore also the costs. The updating of currency exchange rates and the maintenance of the currency functions are done by the Web Service provider.

Figure 7: Banking application accessing a Web Service providing currency functions.

As seen from the above, the developer does not have to cope with SOAP. SOAP is fully transparent, it is used for the actual transmission of data between the application and the Web Service. Although this process is invisible to the developer and user, SOAP has an important role in the Web Service model. Every piece of data that travels between a Web Service and a client program is embedded in SOAP packages and there are many requirements that SOAP must fulfill. This will be described later in this chapter.

The example shows that Web Services are a unique approach to distributed computing, which is a key feature for many businesses, especially for those offering services on the Internet. A short analysis of well known web sites, such as Yahoo or Google, shows that the pages are composed of content that emerges from many sources. To give an example, a news service like CNN offers its content via a Web Service, perhaps as a so-called RSS⁴ news feed, and other web sites can then query this service and embed the news headlines in their pages.

From a technical perspective, distributed computing is not new, hence there are already a lot of protocols and programming frameworks that simplify the implementation of distributed computing environments. The idea of all these programming environments is to hide the actual transmission between the computing nodes from the programmer and let him call remote procedures just as he would call local routines. The implementation of this simplification relies on abstract interface definition languages (``IDL'') which enable programmers to describe and define interfaces between the computing nodes. These IDL definitions can then be used to generate source code, called stubs or skeletons that can then be integrated into applications which deal with the communication between computing nodes. This communication between the nodes is transparent to the user and relies on specific communication protocols which enable passing data, function parameters or serialized objects between the distributed nodes. Here is a short overview of the most common distributed computing environments which can be regarded as predecessors of SOAP Web Services:

Sun/ONC RPC:

This is one of the oldest distributed computing environments and dates back to 1988. It concentrates on remote procedure calls (RPC) and was developed by the Sun Microsystems Open Network Computing (ONC) group. It provides its own language, called ``RCP Language'', which is used to generate stubs by a specific compiler called ``rpcgen''. ONC RPC uses a simple request/response communication protocol and is limited to TCP and UDP⁵. Although it is quite old and has several limitations it is still quite popular as it is distributed with most UNIX operating systems. Moreover, the well known network file system ``NFS'' utilizes ONC RPC. Further information about ONC RPC can be found in [BLO91].

DCE:

The ``Distributed Computing Environment'' (DCE) is a more recent approach than ONC RPC and already implements a feature rich IDL bundled with a compiler that generates stubs. Like ONC RPC, it has a specific protocol which relies on a simple request/response architecture. DCE is developed by a vendor-neutral, international consortium called the ``Open Group''. DCE not only implements RPC, it also provides directory services (CDS/GDS), distributed file service (DFS) and more. An introduction to DCE is given in [BLO91].

CORBA:

The Common Object Request Broker Architecture (CORBA) is an attempt to standardize distributed computing between a wide range of platforms and application environments. CORBA utilizes a so-called ``Object Bus'', called ``ORB'' which provides the communication infrastructure to send and receive requests and responses between distributed computing nodes. CORBA also utilizes an IDL which is platform and programming language independent and is used to generate stubs which are then integrated into applications. CORBA also implements a specific protocol, called IIOP which is used for all transfers between computing nodes. Due to its platform independence, CORBA has been widely adopted by the industry but suffers from its complexity and high initial investments regarding the training and deployment of this architecture. An in-depth analysis of CORBA can be found in [TAR01].

DCOM:

The origin of this protocol lies in the development of a communication protocol (COM) between Microsoft Windows applications. The next step was the ``Distributed Component Object Model'' or DCOM which provides a distributed computing environment for the Microsoft Windows platform. DCOM will over time be replaced by Microsoft's .Net initiative which relies heavily on SOAP Web Services. Further information about DCOM can be found in [RED97].

Java RMI:

This is a Java specific Framework developed by SUN Microsystems for implementing distributing computing in a Java environment. It utilizes a specific protocol, called JRMP. Moreover, it also embraces CORBA through an additional protocol called RMI-IIOP that provides interoperability with CORBA components. Further information on Java RMI can be found in [GRO01].

XML-RPC:

XML-RPC is not a framework like the ones listed above, but it is a simple XML-based RPC protocol which is standardized by the W3C consortium and is a viable alternative to SOAP. It is quite popular due to its simplicity and is utilized by many applications that use this protocol for RPC calls. An in-depth description of this protocol is given in [LAUR01]

All of these protocols have their strengths and weaknesses, some do not scale very well, others are difficult to implement and to debug and others are simply not broadly accepted. Therefore these techniques are not fully satisfactory for a broadly acceptable distributed computing environment.

The industry in cooperation with W3C⁶ focuses on a holistic solution to this problem by specifying several standards that build a framework for providing and interconnecting services in an open and well defined way. Most of these standards are based on XML⁷. Services that use this framework are called ``Web Services''.

A distributed computing environment like a SOAP Web Service has to fulfill many requirements. The W3C consortium has reduced these demands to three basic needs:

1. Locating Web Services or Web Service providers.
2. Describing the Web Service in a common, extensible way.
3. Representing the message in a common, extensible format.

For these key requirements the W3C has created three standards in cooperation with the industry : UDDI, WSDL and SOAP, which will be described in the next sections. These standards are all based on XML and form the basic framework for Web Services. These technologies and their underlying protocols can be applied to the OSI reference model⁸ as shown in figure 8.

Figure 8: Web Service Technologies in the OSI Reference Model