SyntaxHighlighter

Saturday, January 4, 2014

Discovering the Discovery Service?

One of the problems that always bothered me with UDDI is that you need to know a number of things in order to find something. Specifically, you need

  1. The location of the UDDI services, at least the Inquiry
  2. Information about what you're looking for
  3. Optionally, credentials
So we need to know where UDDI is before we can look up the where the services are that we want to use? This is almost a catch 22 scenario. Consider a scenario where you have 1000s of web serivce clients, all depending on the UDDI server for figuring out how to route requests. What is the UDDI server location changes? Now you have a few angry IT guys to deal with.

Falling in line with most IT solutions of making things easier and reducing complexity, how do we remove the extra step of locating UDDI? There's a few options and they are all multicast based solutions.
The jUDDI team has had a number of discussions about this and have opened a ticket to enable one of these capabilities in the future, currently slated for version 3.3.

If you happen to have an opinion on the subject, please feel free to share.

UDDI as a registry for REST services?

Yes, you read that correctly! Believe it or not, UDDI actually defines a REST endpoint in the spec!

Strangely, we don't really know if anyone else has implemented it not. It's possible that HP/Systinet has it, but Microsoft definitely doesn't! So the really cool neato guys on the jUDDI team thought, why not? Since we're using Apache CXF, it turned out to be low hanging fruit using Jettison.

Starting with jUDDI 3.2, here's all the things you can do with the REST endpoint (pist, there's a WADL too!). Wait, did I say REST? well it's really more of just an HTTP GET endpoint, POST/making changes isn't supported yet.

  1. Get the details on any UDDI element (per the spec) in XML
  2. Get the details on any UDDI element in JSON
  3. Get the Operational Info on anything in JSON and XML (this is basically the owning username and some time stamps)
  4. Get all of the execution endpoints of a given service key (this even resolves wsdlDeployments, Hosting directors and more)
There's a few caveats to this, namely that authentication isn't currently supported, so if your turn on the flag to require authentication for the Inquiry service, then this isn't going to work.

Here's a link to the source code for those so inclined.

In the future, we hope to include simplified parts of the find(entity) functions. Frankly, the UDDI spec for searching is insanely complex, thus it will need to be simplified for a URL query string.

In addition, we've added a few things to help make it easier for people to use UDDI to advertise REST services, such as a WADL interpreter that will take all of your well formed and documented WADL files and convert them into UDDI's data structures (pist there's a WSDL interpreter too!). We've also added REST tModels to the default install data.

So the future is looking up for both UDDI and jUDDI.

Edit: I forgot to mention that you can automate the un/registration of both REST and SOAP endpoints in UDDI using the juddi-client jars/dlls? This process is simple and there's a few examples such as this and this.

Edit: It looks like OpenUDDI has the REST endpoint, bravo!

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:uddi.org:categorization:types", "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="uddi:uddi.org:categorization:validatedby") 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 "uddi:uddi.org:categorization:types". Here's an example of how it's used on a UDDI Business Service element in a Category Bag
tModelKey="uddi:uddi.org:categorization:types"
keyName="uddi-org:types:wsdl"
keyValue="wsdlDeployment" 
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
    tModelKey="uddi:uddi.org:ubr:categorization:iso3166"
    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="uddi:juddi.apache.org:servicebindings-publisher-ws" serviceKey="uddi:juddi.apache.org:services-publisher">
  <description>jUDDI Publisher Service API V3</description>
  <accessPoint useType="wsdlDeployment">http://localhost/.../publisher?wsdl</accessPoint>
  <tModelInstanceDetails>
   <tModelInstanceInfo tModelKey="uddi:uddi.org:protocol:soap" />
   <tModelInstanceInfo tModelKey="uddi:uddi.org:transport:http" />
  </tModelInstanceDetails>
  <categoryBag>
   <keyedReference keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" tModelKey="uddi:uddi.org:categorization:types"/>
   </categoryBag>
</bindingTemplate>


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.