Understanding UDDI and JAXR
Pages: 1, 2

Are there any standard namespaces and/or classifications that are expected with any UDDI provider?

Taxonomy	tModelName
NAICS	ntis-gov:naics:1997
ISO 3166	iso-ch:3166:1999
UNSPSC	unspsc-org:unspsc:3-1
Other Taxonomy	uddi-org:general_keywords

Obviously, you need to get the unique keys of these tModels to reference them in your category bags.

The best source for understanding identity and category bags is the "UDDI data structures" document (PDF) from UDDI.org.

Can tModels be categorized as well?

So far we have seen how a business entity can make use of category bags using tModels. In addition, UDDI allows tModels themselves to be categorized. Why?

Let's draw a parallel to a hierarchical file system. Directories are used to categorize files, but directories can also be categorized under parent directories. Just like directories on a hard drive, tModels can be hierarchically organized.

Let's talk about a service called getUniversalTime(), which will return the current universal time anywhere in the world. Two competing companies might provide implementations of this service. A business service is tied to a company and not visible outside of that company. So you will end up with the following:

company1:getTime()
company1:getCurrentTime()

Both of these do the same. To indicate that they both implement a concrete conceptual service called getUniversalTime(), you can define a tModel as follows:

tModel
	name: Get Universal Time
	category: uddi-org:types, wsdl 
	  [implying that this a service as 
	  described by a WSDL document]

The above definition indicates that getUniversalTime() is a WSDL service that can be implemented by any organization.

Now that I have clarified the relationship between tModels and bags, I can show you the UML representation of a tModel.

Figure 4. A tModel explained using UML.

From the diagram, you can see that a tModel is basically a name and description. In addition it can contain a URL for further details. A tModel can also be identified using an identity bag and categorized by a category bag.

How many other types are there in the uddi-org:types category?

While categorizing a tModel, we have learned that some of the categories to which a tModel can belong to are pre-defined by the UDDI -- WSDL, SOAP service, etc. Here is a list of some of these pre-defined categories in the uddi-org:types namespace.

• tModel
• identifier (Unique identifier)
• namespace
• categorization
• specification
• xmlSpec
• soapSpec
• wsdlSpec
• protocol
• transport
• signatureComponent

So How Do You Go About Creating a Service in UDDI?

1. You start out defining a tModel for your service. This requires a name for your service and one of the above types of service. Of course, you can always create your own categories if you don't particularly care for the above choices.
2. You define a business service under your company, pointing to the tModel you have created above.
3. In the business service definition, you will need to specify a URL pointing to the actual WSDL document defining inputs/outputs to your service (assuming you are using a WSDL-compliant service).

Please refer to the excellent article by Andy Grove in the November, 2001 edition of Web Services Journal to see an example of this.

What are tModels Used For in UDDI?

tModels are used for the following purposes in UDDI:

• Identifying and categorizing business entities
• Identifying and categorizing business services
• Identifying and categorizing tModels
• Aliasing/binding business services to their abstract tModel definitions

Quick Reference to UDDI Terms

When you read literature about UDDI, it is very annoying to read terms that are fairly abstract. What the authors are trying to do is to draw parallels from the rest of the industry to the concepts in UDDI. However, it's very helpful to draw comparisons (however remote) to aid in our understanding of UDDI concepts.

Interfaces and Implementations

A service binding is considered a case where interfaces are tied to their implementations; a binding element specifies a tModelInstaceInfo and an instanceDetail together. The tModelInstanceInfo points to a tModel that actually defines a service name. instanceDetail is expected to provide some specific detail about this service.

Again, an example will help. For the "Get Universal Time" service, the detail is expected to provide the actual WSDL document that defines inputs and outputs. In addition, the accesspoint of a binding is expected to give you a physical machine and a port where this service is implemented. With this background, one can conclude the following:

• The tModel defined for a service is the interface allowing multiple companies to provide multiple implementations.
• Service binding is the implementation.

Namespaces

Namespaces appear all over the programming languages Java, C++, and XML. They may be called different things, but they all provide a context under which a name makes sense. In UDDI, a tModel represents "name." When you refer to this name as your category, you are essentially saying, "I belong to this name." In this sense, a tModel is representing a namespace.

Technical Fingerprints

When a service is registered as a tModel, one has the option of registering the protocol used to communicate with that service (such as WSDL, SOAP, etc.). Hence, a given tModel has a fingerprint of WSDL or a fingerprint of SOAP, depending on which specification it is using. Thus tModels are considered technical fingerprints, each adhering to a certain technical specification. If tModel can represent a "technical fingerprint," I could also argue that a tModel can also be said to represent a "protocol" as well.

Taxonomy

Taxonomy is synonymous with (and equivalent to) categorization, classification, and namespaces. Taxonomy provides a context under which identifiers such as numbers and names make sense. For example, US tax and ISBN numbers only makes sense when you know that they are US tax numbers or ISBNs. This sort of classification is sometimes called taxonomy.

White Pages

A listing of business entitites in the UDDI registry and the ability to search for companies based on their name.

Yellow Pages

These categorize business entities into their business categories and other sorts of applicable categories.

Green Pages (Technical Specifications)

These add the ability to understand a service definition and its access requirements with the help of a series of documents. serviceBindings and tModels help this cause.

Example XML for UDDI

I cannot possibly leave you without providing a decent reference where you can find example XML documents for the UDDI, to help you solidify your understanding of UDDI.

1. The first excellent reference is provided by Andy Grove in the November 2001 edition of the Web Services Journal under the title of "Understanding UDDI tModels and Taxonomies."
2. The second example is available online at http://dcb.sun.com/practices/webservices/overviews/overview_uddi.jsp.

JAXR

JAXR is a Java XML API for working with service registries. As we have discussed so far, all elements of a UDDI are described using XML documents. In a sense, if you are able to send an XML message containing a service definition, the UDDI registry should be able to register it or update it, as the case may be. Let us see how one can accomplish this if you don't have any tools:

1. Write the necessary XML for the service definition.
2. Understand SOAP headers so that you can send your XML file as a SOAP attachment to the UDDI registry.
3. Access SOAP client Java API to accomplish step 2.
4. Deal with SOAP programmatically.
5. Depending on the UDDI service (sorry to overload this term here), construct messages to accomplish that UDDI task.
6. For each message, go through steps 2 and 3.

If you have access to JAXM, you can do a better job of the same interaction. Because JAXM allows you to send XML messages without concern for SOAP headers and is strictly a message-oriented protocol, using this approach, the above sequence becomes:

1. Write the necessary XML for the service definition.
2. Use the JAXM API to send and receive XML messages. The SOAP stuff is hidden by JAXM.
3. Depending on the UDDI service, construct messages to accomplish that UDDI task. (For example, registering a service with a UDDI registry may contain the exchange of four messages.) This means you are still dealing with XML content.

Here comes JAXR to the rescue. Here, you only need to work with a high-level Java API that will internally generate all of the necessary messages and transact them through JAXM. The interesting point to note is that JAXM will be used to accomplish the task.

Let's look at the stated goals for JAXR:. (This list is directly taken from (JSR 93.)

1. Support for industry-standard XML registry functionality
2. Support for registration of member organizations and enterprises
3. Support for submission and storing of arbitrary registry content
4. Support for lifecycle management of XML and non-XML registry content
5. Support for user-defined associations between registry content
6. Support for user-defined multi-level classification of registry content along multiple user defined facets
7. Support for registry content querying based on defined classification schemes
8. Support for registry content querying based on complex ad hoc queries
9. Support for registry content querying based on keyword based search
10. Support for sharing of Web services
11. Support for sharing of business process between partners
12. Support for sharing of schemas between partners
13. Support for sharing of business documents between partners
14. Support for trading partner agreement assembly and negotiation
15. Support for schema assembly
16. Support for heterogeneous distributed registries
17. Support for enabling publish/subscribe XML Messaging between parties

JAXR is expected to support not only UDDI, but other similar registry standards (such as ebXML) as well.

References

• "Understanding UDDI tModels and Taxonomies" by Andy Grove, Web Services Journal, November 2001.
  If you have access to this magazine, this should be your first read to get an overall idea of UDDI and tModels. You can follow this up by reading the data model as documented in a PDF document at uddi.org. This reference is also a good source to get example XML for the UDDI.

• UDDI Data Structure Specification (PDF)
  This is the most comprehensive and valuable document for not only using UDDI, but understanding it. If you to read only one document on UDDI, read this one.

• UML of the UDDI
  Recently the DTD of an XML is being increasingly represented using UML. UML, being pictorial, can much more easily convey the structure of an XML document. With this trend, this document from XMLModelling.com can give you the minute details of UDDI, represented as XML. The only drawback might be that too much detail in a UML diagram could overwhelm the reader.

• UDDI at Microsoft
  One thing you can gain from the Microsoft Web site is the ability to understand the UDDI registry from the perspective of its GUI interface. For example, how can one register a service graphically, and how can one search for services on the Web?

  This document explains the basic UDDI structures and their programmatic and online manipulation. For the GUI of a UDDI, refer to this document.

• IBM'S UDDI Documents
  This URL explains the relationship between WSDL and UDDI.

• "Hangin' with the JAX Pack", a three-part series by Al Saganich at OnJava.com.
  This series is an excellent and lucid introduction to the JAXPACK API that includes JAXP, JAXB, JAXM, JAX-RPC, and JAXR.

Satya Komatineni is the CTO at Indent, Inc. and the author of Aspire, an open source web development RAD tool for J2EE/XML.

---

Return to ONJava.com.