JBoss.orgCommunity Documentation
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.sar/esb.juddi.client.xml. Both the name of the ClerkManager and the Clerk itself are specified in the bpel.properties file.
Table 5.1. The UDDI related properties in the bpel.properties
| attribute | type (default) | description |
|---|---|---|
| bpel.uddi.registration | boolean (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.secure | boolean (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.impl | String (org.jboss.soa.bpel.uddi.UDDIRegistrationImpl) | Name of the class that implements the org.jboss.soa.bpel.runtime.engine.ode.UDDIRegistration interface. |
| bpel.uddi.clerk.config | String (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 riftsaw.sar/META-INF/riftsaw.uddi.xml. However in that case a
bpel.uddi.clerk.manager needs to be defined.
|
| bpel.uddi.clerk.manager | String (riftsaw-manager) |
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 riftsaw.uddi.xml. Note that if the bpel.uddi.clerk.config is defined, the
setting of the bpel.uddi.clerk.manager is ignored.
|
| bpel.uddi.clerk | String (BPEL_clerk) |
Defines the Clerk name that will be used. This value should correspond to the name of the clerk
in the riftsaw.uddi.xml. By default this is set to 'BPEL_clerk'.
|
| bpel.uddi.lookup | boolean (true) | If set to true, the creating process of the partner channel will do a lookup by serviceName in the UDDI, and Endpoint(s) is retrieved. This process makes it easier to move process deployment around within your server farm, without having to update the partnerlink WSDL files in your BPEL process deployments. If more then one EndPoint (BindingTemplate) is found default policy the ServiceLocator uses a 'PolicyLocalFirst'. Please see the jUDDI v3 documentation for more details and on how to switch to the 'PolicyRoundRobin' or a custom Policy. Note that it is still a requirement to deploy the initial partnerlink WSDL file for each partnerLink. |
When RiftSaw is deployed to JBossAS-5.1.0, jUDDI v3 is not installed, and therefore the UDDI integration is turned off (bpel.uddi.registration=false).
When RiftSaw is deployed to SOA-P-5.1.0 (or JBossESB 4.10 or higher) UDDI integration is
turned on and the bpel.uddi.client.impl is set to
org.jboss.soa.bpel.uddi.UDDIRegistrationImpl.
The riftsaw.sar/META-INF/riftsaw.uddi.xml is used, with manager name 'riftsaw-manager'.
The jUDDI registry is seeded with initial setup data. The riftsaw install process adds 3
seed files to the jbossesb-registry.sar/juddi_custom_install_data directory. The
files are riftsaw_Publisher.xml, riftsaw_BusinessEntity and riftsaw_tModels.
The seed data is loaded only if the registry is empty. Thus if you had already started jboss-esb before
installing riftsaw, you will need to clean the jUDDI database to trigger the loading of the newly added
seed data, or you can add the entities manually before starting riftsaw. Alternatively, in SOA-P-5.x, the
jbossesb-registry.sar/esb.juddi.xml contains a property
juddi.seed.always which can be 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.
Upon deployment of a BPEL process, the process information is registered to the UDDI registry according to the BPEL4WS OASIS technote (Using BPEL4WS in a UDDI registry Technote). For more details please see the jUDDI v3 documentation.
If a BPEL service invokes another BPEL service or WebService EndPoint in general, Riftsaw performs a lookup by serviceQName and portName (obtained from the WSDL). The result is stored in a client-side ServiceCache. This ensures that the lookup is nice and fast. To prevent the client-side cache to return stale information, the cache is automatically invalidated by the UDDI registry using the Subscription API whenever changes occur in the registry. For more details please see the jUDDI v3 documentation.
Other UDDI v3 compliant registries can be used. The UDDIv3 spec requires
communication using the UDDI WebServices (rather than the InVM Transport used by default).
To set up SOAP based communication specify the JAXWS-Transport,
in the riftsaw.sar/META-INF/riftsaw.uddi.xml configuration
file. Note that when using JAXWS-Transport the UDDI server should be hosted out-of-process, as it must
be up during server startup and shutdown. For more details please see the jUDDI v3 documentation.