What Are Web Services?

Web services are based on the concept of service-oriented architecture

(SOA).SOA is the latest evolution of distributed computing, which enables
software components, including application functioDs, objects, and
processes from different systems, to be exposed as services.
According to Gartner research June 15, 2001), "Web services are
loosely coupled software components delivered over Internet standard
technologies"
In short, Web services are self-describingand modular business applica
tions that expose the business logic as services over the Internet
through
programmable interfaces and using Internet protocols for the purpose of
providing ways to find, subscribe, and invoke those services.
Based on XML stándards, Web services can be
pled application components using any developed as loosely cou
programming language, any pro
focol, or any platform. This facilitates delivering
service accessible to anyone, anytime, at any business applications as a
platform. location, and using any
Consider the simple example shown in Figure 2.l where a travel reser
vation services provider exposes its business
supporting a variety of çustomers and application applications as Web services
clients. These business
applicatiorts are- provided by different travel organizations residing at
different nétwÑrks and geographical locations.
 Airline
Wireless Reservation
Device System

Find Register
Services Services
Travel Rental Car
Services Reservation
Desktop
Registry System

Invoke
Services Hotel
PDA Service Travel Reservation
Requestor Reservation
Services System
Provider

Automobile Map and Weather

Information
System

Organization
Credit Card
Payment System..
Flgure 2.1 An example scenario of Web services.
 Serice
Broker

D i s c oSveer
r v i c e

Registr Servic
Service Service
Requestor ProDder
Invoke Service

Figure 2.3 Web services operational model, shoing roles and relationships.

These roles and relationships are defined as follows:

Service provider. The service provider is responsible for developing
and deploying the Web services. The provider also defines the ser
vices and publishes them with the service broker.
Service broker. The service broker (also commonly referred to as a
service registry) is responsible for service registration and discovery
of the Web services. Thebroker lists the various service types,
descriptions, and locations of the services that help the service
requesters find and subscribe to the required services.
Service requestor. The service requestor is responsible for the service
invocation. Therequestor locates the Web service using the service
broker, invokes the required services, and executes it from the service
provider.
Let'sexamine more closely someof the open standard technologies such
as SOAP, WSDL, UDDI, and ebXMLthat enable Web services.
Extensible Markup Language (XML)
Ih February 1998, the Workdwide Web Consortium (W3C) officially
endorsed the Extensible Markup Language (XML) as a standard data fo
mat. XML uses Unicode, and it is structured self-describing neutral daa
that can be stored as a simpletext document for representing complex data
and to make it readable. Today, XML is the de facto standard for structuring
data,content, and data format for electronic documents. It has already been
widely accepted as the universal language lingua franca for exchanging
intormation between applications, systems,and devices across the Internet.
In the core of the Web services model, XML plays a vital role as the com
basis for
mon wire format in all forms of communication. XML also is the
other Web services standards. By learning XML,you will be well prepared
to understand and explore Web services. For more information on XML, go
to the
to Chapter 8, "XML Processing and Data Binding with Java APls," or
official W3C Web site for XML at wwW.w3c.org/XML/.

Simple 0bject Access Protocol (SOAP)

SimpBe Object Access Protocol, or SOAP, is a standard for alightweight
XML-based messaging protocol, It enables an exchange of information
between two or more peers and enables them to communicate with each
other in a decentralized, distributed application environment. Like XML,
SOAP also is independent of the application object model, language, and
running platforms or devices. SOAP is endorsed by W3C and key industry
vendors like Sun Microsystems, IBM, HP, SAP, Oracle, and Microsoft.
These vendors have already announced their support by participating in
the W3C XML protocol-working group. The ebXML initiative from
UN/CEFACT also has announced its support for SOAP.
In the core of the Web services model, SOAP is used as the messaging/
protocol for transport with binding on top of various Internet protoco<s
such asHTTP, SMTP, FTP, and so on. SOAP uses XML asthe message for
inat, andif uses a set of encoding rules for representing data as messages.
Although SOAP is used as amessaging protocol in Web services, it also can
operate ona request/response model by exposing the functionality using
SOAP/RPC based on remote procecural calls. SOAP also can be used with
J2EE-based appication frameworks. For more information about SOAP, go
to Chapter 4, "Developing Web Services Using SOAP" or to the official
W3C Web site for SOAP at www.w3c.org/TR/SOAP/.
 Web Services Definition Language (WSDL)
The Web Services Definition Language (WSDL) standard is an XML forrmat
for describing the network services and its access information. It defines a
binding mechanism used to attach a protocol, data format, an abstract
message, or set of endpoints defining the location of services.
In the core of the Web services model, WSDL is used as the metadata
language for defining Web services and describes how service providers
and requesters communicate with one another. WSDL describes the Web
services functionalities offered by theservice provider, where the service is
located, and how to access the service. Usually the service provider creates
Web services by generating WSDL from its exposed business applications.
Apublic/private registry is utilized for storing and publishing the WSDL
based information. For more information about WSDL, go to Chapter 5,
"Description and Discovery of Web Services," or the official W3C Web site
for WSDLat www.w3c.org/TR/wsdl/.

Universal Description, Discovery, and Integration. (UDDI)

Universal Description, Discovery, and Integration, or UDDI, defines the
standard interfaces and mechanisms for registries intended for publishing
and storing descriptions of network services in terms of XML messages. It
is similar to the yellow pages or a telephone directory where businesses
list their products and services. Web services brokers use UDDl as a stan
ard for registering the Web service providers. By communicating with
the UDDI registries, the service requestors locate services and then
invoke them.
In thecore Web services model, UDDI provides the registry for Web
"services to function as a seryice broker enabling the service providers to
populate the registry with service descriptions and service types and the
service requestors to query the registry to find and locate the services. It
enables Web applications to interact with a UDDI-based registry using
SOAP messages. These registries canbe either private services within. an
enterprise or a specific community, or they can be public registries to ser
vice the whole global business community of the Internet, The UDDI
working group inchades leading technology vendors like Sun Microsys
tems, TBM, HP, SAP, Oracke, and Microsoft. For more information about
UDDI, go to Chapter 5, "Description and Discovery of Web Services," ofto
theofficial Web site of UÐDI at www.uddi.org/.
 i Web:Service
Broker

UDDI
Registry

Discover Services ebXML Register Services

& Location of WSDL using WSDL
Registry/
Repository

!Web Service Web Service

Requester Provider

Service Invoke Services using Services

Delivery Container
SOAP/ebXML Messaging
Figure 3.2 Web Services architecture and its core building blocks.
 Anatomy of a SOAP Message
mechanisms
SOAP defines the structure of an XML document, rules, and
that can be used to enable communication between applications. It does
not mandate a single programming language or a platform, nor does it
define its own language or platform.
Before we go exploring the SOAP features, let'swalk through an existing
SOAP message and understand the XML syntax, semantic rules, and con
ventions. The example shown in Listing 4.1 is a SOAP request/response
message for öbtaining book price information from a book catalog service
provider. The SOAP request accepts a string parameter as the name of the
book and returns a float as the price of the book as a SOAP response.
In thescenario in Listing 4.1, the SOAP message is embedded in an
HTTP requestfor getting the book price information from www.wiley.com
for the book Developing Java Web Services.

POST

ntLenthiN60

APENVEnveloPe
:SOAP BNVA HESt 9/aoap
SIhttp/wwwWw3
mngXBd
g/2001/XShema
ht tp:wwwweoru0017schema Histang
SOpENVencodingstyle
thtepsche soap orsnoapeençod
NVAHead

amlnsoersoi Heade
Spersonimal.
SOAP Heade

ENBGa

book
evelopngava Web (hookname
Tu:Get:pookP1d.
SOAP ENV: Body
SOAPENSEHvelope
L0sting 4.1 SOAP request mnessage.
 HTTP response
Tisting 4.2 shows the SOAP message embedded in an
returning the price of the book.

textamlcharsetekut
K640:

SOAPDNV Envelope
Cmlhs:SOAPENVEhttpLIschemas mlsoap org/9pap/ernvelope/
anlns Xs1HttBrwww.sciota200MSchenSA
KSdhttp:/www.w3aorg2001/XMLSCheima
encodingsty leEttpIs hemasn soap org7soaplencoding
SOARENV: Header
eyi sangaction
m L1eyhttp:/13 ley com/2002/bookts

ENAley:TrànsaeiOn
OAP BNVHeader
SSOAP EN Bodyn
mGetbookPridceResporise.anIhs n
PWW.NTeycÖnl5ws book
PCess0:00Price
m GeBOoKPriceResponse
ISOAPENVABOdy
SOAPENVG EAve lopes

Listing 42 SOAP response message.

In Listing 4.2, you might have noticed that the SOAP message contains a
SOAP Envelope SOAP-ENV :Envelope as its primary root element, and
it relies on defined "XML Namespaces" commonly identified with a
keyword xmlns and specific prefixes to identify the elements and
itsencoding rules. All the elements in the message are associated with
gOAP-ENV-defined namespaces.
Note that a SOAP application should incorporate and use the relevant
SOAP narnespaces for defining its elements and attributes of its sending
nessages; likewise, it must be able to process the receiving messages with
thoss specified namespaces. These namespaces must be in a quaified W3C
XML Schema, which facilitates the SOAP message with groupingS of
elernents using prefixes to avoid name collisions.
 Usually a SOAP message requires defining two basicnamespaces: SOAP
Envelope and SOAP Encoding. The following list their forms in both
versions 1.1 and 1.2 of SOAP.

SOAP ENVELOPE

http://schemas.xmisoap.org/soap/envelope/ (SOAP 1.1)

http://www.w3.org/2001/06/ soap-envelope (S0AP 12)
SOAP ENCODING

http://schemas.xmlsoap.org/soap/encoding/ (SOAP 1.1)

http://www.w3.org/2001/06/soap-encoding (SOAP 1.2)
Additionally, SOAP also can use attributes and values defined in W3C
XML SChema instances or XML Schemas and can use the elements based
on custom XML conforming to W3C XML Schema specifications. SOAP
does not support or use DTD-based element or attribute declarations. To
understand the fundamentals of XML namespaces, refer to Chapter 8,
"XML Processing and Data Binding with Java APls."
Typical to the previous example message, the structural format of a
SOAP message (as per SOAP version 1.1 with attachments) contains the
following elements:
Envelope
-Header (optional)
Body
Attachments (optional)
"..:

Figure 4.1 represents the structure of aSOAP message with attachmnts.

Typically, aSOAP message is represented by a SOAP envelope with zero
more attachments. The SOAP message envelope contains the header and
body of the message, and the SOAP message attachments enable the mes
sage to contain data, which include XML and non-XML data (like
text/binary files). In fact, a SOAP message package is constructed using the
MIME Multipart/Related structure approaches to separate and identify the
different parts of the message.
Now, let's explore thedetails and characteristics of the parts of a SOAP
message.
 SOAP 1 Message SOAP Envelope
WAttachments
SOAP Header
Header entry
SOAP Envelope
(Primary MIME part) Header entry

SOAP. Body
Attachment
Body entry
Attachment
Body entry
Attachment

Attachment

Figure 4.1 Structure of a SOAP message with attachments.

SOAP Envelope
The SOAP envelope is the primary container of aSOAP message's structure
and is the mandatory element of a SOAP message. It is represented as the
root element of the message as Envelope. As we discussed earlier, it is
usually declared as an element using the XML namespace htp://schemas
xmlsoap.org/soap/envelope/. As per SOAP 1.1 specifications, SOAP
messages that do not follow this namespace declaration are not processed
and are considered to be invalid. Encoding styles also canbe defined using
a namespace under Envelope to represent the data types used in the
message. Listing 4.3 shows the SOAPenvelopeelement ina SOAP message.
sOAP Header
The SOAP header is represented as the first immediate child element of a
SOAP envelope, and it has to be namespace qualified. In addition, it also
may contain zeroor more optional child elements, which are referred to as
SOAP header entries. The SOAP encodingStyle attribute will be used to
define the encoding of the data types used in header element entries. The
SOAP actor attribute and SOAP mustUnderstand attribute can be used
to indicate the target SOAP application node (Sender/Receiver/Interme
diary)and to process the Header entries. Listing4.4 shows the sample rep
resentation of a SOAP header element in a SOAP message.
SOAP Body
A SOAP envelope contains a SOAP body as its child element, and it may
contain one or more optional SQAP body block entries. The Body repre
sents the mandatory processing information or the paykoad intended for
the receiver of the message. The SOAP 1.1 specification mandates that
there must be one or more optional SOAP Boy entries in a message. A
Body block of aSOAP message can contain any of the following:
RPC method and its parameters
- Target application (receiver) specific dat
SOAP fault for reporting errors and statusinformation
SOAP Attachments
As per SOAP 1.1 with the attachment specification, a SOAP message con
tains the primary SOAPenvelope in an XML format and SOAP attachments
iñ any data fornat that can be ASCIl or binary (such as XML or non-text).
SOAP attachments are not part of the SOAP envelope but are related to the
message.
As the SOAP message is consiructed using a MIME multipart/related
structure, the SOAP attachment part of the message is contained to a
MIME boundary (defined in the Context-Type header). Each MIME part in
the structure of the SOAP message is referenced using either Content-ID or
Content-Location as labels for the part. Both the SOAP header and body of
the SOAP message also can refer to these labels in the message. Each
attachment ofthe message is identified with a Content-ID (typically an
href atiibute using a URL scheme) or Content-Location (a URI reference
assoçiate to the attachment)}
 SOAP Request

<?xl version="1.0" encoding="UIE-8"?>

<S:Envelope xnlas:3="http:/ischema s. xmlscap.org/soap/envelope/">
<S:Header/>
<S:Sody>
<ns2:add Xmlas :ns2="http:/laddition/ >
<a>4</a>
<b>4</b>
</as2 :add
</S:Sody>
</S:Envelcpe>

SOAP Respouse

<? Kml version="i.0" encoding="UIF-g"?>

<5:Envelope xmlns:S= "http: //schema s . xml aoap.org/soap/envelope/">
<S:Body>
<ns2 : addResponse xmlns:ns2="http:// addition/">
<return></retuzn>
</ns2 taddRe sponse>
</3:Body>
</8:Envelope>

Done Local intranet

 WSDL FILE:

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

-<<-
Published by JAX-WS RIat http://jax-WS. dev.java.net. RI's version is Metro/2.1.1-b09
(branches/2.1-6834; 2011-07-16T17:14:48+0000) JAXWS-RI/2.2.5-promoted-b04 JAXWS/2.2.
-->

- <<-
Generated by JAX-WS RI at http://jax-ws.dev.java.net. R>'s version is Metro/2.1.1-b09
(branches/2.1-6834: 2011-07-16T17: 14:48+0000) JAXWS-RI/2.2.5-promoted-b04 JAXWS/2.2.
-->

-<definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity
utility-1.0.xsd" xml1ns:wsp="http://www.w3.org/ns/ws-policy"
xmins:wspl_2="http:/lschemas.xmlsoap.org/ws/2004/09/policy"
xmins: wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:soap="http://schemas.xnalsoap.org/wsdV'soap/" xmins:tns="http:/addition/"
Xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns="http://schenas.xmlsoap.org/wsdV" targetNamespace="http://addition/"
name="ws1">
<types>
-<xsd:schema>
<xsd:import namespace="http://addition/"
schemaLocation="http://localhost:8080/web/ws1?xsd=1">
</xsd:schema>
types>
:<message name="add">
<part name="parameters" element='tns:add" >
</message>
<message name="addResponse">
<part name-"parameters" element-"tns:addResponse" />
</message>
<message name"hello'>
<part name="parameters" element-"tns:hello" >
<message>
=<message name-"helloResponse">
<part name-"parameters" element-"tns:helloResponse" >
</message>
:portIype name-"ws1">
-<operation name-"add">
<input wsam:Action="http://addition/wsl/addRequest" message-"tns:add">
<output wsam: Action="http:/addition'wsl/addResponse" message="tns:addResponse" />
</operation>
-<operation namne-"hello>
<input wsam:Action="http://addition/ws1/helloRequest" message="tns:hello" >
<output wsam:Action="http://addition/ws1/helloResponse" message="tns:heloResponse" />
</operation>
</portType>
<binding name="ws1 PortBinding" type="tns:ws1">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style=-"document" >
:<operation name="add">
<soap:operation soapAction="">
<input>
<soap:body use="literal" />
</input>
:<output>
<soap:body use="literal" />
<Joutput>
</operation>
:<operation name="hello">
<soap:operation soapAction=">
:<input>
<soap:body use-"literal" /
</input>
:<output>
<soap:body use-"literal" >
<output>
<loperation>
<binding>
-<service namne="ws1">
-<port name-"ws1 Port" binding=-"tns: ws1 PortBinding">
<soap:address location="http:/localhost:8080/web/ws1" >
</port>
</service
<definitions>
< efinitions>. A WSDL document is a set of definitions. These
definitions aredefined 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.
<mASsage>. 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
contains zero
request or response sent toor from the Web service. It to the
basically refer
or more message <part> elements, which
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
operation
response messages defined by <message> elements. Each
refers to an input message and an output message.
<binding>. This 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>. Thiselement specifies an address for binding to the Web
service.
<service>. This element aggregates a set of related <port> ele
of the
ments, each which uniquely specify the binding informationelements
Web service, A <service> consisting of mutiple <port> over
invoked
essentially represernts the capabiity of the service to be is discussed
mutiple bindings. More information on WSDL bindings
in the next section.
WEB SERVICE:
ADD WEBSERVICE.JAVA:
package ADD2;
import javax.jws. WebMethod:
import javax.jws.WebParam;
import javax.jws.WebService;
@WebService()
public class add {
@WebMethod(operationName = "operation")
public Integer operation(@WebParam(name = "a")
int a, (@WebParam(name = "b")
int b) {
I/TODO writeyour implementation code here:
return (atb);

ADDSERVJ.JSP:
<%@page contentType-"text/html" pageEncoding-"UTF-8"%>
<!DOCTYPEHTML PUBLIC "-//W3C//DTD HTML 4,01 TransitionaV/EN"
"http://www.w3.orgTR/html4/loose.dtd">
<htm>
<head
<meta http-cquiv-"Content-Type" content="text/html; charset-UTF-8">
title>JSP Page</title>
<head>
<form id="adderform">
firstnumber:<input type="text"'name="no 1"/>
secondnumber:<input type="text"name-"no2">
<input type="submit"value="add"/>
<form>
<body>
<h2> <h2>
o start web service invocation --%><hr>
%
try {
add webservice.ADDWebServiceService service = new
add webservice.ADDWebServiceService();
add webservice.ADDWebService port service.getADDWebServicePort);
I/TODO initialize WS operation arguments here
int a = Integer.parselnt(request.getParameter("no 1");
int b = Integer.parselnt(request.getParameter("no2"):
I/TODO process result here
java. lang.Integer result = port.add(a, b);
out.printin("Result= "tresult):
}catch (Exception ex) {
TODO handle custom exceptions here

%>
o- end web service invocation --9%><hr>
<body>
<(htm>
 CwsiWeb Service Tester -Windows Internet Explorer
ocahost:tTpste .

Fe Edk Favortes Tools Help

Favortes SASted es
* Page Safety + Tooks -
wsiWeb Service Tester

ws1 Web Service Tester

(WSDL Fie)
This fora wÌaos you to test your web service implementaion
boxes and cick on the button labeied with the method name.
Io oke an operation, fi the method parameter(s) input
Methods :

pbhc abstact t addition Wsl.add(int int)

add 4

pabic abstract java lang String aácition Wsl.helo(java lang.String)

helloANJ

Local intranet 100%

Dore

Explo. MX
Ahethod invDcatíon traceWindows internet

Fe
Hew Favortes Tools Help

Method vocaton trace

add AMethodinvocation

Method parzmeter(s)

Type Vane

int

Methodretuned
nt:8*

Loc irtranot 100%

 JSP Page Windows Internet Explorer
e]http:Mlocalhost: XLre Search
File Edit View Favorites Tools Help

Favorites e) Suggested 5ites Web Slite Galery

Page Safety
Shttp:..

firstmumber4 secondnumber4
add

Hello World!
Resuit =8

Local intranet 100%

 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. UDDl 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
businesseasto discover other businesses for expanding potential business
partnerships. Thus, UDDI presents busineses with an opportunity to step
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 thern, a number of companies joined the UDDIl community. As of this
book's writing, the UDDI project community is looking forward to releas
ing version 3.0of the UDDIspecification. This chapter covers version 2.0 of
the UDDI specification because it is widely implemnented and adopted as
of this writing. To find more information on the UDDI effort, visit the
UDDIofficial Web site at www.uddi.org.

.UDDI Registries
An implementation of the UDDIspecification is termed as a UDDIregistry.
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

AUDDI registry ican 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 wouBd 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.
Aprivate 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
additionaB security controls to protect the integrity of the registry data and
to prevernt access by unauthorized users. Note that aprivate node also can
participate in information replication.
AUDDI registry in itself is a Web service. A Web service consumer
queries the UDDI registry using the SOAPAPI defined by UDDI specifica
tion. Also, the UDDI specification publishes a WSDL description of the
UDDI registry service.
 UDDI project community members operate a UBR. This registry is
available to everyone for free pubhshing/querying of businesses and ser
vices information. To find more information on this publicly operated
UDDI registry, visit the UDDIWeb site at www.uddi.org.

Interacting with a UDDIRegistry

Typically, vendors implementing a UDDI registry provide two ways of
interacting with a UDDI Registry Service.
Agraphical user interface (GUI, for interacting with a UDD0 reg
istry. These GUIs also can be browser-based. The following is a list
of pubic UÐI registries, operated by various comparies such as
Microsoft, IBM, Hewlett Packard, and so on, that provide a browser
based interface to these registries:
https://uddi.rte.microsoft.com/search/frámes.aspx
https://www-3.ibm.com/services/uddi/v2beta/protect
/registry.html
htps://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

SytWAUTD1,4TRWRERU

nd brhem

Brtrot

-al ers
rcedleece qrvehe
gnal
Iedes
brad aane matd: C Yes
am CMesere: Gyes
ert y . BUnsartadAec CDemendng
Dore Unrtad DAKenKdne
PND

Figues3 Web-based GUIlto UDD0 registry.

 Aprogrammatic interface for communicating with the UDDI reg
istry. These programmatic interfaces are based on $OAP, because the
UDD0registry supports SOAP as the communication protocol.
Most of the vendors providing the UDD0 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 comtpany name,
addres, contact information, unique identifiers such as D-U-NS
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 pges.
Green pages level. Businesses that publish the technical information
describing the behavior and supported functions on their Web ser
vices make use of the DDlregistry as green pages.
Note that the UDDI specification does not explicitly make references
these different types of usage levels of the UDD0 registry. The categoriza
tion of these levels is rather implicit.

UDDISpecifications
All versions of the UDDIspecifications 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 UDDIregistries. Also, it describes the programmatic
interfaces supported by UDDIfor achieving replication between
UDDI registries operated by different operators.
UDDIoperators. 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
folow in order to manage the data of the UDDI registry node. Such
guidelines inchude the following:
Node operators' responsibiity for durable recording and backup
of all data.