UDDI and SOAPWSDL Relationships


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 applications in a self-describing manner. The SOAP specification enables one application to invoke the service interface of a service without the requirement of having both applications 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 (Figure 6.13). SOAP is built on top of XML.

click to expand
Figure 6.13: 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.

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.

end sidebar

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

  • A service implementation that contains multiple service interface documents

  • A service interface that references another service interface

  • A service interface provider that is the same as the service provider

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

start example
 <?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 name="SingleSymbolRequest">   <part name="symbol" type="xsd:string"/> </message> <message name="SingleSymbolNewsResponse">   <part name="news" type="xsd:string"/> </message> <portType name="SingleSymbolNewsService">   <operation name="getNews">     <input message="tns:SingleSymbolRequest"/>     <output message="tns:SingleSymbolNewsResponse"/>   </operation> </portType> <binding name="SingleSymbolBinding"          type="tns:SingleSymbolNewsService">   <soap:binding style="rpc"                 transport="http://schemas.xmlsoap.org/soap/http"/>   <operation name="getNews">     <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> 
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

start example
 <?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 name="ArrayOfString">       <complexContent>         <restriction base="soapenc:Array">           <attribute ref=soapenc:arrayType                      wsdl:arrayType="xsd:string[]"/>         </restriction>       </complexContent>     </compextType>   </schemas> </types> <message name="MultiSymbolRequest">   <part name="symbols" type="xsd1:ArrayOfString"/> </message> <message name="MultiSymbolNewsResponse">   <part name="news" type="xsd1:ArrayOfString"/> </message> <portType name="MultiSymbolNewsService">   <operation name="getNews">     <input message="tns:MultiSymbolRequest"/>     <output message="tns:MultiSymbolNewsResponse"/>   </operation> </portType> <binding name="MultiSymbolBinding"          type="tns:MultiSymbolNewsService">   <soap:binding style="rpc"                 transport="http://schemas.xmlsoap.org/soap/http"/>   <operation name="getNews">     <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> 
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

start example
 <?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> 
end example

Listing 6.10: UDDI tModel that corresponds to a multiple-symbol WSDL document

start example
 <?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> 
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

start example
 <definitions name="NewsService"   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 name="NewsService">      <documentation>Flute Bank News Service</documentation>      <port name="SingleSymbolService"          binding="single:SingleSymbolBinding">          <soap:address location="http://www.flutebank.com/newsservice"/>      </port>    <port name="MultiSymbolService"        binding="mult:MultSymbolBinding">        <soap:address location="http://www.flutebank.com/newsservice"/>   </port>   </service> </definitions> 
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

start example
 <?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 name="SingleSymbolRequest">     <part name="symbol" type="xsd:string"/>   </message>   <message name="SingleSymbolNewsResponse">     <part name="news" type="xsd:string"/>   </message>   <portType name="SingleSymbolNewsService">     <operation name="getNews">       <input message="tns:SingleSymbolRequest"/>       <output message="tns:SingleSymbolNewsResponse"/>     </operation>   </portType> </definitions> 
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

start example
 <?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 name="SingleSymbolBinding"            type="interface:SingleSymbolNewsService">     <soap:binding style="rpc"            transport="http://schemas.xmlsoap.org/soap/http"/>     <operation name="getNews">       <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> 
end example

start sidebar

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

end sidebar




Java Web Services Architecture
Java Web Services Architecture (The Morgan Kaufmann Series in Data Management Systems)
ISBN: 1558609008
EAN: 2147483647
Year: 2005
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net