JBoss.orgCommunity Documentation
Table of Contents
The jUDDI Java and .NET clients use an XML configuration file that dictates settings and behaviors. This guide provides an overview of the settings. Both .NET and jUDDI use the same configuration file schema. This schema is located within the source tree and with the client distribution packages of jUDDI.
The root XML node for the jUDDI client configuration file is always "uddi".
<!-- applies to Java clients only --> uddi/reloadDelay
Multiple clients can be defined in each configuration file.
uddi/client@name="someName"
At least one node is required per client. A node represents a one logical UDDI server (or cluster of servers). Each UDDI node should host at least the inquiry service. A client using the jUDDI client package can be configured to access multiple nodes at the same time.
<!-- if isHomeJUDDI is true, then this node is loaded by default, when no node is specified in client code --> uddi/client/nodes[]/node@isHomeJUDDI=true/false <!-- the name of the node is referenced in client code --> uddi/client/nodes[]/node/name <!-- the description of the node --> uddi/client/nodes[]/node/description <!-- the properties section defines HTTP style credentials and a runtime tokenizer for URLs --> uddi/client/nodes[]/node/properties <!-- The transport represents the class name of the transport mechanism that the client will use to connect to the UDDI node. The most commonly used is org.apache.juddi.v3.client.transport.JAXWSTransport, however RMITransport, InVMTransport and JAXWSv2TranslationTransport are also defined --> uddi/client/nodes[]/node/proxyTransport <!-- endpoint URLs --> uddi/client/nodes[]/node/custodyTransferUrl uddi/client/nodes[]/node/inquiryUrl uddi/client/nodes[]/node/publishUrl uddi/client/nodes[]/node/securityUrl uddi/client/nodes[]/node/subscriptionUrl uddi/client/nodes[]/node/subscriptionListenerUrl <!-- note: this is for jUDDI v3.x servers only and is not part of the UDDI standard --> uddi/client/nodes[]/node/juddiApiUrl
The Proxy Transport defines which mechanism is used for on the wire transport of the UDDI XML messages. JAXWS Transport is the most commonly used and assumes SOAP messaging protocol over HTTP transport layer.
RMI Transport using the Java Remote Method Invocation for transport. It’s more commonly used for communicating within a J2EE container, but could be used in other cases. It’s not required by the UDDI specification and is considered a jUDDI add on.
InVM Transport is for hosting jUDDI services without a J2EE container.
JAXWSv2TranslationTransport is a bridge for accessing UDDIv2 web services using the UDDIv3 data structures and APIs. Only the Inquiry and Publish services are required and they must point to SOAP/HTTP endpoints for a UDDI v2 node.
Clerks are responsible for mapping stored user credentials to a Node and for automated registration.
<!-- if true, the contents of the child node xregister are registered when the UDDIClient object is created, using the credential and node reference.--> uddi/client/clerks/registerOnStartup=true/false
Clerks store credentials and map to a specific node.
<!-- the name is a reference to the Node that these credentials apply to--> uddi/client/clerks[]/clerk@node - This is reference to uddi/client/node/name, it must exist uddi/client/clerks[]/clerk@name - This is a unique identifier of the clerk uddi/client/clerks[]/clerk@publisher - This is the username uddi/client/clerks[]/clerk@password uddi/client/clerks[]/clerk@isPasswordEncrypted=true/false uddi/client/clerks[]/clerk@cryptoProvider=(see Crypto providers)
Credentials can be encrypted using the included batch/bash scripts and then appended to the configuration. Example with encryption:
<clerk name="default" node="default" publisher="root" password="(cipher text removed)"
isPasswordEncrypted="true" cryptoProvider="org.apache.juddi.v3.client.cryptor.AES128Cryptor" />Clerks also have settings for the automated cross registration of Businesses and Services on start up.
uddi/client/clerks[]/xregister/service@bindingKey uddi/client/clerks[]/xregister/service@fromClerk uddi/client/clerks[]/xregister/service@toClerk
The Signature section contains settings that map to the Digital Signature Utility that makes working with UDDI digital signatures simple. The section contains all of the settings for both signing and validating signatures.
uddi/client/signature/signingKeyStorePath uddi/client/signature/signingKeyStoreFilePassword uddi/client/signature/signingKeyStoreFilePassword@isPasswordEncrypted uddi/client/signature/signingKeyStoreFilePassword@cryptoProvider uddi/client/signature/signingKeyPassword uddi/client/signature/signingKeyPassword@isPasswordEncrypted uddi/client/signature/signingKeyPassword@cryptoProvider uddi/client/signature/signingKeyAlias uddi/client/signature/canonicalizationMethod uddi/client/signature/signatureMethod=(default RSA_SHA1) uddi/client/signature/XML_DIGSIG_NS=(default http://www.w3.org/2000/09/xmldsig#) uddi/client/signature/trustStorePath uddi/client/signature/trustStoreType uddi/client/signature/trustStorePassword uddi/client/signature/trustStorePassword@isPasswordEncrypted uddi/client/signature/trustStorePassword@cryptoProvider <!-- checks signing certificates for timestamp validity --> uddi/client/signature/checkTimestamps <!-- checks signing certificates for trust worthiness --> uddi/client/signature/checkTrust <!-- checks signing certificates for revocation --> uddi/client/signature/checkRevocationCRL uddi/client/signature/keyInfoInclusionSubjectDN uddi/client/signature/keyInfoInclusionSerial uddi/client/signature/keyInfoInclusionBase64PublicKey <!-- default is http://www.w3.org/2000/09/xmldsig#sha1 --> uddi/client/signature/digestMethod
The subscriptionCallbacks section defines settings uses by the subscription callback API. This enables developers to create capabilities that need to be notified immediately when something in UDDI changes through the use of subscriptions.
uddi/client/subscriptionCallbacks/keyDomain uddi/client/subscriptionCallbacks/listenUrl this is the URL that is used for callbacks, should be externally resolvable uddi/client/subscriptionCallbacks/autoRegisterBindingTemplate=true/false uddi/client/subscriptionCallbacks/autoRegisterBusinessServiceKey=(key) append callback endpoint to this service uddi/client/subscriptionCallbacks/signatureBehavior=(AbortIfSigned,Sign,DoNothing,SignOnlyIfParentIsntSigned), default DoNothing. Applies when auto registering the endpoint to a business or service that is already signed.
XtoWsdl represents configuration parameters for importing WSDL or WADL files. Currently, the only setting is for ignoring SSL errors when fetching remote WSDL or WADL files.
uddi/client/XtoWsdl/IgnoreSSLErrors=true or false
jUDDI has the ability to run in embedded mode. This means that the jUDDI services can operate without a web servlet container, such as Tomcat or JBoss. Typically, this is something that application developers would use for more advanced scenarios and for operation without network connectivity.
A database server, if one is not available, the embedded Derby engine can be used.
<!-- In VM Transport Settings --> <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>
See also the hello-world-embedded example.