Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

Chapter 11. Service Registry Integration with the BPEL Engine

11.1. BPEL Engine

A BPEL engine executes BPEL business process instructions. The BPEL engine included as part of the JBoss Enterprise SOA Platform product is based on Apache ODE.

Note

It is recommended that you only open one BPEL console window in your browser. Failing to do so can result in seeing a blank window upon login or being unable to login from your second window. For details, see RIFTSAW-400.

11.2. Business Process Execution Language (BPEL)

Business Process Execution Language (BPEL) is an OASIS-standard language for business rules orchestration. Refer to http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html for more information.

11.3. BPEL and the Service Registry

Because BPEL is integrated with the Service Registry, services can register themselves automatically as they are deployed.
This registration process utilizes the jUDDI client libraries. When a service is deployed, both it and its BindingTemplate (end-point reference) are registered and a partnerLinkChannel is created for each partnerLink. At the same time, the WSDL end-point is obtained from the UDDI.
Upon undeployment, the BindingTemplate is removed from the UDDI Registry.

11.4. Activate BPEL-Service Registry Integration

Procedure 11.1. Task

  • Integration is turned on by default. To confirm this, open vi SOA_ROOT/jboss-as/server/PROFILE/deploy/riftsaw.sar/bpel.properties.xml and ensure that is set as follows: bpel.uddi.registration=true.

11.5. Partner Link

A partner link is a link which establishes a relationship between a BPEL process and its client.

11.7. esb.juddi.client.xml

The SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml file is the client configuration file for the jUDDI Service Registry.

11.8. bpel.properties Configuration Settings

Table 11.1. The UDDI-related properties in the bpel.properties file

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 every other case it is automatically set 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 Red Hat supports JBossWS and CXF). If your webservice stack is configured to use a secure protocol (such as https), 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) This is the 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) This defines the path to the bpel.uddi.client.xml configuration file. This can be left "commented out" if you want to use the riftsaw.sar/META-INF/riftsaw.uddi.xml. In this case, a bpel.uddi.clerk.manager must be defined.
bpel.uddi.clerk.manager String (riftsaw-manager) This defines the name of the ClerkManager that will be used if the riftsaw.uddi.xml is left commented out. This value should correspond to the name of the manager in the esb.juddi.client.xml. Note that if the bpel.uddi.clerk.config is defined, the bpel.uddi.clerk.manager setting is ignored.
bpel.uddi.clerk String (BPEL_clerk) This defines the name of the clerk 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 this is 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 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 than one end-point (BindingTemplate) is found, the default policy used by the ServiceLocator is 'PolicyLocalFirst'. Note that it is still a requirement to deploy the initial partnerlink WSDL file for each partnerLink.

Note

The names of both the ClerkManager and the Clerk itself are specified in the bpel.properties file.

11.9. Clerk

The clerk (org.apache.juddi.v3.client.config.UDDIClerk) is responsible for registering service end-points in the Service Registry.

11.10. Set the Properties to be Used by the Clerk When Registering Services

Procedure 11.2. Task

  1. Open the esb.juddi.client.xml file in your text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml
  2. Configure the settings. For example: 
    </nodes>
   <clerks registerOnStartup="false">
      <clerk name="SOAExample" node="default" publisher="root" password="root"/>
   </clerks>
   </manager>
</uddi>
  3. Save the file and exit.
  4. Put another copy of the file in here (the files must always correspond: SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/
  5. Save the file and exit.

11.11. Default Settings for the Service Registry Clerk

Table 11.2. Default Settings

Property Value
keyDomain esb.jboss.org
businessKey redhat-jboss
serviceDescription BPEL Service deployed by Riftsaw
bindingDescription BPEL Endpoint deployed by Riftsaw

Important

The SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml file contains a property called juddi.seed.always which is set to false. This means that it is always trying to load the root seed data when the server starts.

11.12. UDDI Registration

Upon deployment of a BPEL process, the process information is registered to the UDDI registry according to the BPEL4WS OASIS technote (http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-bpel-20040725.htm).

11.13. UDDI End-Point Look-Up

If a BPEL service invokes another BPEL service (or a web service end-point in general), the BPEL Engine performs a lookup by serviceQName and portName (obtained from the WSDL). The result is stored in a client-side service cache, resulting in increased performance. To prevent the client-side cache from returning "stale" information, the cache is automatically invalidated by the UDDI registry using the Subscription API whenever changes occur in the registry.