Use the Enterprise JavaBeans (EJB) application programming interface (API) of the UDDI registry component to publish, find, and delete UDDI entries. However, the UDDI EJB interface is deprecated and supports UDDI version 2 API requests only.
The client classes that are required for the EJB interface are contained in app_server_root/UDDIReg/clients/uddiejbclient.jar. You can read the Java documentation 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 class correspond to UDDI Version 2 inquiry API functions, and all the public methods on the PublishBean class 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.
In 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 ten variations of findBusiness methods, with different variations to find by name, find by categoryBag argument, and so on.
The arguments for the EJB interface methods are Java objects in thee com.ibm.uddi.datatypes packag. Generally, there is a one-to-one correspondence between classes in this package and elements of the UDDI Version 2 XML schema. Exceptions to this correspondence are, for example, where UDDI XML elements can be represented by a single String. See the Java documentation for package com.ibm.uddi.datatypes for more information, at Javadoc welcome page.
The methods on the EJB InquiryBean class map to the EJB inquiry role, and those of the EJB PublishBean class map to the EJB publish role. The EJB inquiry and publish roles protect the EJB interface, as described in Access control for UDDI registry interfaces. If the role mapping is such that a method requires a WebSphere Application Server authenticated user ID, a client program can supply the user ID and password, either when prompted by WebSphere Application Server, or by providing application code that logs in to the default realm using the user ID and password. Use the sas.client.props configuration file to determine how to specify the user ID and password (see Configuring security with scripting ).
Using the EJB client
. app_server_root/bin/setupCmdLine.sh
(note the space between the period and app_server_root)
app_server_root/bin/setupCmdLine.bat
. app_server_root/bin/setupCmdLine
(note the space between the period and app_server_root)
$JAVA_HOME/bin/javac
-extdirs $WAS_EXT_DIRS:$JAVA_HOME/jre/lib/ext -classpath $WAS_CLASSPATH:$CLASSPATH
yourcode.java
%JAVA_HOME%/bin/javac
-extdirs $WAS_EXT_DIRS:%JAVA_HOME%/jre/lib/ext -classpath %WAS_CLASSPATH%:%CLASSPATH%
yourcode.java
$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/clients/uddiejbclient.jar:$CLASSPATH <class
name> <args>
%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\clients\uddiejbclient.jar:%CLASSPATH% <class
name> <args>
Ensure that your PATH statement starts with app_server_root/java/bin.