Understanding Web Services Standards Stack

As it must be clear by now, Web services are built on top of the development of a number of standards. Figure 9.7 shows one view of the various standards stack around the development and deployment of Web services. TCP/IP is the basic foundation of the Internet, which uses HTTP/HTTPS as ubiquitous communication protocols. With the definition of Extensible Markup Language (XML), a ubiquitous markup language has been created to describe and tag data. XML Schemas have recently surfaced as a rich alternative mechanism to DTDs, to define XML data about data (metadata). SOAP is the first standards entry into the world of Web services. It defines a communication protocol using XML messages so that disparate systems can use the Web to communicate with each other. WSDL (Web Services Definition Language) provides metadata and description of SOAP-based Web services, and UDDI provides a standard registry and discovery mechanism to register, locate, and consume Web services.

Figure 9.7. Web services standard stack.

Exploring SOAP

SOAP (Simple Object Access Protocol) is a standard that defines a collection of XML messages that can be used for intrasystem communications. SOAP expands the World Wide Web, which has been traditionally used for information discovery and dissemination . SOAP allows the Web to be used as a common vehicle by systems to communicate with each other. SOAP services can be used internally within a department or a corporate intranet and communicated within corporate boundaries using HTTP; SOAP services also can be used to facilitate B2B communications by providing the basic communication protocol for extended enterprise-based integrations.

Because the message format is standardized and based on the XML standard, SOAP can be used to communicate among multiple computer architectures, languages, and operating systems. SOAP enables a new class of applications called Web services, which expose services in a standard way so that application developers can create new applications by putting together services from many different sources on the Web.

SOAP defines an XML Schema “based object model for three main objects ”SOAP envelope, SOAP header, and SOAP body. Sometimes it is useful to examine the various XML objects by looking behind the scenes at what happens when a client invokes the simple SOAP-based Web service, HelloService. This is the same service that you have developed and learned about earlier in the chapter.

The SOAP request:

 <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xmlns:xsd="http://www.w3.org/2001/XMLSchema"   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Body>     <sayHello xmlns="http://www.hiteshseth.com/webservices" />   </soap:Body> </soap:Envelope> 

The SOAP response:

 <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xmlns:xsd="http://www.w3.org/2001/XMLSchema"   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Body>     <sayHelloResponse xmlns="http://www.hiteshseth.com/webservices">       <sayHelloResult>string</sayHelloResult>     </sayHelloResponse>   </soap:Body> </soap:Envelope> 

Describing Web Services Using WSDL

SOAP provides a standard way for systems to communicate with each other using the ubiquitous Internet protocols HTTP/HTTPS. Now, no service consumer would be able to use Web services seamlessly unless he or she knows the exact specification or metadata about the SOAP service. WSDL, a specification developed by the UDDI group and also submitted to the W3C, provides such a way through an open XML-based syntax. WSDL allows service providers to expose the various Web services through an XML specification. Technically speaking, a WSDL document represents the description of a Web service as a collection of ports (or endpoints). The document is typically composed of two sections ”one describes the abstract data types of the messages and the operations; the second is a binding section that associates a service address (typically a URL) with the type definitions.

Typically, if you are a developer or architect creating Web services, apart from providing the URI/URL of your SOAP service, you will publish its specification (types and parameters) using WSDL. However, Microsoft .NET Framework allows the WSDL service description to be almost prebuilt for you. For example, Listing 9.4 is the WSDL interface for the Hello Service that you developed earlier.

Listing 9.4 WSDL-based Web Services Description

 <?xml version="1.0" encoding="utf-8"?> <definitions ... targetNamespace="http://www.hiteshseth.com/webservices"  xmlns="http://schemas.xmlsoap.org/wsdl/">   <types>     <s:schema elementFormDefault="qualified"       targetNamespace="http://www.hiteshseth.com/webservices">       <s:element name="sayHello">         <s:complexType />       </s:element>       <s:element name="sayHelloResponse">         <s:complexType>           <s:sequence>             <s:element minOccurs="0" maxOccurs="1"                name="sayHelloResult" type="s:string" />           </s:sequence>         </s:complexType>       </s:element>     </s:schema>   </types>   <message name="sayHelloSoapIn">     <part name="parameters" element="s0:sayHello" />   </message>   <message name="sayHelloSoapOut">     <part name="parameters" element="s0:sayHelloResponse" />   </message>  <portType name="HelloServiceSoap">   <operation name="sayHello">   <documentation>Simple Hello Method</documentation>   <input message="s0:sayHelloSoapIn" />   <output message="s0:sayHelloSoapOut" />   </operation>   </portType>  <binding name="HelloServiceSoap" type="s0:HelloServiceSoap">     <soap:binding transport="http://schemas.xmlsoap.org/soap/http"      style="document" />     <operation name="sayHello">       <soap:operation        soapAction="http://www.hiteshseth.com/webservices/sayHello"        style="document" />       <input>         <soap:body use="literal" />       </input>       <output>         <soap:body use="literal" />       </output>     </operation>   </binding>   <service name="HelloService">     <port name="HelloServiceSoap" binding="s0:HelloServiceSoap">      <soap:address location="http://localhost/WebServices/HelloService.asmx" />     </port>   </service> </definitions> 

Registry for Web Services ”Universal Directory Description and Integration (UDDI)

Where there is a description or metadata about a collection of objects, a natural extension is to have a telephone book or directory of some sort , or a Registry. UDDI aims to do just that. Universal Directory Description and Integration (UDDI), another specification developed by OASIS Web Services Standardization Organization, aims to provide both private and public registries of SOAP-based services defined using WSDL. UDDI, then, is a Yellow Pages to the world of dynamic Web services. The aim is to provide true B2B and enterprise integration.

SHOP TALK : THE MEGA VISION OF WEB SERVICES

Potentially , a scenario like this can be conceived and developed, where a computer manufacturing company wants to order some raw materials from an appropriate supplier. It queries the public UDDI registry, hosted by a vertical exchange, and is able to locate a company that provides the appropriate raw materials. Through well-defined services, an integration workflow is then able to call an order entry system of the company and order goods. This can all be done in an automated, seamless fashion. From my experience in utilizing services in real-world applications, this scenario does looks a little difficult to achieve. However, if we use this as the eventual vision and what we need to get it, by simplifying some aspects of it, you will realize that the individual components themselves can prove to be very useful as well.

Three major UDDI registry providers can be conceived ”a private registry, a public registry, or an exchange-based UDDI registry.

Private Registry

Your own organization can document and describe its internal Web services, which can foster interdepartment communication and integration. Like any registry, you will also have separate testing and production registries. With the release of Windows 2003, UDDI Registry is part of the Windows operating system and can be used by organizations to host their own private UDDI registry.

Public UDDI Registries

As part of its commitment to promote the UDDI standard, Microsoft (and a number of other organizations, including IBM and SAP) have created their own publicly available UDDI registries. The production Microsoft UDDI Registry is available at http://uddi.microsoft.com, and a test version of the registry is available at http://test.uddi.microsoft.com.

UDDI Registries Hosted by Exchanges

As part of your vertical or horizontal industry, a unification and common access initiative can potentially foster the development of a registry focused on your service offerings. Typically these exchanges have something in common ”either they are focusing on solving a particular business problem or are developed as part of a vertical organization.

Registering Web services in UDDI can also be used for technology implementation requirements, such as ensuring load balancing and failover for creating and publishing highly available Web services.