JBoss.orgCommunity Documentation
This information is relevant for both understanding how jUDDI’s default data is set when jUDDI first runs (i.e. to a new database). It’s also useful for scripting or automating the deployment of a jUDDI server within your organization which will enable you to prepopulate the data.
As of UDDI v3, each registry need to have a "root" publisher. The root publisher is the owner of the UDDI services (inquiry, publication, etc). There can only be one root publisher per node. JUDDI ships some default seed data for the root account. The default data can be found in the juddi-core-3.x.jar, under juddi_install_data/. By default jUDDI installs two Publishers: "root" and "uddi". Root owns the root partition, and uddi owns all the other seed data such as pre-defined tModels.
For each publisher there are four seed data files that will be read the first time you start jUDDI:
<publisher>_Publisher.xml <publisher>_tModelKeyGen.xml <publisher>_BusinessEntity.xml <publisher>_tModels.xml
For example the content of the root_Publisher.xml looks like
<publisher xmlns="urn:juddi-apache-org:api_v3" authorizedName="root">
<publisherName>root publisher</publishername>
<isAdmin>true</isadmin>
</publisher>
Each publisher should have its own key generator schema so that custom generated keys cannot end up being identical to keys generated by other publishers. It is therefor that the each publisher need to define their own KenGenerator tModel. The tModel Key Generator is defined in the file root_tModelKeyGen.xml and the content of this file is
<tModel tModelKey="uddi:juddi.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3">
<name>uddi-org:keyGenerator</name>
<description>Root domain key generator</description>
<overviewDoc>
<overviewURL useType="text">
http://uddi.org/pubs/uddi_v3.htm#keyGen
</overviewurl>
</overviewdoc>
<categoryBag>
<keyedReference tModelKey="uddi:uddi.org:categorization:types"
keyName="uddi-org:types:keyGenerator"
keyValue="keyGenerator" />
</categorybag>
</tmodel>
This means that the legal format of keys used by the root publisher need to be in the form uddi:juddi.apache.org:<text-of-chioce></text-of-chioce> The use of other types of format will lead to an illegal key error. The root publisher can only own one KeyGenerator while any other publisher can own more then one KeyGenerator. KeyGenerators should not be shared unless there is a good reason to do so. If you want to see your publisher with more then just the one KeyGenerator tModel, you can use the <publisher></publisher>_tModels.xml file. Finally, in the <publisher></publisher>_BusinessEntity.xml file can be used to setup Business and Service data. In the root_BusinessEntity.xml we specified the ASF Business, and the UDDI services; Inquiry, Publish, etc.:
<businessEntity xmlns="urn:uddi-org:api_v3" xmlns:xml="http://www.w3.org/XML/1998/namespace" businessKey="uddi:juddi.apache.org:businesses-asf">
<!-- Change the name field to represent the name of your registry -->
<name xml:lang="en">An Apache jUDDI Node</name>
<!-- Change the description field to provided a brief description of your registry -->
<description xml:lang="en">This is a UDDI v3 registry node as implemented by Apache jUDDI.</description>
<discoveryURLs>
<!-- This discovery URL should point to the home installation URL of jUDDI -->
<discoveryURL useType="home">${juddi.server.baseurl}/juddiv3</discoveryURL>
</discoveryURLs>
<categoryBag>
<keyedReference tModelKey="uddi:uddi.org:categorization:nodes" keyValue="node" />
</categoryBag>
<businessServices>
<!-- As mentioned above, you may want to provide user-defined keys for these (and the services/bindingTemplates below. Services that you
don't intend to support should be removed entirely -->
<businessService serviceKey="uddi:juddi.apache.org:services-inquiry" businessKey="uddi:juddi.apache.org:businesses-asf">
<name xml:lang="en">UDDI Inquiry Service</name>
<description xml:lang="en">Web Service supporting UDDI Inquiry API</description>
<bindingTemplates>
<bindingTemplate bindingKey="uddi:juddi.apache.org:servicebindings-inquiry-ws" serviceKey="uddi:juddi.apache.org:services-inquiry">
<description>UDDI Inquiry API V3</description>
<!-- This should be changed to the WSDL URL of the inquiry API. An access point inside a bindingTemplate will be found for every service
in this file. They all must point to their API's WSDL URL -->
<accessPoint useType="wsdlDeployment">${juddi.server.baseurl}/services/inquiry?wsdl</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:v3_inquiry">
<instanceDetails>
<instanceParms>
<![CDATA[
<?xml version="1.0" encoding="utf-8" ?>
<UDDIinstanceParmsContainer xmlns="urn:uddi-org:policy_v3_instanceParms">
<defaultSortOrder>
uddi:uddi.org:sortorder:binarysort
</defaultSortOrder>
</UDDIinstanceParmsContainer>
]]>
</instanceParms>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
<categoryBag>
<keyedReference keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</bindingTemplate>
</bindingTemplates>
</businessService>
<!-- snip -->
</businessService>
Note that the seeding process only kicks off if no publishers exist in the database. So this will only work with a clean database, unless you set juddi/seed/always to true. Then it will re-apply all files with the exception of the root data files. Note that this can lead to losing data that was added to entities that are re-seeded, since data is not merged.
You may have noticed the tokens in the root_BusinessEntity.xml file (${juddi.server.baseurl}. The value of this tokens can set in the juddiv3.xml file. The value substitution takes place at runtime, so that different nodes can do the substitution with their own value if needed.
In your deployment you probably do not want to use the Seed Data shipped with the default jUDDI install. The easiest way to overwrite this data is to add it to a directory call juddi_custom_install_data in the juddiv3.war/WEB-INF/classes/ directory. That way you don’t have to modify the juddi-core-3.x.jar. Additionally if your root publisher is not called "root" you will need to set the juddi/root/publisher property in the juddiv3.xml file to something other then
juddi/root/publisher=root
The juddiv3.war ships with two example data directory. One for the Sales Affiliate, and one for the Marketing Affiliate. To use the Sales Seed Data, in the juddiv3.war/WEB-INF/classes/, rename the directory
*nix mv RENAME4Sales_juddi_custom_install_data juddi_custom_install_data Win* ren RENAME4Sales_juddi_custom_install_data juddi_custom_install_data
before you start jUDDI the first time. It will then use this data to populate the database. If you want to rerun you can trash the database it created and restart tomcat. Don’t forget to set the tokens in the juddiv3.xml file.