UDDI in the OpenShift cloud

We just deployed both the jUDDI server and the jUDDI-GUI in to the OpenShift cloud. There is no guarantee that data you upload there will stay around but you are free to give it a spin. Cheers, --Kurt

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:

http://juddi.apache.org/releases.html

Cheers,

the jUDDI team.



Full Release Notes:

Bug

• [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

Improvement

• [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

Task

• [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, DC=mydomain.com, 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 juddiv3.properties 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!

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.

jUDDI Dev HowTo: Add a new configuration element

As a noob jUDDI developer, I've found there's a few basic things that haven't been documented that may make someone else's life a bit easier. Without further ado, here's a simple how-to guide for adding new configuration elements to jUDDI (server side)

1. Add your property to the actual property files
   I simply did a file search for juddiv3.properties and only modified
   the ones that were under version control. As of 3.1.4, the require
   files are at
   juddi-core-openjpa/src/test/resources
   juddiv3-war/src/main/webapp/WEB-INF/classes
   juddiv3-samples/src/main/webapp/WEB-INF/classes
   
   Simply add a new line towards the bottom with whatever you need.
2. Within the juddi-core project, locate the class org.apache.juddi.config.Property. Despite its name, it's actually a constants interface class. Add your own custom property name here. Here's an example of one I just added for enforcing the registration of tModels before using them as well as a few other things.
   

   public final static String JUDDI_ENFORCE_REFERENTIAL_INTEGRITY = "juddi.validation.enforceReferentialIntegrity";

3. jUDDI uses the Apache Commons Configuration API. Example:
   

   AppConfig.getConfiguration().getBoolean(Property.JUDDI_ENFORCE_REFERENTIAL_INTEGRITY">);

   Be sure to change it to the correct data type for whatever you're using.
4. You're now ready to use it somewhere. In the following example, we are defaulting to a value of false.

               boolean checkRef = false;
               try {
                   checkRef = AppConfig.getConfiguration().getBoolean(Property.JUDDI_ENFORCE_REFERENTIAL_INTEGRITY);
               } catch (ConfigurationException ex) {
                   log.warn("Error caught reading " + Property.JUDDI_ENFORCE_REFERENTIAL_INTEGRITY + " from config file", ex);
               }
   

   Now you're ready to go test it!
   
   
5. Finally, make new Issue in the issue tracker. Then make a SVN patch, attach it and eventually a commiter will either comment back on it or add it to the baseline,

UDDI HowTo: Create tModels with a custom key

When I first started working with UDDI registries, I came across an interesting use case, attaching data to a binding template. For those in the know, binding templates are UDDI's equivalent to a a specific company's service offering, such as a car mechanic's. The additional data might be performance statistics for the that mechanic, such as "I replace starters within 15 minutes".


Moving on, I had a registered service and wanted to add some data to it. This add on data is expressed as tModels in UDDI. tModels are nothing more than a key, name, value tuple. The catch with UDDI is that all tModel keys need to be registered before they can be used. I was discovered is that registering a new tModel isn't as straight forward as I thought it would be. The rest of the post is a how-to guide for creating new tModels in UDDI by first creating a tModel Generator. A tModel Generator is also known as a tModel Key Partition in jUDDI.


From first hand experience, this process is identical for most of the UDDI services that exist, both commercial and open source.
1) Identify a domain that the tModels are related to. Such as a www.mycompany.com. This will become a "partition" in jUDDI. If you reference the UDDI spec, this is actually called a "keyGenerator"

2) Using the Publishing web service to call "save_tModel" with at minimum the following items defined.
tModelKey = uddi:www.mycompany.org:keyGenerator (Note the prefix and suffix are required)

1. Name, such as My Company's Keymodel generator
2. A KeyedReference tModel in the categoryBag with the following defined:  ModelKey="uddi:uddi.org:categorization:types"
3. keyName="uddi-org:keyGenerator" keyValue="keyGenerator"
4. An authentication token ( see the Security API)

            SaveTModel st = new SaveTModel();
            st.setAuthInfo(key);
            TModel tm = new TModel();
            tm.setName(new Name());
            tm.getName().setValue("My Company's Keymodel generator");
            tm.getName().setLang("en");
            tm.setCategoryBag(new CategoryBag());
            KeyedReference kr = new KeyedReference();
            kr.setTModelKey("uddi:uddi.org:categorization:types");
            kr.setKeyName("uddi-org:keyGenerator");
            kr.setKeyValue("keyGenerator");
            tm.getCategoryBag().getKeyedReference().add(kr);
            tm.setTModelKey("uddi:www.mycoolcompany.com:keygenerator");
            st.getTModel().add(tm);
            

3) Send in the request.

            TModelDetail saveTModel = publish.saveTModel(st);
            System.out.println("Creation of Partition Success!");

4) You may now create tModels with keys start with "uddi:www.mycompany.com:" such as uddi:www.mycompany.com:somecustomkey

            tm = new TModel();
            tm.setName(new Name());
            tm.getName().setValue("My Company's Department");
            tm.getName().setLang("en");
            tm.setTModelKey("uddi:www.mycoolcompany.com:department");
            st.getTModel().add(tm);
            saveTModel = publish.saveTModel(st);
            System.out.println("Creation of tModel Department Success!");
            
            tm = new TModel();
            tm.setName(new Name());
            tm.getName().setValue("My Company's Authentication Method");
            tm.getName().setLang("en");
            tm.setTModelKey("uddi:www.mycoolcompany.com:authmode");
            st.getTModel().add(tm);
            saveTModel = publish.saveTModel(st);
            System.out.println("Creation of tModel Auth Mode Success!");

Note: tModel keys, at least in jUDDI, converted to all lower case. Some implementations support mixed case, but to be safe, always use lower case.

New jUDDI Console is under construction

We have a new contributor, Alex O'Ree, working on a proper console for jUDDI. Here is a quick snapshot where he is at right now:

Cheers,

--Kurt

Setting up jUDDI in Eclipse

 I recently helped a developer with setting up eclipse, which I thought would be helpful for other people too.

1. Start with a fresh eclipse Juno:
http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr1

2. Launch eclipse and go to the market place to install:

m2e:

subeclipse:

gwt:

but do not select tools for andriod:



JBoss tools:


Open the SVN Repository window and add the juddi repository





if you get the following error



then select the pure Java SVNKit




and continue to check out the trunk



When the checkout completes import all modules as projects using Check out as an existing maven projects










I got the following issues:



and opted to 'resolve later' and was able to continue. After it created my projects I ended up with errors in some projects. To fix them I needed to stop validation on dtd and wdsl going into the preferences



Also in some pom I got lifecycle errors which when hovering over the '' I could set to exclude in eclipse.




3. Now on your file system; go into the juddi-console directory and run

mvn clean install

this will generate some gwt interfaces

when this finishes you may have to Maven > Update project... for the
uddi-portlets project. Make sure the project now looks like




Note the inclusion of target/generated-sources/gwt.

4. Now start tomcat in juddi-tomcat/target/tomcat/apache-tomcat-6.0.26/bin


5. Now you can launch GWT from eclipse




In the Google Development window select to attach to the UDDIBrowser using Chrome.



and log in using root/root and see the UDDI Browser



You can then set break points in both client side (the java code that ends up being javascript) and server side code. The server side code of the UDDIBrowser makes calls into the jUDDI back end (running on tomcat). You can start tomcat in debug and attach to the debug socket to step through that code as well.

Beside being able to debug the UDDIBrowser it is also the perfect development environment as changes to the code tend to be live immediately on saving the file (and hitting refresh in the browser).

Well, this ended up much longer then expected! I hope it helps you.

Good luck!

--Kurt