Thursday, May 30, 2013

jUDDI v3.2 Preview

We are hard at work making jUDDI better and I figured we would announcement some new features that are planned for the next version. As always, you're welcome to submit your own requests, enhancements, features, or even report problems or patches that you've discovered over at jUDDI JIRA Issue Tracker. These features are tentatively scheduled for 3.2 and may change without notice.

  • End user interface (juddi-gui) - This web browser user interface has been blogged here a few times, but it has some great features that will hopefully aid adoption and just make things easier.
  • Administrative interface (part of juddiv3.war) - This will be a user interface for administrators to graphically configure jUDDI's many configuration options and to provide browser based access to the administrative functions provided by jUDDI's Web Service API (not the UDDI part).
  • Client and Browser side Digital Signature support- enough said
  • Additional validation for Subscription APIs
  • Support for importing WADL files into a UDDI structure
  • REST bindings for the Inquiry API
  • Productize the UDDI Technical Conformance Kit - provides a way to test UDDIv3 compliance of any registry
  • Client side support for HTTP based authentication
  • Configurable SSL stores
  • And possibly, a pluggable Access Control mechanism for RBAC, ABAC, GBAC, or whatever else you can dream up.
Until next time. 

Don't forget, usually at least one of the jUDDI team members is normally on IRC on Freenode #juddi. Feel free to sign in and drop line.

jUDDI v3.1.5 has been released!

The Apache jUDDI team is pleased to announce the release of jUDDI-3.1.5. Some
new features are validation, some long overdue performance fixes, WSDL2UDDI support, a shiny distro with examples, docs and javadoc and the ability to create wars for a few different platforms and configurations (OpenJPA vs Hibernate and CXF vs JBossWS). That, and lots and lots of bugfixes (see the release notes below). jUDDI-3.1.5 can be downloaded from:


the jUDDI team.

Full Release Notes:


  • [JUDDI-363] - Move hibernate and openjpa persistence files out of resources
  • [JUDDI-409] - problems in digital signature on entity
  • [JUDDI-496] - The tModel is not loaded in the SubscriptionNotifier
  • [JUDDI-545] - combineCategoryBags findQualifier not performing correctly when used in find_business call
  • [JUDDI-548] - java7 compatibility
  • [JUDDI-553] - TModelDetail not deleted when TModel is deleted
  • [JUDDI-557] - Update all POMs on example
  • [JUDDI-560] - Issues from findbugs
  • [JUDDI-561] - Transaction rollback when PersonName Lang is greater than 5 characters
  • [JUDDI-562] - CI build integration failures
  • [JUDDI-565] - Binding template validation rules are incorrect
  • [JUDDI-566] - Using service/binding/hostingDirector causes a NPE
  • [JUDDI-568] - If publication of the root publisher fails, juddi goes into an infinite loop
  • [JUDDI-569] - Performance Issue fetching service list
  • [JUDDI-571] - find_services lang issue
  • [JUDDI-572] - Sending a business key for getServiceDetail causing a class cast exception
  • [JUDDI-573] - Performance Issue fetching business
  • [JUDDI-574] - findTmodel search results does not return the Lang element
  • [JUDDI-576] - Fix broken links and old wiki site
  • [JUDDI-582] - KeyedReferenceGroup/tModelKey is either not saved or not retrieved
  • [JUDDI-589] - find qualifier signaturePresent doesn't appear to follow the spec
  • [JUDDI-591] - Add support for email alerts for Subscription API
  • [JUDDI-592] - failing unit test on latest trunk
  • [JUDDI-612] - Build 'clean' target does not remove the content in juddi-core-openjpa\src\main


  • [JUDDI-89] - JDBC Datastore performance improvements
  • [JUDDI-554] - Link to wiki from participation page goes to a different url
  • [JUDDI-555] - Add additional examples for working with UDDI
  • [JUDDI-559] - Authentication Tokens do not expire
  • [JUDDI-575] - Referential Integrity Check
  • [JUDDI-588] - Default Juddi business has services with endpoints starting with ${juddi.server.baseurl}/juddiv3
  • [JUDDI-601] - Add more constant fields and documentation to juddi-client
  • [JUDDI-611] - UDDIClerkManager renamed to UDDIClient

New Feature

  • [JUDDI-563] - Package a Jboss 5/6 compatible war
  • [JUDDI-580] - Validation Framework Enhancements
  • [JUDDI-584] - provide a working example of configuring juddi with postgres
  • [JUDDI-585] - Add a generated Release class to the juddi-client to provide version information at runtime


  • [JUDDI-480] - Add juddiv3.war distribution for other appservers
  • [JUDDI-514] - Upgrade support WSDL2UDDI registration
  • [JUDDI-540] - Revisit Distro
  • [JUDDI-541] - Small changes to the build
  • [JUDDI-586] - Upgrade OpenJPA to 2.x

jUDDI's extensiblity: Authentication Modules

I've been diving through the jUDDI code and ran across another extensibility point: Authentication modules. Authentication modules are used when the UDDI's AuthToken is utilized on the Security web service. It's function is to point to some kind of user credential store to validate users. Let's first go over what's out of the box.

  • org.apache.juddi.v3.auth.JUDDIAuthenticator - this really performs no credential checks. Just give it whatever you want and you'll get a token.
  • org.apache.juddi.v3.auth.XMLDocAuthenticator - this validates users against a clear text xml file, normally called "juddi-users.xml"
  • org.apache.juddi.v3.auth.CryptedXMLDocAuthenticator - this validates users against an encrypted xml file called "juddi-users-encrypted.xml". This uses the Cipher PBEWithMD5AndDES.  I don't believe there's currently any command line utility to encrypt a password, but there is an open ticket for it.
  • org.apache.juddi.v3.auth.LdapSimpleAuthenticator - this validates credentials against an LDAP using "simple" authentication (which can send credentials in the clear). It basically tries to connect to LDAP as the user that's attempting to use jUDDI. Most LDAP's require the user to authentication as a distinguished name, such as CN=Bob Smith, OU=Users,, etc. This is a bit of a  burden on the user.
All of these classes implement the interface org.apache.juddi.v3.auth.Authenticator. So, if you wanted something a bit more functional than what's provided out of the box. you'll need to implement your own Authenticator.  To wire it in, edit the file, specifying your class name as the value to the property "juddi.authenticator" and then add the class or jar containing your implementation to juddiv3.war/WEB-INF/classes or judiv3.war/WEB-INF/lib respectively. 

Note: there's a few open tickets in jUDDI's JIRA Issue tracker that detail some enhancements to Authenticators. 

As always, we appreciate community contributions!

Sunday, May 19, 2013

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:

The class name MUST follow this pattern:
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 (, 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.