Unit-4 Wssoa
Unit-4 Wssoa
UNIT-IV
SOAP
Web Service Request
Requestor 2 Find UDDI Registry
SOAP 4
Request
Invoke Call Web Service
Firewall
SOAP
1
3 Request Register Web Service
Retrieve Publish at Development Time
WSDL Bind JAXR
Definition Servlets or
Specific API SOAP
Request
WSDL Document
In Figure 5.1, all of the communication over the wire takes place on
SOAP. The following list explains the steps depicted in Figure 5.1:
■ Step 1 illustrates a service provider publishing its Web service to a UDDI
registry. This is when the service provider would create a WSDL
definition and publish a link to this definition along with the rest of the
Web service information to a UDDI registry.
■ Step 2 illustrates an interested service user locating the Web service and
finally obtaining information about invoking the Web service from the
published WSDL definition. This step involves download-ing a WSDL
definition to the service user system and deserializing WSDL to a Java
class (or any other language). This Java interface serves as a proxy to the
actual Web service. It consists of the binding information of the Web
service.
■ Step 3 shows the service user binding at runtime to the Web service. In
this step, the service user’s application would make use of the Java
interface representing WSDL as a proxy, in order to bind to the Web
service.
■ Step 4 finally shows the service user invoking the Web service based on
the service invocation information it extracted from the Web service
WSDL definition. This is when the service user’s application would make
use of the Java interface representing WSDL as a proxy, in order to invoke
the methods/functions exposed by the Web service.
<types>. This element defines all of the data types that would be used to
describe the messages that are exchanged between the Web service and
the service user. WSDL does not mandate the use of a specific typing
system. However, as per the WSDL specification, XML Schema is the
default typing system.
XML Schema was discussed in Chapter 4, “Developing Web Services
Using SOAP,” in the context of SOAP encoding.
<message>. This element represents a logical definition of the data being
transmitted between the Web service and the service user. This element
describes a one-way message, which may represent a request or response
sent to or from the Web service. It contains zero or more message <part>
elements, which basically refer to the request parameters or response return
values.
We will further examine each of these elements later. First, let’s take a look at
Listing 5.1, which shows a WSDL document describing a weather information
Web service, WeatherInfoService. This WSDL definition is present in the
WeatherInfo.wsdl file.
6
<?xml version=”1.0”?>
<definitions name=”WeatherInfo”
targetNamespace=”http://myweather.com/weatherinfo.wsdl”
xmlns:tns=”http://myweather.com/weatherinfo.wsdl”
xmlns:xsd1=”http://myweather.com/weatherinfo.xsd”
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”
xmlns=”http://schemas.xmlsoap.org/wsdl/”>
<types>
<schema targetNamespace=
“http://myweather.com/weatherinfo.xsd” xmlns=
“http://www.w3.org/2000/10/XMLSchema”>
<element name=”WeatherInfoRequest”>
<complexType>
<all>
<element name=”Country”
type=”string”/>
<element name=”Zip”
type=”string”/>
<element name=”Instant”
type=”string”/>
</all>
</complexType>
</element>
<element name=”WeatherInfo”>
<complexType>
<all>
<element name=”FTemp”
type=”float”/>
<element name=”Humidity”
type=”float”/>
</all>
</complexType>
</element>
</schema>
</types>
<message name=”GetWeatherInfoInput”>
<part name=”WeatherInfoRequestSpec”
element=”xsd1:WeatherInfoRequest”/>
</message>
<message name=”GetWeatherInfoOutput”>
<part name=”WeatherInfo”
Description and Discovery of Web Services 7
element=”xsd1:WeatherInfo”/>
</message>
<portType name=”WeatherInfoPortType”>
<operation name=”GetWeatherInfo”>
<input message=”tns:GetWeatherInfoInput”/> <output
message=”tns:GetWeatherInfoOutput”/>
</operation>
</portType>
<binding name=”WeatherInfoSoapBinding”
type=”tns:WeatherInfoPortType”>
<soap:binding style=”document”
transport=”http://schemas.xmlsoap.org/soap/http”/>
<operation name=”GetWeatherInfo”>
<soap:operation soapAction=
“http://myweather.com/GetWeatherInfo”/>
<input>
<soap:body use=”literal”/>
</input>
<output>
<soap:body use=”literal”/>
</output>
</operation>
</binding>
<service name=”WeatherInfoService”>
<documentation>
Provides Weather Information
</documentation>
<port name=”WeatherInfoPort”
binding=”tns:WeatherInfoSoapBinding”>
<soap:address location=
“http://myweather.com/provideweatherinfo”/>
</port>
</service>
</definitions>
<definitions> Element
The <definitions> element specifies the name of the document in which this
WSDL definition is stored, which is WeatherInfo in our case.
This element specifies namespaces that would be used in the rest of the WSDL
document. The following are the two important namespaces that the
<definitions> element defines:
WSDL instance specific namespace. The targetNamespace attribute of the
<definitions> element lets the WSDL document make references to itself as
an XML Schema namespace. Note how-ever that it is not required for the
WSDL document to actually exist at the address specified by the
targetNamespace attribute. This attribute is just a mechanism to refer to our
WSDL definition in a unique way.
<message> Element
WeatherInfo.wsdl defines two <message> elements.
The first <message> definition named GetWeatherInfoInput will be used later
to define the input message of the GetWeatherInfo operation. The second
<message> definition named GetWeatherInfoOutput will be used later to define
the output message of the GetWeatherInfo opera-tion. This binding of
<message> definitions to an actual operation is defined in the <portType>
element.
Again, each of these <message> definitions consists of a <part> element. In
case of the GetWeatherInfoInput message, <part> essen-tially specifies the name,
that is, WeatherInfoRequestSpec, and type, that is, WeatherInfoRequest, of the
request parameter to GetWeath-erInfo operation. Whereas, in case of the
GetWeatherInfoOutput message, <part> refers to the name and type of the return
value sent within the response of the GetWeatherInfo operation. Note that both
WeatherInfoRequest and WeatherInfo, which were referred to by
Description and Discovery of Web Services 9
the type attribute of <part> element also were defined by the preceding <types>
element.
Also in cases where operations take multiple arguments or return multi-ple
values, the <message> element can define multiple <part> elements.
<portType> Element
The <portType> element in WeatherInfo.wsdl defines a single opera-tion named
GetWeatherInfo by combining the <input> message as defined by the
GetWeatherInfoInput <message> element and the <output> message as defined
by the GetWeatherInfoOutput <message> element.
CLIENT SERVICE
One-way <input>
Request- <input>
Response <output>
<output> Solicit-
<input> Response
<output> Notification
<binding> Element
A binding defines the message format and protocol details for operations and
messages defined by a particular <portType>. There may be any number of
bindings for a given <portType>. The type attribute of the <binding> element
refers to the <portType> that it binds to, which is WeatherInfoPortType in our
case. Our WeatherInfoService speci-fies a SOAP binding, as is defined in the
WSDL 1.1 specification. The WSDL 1.1 SOAP binding is discussed in detail in a
later section titled SOAP Binding.
<service> Element
The <service> element specifies the location of the service. Because our
WeatherInfoService is bound to SOAP, we use the <soap:address> element and
specify the service URL as http://myweather.com /provideweatherinfo/.
Now, let’s take a look at the support for various bindings in the WSDL 1.1
specification.
Description and Discovery of Web Services 11
WSDL Bindings
In WSDL, the term binding refers to the process of associating protocol or data
format information with an abstract entity such as <message>, <operation>, or
<portType>. In this section, we examine the support for bindings in the WSDL
1.1 specification. Let’s begin with the WSDL binding extensions.
SOAP Binding
WSDL 1.1 defines a binding for SOAP 1.1 endpoints. This binding provides the
following SOAP protocol specific information:
■ An indication that the binding is bound to the SOAP 1.1 protocol
■ A way of specifying an address for a SOAP endpoint
■ The URI for the SOAP action HTTP header for the HTTP binding of
SOAP
■ A list of definitions of headers that are transmitted as part of the
SOAP envelope
Let’s examine the SOAP binding of the request-response RPC operation over
HTTP as defined in the WeatherInfo.wsdl file shown earlier (see the section
titled Anatomy of a WSDL Definition Document).
<soap:binding>
The <soap:binding> element is defined in WeatherInfo.wsdl as follows:
<soap:binding style=”document”
transport=”http://schemas.xmlsoap.org/soap/http”/>
The <soap:binding> element says that the binding is bound to the SOAP
protocol format, that is, envelope, header, and body. However, this element does
not give any information about the format or encoding of the message. This
element must be present whenever describing services that have a SOAP binding.
The style attribute indicates whether the operations supported by this binding
are RPC-oriented or document-oriented. In RPC-oriented commu-nication, the
messages contain parameter and return values, whereas in document-oriented
communication, the messages contain document(s). This information about the
style of communication can be useful because it helps in selecting the
programming model for communicating with the
Description and Discovery of Web Services 13
Web service. For example, if a Web service is described to support RPC, we can
choose a JAX-RPC programming model to communicate with it, or if a Web
service is described to support document-style communication, we can
appropriately choose a JAXM programming model.
The transport attribute specifies the transport binding for the SOAP protocol.
The URI value of http://schemas.xmlsoap.org/soap/http corresponds to the HTTP
binding as defined in the SOAP specification. Sim-ilarly, respective URIs can be
used to indicate other types of transports such as SMTP or FTP.
<soap:operation>
The <soap:operation> element is defined in WeatherInfo.wsdl as follows:
<soap:operation soapAction=
“http://myweather.com/GetWeatherInfo”/>
<soap:body>
The <soap:body> element is defined in WeatherInfo.wsdl as follows:
<soap:body use=”literal”/>
This element defines how the message <part> elements appear inside the
SOAP body element. Based on the style of communication, RPC-oriented or
document-oriented, the <Body> element of the SOAP message is constructed.
The use attribute indicates whether the message <part> elements are encoded
using some encoding rules or whether the <part> elements already define the
concrete schema of the message.
If the value of the use attribute is “encoded”, then each message <part> refers
to an abstract type defined through the type attribute. These abstract types are
then used to produce a concrete definition of the message by applying the
encoding specified by an encodingStyle attribute.
14
<output>
<soap:body
encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”
namespace=”urn:acmens:acmeservice”
use=”encoded”/>
</output>
The <soap:body> element in this code depicts a SOAP binding wherein the
body of the output SOAP message consists of abstract <part> elements that are
used to produce the concrete definition of the message by applying the
encodingStyle as defined in http://schemas .xmlsoap.org/soap/encoding/.
<soap:address>
The <soap:address> element is defined as follows in
WeatherInfo.wsdl:
<soap:address location=
“http://myweather.com/provideweatherinfo”/>
The <soap:address> element specifies an address for the given service port.
WSDL Tools
WSDL tools typically provide functionality in terms of the following:
WSDL generation. Generating WSDL from an existing service component
—for example, a J2EE component or a Java Bean compo-nent or from
scratch.
In the following section, we examine the WSDL tools provided by the Systinet
WASP platform.
package jws.ch5;
String sInstance)
{
/ Talk to some backend services to get hold
/ of the weather information
public void SetWeatherInfo (String sCountry, String sZip, String sInstance, String
sTemperature) {
As can be seen from the previous listing, this class provides get and set
methods. The main job of this class is to manage information related to weather.
Note that this is a very simplistic version of such a weather infor-mation service.
For example, we want to expose this class as a Web service. In which case, we
also decide to provide the description of the interface of this Web service as a
WSDL. Our Web service supports SOAP-based communica-tion, and hence, a
SOAP binding as well. Thus, this fact also should be considered while generating
WSDL using the Java2WSDL tool.
Once the WSDL has been generated, it can be registered in a registry such as
UDDI accompanied by the business- and other service-related information. So
when the prospective Web service users find the Web service, they can obtain the
WSDL description corresponding to this Web service and start using it.
The following command line instruction shows the usage of the Java2WSDL
tool such that it would generate a WeatherInfo.wsdl from the
WeatherInfoJavaService class:
The Java2WSDL tool supports many more arguments than what are shown in
Table 5.2. To find detailed information on these arguments and the Java2WSDL
tool in general, please visit the Systinet Web site at
www.systinet.com/doc/wasp_jserver/tools/java2WSDL.html.
The output WeatherInfo.wsdl generated by the Java2WSDL tool is shown in
Listing 5.2.
<?xml version=’1.0’?>
<wsdl:definitions name=’jws.ch5.WeatherInfoJavaService’
targetNamespace=’http://www.myweather.com/WeatherInfo’
xmlns:wsdl=’http://schemas.xmlsoap.org/wsdl/’
xmlns:tns=’http://www.myweather.com/WeatherInfo’
xmlns:ns0=’http://systinet.com/xsd/SchemaTypes/’
xmlns:soap=’http://schemas.xmlsoap.org/wsdl/soap/’
xmlns:map=’http://systinet.com/mapping/’>
<wsdl:types>
<xsd:schema elementFormDefault=”qualified”
targetNamespace=
“http://systinet.com/xsd/SchemaTypes/”
xmlns:tns=”http://systinet.com/xsd/SchemaTypes/”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
type=”xsd:string”/>
<xsd:element name=”float_res”
type=”xsd:float”/>
<xsd:element name=”sTemperature”
nillable=”true” type=”xsd:string”/>
</xsd:schema>
</wsdl:types>
<wsdl:message name=
‘WeatherInfoJavaService_GetWeatherInfo_1_Request’> <wsdl:part name=’sCountry’
element=’ns0:sCountry’/> <wsdl:part name=’sZip’ element=’ns0:sZip’/>
<wsdl:part name=’sInstance’ element=’ns0:sInstance’/>
</wsdl:message>
<wsdl:message name=
‘WeatherInfoJavaService_GetWeatherInfo_Response’> <wsdl:part name=’response’
element=’ns0:float_res’/>
</wsdl:message>
<wsdl:message name
=’WeatherInfoJavaService_SetWeatherInfo_Response’/>
<wsdl:message name=
‘WeatherInfoJavaService_SetWeatherInfo_1_Request’> <wsdl:part name=’sCountry’
element=’ns0:sCountry’/> <wsdl:part name=’sZip’ element=’ns0:sZip’/>
<wsdl:part name=’sInstance’ element=’ns0:sInstance’/> <wsdl:part
name=’sTemperature’ element=’ns0:sTemperature’/>
</wsdl:message>
‘tns:WeatherInfoJavaService_GetWeatherInfo_1_Request’/>
<wsdl:output message=
‘tns:WeatherInfoJavaService_GetWeatherInfo_Response’/>
</wsdl:operation>
<wsdl:operation name=’SetWeatherInfo’
parameterOrder=’sCountry sZip sInstance
sTemperature’>
<wsdl:input message=
‘tns:WeatherInfoJavaService_SetWeatherInfo_1_Request’/>
<wsdl:output message=
‘tns:WeatherInfoJavaService_SetWeatherInfo_Response’/> </wsdl:operation>
</wsdl:portType>
<wsdl:binding name=’WeatherInfoJavaService’
type=’tns:WeatherInfoJavaService’>
<soap:binding transport=
‘http://schemas.xmlsoap.org/soap/http’
style=’document’/>
<wsdl:operation name=’GetWeatherInfo’>
<map:java-operation name=
‘GetWeatherInfo’ signature=’KExq...’/>
<soap:operation soapAction=’_10’
style=’document’/>
<wsdl:input>
<soap:body use=’literal’
namespace=’http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>
</wsdl:input>
<wsdl:output>
<soap:body use=’literal’ namespace=
‘http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>
</wsdl:output>
</wsdl:operation>
<soap:operation soapAction=’_11’
style=’document’/>
<wsdl:input>
<soap:body use=’literal’ namespace=
‘http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>
</wsdl:input>
<wsdl:output>
<soap:body use=’literal’ namespace=
‘http://www.myweather.com/
WeatherInfoWeatherInfoJavaService’/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name=’JavaService’>
<wsdl:port name=’WeatherInfoJavaService’
binding=’tns:WeatherInfoJavaService’>
<soap:address location=
‘urn:unknown-location-uri’/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
/**
*/
public interface WeatherInfoJavaService {/
/**
*/
float GetWeatherInfo(java.lang.String sCountry, java.lang.String sZip, java.lang.String
sInstance);
/**
*/
void SetWeatherInfo(java.lang.String sCountry, java.lang.String sZip, java.lang.String
sInstance, java.lang.String sTemperature);
/*
* Generated by WSDLCompiler, (c) 2002, Systinet Corp.
* http://www.systinet.com */
This tool also has various options that enable fine-tuning of the genera-tion of
the Java interface. Also, WSDLCompiler supports the generation of Java Bean
components from WSDL definitions. To find further informa-tion about this tool,
visit www.systinet.com/doc/wasp_jserver/tools /wsdlCompiler.html.
Note that tools such as Apache Axis also provide support for generating
messaging implementation classes from WSDL.
Future of WSDL
As mentioned earlier, WSDL 1.2 is presently a work in progress under the Web
Services Description Working Group at W3C. W3C released the draft
specifications of WSDL 1.2 in July 2002. The WSDL 1.2 specification consists
of two documents: Web Services Description Language Version 1.2 and Web
Ser-vices Description Language Version 1.2 Bindings. The former defines the
core language that can be used to describe Web services based on an abstract
model of what the service offers. The latter describes how to use WSDL for
describing services that use SOAP 1.2, MIME, or HTTP 1.1 bindings.
22
The following lists some of the important enhancements of WSDL 1.2 over
WSDL 1.1:
■ WSDL 1.2 provides support for W3C Recommendations, including
XML Schemas and XML Information Set.
■ WSDL 1.2 removes non-interoperable features from WSDL 1.1.
■ WSDL 1.2 clearly defines HTTP 1.1 binding.
To obtain further information on WSDL 1.2, visit www.w3.org/2002/ws
/desc/.
Limitations of WSDL
WSDL 1.1 has an obvious limitation: its incapability of being able to describe
complex business Web services, which typically are constituted by orchestrating
multiple finer-grained Web services. This drawback is due to the lack of support
for workflow descriptions in WSDL. To overcome these limitations of WSDL,
standards such as ebXML Collaborative Protocol Profile/Collaborative Protocol
Agreement (CCP/A), Business Process Specification Schema (BPSS), and Web
Services Choreography Interface (WSCI) can be leveraged. An EbXML set of
technologies can be used to build business Web services. To find more
information on EbXML technical architecture, refer to Chapter 14, “Introduction
to Sun ONE.” A WSCI specification can be downloaded from
wwws.sun.com/software/xml /developers/wsci/. Also Chapter 2, “Introduction to
Web Services,” pro-vides a brief introduction to WSCI.
Apart from these, there are some low-level issues with WSDL 1.1 speci-
fication in terms of the clarity of specification. To get a complete listing of
WSDL 1.1 issues, visit wsdl.soapware.org/.
We will now begin our journey with UDDI.
into new markets and services. It powers all kinds of businesses, large, medium,
or small, to accelerate their business presence in this global market.
UDDI initially started as a joint effort from IBM, Microsoft, and Ariba. Since
then, a number of companies joined the UDDI community. As of this book’s
writing, the UDDI project community is looking forward to releas-ing version
3.0 of the UDDI specification. This chapter covers version 2.0 of the UDDI
specification because it is widely implemented and adopted as of this writing. To
find more information on the UDDI effort, visit the UDDI official Web site at
www.uddi.org.
UDDI Registries
An implementation of the UDDI specification is termed as a UDDI registry.
UDDI registry services are a set of software services that provide access to the
UDDI registry. Meanwhile, registry services can perform a plethora of other
activities such as authenticating and authorizing registry requests, logging
registry requests, load-balancing requests, and so on.
UDDI Specifications
All versions of the UDDI specifications can be obtained from the UDDI
organization at their Web site at http://uddi.org/specification.html. The UDDI 2.0
specification set includes the following documents:
UDDI replication. The document describes the data replication process of
the UDDI registries. Also, it describes the programmatic interfaces
supported by UDDI for achieving replication between UDDI registries
operated by different operators.
UDDI operators. This document provides information on the opera-tional
behavior that should be followed by UDDI node operators. For example, the
document defines guidelines that node operators can follow in order to
manage the data of the UDDI registry node. Such guidelines include the
following:
UDDI data structures. This document outlines the details of the XML
structures that are associated with the SOAP messages used to com-
municate with the UDDI registries. These SOAP messages are well defined
by the UDDI programmer’s API specification and are used to perform the
inquiry and publishing functions on the UDDI registry.
To begin with, let’s take a look at how to retrieve, search, and publish
information to a UDDI registry in the next section.
stored in the registry. To retrieve information, a registry user does not need to be
authenticated.
The following is a list of inquiry API functions that can be used for finding
information in a UDDI registry:
■ <find_business>
■ <find_relatedBusinesses>
■ <find_service>
■ <find_binding>
■ <find_tModel>
To get further detailed information from the UDDI registry, the follow-ing
inquiry API functions are available:
■ <get_businessDetail>
■ <get_businessDetailExt>
■ <get_serviceDetail>
■ <get_bindingDetail>
■ <get_tModelDetail>
Publishing API
The publishing API consists of functions represented by a UDDI Schema, which
defines XML messages that can be used to create, update, and delete the
information present in a UDDI registry. Note that in order to publish to a UDDI
registry, the registry user needs to be authenticated.
The following is a list of publishing API functions that can be used for
adding/modifying information to a UDDI registry:
■ <save_business>
■ <set_publisherAssertions>
■ <add_publisherAssertions>
■ <save_service>
■ <save_binding>
■ <save_tModel>
The following is a list of publishing API functions that can be used for deleting
information from a UDDI registry:
■ <delete_business>
■ <delete_publisherAssertions>
28
■ <delete_service>
■ <delete_binding>
■ <delete_tModel>
Apart from the functions just mentioned, the publishing API also defines
functions that deal with the authentication of the registry users, which is required
in order to successfully execute the rest of the functions of this API:
■ <get_authToken>
■ <discard_authToken>
We will discuss each of the aforementioned APIs in detail in the sections titled
Inquiry API and Publishing API, which follow.
The XML messages constituting the UDDI programmer APIs are defined
using a UDDI XML Schema. These XML messages are wrapped in a SOAP
message and then sent to the UDDI registry. In other words, all of the XML
messages are enveloped within a SOAP <body> element and then sent as an
HTTP POST request to the UDDI registry. The UDDI registry then processes
these SOAP messages and gets hold of the actual API function represented by the
XML message, which further instructs the registry ser-vices to provide either
publishing or querying services.
A UDDI registry node typically enables access to both inquiry and publishing
functionalities through different access point URLs. Table 5.3 lists the URLs for
publicly operated UDDI registry nodes.
As we can see from Table 5.3, all of the URLs corresponding to the pub-
lishing access points support HTTPS, because publishing operations need
authenticated access.
<businessEntity>
The <businessEntity> data structure represents the primary information about a
business, such as contact information, categorization of the business according to
a specific taxonomy or classification scheme, identifiers, rela-tionships to other
business entities, and descriptions about that particular
30
business. The categorizations are discussed in a later section titled Support for
Categorization in UDDI Registries.
<publisherAssertion>
A business registered in a UDDI registry can have active business relationships
with other businesses. This relationship can be of any form, for example, a
relationship of business partners or a business-to-customer relationship. Such
relationships are represented by a <publisherAssertion> data structure in a UDDI
Registry. The <publisherAssertion> structure is used to establish a relationship
between two <businessEntity> structures.
<tModel>
The <tModel> structure provides a description of a particular specifica-tion or
behavior of the service. The <tModel> structure does not contain the service
specification directly; instead, it contains a link to the service specification,
which is managed elsewhere. The <tModel> thus defines the interaction pattern
in order to use the service. For example, a business may provide a Web service
whose WSDL interface may be referenced through a link from within the
<tModel> structure.
Thus, <tModel> defines the lowest-level and most concrete piece of
information about the services offered by a business. A UDDI client typi-cally
gets hold of the service specification pointed out by the <tModel> structure in
order to use a publicly available Web service registered by a particular business.
The linking between these five core data structures of UDDI is depicted in
Figure 5.4.
Apart from these five primary data structures, two other structures exist that
represent the category and identification information of the primary data
structures: <identifierBag> and <categoryBag>. Let’s take a look at each of them
now.
<identifierBag>
The <identifierBag> structure enables <businessEntity> or <tModel> structures
to include information about the common forms of identification such as D-U-N-
S numbers and tax IDs. This data can be used to signify the identity of
<businessEntity>, or it can be used to signify the identity of the publishing party.
Including such identification informa-tion is optional. However, when a
published <businessEntity> or <tModel> carries such common forms of
identification, it greatly enhances the search behaviors exposed via inquiry API
functions.
32
<businessEntity> <publisherAssertion>
<businessService> <tModel>
<bindingTemplate>
<bindingTemplate> data contains
references to
Technical information about a
<tModel>
service entry point and structures. These
construction specification <tModel>
structures
designate the
interface
specifications for a
service.
<categoryBag>
The <categoryBag> structure enables <businessEntity>, <businessService>, and
<tModel> structures to be categorized according to any categorization system,
such as an industry categorization system or a geography categorization system.
Categorizing the data structures mentioned previously is optional. However,
when these data structures are published along with their categorization
information, it greatly enhances the search behaviors exposed via inquiry API
functions. The categorization support in a UDDI registry is discussed in the
following section.
Description and Discovery of Web Services 33
Inquiry API
This section will cover all of the XML messages that perform the function-ality
of inquiring certain information from a UDDI registry. Inquiry API constitutes of
two types of functions:
■ Functions that return zero or more homogeneous data structures
containing abbreviated information
■ Functions that return zero or more homogeneous data structures
containing detailed information
To begin with, we will take a look at the API functions, which return
abbreviated information in response.
ARGUMENT DESCRIPTION
maxRows This argument specifies the maximum number of
results that can be returned.
findQualifiers This argument represents a collection of search
qualifiers that form the criteria of the given
operation. The search qualifiers are discussed in
more detail in a later section.
Name This argument can be a partial or full name of the
business being searched. The name pattern can
make use of the wildcard character % as well. Up to
five name values can be specified in the argument.
In cases when multiple name values are passed, the
match occurs on a logical OR basis.
The returned <businessList> contains
<businessInfo> structures for businesses whose
name matches the name value(s) passed in a lexical
(leftmost in left to right languages) fashion.
IdentifierBag This argument contains a list of business identifier
references.
The returned <businessList> contains
<businessInfo> structures matching any of the
identifiers passed (logical OR).
categoryBag This is a list of category references.
The returned <businessList> contains
<businessInfo> structures matching all of the
categories passed (logical AND).
Description and Discovery of Web Services 37
ARGUMENT DESCRIPTION
tModelBag This argument enables searching for businesses that
have bindings exposing a specific fingerprint within
the <tModelInstanceDetails> structure.
The following code shows the <find_business> XML message that is sent
within the request SOAP message to the UDDI registry. This function call
basically suggests that the UDDI registry returns information on the businesses
that lexically match ‘ACM’:
<uddi:find_business generic=”2.0” maxRows=”10”>
<uddi:name>
ACM
</uddi:name>
</uddi:find_business>
<name xml:lang=”en”>
ACME Computer Services
</name>
<description xml:lang=”en”>
Provides professional services
in the areas of computer software
</description>
<serviceInfos>
<serviceInfo
serviceKey=
“uuid:1245sdef-af35-6a3f-c34a-
bf798dab965a”
businessKey=”uuid:523f3aef-
af35-6a3f-c34a-bf798dab965a”>
<name xml:lang=”en”>
Billing Services
</name>
</serviceInfo>
</serviceInfos>
</businessInfo>
</businessInfos>
</businessList>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Thus, as can be seen from the response in Listing 5.4, the <businessList>
structure contains information about each matching busi-ness and summaries of
the <businessServices> exposed by the individ-ual businesses. If <tModelBag>
were used in the search, the resulting <serviceInfo> structures would only reflect
data for the <busi-nessServices> that contain the matching <bindingTemplate>.
Arguments for this function are listed in Table 5.6. Note that the
<findQualifiers> argument has been discussed before and hence is not discussed
again.
The following code shows the <find_relatedBusinesses> XML message that is
sent within the request SOAP message to the UDDI reg-istry. This function call
suggests that the UDDI registry return the busi-nesses that are related to the
<businessEntity> specified by the UUID ‘23453aef-af35-6a3f-c34a-
bf798dab965a’:
<uddi:find_relatedBusinesses generic=”2.0”>
<uddi:businessKey>
23453aef-af35-6a3f-c34a-bf798dab965a
</uddi:name>
</uddi:find_relatedBusinesses>
ARGUMENT DESCRIPTION
businessKey This is a UUID that is used to specify a particular
<businessEntity> to use as the focal point of
the search. This is a mandatory argument, and it
must be used to specify an existing
<businessEntity> in the registry.
The following code shows the partial SOAP message response, contain-ing the
<relatedBusinessesList> structure, returned from the reg-istry:
<relatedBusinessInfos>
<relatedBusinessInfo>
<businessKey>
22443aef-ac35-2f3f-c34a-ca4423bb931c
</businessKey>
<name>
XYZ Corporation
</name>
<description>
Outsourced HR Services provider
</description>
<sharedRelationships>
<keyedReference tModelKey=”uuid:...”
keyName=”XYZ Provides HR Services to ACME
Computer Services”
keyValue=”1”>
</sharedRelationships>
</relatedBusinessInfo>
</relatedBusinessInfos>
</relatedBusinessesList>
<find_service>
Given the UUID of a <businessEntity> structure, the name of the ser-vice, the
<tModel> of a specification, or the service category, this message returns a
summary of matching services represented by <serviceInfo> structures contained
within a <serviceList> structure.
The following code shows the syntax for this API:
Semantics of the arguments to this API function have already been discussed
earlier in the “<find_business>” and “<find_relatedBusinesses>” sections and
hence are not covered again to avoid redundancy.
The following code shows the <find_service> XML message that is sent
within the request SOAP message to the UDDI registry. This function call
suggests that the UDDI registry return a list of services that match to the name
pattern ‘Bill’ specified by the <name> element.
<uddi:find_service generic=”2.0”>
<findQualifiers>
<findQualifier>
caseSensitiveMatch
</findQualifier>
</findQualifiers>
<uddi:name>
Bill
</uddi:name>
</uddi:find_service>
<find_binding>
Given the UUID of a <businessService> structure, the <find_bind-ing> message
returns a <bindingDetail> structure containing zero or more <bindingTemplate>
structures matching the criteria specified by the argument list.
42
Semantics of the arguments to this API function have been discussed earlier
and hence will not be covered again.
The following code shows the <find_binding> XML message that is sent
within the request SOAP message to the UDDI registry. This function call
suggests that the UDDI registry return a list of <bindingTemplate> structures that
belong to the service whose key is ‘1245sdef-af35-6a3f-c34a-bf798dab965a’.
<uddi:find_binding serviceKey=
“uuid:1245sdef-af35-6a3f-c34a-bf798dab965a” generic=”2.0”>
<findQualifiers>
<findQualifier>
sortByNameAsc
</findQualifier>
</findQualifiers>
</uddi:find_binding>
<bindingTemplate
bindingKey=”uuid:acd5sdef-1235-6a3f-c34a-bf798dab124a”
serviceKey=”uuid:1245sdef-af35-6a3f-c34a-bf798dab965a”>
<accessPoint URLType=”http”>
http://www.acmecomputerservices.com/
billingservices_entry/
</accessPoint>
<tModelInstanceDetails>
Description and Discovery of Web Services 43
<description>
Provides SOAP Interface. Described
by BillingServices_WSDL.wsdl.
</description>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingDetail>
<find_tModel>
Given a name, a category, or an identifier, this message returns abbreviated
information of all the matching <tModel> structures contained in a <tModelList>
structure.
The syntax for this API is as follows:
Semantics of the arguments to this API function have already been dis-cussed
earlier and hence are not covered again in order to avoid redundancy.
The following code shows the <find_tModel> XML message that is sent
within the request SOAP message to the UDDI registry. This function call
suggests that the UDDI registry return a list of <tModel> structures that match to
the name pattern ‘WSDL’.
<uddi:find_tModel generic=”2.0”>
<name>
WSDL
</name>
</uddi:find_tModel>
SOAP_WSDL_BillingServices
</name>
</tModelInfo>
</tModelInfos>
</tModelList>
All of these get_xx functions are quite straightforward. These functions require
a valid UUID for the data structure whose details need to be drilled down.
Table 5.7 lists these four get_xx functions and an explanation of their
semantics. Also listed in the table are the response structures returned by the
UDDI registry in response to each of these calls.
<uddi:get_businessDetail generic=”2.0”>
<businessKey>
23453aef-af35-6a3f-c34a-bf798dab965a
</businessKey>
</uddi:find_tModel>
46
<discoveryURLs>
<discoverURL useType=”businessEntity”>
http://www.systinet.com/wasp/uddi/
discovery?businessKey=
23453aef-af35-6a3f-c34a-bf798dab965a
</discoveryURL>
</discoveryURLs>
<name>
ACME Computer Services
</name>
<description xml:lang=”en”>
Provides professional services in the areas of computer software
</description>
<contacts>
<contact useType=”information”>
<description xml:lang=”en”>
For sales related information
</description>
<personName>
Joe Smith
</personName>
<address>
1, Computer Drive, Burlington,
MA 01803 USA
</address>
</contact>
</contacts>
<businessServices>
...
</businessServices>
</businessEntity>
</businessDetail>
Description and Discovery of Web Services 47
<description xml:lang=”en”>
Billing Services
</description>
<bindingTemplates>
<bindingTemplate bindingKey=
“uuid:acd5sdef-1235-6a3f-c34a-bf798dab124a”
serviceKey=”1245sdef-af35-6a3f-c34a-bf798dab965a “>
<description xml:lang=”en”>
Here is where you should be visiting to
get started with using billing services
provided by us.
</description>
<accessPoint URLType=”http”>
http://www.acmecomputerservices.com/
billingservices_entry/
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey=
“uuid:acd5sdef-1235-6a3f-c34a-
bf798dab124b”>
<description xml:lang=”en”>
Provides SOAP Interface.
Described by
BillingServices_WSDL.wsdl.
</description>
<instanceDetails>
<overviewDoc>
<description
xml:lang=”en”>
Describes how to use
this service
</description>
<overviewURL>
48
http://www.acmecomputer
services.com/billing_
services_description/
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference keyName=
“Custom Computer Programming Services “
keyValue=”541511”
tModelKey=
“uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2”/>
The next section talks about search qualifiers, one of the arguments to most of
the inquiry API functions.
Search Qualifiers
Most of the inquiry API functions accept <findQualifiers> as arguments. The
<findQualifiers> structure consists of search qualifiers expressed by a
<findQualifier> data structure. The UDDI Programmer’s API specifi-cation
document pre-defines search qualifiers as an enumeration.
Table 5.8 shows some of the most frequently used search qualifiers, rep-
resented by their enumerated values, and explains their semantics.
Description and Discovery of Web Services 49
ENUMERATED SEARCH
QUALIFIER DESCRIPTION
exactNameMatch When this search qualifier is specified, only the entries
that exactly match the name pattern passed in the
<name> argument would be returned in the result.
caseSensitiveMatch This search qualifier signifies that case sensitive
matching between entries has been searched and the
entry has been specified by the <name> argument.
sortByNameAsc This is the default sort qualifier, if no other conflicting
sort qualifier is specified.
sortByNameDesc This signifies that the result returned by a find_xx or
get_xx Inquiry API call should be sorted based on the
name field in descending alphabetic sort order.
sortByDateAsc This is the default sort qualifier, if no other conflicting
sort qualifier is specified. Also, the sort qualifiers
involving a date are secondary in precedence to the
sortByName qualifiers. This causes the sortByName
elements to be sorted within name by date, oldest to
newest.
sortByDateDesc Also, because the sort qualifiers involving dates are
secondary in precedence to the sortByName
qualifiers, this causes sortByName elements to be
sorted within name by date, newest to oldest.
With this, now we will proceed to the publishing API of the UDDI registry.
Publishing API
This section will cover all of the XML messages that perform the function-ality
of adding/modifying/deleting information from a UDDI registry. As mentioned
earlier, publishing to a UDDI registry requires an authenticated access. UDDI
specification does not define authentication mechanisms, and hence,
authentication is dependent upon the implementations of UDDI. Also, a URL
different from an inquiry URL usually handles publishing-related API calls.
Typically, HTTPS is used for carrying pub-lishing call request/response
information.
Table 5.9 lists the publishing API functions as well as their semantics. The
table also lists the structure that is returned in response to each of these function
calls.
50
Table5.9 PublishingAPIFunctions
PUBLISHING RETURNED
APIFUNCTION STRUCTURE DESCRIPTION
TheUDDIregistrynodewillreturnanauthenticationtokeninresponsetothismessageinan<authToken>
structure.
:AvalidauthenticationtokenisrequiredinordertoNoteexecutefunctioninthepublishingAPI
<dispositionRep .any
<discard authToken> ort>
ThemessageinformsaUDDIregistrynodetodiscardtheactiveauthenticationsessionassociatedwiththisuser,essentiallyresultinginto
alogoffoperation.
ThismessageshouldbesenttotheUDDIregistrynodeaftertheexecutionofpublishingoperationshasbeenco
mpleted.
UDDIerrorsarecommunicatedtotheclientasSOAPfaultmessages.TheUDDIdatastructuremapstothe<dispositionReport><detail>structuralelementoftheSOAPfaultmessage.Thus,isusedinallthecaseswhere<dispositionReport>errorsneedtobecommuni
cated.However,UDDIalsousesthisstructuretocommunicatesuccessesinnon-errorsituations.Themessage<dispositionReport>isalwaysreturnedinresponsetodeletexxormessages.<discardauthToken>
PUBLISHING RETURNED
APIFUNCTION STRUCTURE DESCRIPTION
Thismessageconsistsof structure(s)<businessEntity>correspondingtotheoneormorebusinessinstancesthatneedtobeadded/modifiedtotheUDDIregistry.
Theregistryresponseconsistsofthe<businessDetail>structurecontainingthefulldetailsofthebusinessthathasjustbeenadded/modified.
<dispositio
<delete
business> nReport>
ThismessagesuggeststhattheUDDIregistrydeletebusinessescorrespondingtothekeysspecifiedwithinthemessage.Deleting<deletebusiness>businesseswouldcausethedeletionofanycontainedaswellas<businessService><bindingTemplate>structures.Alsoany<publisher
Assertion>structurescreatedwiththeUUIDofthisbusinesswouldbedeletedfromtheregistry.
Thismessageconsistsof<businessService>structure(s)correspondingtotheservice(s)thatneedtobeadded/
modifiedtotheUDDIregistry.Changestoanexistingstructurecanimpact<businessService>existingreferencestostructures.<bindingTemplate>
Description and Discovery of Web Services
Theregistryresponseconsistsofthe<serviceDetail>structurecontainingthefulldetailsoftheservice(s)thathavejustbeenadded/modified.
(continues)
51
52
Thismessageinformstheregistrytodeletetheservice(s)instancescorrespondingtotheUUIDkey(s)specifiedwithinthemessage.<d
<delete service> <dispositionReport> eleteservice>
Theregistryresponsetothismessageconsistsofthestructurecontainingthefulldetails<bindingDetail>ofthebinding(s)thathavejustbeenadded/
<save binding> <bindingDetail> modified.
Thismessageinformstheregistrytodeleteoneormoreinstancescorrespondingtothe<bindingTemplate>UUIDkey(s)specifiedwithinthe<deleteb
<delete binding> <dispositionReport> inding>message.
Theregistryresponsetothismessageconsistsofthestructurecontainingthefulldetailsof<tModelDetail>theinstancesthathavejustbeen<tMod
<save tModel> <tModelDetail> el>added/modified.
Thereasonfornotcompletelydestroying<tModel>instancesistoenableorganizationsstillusingthatspecificstructuretogetbasicdetailsabou
<delete tModel> <dispositionReport> tit.<tModel>
Thismessagereturnsalistof<publisherAssertion>structuresthatwerepublishedbythisregistryus
<get publisherAssertions> <publisherAssertions> er.
Thismessage
theadds<publisherAssertion>structurescontainedwithinthismessagetothelistofexistinginstancesassociated<publisherAssertion>withthisregistryus
<add publisherAssertions> <dispositionReport> er.
PUBLISHING RETURNED
APIFUNCTION STRUCTURE DESCRIPTION
Thisreturnsa
<set publisherAssertions> <publisherAssertions> structureas<publisherAssertions>partoftheresponse,containingacollectionofthereplacingstructures.<publisherAssertion>
Thisisaqueryfunctionthatreturnsalistofalltheinstances,createdbythis<publisherAssertion>registryuserorothers,aspartofthestructure,whichinvolvesthe<assertionStatusReport>instan
<get assertionStatusReport> <assertionStatusReport> cepublishedbythisregistry<businessEntity>user.
Themessagereturnsalistofalltheand
<get registeredInfo> <registeredInfo> documentsthat<businessEntity><tModel>aremanaged(owned)bythisregistryuser.
Description and Discovery of Web Services
53
54
Implementations of UDDI
The UDDI specification enjoys tremendous amounts of vendor support. There
are a lot of offerings in the UDDI space. Vendors provide UDDI support in two
ways:
UDDI client. Almost all of the vendors participating in the UDDI space
provide UDDI client support. A UDDI client basically provides APIs
required for working with the UDDI registry. These APIs can be in a
variety of languages such as Java, C++, Python, and so on. Note that most
of the vendors, as of this writing, provide proprietary implementations of
Java APIs for UDDI. JSR-093 JAXR is an effort to provide a standard Java
API for communicating with UDDI reg-istries. Because the JAXR
specification has just recently been final-ized, vendors should now be able
to start providing support for JAXR in their API implementations. The
JAXR specification is cov-ered in more detail in Chapter 11, “Java API for
XML Registries.” The examples covered in this chapter do not make use of
JAXR APIs.
* UDDI examples in this chapter are developed using Systinet WASP UDDI APIs.
Description and Discovery of Web Services 55
Figure 5.6 shows registering a user with login ID: registry_user and
password: registry_user.
Our examples will make use of this account, in order to authenticate to the
UDDI registry. Hence, before trying to run the examples, please ensure that this
account does exist in the Systinet public UDDI registry. If it does not, create a
new account with the same credentials. If you are unable to create the account
with the same credentials, then create an account with different credentials
followed by changing the hard-coded login ID and password to the new account
login ID and password, in SubmitBusiness .java and DeleteBusiness.java, and re-
compiling them.
Now, let ‘s proceed with submitting new business information to the UDDI
registry.
package jws.ch5;
import org.idoox.uddi.client.api.v2.*;
import org.idoox.uddi.client.api.v2.request.publishing.*; import
org.idoox.uddi.client.structure.v2.business.*; import
org.idoox.uddi.client.structure.v2.base.*; import
org.idoox.uddi.client.api.v2.response.*; import org.idoox.uddi.*;
doSubmit();
}
System.out.println(“Name: “ + sBusinessName);
System.out.println(“Description: “ +
sBusinessDescription);
UDDIApiPublishing objUDDIApiPublishing =
UDDILookup.getPublishing(“https://www.systinet.com:443
/wasp/uddi/publishing/”);
// registry_user password.
}
else
{
System.err.println(“\nSuccessful in submitting the new business
information to registry.”);
}
return;
}
}
4. Now, check whether the businesses are found matching the given
criteria. If there are matching businesses, we need to traverse through
their BusinessInfo structures and get hold of the name and key UUID of
the business.
package jws.ch5;
import org.idoox.uddi.*;
if (args.length != 1)
{
printUsage();
}
else
{
String sNameOfBusiness = args[0];
// criteria
if (objBusinessList==null)
{
System.err.println(“No businesses were found matching the
criteria.”);
}
else
{
/ Get hold of the BusinessInfo objects,
/ contained by BusinessList BusinessInfos
objBusinessInfos =
objBusinessList.getBusinessInfos();
BusinessInfo objBusinessInfo =
objBusinessInfos.getFirst();
BusinessKey objBusinessKey;
if (objBusinessInfo != null)
{
objBusinessKey=objBusinessInfo.
getBusinessKey();
System.out.println(“Business UUID = “ +
objBusinessInfo.getBusinessKey());
System.out.println(“----------------
---------------------------------”);
}
}
}
}
}
package jws.ch5;
import org.idoox.uddi.*;
import org.idoox.uddi.client.api.v2.*;
import org.idoox.uddi.client.api.v2.request.publishing.*; import
org.idoox.uddi.client.api.v2.response.*; import
org.idoox.uddi.client.structure.v2.business.*;
{
if (args.length != 1)
{
printUsage();
}
else
{
BusinessKey objBusinessKey =
new BusinessKey (args[0]);
doDelete(objBusinessKey);
}
}
UDDIApiPublishing objUDDIApiPublishing =
UDDILookup.getPublishing(“
https://www.systinet.com:443/wasp/uddi/publishing/”);
new org.idoox.uddi.client.api.v2.request.
publishing.DeleteBusiness();
System.out.println(
objDispositionReport.toXML());
}
}
}
}
Limitations of UDDI
UDDI is an evolving standard. Currently, the most deployed version of UDDI
(2.0) is limiting in terms of the information model that it supports, especially
when compared to other registry specifications such as ebXML
Registry/Repository. UDDI provides support for storing only the basic data
structures, such as businesses, users, services, and service technical descriptions.
However, storing information about business Web services requires more than
just the basic support. For example, potential users of business Web services
should be able to publish/query extensive business-oriented information, such as
the business process models that a particular business Web service relies upon.
This is possible only if the target registry provides a data structure representing
the business process model. Thus, an information model is an important feature
for any registry. Registry information model, are further discussed in Chapter 11,
“Java API for XML Registries.”
Summary
In this chapter we discussed in detail how to describe and discover Web services.
In this regard, we discussed two very important technologies in the Web services
space: WSDL and UDDI. We also discussed how to use WSDL and UDDI for
describing, publishing, and discovering Web services using various tools in this
chapter. In the next chapter, “Creating .NET Interoperability,” we will see how to
achieve interoperability between Java Web services and .NET Web services.