jUDDI's extensiblity: Subscription Notification Handlers

The upcoming releases of jUDDI 3.1.5 has a number of new features and a lot of bug fixes. Literally, there's at least 100 new unit tests, many of which were initial failures over the previous version. Since the development of 3.1.5 and 3.2 are happening concurrently (3.2 = a shinny new user interface based on Bootstrap), I've used this as an opportunity to really exercise every possible component of the UDDI specification and cross reference stuff that may have been missed with earlier versions.

One of the things that was missed was the capability for Email based alerts when something changes in UDDI via the Subscription API. Pretty cool. I sat there and thought to myself, "wait a second, what if I had some really cool new message delivery method that I want to integrate into jUDDI?" 

After a few conversations with Kurt Stam, the jUDDI project lead, I was pleased to find out that this function was already implemented. It just wasn't well documented anywhere. So without further ado, I present a quick how to guide for adding your own protocol handlers to the Subscription API of jUDDI and some basic steps of how to set it up a testing scenario.

Make a new Java library projects in your IDE of choice.

Reference the juddi-core, and uddi-ws projects or JAR files.

Create a class of your own within the following package name:

org.apache.juddi.subscription.notify

The class name MUST follow this pattern:

PROTOCOLNotifier

Where PROTOCOL is the prefix of whatever URL you want users to be able to use. Here's an example using Apache Qpid.

Example URL: amqp://guest:guest@client1/development?brokerlist='tcp://localhost:5672'

Class Name: AMQPNotifier

The Notification class basically takes the protocol of the Access Point's value, splits it on the character ":" and then grabs the first token "amqp" and converts to upper case. Using this pattern you should be able to insert anything you want.

Our new shinny class, AMQPNotifier, must implement the interface org.apache.juddi.subscription.notify.Notifier.

From there, all you need to do is to add in the jars necessary for your transport mechanism and wire in your own code.

Deployment is simple. Add your PROTOCOLNotifier jar and its dependencies to the juddiv3.war/WEB-INF/lib folder.

Note: be careful and watch for conflicting jar file versions. In general, usually moving up a version is ok, but moving down may cause the services to fail unexpectedly.

Time to test. Create a Service with the BindingTemplate's Access Point's value equal to whatever you need.

Next, setup a subscription and reference the BindingTemplate key that represents your call back handler's end point. Finally,   change an item that is covered by the subscription's filter and monitor the log files. Hopefully, you won't see an unexpected errors.

The next article, we'll use Apache Qpid as an example, which using the AMQP transport protocol. In order to have a really useful subscription protocol handler, one would need to determine to best use it. AMQP publishers (which is what this example is wiring in) needs a number of settings and possibly credentials or key stores. One option is to bundle all the settings within jUDDI's configuration file (juddiv3.properties), make your own, or enable clients to configure the settings themselves through either a tModelInstance or perhaps through tModel KeyReferences. We're a bit off topic now, but I just wanted to bring up the fact that configuration management of additional protocol handlers (especially for pub/sub mechanisms) can be complex, so think about it and plan ahead.