Red Hat Training

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

Chapter 7. Advanced BPEL Engine Integration

7.1. Bi-directional Loose Coupling

Bi-directional loose coupling is provided through web services. For example, an ESB action may invoke a BPEL process via a web service. This web service would be represented by a WSDL interface. Likewise, a BPEL process can invoke an ESB-managed service that can present itself as a web service.

7.2. Enterprise Service Bus

An enterprise service bus is a concrete implementation of an abstract SOA design philosophy. An enterprise service bus (ESB) has two roles: it provides message routing functionality and allows you to register services. The enterprise service bus that lies at the center of the JBoss Enterprise SOA Platform is called JBoss ESB.
An enterprise service bus deals with infrastructure logic, not business logic (which is left to higher levels). Data is passed through the enterprise service bus on its way between two or more systems. Message queuing may or may not be involved. The ESB can also pass the data to a transformation engine before passing it to its destination.

7.3. Use the BPELInvoke ESB Action

Prerequisites

  • The BPEL Engine must be installed in the same Java virtual machine as the ESB
  • The requested process must have been deployed to the local BPEL Engine.

Procedure 7.1. Task

  1. Open a jboss-esb.xml file in your text editor.
  2. Add the the BPELInvoke ESB action.
    The following example shows the action being used together with the bpel_esb_helloworld quickstart:
          <action name="action2" class="org.jboss.soa.esb.actions.bpel.BPELInvoke">
        <property name="service" value="{http://www.jboss.org/bpel/examples/wsdl}HelloService"/>
        <property name="port" value="HelloPort" />
        <property name="operation" value="hello" />
        <property name="requestPartName" value="TestPart" />
        <property name="responsePartName" value="TestPart" />
    </action>
    
  3. Save the file and exit.

7.4. BPELInvoke ESB Action Class

The BPELInvoke ESB action class (org.jboss.soa.esb.actions.bpel.BPELInvoke) can be used to call upon the BPEL Engine from within ESB services.

7.5. BPELInvoke ESB Action Class Properties

Table 7.1. Properties

Property Explanation
service
This property is mandatory. It defines the service name registered in the WSDL which is associated with the deployed BPEL process.
port
This property is optional. It defines the name of the port associated with the deployed BPEL process that is registered in the WSDL. This parameter is only required if port-specific end-point configuration information has been registered as part of the BPEL process deployment.
operation
This property is mandatory. It represents the WSDL operation being invoked.
requestPartName
Use this optional property to define the WSDL message part to which the inbound ESB message content should be mapped. Only use this property where the ESB message does not already represent a multi-part message.
responsePartName
Use this optional property to extract the content of a response multi-part WSDL message and place it in the ESB message being passed to the next action in the pipeline. (If this property is not defined, the complete multi-part message value will be placed in the ESB message.)
abortOnFault
Use this optional property to indicate whether a fault generated during the invocation of a BPEL process should be treated as a message (when the value of this property is false) or as an exception that will abort the ESB service. The default value is true, which aborts the service.
This ESB action supports inbound messages. The content of these messages must be defined as one of the following items:

Table 7.2. Properties

Item Explanation
DOM
If the message content is a DOM document or element, it can be used as the complete multi-part message or as the content of a message part. Use the requestPartName property to define it.
Java String
If the message content is a string representation of an XML document, the requestPartName is optional. If not specified, the document must represent the multi-part message.
If the message content is a string that does not represent an XML document, the requestPartName must be specified.
When the message content represents every single part of a multi-part message, it must be defined as a top-level element (which you can name anything). Its child elements must come immediately below it as these represent each part of the message. Each of these child elements must in turn have their own single child element. This element represents the value of the named part.
This is the structure of a multi-part message:
<message>
	<TestPart>
		Hello World
	</TestPart>
</message>
The top element (the message tag) is unimportant. The elements at the next level represent the part names: in this case there is only one, namely TestPart. This part is a text node, in this case called Hello World. (However it could also have been an element representing the root node of a more complex XML value.)

7.6. BPELInvoke and the Action Pipeline

When a WSDL operation is run, a response message will normally be returned from the BPELInvoke action. This message is then placed in the action pipeline ready for processing by the next action. (If no further actions have been defined, it is returned to the service client.)

7.7. Action Pipeline

The action pipeline consists of a list of action classes through which messages are processed. Use it to specify which actions are to be undertaken when processing the message. Actions can transform messages and apply business logic to them. Each action passes the message on to the next one in the pipeline or, at the conclusion of the process, directs it to the end-point listener specified in the ReplyTo address.
The action pipeline works in two stages: normal processing followed by outcome processing. In the first stage, the pipeline calls the process method(s) on each action (by default it is called "process") in sequence until the end of the pipeline has been reached or an error occurs. At this point the pipeline reverses (the second stage) and calls the outcome method on each preceding action (by default it is processException or processSuccess). It starts with the current action (the final one on success or the one which raised the exception) and travels backwards until it has reached the start of the pipeline.