WSDL is used to describe the interface of
a web service. <tModel> UDDI documents
provide metadata descriptions of a web service and pointers to
specifications that describe their implementation. Given this
provision, WSDL documents tie into the UDDI data structures in a
couple of places:
A
<tModel>document should be created for each WSDL document supported by a web service. The<tModel>describes the abstract service type, not the service instance; if appropriate, the WSDL file pointed to by the<tModel>should not contain the<service>and<port>elements. Omitting the<service>and<port>elements allows a WSDL document to describe many web services located in several different places. The WSDL document’s URL should be listed as the value of the<overviewURL>element. A<tModel>that references a WSDL document should have a categorization taxonomy ofuddi-org:types; a categorization value ofwsdlSpecshould be applied to it by using a<categoryBag>element.A
<bindingTemplate>structure is created for each unique URL access point used by the web service. The<bindingTemplate>document references one or more<tModel>documents containing the WSDL definitions supported at this access point.A
<businessService>document is created for each web service. The document contains one<bindingTemplate>for each of the access points supported by the web service.
For example, if you implement one web service that has a single
access point and is defined by a single WSDL document, you would
create a single <tModel>, a single
<bindingTemplate>, and a single
<businessService>. Also, if you implement
one web service that has two separate access points, each defined by
a different WSDL document, you would create two
<tModel> documents (one for each interface),
two <bindingTemplate> documents (one for
each access point), and a single
<businessService> document. Each
<bindingTemplate> document must point to the
<tModel> that references its interface.
The Hertz reservation system web service provides a concrete example
of how UDDI and WSDL work together. Here is the
<tModel> for this web service:
<tModel authorizedName="..." operator="..." tModelKey="...">
<name>HertzReserveService</name>
<description xml:lang="en">WSDL description of the Hertz reservation service
interface</description>
<overviewDoc>
<description xml:lang="en">WSDL source document.</description>
<overviewURL>http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
keyName="uddi-org:types" keyValue="wsdlSpec"/>
</categoryBag>
</tModel>The WSDL document URL that this web service implements is contained
as the value of the <overviewURL>.
Additionally, this <tModel> is categorized
as a web service by incorporating a
<categoryBag>.
<categoryBag> has a
<keyedReference> that specifies the
keyName attribute as
uddi-org:types and the keyValue
attribute as wsdlSpec.
A <tModel> can further qualify the portion
of the WSDL document it refers to. For example, a
<tModel> can refer to a specific
<binding> element within a WSDL document
that has multiple <binding> elements. A
pound sign fragment identifier is used between the URL of the WSDL
document and the name of the <binding>
element that accomplishes this qualification. For example:
<overviewURL>http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl#HertzReserveBinding </overviewURL>
Writing a Java program that creates a complete web service registration to a UDDI registry requires a lot of effort: an understanding of SOAP, accessing a UDDI registry using the correct SOAP messages, and ensuring that WSDL documents are placed in the correct locations in a UDDI registry. A developer can easily make mistakes when following this model.
It didn’t take long for companies to begin developing abstraction APIs that facilitate this process. It is argued that companies and developers will use the UDDI/WSDL/SOAP model more than any other model since it is a worldwide standard and supported by every major technology business. As such, providing an abstraction layer that simplifies publishing documents following this model makes sense.
IBM created an API that does this abstraction very cleanly. This API is called the Service Registry Proxy (SRP) and is contained as part of the UDDI4J project at IBM. This pseudocode demonstrates how to publish a new web service exposed by WSDL into a UDDI registry:
// Create an active connection to a UDDI registry
ServiceRegistryProxy srp = new ServiceRegistryProxy(
"http://localhost:8080/wasp/uddi/inquiry/",
"https://localhost:8443/wasp/uddi/publishing/",
"admin",
"changeit");
// Create a category list for an existing tModel (<categoryBag> document)
CategoryList categoryList = new CategoryList(
TModelKeyTable.getTModelKey(TMODEL_UUID_VALUE_HERE),
"uddi-org:types",
"wsdlSpec");
// Create service provider (<businessService> document)
ServiceProvider serviceProvider = new ServiceProvider(
"Demi Credit",
"Financing Company",
categoryList);
// Publish the service to UDDI
srp.publish(serviceProvider);The
ServiceRegistryProxy
class creates connections to an inquiry
and publishing access point. The program instantiating the proxy
passes in all the information needed to create these connections,
including the username and password needed to get an authentication
token. The CategoryList object creates the
equivalent of a <categoryBag> document for a
specific <tModel>. Since WSDL
<tModel> documents are supposed to have a
special categorization, creating a CategoryList
instance and passing this instance as an input parameter to the
ServiceProvider constructor creates this
categorization. A ServiceProvider object is an
abstraction of a <businessService> document.
Finally, the ServiceProvider object has a series
of methods that allow a program to perform such actions as publish,
unpublish, and find. All of these actions result in SOAP messages
that are sent to the UDDI server.