SCDJWS Study Guide: UDDI
Printer-friendly version |
Mail this to a friend
 |
 |
 |
 |
Using WSDL Definitions with UDDI
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 <h1>viewURL>
element. A <tModel>
that references a WSDL document
should have a categorization taxonomy of uddi-org:types;
a categorization value of wsdlSpec
should 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>.
The <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>
An Abstraction API
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.