Introduction to Web Services Part 2

In this second part of 'An Introduction to Web Services' we will look a little closer at the SOAP protocol and the Web Service Description Language.

As we said in Introduction to Web Services Part 1, a Web Service is basically an application that exposes a programmatic interface using standard, Internet-friendly protocols.

(To review: A protocol is basically an agreement between communicating parties on how that communication is to proceed. Most networks are organised as a series of layers or protocol hierarchies. Layers offer services to higher layers.  Programs invoking a Web service are called clients. SOAP over HTTP is the most commonly used protocol for invoking Web services.

An XML Web Service can be defined as a software service exposed on the Web through SOAP, and described with a WSDL file.

Technology
The technologies XML, XSD, SOAP, WSDL and UDDI are the building blocks of the Web Services platform.

The platform needs a minimum set of features to construct distributed applications. A platform must have a data representation format and type system. In order to achieve interoperability, the Web Services platform needs to supply a standard type system that works across different  type systems of different platforms, programming languages, and component models. The Web services platform has to provide a way of describing a Web service and providing the information needed to invoke it.

Finally, there must be a mechanism for invoking Web services remotely, similar to a Remote Procedure Call (RPC) protocol. To promote interoperability, this RPC protocol must be platform and programming language independent. This has been achieved by the technologies that make up the Web Services platform.

SOAP
SOAP was originally intended to be a cross-Internet form of DCOM or CORBA. The name of an early SOAP-like technology was "WebBroker" -- Web-based object broker. It made perfect sense to model an inter-application protocol on DCOM, CORBA, RMI etc. because they were the current models for solving inter-application interoperability problems.

SOAP version 1.2 provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding application defined data. This allows SOAP to be used in a large variety of systems ranging from messaging systems to remote procedure calls (RPC). 

SOAP relies on HTTP 1.0 or greater and can take advantage of the HTTP extension framework.

SOAP also relies on the core W3C XML recommendation.

While SOAP defines a framework for message structure it does not define messages types. WSDL may be used to describe the message types a Web service can send and receive.

RPC and Messaging
From the above paragraph we should understand that there are two common ways for Web service applications to communicate:

• Remote Procedure Calls (RPC)

• Messaging

Using RPC, the client is focused on invoking a remote procedure on the server. This usually involves instantiating a remote object and invoking its methods or properties. The focus is on the remote object and its interface, i.e. the properties, methods and parameters that it exposes. An example of an RPC mechanism is DCOM.

A more loosely coupled system is Messaging, where the client thinks in terms of sending a message to a server and receiving a response. The focus in messaging systems is on the request and response message format instead of the remote object’s interface. As the focus is only on message formats, the client and server are less tightly coupled than in the case of RPC.

RPC systems try to provide location transparency by exposing the remote object’s interface as if it were local and hide what’s going on the wire. In this way the client does not need to be concerned that the server object is on another machine. Alternatively, Messaging exposes what’s on the wire (i.e. the message) and hides what is on the other end. The client does not know how the server is implemented or how the message is processed.

However, it is possible to create a messaging server that invokes objects based on the messages it receives, effectively implementing RPC via messaging.  So, if the client is operating in terms of messages, it is messaging. If on the other hand the client is operating in terms of instantiating and invoking a remote object,  it is RPC.

When XML–based messaging is implemented , the focus will be mainly on the XML request and response messages.   While tools for building Web services do much of the work involved in XML messaging the data is still being sent as XML. This means that developers will often have to do some message manipulation themselves.  Therefore an understanding of XML and XML Schemas is essential to being effective at implementing XML messaging systems.

SOAP is an application-level protocol so it can work directly over a transport protocol such as TCP.

The Internet infrastructure is a maze of proxies and firewalls that more often than not has only HTTP traffic. So that all Internet-connected applications can communicate, SOAP must flow over the current Internet infrastructure. To achieve this SOAP can be layered over HTTP.

The SOAP message is sent as part of an HTTP request or response making it easy to communicate over any network that allows HTTP traffic.

In order to achieve platform independence and maximum interoperability, SOAP takes advantage of XML to represent messages exchanged between clients and Web services. By using HTTP and XML, SOAP allows communications between applications running on any platform and connected over the existing Internet infrastructure.

The simple architecture of SOAP is intended to encourage vendors to adopt and implement the protocol. While SOAP does not claim to solve all the problems associated with distributed applications communication, it does however establish the minimum standards required to send messages from one application to another. It does not for example, include specifications for security or distributed transactions, both of which are usually required for distributed applications. However, the SOAP architecture is flexible and extensible through the use of SOAP headers which I’ll discuss later in this chapter.

There is nothing in the architecture about accessing objects and invoking methods remotely as in a Remote Procedure Call. The emphasis is on sending a message from a sender to a recipient. In order to fully understand SOAP, we need to think in terms of messages exchanged between client and Web service. Using SOAP for RPC is simply a special application of messaging that combines two messages in opposite directions.

The SOAP Message
The SOAP message architecture consists of an Envelope which contains an optional Header and a mandatory Body. The Body itself contains the payload (the data being sent) and optional error information.

A basic SOAP message is a well-formed XML document consisting of an <Envelope> and <Body> elements that belong to the SOAP envelope namespace defined as http://schemas.xmlsoap.org/soap/envelope/.

SOAP Message Structure

• Request and Response Messages
    Request invokes a method on a remote object
    Response returns result of calling the method

SOAP specification defines an “envelope”
“envelope” wraps the message itself
Message is a different vocabulary and is application specific.
Namespace prefix is used to distinguish the two parts.

WSDL
We need a common language for describing Web Services. When providing a service,  we need to be able to describe it to the world, and if we want to use a service,  we have to be able to describe what we are looking for. WSDL was designed with this in mind.

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information (RPC – remote procedure call).

The operations and messages are described abstractly, and then bound to a network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).

As communications protocols and message formats are standardized in the web community, it is important to be able to describe the communications in a structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages.

WSDL stands for Web Service Definition Language. To successfully call a Web service you need to know how to get to the service, what operations the service supports, what parameters the service expects, and what it returns. WSDL provides all of this information in an XML document that can be read or machine-processed.

WSDL provides a way for service providers to describe the basic format of web service requests. It describes what a web service can do, where it resides, and how to invoke it.  While the claim of SOAP/HTTP independence is made in various specifications, WSDL assumes SOAP/HTTP/MIME as the remote object invocation mechanism. The registries in UDDI describe the various aspects of web services, including the binding details of the service.

In WSDL ,services are defined as collections of network endpoints or ports where the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings.  This separation allows for the reuse of abstract definitions of messages, which are abstract descriptions of the data being exchanged, and port types, which are abstract  collections of operations. The protocol and data format specifications for a particular port type constitute a reusable binding. A port is defined by associating a network address with a reusable binding; a collection of ports define a service. A WSDL document uses the following elements in the definition of network services:

SOAP Request Message
 

SOAP Response Message
 

This is part of the definition of a stock quote service. It defines a method called getLastTradePrice, with the associated SOAP information that enables a piece of code to find the service, invoke a method, and process the response

Conclusion
This has been a quick guide to the technologies SOAP and WSDL which are key technologies in Web Services.

Using the technologies outlined in these two documents we can see how Web services make integrating applications easier than other means of distributed computing such as DCOM (Distributed Component Object Model), RMI (Remote Method Invocation), and CORBA. These other means require compatible architectures from all participants to succeed. 

Web services allow businesses to extend existing systems to those of trading partners and customers without having to re-design existing back-end infrastructure. Web services carry the additional advantage of being universally accessible through Web-based directories allowing providers of Web services and potential customers to locate one another.

You can find the WSDL specification at www.w3.org/TR/wsdl.

The SOAP specification is available at www.w3.org/TR/soap12-part2/.

The W3C Web Services Activity page is at www.w3.org/2002/ws/.