Web ServicesKey Features of UDDI4J Version 2

Key Features of UDDI4J Version 2

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Look at the UDDI (Universal Description, Discovery and Integration) Project as a building block for e-commerce that’s bigger and more important with every revision. As an open, comprehensive enabler, business processes can discover each other, dynamically define how they interact over the Internet, and transact with one another via their preferred applications. With this viewpoint, UDDI4J is a Java class library that enables applications to interact with any UDDI registry. This open-source library is endorsed by IBM, HP, and SAP, who are operators of the public UDDI Business Registry (UBR), and is freely available at www.uddi4j.org. HP offers its UDDI Version 2 public UBR at uddi.hp.com.

With the recent version 2 releases of UDDI and UDDI4J Version 2, several important new features are now available. UDDI Version 2 supports the ability to search trusted-partner services, provide localized service and business names, and share services between partners. UDDI4J provides full support of the UDDI Version 2 (V2) specification and includes support for multiple SOAP transports, configuration capabilities, and debug logging. With the introduction of these new features, applications can better locate and communicate with Web services.

Finding a Web service can be a tricky endeavor. They are executable objects accessible via XML that live anywhere on the Internet. Finding an appropriate set of services that match desired criteria is one purpose of a UDDI registry. The Web Services model has three main functions, called publish, find, and bind. UDDI provides two of them, namely publish and find. The publish function allows developers to place a service into a registry and identify the service. Find is the mechanism by which applications locate a services.

UDDI registry information is divided into five data structures. This data partitioning is meant to facilitate rapid location and use of registration semantics and be familiar to business users. Each structure contains fields that comprise a business or technical description purpose.

The five data structures are:

  • BusinessEntity: Describes the publisher of services, typically an organization.
  • BusinessService: Describes a service.
  • BindingTemplate: Specifies service entry points and construction
  • TModel: Specifies taxonomies (namespaces) or service types and is the basis for technical fingerprints.
  • PublisherAssertion: Asserts a relationship between two parties, by one or both.

New Features

With the introduction of UDDI Version 2, both the UDDI specification and the UDDI4J classes include new features. Both sets of enhancements are described below, divided into specification and library features. The following new capabilities are part of the UDDI Version 2 specification:

  • Creating partnerships through the Publisher Assertion.
  • Service Projections are mechanisms to identify services shared between various organizations.
  • Contact information is now structured and can be validated within a Taxonomy.
  • Better support for multi-language requirements.
  • Validation of categorization values.

The following features are new capabilities of the UDDI4J library:

  • Logging features allow developers to view and store XML messages for events.
  • Transport Independence allows multiple transport protocols to be employed.
Trusted-partner creation

In the UDDI registry, a company is described through a Business Entity object. The Business Entity object contains information about a company and its published services. Other information in the Business Entity identifies the company’s business identifiers, e.g., Dunn & Bradstreet number, business categories, URLs, and other descriptive data to enable interaction with the company. Publisher Assertions offer useful mechanisms to link top-level Business Entities together, to identify various top-level businesses as part of the same company or partners.

Listing 1 contains a code fragment that shows how two companies assert a peer-to-peer, or partnership relationship between each other. In this example, Company A and Company B will assert a partnership. In order to complete a mutual assertion, the following code needs to be executed by Company A and Company B . “BkA” and “BkB” represents the key of Company A and Company B respectively, which is obtained during the creation of their Business Entity structures.

Listing 1: Code fragment for a mutual assertion.

String fromKey = "BkA";String toKey    =  "BkB"; KeyedReference keyedReference = new KeyedReference ("Partner  Company","peer-peer");// Set the TmodelKey  so that it refers to uddi-org:relationshipskeyedReference.setTModelKey(TModel.RELATIONSHIPS_TMODEL_KEY);PublisherAssertion publisherAssertion =            new PublisherAssertion(fromKey,toKey,keyedReference);// token is AuthToken obtained using get_authToken() call earlier for the respective publisher// account ( Company A or Company B).DispositionReport dispositionReport=proxy.add_publisherAssertions(token.getAuthInfoString(),  publisherAssertion);

In this code fragment, a KeyedReference object is constructed, which refers to the uddi-org:relationships Categorization and a valid value like “peer-peer”, “parent-child”, or “identity”in the uddi-org:relationships Categorization.

Next, a PublisherAssertion structure that has the Business Keys (“BkA” and BkB”) of the businesses between which the relationship is being asserted (Company A and Company B) is constructed.

Finally, a call to add_publisherAssertions() is made, which asserts the relationship between the fromKey (“BkA” or Company A) and the toKey (“BkB” or Company B).

This means that Company A has declared Company B as a partner but not vice-versa. Hence, the same program should be executed by swapping the keys and using Company B’s “publisher” (login) account in UDDI.

This can be a useful feature to a client program, which may want to extend its trust with a known company to that company’s partner. A client searching for a digital-printing service can search for HP and its partner, and be assured that the vendors are reliable and offer a service qualified by HP. This find can be done using the find_relatedBusinesses() call. The trust can be further established by having the service classified (using taxonomies) as an “HP Certified Provider”. Note, PublisherAssertion only establishes a relationship among Companies and is not an explicit mechanism to express trust for the services offered.

Service Projection

This feature allows sharing of services across Companies. Usually, companies having a relationship share services amongst themselves. This then allows clients to find related services that are developed by partnering companies. One benefit for the service publishers is that related services have a better chance of obtaining hits than standalone services. This mechanism can also enable outsourcing of services done by a Company (Business Entity).

This ability to share services across companies is referred to as service projection. This is accomplished simply by saving the Business Entity again with the shared service information. Now, the shared service would appear as a service listing of both the publishing Organizations.

Listing 2 contains the XML message fragment that achieves service projection.

Listing 2: Message fragment for service projection.

<businessEntity businessKey="uuid_1">     <businessServices>         <!-- native business service -->         <businessService serviceKey="uuid_a" businessKey="uuid_1">             ...         </businessService>         <!-- business service projected from business entity with uuid uuid_2 -->         <businessService serviceKey="uuid_b" businessKey="uuid_2">             ...         </businessService>     <businessServices> <businessEntity>

In this example, a business with “uuid_2” is being shared between Company A and Company B. Company A has the businessKey “uuid_1” and Company B has businessKey “uuid_2”.

Contact Information

The contact information used in storing a Business Entity structure contains an address structure, which in turn contains any number of AddressLine elements. In UDDI V2, this feature has been enhanced to hold a reference to a Taxonomy, or TModel data structure. The TModel structure is meant to represent taxonomies also ( namespace usage) apart from using them as service type . In this case, it offers a structure to the addressline by adorning it with a keyName-keyValue pair. This way, one can differentiate between various elements in the address (for example, whether it is a Street Name or City Name).

By using a checked Taxonomy, it can also be insured (with the help of validation services) that a publisher is using a known value in a given category, i.e., it can ensure a known ZIP code location refers to the city used.

Listing 3 contains a Message fragment that defines contact information using a taxonomy.

Listing 3: Message fragment for defining contact information via a Taxonomy.

<address useType="Development Office" tModelKey="uuid:A548">   // The TModel Key refers to a Postal Code Taxonomy.<addressLine keyName="Street" keyValue="1">Cunningham Road</addressLine><addressLine keyName="Street number" keyValue="2">29</addressLine><addressLine keyName="City " keyValue="3">Bangalore</addressLine>...<addressLine keyName="Country" keyValue="7">India</addressLine></address>

Multi-language Support

The key internationalization feature of UDDI Version 2 is its ability to support names and descriptions in various languages. For example, a restaurant service could be stored in multiple languages, such as “Restaurante” in Spanish, “Ristorante” in Italian, or “Gaststatte” in German. Of course, this allows local users to search in their native language. This feature becomes very important in the global Internet economy, where posting an advertisement in multiple languages may translate into more usage of that service.

Multilanguage support applies to all the UDDI data structures. This means that all descriptive information, such as business information and service descriptions, can be written in native languages.

As part of its new multi-language features, UDDI V2 now also ensures that only one name/description can be specified in a given language.

Validation of Categorization Values

UDDI V2 adds support for validating referred Taxonomy values. These values are used for categorizing and identifying Businesses and Services. Categorization and identification information is passed in the KeyedReference object, which is usually contained in CategoryBag or IdentifierBag structure.

The validate_values Web service is hosted by Taxonomy providers and is used to validate business and service categorization values. The validate_value Web service ensures that while using standard or user-defined checked taxonomies, only valid category values are referenced. The UDDI server uses this service internally to do the validation. For example, in UNSPSC categorization, if a publisher declares the mobile telephones category and does not specify the correct category number, as 43171512, then the validate_values service would indicate an error.

UDDI4J offers an API, also called validate_values, which can be used by tool providers or other applications to accomplish additional validation at the client side. This is useful for performing extra checks in the application by talking directly to a Taxonomy Provider’s service. This validation can be carried out for any of the Business Entity, Business Service, or TModel structures.

Listing 4 shows a UDDI4J client-side message sent for validation.

Listing 4: XML message sent for client-side validation.

<validate_values generic="2.0" >    <businessEntity businessKey="20B649E0-EAE7-11D5-B3C2-000629DC0A2B"                   operator="www.ibm.com/services/uddi" authorizedName="1000003C44">  <discoveryURLs>  <discoveryURL useType="businessEntity">https://www.ibm.com/services/uddi/v2beta/uddiget?businessKey=20B649E0-EAE7-11D5-B3C2-000629DC0A2B</discoveryURL>     </discoveryURLs>  <name xml_lang="en">Mobile Telephones Inc. </name>   <businessServices>  <businessService serviceKey="BA10B620-EAE7-11D5-B3C2-000629DC0A2B" businessKey="20B649E0-EAE7-11D5-B3C2-000629DC0A2B">  <name xml_lang="en">SMS Service</name>     </businessService>   <categoryBag>   <keyedReference tModelKey="uuid:CD153257-086A-4237-B336-6BDCBDCC6634" keyName="Mobile Telephones" keyValue="4317152"/></categoryBag>    </businessServices>  </businessEntity>          </validate_values>

XML Message Logging

XML message logging allows a client application to store all received SOAP messages. In UDDI4J, message logging can be enabled and disabled at run time by setting the “org.uddi4j.logEnabled” Java property to true or false. This can be very useful debugging information for tool developers and UDDI4J API users. UDDI4J relies on the underlying SOAP transport’s logging features to log these messages. The messages can also be logged to a file in a given directory by specifying “hpsoap.logDirectory” and “hpsoap.logFileName” properties.

Listing 5 contains a code fragment that logs all SOAP messages to a temporary file.

Listing 5: Code fragment for logging SOAP messages.

// The user can set these properties at run timeSystem.setProperty ("hpsoap.logDirectory","/tmp");System.setProperty ("hpsoap.logFileName", "uddi4j.log");System.setProperty ("org.uddi4j.logEnabled","true"); // Logging enabled// now connect to the registry and save a business entity UDDIProxy uddiProxy = new UDDIProxy ();  proxy.save_business();System.setProperty ("org.uddi4j.logEnabled","false"); // Logging disabled.

Browsing the file “/tmp/uddi4j.log” after execution of this code fragment will show how the transport layer communicates with the registry.

Transport independence allows new SOAP Transports

Another key enhancement to UDDI4J is Transport independence. Through the use of the new UDDI4J Transport plug-in, any SOAP Transport provider can be added very easily. Of course, since the UDDI specification mandates SOAP messaging, only a SOAP-based transport can be plugged in. This feature allows any SOAP implementation, such as Apache SOAP, HP SOAP, or Apache Axis to be used for message transport. Currently, all three, Apache SOAP, HP SOAP, and Apache Axis are supported.

One use of this feature would take place during development of a Web services solution. Typically, the whole solution would use a single SOAP implementation, decided upon by various needs. Integration of UDDI4j code in such an application would be seamless, thanks to the possibility of plugging in the application desired SOAP transport.

Listing 6 shows the interface that SOAP providers implement.

Listing 6: Implementing the Transport interface.

public interface Transport {  public Element send(UDDIElement el, URL url) throws TransportException;  public Element send(Element el, URL url) throws TransportException ;  }

For example, HPSOAPTransport implements the two methods declared in listing 6. One can choose any transport implementation at run time by specifying the Java property “org.uddi4j.TransportClassName” to the implementation.

The user can set these properties at startup time as:

% java -Dorg.uddi4j.TransportClassName=org.uddi4j.transport.HPSOAPTransport-Dorg.uddi4j.logEnabled=true SomeUDDIClient

Summary

As Web services come online, the features of the UDDI registry are increasingly important to software developers. The new features described here are improving the programming and capabilities of Web services and their client applications. The practices of developers using and making best use of UDDI standards is rapidly evolving with every application that’s created.

(As such, developer-focused conferences such as Invent 2002, Las Vegas, May 28-31, 2002, become important for spreading best-practices. The conference is providing a number of sessions that can enhance development practices using UDDI and UDDI4J. For more information, see www.hp.com/go/invent2002.)

About the Author

Ravi Trivedi is a Technical Lead for the UDDI4j and UDDI teams at Middleware labs, E-Solutions Division, Hewlett Packard, Bangalore. He holds a masters degree in computer science from the Indian Institute of Science and is an expert group member for HP in JAXR (JSR 93). He is a committer for the UDDI4j project at www.uddi4j.org and has been involved in developing core Web services infrastructure such as UDDI and e-speak. He has been responsible for architecting and implementing some of the very first solutions in production using Web services.

Trivedi is also presenting at Invent 2002, the HP worldwide developer conference, May 28-31 in Las Vegas (www.hp.com/go/invent2002). His presentation is, “UDDI: Matchmaking for Web Services”, and he will be leading one of the Table Topics Lunch Sessions.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories