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