SOA Standards

WSDL

How does a client know what format to use in making a request to a service? For that matter, how do the client and the service know what the request means? The answers to these questions are provided by information in an XML document, called a WSDL document, that contains a description of the web service's interface. A WSDL document contains information specified in Web Service Description Language (WSDL), as defined in the WSDL specification. WSDL defines an XML schema for describing a web service. To uncover the description for a Web service, a client needs to find the service's WSDL document. One way, perhaps the most typical way, to do this is for the client to find a pointer to the WSDL document in the web service's registration, which can be in a UDDI registry or an ebXML registry/repository. A typical scenario is that a business registers its service. The registry entry includes a pointer to a WSDL file that contains the WSDL document for the service. Another business searches the registry and finds the service. A programmer uses the interface information in the WSDL document to construct the appropriate calls to the service.

A WSDL document describes a web service as a collection of abstract items called "ports" or "endpoints." A WSDL document also defines the actions performed by a web service and the data transmitted to these actions in an abstract way. Actions are represented by "operations," and data is represented by "messages." A collection of related operations is known as a "port type." A port type constitutes the collection of actions offered by a web service. What turns a WSDL description from abstract to concrete is a "binding." A binding specifies the network protocol and message format specifications for a particular port type. A port is defined by associating a network address with a binding. If a client locates a WSDL document and finds the binding and network address for each port, it can call the service's operations according to the specified protocol and message format.

Here, for example, is a WSDL document for an online book search service. Notice in the example that the WSDL document specifies one operation for the service: 

getBooks:

<operation name="getBooks" ...

The input message for the operation, BookSearchInput contains a string value named isbn:

<complexType>

    <all>

       <element name="isbn"

       type="string"/>

    </all>

The output message for the operation, BookSearchOutput returns a string value named title:

<complexType>

    <all>

       <element name="title"

             type="string"/>

    </all>

Notice too that the WSDL document specifies a SOAP protocol binding. The style attribute in the binding element specifies that the receiver should interpret the payload in the SOAP message as an RPC method call:

<soap:binding
     transport="transport=http://schemas.xmlsoap.org/soap/http"
     style="rpc"/>

Alternatively, the style attribute in a bindingelement could specify "document".
In that case, a complete document (typically an XML document) would be exchanged in the call. In fact, the document style of binding is more typical of services in an SOA. One of the advantages of passing an XML document to a service instead of an RPC-style message is that it tends to be easier to validate and to apply business rules.

SOAP

Though agreeing on the meaning and structure of XML tags makes the use of XML an effective way to exchange data, it's not sufficient for data interchange over the Web. For instance, you still need some agreed-upon protocol for formatting an XML document so that the receiver understands what the main, "payload," part of the message is, and what part contains additional instructions or supplemental content. That's where Simple Object Access Protocol (SOAP) comes in. SOAP is an XML-based protocol for exchanging information in a distributed environment. SOAP provides a common message format for exchanging data between clients and services. The basic item of transmission in SOAP is a SOAP message, which consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. The envelope specifies two things: an XML namespace and an encoding style. The XML namespace specifies the names that can be used in the SOAP message. Namespaces are designed to avoid name clashes -- the same name can be used for different items, provided that the names are in different namespaces. The encoding style identifies the data types recognized by the SOAP message. If a header is provided, it extends the SOAP message in a modular way. It's important to understand that as a SOAP message travels from a client to a service, it can pass through a set of intermediate nodes along the message path. Each node is an application that can receive and forward SOAP messages. An intermediate node can provide additional services such as transform the data in the message or perform security-related operations. The SOAP header can be used to indicate some additional processing at an intermediate node, that is, processing independent of the processing done at the final destination. Typically, the SOAP header is used to convey security-related information to be processed by runtime components. The body contains the main part of the SOAP message, that is, the part intended for the final recipient of the SOAP message.

Here's an example of a SOAP message designed to retrieve the price of a book. Notice the <SOAP-ENV: Envelope>, <SOAP-ENV:Header> and <SOAP-ENV: Body> elements that mark the envelope, header, and body parts of the SOAP message, respectively. The attribute value must Understand=1 in the header means that the receiver of the SOAP message must process it.

<SOAP-ENV: Envelope

  xmlns:SOAP-ENV=

    "http://schemas.xmlsoap.org/soap/envelope/"

  SOAP-ENV:

    encodingStyle=

      "http://schemas.xmlsoap.org/soap/encoding/">

        <SOAP-ENV:Header>

           <t:Transaction xmlns:t="some-URI">

              SOAP-ENV:mustUnderstand="1">

           </t:Transaction>

        </SOAP-ENV:Header>

        <SOAP-ENV:Body>

           <m:GetBookPrice xmlns:m="some-URI">

              <title>My Life and Times</title>

              <author>Felix Harrison</author>

           </m: GetBookPrice>

        </SOAP-ENV:Body>

</SOAP-Envelope>

A related standard, SOAP Messages With Attachments, specifies the format of a SOAP message that includes attachments (such as, images). SOAP messages (with or without attachments) are independent of any operating system or platform and can be transported using a variety of communication protocols, such as HTTP or SMTP. WS-I Basic Profile 1.0 references SOAP 1.1.

UDDI :

As mentioned earlier, an SOA can also include a service that provides a directory or registry of services. But how can a service be described in a registry so that a program looking for that service can easily find it and understand what it does? The Universal Description, Discovery, and Integration (UDDI) specifications define how to publish and discover information about services in a UDDI-conforming registry. More specifically, the specifications define a UDDI schema and a UDDI API. The UDDI schema identifies the types of XML data structures that comprise an entry in the registry for a service. Think of a UDDI registry as a "Yellow Pages" for web services. Like the Yellow Pages directory for phone numbers, a UDDI registry provides information about a service such as the name of the service, a brief description of what it does, an address where the service can be accessed, and a description of the interface for accessing the service. The accompanying figure illustrates the schema. It shows the five types of XML data structures that comprise a registration.

Here is an example that shows part of a complete BusinessEntity structure for a hypothetical company named BooksToGo. The company provides various web services, including an online book ordering service.

<businessEntity businessKey="35AF7F00-1419-11D6-A0DC-000C0E00ACDD"
authorizedName="0100002CAL"
  operator="www-3.ibm.com/services/uddi">
<name>BooksToGo</name>
<description xml:lang="en">                                  
   The source for all professional books
</description>
<contacts>
<contact>
<personName>Benjamin Boss</personName>
<phone>
  (877)1111111
</phone>
</contact>
</contacts>

The API describes the SOAP messages that are used to publish an entry in a registry, or discover an entry in a registry. Here, for example, is a message that searches for all business entities in a registry whose name begins with the characters "Books":<find_business generic="2.0" xmlns=um:uddi-org:api-v2"><name>Books%</name></find_business>