UDDI Publishing with Java

Like this article? We recommend

UDDI: Building Registry-based Web Services Solutions

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

UDDI: Building Registry-based Web Services Solutions

Learn More Buy

UDDI4J APIs

UDDI4J provides a set of Java APIs to interact with a UDDI registry. UDDI4J isn't the only Java API available today, but it's likely to be a dominant API due to endorsement from IBM and HP. The UDDI4J is an ongoing open source project.

To demonstrate the use of the Java APIs, let's walk through the business case of a service provider that wants to publish its service within the Universal Business Registry (UBR), a global pool of UDDI registries.

Establishing Connection

Per the UDDI specification, a registered and validated user (or program) can publish information on a UDDI registry. The registration and validation comes in form of an authentication token. This token has a specific lifespan during which it can be presented to the registry for publishing purposes. A Java program segment used for this purpose might look like this:

UDDIProxy proxy = new UDDIProxy();
proxy.setPublishURL("URL of the UDDI registry");
System.out.println("Getting authtoken");

// Pass in userID and password registered at the UDDI site
AuthToken token = proxy.get_authToken("Passport login name",
 "Passport login password");
System.out.println("Returned authToken:" + token.getAuthInfoString());

// Now get the information registered for this publisher.
RegisteredInfo ri = proxy.get_registeredInfo(token.getAuthInfoString());
System.out.println("\n\nUDDI Operator: " + ri.getOperator());

When the get_authToken method is invoked, the UDDI4J APIs interact with the UDDI registry in XML format and receive an authentication token upon successful authentication. This token can then be used when publishing data about a service or service provider. Let's consider an example.

Prudentially 401(k), Inc. is a subsidiary of a global financial services conglomerate that specializes in providing pension fund management services to its clients. The company has established a large clientele through the years and is one of the founding members of the Financial Interactions and Transactions Standardization Organization (FITSO).

FITSO is an established not-for-profit consortium of large financial institutions in North America, including pension fund providers. FITSO has embarked on a standardization effort to make interacting with financial service organizations simpler and more predictable. FITSO is currently focusing on pension fund providers and hopes to roll out the experience to other financial service areas thereafter. After investigating web services standards and interaction patterns, FITSO decides that it needs to adopt and encourage two types of standards:

• Classification scheme for business entities

• Set of basic interaction patterns

Given the familiarity of the North American Industry Classification System (NAICS) in the financial industry, FITSO decides to recommend the NAICS classification scheme to classify the business entities behind the pension services. This taxonomy choice translates to using the NAICS tModel preloaded in the UDDI registry.

FITSO has also decided to standardize on basic interactions. Service consumers would be able to develop applications that interact with the services; the vision is that applications designed to work with one service would easily interchange with another. Based on the types of interactions that are simple enough to standardize, FITSO designs a set of service interfaces for the pension fund services. For this example, we focus on the 401(k) information services specification. The functions that should be supported by a FITSO pension fund are as follows:

1. Get list of funds.

2. Get fund performance.

3. Add employee to a plan.

4. Get employee contribution data.

FITSO needs to register a tModel associated with this service interaction interface, as shown later in this article. This tModel is called TM401k. Prudentially 401(k), Inc. needs to use this information when registering as a company that provides a service abiding by the TM401k tModel. Assume that the registration data for Prudentially 401(k) is as shown in the following table.

FITSO Compliance-Based Prudentially 401(k), Inc. Modeling

Publishing a Business Entity

Before its services can be published, Prudentially 401(k), Inc. needs to register its business entity with the UDDI registry. This registered entity assumes ownership of the services registered thereafter. Service consumers who discover services applicable to their needs can then search for the responsible entity to get more information about the service provider.

In UDDI4J, the main class that drives the registration of the business entity is BusinessEntity. This class acts as the container that holds the information necessary to register the business. A properties file can be used to hold the information necessary for business entity registration. The properties used in this example are as follows:

# Properties file for business Prudentially401k, Inc.
BusinessName=Prudentially401k, Inc.
DiscoveryURL=http://www.tasmanAve.com/Prudentially401k
Description=Prudentially401k, Inc. is known for outstanding
 service to its customers for their 401(k) needs.
ContactName=John Doe
ContactPhone=212-555-1212

# NAICS (1997)
TModelKey=uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2
ClassificationName=Pension fund, third-party administrative services
ClassificationNumber=524292

The code segment below can be used to populate business entities for Prudentially 401(k), Inc.

UDDIProxy proxy = new UDDIProxy();
proxy.setPublishURL("URL of the UDDI registry");
AuthToken token = proxy.get_authToken("Passport login name",
 "Passport login password");

Properties bep = new Properties();
bep.load("FileInputStream object for the properties file");

BusinessEntity be = new BusinessEntity("", businessName);
be.setDiscoveryURLs(new DiscoveryURLs(createBusinessURLVector(bep, "DiscoveryURL")));
be.setDescriptionVector(createDescriptionVector(bep, "Description"));
Contacts cs = new Contacts();
cs.setContactVector(createContactVector(bep));
be.setContacts(cs);

Notice that the BusinessEntity object is instantiated with a null key (""). This is a trigger for the UDDI registry to treat this registration as new and assign a key. If a key is provided, the transaction is treated as an update of an existing entity associated with the specified key. Various create* functions referenced in this code segment create the necessary Vector objects required to build corresponding portions of the business entity registration. For example, the createBusinessURLVector method is as follows:

public static Vector createBusinessURLVector(Properties p, String propertyName)
{
Vector resultVector = new Vector();
DiscoveryURL du = new DiscoveryURL(p.getProperty(propertyName), "");
resultVector.add(du);

return resultVector;
}

For the human-readable description associated with any attribute, such as the business entity description above, the UDDI specification allows one description per language code. The applicable language codes are defined by the Internet Engineering Task Force (IETF) standard known as Request For Comment (RFC) 1766.

Classifying a Business Entity

At the time of registration, a business entity should also be categorized properly so that it can be discovered by appropriate clientele, although this is not mandated by the UDDI specification. Prudentially 401(k), Inc. needs to classify itself under the NAICS taxonomy and the Pension Fund classification code, 524292, because of the FITSO specification. For each classification, three data elements are required:

• tModel key associated with the classification scheme

• Key name under which the entity is classified

• Value or code associated with the key

A class CategoryBag holds these three elements together:

//Set the category of the business based on properties file data
CategoryBag cb = new CategoryBag();
cb.setKeyedReferenceVector(createCategoryVector(bep));
be.setCategoryBag(cb);

//Add the business entity to the entities object used during
// registration
Vector entities = new Vector();
entities.add(be);

Although not used in this example, a business entity should also specify the set of identifiers, such as DUNS identifiers, that can uniquely identify the entity. Even though providing these identifiers is optional, they help in precision of a discovered entity. Like the classification scheme, the UDDI specification does not mandate any identification scheme.

Once the BusinessEntity container object is ready with all the necessary information, the entity can be registered using the save_business method of the UDDIProxy class:

//Register the business
BusinessDetail bd = proxy.save_business(token.getAuthInfoString(),entities);

The returned BusinessDetail object can be used to get the UUID key assigned to the registered resource.

Publishing a tModel

Recall that FITSO developed a service interaction specification, TM401k, for the pension fund 401(k) information services. This interaction specification needs to be registered in UDDI as a tModel.

In UDDI4J, the main API for registering the tModel with the UDDI registry is the save_tModel method of the UDDIProxy class. This method is used for registering (and modifying) a tModel with the registry. As with the earlier example, the properties for registering the tModel are assumed to be stored in a file as follows:

# Properties file for TM401k tModel
TMName=TM401k
TMDescription=tModel defined by FITSO for 401(k) interactions
TMOverviewDoc=http://www.tasmanAve.com/FITSO/TM401k.wsdl

# Taxonomy to classify.
# uddi-org:general_keywords
CategoryTModelKey=uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4
ClassificationName=KEYWORD
ClassificationValue=401(k)

As with the BusinessEntity class, the tModel object model needs to be populated before being saved in the UDDI registry:

Properties TMp = new Properties();
TMp.load("FileInputStream object for the properties file");

Vector tModels = new Vector();
TModel tModel = new TModel("", TMp.getProperty("TMName"));
tModel.setDefaultDescriptionString(TMp.getProperty("TMDescription"));
OverviewDoc od = new OverviewDoc();
od.setOverviewURL(TMp.getProperty("TMOverviewDoc"));
tModel.setOverviewDoc(od);

//Add taxonomy data
CategoryBag cb = new CategoryBag();
cb.setKeyedReferenceVector(createCategoryVector(TMp));
tModel.setCategoryBag(cb);

tModels.add(tModel);

//Register tModel
TModelDetail tmd = proxy.save_tModel(token.getAuthInfoString(), tModels);

The data elements associated with tModel registration are similar to those of a business entity registration—name, description, category, and so on. The UDDI registry provides a unique UUID key for the tModel registration. The tModel can then be identified using this key.

Publishing a Service

Following a similar pattern, the main API for publishing a service to the UDDI registry is the save_service method of the UDDIProxy class. One additional service detail to note is the field BusinessKey, which links the service to the responsible or publishing business entity. In this case, we link the P401kService to the Prudentially401(k), Inc. business entity. The BusinessKey returned when the business entity was registered should be used in the associated properties file:

# Properties file for 401(k) service provided by Prudentially401k, Inc.
ServiceName=P401kService_Java
BusinessKey=Business key from save_business call
ServiceDescription=401(k) management service by
 Prudentially401(k), Inc. abiding by the FITSO TM401k tModel

#Replace the URL below with actual service URL
AccessPoint=http://www.tasmanAve.com/Prudentially401k/P401kService

#tModel key for TM401k service. Replace with appropriate
 tModel key for your example.
ComplianceTModelKey=uuid:40af6cbd-a9f6-40e1-b72e-937cc7ccd549

# Taxonomy to classify.
# uddi-org:general_keywords
CategoryTModelKey=uuid:A035A07C-F362-44dd-8F95-E2B134BF43B4
ClassificationName=KEYWORD
ClassificationValue=401(k)


Properties Svcp = new Properties();
Svcp.load(("FileInputStream object for the properties file");

In addition to this information, the service binding information must also be provided. This binding information includes data about a specific instance of the service such as service access point and the tModel with which the service complies:

//Set the binding templates of the service based on
 properties fileBindingTemplates bt = new BindingTemplates();
bt.setBindingTemplateVector(createBindingTemplateVector(Svcp));

BusinessService bs = new BusinessService("",
 Svcp.getProperty("ServiceName"), bt);
bs.setBusinessKey (Svcp.getProperty("BusinessKey"));

bs.setDefaultDescriptionString(Svcp.getProperty("ServiceDescription"));

//Set the category of the service based on properties file data
CategoryBag cb = new CategoryBag();

cb.setKeyedReferenceVector(createCategoryVector(Svcp));
bs.setCategoryBag(cb);


Vector services = new Vector();
services.addElement(bs);

//Register service
ServiceDetail sd = proxy.save_service(token.getAuthInfoString(),services);

A service must also be classified, like other resources such as business entities and tModels. This process is similar to one discussed earlier in the article.

Deleting from a Registry

The UDDI specification also provides delete functionality that can be used to retire any resources that no longer need to be advertised. The corresponding APIs in UDDI4J require appropriate authentication to delete a resource and the unique identifier key. Ideally, the publisher would have a list of all the resource identifier keys. If not, the publisher could find the resource, obtain its identifier key, and then delete it from the registry. Simply obtaining the identifier key of a resource does not provide ownership over the resource; the identifier key is merely a unique reference to the resource. The UDDI registry establishes ownership relationships within the registry itself. Therefore, only the UDDI user who published a resource to the registry can delete it. Typically, the UDDI4J APIs for deleting a resource take the form of delete_<resource>. The following code segment demonstrates deleting a service:

DispositionReport dr =
  proxy.delete_service(token.getAuthInfoString(),
  dsp.getProperty("ServiceKey"));

Other UDDI-registered resources such as binding templates, tModels, and business entities can be deleted in a similar manner using corresponding APIs and classes. Because tModels are extensively referenced in the UDDI data model, they cannot simply be deleted from the registry. When a delete_tModel API is invoked, the specified tModel is "hidden." This means that the deleted tModel cannot be discovered using find_tModel, but the details can still be obtained using get_tModel. Discoverability is removed, but existing users can continue to use the tModel. The only way to completely remove a tModel is to petition the operator where the tModel was saved.