Understanding UDDI and JAXRby Satya Komatineni
Over the past few years, much of the Java developer community has embraced the various pieces of J2EE, and in the process has given server-side programming the high status formerly enjoyed by client-side programming tools (GUI frameworks that include Swing). Now, the developer community is being challenged once more to weigh SOAP services to see if they can raise the bar for server-side programming.
The proponents of SOAP services believe:
- An enterprise application server is a collection of services (or transactions).
- Available services should be conveniently listed for browsing, searching, and access.
- Designing an application server as a collection of services will encourage developers to use better design practices, just as they are now adhering more closely to component-based development practices.
- These units of transactions can be relocated, load-balanced, replaced, security-applied, etc.
The skeptics, on the other hand, see SOAP services as another attempt at bringing CORBA and COM to a much broader audience. They note that SOAP seems to require a lot of work for a simple call to an object, and argue that the benefits of UDDI are overstated as far as a business differentiation/sales tool.
So which is it? While some developers have already picked sides, those with an open mind will want to understand some of the core technologies before deciding whether or not to embrace SOAP services.
In this effort, I recently spent a good part of a week pouring through magazines and online materials looking for comprehensive information for the role and necessity of UDDI/WSDL for Services. I hope that by writing this article, I can save you a ton of time going through a similar exercise. I would not have written this article if UDDI were not interestingly abstract and complex. But it is both, so on with my findings.
The annotated references at the end of the article will work as references for the basic material. I intend to focus here on the tricky parts of the standard while only covering the basics for a comprehensive read. The article concludes with a discussion of Java APIs for XML Registries and Messaging (JAXR and JAXM, respectively.)
Let us start with the acronym. UDDI stands for Universal Description, Discovery and Integration. UDDI's intent is to function as a registry, just like the Yellow Pages is a registry for businesses in a given metropolitan area. Like in the Yellow Pages, in a UDDI registry, companies will register themselves or their services under different categories. By browsing a UDDI registry, a developer should be able to locate a service and a company, and find out how to invoke the service.
Beside the Yellow Pages, UDDI also refers to White Pages and Green Pages. White Pages are a listing of business entities. Green Pages (here the phone book metaphor breaks down, unless there are some green-colored manuals hidden away at the phone company) basically represent technical documents necessary to invoke a given service.
UDDI definitions are general enough to accomodate services of different kinds, which are not necessarily SOAP services. A UDDI definition could represent a faxing service or a telephone service. UDDI, being a registry, is typically implemented using a database of sorts. In this database, there is a data model allowing publishing and querying of these pieces of information.
UDDI Data Model
The UDDI data model contains the following main elements:
businessEntity: Represents a physical company.
businessService: Represents a service offered by a company.
bindingTemplate: Instructions on how to invoke a service.
tModel>: Good luck understanding this! (Just kidding, I will explain this later.)
Examples of UDDI XML documents are available here.
For an in-depth understanding of the data model, let's look at a UML representation of these data elements. Figure 1 shows the relationship between the four main elements.
From this diagram, you can infer that a business entity (a company) has a descriptive URL that can tell us more about the company, and a list of contacts at that company. In addition, a business entity has a list of business services. There can be multiple ways of invoking each business service. Each invocation is described by a binding template. Because a binding template describes in detail how to access a service, it can benefit from a series of documentation elements that describe how one can access the service. This connection between a binding template and its necessary documentation is accomplished through what is called a
tModel. In the diagram, this relationship is simplistically represented for now as a
bindingTemplate having a collection of
tModels. This relationship will be further explored in the coming pages. Unfortunately, before I can explain how
tModel>s relate to binding templates, we have to travel the detour of understanding what
What is a TModel?
tModel as an independent table in a database with the following columns: name, description, URL (that can tell you more about the name and description), unique key (to identify the name). In essence, a
tModel is something that has a "name" and "description." Of what use is such minimal information? And isn't that a waste, giving a database table to represent this minimal concept? Let us take an example and explore.
Here are a couple of entries in a fictitious
|1||Represents a fully qualified name of a java class||http://www.javasoft.com|
|2||Represents a JNDI name. Look at the J2EE specification||http://www.javasoft.com|
A few things can be noted by correlating a
tModel to a database table. First of all, a
tModel is an independent table, meaning it can exist by itself. Secondly, a
tModel is a lookup table providing a translation between a key and a representation of what that key is. In this sense, a
tModel is a reference table, like a dictionary. In some databases such a table is also known as a codeset.
In all cases, the above definitions will allow me to say:
This implies that the string
com.mycompany.HelloWorld is a fully qualified Java class.
This implies that the string
com.mycompany.HelloWorldHome is a JNDI name.
So in a sense, the unique keys of
tModels are representing a concept, such as a "namespace." To illustrate this further, consider the following numbers:
904-555-1212 904-555-1213 1-56592-391-x
How could you tell what these numbers are? You need a context, or a namespace, to establish that 904-555-1212 is a telephone number, 904-555-1213 is a fax number, and 1-56592-391-x is an ISBN number.
So in your
tModel database, you will define three entries: one for a telephone number, one for a fax number, and one for an ISBN number.
Let's say that your company "mycompany" has declared a helpline at number "1-800-my-helpline" and you want to register this with the UDDI. Then your data models will be:
company name: mycompany Service name: helpline tModel: key=11 (representing telephoneline), name=telephone, description=telephone stuff, url: some at&t url binding: accesspoint: 1-800-my-helpline tModelInstanceInfo: 11
With this basic understanding of the
tModel, let us investigate, using a UML diagram, the relationship between a binding template and
tModels. As I have suggested earlier, this should lead us to a direct understanding of how a binding template achieves the "how to invoke a service" requirement of UDDI.
In Figure 2, I have elaborated the relationship between a binding template and
tModels. From the diagram, you can see that a binding template can point to a technical specification identified by a
tModel. This technical specification has two parts:
- The type of the specification (e.g., email, fax, WSDL, SOAP service, etc.)
- Documents identifying inputs and outputs (in the case of a SOAP service, these documents could be XML input/output message formats)
Now that we understand
tModels in some detail, let us move to the next level of complexity in UDDI, namely identity bags and category bags.
Understanding Identity and Category Bags
If conceptual understanding of the
tModels is the first obstacle in understanding UDDI, understanding the identity and category bags is the second obstacle. These bags are best described with an example.
Your company has a tax ID number for doing business in the U.S. If you were to operate in another country as well (say, Mexico), you would need to have a Mexican tax ID number in addition to your U.S. number. To capture this information about your company in the UDDI registry, you would do something like this:
Company name: mycompany Identifiers: US tax number: 111111 Mexico tax number: 2223344 Some other number: 333333 ...Other xml stuff <identifierBag> <keyedReference tModelKey="US-tax-code" keyName="taxnumber" keyValue="1111111"> <keyedReference tModelKey="Mexico-tax-code" keyName="taxnumber" keyValue="2223344"> <keyedReference tModelKey="other-stuff" keyName="taxnumber" keyValue="333333"> </identifiedBag> ... Other xml
See how the
tModels are being used as namespaces (
mexico-tax-code, etc.)? To further solidify your understanding of the identifier bags, Figure 3 shows a UML diagram.
From Figure 3, one can see that an identifier bag is a collection of key/value pairs within a given context. The context is essentially the namespace that can uniquely resolve the name/value pairs. This namespace is identified by a
tModel. The same is true with category bags. The only difference is that the namespace identified by the
tModel in a category bag points to a predefined category (or a "taxonomy").
Let's say I want to categorize my company as belonging to the "restaurants" category and geographically located in "Jacksonville."
Company name: mycompany Applicable Categories: Type of business classification: restaurant city classification: Jacksonville <categoryBag> <keyedReference tModelKey="BusinessTypeClassification" keyName="restaurant" keyValue=".."> <keyedReference tModelKey="CityClassification" keyName="JAX" keyValue=".."> </categoryBag>
So far we have seen how
tModels have been used for the purposes of Identifier and Category bags.
tModels have essentially served as namespaces.
Pages: 1, 2