October 21, 2016
Hot Topics:

Key Features of UDDI4J Version 2

  • April 9, 2002
  • By Ravi Trivedi
  • Send Email »
  • More Articles »
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" xmlns="urn:uddi-org:api_v2">    <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


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.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel