GuideAdministration
There are several different ways to administrator and configure jUDDI. This section will outline and/or link to relevant information to assist you. There are two ways to configure and reconfigure jUDDI, via the XML file and through your web browser.
The jUDDI web services are typically first configured via manually editing the juddiv3.xml file, located at the following location:
<servletContainer>/juddiv3/WEB-INF/classes/juddiv3.xml
Note: version prior to 3.2 used a properties (key=value) file. Version 3.2 and up use an XML configuration file. Many of key names have changed to help cluster settings logically.
Once jUDDI is deployed, it can be reconfigured via the web browser by accessing:
http://<server>:<port>/juddiv3/admin
Then click on "Configure".
jUDDI includes a number of Cryptographic providers that are provided with most Java Runtime environments. Not all of the functions will operate in all countries due to various legal restrictions.
-
Triple Data Encryption Standard
-
Advanced Encryption Standard 128 and 256 bit
-
Password Based Encryption With MD5 and DES
For convenience, administrators can use a command line utility to encrypt passwords that are stored within the jUDDI server and client configuration files.
If you want to change the port Tomcat listens on to something non-standard (something other than 8080), use the following guidance.
jUDDI Server (Tomcat) - This assumes you are using the jUDDI server bundled with Apache Tomcat. For other application servers, consult their documentation, however the juddiv3.xml must still be altered.
-
Edit conf/server.xml and change the port within the <Connector> element.
-
Edit webapps/juddiv3/WEB-INF/classes/juddiv3.xml and change the port number jUDDI Server Baseurl.
-
Edit webapps/juddiv3/WEB-INF/config.properties and change the port numbers for "securityurl" and "juddipapi".
-
Edit webapps/juddi-gui/META-INF/config.properties and change the port numbers for all of the URLs listed.
There are a few options for deploying jUDDI to another application server and/or web service stack. . Grab the default prebuilt war file and modify it to work in your environment . Download the source code for jUDDI and run the maven integration script. Use the following steps
-
Target platform Tomcat and Derby using OpenJPA and CXF. Both OpenJPA and CXF are packaged up in the juddiv3.war.
mvn clean package -P openjpa
-
Target platform Tomcat and Derby using Hibernate and CXF. Both Hibernate and CXF are packaged up in the juddiv3.war.
mvn clean package -P hibernate
-
Target platform Tomcat and Derby using OpenJPA and Apache Axis2. Both Hibernate and Axis2 are packaged up in the juddiv3.war.
mvn clean package -P axis2
-
Target platform JBoss-6.x and HSQL using Hibernate and JBossWS-native. The juddiv3.war relies on Hibernate and JBossWS-native in the appserver.
mvn clean package -P hibernate-jbossws-native
-
Target platform JBoss-6.x and HSQL using Hibernate and JBossWS-cxf. The juddiv3.war relies on Hibernate and JBossWS-cxf in the appserver.
mvn clean package -P hibernate-jbossws-cxf
- Issue 1
-
15:14:37,275 SEVERE [RegistryServlet] jUDDI registry could not be started. org.apache.commons.configuration.ConfigurationException: java.util.zip.ZipException: error in opening zip file: org.apache.commons.configuration.ConfigurationException: org.apache.commons.configuration.ConfigurationException: java.util.zip.ZipException: error in opening zip file
Workaround: deploy juddiv3.war as a directory (not a zip file).
- Issue 2
-
JBoss-5.x Note that configuration 3 and 4 will also run on JBoss-5.x, but you may run into the following
ERROR [org.jboss.ws.metadata.wsdl.xmlschema.JBossXSErrorHandler] (main) [domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolve]::Message=src-resolve: Cannot resolve the name ns1:Signature to a element declaration component.
Workaround: Unzip the deployers/jbossws.deployer/jbossws-native-core.jar and add the xmldsig-core-schema.xsd in the schema directory,
10293 Fri May 27 14:40:40 EDT 2011 schema/xmldsig-core-schema.xsd
Edit the file META-INF/jbossws-entities.properties by adding a line at the bottom saying:
http\://www.w3.org/2000/09/xmldsig#=schema/xmldsig-core-schema.xsd
If you are using Hibernate as a persistence layer for jUDDI, then Oracle will generate a default sequence for you ("HIBERNATE_SEQUENCE"). If you are using hibernate elsewhere, you may wish to change the sequence name so that you do not share this sequence with any other applications. If other applications try to manually create the default hibernate sequence, you may even run into situations where you find conflicts or a race condition.
The easiest way to handle this is to create an orm.xml file and place it within the classpath in a META-INF directory, which will override the jUDDI persistence annotations and will allow you to specify a specific sequence name for use with jUDDI. The following orm.xml specifies a "juddi_sequence" sequence to be used with jUDDI.
<entity-mappings
xmlns="http://java.sun.com/xml/ns/persistence/orm"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
version="1.0">
<sequence-generator name="juddi_sequence" sequence-name="juddi_sequence"/>
<entity class="org.apache.juddi.model.Address">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.AddressLine">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BindingDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BusinessDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BusinessIdentifier">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BusinessName">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.CategoryBag">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.Contact">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.ContactDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.DiscoveryUrl">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.Email">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.InstanceDetailsDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.InstanceDetailsDocDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.KeyedReference">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.KeyedReferenceGroup">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.OverviewDoc">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.OverviewDocDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.PersonName">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.Phone">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.ServiceDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.ServiceName">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.SubscriptionMatch">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelIdentifier">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelInstanceInfo">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TmodelInstanceInfoDescr">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.TransferTokenKey">
<attributes>
<id name="id">
<generated-value generator="juddi_sequence" strategy="AUTO"/>
</id>
</attributes>
</entity>
<entity class="org.apache.juddi.model.BindingTemplate">
<attributes>
<basic name="accessPointUrl">
<column name="access_point_url" length="4000"/>
</basic>
</attributes>
</entity>
</entity-mappings>
jUDDI supports both OpenJPA and Hibernate as persistence providers. If you are embedding jUDDI, it is important to note that there are two JARs provided through maven. If you will be using Hibernate, please use the juddi-core JAR, if you are using OpenJPA, use juddi-core-openjpa.
The difference between these JARs is that the persistence classes within juddi-core-openjpa have been enhanced (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html). Unfortunately, the Hibernate classloader does not deal well with these enhanced classes, so it it important to note not to use the juddi-core-openjpa JAR with Hibernate.
The jUDDI codebase uses the commons-logging-api, and log4j as the default logging implementation. The juddiv3/WEB-INF/classes/commons-logging.properties sets the logging to log4j. The default log4j configuration logs to a juddi.log file in the tomcat/logs directory. The log4j configuration lives in the juddiv3/WEB-INF/classes/log4j.properties file, which is referenced in the web.xml
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>/WEB-INF/classes/log4j.properties</param-value>
</context-param>
The commons-logging and log4j jars are shipped in the juddiv3/WEB-INF/lib directory.
If you are using CXF for the webservice stack you can log the request/response xml by adding
log4j.category.org.apache.cxf=INFO
to your log4j.properties and the cxf.xml file should contains this:
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
The jUDDI beans.xml specifies the location of this file at META-INF/cxf/cxf.xml.
There are a few things worth mentioning for administering the jUDDI Graphical User Interface. The first is user authentication, which is covered in the authentication chapter. The other the the Digital Signature Applet. This applet enables users to digitally signed UDDI entities via the GUI. There are a number of requirements in order for this to work.
-
The applet must be digitally signed. It is recommended that this signed by the administrator using the SSL certificate of the jUDDI instance. If it is not signed, it may not be able to digital certificates.
-
The Oracle Java browser plugin must be installed. For details on this, visit Oracle’s website.
-
The end user must have a digital certificate installed that is accessible to the browser. On Windows computers, this is supported by Internet Explorer, Opera and Chrome which use the Windows Certificate Store (Start > Run > MMC, Add Certificates). Firefox uses its own certificate store. On MacOS, Safari uses the Mac Keychain.
Your instance of the jUDDI (juddiv3.war) can be managed via the administration console. It can be access url the following URL:
http://localhost:8080/juddiv3/admin
By default, only users with the role "uddiadmin" are allowed to access this page. In addition, it must be accessed from the same computer hosting juddiv3.war (this can be changed if needed). When accessing the URL, you should be prompted for login via username/password (this can also be changed to another mechanism).
After authenticating, you will be prompted with a very similar interface to the juddi-gui.war. From here, you can perform a number of tasks.
Access the jUDDIv3 API, which provides a number of administrative tasks and functions (requires an additional login)*
*Why is there another login required for the jUDDIv3 API functions?
The answer is because the admin console will be directly accesses a web service and it requires a user account with juddi admin rights. This may be the same username you use to access the admin console (juddiv3.war/admin) but unfortunately, this double login is unavoidable.
From the browser, it is possible to configure jUDDI’s web services via the web browser. All of the settings available from the chapter on configuring jUDDI can be set there.
The Statistics and Status page provides valuable information to administrators and developers looking to trouble shoot or debug problems with jUDDI.
The Statistics page provides you with access to usage counts and time spent processing on each method of each service that jUDDI provides.
|
Tip
|
This information can be pulled and is available in JSON encoded data from the following URL: http://localhost:8080/juddiv3/admin/mbeans.jsp |
The jUDDI API is a web service that extends the UDDI specification. It provides various functions for both configuring the jUDDI server and for performing administrative functions, such as authorizing a new username as a publisher, user rights assignment and so on. This page will let you access the functions from the web browser.
|
Tip
|
You must authenticate using the top right hand side login/password box in order to use this. |
There are several different strategies for managing your jUDDI backups.
Database backups are vendor specific and are effective for backup/restore to a similar or exact jUDDI version reinstall.
Aside from database backups, you should also make backup copies of all jUDDI configuration files and any files that you have customized to meet your operational needs.
Sometimes, the jUDDI development team has no choice but to alter the database schema. In many cases, OpenJPA or Hibernate (both Java Persistence API provides) will automatically alter database columns when a new version is installed. In some cases, there may actually be data loss.
|
Tip
|
Check the jUDDI distribution notes before attempting an upgrade. |
|
Important
|
Always perform a database level backup of your instance before attempting the upgrade. |
As of version 3.2, jUDDI includes a command line data migration tool. It can export and import data from UDDIv3 servers. It can also capture jUDDI publisher data. In addition, it can preserve UDDI entity ownership information. Here’s a few use cases for using the migration tool:
-
Copying data from one registry to another
-
Migrating from one vendor to another
-
Periodic backups
-
Upgrades to jUDDI
|
Tip
|
The migration tool will not overwrite data when importing. |
There are many configuration options and settings for the migration tool. This tool is distributed with the uddi client distribution package. To execute, type
C:\juddi\trunkcur\juddi-migration-tool\target>java -jar juddi-migration-tool-{VERSION}-SNAPSHOT-jar-with-dependencies.jar
This tool is used to export and import UDDI data from a UDDI v3 registry
Random TIP: You can easily script the UDDI migration tool and use it as a backup mechanism.
usage: java -jar juddi-migration-tool-(VERSION)-jar-with-dependencies.jar
-business <arg> Im/Export option, file to store the business data,
default is 'business-export.xml'
-config <arg> Use an alternate config file default is 'uddi.xml'
-credFile <arg> Import option with -preserveOwnership, this is a
properties file mapping with user=pass
-export Exports data into a UDDIv3 registry
-import Imports data into a UDDIv3 registry
-isJuddi Is this a jUDDI registry? If so we can in/export
more stuff
-mappings <arg> Im/Export option, file that maps keys to owners,
default is 'entityusermappings.properties'
-myItemsOnly Export option, Only export items owned by yourself
-node <arg> The node 'name' in the config, default is 'default'
-pass <arg> Password, if not defined, those is uddi.xml will be
used
-preserveOwnership Im/Export option, saves owership data to the
'mappings' file
-publishers <arg> jUDDI only - In/Export option, file to store
publishers, default is 'publishers-export.xml'
-tmodel <arg> Im/Export for tmodels, file to store tmodel data,
default is 'tmodel-export.xml'
-user <arg> Username, if not defined, those is uddi.xml will be
used