UDDI EJB Interface (Deprecated)

The UDDI EJB interface is deprecated in WebSphere Application Server version 6 or later and supports UDDI version 2 API requests only.

This section describes how to use the EJB application programming interface (API) of the IBM WebSphere UDDI Registry component to publish, find and delete UDDI entries.

The client classes that are required for the EJB interface are contained in install_root/UDDIReg/ejb/ejbclient.jar. You can read the Javadoc for these classes at the Javadoc welcome page.

The EJB API is contained in two stateless session beans, one for the Inquiry API (com.ibm.uddi.ejb.InquiryBean) and one for the Publish API (com.ibm.uddi.ejb.PublishBean), whose public methods form an EJB interface for the UDDI Registry. All the public methods on the InquiryBean correspond to UDDI Version 2 Inquiry API functions, and all the public methods on the PublishBean correspond to UDDI Version 2 Publish API functions. Not all UDDI Version 2 API functions are implemented, for example get_authToken, discard_authToken, get_businessDetailExt.

Within each interface there are groups of overloaded methods that correspond to the operations in the UDDI 2.0 specification. There is a separate method for each major variation in function. For example, the single UDDI operation find_business is represented by 10 variations of findBusiness methods, with different variations for finding by name, finding by categoryBag and so on.

The arguments for the EJB interface methods are Java objects in the package com.ibm.uddi.datatypes. Roughly speaking, there is a one to one correspondence between classes in this package and elements of the UDDI Version 2 XML schema. Exceptions to this are, for example, where UDDI XML elements can be represented by a single String. See the Javadoc for package com.ibm.uddi.datatypes for more information at Javadoc welcome page

The methods of the UDDI EJB interface are mapped to the EJB Inquiry and Publish roles, which protect the EJB interface as described in Access control for UDDI Registry interfaces. If the role mapping is such that a method will require a WebSphere Application Server authenticated userid, a client program can supply the userid and password either when prompted by WebSphere Application Server, or by providing application code which logs in to the default realm using the userid and password.

Using the EJB Client In this section it is assumed that you have installed both WebSphere Application Server version 6.0 and the UDDI Registry (and they are both running). You cannot use the EJB Client from a machine that does not have WebSphere installed.

1. Set up your environment for communicating with WebSphere:

   • UNIX: . install_root/bin/setupCmdLine.sh (note that there is a space between the '.' and install_root)

   • Windows: install_root/bin/setupCmdLine.bat

2. Ensure that your CLASSPATH includes the uddiejbclient.jar (from install_root/UDDIReg/ejb) and the code for your client.

3. Compile your EJB client programs:

   • UNIX: $JAVA_HOME/bin/javac -extdirs $WAS_EXT_DIRS:$JAVA_HOME/jre/lib/ext -classpath $WAS_CLASSPATH:$CLASSPATH yourcode.java

   • Windows: %JAVA_HOME%\bin\javac -extdirs %WAS_EXT_DIRS%:%JAVA_HOME%\jre\lib\ext -classpath %WAS_CLASSPATH%;%CLASSPATH% yourcode.java

4. Execute the compiled programs:

   • UNIX: $JAVA_HOME/bin/java -Djava.ext.dirs=$WAS_EXT_DIRS:$JAVA_HOME/jre/lib/ext -Dwas.install.root=$WAS_HOME -Dserver.root=$WAS_HOME $CLIENTSAS $CLIENTSOAP -cp $WAS_CLASSPATH:$WAS_HOME/UDDIReg/ejb/uddiejbclient.jar:$CLASSPATH <class name> <args>

   • Windows: %JAVA_HOME%\bin\java -Djava.ext.dirs=%WAS_EXT_DIRS%;%JAVA_HOME%\jre\lib\ext -Dwas.install.root=%WAS_HOME% -Dserver.root=%WAS_HOME% %CLIENTSAS% %CLIENTSOAP% -cp %WAS_CLASSPATH%;%WAS_HOME%\UDDIReg\ejb\uddiejbclient.jar:%CLASSPATH% <class name> <args>

Ensure that your PATH statement starts with install_root/java/bin