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.

Procedure 3.2. Task

• Use the <publisher>_tModels.xml file.

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.

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.

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>
  

Procedure 4.1. Task

1. Instantiate the SimplePublish class. Here is the constructor:

         public SimplePublish() 
   {
       try 
       {
           String clazz = UDDIClientContainer.getUDDIClerkManager(null).
               getClientConfig().getUDDINode("default").getProxyTransport();
           Class<?> transportClass = ClassUtil.forName(clazz, Transport.class);
           if (transportClass!=null) 
           {
               Transport transport = (Transport) transportClass.
                   getConstructor(String.class).newInstance("default");
   
               security = transport.getUDDISecurityService();
               juddiApi = transport.getJUDDIApiService();
               publish = transport.getUDDIPublishService();
           }	
       } 
       catch (Exception e) 
       {
           e.printStackTrace();
       }	
   }
   

   This constructor uses the jUDDI client API to retrieve the transport from the default node. In this example, it is simply retrieving the default client transport class which is designed to make UDDI calls out using JAX-WS web services.
2. Obtain the three API sets needed for the example:
   • the Security API set, so you can obtain authorisation tokens,
   • the proprietary jUDDI API set so you can save a publisher,
   • the Publication API set so that you can register entities in the jUDDI.
   Here are the first few lines of the publish method:

    // Setting up the values to get an authentication token for the 'root' user 
   // ('root' user has admin privileges and can save other publishers).
   GetAuthToken getAuthTokenRoot = new GetAuthToken();
   getAuthTokenRoot.setUserID("root");
   getAuthTokenRoot.setCred("");
   
   // Making API call that retrieves the authentication token for the 'root' user.
   AuthToken rootAuthToken = security.getAuthToken(getAuthTokenRoot);
   System.out.println ("root AUTHTOKEN = " + rootAuthToken.getAuthInfo());
   

   This code simply retrieves the authorisation token for the root user.
3. Add a publisher:

   // Creating a new publisher that we will use to publish our entities to.
   Publisher p = new Publisher();
   p.setAuthorizedName("my-publisher");
   p.setPublisherName("My Publisher");
   
   // Adding the publisher to the "save" structure, using the 'root' user authentication 
   // info and saving away. 
   SavePublisher sp = new SavePublisher();
   sp.getPublisher().add(p);
   sp.setAuthInfo(rootAuthToken.getAuthInfo());
   juddiApi.savePublisher(sp);
   

   The code above uses the jUDDI API to save a publisher with authorised name, my-publisher. Note that the authorisation token for the root user is utilised.
4. Obtain the authorisation token for this new publisher:

    // Our publisher is now saved, so now we want to retrieve its authentication token
   GetAuthToken getAuthTokenMyPub = new GetAuthToken();
   getAuthTokenMyPub.setUserID("my-publisher");
   getAuthTokenMyPub.setCred("");
   AuthToken myPubAuthToken = security.getAuthToken(getAuthTokenMyPub);
   System.out.println ("myPub AUTHTOKEN = " + myPubAuthToken.getAuthInfo());
   

   Note that no credentials have been set on either of the authorisation calls. This is because, by using the default authenticator, you do not have to provide any.
5. Publish:

   // Creating the parent business entity that will contain our service.
   BusinessEntity myBusEntity = new BusinessEntity();
   Name myBusName = new Name();
   myBusName.setValue("My Business");
   myBusEntity.getName().add(myBusName);
   
   // Adding the business entity to the "save" structure, using our publisher's 
   // authentication info and saving away.
   SaveBusiness sb = new SaveBusiness();
   sb.getBusinessEntity().add(myBusEntity);
   sb.setAuthInfo(myPubAuthToken.getAuthInfo());
   BusinessDetail bd = publish.saveBusiness(sb);
   String myBusKey = bd.getBusinessEntity().get(0).getBusinessKey();
   System.out.println("myBusiness key:  " + myBusKey);
   
   // Creating a service to save.  Only adding the minimum data: the parent 
   // business key retrieved from saving the business above and a single name.
   BusinessService myService = new BusinessService();
   myService.setBusinessKey(myBusKey);
   Name myServName = new Name();
   myServName.setValue("My Service");
   myService.getName().add(myServName);
   // Add binding templates, etc...
   
   // Adding the service to the "save" structure, using our publisher's 
   // authentication info and saving away.
   SaveService ss = new SaveService();
   ss.getBusinessService().add(myService);
   ss.setAuthInfo(myPubAuthToken.getAuthInfo());
   ServiceDetail sd = publish.saveService(ss);
   String myServKey = sd.getBusinessService().get(0).getServiceKey();
   System.out.println("myService key:  " + myServKey);
   

   Note

   There are some important things to note with regard to the use of entity keys. Version three of the specification allows for publishers to create their own keys but also instructs implementers to have default methods.

   Red Hat has chosen the default implementation approach by leaving each entity’s key field blank in the save call. The jUDDI’s default key generator simply takes the node’s partition and appends a GUID to it.

   In a default installation, it will look something like this: uddi:juddi.apache.org:<GUID>

   (You can, of course, customise all of this if you wish.)

   The second important point is that when the BusinessService is saved, its parent business key (retrieved from previous call saving the business) is set explicitly. This is a necessary step when the service is saved in an independent call like this because, otherwise, you would encounter an error as the jUDDI will not know where to find the parent entity.

Procedure 5.1. Task

1. Configuring Node One: Sales

   Create juddi_custom_install_data by running these commands:
   cd juddiv3/WEB-INF/classes
   mv RENAME4SALES_juddi_custom_install_data juddi_custom_install_data
2. Open the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml file in a text editor and set the following property values (where "sales" is the DNS name of your server):

   juddi.server.name=sales
   juddi.server.port=8080
   

3. Save the file and exit.
4. Start the server: SOA_ROOT/jboss-as/bin/./run.sh
5. Open a web browser and go to this address: http://sales:8080/juddiv3. You should see a message that provides you with information about the node.

6. Configuring Node Two: Marketing

   Create juddi_custom_install_data by running these commands:
   cd juddiv3/WEB-INF/classes
   mv RENAME4MARKETING_juddi_custom_install_data juddi_custom_install_data
7. Open the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml file in a text editor and set the following property values (where "marketing" is the DNS name of your server)

   juddi.server.name=marketing
   juddi.server.port=8080
   

8. Save the file and exit.
9. Start the server: SOA_ROOT/jboss-as/bin/./run.sh
10. Open a web browser and go to this address: http://sales:8080/juddiv3. Again you should see a message that provides you with information about the node.

    Note

    Note that the root partition was kept the same, because both the sales and marketing departments are located in the same company, but the Node Id and Name changed to reflect that each node belongs to a different department.
11. Next, replace the sales server's uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml file with uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml.sales.
12. Open the uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml file in a text editor and add the following properties:

    <name>default</name>
    <properties>
        <property name="serverName" value="sales"/>
        <property name="serverPort" value="8080"/>
        <property name="rmiPort" value="1099"/>
    </properties>
    

13. Save the file and exit.
14. Launch a web browser and go to this address: http://sales:8080/pluto.
15. Log in with both a user name and password of sales and observe what is displayed onscreen.
16. Before logging into the marketing portal, replace marketing's uddi-portlet.war/WEB-INF/classes/META-INF/uddi.xml file with udd-portlet.war/WEB-INF/classes/META-INF/uddi.xml.marketing.
17. Open the uddi-portlet.war/WEB-INF/classes/META_INF/uddi.xml file in a text editor and add the following properties:

    <name>default</name>
    <properties>
        <property name="serverName" value="marketing"/>
        <property name="serverPort" value="8080"/>
        <property name="rmiPort" value="1099"/>
    </properties>
    

18. Save the file and exit.
19. Launch a web browser and go to this address: http://marketing:8080/pluto.
20. Log in with both a user name and password of sales and observe what is displayed onscreen.

    Note

    The subscriptionlistener is owned by the Marketing Node business, not the Root Marketing Node. The Marketing Node Business is managed by the marketing publisher.

Procedure 5.2. Task

1. Open the juddiv3-samples.war/WEB-INF/classes/META-INF/uddi.xml file in a text editor and add the following property values to sales:

   <?xml version="1.0" encoding="ISO-8859-1" ?>
   <uddi>
       <reloadDelay>5000</reloadDelay>
       <manager name="example-manager">
           <nodes>
               <node>
                   <name>default</name>
                   <description>Sales jUDDI node</description>  
                   <properties>
                       <property name="serverName"  value="sales"/>
                       <property name="serverPort"  value="8080"/>
                       <property name="keyDomain"   value="sales.apache.org"/>
                       <property name="department"  value="sales" />
                   </properties>
                   <proxyTransport>
                       org.apache.juddi.v3.client.transport.InVMTransport
                   </proxyTransport>
                   <custodyTransferUrl>
                       org.apache.juddi.api.impl.UDDICustodyTransferImpl
                   </custodyTransferUrl>
                   <inquiryUrl>org.apache.juddi.api.impl.UDDIInquiryImpl</inquiryUrl>
                   <publishUrl>org.apache.juddi.api.impl.UDDIPublicationImpl</publishUrl>
                   <securityUrl>org.apache.juddi.api.impl.UDDISecurityImpl</securityUrl>
                   <subscriptionUrl>
                       org.apache.juddi.api.impl.UDDISubscriptionImpl
                   </subscriptionUrl>
                   <subscriptionListenerUrl>
                       org.apache.juddi.api.impl.UDDISubscriptionListenerImpl
                   </subscriptionListenerUrl>
                   <juddiApiUrl>org.apache.juddi.api.impl.JUDDIApiImpl</juddiApiUrl>
               </node>
           </nodes>
       </manager>
   </uddi>
   

2. Save the file and exit.
3. Now deploy the juddiv3-samples.war to the sales registry.
   ant deploy
   ant runtest

   Note

   The HelloSales service is provided in the juddiv3-samples.war archive file and it is annotated, so it will automatically register itself.
4. Subscribe to the Sales UDDI node's HelloWord service from within the Marketing UDDI node.

Procedure 5.3. Task

1. If you are going to use the marketing publisher to subscribe to updates in the sales registry, then you must provide this publisher with two clerks. You do so by opening the uddi-portlet.war/uddi.xml file in a text editor and adding the following lines:

       <clerks registerOnStartup="false">
       <clerk  name="MarketingCratchit"    node="default" 
               publisher="marketing"       password="marketing"/>
   
       <clerk  name="SalesCratchit"        node="sales-ws"   
               publisher="marketing"       password="marketing"/>
       <!--  optional 
       <xregister>
           <servicebinding 
               entityKey="uddi:marketing.apache.org:servicebindings-subscriptionlistener-ws" 
               fromClerk="MarketingCratchit" toClerk="SalesCratchit"/>
       </xregister>
       -->
   </clerks>
   

   In the code above, you created two clerks for this publisher, namely MarketingCratchit and SalesCratchit. These allow the publisher to check on the subscriptions it owns in each of the two systems.
2. Save the file and exit.
3. Log in as the marketing publisher on the marketing portal and select the UDDISubscription Portlet.
4. When both nodes turn green, click on the new subscription icon (found on the toolbar.) This will be a synchronous subscription, so only leave the Binding Key and Notification Interval
5. Click the Save icon to store the subscription.
6. Make sure that the subscription key uses the marketing publisher's keyGenerator's conventions. You should see the orange subscription icon appear under the sales-ws UDDI node.
7. To invoke a synchronous subscription, click the Green Arrows icon. This will give you the opportunity to set the coverage period.
8. Click the Green Arrows icon again to invoke the synchronous subscription request.
   The example finder request will search the sales node looking for updates to the HelloWorld service. The raw XML response is then posted to the UDDISubscriptionNotification portlet:
9. The response is processed by the marketing node. This node then imports the HelloWorld subscription information, as well as the sales business. If they synchronise successfully, three businesses will be visible in the marketing node's browser portlet.

Procedure 7.1. Task

1. Open META-INF/uddi.xml in your text editor.
2. Configure the settings.
3. Save and exit.
4. Include the uddi.xml file in your archive when you deploy it.
5. Call this code:

   UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml");
   clerkManager.start();
   

6. Alternatively, if your application deploys as a WAR archive, add your client configuration to yourwar/META-INF/myuddi.xml and, in the web.xml file, specify these context parameters: uddi.client.manager.name and uddi.client.xml.
   In this example, both context parameters are set and on deployment the UDDIClerkServlet takes care of reading the configuration:

          <!-- required -->
   <context-param>
       <param-name>uddi.client.manager.name</param-name>
       <param-value>example-manager</param-value>
    </context-param>
    
   <!-- optional override -->
   <context-param>
       <param-name>uddi.client.xml</param-name>
       <param-value>META-INF/myuddi.xml</param-value>
   </context-param>
   
   <servlet>
       <servlet-name>UDDIClerkServlet</servlet-name>
       <display-name>Clerk Servlet</display-name>
       <servlet-class>org.apache.juddi.v3.client.config.UDDIClerkServlet</servlet-class>
       <load-on-startup>1</load-on-startup>
   </servlet>
   

Procedure 7.2. Task

• Ensure that the JAX-WS URLs are pointing to an address where the UDDI client can find the WSDL documents:

  <!-- JAX-WS Transport -->
  <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport>
  <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer</custodyTransferUrl>
  <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry</inquiryUrl>
  <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish</publishUrl>
  <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security</securityUrl>
  <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription</subscriptionUrl>
  <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-listener</subscriptionListenerUrl>
  <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</juddiApiUrl>
  

  Important

  Pros: This is the standard way of performing UDDI communication and it should should work with all UDDIv3 server implementations.

  Cons: If the server is deployed on the same application server this may lead to issues when auto-registration on deployment/undeployment is used, since the WS stack may become unavailable during undeployment. A workaround is to host the UDDI server on a different server.

Procedure 7.3. Task

1. Open the jUDDI configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml.
2. Edit the settings and set the property <entry key="juddi.jndi.registration">true</entry>. If set to true, RMI methods are registered to jndi and can be searched and called. Default is true.
3. Save the file and exit.
4. Open the UDDI configuration file in a text editor: vi META-INF/uddi.xml.
5. "Comment out" the JAX-WS section of the file and uncomment the RMI section instead.
6. As an optional step, you can also set the java.naming.* properties. In this example, you specified the setting for connecting to jUDDI v3 deployed on a JBoss Application Server. If you like you can instead set the java.naming.* properties in a jndi.properties file, or as system parameters.

   <!-- RMI Transport Settings -->
   <proxyTransport>org.apache.juddi.v3.client.transport.RMITransport</proxyTransport>
   <custodyTransferUrl>/juddiv3/UDDICustodyTransferService</custodyTransferUrl>
   <inquiryUrl>/juddiv3/UDDIInquiryService</inquiryUrl>
   <publishUrl>/juddiv3/UDDIPublicationService</publishUrl>
   <securityUrl>/juddiv3/UDDISecurityService</securityUrl>
   <subscriptionUrl>/juddiv3/UDDISubscriptionService</subscriptionUrl>
   <subscriptionListenerUrl>/juddiv3/UDDISubscriptionListenerService</subscriptionListenerUrl>
   <juddiApiUrl>/juddiv3/JUDDIApiService</juddiApiUrl>
   <javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial>
   <javaNamingFactoryUrlPkgs>org.jboss.naming</javaNamingFactoryUrlPkgs>
   <javaNamingProviderUrl>jnp://${serverName}:1099</javaNamingProviderUrl>
   

   Important

   Pros: It is lightweight fast since it does not need a web service stack.

   Cons: It only works with a jUDDI v3 server implementation.
7. Save the file and exit.

Procedure 7.4. Task

1. Open the UDDI configuration file in a text editor: vi META-INF/uddi.xml.
2. "Comment out" the JAX-WS and RMI Transport sections of the file and uncomment the InVM Transport section instead.

   <!-- InVM -->
   <proxyTransport>org.apache.juddi.v3.client.transport.InVMTransport</proxyTransport>
   <custodyTransferUrl>org.apache.juddi.api.impl.UDDICustodyTransferImpl</custodyTransferUrl>
   <inquiryUrl>org.apache.juddi.api.impl.UDDIInquiryImpl</inquiryUrl>
   <publishUrl>org.apache.juddi.api.impl.UDDIPublicationImpl</publishUrl>
   <securityUrl>org.apache.juddi.api.impl.UDDISecurityImpl</securityUrl>
   <subscriptionUrl>org.apache.juddi.api.impl.UDDISubscriptionImpl</subscriptionUrl>
   <subscriptionListenerUrl>org.apache.juddi.api.impl.UDDISubscriptionListenerImpl</subscriptionListenerUrl>
   <juddiApiUrl>org.apache.juddi.api.impl.JUDDIApiImpl</juddiApiUrl>
   

   Important

   Pros: It is lightweight and provides the best performance for communications and there are no deployment order issues when using auto-registration of services during deployment and undeployment.

   Cons: It will only work with a jUDDI v3 server implementation. Normally, you would use a jUDDI server for each application server sharing one common database.
3. Save the file and exit.

• Call the following method prior to making any other calls to it: Registry.start()

Procedure 7.5. Task

• Call the following method prior to making any other calls to it: Registry.stop()

Procedure 7.6. Task

• Use the UDDIService annotation to register a service under an already-existing business in the Registry. The annotation should be added to the Java class' "class" level.

Procedure 7.7. Task

• Use the UDDIServiceBinding annotation to register an end-point reference in the Service Registry. The annotation should be added to the Java class' "class" level.

  Note

  You cannot use this annotation by itself. It needs to be utilised within an UDDIService annotation

Procedure 7.8. Task

1. Add an annotation to any class that defines a service. Here is an example where they are added to a web service POJO with a JAX-WS Webservice annotation:

   package org.apache.juddi.samples;
   
   import javax.jws.WebService;
   import org.apache.juddi.v3.annotations.UDDIService;
   import org.apache.juddi.v3.annotations.UDDIServiceBinding;
   
   @UDDIService(businessKey="uddi:myBusinessKey", serviceKey="uddi:myServiceKey", description = "Hello World test service")
   @UDDIServiceBinding(bindingKey="uddi:myServiceBindingKey", description="WSDL endpoint for the helloWorld Service. This service is used for "
         + "testing the jUDDI annotation functionality",
       accessPointType="wsdlDeployment", accessPoint="http://localhost:8080/juddiv3-samples/services/helloworld?wsdl")
   @WebService(endpointInterface = "org.apache.juddi.samples.HelloWorld", serviceName = "HelloWorld")
   
   public class HelloWorldImpl implements HelloWorld {
       public String sayHi(String text) {
           System.out.println("sayHi called");
           return "Hello " + text;
       }
   }
   

   On deployment of this WebService, the juddi-client code will scan this class for UDDI annotations and take care of the registration process.
2. Open the uddi.xml file in your text editor: vi uddi.xml
3. Scroll down to the "clerk" section and add a reference to the org.apache.juddi.samples.HelloWorldImpl service class:

   <clerks registerOnStartup="true">
     <clerk name="BobCratchit" node="default" publisher="bob" password="bob"> 
       <class>org.apache.juddi.samples.HelloWorldImpl</class>  
     </clerk>
   </clerks>
   

   In this example, Bob is using the connection setting for the node named "default". Furthermore, he will be using a publisher named "bob", for which the password is also "bob".
4. Save the file and exit.

Procedure 7.9. Task

1. Open the jUDDI client configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml. Use this file as a template for your own uddi.xml file.
2. Make sure the clerk manager points to your custom uddi.xml when it is instantiated:

   UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml");
   clerkManager.start();
   
   UDDIClerk clerk = clerkManager.getClientConfig().getUDDIClerks().get(clerkName);
   

   Note

   A UDDIClerk will allow you do make authenticated requests to a UDDI server.

Procedure 7.10. Task

1. Use the code in the org.apache.juddi.v3.client.mapping package.
2. Make the following call to asynchronously register your web service end point:

   //Add the properties from the uddi.xml
   properties.putAll(clerk.getUDDINode().getProperties());
   RegistrationInfo registrationInfo = new RegistrationInfo();
   registrationInfo.setServiceQName(serviceQName);
   registrationInfo.setVersion(version);
   registrationInfo.setPortName(portName);
   registrationInfo.setServiceUrl(serviceUrl);
   registrationInfo.setWsdlUrl(wsdlURL);
   registrationInfo.setWsdlDefinition(wsdlDefinition);
   registrationInfo.setRegistrationType(RegistrationType.WSDL);
   registration = new AsyncRegistration(clerk, urlLocalizer, properties, registrationInfo);
   Thread thread = new Thread(registration);
   thread.start();
   

   Note

   This does assume that you can pass in a URL to the WSDL file in addition to the WSDLDefinition. In most cases you will need to package the WSDL file you wish to register in your deployment.

   To obtain a WSDLDefinition use this code:

   ReadWSDL readWSDL = new ReadWSDL();
   Definition definition = readWSDL.readWSDL("wsdl/HelloWorld.wsdl");
   

   You need to pass the path information to the WSDL that is on the classpath.

Procedure 7.11. Task

• To remove a WSDL binding from the service registry, use this code:

  WSDL2UDDI wsdl2UDDI = new WSDL2UDDI(clerk, urlLocalizer, properties);
  String serviceKey = wsdl2UDDI.unRegister(serviceName, portName, serviceURL);
  

  Note

  If this is the last BindingTemplate for the BusinessService it will also remove the BusinessService itself along with the WSDLPortType and WSDLBinding TModels. The lifecycle is set to "registration" on deployment of the end point and set to "unregistration" on removal of the end point.

Procedure 7.12. Task

1. Use the code in the org.apache.juddi.v3.client.mapping package.
2. Make the following call to asynchronously register your web service end point:

   //Add the properties from the uddi.xml
   properties.putAll(clerk.getUDDINode().getProperties());
   RegistrationInfo registrationInfo = new RegistrationInfo();
   registrationInfo.setServiceQName(serviceQName);
   registrationInfo.setVersion(version);
   registrationInfo.setPortName(portName);
   registrationInfo.setServiceUrl(serviceUrl);
   registrationInfo.setWsdlUrl(wsdlURL);
   registrationInfo.setWsdlDefinition(wsdlDefinition);
   registrationInfo.setRegistrationType(RegistrationType.BPEL);
   registration = new AsyncRegistration(clerk, urlLocalizer, properties, registrationInfo);
   Thread thread = new Thread(registration);
   thread.start();
   

   Set the RegistrationInfo.RegistrationType to RegistrationType.BPEL.

Procedure 7.13. Task

• To locate a service binding using the service locator, use this code:

  ServiceLocator serviceLocator = new ServiceLocator(clerk, urlLocalizer, properties);
  String endPointURL = serviceLocator.lookupEndpoint(serviceQName, String portName);
  

  Note

  The downside of doing a look-up prior to each service invocation is that it will be detrimental to performance.

Procedure 7.14. Task

1. Obtain the sample code located in the uddi-client module.
2. Make a call to the Registry to obtain an authentication token. (The following code is taken from the unit tests in this module):

   public void testAuthToken() {
       try {
           String clazz = ClientConfig.getConfiguration().getString(
               Property.UDDI_PROXY_TRANSPORT,Property.DEFAULT_UDDI_PROXY_TRANSPORT);
           Class<?> transportClass = Loader.loadClass(clazz);
           if (transportClass!=null) {
               Transport transport = (Transport) transportClass.newInstance();
               UDDISecurityPortType securityService = transport.getSecurityService();
               GetAuthToken getAuthToken = new GetAuthToken();
               getAuthToken.setUserID("root");
               getAuthToken.setCred("");
               AuthToken authToken = securityService.getAuthToken(getAuthToken);
               System.out.println(authToken.getAuthInfo());
               Assert.assertNotNull(authToken);
           } else {
               Assert.fail();
           }
       } catch (Exception e) {
           e.printStackTrace();
           Assert.fail();
       } 
   }
   

   Note

   Ensure that you supply the correct credentials for the root publisher to obtain a successful response.