Apache jUDDICommunity Documentation

Chapter 7. Using the jUDDI-Client

7.1. Introduction
7.2. Configuration
7.3. JAX-WS Transport
7.4. RMI Transport
7.5. InVM Transport
7.6. Dependencies
7.7. Sample Code

The jUDDI project includes a jUDDI-Client (juddi-client-3.0.0.jar) which can be use to connect to the Registry. The client uses the UDDI v3 API so it should be able to connect to any UDDI v3 compliant registry, however we have only tested it with jUDDIv3. It maybe useful to take a look at the unit-tests in the jUDDIv3-uddi-client module to see how the client can be used.

The UDDI client has a configuration file called uddi.xml. In this file you can set the type “Transport” used by the client to talk to the registry. The client tries to locate this file on the classpath and uses Apache Commons Configuration [COM-CONFIG] to read it. By default the uddi.xml file looks like

<?xml version="1.0" encoding="ISO-8859-1" ?>
<uddi>
    <reloadDelay>5000</reloadDelay>
    <manager name="example-manager">
        <nodes>
            <node>
                <name>default</name>
                <description>Main jUDDI node</description>  
                <properties>
                    <property name="serverName"  value="localhost"/>
                    <property name="serverPort"  value="8080"/>
                    <property name="keyDomain"   value="juddi.apache.org"/>
                    <property name="department"  value="businesses" />
                </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>

Using the settings in the uddi.xml file from above, 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 WS stack (such as CXF, Axis2 or JBossWS). Make sure to point the JAXWS URLs to 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?wsdl
    </custodyTransferUrl>
    <inquiryUrl>
        http://${serverName}:${serverPort}/juddiv3/services/inquiry?wsdl
    </inquiryUrl>
    <publishUrl>
        http://${serverName}:${serverPort}/juddiv3/services/publish?wsdl
    </publishUrl>
    <securityUrl>
        http://${serverName}:${serverPort}/juddiv3/services/security?wsdl
    </securityUrl>
    <subscriptionUrl>
        http://${serverName}:${serverPort}/juddiv3/services/subscription?wsdl
    </subscriptionUrl>
    <subscriptionListenerUrl>
        http://${serverName}:${serverPort}/juddiv3/services/subscription-listener?wsdl
    </subscriptionListenerUrl>
    <juddiApiUrl>
        http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl
    </juddiApiUrl>

If jUDDIv3 is deployed to an Application Server it is possible to register the UDDI Services as RMI services. If this is desired you need to edit the juddiv3.war/WEB-INF/classes/juddiv3.properties file, on the server. Add the following setting

juddi.jndi.registration=true

Now at deployment time, the RMI based UDDI services are bound into the Global JNDI namespace.

Next, on the client side you need to comment out the JAXWS section in the uddi.properties file and use the RMI Transport section instead. Optionally you can set the java.naming.* properties. In this case we specified setting for connecting to jUDDIv3 deployed to a JBoss Application Server. If you like you can set the java.naming.* properties in a jndi.properties file, or as System parameters.

If you choose to use InVM Transport this means that the jUDDIv3 server is running in the same VM as you client. If you are deploying to juddi.war the server will be started by the org.apache.juddi.RegistryServlet, but if you are running outside any container, you are responsible for starting and stopping the org.apache.juddi.Registry Service yourself. Make sure to call

Registry.start()

before making any calls to the Registry, and when you are done using the Registry (on shutdown) call

Registry.stop()

so the Registry can release any resources it may be holding. To use InVM Transport uncomment this section in the uddi.properties while commenting out the JAXWS and RMI Transport sections.

The UDDI client depends on uddi-ws-3.0.0.jar, commons-configuration-1.5.jar, commons-collection-3.2.1.jar and log4j-1.2.13.jar, plus

Sample code on how to use the UDDI client can be found in the uddi-client module on the jUDDIv3 project. Usually the first thing you want to is to 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();
    } 
}

Make sure that the publisher, in this case “root” is an existing publisher in the Registry and that you are supplying the correct credential to get a successful response. If needed check Chapter 3, Authentication to learn more about this subject.

Another place to look for sample code is the docs/examples/helloword directory. Alternatively you can use annotations.