Home > Articles > Programming > Java

Like this article? We recommend

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.

NOTE

If you have read the previous articles in this series, the following examples will look familiar. The UDDI publishing and inquiry processes are the same regardless of the programming language you choose. The difference between the examples in this article (using Java) and those of the first article in the series (using C#) come from differences in language-specific APIs—class names and so on.

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

Model

UDDI Representation

Business

Entity: Prudentially 401(k), Inc.

Classification

NAICS

Subclassification

524292

Service

Prudentially401kInformationService

Interface Specification

TM401k


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020