The core technologies at the heart of Web servicesWSDL, SOAP, and UDDIare designed to ease interoperability. In particular, SOAP, a protocol built upon XML, is the fundamental Web service transport technology. Because XML is a widely accepted technology for passing structured data, it is tempting to believe that SOAP messages provide interoperability. But, XML is not the
"silver bullet" for solving integration problems.
To achieve true interoperability across multiple companies, standard syntax and semantics are both required. For example, let's define a simple data structure for a purchase order. The over-simplified purchase order example will contain only the company name, product identifier, and price.
<name> "Widgets, Inc." </name>
<productid> 123456 </productid>
<price> "$59.95" </price>
This example represents pricing data as a string. If a partner were to instead represent pricing data as a floating-point number, data type errors would be likely to occur. Therefore, agreement among partners about how to handle data is essential. XML solves data typing issues through the use of XML schemas. The following example shows how each element in the purchase order can be designated a specific data type:
<xs:schema xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="name" type="xs:string"/>
<xs:element name="productid" type="xs:int"/>
<xs:element name="price" type="xs:string"/>
With the XML schemas defined, you can create the WSDL that defines the input and output operations. In this scenario, there might be an XML type defining the "order_request" and another defining the "order_response." The following WSDL could be used to tie the request and response messages together:
<definitions xmlns:tns="uri:order.hp.com" >
<wsdl:part element="tns:order_request" name="input"/>
<wsdl:part element="tns:order_response" name="output"/>
In the WSDL example above, the request and response messages are mapped to the specific XML schema types. Then, a specific operation is defined, called "placeOrder" that connects the request with the response message. This simple example illustrates how XML schemas can be used to identify specific data types that are required for a Web service and how WSDL messages and operations can be constructed. Developers wishing to use the service (for example, those who work for your partners) then know the exact contract or interface required.
Things get more complicated when you try to understand the meaning, or underlying semantics, of the data. In my fictitious example, there are two major assumptions about products and prices: First, that products will always be represented with numbers, and second, that pricing can be expressed in U.S. dollars. Both assumptions are unlikely to be tenable in the real world.
Neither XML nor WSDL can solve such semantic issues. They must be agreed upon in advance by the various partners in the interaction, and a mechanism to translate from one structure to another must be developed. Technologies such as XSLT (the Extensible Stylesheet Language Transformations) and XPath (the XML Path Language) meet that need.
There are tools available that provide direct support for mapping between different XML formats or schemas. For example, with Cape Clear's CapeStudio developers can input two XML schemas, define mappings between the types, and the product will automatically generate an XSLT document for translation. BEA's WebLogic Workshop provides a Map and Interface Editor in which you can easily set up XML mappings between incoming XML requests and back-end logic. Other platforms can utilize handlers to pre-process incoming SOAP requests. Here, a developer could introduce XSLT logic to transform the XML document if necessary.