Saturday, January 4, 2014

Using Category Bags, Identifier Bags, and tModel Instance Infos in UDDI (oh my!)

Seemingly since UDDI was created, there has been confusion as to the differences and usage scenarios for tModels, Category bags, Identifier bags and these wacky things called Key References. So to save everyone, including myself, some time, here's a explanation of these topics, when to use them and when to not. A quick reference guide if you will.

The Technical Model - This thing basically defines any data you want to attach to something in UDDI. More formally, a tModel
Describes a "technical model" representing a reusable concept, such as a Web service type, a protocol used by Web services, or a category system (ref) 
If you were to translate this into programming terms, the closest thing is an Interface. If you're using jUDDI v3.2 comes with almost 100 predefined tModels. Every tModel needs a few things:
  1. A non empty, non null Name value
  2. A tModel key, (however some registries will generate one for you, usually a nasty GUID)
  3. A Category bag Key Reference referencing either "", "uddi-org:types:checked" or "uddi-org:types:unchecked"
Checked vs Unchecked tModels and the little known "ValidatedBy" (source)

  • A "Checked" tModel is basically a tModel that whose value conforms to some rules, the most basic is that it the tModel must be defined.
  • An "Unchecked" tModel is a tModel whose value could be anything.
  • The Validated By (tModel/categoryBag/KeyedReference/tModelkey="") is a special case in which a UDDI server can call a UDDI Value Set Validation endpoint in order to validate that you usage of this tModel is valid. The value of the KeyedReference is actually a bindingTemplate key.

The Category Bag - This element is basically used to categorize UDDI entities. Think of it as a classification or taxonomy mechanism. The most commonly used one is "". Here's an example of how it's used on a UDDI Business Service element in a Category Bag
Business Category Bag - The only example provided in the specification for a Business's Category Bag (aside from a UDDI node) is Geographic location.
Business: <keyedReference
    keyName="California, USA"
    keyValue="US-CA" />

Service Category Bags - contains a list of business categories that each describes a specific business aspect of the businessService (e.g. industry, product category or geographic region) and is valid in its own category system. source

The UDDI spec doesn't have any explicit examples for service category bags,

Identifier Bag - Holds keyReferences (to keys) that uniquely identify the business (instance) through the specified identification system (D-U-N-S, Tax ID, etc.) which is external to the repository.

In the words of Peer Reynders
identifierBag contains references to keys that identify the company (BusinessEntity). It answers the question, "Who are you"?
categoryBag contains references to keys that identify the type of business the company is in. It answers the question, "What do you do"?

tModel Instance Info - This is (or at least should be) the most used data element in a UDDI registry. It's part of the Binding Template structure. I'll give you the short version:  this is used to define data specific to the end point of the service that's described, such as authentication types, transport mechanism, protocols, SOAP vs REST, or even Quality of Service metrics. Every binding template should have at least a protocol and a transport mechanism defined, but it's not required.

Here's an example from jUDDI's default install data (as of v3.2)
<bindingTemplate bindingKey="" serviceKey="">
  <description>jUDDI Publisher Service API V3</description>
  <accessPoint useType="wsdlDeployment">http://localhost/.../publisher?wsdl</accessPoint>
   <tModelInstanceInfo tModelKey="" />
   <tModelInstanceInfo tModelKey="" />
   <keyedReference keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" tModelKey=""/>

Important: Most UDDI implementations should enforce referential integrity, meaning that before you can use a reference to a tModel key, the tModel itself must be first created if it doesn't exist already.

So hopefully this clear things up a bit. This is just one guys interpretation of the UDDI v3 spec, but is open to interpretations. Feel free to post a comment if you disagree or have something to add.

No comments:

Post a Comment