Friday, December 5, 2014

jUDDI v3.2.1 Released

jUDDI Version 3.2.1 Released

Today we released jUDDI version 3.2.1! This version contains a number of bug fixes and offer's enhanced functionality in the user interface for interacting with tModels. This release resolved a incredible 65 jiras, as you can see in the Release Notes.

What new in version 3.2.1?

  • Numerous enhancements to juddi-gui (web user interface) including several security fixes, more internationalization support, 
  • More automated unit tests and refactoring
  • Database DDL files are now auto generated with each build
  • Fixes for the newer versions of Hibernate
  • We're now using GIT for cvs
You can grab the release here:

The website will be updated as soon as the ASF Infrastructure team get the CMS repo up and running again.

Thursday, February 6, 2014

UDDI: Universal Description, Discovery, and Integration

Check out the free chapter on UDDI of the O'Reilly 'Java WebService' book by Tyler Jewell

It gives a very nice overview on how to use UDDI in general as well as some good detail on how to use taxonomies.



jUDDI 3.2.0 Released - Now with a full GUI!

jUDDI Version 3.2.0 Released

Today we released jUDDI version 3.2.0! This version marks the first jUDDI release with a full featured console. Suddenly jUDDI has become much easier to use. This release resolved a incredible 206(!) jiras, as you can see in the Release Notes.

What new in version 3.2?

  • A new end user interface based on Twitter’s Bootstrap
  • A new administrative user interface based on Twitter’s Bootstrap with in browser monitoring
  • A client side subscription callback API
  • Client distribution package
  • Many more examples
  • WADL to UDDI mappings
  • All credentials are now encryptable with command line tools
  • Removal of the portlet services
  • Deployment templates for JBoss EAP 6+
  • Client side digital signature support
  • REST style interface for Inquiry API
  • Added many more tModels to the base install
  • More documentation

Admin and jUDDI GUI Web based consoles

This is the first release that features a the juddi-gui. A screen capture of the juddi-gui Service Editor is shown in Figure 1. A demo cloud instance is running at if you want to try it out.

Figure 1. Screen capture of the juddi-gui Service Editor.
Figure 2 shows a the admin console as part of the juddiv3 server. The juddi-gui runs in the same servlet container but it can run remotely as well since it connects to the server over HTTP/S only.
Figure 2. High Level Application Diagram showing the jUDDI server as well as the admin console and juddi-gui.
Finally if we zoom into the juddiv3 application itself, see Figure 3, it shows the various deployment options jUDDI gives you in terms of container and database choice, JPA and JAXWS providers and connection protocols.

Figure 3. jUDDI architecture showing the plugable components.

Getting Started:

Either try out the demo cloud instance, simply download the distribution from, and start the preconfigured tomcat with the UDDI server and GUI; all you have to do is unzip, start tomcat and in your browser navigate to http://localhost:8080/juddiv3.
  • Then follow the Getting Started Chapter of the jUDDI Guide.
  • Scripted support for deployment to other application servers such as JBoss EAP.
  • Detailed documentation guides and javadoc.
  • Code examples on how to interact with the UDDI server.




Apache jUDDI releases v3.2!

The Apache Software Foundation jUDDI project has just released version 3.2

This release covers over 200 tickets, has a brand new Bootstrap based user interface and is just simply light years of the previous one in terms of features, usability, test cases and documentation. Enjoy!

More details to be posted soon!

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-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.