0% found this document useful (0 votes)

114 views71 pages

Unit-4 Wssoa

This chapter discusses the description and discovery of Web services, focusing on technologies like WSDL and UDDI. It explains how WSDL defines the interface, data types, and binding information for Web services, enabling interoperability across different platforms. The chapter also outlines the Web service life cycle, detailing the steps from publishing a service to invoking it using SOAP requests.

Uploaded by

Venkatesh Ramineni

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

114 views71 pages

Unit-4 Wssoa

Uploaded by

Venkatesh Ramineni

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 71

CHAPTER

UNIT-IV

Description and Discovery

of Web Services

In Chapter 4, “Developing Web Services Using SOAP,” we saw how to develop

and deploy Web services that use the Simple Object Access Proto-col, or SOAP.
But there is more to Web services than just SOAP support. A Web service can
further its capabilities by supporting a description of its interfaces so that its
potential users can study it and determine whether the Web service supports the
behavior that they need. Also, an organization that develops Web services can
register these Web services at a location that is well known, so that its potential
users can discover them.
This chapter covers such description and discovery aspects of a Web service.
Detailed information is provided on two mainstream technologies that are used
today for describing and discovering Web services: the Web Services Description
Language (WSDL) and Universal Description, Dis-covery, and Integration
(UDDI). Furthermore, examples demonstrate how to use these technologies in
the real world.
The following are key topics covered in this chapter:
■ Web Services Description Language (WSDL)
■ WSDL in the World of Web services
■ Anatomy of a WSDL definition document
■ WSDL bindings
■ WSDL tools
1
2

■ Universal Description, Discovery, and Integration (UDDI)

■ Programming with UDDI
■ Inquiry APIs
■ Publishing APIs
■ Implementations of UDDI
■ Registering as a Systinet UDDI Registry user
■ Publishing information to a UDDI registry
■ Searching information in a UDDI registry
■ Deleting information from a UDDI registry

Web Services Description Language (WSDL)

Microsoft, IBM, and Ariba released the first version of the WSDL specifica-tion
jointly, in September 2000, briefly after announcing a UDDI specification along
with 36 other companies. This version of WSDL was based on two precedent
description languages: Network Accessible Services Specification Language
(NASSL) and (SOAP Contract Language SCL), from IBM and Microsoft,
respectively. Later on in March 2001, the same companies joined by a few others
submitted the WSDL 1.1 specification to W3C. Thus, cur-rently the WSDL
specification is in works at W3C. Officially, it is a W3C Note that forms the
basis of the upcoming WSDL 1.2 specification from W3C. This chapter goes into
detail in understanding WSDL 1.1.
JSR 110 (Java API for WSDL) is currently in the works in the Java Com-
munity Process (JCP). When released, it will provide an API for manipulat-ing
WSDL documents instead of directly interacting with the XML syntax of WSDL.
This would avoid manipulating the WSDL documents with the help of low level
APIs such as JAXP. JWSDL would be much easier and faster to use, simplifying
things further for a developer. More information on JWSDL can be obtained
from the JCP Web site at www.jcp.org/jsr/detail/110.jsp.

WSDL in the World of Web Services

WSDL, as we know, is a description language for Web services. So what does
this exactly mean? This means that WSDL represents information about the
interface and semantics of how to invoke or call a Web service. A WSDL
definition contains four important pieces of information about the Web service:
Description and Discovery of Web Services 3

■ Interface information describing all the publicly available functions

■ Data type information for the incoming (request) and outgoing
(response) messages to these functions
■ Binding information about the protocol to be used for invoking the
specified Web service
■ Address information for locating the specified Web service
Once we develop a Web service, we create its WSDL definition. We can
create this definition either manually or by using a tool. Many tools are available
for generating a WSDL definition from existing Java classes, J2EE components
(such as Servlets/EJBs), or from scratch. Once the WSDL def-inition is created, a
link to it is published in a Web services registry (based on UDDI, for instance),
so that the potential user(s) of this Web service can follow this link and find out
the location of the Web service, the function calls that it supports, and how to
invoke these calls. Finally, the user(s) would use this information to formulate a
SOAP request or any other type of request based on the binding protocol
supported, in order to invoke the function on a Web service.

Web Service Life Cycle

Figure 5.1 illustrates the steps of the Web service life cycle.

Look Up the Web Service

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

Web Service Provider

Figure 5.1 Web service life cycle.

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.

Language and Platform Independency of WSDL

WSDL is capable of describing Web services that are implemented using any
language and deployed on any platform. Thus, WSDL contributes toward
enabling interoperability in the Web service architecture. In other words, as long
as a WSDL definition can be understood and consumed by the service user, the
service user systems can obtain all of the information necessary to invoke a Web
service potentially developed and deployed using a completely different set of
platform tools and servers.
Now, let’s see what a typical WSDL document looks like and understand its
structural elements.

Anatomy of a WSDL Definition Document

A WSDL definition document consists of the following seven key struc-tural
elements:
Description and Discovery of Web Services 5

<definitions>. A WSDL document is a set of definitions. These definitions

are defined inside the <definitions> element, which is the root element in a
WSDL document. It defines the name of the Web service and also declares
the namespaces that are used throughout the rest of the WSDL document.

<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.

<portType>. This element defines the abstract definition of the oper-ations

supported by a Web service, by combining various request and response
messages defined by <message> elements. Each operation refers to an input
message and an output message.
<binding>. his element specifies a concrete protocol and data for-mat used
for representing the operations and messages defined by a particular
<portType>, on the wire.
<port>. This element specifies an address for binding to the Web service.

<service>. This element aggregates a set of related <port> ele-ments, each

which uniquely specify the binding information of the Web service. A
<service> consisting of multiple <port> elements essentially represents the
capability of the service to be invoked over multiple bindings. More
information on WSDL bindings is discussed in the next section.

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”?>

<message name=”GetWeatherInfoOutput”>
<part name=”WeatherInfo”
Description and Discovery of Web Services 7

element=”xsd1:WeatherInfo”/>
</message>

</portType>

<soap:binding style=”document”
transport=”http://schemas.xmlsoap.org/soap/http”/>

<soap:operation soapAction=
“http://myweather.com/GetWeatherInfo”/>

<documentation>
Provides Weather Information
</documentation>

Listing 5.1 WeatherInfo.wsdl. (continued)

Now, let’s understand how exactly WeatherInfo.wsdl describes the

WeatherInfoService Web service.

<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.

Default namespace for a WSDL document. The default namespace is

specified by xmlns=”http://schemas.xmlsoap.org/wsdl/”. The default
namespace indicates that all of the elements in this WSDL definition
without a namespace prefix, such as <types>, <message>, and <portType>,
are part of this namespace.

<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.

Note the use of WeatherInfo.wsdl as a target namespace by the <input> and

<output> elements.
Four types of operations are supported by WSDL:
One-way operation. One-way operation represents a service that just
receives the message, and thus a one-way operation is typically defined by
a single <input> message element.
Request-response operation. A request-response operation repre-sents a
service that receives a request message and sends a response message.
Typically, a request-response operation is defined by one <input> message
followed by one <output> message. An optional <fault> element also can
be included in the definition of a request-response operation to specify the
abstract message format for any error messages that may be output as a
result of the operation.

The GetWeatherInfo operation follows the request-response

transmission pattern.
Solicit-response operation. A solicit-response operation represents a service
that sends a request message and that receives the response message. Such
operations are therefore defined by one <output> message, followed by an
<input> message. A solicit-response opera-tion also can include a <fault>
element in order to specify the for-mat of any error messages resulting from
the operation.
Notification operation. This operation represents a service that sends a
message, hence this kind of operation is represented by a single <output>
element.

Figure 5.2 provides the pictorial representation of the previous four

transmission types.
10

CLIENT SERVICE

One-way <input>

Request- <input>
Response <output>

<output> Solicit-
<input> Response

<output> Notification

Figure 5.2 WSDL operation types.

<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.

WSDL Binding Extensions

WSDL allows user-defined elements, also known as Extensibility Elements,
under various elements defined by a default WSDL namespace. These ele-ments
are commonly used to specify some technology-specific binding, although they
can be used for other purposes as well. Extensibility ele-ments, when used to
specify a technology-specific binding, are known as WSDL Binding Extensions.

Extensibility elements provide a powerful mechanism for extending WSDL

because they enable support for network and message protocols to be revised
without having to revise the WSDL specification.
The base specification of WSDL defines three WSDL binding extensions,
which are as follows:
■ SOAP binding
■ HTTP GET & POST binding
■ MIME binding
We will take a look at the most commonly used WSDL binding exten-sion, the
SOAP binding, in a later section titled SOAP Binding.

WSDL Binding Support for Operations

All four types of operations supported by WSDL—one-way, request-response,
solicit-response, and notification—represent an abstract notion only. Binding
describes the concrete correlation to these abstract notions. Binding determines
how the messages are actually sent, for instance, within a single communication
(for example, an HTTP request/response) or as two independent communications
(for example, two HTTP requests). Thus, binding for a specific operation type
must be defined in order to successfully carry out that type of operation. Note
that although the WSDL structure supports the bindings for these four operations,
the WSDL
12

specification defines bindings for only one-way and request-response operations.

Hence, in order to use WSDL to describe services that support solicit-response
and/or notification types of operations, the communica-tion protocol of the Web
service must define the WSDL binding extensions, thus enabling the use of these
operations.
Let’s now take a look at SOAP binding as defined by the WSDL 1.1
specification.

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”/>

The <soap:operation> element defines the information with regard to

communication style and the SOAP action header at that specific opera-tion
level.
The semantics of the style attribute remains the same as that for a
<soap:binding> element.
The soapAction attribute specifies the value of a SOAP action header in the
form of a URI. The usage of the SOAP action header was discussed in Chapter 4,
“Developing Web Services Using SOAP.”

<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

Consider the following example:

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.

WSDL compilation. A typical WSDL compiler would generate the necessary

data structures and a skeleton for the implementation of the service. The
generated implementation skeleton contains all the meth-ods (operations)
that are described in the given WSDL definition.
WSDL proxy generation. This functionality can read a WSDL and
produce a specific language binding (for example, Java or Perl)
consisting of all the code required to bind the Web service and to
invoke the Web service functions at runtime. This functionality is
typically used at the client end.

Many WSDL tools provide support for these three functionalities.

Table 5.1 lists some of the famous ones in the Java Web Services space.
Description and Discovery of Web Services 15

Table 5.1 WSDL Tools

TOOL DOWNLOAD FROM ...

Sun ONE Studio 4 wwws.sun.com/software/sundev/jde/index.html
Systinet WASP www.systinet.com/wasp
The Mind Electric GLUE www.themindelectric.com/glue/index.html
IBM Web Services Toolkit www.alphaworks.ibm.com/tech/webservicestoolkit/
BEA WebLogic Workshop www.bea.com/products/weblogic/workshop
/easystart/index.shtml
Apache Axis http://xml.apache.org/axis

In the following section, we examine the WSDL tools provided by the Systinet
WASP platform.

Support for WSDL in Systinet WASP 4.0

Systinet WASP provides two tools for working with WSDL: Java2WSDL and
WSDL Compiler. Both of these tools accomplish two different types of
functionalities related to WSDL:
Generating WSDL from a Java class that is a potential candidate for a
Web service. his functionality is taken care of by the Java2WSDL tool.

Generating Java code from an existing WSDL. This functionality is

taken care of by the WSDL Compiler.
We will check out both these tools in the following two sections.

Generating WSDL from a Java Class

In situations in which an implementation of the Web service has already been
created first, the Java2WSDL tool can be used to generate WSDL. This tool
provides a lot of options for generating WSDL from an existing Java
implementation.
To understand the functioning of this tool, consider the following
Java class:

package jws.ch5;

public class WeatherInfoJavaService

{
public float GetWeatherInfo (String sCountry, String sZip,
16

String sInstance)
{
/ Talk to some backend services to get hold
/ of the weather information

/ Return the weather information;

/ a manipulated value for now.
return 65.0f;
}

public void SetWeatherInfo (String sCountry, String sZip, String sInstance, String
sTemperature) {

/ Update the backend weather databases

/ with this information
}
}

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:

> Java2WSDL jws.ch5.WeatherInfoJavaService --package-mapping

“jws.ch5=http://www.myweather.com/WeatherInfo” --output-file-mapping
“http://www.myweather.com/WeatherInfo=
WeatherInfo.wsdl” —output-directory jws/ch5

This command would generate WeatherInfo.wsdl and place it in the

%DEMO_DIR%/jws/ch5 directory. Table 5.2 gives the explanation of the
arguments used in the previous command.
Description and Discovery of Web Services 17

Table 5.2 Java2WSDL Command Line Options

Package mapping Whenever a Java class is processed by a Java2WSDL

tool, it assumes that the package namespace is the
target namespace as well. Hence, in order to
provide a new mapping of package name to the
WSDL namespace, this argument must be provided.
Outputfile mapping By default, the Java2WSDL tool would generate a
WSDL document named as the package namespace,
preceded by “Definitions_”. Thus, in order to
give a new name to the WSDL definition document,
we can use this argument.
Output directory This argument specifies the directory where the
output WSDL definition would be stored. The
default is the current directory.

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”>

<xsd:element name=”sCountry” nillable=”true”

Listing 5.2 WeatherInfo.wsdl generated by the Java2WSDL tool. (continues)

type=”xsd:string”/>

<xsd:element name=”sZip” nillable=”true”

type=”xsd:string”/>

<xsd:element name=”sInstance” nillable=”true”

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>

<wsdl:portType name=’WeatherInfoJavaService’> <wsdl:operation

name=’GetWeatherInfo’ parameterOrder=’sCountry sZip
sInstance’>
<wsdl:input message=

Listing 5.2 WeatherInfo.wsdl generated by the Java2WSDL tool.

Description and Discovery of Web Services 19

‘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>

<wsdl:operation name=’SetWeatherInfo’> <map:java-operation

name=’SetWeatherInfo’ signature=’KExq...’/>

Listing 5.2 WeatherInfo.wsdl generated by the Java2WSDL tool. (continues)

<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>

Listing 5.2 WeatherInfo.wsdl generated by the Java2WSDL tool. (continued)

Generating Java Code from an Existing WSDL

In situations in which WSDL definitions are created before actually imple-
menting a Web service, the WSDLCompiler tool of WASP can be used to
generate the skeleton of a Java interface. A Java class consisting of the actual
method implementations then can implement this generated Java interface.

The usage of the WSDLCompiler tool is as follows:

> WSDLCompiler WeatherInfo.wsdl

In this case, a Java interface with the name WeatherInfoJavaService is created

as shown in Listing 5.3.
Description and Discovery of Web Services 21

/**

*/
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 */

Listing 5.3 WeatherInfoJavaService Java class generated by the WSDLCompiler tool.

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.

Universal Description, Discovery,

and Integration (UDDI)
As already discussed, UDDI technology is the core and one of the building
blocks of Web services apart from SOAP and WSDL. UDDI enables the busi-
nesses providing services (in electronic form or in any other medium) to reg-ister
information to enable the discovery of their services and business profile by
prospective customers and/or partners. Similarly, it enables businesses to
discover other businesses for expanding potential business partnerships. Thus,
UDDI presents businesses with an opportunity to step
Description and Discovery of Web Services 23

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.

Public and Private UDDI Registries

A UDDI registry can be operated in two modes: public mode and private mode.
A public UDDI registry is available for everyone to publish/query the business
and service information on the Internet. Such public registries can be a logical
single system built upon multiple UDDI registry nodes that have their data
synchronized through replication. Thus, all the UDDI reg-istry node operators
would each host a copy of the content and accessing any node would provide the
same information and quality of service as any other operator node. Such global
grouping of UDDI registry nodes is known as a UDDI Business Registry, or
UBR. Content can be added into a UBR from any node, however, content can be
modified or deleted only at a node at which it was inserted.

A private UDDI registry is operated by a single organization or a group of

collaborating organizations to share the information that would be avail-able only
to the participating bodies. Private UDDI registries can impose additional
security controls to protect the integrity of the registry data and to prevent access
by unauthorized users. Note that a private node also can participate in
information replication.
A UDDI registry in itself is a Web service. A Web service consumer queries
the UDDI registry using the SOAP API defined by UDDI specifica-tion. Also,
the UDDI specification publishes a WSDL description of the UDDI registry
service.
24

The UDDI project community members operate a UBR. This registry is

available to everyone for free publishing/querying of businesses and ser-vices
information. To find more information on this publicly operated UDDI registry,
visit the UDDI Web site at www.uddi.org.

Interacting with a UDDI Registry

Typically, vendors implementing a UDDI registry provide two ways of
interacting with a UDDI Registry Service.
■ A graphical user interface (GUI), for interacting with a UDDI reg-istry.
These GUIs also can be browser-based. The following is a list of public
UDDI registries, operated by various companies such as Microsoft, IBM,
Hewlett Packard, and so on, that provide a browser-based interface to these
registries:
■ https://uddi.rte.microsoft.com/search/frames.aspx
■ https://www-3.ibm.com/services/uddi/v2beta/protect
/registry.html
■ https://uddi.hp.com/uddi/index.jsp
■ http://udditest.sap.com/
■ http://www.systinet.com/uddi/web
Figure 5.3 shows a browser-based GUI provided by Systinet in order to
interact with its publicly hosted UDDI registry. This screenshot depicts the
interface provided for searching businesses registered with the Systinet registry.

Figure 5.3 Web-based GUI to UDDI registry.

Description and Discovery of Web Services 25

■ A programmatic interface for communicating with the UDDI reg-istry.

These programmatic interfaces are based on SOAP, because the UDDI
registry supports SOAP as the communication protocol.
■ Most of the vendors providing the UDDI registry implementa-tions
support both of these types of access to the registry.

Uses of UDDI Registry

Businesses can use a UDDI registry at three levels:
White pages level. Businesses that intend to register just the very basic
information about their company, such as company name, address,
contact information, unique identifiers such as D-U-N-S numbers or
Tax IDs, or Web services use UDDI as white pages.
Yellow pages level. Businesses that intend to classify their informa-tion
based on categorizations (also known as classification schemes or
taxonomies) make use of the UDDI registry as yellow pages.
Green pages level. Businesses that publish the technical information
describing the behavior and supported functions on their Web ser-vices
make use of the UDDI registry as green pages.
Note that the UDDI specification does not explicitly make references to these
different types of usage levels of the UDDI registry. The categoriza-tion of these
levels is rather implicit.

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:

■ Node operators’ responsibility for durable recording and backup of all

data.
26

■ Checking the validity of information provided by businesses

during registration, such as email addresses.
■ Checking the integrity of data in the UDDI registry after it has been
modified. For example, if a business has been deleted from the
registry, then the operator should ensure that the services
corresponding to this business also are deleted.
Note that private UDDI node operators are not required to follow the
guidelines mentioned in this document.
UDDI programmer’s API. This document describes the programming
interfaces supported by a UDDI registry in terms of SOAP messages. This
document is targeted towards programmers who want to write software that
would interact with a UDDI registry operated at a pub-lic or private level,
using SOAP.

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.

Programming with UDDI

This section introduces the APIs used for communicating with a UDDI reg-istry.
Also, important data structures and categorization support of UDDI are
discussed.

UDDI Programming API

The UDDI specification defines two XML-based programming APIs for
communicating with the UDDI registry node: inquiry API and publishing API.
The following sections describe each of these.
Inquiry API
The inquiry API consists of XML messages defined using a UDDI Schema,
which can be used to locate information about a business, such as the ser-vices a
business offers and the technical specification of those services (such as a link to
a WSDL document describing the interface of the service, the binding of the
service and the URL where the service is running, and so on). A UDDI
programmer would use these inquiry APIs to retrieve information
Description and Discovery of Web Services 27

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.

Table 5.3 Access Point URLs

OPERATOR INQUIRY URL PUBLISHING URL

Microsoft http://uddi.microsoft.com/inquire https://uddi.microsoft.com
/publish
IBM http://www-3.ibm.com/services https://www-3.ibm.com
/uddi/inquiryapi /services/uddi/protect
/publishapi
HP http://uddi.hp.com/inquire https://uddi.hp.com/publish
SAP http://udditest.sap.com/uddi https://udditest.sap.com
/api/inquiry /uddi/api/publish
Description and Discovery of Web Services 29

Note that all the UDDI invocations follow a synchronous request/response

mechanism and are stateless in nature. This statelessness has a significant impact
on the authentication of a registry user to the UDDI registry, which is required
when performing a publishing operation on the registry. Because of the stateless
nature of the UDDI programming API, each time a registry user uses a
publishing programming API, the security credentials of the identity associated
with the registry user also are passed with each UDDI invocation.

UDDI Data Structures

The information managed by a UDDI registry is represented as XML data
structures also known as UDDI data structures. The UDDI data structures
specification document defines the meaning of these data structures and the
relationship between them. Ultimately, it is these data structures with which a
UDDI client needs to work. A UDDI client makes use of these, in conjunction
with the XML messages of programming APIs, to manipulate a specific type of
information in a registry. Similarly, response to a search operation received from
the UDDI registry also would consist of these data structures. Hence, the UDDI
data structures are more or less input and out-put parameters for the UDDI
programming API.
The following are the five primary UDDI data structures defined in the
specification:
■ <businessEntity>
■ <publisherAssertion>
■ <businessService>
■ <bindingTemplate>
■ <tModel>
Note that all of these data structures except <publisherAssertion> are
identified and referenced through a 128-bit globally unique identifier also known
as UUID. These UUIDs can later be used as keys to access the specific data
within the registry.
Now, let’s take a look at each of these one by one.

<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.

A very interesting aspect about relationships in a UDDI registry is its ability to

not make the relationship visible to the public unless and until both of the parties
establishing this association assert for the same. This means that if a
<businessEntity> structure representing Company A asserts its relationship with
a <businessEntity> structure representing Company B through a
<publisherAssertion> structure, a UDDI reg-istry would not make this
relationship public until Company B has created another similar
<publisherAssertion> structure. This provision is supported by the UDDI
registries in order to ensure that a company can claim a business relationship
with another company, only if the other part-ner also asserts for the same
relationship.
<businessService>
The <businessService> data structure represents the service of a busi-ness. These
services can be Web services or any other type of service. For example, the
<businessService> data structure may represent a service that is offered over the
telephone, such as a telephone banking service. The <businessService> data
structure is merely a logical representation of services that a business has to offer.

A <businessEntity> structure contains one or more <businessService>

structures. The same <businessService> struc-ture also can be used by multiple
<businessEntity> structures. For example, if a business has two departments—
say, manufacturing and sales— that are each published to a UDDI registry as a
<businessEntity> structure, then both of them can use the same
<businessService> struc-ture representing another business service—say, legal
counseling.
<bindingTemplate>
The <bindingTemplate> structure consists of pointers to technical descriptions
and access URLs of the service. Each <businessService>
Description and Discovery of Web Services 31

structure can contain one or more <bindingTemplate> structures. So, for

example, if the <businessService> structure represents a Web ser-vice, then its
<bindingTemplate> would refer to a PDF document pro-viding the technical
description of this Web service and the URL at which the Web service can be
accessed. Also, the <bindingTemplate> structure can provide an optional
description of the Web service.
Note that the <bindingTemplate> structure does not provide the details of the
service specification, such as the interface of a service. That information is
provided by the <tModel> structures, and <bindingTemplate> simply refers to
one or more of such <tModel> 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

Information about the party Information about the

who publishes information relationship between two parties,
about a family of services asserted by one or both parties

Descriptive information about a Descriptions of specifications for services

particular Web service (or categorization systems)

<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.

Figure 5.4 Primary UDDI data structures.

<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

Support for Categorization in UDDI Registries

Categorization—also known as classification in JAXR terminology—is con-
sidered to be the prominent functionality of any registry. Categorization enables
the data to be classified with the help of various categorization sys-tems (also
known as taxonomies or classification schemes), such as an indus-try
categorization system or a geography categorization system. For example, a
business can be classified as being located in the United States with the help of a
standard geography categorization system such as ISO-3166.
Categorizing data aids in searching for a particular piece of data. For example,
searching for a software organization whose name begins with the letter M is
much easier when that data is categorized as being located in Redmond,
Washington, than when it is not. Searching by the letter M for an organization
that does not have a geographical categorization returns a much broader set of
results, thus making it much more difficult to discover the business in which one
is interested. Hence, categorization is especially useful in the discovery of
information managed by a UDDI registry.
UDDI registries have built-in support for three industry standard cate-
gorization systems. Also, the registry specification enables support for an open-
ended categorization system that can be used in specific ways by a UDDI registry
node operator. In UDDI, the categorization system is repre-sented by a <tModel>
structure. These <tModel> structures have a unique name across all the UDDI
registry node operators; however, the <tModel> UUID may change between the
node operators.
UDDI-Supported Categorization Systems
The UDDI supported categorization systems and their <tModel> names are
shown in Table 5.4.
Checked and Unchecked Categorization System
UDDI version 2.0 included the capability of validating the categorization of a
particular UDDI data structure. Depending upon whether an organi-zation
chooses to use the validation service of a UDDI registry, one of the two types of
categorization systems will be supported:
Checked categorization system. Checked categorization systems are used
when the publisher of a categorization system wishes to ensure that the
categorization code values registered represent accurate and validated
information. The categorization code values represented by UDDI structure
<categoryBag> would be checked for valid values during a
<save_business>, <save_service>, or <save_tModel> API call.
34

Table 5.4. UDDI-Supported Categorization Systems and Their <tModel> Names

CATEGORI- <TMODEL> NAME DESCRIPTION

ZATION
SYSTEM
NAICS ntis-gov:naics This is a standard industry and services
:1997 categorization system. NAICS abbreviates to
the North American Industry Classification
System. This system is the most elaborate
and comprehensive industry classification
scheme defined so far. Further information
on this categorization system can be
obtained from www.census.gov/epcd/www
/naics.html.
UNSPSC unspcs-org This standard industry and services
:unspsc:3-1 categorization system abbreviates to the
Universal Standard Products and Services
Classification. This was the first such
industry classification scheme defined for
electronic businesses. Further information
on this categorization system can be
obtained from www.unspsc.org.
ISO 3166 iso-ch:3166 This is the standard geography-based
:1999 categorization system. Further information
can be found at www.din.de/gremien/nas
/nabd/iso3166ma.
Operator uddi-org:general This categorization system is operator
Specific _keywords specific. This is an open-ended
categorization system that is not pre-
defined. As a result, it can consist of any
category entries that may be defined
specifically for that UDDI registry node.

UDDI version 2 also enables third parties registering new categoriza-tion

systems to control the categorization validation process. In such case, the
third party would implement a Web service, in the same manner as UDDI
does, that exposes a single XML API function named <validate_values>.

Unchecked categorization system. Unchecked categorization systems are

used for categorization without the need for a UDDI to perform validation
of categorization code values. Businesses can choose to
Description and Discovery of Web Services 35

make their categorization system available for categorization as an

unchecked categorization system. Registering a new <tModel> structure
and categorizing that <tModel> as a categorization system would register it
as an unchecked categorization system.
Now, let’s take a look at the available programming APIs for searching
information in a UDDI registry.

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.

Find_xx Inquiry API Functions

The find_xx functions follow the browse pattern. The browse pattern typi-cally
involves starting with some broad information, performing a search, finding
general result sets, and then selecting more specific information for drill-down
purposes.
The find_xx calls form the search capabilities such that the summary of
matched results are returned in the response message. Hence, a UDDI client
would get the overview information about the registered data by using find_xx
inquiry API calls. Once the client gets hold of the key for one of the primary
UDDI data structures, it then can use get_xx inquiry API functions to get further
details.
<find_business>
The <find_business> API function represented by an XML message is used to
locate information about one or more businesses. Given a regular expression,
business category, business identifier, or <tModel> as criteria, this message
retrieves zero or more <businessInfo> structures con-tained within a single
<businessList> structure.
36

The syntax for this API is as follows:

<find_business [maxRows=”nn”] generic=”2.0”

xmlns=”urn:uddi-org:api_v2”>
[<findQualifiers/>]
[<name/> [<name/>]...]
[<discoveryURLs/>]
[<identifierBag/>]
[<categoryBag/>]
[<tModelBag/>]
</find_business>

Arguments to this function are listed in Table 5.5.

Table 5.5 <find_business> Function Arguments

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

Table 5.5 (Continued)

ARGUMENT DESCRIPTION
tModelBag This argument enables searching for businesses that
have bindings exposing a specific fingerprint within
the <tModelInstanceDetails> structure.

The returned <businessList> structure contains

<businessInfo> consisting of a
<businessEntity> structure, which in turn
contains <bindingTemplate> referencing
<tModel> structures that match all the <tModel>
keys passed in this argument (logical AND).
discoveryURLs This argument contains a list of URLs to be matched
against the <discoveryURL> data associated with
any registered <businessEntity> structures.

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>

The complete SOAP message response, containing the <businessList>

structure returned from the registry, is shown in Listing 5.4.

<?xml version=”1.0” encoding=”UTF-8”?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=
“http://schemas.xmlsoap.org/soap/envelope/”>
<SOAP-ENV:Body>
<businessList xmlns=”urn:uddi-org:api_v2”
generic=”2.0” operator=”SYSTINET”>
<businessInfos>
<businessInfo businessKey=
“uuid:23453aef-af35-6a3f-c34a-
bf798dab965a”>

Listing 5.4 Response to <find_business> function. (continues)

<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>

Listing 5.4 Response to <find_business> function. (continued)

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>.

If any error occurred in processing this API call, a <disposition Report>

structure would be returned to the caller in the SOAP Fault.
<find_relatedBusinesses>
Given the UUID of a <businessEntity>, this message returns a list of UUIDs
contained within a <relatedBusinessesList> structure. The
<relatedBusinessesList> structure would consist of <related
Description and Discovery of Web Services 39

BusinessInfo> structures consisting of information about the businesses that have

a relationship with this business.
The syntax for this API is as follows:

<find_relatedBusinesses generic=”2.0” xmlns=”urn:uddi-org:api_v2”>

[<findQualifiers/>]
<businessKey/>
[keyedReference/>
</find_relatedBusinesses>

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>

Table 5.6 <find_relatedBusinesses> Function Arguments

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 results would include the businesses that are

related in some way to the <businessEntity>
whose key has been specified by this argument.
keyedReference This is a single, optional <keyedReference>
element that is used to specify that only businesses
related to the focal point in a specific way should be
included in the results. The <keyedReference>
structure is used to classify a data structure in a
UDDI registry. The usage of the <keyedReference>
structure is shown later.
40

The following code shows the partial SOAP message response, contain-ing the
<relatedBusinessesList> structure, returned from the reg-istry:

<relatedBusinessesList generic=”2.0” operator=”SYSTINET” xmlns=”urn:uddi-

org:api_v2”>
<businessKey>
23453aef-af35-6a3f-c34a-bf798dab965a
</businessKey>

<name>
XYZ Corporation
</name>

<description>
Outsourced HR Services provider
</description>

</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:

<find_service businessKey=uuid_key” [maxRows=”nn”] generic=”2.0”

xmlns=”urn:uddi-org:api_v2”>
[<findQualifiers/>]
[<name/>[<name/>]...]
[<categoryBag/>]
[<tModelBag/>]
</find_service>
Description and Discovery of Web Services 41

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>

Also, note how this query makes use of <findQualifiers> consisting of an

enumerated value ‘caseSensitiveMatch’ to instruct a case-sensitive matching.
Find qualifiers are discussed in detail in a later section.
The following code shows the partial SOAP message response, contain-ing a
<serviceList> structure, returned from the registry:

<serviceList generic=”2.0” operator=”SYSTINET”

xmlns=”urn:uddi-org:api_v2”>
<serviceInfos>
<serviceInfo
serviceKey=
“uuid:1245sdef-af35-6a3f-c34a-bf798dab965a”
businessKey=
“uuid:23453aef-af35-6a3f-c34a-bf798dab965a”>
<name>
Billing Services
</name>
</serviceInfo>
</ServiceInfos>
</serviceList>

<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

The syntax for this API is as follows:

<find_binding serviceKey=uuid_key” [maxRows=”nn”] generic=”2.0”

xmlns=”urn:uddi-org:api_v2”>
[<findQualifiers/>]
[<tModelBag/>]
</find_binding>

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>

Also, note this query makes use of <findQualifiers> carrying an enumerated

value of ‘sortByNameAsc’ to instruct the sorting of returned results by names of
the <tModel> structures, in an ascending order. Find qualifiers are discussed in
the Search Qualifiers section.
The partial SOAP message response, containing a <serviceList> structure
returned from the registry, is as follows:

<bindingDetail generic=”2.0” operator=”SYSTINET”

xmlns=”urn:uddi-org:api_v2”>

<accessPoint URLType=”http”>
http://www.acmecomputerservices.com/
billingservices_entry/
</accessPoint>

<tModelInstanceDetails>
Description and Discovery of Web Services 43

<tModelInstanceInfo tModelKey= “uuid:acd5sdef-1235-6a3f-

c34a-bf798dab124b”>

<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:

<find_tModel [maxRows=”nn”] generic=”2.0”

xmlns=”urn:uddi-org:api_v2”>
[<findQualifiers/>]
[<name/>]
[<identifierBag/>]
[<categoryBag/>]
</find_tModel>

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>

The partial SOAP message response, containing a <tModelList> struc-ture,

returned from the registry is as follows:
44

<tModelList generic=”2.0” operator=”SYSTINET”

xmlns=”urn:uddi-org:api_v2”>
<tModelInfos>
<tModelInfo tModelKey=
“uuid:acd5sdef-1235-6a3f-c34a-bf798dab124b”> <name>

SOAP_WSDL_BillingServices
</name>
</tModelInfo>
</tModelInfos>
</tModelList>

Get_xx Inquiry API Functions

The get_xx functions follow the drill-down pattern. This pattern typically
involves getting more specific and detailed information about an entity based on
a unique key corresponding to the entity.
The get_xx calls form the search capabilities wherein once the UDDI client
has a UUID key for any of the primary UDDI data structures of
<businessEntity>, <businessService>, <bindingTemplate>, and <tModel>, it can
use that key to get access to the full registered details of that particular structure.
The client then can access the details of these structures by passing a relevant key
type to one of the get_xx Inquiry API function calls.

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.

Table 5.7 get_xx Functions

GET_XX FUNCTION RETURNED STRUCTURE DESCRIPTION

<get_businessDetail> <businessDetail> This message returns a
<businessDetail>
structure consisting of one or
more <businessEntity>
structures matching the
UUID(s) passed as an
argument to this function call.
Description and Discovery of Web Services 45

Table 5.7 (Continued)

GET_XX FUNCTION RETURNED STRUCTURE DESCRIPTION

<get_serviceDetail> <serviceDetail> This message returns a
<serviceDetail> structure
containing one or more
<businessService>
structures matching the
UUID(s) passed as an
argument to this function call.
<get_bindingDetail> <bindingDetail> If the integrity of
<bindingTemplate> is not
intact, for example if the
document referred to by the
<tModel> referenced by
<bindingTemplate> has
been moved or deleted, this
function call should be used
to get hold of the new
<bindingDetail> structure.
<get_tModelDetail> <tModelDetail> This message returns a
<tModelDetail> structure
consisting of one or more
<tModel> data structures
matching the UUID(s)
passed as an argument to
this function call.

In order to understand the nature of get_xx functions, let’s examine the

working of the <get_businessDetail> function call.
The following code shows the <get_businessDetail> XML message that is sent
within the request SOAP message to the UDDI registry. This function call
suggests that the UDDI registry return the registered details for business
corresponding to the key ‘23453aef-af35-6a3f-c34a-bf798dab965a’.

<uddi:get_businessDetail generic=”2.0”>
<businessKey>
23453aef-af35-6a3f-c34a-bf798dab965a
</businessKey>
</uddi:find_tModel>
46

The partial SOAP message response, containing a <businessDetail> structure,

returned from the registry is as follows:

<businessDetail generic=”2.0” operator=”SYSTINET”

xmlns=”urn:uddi-org:api_v2”>

<businessEntity authorizedName = “John Smith” businessKey=”uuid:23453aef-

af35-6a3f-c34a-bf798dab965a” operator=”SYSTINET”>

<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>

<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

The <businessServices> structure in the previous listing is expanded as

follows:
<businessService
businessKey=”23453aef-af35-6a3f-c34a-bf798dab965a”
serviceKey=”1245sdef-af35-6a3f-c34a-bf798dab965a”>
<name xml:lang=”en”>
Billing Services
</name>

<description xml:lang=”en”>
Billing Services
</description>

<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>

<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>

<keyedReference keyName=”United States”

keyValue=”US”
tModelKey=
“uuid:4e49a8d6-d5a2-4fc2-93a0-0411d8d19e88”/>
</categoryBag>
</businessService>

Thus, this business is classified by two categories:

The standard industry categorization system (NAICS). The first
<keyedReference> structure under <categoryBag> suggests that ACME
Computer Services is a “Custom Computer Programming Services”
company.

The standard geography categorization system (ISO-3166). The sec-ond

<keyedReference> structure under <categoryBag> in the previous listing
suggests that ACME Computer Services is geograph-ically related to
“United States”.

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

Table 5.8 The Most Frequently Used Search Qualifiers

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.

<get authToken> <authToken>

ThismessageconsistsofaloginIDandpasswordcorrespondingtoaregistryuserthattheUDDIregistrywoulduseforauthentication
purposes.

: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.

<save business> <businessDetail>

Changestoanexisting
structurecan<businessEntity>impactexistingreferencesto,<publisherAssertion>,or<businessService><bindingTemplate>structures.

Theregistryresponseconsistsofthe<businessDetail>structurecontainingthefulldetailsofthebusinessthathasjustbeenadded/modified.

<dispositio
<delete
business> nReport>

ThismessagesuggeststhattheUDDIregistrydeletebusinessescorrespondingtothekeysspecifiedwithinthemessage.Deleting<deletebusiness>businesseswouldcausethedeletionofanycontainedaswellas<businessService><bindingTemplate>structures.Alsoany<publisher
Assertion>structurescreatedwiththeUUIDofthisbusinesswouldbedeletedfromtheregistry.

<save service> <serviceDetail>

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

Table5.9 PublishingAPIFunctions (continued)

PUBLISHING RETURNED
APIFUNCTION STRUCTURE DESCRIPTION

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 registry server implementation. Many implementations of the UDDI

registry server are available now. Apart from the public reg-istries hosted
by Microsoft, HP, IBM, and Systinet, several vendors also provide
implementations of private UDDI registries.
Table 5.10 is a partial listing of the UDDI implementations.

Table 5.10 UDDI Implementations

IMPLEMENTATION DOWNLOAD FROM . . .

Java Web Services java.sun.com/xml/download.html
Developer Pack (JWSDP)*
Systinet WASP** www.systinet.com/wasp
The Mind Electric GLUE www.themindelectric.com/glue/index.html
IBM Web Services Toolkit www.alphaworks.ibm.com/tech/
webservicestoolkit/
BEA WebLogic Workshop www.bea.com/products/weblogic/workshop/
easystart/index.shtml
* JWSDP provides an implementation of private UDDI registry implemented on the Tomcat and Xindice
databases. Chapter 11, “Java API for XML Registries,” uses the JWSDP UDDI Registry Server for examples.

* UDDI examples in this chapter are developed using Systinet WASP UDDI APIs.
Description and Discovery of Web Services 55

UDDI Support in Systinet WASP 4.0

The Systinet WASP 4.0 platform includes extensive support for the UDDI
registry. WASP provides an implementation of the UDDI version 2.0 reg-istry.
Also, WASP provides a client API to work with the UDDI registry.
In the following three examples, we will examine how to work with the
UDDI registry on the Systinet WASP 4.0 platform:
SubmitBusiness (SubmitBusiness.java). This example shows how to
submit business information to the UDDI registry.
SearchBusiness (SearchBusiness.java). This example shows how to look
up the business information using name patterns.
DeleteBusiness (DeleteBusiness.java). This example demon-strates the
deletion of business information from a UDDI registry.
The examples are discussed in detail in the following sections: Publishing
Information to a UDDI Registry, Searching Information in a UDDI Registry, and
Deleting Information from a UDDI Registry. Note that all of these three
examples along with their source code and readme.txt consisting of setup
instructions can be downloaded from Wiley’s Web site at www.wiley.com
/compbooks/nagappan.
Note that we will run these examples against the public UDDI registry that is
hosted by Systinet at www.systinet.com/uddi/web. The following are the inquiry
and publishing URLs supported by Systinet’s public registry:
■ www.systinet.com/wasp/uddi/inquiry
■ www.systinet.com:443/wasp/uddi/publishing
In order to work with the Systinet UDDI client APIs, ensure that the following
JAR files are in the CLASSPATH:
uddiclient.jar. This archive implements UDDI Versions 1 and 2 inquiry and
publishing. It can be found under $WASP_HOME/dist.
wasp.jar. This archive can be found under $WASP_HOME/lib.
In order to execute SubmitBusiness and DeleteBusiness, which make use of
the UDDI publishing API, we first need to register as a user of the UDDI
registry. Registration of the user is covered in the next section.

Registering as a Systinet UDDI Registry User

Anyone can easily register as a Systinet registry user. Figure 5.5 shows the
browser interface supported by Systinet for registering a user.
56

Figure 5.5 Browser interface for registering a user.

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.

Figure 5.6 Registering a user.

Description and Discovery of Web Services 57

Now, let ‘s proceed with submitting new business information to the UDDI
registry.

Publishing Information to a UDDI Registry

SubmitBusiness.java shows us how to publish a business named ACME
Computer Services along with its description. In the coming sections, we will
examine the source code of SubmitBusiness.java, followed by its compilation
and execution.

Programming Steps for Publishing

The entire publishing logic is provided by the doSubmit() method of the
jws.ch5.SubmitBusiness class, and hence, its implementation is of most interest
to us. The following are the steps of doSubmit():
1. Construct the UDDIApiPublishing object. This is the object that we will
use to actually publish to the registry.
2. Get hold of the authentication token from the registry with the help of the
get_authToken() API call on the UDDIApiPublishing object. Once we
have the authentication token, we should be able to publish to the
registry.
3. Create the BusinessEntity structure and populate it with the name and
description of the business to submit. Note that we do not have to
create the key for this business because the registry, upon submitting
the business information, would generate it.

4. Now, get hold of the SaveBusiness object. This object represents a

collection of businesses that we wish to submit at a time. Hence, we will
need to add the BusinessEntity object that we just created to the
SaveBusiness object using the addBusinessEntity() method.

5. Now, publish the business information through a save_busi-ness() call

on UDDIApiPublishing object. This method call takes the
SaveBusiness object as an argument and returns the BusinessDetail
object upon completion.
6. After the publishing operation has been executed, discard the authen-
tication token. Finally, check whether the publishing operation was
successful or not.
58

SubmitBusiness.java Source Code

Listing 5.5 shows the complete code listing of SubmitBusiness.java.

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.*;

public class SubmitBusiness

{
public static void main(String args[]) throws Exception {

/ Call the method in order to submit new business to

/ the public registry hosted by Systinet.

doSubmit();
}

public static void doSubmit() throws Exception {

String sBusinessName = “ACME Computer Services”; String

sBusinessDescription = “Provides professional services in the areas of
Computer Software”;

System.out.println(“Saving business with the following

details:”);

System.out.println(“Name: “ + sBusinessName);

System.out.println(“Description: “ +
sBusinessDescription);

/ Get hold of the UDDI Publishing API

/ Note our usage of Publishing URL for the Systinet
/ UDDI Registry

UDDIApiPublishing objUDDIApiPublishing =
UDDILookup.getPublishing(“https://www.systinet.com:443
/wasp/uddi/publishing/”);

/ First we get hold of Authentication token from the

/ Registry so that we can publish to the UDDI
/ Registry. Note that registered a user in Systinet
/ Public Registry with registry_user ID and

Listing 5.5 SubmitBusiness.java.

Description and Discovery of Web Services 59

// registry_user password.

AuthToken objAuthToken = objUDDIApiPublishing.

get_authToken (new GetAuthToken(new
UserID(“registry_user”), new Cred(“registry_user”)));

/ Create the BusinessEntity Structure BusinessEntity

objBusinessEntity = new BusinessEntity();

/ Set the empty businessKey since we are creating a

/ new business
objBusinessEntity.setBusinessKey
(new BusinessKey(“”));

/ Set the name of the business objBusinessEntity.addName(new

Name(sBusinessName));

/ Set the description of the business

objBusinessEntity.addDescription
(new Description(sBusinessDescription));

/ Get hold of the SaveBusiness interface SaveBusiness

objSaveBusiness = new SaveBusiness();

/ Set the Authentication Information on SaveBusiness

objSaveBusiness.setAuthInfo (objAuthToken.getAuthInfo());

/ Now add the BusinessEntity to save to the

/ SaveBusiness interface
objSaveBusiness.addBusinessEntity(objBusinessEntity);

/ Finally publish the SaveBusiness object to the

/ registry
BusinessDetail objBusinessDetail =
objUDDIApiPublishing.save_business(objSaveBusiness);

/ Discard the Authentication token now

objUDDIApiPublishing.discard_authToken
(new DiscardAuthToken(objAuthToken.getAuthInfo()));

/ See if the Business has been published

/ successfully
if (objBusinessDetail==null)
{
System.err.println(“\nUnsuccessful in
submitting the new business information to
registry.”);

Listing 5.5 SubmitBusiness.java. (continues)

}
else
{
System.err.println(“\nSuccessful in submitting the new business
information to registry.”);
}
return;
}
}

Listing 5.5 SubmitBusiness.java. (continued)

Compiling and Executing SubmitBusiness.java

The following command line instruction compiles SubmitBusiness .java:

> javac jws/ch5/SubmitBusiness.java

The following command line instruction executes SubmitBusiness .java:

> java -classpath %CLASSPATH%;. jws.ch5.SubmitBusiness

Figure 5.7 shows the output of this execution.

You can verify the creation of this new business by visiting the Systinet public
registry or by executing SearchBusiness.

Searching Information in a UDDI Registry

SearchBusiness.java shows us how to search for businesses based on the name
pattern provided by the user. In the coming sections, we will examine the source
code of SearchBusiness.java, followed by its com-pilation and execution.

Figure 5.7 Executing SubmitBusiness.java.

Description and Discovery of Web Services 61

Programming Steps for Searching

The entire querying logic is provided by the doSearch() method of the
jws.ch5.SearchBusiness class, and hence, its implementation is of most interest to
us. The following are the steps to implementing a doSearch():
1. Construct the FindBusiness object. This object represents the criteria
for the search operation. Hence, we will need to add our criteria, that is,
the name pattern that the user supplied, using the addName() method on
this object.
2. Construct the UDDIApiInquiry object that we would use for placing
the inquiry call.
3. Finally, invoke the business inquiry operation through the find
_business() method on the UDDIApiInquiry object. This method
returns a BusinessList object containing the BusinessInfo structures.

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.

SearchBusiness.java Source Code

Listing 5.6 is the complete code listing of SearchBusiness.java.

package jws.ch5;

import org.idoox.uddi.client.api.v2.request.inquiry.*; import

org.idoox.uddi.client.structure.v2.tmodel.*; import
org.idoox.uddi.client.structure.v2.base.*;

import org.idoox.uddi.client.api.v2.response.*; import

org.idoox.uddi.client.structure.v2.business.*; import
org.idoox.uddi.client.api.v2.*;

import org.idoox.uddi.*;

public class SearchBusiness

{
public static void main(String args[]) throws Exception {

if (args.length != 1)
{

Listing 5.6 SearchBusiness.java. (continues)

printUsage();
}
else
{
String sNameOfBusiness = args[0];

/ Invoke the search operation

doSearch(sNameOfBusiness);
}
}

private static void printUsage()

{
System.err.println(“\nUsage: java jws.ch5.SearchBusiness
<BusinessNamePattern>”);

System.err.println(“\nwhere <BusinessNamePattern> represents name of

the business you want to search.”);

public static void doSearch(String sNameOfBusiness) throws

Exception
{
// Create a FindBusiness object
FindBusiness objFindBusiness = new FindBusiness();

/ Send the find criteria objFindBusiness.addName(new

Name(sNameOfBusiness));

/ Set the maximum number of rows to return

objFindBusiness.setMaxRows(new MaxRows(“10”));

/ Get hold of UDDILookup object to place the query UDDIApiInquiry

objUDDIApiInquiry =
UDDILookup.getInquiry(“http://www.systinet.com:80/ wasp/uddi/inquiry/”);

/ Invoke the query on the UDDI Inquiry API BusinessList

objBusinessList= objUDDIApiInquiry.find_business(objFindBusiness);

/ Check whether anything was found matching the

Listing 5.6 SearchBusiness.java.

Description and Discovery of Web Services 63

// 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();

System.out.println(“\n” + objBusinessInfos.size() + “ businesses

found matching the criteria...\n”);

BusinessInfo objBusinessInfo =
objBusinessInfos.getFirst();

BusinessKey objBusinessKey;

if (objBusinessInfo != null)
{
objBusinessKey=objBusinessInfo.
getBusinessKey();

/ Traverse through the results. while

(objBusinessInfo!=null)
{
System.out.println(“Business Name = “ +
objBusinessInfo.getNames(). getFirst().getValue());

System.out.println(“Business UUID = “ +
objBusinessInfo.getBusinessKey());

System.out.println(“----------------
---------------------------------”);

/ Next BusinessInfo objBusinessInfo

= objBusinessInfos.getNext();

}
}
}
}
}

Listing 5.6 SearchBusiness.java. (continued)

Compiling and Executing SearchBusiness.java

The following command line instruction compiles SearchBusiness .java:

> javac jws/ch5/SearchBusiness.java

The following command line instruction executes SearchBusiness .java in

order to search for businesses with names starting with a ‘A’:
> java -classpath %CLASSPATH%;. jws.ch5.SearchBusiness A

Figure 5.8 shows the output of this execution.

As can be seen from the output in Figure 5.8, ACME Computer Services is one
of the businesses that matched our search criteria.

Deleting Information from a UDDI Registry

DeleteBusiness.java demonstrates how to delete a business from the UDDI
registry based on its key UUID, which is passed by the user as a com-mand line
argument. You can get hold of the business key either by brows-ing the Systinet
registry on the Web or by executing SearchBusiness. In the coming sections, we
will examine the source code of DeleteBusiness .java, followed by its
compilation and execution.

Figure 5.8 Executing SearchBusiness.java.

Description and Discovery of Web Services 65

Programming Steps for Deleting

The deletion logic is provided by the doDelete() method of the
jws.ch5.DeleteBusiness class, and hence, its implementation is of most interest to
us. The following are the steps to implementing doDelete():
1. Construct the UDDIApiPublishing object. This is the object that we
would use to actually delete information from the registry.
2. Get hold of the authentication token from the registry with the help of the
get_authToken() API call on the UDDIApiPublishing object. Once we
have a valid authentication token, we should be able to delete from the
registry.
3. Now, get hold of the DeleteBusiness object. This object represents a
collection of businesses that we wish to delete at a time. Hence, we will
need to add businesses referenced through BusinessKey to this object,
using the addBusinessKey() method on DeleteBusiness.
4. Now, delete the business information through the delete_busi-ness() call
on the UDDIApiPublishing object. This method call takes the
DeleteBusiness object as an argument and returns the DispositonReport
object upon completion.
5. Check the DispositionReport object to see if this operation was a success
or a failure.

DeleteBusiness.java Source Code

Listing 5.7 is the complete code listing of DeleteBusiness.java.

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.*;

public class DeleteBusiness

{
public static void main(String args[]) throws Exception

Listing 5.7 DeleteBusiness.java. (continues)

{
if (args.length != 1)
{
printUsage();
}
else
{
BusinessKey objBusinessKey =
new BusinessKey (args[0]);

doDelete(objBusinessKey);
}
}

private static void printUsage()

{
System.err.println(“\nUsage: java
jws.ch5.DeleteBusiness <BusinessKey>”);

System.err.println(“\nwhere <BusinessKey> is a string representation of UUID

corresponding to Business you want to delete.”);

public static void doDelete(BusinessKey objBusinessKey)

throws Exception
{
System.out.println(“\nDeleting Business with Key: “);
System.out.println(objBusinessKey.toString());

UDDIApiPublishing objUDDIApiPublishing =
UDDILookup.getPublishing(“
https://www.systinet.com:443/wasp/uddi/publishing/”);

/ First we get hold of Authentication token from the

/ Registry so that we can delete
/ business from the UDDI Registry. Note that
/ registered a user in Systinet Publich Registry
/ with registry_user ID and registry_user password.

AuthToken objAuthToken = objUDDIApiPublishing.

get_authToken(new GetAuthToken(
new UserID(“registry_user”),
new Cred(“registry_user”)));

/ Now get hold of the DeleteBusiness structure

org.idoox.uddi.client.api.v2.request. publishing.DeleteBusiness
objDeleteBusiness =

Listing 5.7 DeleteBusiness.java.

Description and Discovery of Web Services 67

new org.idoox.uddi.client.api.v2.request.
publishing.DeleteBusiness();

/ Set the login information on DeleteBusiness

objDeleteBusiness.setAuthInfo (objAuthToken.getAuthInfo());

/ Add business to delete to the DeleteBusiness

/ Structure objDeleteBusiness.addBusinessKey(objBusinessKey);

/ Call Publishing API method delete_business

DispositionReport objDispositionReport =
objUDDIApiPublishing.delete_business (objDeleteBusiness);

/ Discard the Authentication token now

objUDDIApiPublishing.discard_authToken
(new DiscardAuthToken(objAuthToken.getAuthInfo()));

/ Check to see if the delete operation was

/ successful
if (objDispositionReport == null)
{
System.err.println(“Unsuccessful in deleting the business
information from the registry.”);
}
else
{
if (objDispositionReport.
resultIs(UDDIErrorCodes.E_SUCCESS))
{
System.out.println(“\nSuccessful in
deleting the business information from the
registry.”);
}
else
{
System.out.println(“\nUnsuccessful in
deleting the business information due to
following reason(s):”);

System.out.println(

Listing 5.7 DeleteBusiness.java. (continues)

objDispositionReport.toXML());
}
}
}
}

Listing 5.7 DeleteBusiness.java. (continued)

Compiling and Executing SearchBusiness.java

The following command line instruction compiles DeleteBusiness .java:

> javac jws/ch5/DeleteBusiness.java

The following command line instruction executes DeleteBusiness .java in

order to delete the ACME Computer Services business corre-sponding to the key
‘fe4b2d70-9988-11d6-9917-b8a03c50a862’.

> java -classpath %CLASSPATH%;. jws.ch5.DeleteBusiness fe4b2d70-9988-

11d6-9917-b8a03c50a862

Figure 5.9 shows the output of this execution.

Deletion of ACME Computer Services can be verified either by visiting the
Systinet public registry or by executing SearchBusiness.

Figure 5.9 Executing DeleteBusiness.java.

HH Description and Discovery of Web Services 69

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.”

Also, UDDI is just a registry as opposed to ebXML Registry/Repository,

which is, as the name suggests, a registry as well as repository. The basic
difference between a registry and repository is that a registry holds just the
metadata of the objects submitted, whereas a repository actually stores the
submitted objects.

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.

Soap Rest
No ratings yet
Soap Rest
9 pages
WSDL Tutorial
No ratings yet
WSDL Tutorial
10 pages
Web Services I 533
No ratings yet
Web Services I 533
98 pages
Lecture 3
No ratings yet
Lecture 3
40 pages
Web Services
No ratings yet
Web Services
35 pages
Web Services Building Blocks
No ratings yet
Web Services Building Blocks
51 pages
Lecture 2 - WS and Apps
No ratings yet
Lecture 2 - WS and Apps
50 pages
Web Services
No ratings yet
Web Services
32 pages
Chapter 3 Part II WSDL
No ratings yet
Chapter 3 Part II WSDL
33 pages
Webservices
No ratings yet
Webservices
22 pages
Web Service Foundations: WSDL and SOAP
No ratings yet
Web Service Foundations: WSDL and SOAP
98 pages
Module 3
No ratings yet
Module 3
15 pages
Web Services
No ratings yet
Web Services
67 pages
Web Services: DR - Saranya K G Assistant Professor (S.GR) Dept - of CSE, PSG College of Technology, Coimbatore
No ratings yet
Web Services: DR - Saranya K G Assistant Professor (S.GR) Dept - of CSE, PSG College of Technology, Coimbatore
90 pages
Web Services Description Language
No ratings yet
Web Services Description Language
48 pages
Unit - 2 Part - 2
No ratings yet
Unit - 2 Part - 2
9 pages
Soap Webservices
No ratings yet
Soap Webservices
22 pages
Web Services
No ratings yet
Web Services
22 pages
4 5800736925367143212
No ratings yet
4 5800736925367143212
13 pages
Webservices
No ratings yet
Webservices
23 pages
Web Services Description Language
No ratings yet
Web Services Description Language
51 pages
Web Services, Web 2.0 & Web OS
No ratings yet
Web Services, Web 2.0 & Web OS
61 pages
Web Services
No ratings yet
Web Services
26 pages
What Is Web Service
No ratings yet
What Is Web Service
25 pages
4 5805315931735329384-1
No ratings yet
4 5805315931735329384-1
9 pages
Web Services
No ratings yet
Web Services
22 pages
Unit 2 - Chapter 2.2
No ratings yet
Unit 2 - Chapter 2.2
41 pages
Web Services
No ratings yet
Web Services
57 pages
WSDL
No ratings yet
WSDL
21 pages
System Integration Chapter 4-Web Service Technologies
No ratings yet
System Integration Chapter 4-Web Service Technologies
12 pages
Webservices Notes
No ratings yet
Webservices Notes
9 pages
1ec46WEB SERVICES and It-Amity Uni
No ratings yet
1ec46WEB SERVICES and It-Amity Uni
5 pages
What's New in WSDL 2.0
No ratings yet
What's New in WSDL 2.0
12 pages
Soapuitraining: Types
No ratings yet
Soapuitraining: Types
2 pages
WSDL Tutorial
No ratings yet
WSDL Tutorial
32 pages
UDDI and WSDL
No ratings yet
UDDI and WSDL
5 pages
WSDL
No ratings yet
WSDL
8 pages
Introduction To Web Services
No ratings yet
Introduction To Web Services
14 pages
Web Services
No ratings yet
Web Services
17 pages
CS8791-CC Unit-II
No ratings yet
CS8791-CC Unit-II
75 pages
Web Services and J2EE: Dan Harkey
No ratings yet
Web Services and J2EE: Dan Harkey
21 pages
To Web Services: Raju. A
No ratings yet
To Web Services: Raju. A
33 pages
Webservices
No ratings yet
Webservices
31 pages
Web Service Architecture
No ratings yet
Web Service Architecture
14 pages
Web Services Web Services
No ratings yet
Web Services Web Services
5 pages
Brain Computer Interface
No ratings yet
Brain Computer Interface
23 pages
SOA and Web Services Primer
No ratings yet
SOA and Web Services Primer
71 pages
Implementation of Webservices Ex - No:: D Aim
No ratings yet
Implementation of Webservices Ex - No:: D Aim
14 pages
WSDL Web Services Description Language: Neet Wadhwani University of Colorado 3 October, 2001
No ratings yet
WSDL Web Services Description Language: Neet Wadhwani University of Colorado 3 October, 2001
24 pages
Soapuitraining-Rahul Shetty: Types
No ratings yet
Soapuitraining-Rahul Shetty: Types
2 pages
WSDL Tutorial
No ratings yet
WSDL Tutorial
6 pages
Web Services Part 2 - SOAP
No ratings yet
Web Services Part 2 - SOAP
13 pages
6 CSE - CS8651 IP Unit 5
No ratings yet
6 CSE - CS8651 IP Unit 5
43 pages
Web Services Description Language
No ratings yet
Web Services Description Language
2 pages
Understanding WSDL: Web Services Technical Articles
No ratings yet
Understanding WSDL: Web Services Technical Articles
18 pages
Web Services Description Language (WSDL)
No ratings yet
Web Services Description Language (WSDL)
29 pages
ERP Architecture
No ratings yet
ERP Architecture
43 pages
SOAP Tutorial
100% (2)
SOAP Tutorial
23 pages
What Is The Web Service Protocol Stack?: Yodlee Confidential
No ratings yet
What Is The Web Service Protocol Stack?: Yodlee Confidential
4 pages
JNTUH Syllabus 2013 M.Tech CSE
No ratings yet
JNTUH Syllabus 2013 M.Tech CSE
33 pages
Soa, WSDL, Soap
No ratings yet
Soa, WSDL, Soap
7 pages
Predictive Maintenance - Reduce Cost
No ratings yet
Predictive Maintenance - Reduce Cost
9 pages
C Questions
No ratings yet
C Questions
19 pages
PeopleTools Tables
No ratings yet
PeopleTools Tables
57 pages
IIT
No ratings yet
IIT
29 pages
GCC Unit Iii Notes
No ratings yet
GCC Unit Iii Notes
22 pages
GHMC
No ratings yet
GHMC
38 pages
Unit-1 Wssoa
No ratings yet
Unit-1 Wssoa
30 pages
Li 2018
No ratings yet
Li 2018
11 pages
5 Soa
No ratings yet
5 Soa
35 pages
3 Tier Architecture
No ratings yet
3 Tier Architecture
19 pages
02 Architecture
No ratings yet
02 Architecture
16 pages
Exploring Cloud Infrastructures
No ratings yet
Exploring Cloud Infrastructures
74 pages
Unit V Controlling
No ratings yet
Unit V Controlling
6 pages
Web Services Interview Questions: Click Here
No ratings yet
Web Services Interview Questions: Click Here
34 pages
Ayushi Internship Report
No ratings yet
Ayushi Internship Report
68 pages
SOA and Web Services - Understanding SOA With Web Services...
No ratings yet
SOA and Web Services - Understanding SOA With Web Services...
69 pages
Tib Amx Policy Agent Release Notes
No ratings yet
Tib Amx Policy Agent Release Notes
16 pages
Creating New Web Service Using PLSQL Package
No ratings yet
Creating New Web Service Using PLSQL Package
25 pages
Delegates
No ratings yet
Delegates
45 pages
Web Services Essentials
No ratings yet
Web Services Essentials
8 pages
Siebel Web Services
No ratings yet
Siebel Web Services
20 pages
Chen Liang Sun 2004
No ratings yet
Chen Liang Sun 2004
8 pages
13 - Chapter 4 Technical Feasibility Study
No ratings yet
13 - Chapter 4 Technical Feasibility Study
24 pages
SAP and Oracle - A Comparison On Support Standards
No ratings yet
SAP and Oracle - A Comparison On Support Standards
35 pages
XML Web Services: Dietrich Birngruber
No ratings yet
XML Web Services: Dietrich Birngruber
27 pages
Gender Detection Using Machine Learning Algorithms
No ratings yet
Gender Detection Using Machine Learning Algorithms
7 pages
Creating A Service Consumer Proxy - SCN
No ratings yet
Creating A Service Consumer Proxy - SCN
8 pages
B Tech 4-2 Cse-Lesson Plan For Web Services
No ratings yet
B Tech 4-2 Cse-Lesson Plan For Web Services
2 pages
WSDL Tutorials - Herong's Tutorial Examples
From Everand
WSDL Tutorials - Herong's Tutorial Examples
Herong Yang
No ratings yet
WCF 4.0 Multi-tier Services Development with LINQ to Entities
From Everand
WCF 4.0 Multi-tier Services Development with LINQ to Entities
Mike Liu
No ratings yet
Professional ASP.NET 4 in C# and VB
From Everand
Professional ASP.NET 4 in C# and VB
Bill Evjen
No ratings yet
WSDL Protocol in Application Design: Definitive Reference for Developers and Engineers
From Everand
WSDL Protocol in Application Design: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
RESTful Java Web Services Interview Questions You'll Most Likely Be Asked: Second Edition
From Everand
RESTful Java Web Services Interview Questions You'll Most Likely Be Asked: Second Edition
Vibrant Publishers
No ratings yet