minceillusionInternet and Web Development

Jul 30, 2012 (4 years and 8 months ago)




Universal Description, Discovery, and Integration
) is an
based registry for
esses worldwide to list themselves on the Internet. Its ultimate goal is to streamline online
transactions by enabling companies to find one another on the Web and make their systems
interoperable for e
commerce. UDDI is often compared to a telephone book'
s white, yellow, and green
pages. The project allows businesses to list themselves by name, product, location, or the Web services
they offer.

Microsoft, IBM, and Ariba spearheaded UDDI. The project now includes 130 companies, including some
of the biggest

names in the corporate world. Compaq, American Express,


AG, and Ford Motor
Company are all committed to UDDI, as is

, whose own XML
based directory approach,

, is now being integrated with UDDI.

While the group does not r
efer to itself as a standards body, it does offer a framework for Web services
integration. The UDDI specification utilizes World Wide Web Consortium (
) and Internet
Task Force (
) standards such as XML,

, and Domain Na
me System (
) protocols. It has
also adopted early versions of the proposed Simple Object Access Protocol (
) messaging
guidelines for cross platform programming.

In November 2000, UDDI entered its public

testing phase. Each

of its three founders

IBM, and Ariba

now operates a registry server that is interoperable with servers from other members. As
information goes into a registry server, it is shared by servers in the other businesses. The UDDI beta is
ed to end in the first quarter of 2001. In the future, other companies will act as operators of the
UDDI Business Registry.

UDDI registration is open to companies worldwide, regardless of their size

An inside look at UDDI

For Web services to be truly
useful, there has to be a way for people and companies to find them and connect to
them using a variety of public and private registries. These registries, called service registries, are a central part of
the Web services architecture. The registries are b
uilt using Universal Description, Discovery and Integration (UDDI),
a group of specifications that lets companies publish information about themselves and their Web services, and lets
others search through that information in order to find a Web service, b
ind to it and run it.

In this column, we'll look at the basics of UDDI, examine a UDDI listing, and also take a look at some of its
shortcomings, and why there are so few registries built using UDDI today.

The basics of UDDI

Like everything else having to
do with Web services, UDDI is based on XML. A UDDI registry is made up of XML
based service descriptors. Each service descriptor contains the information needed to find and then bind to a
particular Web service. So when someone searches through a UDDI regi
stry looking for a Web service, they're
searching through the XML listings. And when they find and bind to a Web service, they're using the XML information
contained in that listing.

UDDI is itself made up of three different elements. Each of the elements
isn't required for a listing, so not all listings in
UDDI registries contain all of the elements. But the more of the elements that are in a listing, the more easily a
service can be found and then bound to.

The three elements are:

A "white pages"

This con
tains the basic contact information for each Web service listing. It generally
includes basic information about the company, as well as how to make contact.

A "yellow pages"

This has more details about the company, and includes descriptions of the kind of
electronic capabilities the company can offer to anyone who wants to do business with it. It uses commonly
accepted industrial categorization schemes, industry codes, product codes, business identification codes
and the like to make it easier for companies

to search through the listings and find exactly what they want.

A "green pages"

This is what allows someone to bind to a Web service after it's been found. It includes the
various interfaces, URL locations, discovery information and similar data required
to find and run the Web

Listings are created using the Web Services Description Language (WSDL), and then send to a UDDI registry. UDDI
will ultimately allow registries to exchange listings with each other, so that if a listing is sent to one UDDI

registry, it
can be replicated to other registries. And there will be a combination of private and public registries

with private
registries reserved for business partners or potential business partners, and not the general public.

A look inside a UDDI

UDDI isn't really "cooked yet" as a standard, and so for now the few registries are experimental and contain only
basic information. IBM and Microsoft both have registries you can search, though, so you can get a preview of the
future by checking t
hem out. You can find Microsoft's at
, and IBM's

. And the UDDI.org
group, which promotes the use of the standard, lets
you search both registries, from here:

The information you'll find in the registries today is primarily of the "white pages" sor
t, with sometimes "yellow page"
information thrown in as well. To a large extent, "green page" information isn't yet available.

So what does an actual UDDI listing look like? It's in XML format, and a simple one is fairly easy to follow. Take a
look at the

following example, which is the UDDI listing for the FreePsychicNetwork.com in the Microsoft UDDI
registry. (No, I'm not making that up

it's real.) You'll very quickly get a good sense of the structure of a simple listing:


version="1.0" encoding="utf
8" ?>

<businessEntity xmlns:xsi="http://www.w3.org/2001/XMLSchema



operator="Microsoft Corporation"

ames UDDI Publisher"



<discoveryURL useType="businessEntity">http://uddi.microsoft.com/discovery?




<description xml:lang="en">

This is a UDDI Business Registry entry for


<contact useType="Main">

<description xml:lang="en">Main contact information</description>

<personName>Alma E Mounger<

<phone useType="Main">4079441169</phone>

<email useType="Main">jimmyrayswindle@hotmail.com</email>

<address sortCode="" useType="Main">

<addressLine>2775 Wells Ct</addressLine>

<addressLine>Kissimmee, FL 34744</addressLine>




<contact useType="Technical">

<description xml:lang="en">Technical contact information</description>

<personName>Alma E Mounger</personName>

<phone useType="Technical">4079441169</phone>

email useType="Technical">jimmyrayswindle@hotmail.com</email>

<address sortCode="" useType="Technical">

<addressLine>2775 Wells Ct</addressLine>

<addressLine>Kissimmee, FL 34744</addressLine>




<contact useType="Billing">

<description xml:lang="en">Billing contact information</description>

<personName>Alma E Mounger</personName>

<phone useType="Billing">4079441169</phone>

<email useType="Billing">jimmyrayswindle@hotmail.com</email>

<address sortCode="" useType="Billing">

<addressLine>2775 Wells Ct</addressLine>

<addressLine>Kissimmee, FL 34744</addressLine>






Where UDDI is today

As a
practical matter, UDDI is much further from being used than other Web service standards like XML and SOAP.
Registries today are experimental at best. One major problem is that the standard is still in the process of being
finalized. Notably, it is missing
upon security features

and without security, there's no way for companies to
restrict access to Web services to only trusted business partners. Because of that, companies simply aren't using
UDDI registries as a way to do business. For now each UD
DI registry uses its own security methods

Microsoft uses
its Passport technology, while IBM uses its own security methods.

Beyond security, there are other issues as well. There has to be a better, agreed
upon taxonomy that will accurately
describe all t
he categories that businesses fall into, or else the registries won't be usable. And companies have to
actually build service descriptors using WSDL before they can be listed in the registries, a practice that is now far
from common.

So for now, UDDI regis
tries are not much more than a "proof of concept." But if Web services are to take off in a big
way, you'll be hearing a lot more about them

and using them as well.



Universal Description, Discovery,

and Integration

(UDDI) is fast becoming a standard for storing
business processes available on the Web. Although UDDI is capable of storing many different types
of data, for the purposes of this tip, I’ll focus on how UDDI can be used to register Web serv
thereby making them available for application
level consumption.

Back to top


You are using

IBM® WebSphere® Studio Application Developer V5.0

Developer) or another J2EE compliant development environment, such as the

Eclipse IDE

® has been installed, and the sample database has been created (this sample uses the
Employee and Department tables. To create the sample database, open DB2 First Steps
and click on the "Create

Sample Database" link).

UDDI registry is installed and properly configured. Please see the InstallUDDI listing for an
automated setup of a UDDI registry to use the Cloudscape database.


from a command window to create the necessary directory

Back to top

What this tip covers

his tip provides Java developers with a fast and simple way to develop their own UDDI Java
applications to consume Web services registered within a UDDI registry. The

sample code

contains a Payroll Web service (deployed from an entity bean) and a UDDI session bean.

Back to top

Tip background

This tip i
s based heavily on the tutorial "
Discover Web services with the WSDK V5.1: UDDI
, November 2003), which is cited in the Resources section. My
intention is to
present an extension to the basic Universal Description, Discovery, and Integration for Java
(UDDI4J) classes in order to help you quickly stand up your own UDDI registry of Web services.
While working through the "Discover Web services wit
h the WSDK V5.1: UDDI" tutorial, I developed
an extension API that provides a higher
level approach to the UDDI4J API. This tip extends only a
small subset of the UDDI4J functionality, since its purpose is to register, discover, and consume a
Web service s
tored within a UDDI registry. For a more broad discussion of UDDI and its uses
beyond storing Web services, please see "
Understanding UDDI
" (
, July 2002), by
om Bellwood.

Back to top

Payroll Web service



file included contains an Enterprise JavaBeans (EJB) project named

Within this EJB project are two entity beans: Department and Employee, and

one session bean,
Payroll. The Department and Employee entity beans expose getter and setter methods for the
sample database. The Payroll bean, which exposes 12 methods, uses the getter methods of the
entity beans to query various pieces of information fr
om the sample database. The


might easily be extended to provide setter functionality from within the Payroll bean. Exposing
all of the sample databas
e fields is beyond the scope of this tip.

Back to top

UDDIClient session EJB

The UDDIClient

session bean makes almost exclusive use of the UDDI utility API discussed in the
next section.

A UDDI registry might contain Businesses, Services, and TModels. The UDDIClient bean provides a
publish() and two delete() methods for each type of UDDI entry.
As shown in

Listing 1

below, method
signature methods are as simple as possible, while shifting the work to the UDDI Utility API.

Listing 1.

Method signatures


String publishBusiness(String busName)





public void

deleteBusinessByName(String busName)




public void

essByKey(String busKey)





String publishService(String serviceName, String busName,

String tModelName, String tModelOverviewDoc,

String accessPointStr, String description)






public void

deleteServiceByName(String serviceName)




public void

ring serviceKey)





String publishTModel(String tModelName, String overviewDocString)





public void

(String tModelName)




public void

deleteTModelByKey(String tModelKey)




Methods getService and executeService

The getService and executeService methods

of the UDDIClient bean demonstrate how to retrieve
our Payroll Web service and invoke some of its methods. The executeService method takes a string
representing the name of a service stored in the registry. In the sample code, the service registered
is th
e Payroll Web service. For the purposes of this tip, I’ve hard coded two methods that are called
from the Payroll Web service found within the registry, as shown in

Listing 2

Listing 2. Methods getService and executeService


* Execute a Service found in the UDDI registry

* @param serviceName Service name used to search for

and execute available UDDI Services


public void

(String serviceName)


//Obtain all access points for services providing this


Map accessPoints =


//Create a set of accespoints

Set accessSet = accessPoints.keySet();

Iterator it
= accessSet.iterator();

Payroll payroll =

Object obj =





//For each access point, create an

PayrollService object

String accessPoint = (String)it.next();

System.out.println("Service Access Point: " +


payroll = getService(accessPoint);

(payroll !=


System.out.println("Employee 000010's

bonus is " + payroll.getBonus("000010"))

System.out.println("Employee 000010's

phone number is " + payroll.getPhoneNo("000010"));



(Exception e)







* Create a Service object, to communicate with the

Web service defined by
the URL

* @param urlString the URL of the Web service

* @return A PayrollService object.



Payroll getService(String urlString)


PayrollServiceLocator payrollServiceLocator =



Payroll payroll =



URL url =


System.out.println("Payroll URL: " + url.toString());

System.out.println("Getting Payroll object");

payroll =


System.out.println("Payroll object retrieved




(MalformedURLException e)


System.out.println("URL Exception: " + e.toString());


(javax.xml.rpc.ServiceException se)


System.out.println("Service Exception: " +






Back to top

UDDI utility API

The UDDI Utility API has four main classes, three of which I will cover in detail in Listings


, and

The fourth, Utilities.class, contains all of the setup information for the UDDI registry. The values and
structure are explained in detail in the "
Publishing your services on UDDI with the WSDK V5.1
, November 2003) tutorial.

Listing 3. BusinessUtilities


* Display business information of a BusinessEntity

* @param

businessKey The businessKey of the BusinessEntity

whose detail is to be displayed


public static void

showBusinessDetail(String businessKey)


* Locate a Business by name

* @param busName The business name used to search for a business

* @retur
n Vector: This method returns a Vector of Strings.

Each String represents the businessKey of a business matching the query


public static

Vector findBusinessByName(String busName)


* Locate a Business by key

* @param businessKey The business ke
y used to search for a business

* @return BusinessList: This function returns a BusinessList on success.

In the event that no matches were located for the specified criteria,

a BusinessList structure with zero BusinessInfo structures is returned.


public static

BusinessList findBusinessByKey(String businessKey)


* Delete a Business by name

* @param busName Business name used to find and delete a business


public static void

deleteBusinessByName(String busName)


* Delete a Business by


* @param businessKey A Business key used to find and delete a business


public static void

deleteBusinessByKey(String businessKey)


* Publish a Business

* @param busName The name of the business to be published

* @return String: This metho
d returns a String representing the

key of the newly published Business


public static

String publishBusiness(String busName)

Listing 4. ModelUtilities


* Locate a technical Model by name

* @param tModelName the Name

* @return Vector: This method returns a Vector of

tModelKey Strings


public static

Vector findTModelByName(String tModelName)


* Locate a technical Model by key

* @param tModelName The TModel key used to search for a TModel

* @return TModelLi
st: This method returns a TModelList

of TModelInfos objects


public static

TModelList findTModelByKey(String tModelKey)


* Delete a technical Model by name

* @param tModelKey TModel name used to delete a TModel


public static void

deleteTModelByName(String tModelName)


* Delete a technical Model by key

* @param tModelKey TModel key used to delete a TModel


public static void

deleteTModelByKey(String tModelKey)


* Publish a technical Model

* @param tModelName The TMod
el name

* @param overviewDocString This parameter expects a

String representation of the WSDL address.

EX: http://localhost:9080/MyRouter/Test.wsdl

* @return String: This method returns a String

representing the key of the newly published TMod


public static

String publishTModel(String tModelName,

String overviewDocString)

Listing 5. ServiceUtilities


* Locate a Service by name

* @param serviceNames A vector of Name objects

* @return Map: This method returns a Map of service

and business key pairs


public static

Map findServiceByName(Vector serviceNames)


* Locate a Service by key

* @param serviceKey A key used to search for a Service

* @return ServiceList: This

method returns a ServiceList of

ServiceInfos objects


public static

ServiceList findServiceByKey(String serviceKey)


* Delete a Service by name

* @param serviceName Service name used to find

and delete a Service


public static void

deleteServiceByName(String serviceName)


* Delete a Service by key

* @param serviceKey Service key used to find and delete

a Service


public static void

deleteServiceByKey(String serviceKey)


* Publish a Service

* @param serviceName The n
ame of the Service to be published

* @param businessName The Business name used to

associate the service to. If Business name does not exist

in the registry, a Business entry will be created.

* @param tModelName The TModel

that the service implements.

If TModel is not found in the registry and the

TModelOverviewDoc parameter is not null, a TModel entry

will be created.

* @param tModelOverviewDoc Required only if the TModel name

provided in the tModelName parameter

is not

found in the registry.

This parameter expects a URL
String representation of the

WSDL address. EX: http://localhost:9080/MyRouter/Test.wsdl

* @param accessPointStr

* @param description Optional Service description.

* @return String: This m
ethod returns a String representing

the key of the newly published Service


public static

String publishService(String serviceName,

String busName, String tModelName, String tModelOverviewDoc,

String accessPointStr, String description)

Back to top


Get the products used in this tip

If you are a developerWorks subscriber, you have a single user license to use

WebSphere Studio Application Developer

and other
DB2, Lotus®, Rational®, Tivoli®, and WebSphere products

including the Eclipse
based WebSphere Studio IDE

to develop, test,
evaluate, and demonstrate your applications. If you are not a subscriber, you can
subscribe today

As you have seen, UDDI programming can be a very powerful way to share information on

the Web
using the UDDI registry. This sample code, and more specifically, the UDDI Utility API are provided
as a starting point from which you can develop a more customized solution.


UDDI4J lets Java do the walking

Access any UDDI registry from within Java using the UDDI4J API


Andr&eacute; Tost,







Discuss (6)








Web services technology allows the communication between applications across the Internet over standard, XML
based protocols. The Simple Object Access Protocol (SOAP) invokes a Web service, which can be located anywhere
on the Internet and

written in any programming language. A Web service's interface is described using the Web
Services Definition Language (WSDL). Public registries exist where a service provider can publish services and
service requestors can find them. Such registries foll
ow the Universal Description, Discovery, and Integration (UDDI)

The standard defines an XML
based API with which clients access the registry. The open source
UDDI4J project defines a Java API that provides access to any UDDI registry from within

a Java
application. UDDI4J lets you publish and find information in a UDDI registry by wrapping all the XML
artifacts used by UDDI. It also handles the network access to a registry via the SOAP protocol,
making it easy to integrate UDDI access into any ne
w or existing Java application.

In this article, I introduce UDDI in general, then move on to the UDDI4J API, including some
programming examples demonstrating its use. I will not cover the Web services architecture in any
detail, nor will I explain the SO
AP or WSDL specifications. Please see

for links to further
articles and tutorials on these topics.


UDDI defines a set of registries that contain
information about businesses and the services they
offer. Moreover, it defines a set of specifications: one specification for an XML schema that defines
the structure of the contained data, one specification for a common API to access this data, and one
I for the replication of data between different registries. A community of over 220 companies now
back UDDI, each working together to define and support the comprising specifications.

Currently, two production UDDI registries exist: one hosted by IBM and o
ne by Microsoft. Hewlett
Packard's registry should launch later this summer. (See


for links to all three registeries.)
Since they replicate information

between each other, any one provides all available information.

UDDI data structure

A UDDI registry contains data in a combination of

white pages,yellow pages,


green pages.

white pages information includes items such as a business's name, its
address, and other contact
information. The yellow pages help categorize a business; they define its business type, as well as
the industry in which it operates. Lastly, the green pages define what kinds of services a business
offers, and how to electronic
ally communicate with these services.

All UDDI registry data is formatted in XML. As such, the data structure specification defines the XML
schemas all entries must follow. Some of the more generic defined elements can exist at various
places of the regist


A generic information container that typically points to a technical specification, thus making it possible
to use

s as technical fingerprints to identify certain services. Each


possesses a unique key. A
number of entries in the UD
DI registry use

, but most notably they are contained in a binding template,
described below.

Identifier Bag

A number of named key
value pairs. Many of the elements in a UDDI registry can
contain identifiers to help classify the given information. O
n top of that, each identifier includes a reference to

, which indicates the key type contained in the identifier.

Category Bag

Contains a number of categories that resemble identifiers but have predefined taxonomies.
For example, you'll find a
category for industry codes as defined by the North American Industry Classification
System (NAICS).

These elements help find businesses based on their industry classification, or based on certain
technical specifications (
s, for example) they suppo

The other elements defined in the UDDI specification describe the actual businesses and their
offered services:

Business Entity

Contains general information about a business, such as its contact information and
business type categorization data. The

entry also contains a number of business service entries.

Business Service

Represents the service a business offers. It contains a description, as well as an
point element that defines where the service is located. Each business service entry cont
ains a number of
binding templates.

Binding Templates

Contains a reference to one or more

s, which helps classifying the
offered service.

Figure 1 shows

the elements contained in a UDDI registry and their relationships. Please note the
missing entry: the
, an element added to UDDI version 2.0, which no
production registry yet supports.


helps define relationships between

business entity entries. As it's not supported, we will not look at it in any detail.

Figure 1. A UDDI registry


The UDDI API specification defines itself as a collection of XML requests and their responses

making the API
completely programming
language neutral. There are two types of APIs: find
methods and publish methods. Obviously, the find methods find certain entries in the registry; they
do not make any updates.

You can call finder methods to retrieve any kind of entr
y contained in the registry. Finders exist for
business entities, business services, or even individual

s. The criteria passed with a find
method can be a specific key

to find all the services offered by a particular business, for example.
Or it c
an be category or


information, for example to find all businesses that offer services
associated with a particular specification identified by its


With the publish methods, you create new entries, change existing entries, and delete entries.

you can change business entities, business service entries, and also to

s. All publish APIs
require userid/password credentials to be passed with every request.

These methods' parameters and return values reflect the defined UDDI data structu
res closely.
Since the API, as defined, is a collection of XML messages, some of these messages simply contain
the exact structure of the element they represent.

UDDI for Java (UDDI4J)

A typical UDDI API implementation uses SOAP under the covers to access
a UDDI registry. Each
registry provides SOAP access points. One example for such an implementation: UDDI for Java
(UDDI4J). The open source UDDI4J project provides a Java implementation of the UDDI API
specification. You can use it to access all registries

following the specification. (See

access the latest version of the UDDI4J implementation, which, at the time of this writing, is 1.0.3.)

At i
ts core, UDDI4J maps the data structures defined in UDDI into Java objects. For example, the
business entity data structure has the following XML schema definition:

Page 3 of 4

<element name="businessEntity">

<type content="elementOnly">

group order="seq">

<element ref="discoveryURLs" minOccurs="0" maxOccurs="1"/>

<element ref="name"/>

<element ref="description" minOccurs="0" maxOccurs="*"/>

<element ref="contacts" minOccurs="0" maxOccurs="1"/>

<element ref="businessServices" minOccurs="0" maxOccurs="1"/>

<element ref="identifierBag" minOccurs="0" maxOccurs="1"/>

<element ref="categoryBag" minOccurs="0" maxOccurs="1"/>


<attribute name="businessKey" minOccurs
="1" type="string"/>

<attribute name="operator" type="string"/>

<attribute name="authorizedName" type="string"/>



Without delving into too much detail, you can see that a business entity element contains a number
of other
elements (

, and so on), as well as three

, and


Now let's look at the respective Java class defined in UDDI4J
. We won't list the e
ntire source here, just
the significant pieces:

public class BusinessEntity extends UDDIElement {

public static final String UDDI_TAG = "businessEntity";

protected Element base = null;

String businessKey = null;

String operator = null;

g authorizedName = null;

DiscoveryURLs discoveryURLs = null;

Name name = null;

Contacts contacts = null;

BusinessServices businessServices = null;

IdentifierBag identifierBag = null;

CategoryBag categoryBag = null;

// Vector of Description objects

Vector description = new Vector();



The remainder of the class consists of get and set methods for the class's attributes. You can tell
that elements and attributes of the XML definition for business entity a
re treated the same way in the
Java class.

You will find a similar class for all structures defined in the UDDI specification. Not only are the data
structures mapped in this way, there are also classes for all request and response structures defined
in th
e UDDI API specification. However, a typical client will not use those classes to access a UDDI


class performs that task.

The UDDIProxy class

To access a UDDI registry, a client program employs the



Not only does it wrap
the find and publish methods defined in the UDDI specification,


also handles the
network access to the actual UDDI registry server. UDDI registries provide a SOAP access point for
clients to use. The


class uses th
e Apache SOAP implementation to send and receive
messages to and from the registry. You merely specify to the class the registry's URL and use any
method defined on it, plus the type of network protocol you want to use (HTTP in most cases).

Thus, the call
to construct an


instance looks like:

UDDIProxy up = new UDDIProxy(

new URL("http://www.ibm.com/services/uddi/inquiryapi"),

new URL("https://www.ibm.com/services/uddi/protect/publishapi"),

new org.apache.soap.transport.http.SOAPH

In this example, the proxy is set up to talk to the IBM UDDI registry. Note that each UDDI registry
provides a test area you can use for testing purposes. Note also that the URL for publishing uses
HTTPS for the communication, since it m
akes changes to the registry. You will see later that you
need to provide a valid userid/password combination for making changes. The last parameter
indicates that we want to use HTTP as the network protocol to talk to the registry. You can download
the Ap
ache SOAP implementation that includes this class at


Use the find methods

Next, to find existing business entries and their services, turn to the


class. I
earlier that the hierarchy of entries in a UDDI registry starts with business entities, which contain
business services with binding templates and so forth. To browse a registry, you therefore start with
the appropriate find method for a business

entity, called

. The following code
extract shows how you can list all businesses whose name starts with "J" (assuming you have
created an instance of


called "up" like shown above):

BusinessList bl = up.find_business("J", null, 0)

Vector businessInfos = bl.getBusinessInfos().getBusinessInfoVector();

Enumeration enum = businessInfos.elements();

while (enum.hasMoreElements()) {

BusinessInfo bi = (BusinessInfo)enum.nextElement();

System.out.println("found a business : "+


Once you have the


object, you can retrieve the supported services by using


method and so forth. The


file shows an example for
how to drill down the hierarchy of entries in the reg
istry. The sample code uses the IBM test registry,
but you can access any other registry, too. It expects one input parameter as the search criteria for



Use the publish methods

Now that you have seen how to find entries in a reg
istry, let us look at how to create new entries

the publish methods' job. As above, you'll employ the



However, before you can create your own entries, please note that both the IBM and the Microsoft
registry make publishing availa
ble only via an HTTPS connection. A standard JVM cannot create
such a connection, so you'll have to make other arrangements.

"Java Tip 96: Use HTTPS in Your
Java Clie
nt Code"

explains how to do so. Please also note: to make changes, you must register with
those sites. The simple registration for the test areas gives you a valid userid and password

Let us assume you have a business, called John's Balance Bu
siness that offers accounting services.
You want to create a UDDI entry for your business. With the business entity, you want to associate a
category bag that shows your business as an accounting business. The following code creates


instance, t
he required authentication object, and a category bag:

UDDIProxy up = new UDDIProxy(

new URL(


new URL(


new org.apache.soap.transport.http.SOAPHTTPConnection());

AuthToken at = up.get_authToken("myuserid", "mypassword");

String ais = at.getAuthInfoString();

KeyedReference kr =

new KeyedReference("Other Accounting Services", "541219");

/ The following UUID references the NAICS TModel key


Vector krVector = new Vector();


CategoryBag cb = new CategoryBag();


To finish, you create the new business entity, add the category bag to it, and save it in the registry:

Page 4 of 4

BusinessEntity be = new BusinessEntity();

be.setName(new Name("John's Balance Business"));

business doing balance stuff.");


Vector beVector = new Vector();


try {

up.save_business(ais, beVector);

System.out.println("Business saved.");

} catch (UDDIException x) {

System.out.println("Caught e
xception : "+x.getFaultString());


You can find a complete sample in the


file contained in

. There you'll also find the

file that shows how to delete your
newly created entry.

You may have noted that the samples shown do not address where to store an actual WSDL
document. In fact, the UDDI specifications operate completely independent of WSDL or SOAP. The
issue of where and how to store a WSDL document in a UDDI registry is beyond the scope of this
article. You can find a link to a whitepaper explaining this in


Show developers UDDI4J, and you've shown them the world!

In this article you learned how you can use the UDDI4J API to access information stored in a UDDI
registry, thus allowing access to information about businesses and their Web services

from within
any Java application. UDDI4J users can skip the specifics of the network access to a registry, as
well as the details of the XML documents stored there. You also learned about the basic structure of
the content stored in a registry, and how th
e UDDI4J maps this content into the Java language.

You can now use this knowledge and start developing your own applications that integrate UDDI
information. The sample source code that comes with this article can serve as a starting point. For

use one of the available test registries at first. Consider the following usage scenario: you
have integrated a particular Web service into your application. You could add functionality to
automatically refresh the cached information about the location of

that Web service in case it
becomes unavailable. With UDDI4J, this should be a relatively easy task. Enjoy!

About the author

Andr� Tost works as a solution architect for IBM's Software Group in Rochester, MN. He holds a degree in
electrical engineering
from Berufsakademie Stuttgart, Germany, and has been working on various object
development projects over the last seven years.