GuideAdministration
There are several different ways to administrator and configure jUDDI. This chapter will outline and/or link to relevant information to assist you.
There are a few options for deploying jUDDI to another application server, web service stack or JPA provider. 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
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'.
|
Note
|
Saving will only work if juddiv3 is deployed a directory and has write access to update the juddiv3.xml file. |
For an overview of all configuation properties see
As of version 3.2, jUDDI Authentication is handled from two perspectives, end user access and administrators.
End users typically will either access jUDDI’s services directly at http://localhost:8080/juddiv3/ or via the user interfaces http://localhost:8080/juddi-gui. In both cases, authentication is handled via jUDDI’s Authentication providers which is configured in juddiv3.war/WEB-INF/classes/juddiv3.xml.
Administrative users have special access to juddi-gui’s remote configuration page at http://localhost:8080/juddi-gui/settings.jsp and to the Administrative Console at http://localhost:8080/juddiv3/admin. Access to both of these is configured at the container level (i.e. Jboss, Tomcat, etc). By default, users that need to access these pages need to have the "uddiadmin" role (which is defined in the WEB-INF/web.xml of both web application archives).
In order to enforce proper write access to jUDDI, each request to jUDDI needs a valid authToken. Note that read access is not restricted (by default, but can be enabled) and therefore queries into the registries are not restricted.
To obtain a valid authToken a getAuthToken() request must be made, where a GetAuthToken object is passed. On the GetAuthToken object a userid and credential (password) needs to be set.
|
Important
|
When referring to configuration 'properties', we are really referencing the XPath to specified setting. |
org.uddi.api_v3.GetAuthToken ga = new org.uddi.api_v3.GetAuthToken();
ga.setUserID("username");
ga.setCred("password");
org.uddi.api_v3.AuthToken token = securityService.getAuthToken(ga);
The property juddi/auth/* in the juddiv3.xml configuration file can be used to configure how jUDDI is going to check the credentials passed in on the GetAuthToken request. By default jUDDI uses the JUDDIAuthenticator implementation. You can provide your own authentication implementation or use any of the ones mention below. The implementation needs to implement the org.apache.juddi.auth.Authenticator interface, and juddi/auth/authenticator/class property should refer to the implementation class.
There are two phases involved in Authentication. The authenticate phase and the identify phase. Both of these phases are represented by a method in the Authenticator interface.
The authenticate phase occurs during the GetAuthToken request as described above. The goal of this phase is to turn a user id and credentials into a valid publisher id. The publisher id (referred to as the "authorized name" in UDDI terminology) is the value that assigns ownership within UDDI. Whenever a new entity is created, it must be tagged with ownership by the authorized name of the publisher. The value of the publisher id can be completely transparent to jUDDI - the only requirement is that one exists to assign to new entities. Thus, the authenticate phase must return a non-null publisher id. Upon completion of the GetAuthToken request, an authentication token is issued to the caller.
In subsequent calls to the UDDI API that require authentication, the token issued from the GetAuthToken request must be provided. This leads to the next phase of jUDDI authentication - the identify phase.
The identify phase is responsible for turning the authentication token (or the publisher id associated with that authentication token) into a valid UddiEntityPublisher object. The UddiEntityPublisher object contains all the properties necessary to handle ownership of UDDI entities. Thus, the token (or publisher id) is used to "identify" the publisher.
The two phases provide compliance with the UDDI authentication structure and grant flexibility for users that wish to provide their own authentication mechanism. Handling of credentials and publisher properties can be done entirely outside of jUDDI. However, jUDDI provides the Publisher entity, which is a sub-class of UddiEntityPublisher, to persist publisher properties within jUDDI. This is used in the default authentication and is the subject of the next section.
The default authentication mechanism provided by jUDDI is the JUDDIAuthenticator. The authenticate phase of the JUDDIAuthenticator simply checks to see if the user id passed in has an associated record in the Publisher table. No credentials checks are made. If, during authentication, the publisher does not exist, it the publisher is added on the fly.
|
Warning
|
Do not use jUDDI Default Authenticator in production. It does not compare passwords to anything! |
The identify phase uses the publisher id to retrieve the Publisher record and return it. All necessary publisher properties are populated as Publisher inherits from UddiEntityPublisher.
juddi/auth/authenticator/class = org.apache.juddi.auth.JUDDIAuthentication
jUDDI provides a number of cryptographic providers. Some of them may not be available in your region of the world due to export restrictions. All of these providers are provides that are included with the Oracle Java Runtime Environment.
|
Tip
|
The AES256Cryptor requires the Sun Java unlimited strength Crypograhpic Extensions to be installed. OpenJDK users are not affected by this. |
In the following section, Authentication, a Cryptographic Provider must be selected using the following property in juddiv3.xml:
juddi/cryptor
-
org.apache.juddi.cryptor.DefaultCryptor - Password Based Encryption With MD5 and DES
-
org.apache.juddi.cryptor.TripleDESCrytor - Triple DES 168 bit
-
org.apache.juddi.cryptor.AES128Cryptor - Advanced Encryption Standard 128 bit
-
org.apache.juddi.cryptor.AES256Cryptor - Advanced Encryption Standard 256 bit
-
org.apache.juddi.v3.client.crypto.DefaultCryptor - Password Based Encryption With MD5 and DES
-
org.apache.juddi.v3.client.crypto.TripleDESCrytor - Triple DES 168 bit
-
org.apache.juddi.v3.client.crypto.AES128Cryptor - Advanced Encryption Standard 128 bit
-
org.apache.juddi.v3.client.crypto.AES256Cryptor - Advanced Encryption Standard 256 bit
To encrypt a password, the jUDDI Tomcat server comes with a basic Windows Batch file and a Unix Bash script which will fire off the correct Java command. It is located at the following path:
{tomcat_home}/bin/juddi-cryptor.bat/sh
|
Tip
|
The jUDDI-Client (Java only) uses the same encryption keys and the jUDDI Server, therefore encrypted passwords using this tool will work with the jUDDI-client’s configuration file. |
In addition, an MD5 hashing program is included to assist with setting users passwords for the MD5XMLDocAuthenticator.
{tomcat_home}/bin/juddi-md5.bat/sh
The XMLDocAuthentication implementation needs a XML file on the classpath. The juddiv3.xml file would need to look like
juddi/auth/authenticator/class = org.apache.juddi.auth.XMLDocAuthentication juddi/auth/usersfile = juddi-users.xml
where the name of the XML can be provided but it defaults to juddi-users.xml, and the content of the file would looks something like
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<juddi-users>
<user userid="anou_mana" password="password" />
<user userid="bozo" password="clown" />
<user userid="sviens" password="password" />
</juddi-users>
The authenticate phase checks that the user id and password match a value in the XML file. The identify phase simply uses the user id to populate a new UddiEntityPublisher.
The CryptedXMLDocAuthentication implementation is similar to the XMLDocAuthentication implementation, but the passwords are encrypted.
juddi/auth/authenticator/class = org.apache.juddi.auth.CryptedXMLDocAuthentication juddi/auth/usersfile = juddi-users-encrypted.xml juddi/cryptor = org.apache.juddi.cryptor.DefaultCryptor
where the name user credential file is juddi-users-encrypted.xml, and the content of the file would looks something like
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<juddi-users>
<user userid="anou_mana" password="+j/kXkZJftwTFTBH6Cf6IQ=="/>
<user userid="bozo" password="Na2Ait+2aW0="/>
<user userid="sviens" password="+j/kXkZJftwTFTBH6Cf6IQ=="/>
</juddi-users>
The DefaultCryptor implementation uses BEWithMD5AndDES and Base64 to encrypt the passwords. Note that the code in the AuthenticatorTest can be used to learn more about how to use this Authenticator implementation. You can plugin your own encryption algorithm by implementing the org.apache.juddi.cryptor.Cryptor interface and referencing your implementation class in the juddi.cryptor property. The authenticate phase checks that the user id and password match a value in the XML file. The identify phase simply uses the user id to populate a new UddiEntityPublisher.
The MD5XMLDocAuthenticator implementation is similar to the XMLDocAuthentication implementation, but the passwords are hashed using MD5.
juddi/auth/authenticator/class = org.apache.juddi.auth.MD5XMLDocAuthenticator juddi/auth/usersfile = juddi-users-hashed.xml juddi/cryptor = org.apache.juddi.cryptor.DefaultCryptor
where the name user credential file is juddi-users-encrypted.xml, and the content of the file would looks something like
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<juddi-users>
<user userid="anou_mana" password="+j/kXkZJftwTFTBH6Cf6IQ=="/>
<user userid="bozo" password="Na2Ait+2aW0="/>
<user userid="sviens" password="+j/kXkZJftwTFTBH6Cf6IQ=="/>
</juddi-users>
The DefaultCryptor implementation uses BEWithMD5AndDES and Base64 to encrypt the passwords. Note that the code in the AuthenticatorTest can be used to learn more about how to use this Authenticator implementation. You can plugin your own encryption algorithm by implementing the org.apache.juddi.cryptor.Cryptor interface and referencing your implementation class in the juddi.cryptor property. The authenticate phase checks that the user id and password match a value in the XML file. The identify phase simply uses the user id to populate a new UddiEntityPublisher.
LdapSimpleAuthenticator provides a way of authenticating users using LDAP simple authentication. It is fairly rudimentary and more LDAP integration is planned in the future, but this class allows you to authenticate a user based on an LDAP prinicipal, provided that the principal (usually the distinguished name) and the juddi publisher ID are the same.
To use this class you must add the following properties to the juddi3v.xml file:
juddi/auth/authenticator/class=org.apache.juddi.auth.LdapSimpleAuthenticator juddi/auth/authenticator/url=ldap://localhost:389 juddi/auth/authenticator/style=simple
The juddi/authenticator/url property configures the LdapSimpleAuthenticator class so that it knows where the LDAP server resides. Future work is planned in this area to use the LDAP uid rather than the LDAP principal as the default publisher id.
LdapExpandedAuthenticator provides a slightly more flexible way to authenticate users via LDAP.
juddi/auth/authenticator/class=org.apache.juddi.v3.auth.LdapSimpleAuthenticator juddi/auth/authenticator/url=ldap://localhost:389 juddi/auth/authenticator/style=simple juddi/auth/authenticator/ldapexp=CN=%s, OU=Users,DC=Domain, etc
Finally is it possible to hook up to third party credential stores. If for example jUDDI is deployed to the JBoss Application server it is possible to hook up to it’s authentication machinery. The JBossAuthenticator class is provided in the docs/examples/auth directory. This class enables jUDDI deployments on JBoss use a server security domain to authenticate users.
|
Tip
|
The JBoss authentication is not distributed with jUDDI. It can be found here: http://svn.apache.org/viewvc/juddi/extras/jbossauthenticator/src/org/apache/juddi/auth/JBossAuthenticator.java?view=markup |
To use this class you must add the following properties to the juddiv3.xml file:
juddi/auth/authenticator/class=org.apache.juddi.auth.JBossAuthenticator juddi/auth/securityDomain=java:/jaas/other
The juddi/auth/authenticator/class property plugs the JbossAuthenticator class into the jUDDI the Authenticator framework. The juddi/sercuityDomain, configures the JBossAuthenticator class where it can lookup the application server’s security domain, which it will use to perform the authentication. Note that JBoss creates one security domain for each application policy element on the $JBOSS_HOME/server/default/conf/login-config.xml file, which gets bound to the server JNDI tree with name java:/jaas/<application-policy-name></application-policy-name>. If a lookup refers to a non existent application policy it defaults to a policy named other.
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.
~~~~~~~~~~~~~~
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.
jarsigner -keystore your.keystore -storepass yourpass -keypass keypass <pathto>/juddi-gui.war/applets/juddi-gui-dsig-all.jar
Note: Jarsigner comes with most JDKs and has many command line options.
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 Status and Statistics of jUDDI
-
Configure jUDDI (juddiv3.war)
-
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. |