JaVa
   

UDDI and SOAP/WSDL Relationships

As you are aware, XML is a cross-platform approach to data encoding and can be used for data exchange between different apps in a self-describing manner. The SOAP specification enables one app to invoke the service interface of a service without the requirement of having both apps either written in the same language or using a distributed object infrastructure, such as COM or CORBA. SOAP is one solution to the interoperability problem, in that it uses a layered approach (Screenshot). SOAP is built on top of XML.

Java Click To expand
Screenshot: UDDI interoperability

Using XML and SOAP are good first steps, but there are many gaps. When one asks the question "What do I require to have a standards-based, end-to-end solution supported on every computing platform?" the answer becomes clear that we need additional solutions. UDDI borrows on the best practices and thoughts of XML and SOAP by defining the next layer, then enables organizations to share a mechanism to query each other's services as well as describe their own. A UDDI business registry is accessed via SOAP. A registered service can expose any type of service interface. UDDI allows for the registration of services regardless of the type of service description means, including, but not limited to, WSDL. A service can be described via ASCII, RosettaNet, or other description approaches. Ideally, one should wherever possible use WSDL to describe the service. The primary reason for storing WSDL in UDDI is so clients can easily discover the location of the WSDL document and optionally programmatically generate a proxy to the service. Consider the following example: Flute Bank has decided it wants to publish its news service WSDL in UDDI. It has decided to break down the news service into two separate files. The first file contains the service interface definition and exposes it at www.flutebank.com/services/newsInterface.wsdl. Flute will also create a tModel that references the service interface definition. The second file contains the service implementation definition and exposes it at /www.flutebank.com/services/news.wsdl. Let us look at the SOAP message for save_service API:

<save_tModel generic="2.0" xmlns="urn:uddi-org:api">
 <authInfo> ... </authInfo>
 <tModel>
 <name>Flute Bank News Service Interface Definition</name>
 <description>This is the service interface definition for the news service
 </description>
 <overviewDoc>
 <overviewURL>
 http://www.flutebank.com/services/newsInterface.wsdl
 </overviewURL>
 </overviewDoc>
 <categoryBag>
 <keyedReference keyName="uddi.org:types" keyValue="wsdlSpec"
 tModelKey="UUID:C1BBBA26D-9762-4344-9370-22B756E62AB4"/>
 </categoryBag>
 </tModel>
</save_tModel>


The tModel contains an overviewURL element that points to the location of the service interface definition (WSDL). The keyedReference element specifies its categorization as a WSDL specification document. A WSDL/UDDI-aware tool can search for this specific tModel and generate the appropriate proxy to the service. Now that Flute Bank has generated the tModel for the news service interface, it may also want to specify that the news service businessService entity uses this tModel. The save_service API will generate the following XML:

<save_service generic="2.0" xmlns="urn:uddi.org:api">
 <authInfo> ... </authInfo>
 <businessService>
 <name>Flute Bank News Service</name>
 <description>This service uses the News service interface definition</description>
 <bindingTemplates><bindingTemplate>
 <description>Reference the service interface definition</description>
 <accessPoint URLType="http">www.flutebank.com/services/news</accessPoint>
 <tModelInstanceDetails>
 <tModelInstanceInfo
 tModelKey="UUID:43E24422-3E2A-11D8-222B-BAD69F5ABC12">
 <instanceDetails>
 <overviewDoc>
 <description>Points to service implementation WSDL</description>
 <overviewURL>
 www.flutebank.com/services/news.wsdl
 </overviewURL>
 </overviewDoc>
 </instanceDetails>
 </tModelInstanceInfo>
 </tModelInstanceDetails>
 </bindingTemplate></bindingTemplates>
 </businessService>
</save_service>


A Web service specifies the location of a service within its service implementation file (WSDL). However, our scenario specifies the URL in which the service can be invoked by using the accessPoint element. This approach provides several advantages. First, it allows for Flute Bank to move the service location without having to update the UDDI businessService entity. Second, clients receive the latest copy of the WSDL document and does not have to wait for it to replicate to all instances of a UDDI registry upon publication in a replicated environment.

Java Start Sidebar

UDDI.org publishes a best-practices document at www.uddi.org/bestpractices.html that should be read by anyone wanting to publish WSDL in a UDDI registry.

Java End Sidebar

There are many other scenarios in which you will want to integrate WSDL into UDDI, including

A service implementation may decide to implement more than one service interface definition. In this scenario, the service implementation document WSDL will contain references to all the service interface documents. For example, the Flute Bank news service will support two different service interfaces. The first supports passing in a single stock symbol to retrieve news for the company. The second allows multiple symbols to be passed in to retrieve news. The supporting interface contains a different namespace and binding. Listing 6.7 shows the WSDL service interface for the single news service.

Listing 6.7: First WSDL document: allows a single symbol to be passed
<?xml version="1.0"?>
<definitions name="NewsService-SingleSymbol-interface"
 targetNamespace="http://www.flutebank.com/NewsService-SingleSymbol-interface"
 xmlns:tns="http://www.flutebank.com/NewsService-SingleSymbol-interface"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema "
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns="http://schemas.xmlsoap.org/wsdl/">
<documentation>
 Service interface definition for the Flute Bank News service
 Accepts a single symbol
</documentation>
<message >
 <part type="xsd:string"/>
</message>
<message >
 <part type="xsd:string"/>
</message>
<portType >
 <operation >
 <input message="tns:SingleSymbolRequest"/>
 <output message="tns:SingleSymbolNewsResponse"/>
 </operation>
</portType>
<binding 
 type="tns:SingleSymbolNewsService">
 <soap:binding style="rpc"
 transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation >
 <soap:operation soapAction="http://www.flutebank.com/GetNews"/>
 <input>
 <soap:body use="encoded"
 namespace="urn:single-symbol-news"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
 </input>
 <output>
 <soap:body use="encoded"
 namespace="urn:single-symbol-news"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
 </output>
 </operation>
 </binding>
</definitions>



Java End example

Listing 6.8 shows the second WSDL service interface that allows for retrieving multiple news items based on passing multiple ticker symbols.

Listing 6.8: Second WSDL document: allows multiple symbols to be passed
<?xml version="1.0"?>
<definitions name="NewsService-MultiSymbol-interface"
 targetNamespace="http://www.flutebank.com/NewsService-MultiSymbol-interface"
 xmlns:tns="http://www.flutebank.com/NewsService-MultiSymbol-interface"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema "
 xmlns:xsd1="http://http://www.flutebank.com/NewsService/schema"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns="http://schemas.xmlsoap.org/wsdl/">
<documentation>
 Service interface definition for the Flute Bank News service
 Accepts multiple symbols
</documentation>
<types>
 <schema targetNamespace="http://www.flutebank.com/NewsService/schema"
 xmlns="http://www.w3.org/2001/XMLSchema"
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
 <complexType >
 <complexContent>
 <restriction base="soapenc:Array">
 <attribute ref=soapenc:arrayType
 wsdl:arrayType="xsd:string[]"/>
 </restriction>
 </complexContent>
 </compextType>
 </schemas>
</types>
<message >
 <part type="xsd1:ArrayOfString"/>
</message>
<message >
 <part type="xsd1:ArrayOfString"/>
</message>
<portType >
 <operation >
 <input message="tns:MultiSymbolRequest"/>
 <output message="tns:MultiSymbolNewsResponse"/>
 </operation>
</portType>
<binding 
 type="tns:MultiSymbolNewsService">
 <soap:binding style="rpc"
 transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation >
 <soap:operation soapAction="http://www.flutebank.com/GetNews"/>
 <input>
 <soap:body use="encoded"
 namespace="urn:multi-symbol-news"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
 </input>
 <output>
 <soap:body use="encoded"
 namespace="urn:multi-symbol-news"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
 </output>
 </operation>
</binding>



Java End example

Listings 6.7 and 6.8 show two distinct WSDL documents that contain a different message, port, and binding specification for the same service. In this scenario, they will be published in a UDDI registry using distinct tModels. Note that each service interface has only a single binding. This allows the overviewURL to be generic rather than requiring it to reference a specific binding.

Listings 6.9 and 6.10 show the tModels that will be published for each WSDL document.

Listing 6.9: UDDI tModel that corresponds to a single-symbol WSDL document
<?xml version="1.0"?>
<tModel tModelKey="">
 <name>http://www.flutebank.com/NewsService-SingleSymbol-interface</name>
 <description xml:lang="en">
 Service interface definition for the Flute Bank News service
 Accepts a single symbol
 </description>
 <overviewDoc>
 <description xml:lang="en">
 WSDL Service Interface Document
 </description>
 <overviewURL>
 http://www.flutebank.com/services/NEWS-SingleSymbol-interface.wsdl
 </overviewURL>
</overviewDoc>
<categoryBag>
 <keyedReference tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"
 keyName="uddi-org:types" keyValue="wsdlSpec"/>
 <keyedReference tModelKey="UUID:BB22457D-9AF8-4D54-AB7C-033A2A122E87"
 keyName="flute bank News services"
 keyValue="90210801"/>
 </categoryBag>
</tModel>



Java End example
Listing 6.10: UDDI tModel that corresponds to a multiple-symbol WSDL document
<?xml version="1.0"?>
<tModel tModelKey="">
 <name>http://www.flutebank.com/NewsService-MultiSymbol-interface</name>
 <description xml:lang="en">
 Service interface definition for the Flute Bank News service
 Accepts multiple symbols
 </description>
 <overviewDoc>
 <description xml:lang="en">
 WSDL Service Interface Document
 </description>
 <overviewURL>
 http://www.flutebank.com/services/NEWS-MultiSymbol-interface.wsdl
 </overviewURL>
</overviewDoc>
<categoryBag>
 <keyedReference tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"
 keyName="uddi-org:types" keyValue="wsdlSpec"/>
 <keyedReference tModelKey="UUID:BB22457D-9AF8-4D54-AB7C-033A2A122E87"
 keyName="Flute Bank News services"
 keyValue="90210801"/>
 </categoryBag>
</tModel>



Java End example

Note that the WSDL service implementation document will contain two import elements, each of which references one of the service interface documents. Listing 6.11 shows the WSDL for the service implementation document.

Listing 6.11: WSDL service implementation
<definitions 
 targetNamespace="http://www.flutebank.com/NewsService"
 xmlns:single="http://www.flutebank.com/NewsService-SingleSymbol-interface"
 xmlns:mult="http://www.flutebank.com/NewsService-MultiSymbol-interface"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns="http://schemas.xmlsoap.org/wsdl/">
 <import
 namespace="http://www.flutebank.com/NewsService-SingleSymbol-interface"
 location="http://www.flutebank.com/wsdl/NEWS-SingleSymbol-interface.wsdl"/>
 <import
 namespace="http://www.flutebank.com/Newservice-MultiSymbol-interface"
 location="http://www.flutebank.com/wsdl/NEWS-MultSymbol-interface.wsdl"/>
 <service >
 <documentation>Flute Bank News Service</documentation>
 <port 
 binding="single:SingleSymbolBinding">
 <soap:address location="http://www.flutebank.com/newsservice"/>
 </port>
 <port 
 binding="mult:MultSymbolBinding">
 <soap:address location="http://www.flutebank.com/newsservice"/>
 </port>
 </service>
</definitions>



Java End example

As you can tell, the WSDL service implementation uses the same port to support both single and multiple symbols quotes. Sometimes it is useful to have a service interface that references another service interface. This can be used by other service interface providers to specify their own bindings for the service interface. Listing 6.12 is an example.

Listing 6.12: Service interface that references another service interface
<?xml version="1.0"?>
<definitions name="NewsService-interface"
 targetNamespace="http://www.flutebank.com/NewsService-interface"
 xmlns:tns="http://www.flutebank.com/NewsService-interface"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema "
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns="http://schemas.xmlsoap.org/wsdl/">
 <documentation>
 Service interface definition for the Flute Bank News service
 without bindings
 </documentation>
 <message >
 <part type="xsd:string"/>
 </message>
 <message >
 <part type="xsd:string"/>
 </message>
 <portType >
 <operation >
 <input message="tns:SingleSymbolRequest"/>
 <output message="tns:SingleSymbolNewsResponse"/>
 </operation>
 </portType>
</definitions>



Java End example

In Listing 6.12, the service interface alone contains the bindings that can be published in the registry as a tModel. The WSDL service interface document contains the types, message, and portType elements. These cannot be published in UDDI, because a UDDI tModel can point only to a WSDL service interface that contains at least one binding element. The service bindings can be published as a tModel and will point to the WSDL service interface document that contains the binding definitions, as in Listing 6.13. A client will use the document to retrieve the service interface that contains the binding definitions. Tools that understand WSDL need the ability to follow an import chain.

Listing 6.13: WSDL service bindings
<?xml version="1.0"?>
<definitions name="NewsService-binding"
 targetNamespace="http://www.flutebank.com/NewsService-binding"
 xmlns:interface="http://www.flutebank.com/NewsService-interface"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema "
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns="http://schemas.xmlsoap.org/wsdl/">
 <documentation>
 Service interface definition for the Flute Bank News service
 </documentation>
 <import namespace="http://www.flutebank.com/NewsService-interface/"
 location="http://www.flutebank.com/News-interface.wsdl">
 <binding 
 type="interface:SingleSymbolNewsService">
 <soap:binding style="rpc"
 transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation >
 <soap:operation soapAction="http://www.flutebank.com/GetNews"/>
 <input>
 <soap:body use="encoded"
 namespace="urn:single-symbol-news"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
 </input>
 <output>
 <soap:body use="encoded"
 namespace="urn:single-symbol-news"
 encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
 </output>
 </operation>
 </binding>
</definitions>



Java End example
Java Start Sidebar

One tool that supports this capability is WSDL4J, available at www-124.ibm.com/developerworks/projects/wsdl4j/

Java End Sidebar

JaVa
Comments