Red Hat Training

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

Chapter 7. Using the jUDDI Client

7.1. jUDDI Client

The jUDDI Client connects you to your Service Registry. The client is found in SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/lib/juddi-client-VERSION.jar.

7.2. jUDDI Client Dependencies

The jUDDI Client depends on the following files:
  • uddi-ws-3.0.0.jar
  • commons-configuration-1.5.jar
  • commons-collection-3.2.1.jar
  • log4j-1.2.13.jar
In addition to these, you may require the following, depending on your configuration choices:
  • libraries for JDK6.
  • JAXWS client libraries (if you are using a JAXWS transport like CXF.)
  • RMI and JNDI client libraries (if you are using the RMI Transport.)

7.3. jUDDI Client and the JBoss Enterprise SOA Platform

Important

The jUDDI Client uses the UDDI v3 API so it should be able to connect to any UDDI v3-compliant registry. However, Red Hat only supports it with the jUDDI v3 Registry.

7.4. Transport Settings

The transport settings are the connection settings that the jUDDI client uses to talk to its server.

7.5. uddi.xml

The META-INF/uddi.xml file contains the configuration settings for the jUDDI client. You can include this file in the deployment archive that is interacting with the UDDI client code.

7.6. Deploy a Custom jUDDI Client Configuration

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>
    

7.7. Sample jUDDI Client Configuration File

Here is a simple jUDDI client configuration:
        <?xml version="1.0" encoding="ISO-8859-1" ?>
<uddi>
  <reloadDelay>5000</reloadDelay>
  <manager name="example-manager">
    <nodes>
      <node isHomeJUDDI="true">
        <name>default</name>
        <description>jUDDI node</description>  
        <properties>
          <property name="serverName"  value="www.myuddiserver.com"/>
          <property name="serverPort"  value="8080"/>
          <property name="keyDomain"   value="mydepartment.mydomain.org"/>
          <property name="department"  value="mydepartment" />
        </properties>
        <!-- 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>
        <!-- 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>
        -->
        <!-- 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>
        -->
      </node>
    </nodes>
    <clerks registerOnStartup="true">
      <clerk name="BobCratchit" node="default" publisher="bob" password="bob">
         <class>org.apache.juddi.samples.HelloWorldImpl</class>
      </clerk>
    </clerks>
  </manager>	
</uddi>
The manager element is required. The example-manager name attribute should be unique to your deployment environment. The nodes element may contain one or more sub-node elements. Normally, you would only need one node, unless you are using subscriptions to transfer updates of entities from one UDDI registry to another. For the 'local' registry you would set isHomeJUDDI="true", while for the 'remote' registries you would set isHomeJUDDI="false".

Table 7.1. Elements

Element Name Description Required?
name name of the node yes
description description of the node no
properties container for properties that will be passed into the clerk no
proxyTransport The Transport protocol used by the client to connect to the UDDI server yes
custodyTransferUrl Connection settings for custody transfer no
inquiryUrl Connection location settings for inquiries yes
publishUrl Connection location settings for publishing yes
securityUrl Connection location settings for obtaining security tokens yes
subscriptionUrl Connection location settings for registering subscription requests no
subscriptionListenerUrl Connection location settings receiving subscription notifications no
juddiApiUrl Connection location settings for the jUDDI specific API for things like publisher management no
Finally, the manager element can contain a 'clerks' element in which you can define one or more clerks.

Table 7.2. Clerks

Attribute Name Description Required?
name name of the clerk yes
node name reference to one of the nodes specified in the same manager yes
publisher name of an existing publisher yes
password password credential of the publisher yes

7.8. Java API for XML Web Services (JAX-WS)

The Java API for XML Web Services (JAX-WS) is a Java API that allows you to create web services. The JAX-WS handler mechanism is used by the web service to invoke a user-specified class whenever a message (or fault) is sent or received. The handler is therefore installed in the message pipeline and used to manipulate the message header or body as required.

7.9. Set the JAX-WS Transport

Prerequisites

  • Based on the settings in the uddi.xml file, the client will use JAX-WS to communicate with the (remote) registry server. This means that the client needs to have access to a JAX-WS-compliant web service stack (such as CXF, Axis2 or JBossWS).

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.

7.10. Remote Invocation Class

As its name implies, a remote invocation class is a class that can be called from a remote machine. This can be useful for developers but can also lead to potential security risks.

7.11. jUDDI and Remote Method Invocation

If you deploy the jUDDI to an Application Server, you can register the UDDI services as remote method invocation services.

7.12. Enable Remote Method Invocation for jUDDI

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.
Result

When you deploy it, the RMI-based UDDI services will bind to the global JNDI namespace:

  • juddiv3 (class: org.jnp.interfaces.NamingContext)
  • UDDIPublicationService (class: org.apache.juddi.rmi.UDDIPublicationService)
  • UDDICustodyTransferService (class: org.apache.juddi.rmi.UDDICustodyTransferService)
  • UDDISubscriptionListenerService (class: org.apache.juddi.rmi.UDDISubscriptionListenerService)
  • UDDISecurityService (class: org.apache.juddi.rmi.UDDISecurityService)
  • UDDISubscriptionService (class: org.apache.juddi.rmi.UDDISubscriptionService)
  • UDDIInquiryService (class: org.apache.juddi.rmi.UDDIInquiryService)

7.13. InVM Transport

The InVM ("intra-virtual machine") Transport provides communication between services running on the same JVM.

7.14. InVM and jUDDI

You have the option of using the InVM Transport. It allows you to run the jUDDI server in the same virtual machine as your client. If you are deploying to the juddi.war archive, the server will be started by the org.apache.juddi.RegistryServlet class, but if you are running outside any container, you are responsible for starting and stopping the org.apache.juddi.Registry service yourself.

7.15. Configure the InVM Transport for jUDDI

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.

7.16. Start the Service Registry Using the InVM Transport

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

7.17. Stop the Service Registry Using the InVM Transport

Procedure 7.5. Task

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

The registry releases any resources it may be holding.

7.18. UDDI Annotation

UDDI annotations automatically register services as they are deployed. By having them automatically handling service registration, it means the data in the Service Registry is less likely to become outdated than if you added and removed each end-point reference manually.
There are two annotations, namely UDDIService and UDDIServiceBinding. You need to use both to register an end-point.
When you undeploy a service, the end-point will be removed from the UDDI Registry but the service information remains. (It makes sense to leave the service level information in the Registry since this reflects that the service is there even though there is no end-point at the moment. This is telling it to "check back later").

Note

If you do want to remove service information, you must do so manually.

7.19. Use the UDDIService Annotation

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.

7.20. UDDIService Attributes

Table 7.3. 

Attribute Description Required?
serviceName This is the name of the service. By default, the clerk will use the one name specified in the WebService annotation No
description This is the human-readable description of the service Yes
serviceKey This is the service's UDDI v3 key. Yes
businessKey This is the UDDI v3 key of the business that should own the service. (The business should exist in the Registry at time of registration.) Yes
lang This is the language locale which will be used for the name and description. (It defaults to "en" if you omit it.) No
categoryBag This is the definition of a CategoryBag. No

7.21. Use the UDDIServiceBinding Annotation

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

7.22. UDDIServiceBinding Attributes

Table 7.4. UDDIServiceBinding Attributes

Attribute Description Required?
bindingKey This is the ServiceBinding's UDDI v3 key. Yes
description This is a human-readable description of the service Yes
accessPointType This is UDDI v3's AccessPointType. (It defaults to wsdlDeployment if you omit it.) No
accessPoint This is the end-point reference Yes
lang This is the language locale which will be used for the name and description, (It will default to "en" if you omit it.) No
tModelKeys This is a comma-separated list of tModelKeys key references. No
categoryBag This is the definition of a CategoryBag. No

7.23. Example Use of UDDI Annotations

Introduction

You can use the annotations on any class that defines a service. Here they are added to a web service (a POJO with a JAX-WS web service 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;
    }
}
When you deploy this web service, the juddi-client code will scan this class for UDDI annotations and take care of the registration process.
In the clerk section, you need to refer to the org.apache.juddi.samples.HelloWorldImpl service class:
            <clerk name="BobCratchit" node="default" publisher="sales" password="sales"> 
                 <class>org.apache.juddi.samples.HelloWorldImpl</class>  
            </clerk>
This code dictates that Bob is using the connection setting of the node named default, and that he will be using the sales publisher (for which the password is sales).

Note

This is analogous with how data-sources are defined.

7.24. CategoryBag Attribute

Use the CategoryBag attribute to refer to tModels.

7.25. Example Use of the CategoryBag Annotation

Here is a sample CategoryBag:
        <categoryBag>
           <keyedReference tModelKey="uddi:uddi.org:categorization:types" 
            keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" /> 
           <keyedReference tModelKey="uddi:uddi.org:categorization:types" 
            keyName="uddi-org:types:wsdl2" keyValue="wsdlDeployment2" />
        </categoryBag>
You can add it like this:
categoryBag="keyedReference=keyName=uddi-org:types:wsdl;keyValue=wsdlDeployment;" +
                     "tModelKey=uddi:uddi.org:categorization:types," +  
                     "keyedReference=keyName=uddi-org:types:wsdl2;keyValue=wsdlDeployment2;" +
                     "tModelKey=uddi:uddi.org:categorization:types2",

7.26. Use Annotations to Develop a Web Service

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.

7.27. Key Template

A key template is a template that can be set in a business, service or binding key's "annotation" attribute. Both the WSDL and BPEL registration code use the key format o construct UDDI v3 keys. The format of the keys is defined in the properties section of the uddi.xml file.
Both the key's serviceName and portName are obtained from the RegistrationInfo. The nodeName can be obtained automatically from the environment, or you can set it manually in the uddi.xml file. The values you set for the properties in this template will be used when the key is registered.

7.28. Key Template Properties

Table 7.5. Key Template Properties

Property Description Required? Default Value
lang The language setting used by the registration no en
businessName The business name which is used by the registration. yes -
keyDomain The key domain key part (used by the key formats) yes -
businessKeyFormat Key format used to construct the Business Key no uddi:${keyDomain}:business_${businessName}
serviceKeyFormat Key format used to construct the BusinessService Key no uddi:${keyDomain}:service_${serviceName}
bindingKeyFormat Key format used to construct the TemplateBinding Key no uddi:${keyDomain}:binding_${nodeName}_${serviceName}_${portName}
serviceDescription Default BusinessService description no Default service description when no <wsdl:document> element is defined inside the <wsdl:service> element.
bindingDescription Default BindingTemplate description no Default binding description when no <wsdl:document> element is defined inside the <wsdl:binding> element.

7.29. Use the jUDDI Client Code in Your Application

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.

7.30. WSDL and the UDDI Registry

The jUDDI client implements the UDDI v3 version of the WSDL2UDDI mapping as described in the OASIS technical note found at http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v2.htm. The registration process registers a BindingTemplate for each WebService EndPoint and, if the BusinessService for this BindingTemplate does not yet exist, it also registers the BusinessService along with a WSDLPortType TModel for each portType, and a WSDLBinding TModel for each binding.

7.31. Specification for the Service and Binding Descriptions in the WSDL

The UDDI specification allows you to set a human-readable description on both the BusinessService and TemplateBinding. These description fields are important if humans are browsing the registry. A default global description is found in the uddi.xml file. However it makes a lot more sense to have a specific description for each service and binding and so the registration code tries to obtain these descriptions from the <wsdl:document> tags in the WSDL, which can be nested as a child element inside the <wsdl:service> and <wsdl:binding> elements.

7.32. Register a WSDL Process in jUDDI

Prerequisites

  • org.apache.juddi.v3.client.mapping

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.

7.33. Remove a WSDL Binding from the Service Registry

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.

7.34. Register a BPEL Process in jUDDI

Prerequisites

  • org.apache.juddi.v3.client.mapping

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.

7.35. URLLocalizer Interface and the JBoss Enterprise SOA Platform

The end-point URL setting is obtained from WSDL <wsdl:port>'s <soap:addressbinding>. Unfortunately, this URL is static, and it is useful if it can be made dynamic. In the version of the URLLocalizer that ships with the JBoss Enterprise SOA Platform, the settings obtained from the local WebService Stack override the protocol and host parts of the URL, mitigating this problem.

7.36. Dynamic UDDI Service Look-up

"Dynamic UDDI service look-up" refers to the process of periodically interrogating the UDDI registry to obtain fresh binding information. This makes the system more dynamic than if it simply looked at the actual binding information for the web service's end point that is stored on the client-side. Furthermore, it allows clients to simply following the changes that occur in the service deployment topology.

7.37. Use the Service Locator to Find a Service Binding

Prerequisites

  • You must already know the names of the service and port.

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.

7.38. Tutorial: Using the jUDDI Client

Prerequisites

  • Make sure the publisher (in this case, root) already exists in the Service Registry

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.