JBoss.orgCommunity Documentation

Chapter 4. UDDI Integration

4.1. Overview
4.2. UDDI config properties
4.3. Default configurations
4.4. Other UDDI v3 Registries
4.5. UDDI Registry Entities and UDDI Seed Data

The integration of a UDDI client into the RiftSaw runtime codebase allows for the auto-registration of BPEL services to an UDDI registry upon deployment of the service. The registration process uses the jUDDI-3 client libraries which are capable of communicating to any UDDI v3 complaint registry.

Upon deployment both the Service and its BindingTemplate (EndPoint information) are registered, and a partnerLinkChannel is created for each partnerLink. UDDI lookup will obtain the WSDL Endpoint from the UDDI and access this URL to obtain the WSDL straight from the Service. Upon undeployment the BindingTemplate is removed from the UDDI Registry.

By default RiftSaw uses the jUDDI client libraries of JBossESB/SOA-P, and the client configuration is found in the deploy/jbossesb.saw/esb.juddi.client.xml. Both the name of the ClerkManager and the Clerk itself are specified in the bpel.properties file.

Table 4.1. The UDDI related properties in the bpel.properties

attributetype (default)description
bpel.uddi.registrationboolean (true) If set to 'false', the UDDI integration is turned off. The RiftSaw installation process sets this value to 'true' only if the jbossesb-registry.sar is detected containing a jUDDI v3 registry. In all other case it is defaulted to false.
bpel.webservice.secureboolean (false) The UDDI Registration process registers an WSDL AccessPoint in the BindingTemplate for the BPEL Service it is registering. The BPEL server exposes the service WSDL Endpoint on the WS stack (Currently we support JBossWS and CXF), if your WS stack is configured to a use a secure (https) protocol, then you need to switch this setting to 'true'. Note that this setting is used during the registration process only.
bpel.uddi.client.implString (org.jboss.soa.bpel.uddi.UDDIRegistrationImpl) Name of the a class that implements the org.jboss.soa.bpel.runtime.engine.ode.UDDIRegistration interface. The RiftSaw installation process set this value to org.jboss.soa.bpel.uddi300.UDDI300RegistrationImpl if JBossESB-4.7 is detected. JBossESB-4.7 uses the jUDDI-3.0.0 client libary, while SOA-P-5.0.0 and future version of JBossESB will use jUDDI-3.0.1 or higher and for those it is set to org.jboss.soa.bpel.uddi.UDDIRegistrationImpl.
bpel.uddi.clerk.configString (not used by default) Defines the path to the bpel.uddi.client.xml config file. This can be left commented out if you want to use the jbossesb.sar/esb.uddi.client.xml. However in that case a bpel.uddi.clerk.manager needs to be defined.
bpel.uddi.clerk.managerString (esb-registry) Defines the ClerkManager name that will be used if the bpel.uddi.clerk.config is left commented out. This value should correspond to the name of the manager in the esb.juddi.client.xml. For JBossESB-4.7 this is 'test-manager', while for SOA-P-5.0.0 and newer version of JBossESB it is 'esb-registry'. Note that if the bpel.uddi.clerk.config is defined, the setting of the bpel.uddi.clerk.manager is ignored.
bpel.uddi.clerkString (BPEL_clerk) Defines the Clerk name that will be used. This value should correspond to the name of the clerk in the esb.juddi.client.xml. By default this is set to 'BPEL_clerk'.
bpel.uddi.lookupboolean (false) If set to true, the creating process of the partner channel will do a lookup by serviceName in the UDDI, and a WSDL Endpoint is retrieved. This WSDL Endpoint is the then used to obtain the WSDL. This process makes it easier to move Endpoints around within your deployment, without having to update the partnerlink WSDL files in your bpel deployments. Note that an it is still a requirement to deploy the initial partnerlink WSDL file for each partnerLink.

When RiftSaw is deployed to a JBossAS-5.1.0, jUDDI v3 is not installed, and therefor the UDDI integration is turned off (bpel.uddi.registration=false).

When RiftSaw is deployed to JBossAS-5.1.0 + JBossESB-4.7, the UDDI integration is turned on. By default we use the jUDDI client library which ships with the JBossESB, which is configured in the jbossesb.sar/esb.uddi.client.xml, with manager name 'test-manager'. The bpel.uddi.client.impl is set to org.jboss.soa.bpel.uddi300.UDDI300RegistrationImpl.

When RiftSaw is deployed to SOA-P-5.0.0 (or JBossESB > 4.7) UDDI integration is turned on and the bpel.uddi.client.impl is set to org.jboss.soa.bpel.uddi.UDDIRegistrationImpl. Again the jbossesb.sar/esb.uddi.client.xml is used, with manager name 'esb.registry'.

Other UDDI v3 complaint registries can be used, however the UDDIv3 spec only requires communication using the UDDI WebServices. To set up SOAP based communication specify the JAXWS-Transport. At this point it makes sense to no longer use the the esb.uddi.client.xml, but rather use your own bpel.uddi.client.xml. For more details please see the jUDDI v3 documentain.

In the esb.uddi.client.xml a few properties are defined that are used by the Clerk at registration time. These settings of these values can be customized, however they must correspond to the UDDI seed data specified for the jbossesb publisher, in the jbossesb-registry.sar/juddi_custom_install_data. So you will need to change it there as well.

The clerk is configured to use the jbossesb publisher and the keyDomain is set to "esb.jboss.org".

The businessKey is set to "redhat-jboss".

The serviceDescription is set to "BPEL Service deployed by Riftsaw".

The bindingDescription is set to "BPEL Endpoint deployed by Riftsaw".

Note that in SOA-P-5 the jbossesb-registry.sar/esb.uddi.xml contains a property juddi.seed.always which is set to "true". This means that that it is always trying to load the root seed data on startup of the server. It is recommended to turn this value to "false" once you are content with the UDDI Seed Data.