Show Table of Contents
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.
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.xmland ensure that is set as follows:
11.5. Partner Link
A partner link is a link which establishes a relationship between a BPEL process and its client.
11.6. Partner Link Channel
A partner link channel is a communications channel that is used to interact with a client and the services integrated in a BPEL process.
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xmlfile 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
|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.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 |
|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 |
|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.|
The names of both the ClerkManager and the Clerk itself are specified in the
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
- Open the
esb.juddi.client.xmlfile in your text editor:
- Configure the settings. For example:
</nodes> <clerks registerOnStartup="false"> <clerk name="SOAExample" node="default" publisher="root" password="root"/> </clerks> </manager> </uddi>
- Save the file and exit.
- Put another copy of the file in here (the files must always correspond:
- Save the file and exit.
11.11. Default Settings for the Service Registry Clerk
Table 11.2. Default Settings
|serviceDescription||BPEL Service deployed by Riftsaw|
|bindingDescription||BPEL Endpoint deployed by Riftsaw|
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xmlfile 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.