Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

Chapter 3. Setting Up Your Root Seed Data

3.1. Service Registry Publishers

Publisher is an identity management system for the Service Registry. Two publishers are installed by default:
root
The root publisher is the owner of the root partition and UDDI services (such as inquiry and publication). Each registry need to have a root publisher. There can only be one root publisher per node. The jUDDI Registry ships some default seed data for the root account, found in the juddi-core-3.x.jar file's juddi_install_data/ directory.
uddi
uddi owns all of the other seed data (such as the pre-defined tModels.

3.2. Seed Data

Seed data is some initial data you feed into the system. It functions as a template.

3.3. Service Registry Seed Data Files

For each publisher there are four seed data files. These are read the first time you start the jUDDI:
  • <publisher>_Publisher.xml
  • <publisher>_tModelKeyGen.xml
  • <publisher>_BusinessEntity.xml
  • <publisher>_tModels.xml

3.4. root_Publisher.xml

The contents of the root_Publisher.xml data seed file looks like this: 
<publisher xmlns="urn:juddi-apache-org:api_v3" authorizedName="root">
    <publisherName>root publisher</publisherName>
    <isAdmin>true</isAdmin>
</publisher>

3.5. Key Generator Schema

As its name implies, a key generator schema generates keys. Using it allows one to avoid the risk of creating keys that are identical to those generated by other publishers. Each publisher should always have its own key generator schema. The root publisher can only own one KeyGenerator while but any other publisher can own more than one.

3.6. tModel

A tModel ("technical model") is an UDDI data structure that represents one of the services registered in the registry. They are are a catch-all structure that can do anything from categorising one of the main entities, describing the technical details of a binding (such as a protocol or a transports), to registering a key partition.

3.7. root_tModelKeyGen.xml

The tModel Key Generator is defined in the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_tModelKeyGen.xml file: 
<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 keys used by the root publisher need to be in the following form: uddi:juddi.apache.org:<text-of-choice>.

3.8. Create a Key Generator Schema for a Publisher

Procedure 3.1. Task

  1. Each publisher need to define its own KenGenerator tModel. The tModel Key Generator is defined in the root_tModelKeyGen.xml file: 
    <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>
  2. The keys used by the root publisher need to be in the following form: uddi:juddi.apache.org:<text-of-choice>. If you use another format, you will see an illegal key error.

    Warning

    Do not share KeyGenerators.

3.9. View a Publisher via More than Just One KeyGenerator tModel

Procedure 3.2. Task

  • Use the <publisher>_tModels.xml file.

3.10. Configure Business and Service Data Using a Publisher

Procedure 3.3. Task

  1. Open the <publisher>_BusinessEntity.xml file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml
  2. Edit the file to specify your services. Here is an example: 
    <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">
            http://${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">
                        http://${juddi.server.baseurl}/juddiv3/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>
        <businessService serviceKey="uddi:juddi.apache.org:services-publish" 
            businessKey="uddi:juddi.apache.org:businesses-asf">
            <name xml:lang="en">UDDI Publish Service</name>
            ...........
        </businessService>
    </businessServices>
</businessEntity>
  3. Save the file and exit.

    Warning

    The seeding process only commences if there are no publishers in the database, unless you set juddi.seed.always to true. (It will then re-apply all files with the exception of the root data files.)
    This can lead to data loss, as any information added to entities that are re-seeded will be erased. This is because that data is not merged.

3.11. Configure Tokens in the root_BusinessEntity.xml File

Procedure 3.4. Task

  1. To set the value of the tokens in the root_BusinessEntity.xml file (${juddi.server.baseurl}), modify the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml file. Open the <publisher>_BusinessEntity.xml file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml
  2. Here you can set keys and security tokens. Modify these sections to suit your needs.
  3. Save the file and exit.

    Note

    The value substitution takes place at run-time, so different nodes can substitute their own values if need be.

3.12. Customise the Seed Data

Procedure 3.5. Task

  • Important

    You must do this prior to starting the Service Registry for the first time as this seed data will be used to populate the database.
    If you do want to re-run the process, delete the database that was created.
    Do not forget to set the tokens in the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml file.
    Add your custom seed data to juddiv3.war/WEB-INF/classes/juddi_custom_install_data/ directory.

    Note

    To use the Sales Seed Data rename the directory found in the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar//WEB-INF/classes/ by running this command: mv RENAME4Sales_juddi_custom_install_data juddi_custom_install_data

    Note

    If your root publisher is not called root you will need to set the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml file's juddi.root.publisher property to something other than this: 
    juddi.root.publisher=root
    Properties are set in this way: 
    <entry key="juddi.root.publisher">root</entry>