|
The following topics describe the BPEL Service Engine.
About the BPEL Service Engine
Engine Features
BPEL SE Runtime Properties
BPEL SE Deployment Artifacts
BPEL BluePrint Projects
BPEL Language Constructs
About the BPEL Service Engine
The BPEL Service Engine (SE) is a JSR 208-compliant JBI runtime component
that provides services for executing WS-BPEL 2.0 (or simply BPEL) compliant
business processes. WS-BPEL 2.0 (Web Services Business Process Execution
Language) is an XML-based language used to program business processes.
Business processes typically involve the exchange of messages between
the process and other web services known as partner services (hence
the term: web service orchestration). The contract between a business
process and partner services is described in WSDL 1.1. The Message exchange
between a business process and partner services is wrapped in the WSDL
1.1 message wrapper, as defined by the JBI specification, and routed
via the JBI-NMR (Normalized Message Router). The NMR interacts with
external web services, not resident on the local JVM, via binding components.
Binding components are responsible for encapsulating protocol specific
details. Transactions between BPEL SE and collocated EJBs or Web Components
are handled through the Java EE Service Engine.
WS-BPEL 2.0 utilizes several XML specifications: WSDL 1.1, XML Schema
1.0, XPath 1.0, and XSLT 1.0. Note that the JBI specification is targeted
toward WSDL 2.0 and accommodates WSDL 1.1 by defining the wrapper.
The BPEL Service Engine supports one-way, request-response operations
(as defined in WSDL 1.1), within stateful, long-running interactions
that involve two or more parties. Asynchronous request-response is accomplished
using two one-way operations, one implemented by a partner, the other
implemented by the business process using message correlation as defined in WS-BPEL 2.0.
For further information, see WS-BPEL 2.0.
The BPEL Editor provides an easy-to-use interface that allows you to
build or edit your BPEL Project, deploy your project to the BPEL Service
Engine, and test BPEL services. The BPEL Service Engine implements most WS-BPEL language
constructs defined in WS-BPEL 2.0. Language constructs not implemented by the BPEL Service Engine are those that are rarely used. Refer to BPEL 2.0 Constructs for a list of the supported constructs.
The BPEL SE also offers a command-line interface for building a Service
Assembly and testing the deployed service.
The BPEL Service Engine is included with the Java EE 5 SDK. The Java EE 5 SDK includes the JBI Runtime, which includes the BPEL Service Engine and an HTTP/SOAP binding Conponent. Several download options are available from the Java EE 5 SDK download page, including options to download the Java EE 5 SDK with NetBeans tools.
http://java.sun.com/javaee/downloads/index.jsp
top
Engine Features
Following are technical details of the BPEL SE:
- Standard JBI 1.0 engine component
- Supports BPEL 2.0. Refer to BPEL 2.0 Constructs for a list of the supported constructs.
- Provides and consumes web services defined by using WSDL 1.1
- Exchanges messages in JBI-defined XML document format for wrapped
WSDL 1.1 message parts
- Can be configured in these modes: static, deployment, and runtime
- Implements endpoint status monitoring
- Supports multiple-thread execution
top
BPEL SE Runtime Properties
The BPEL SE is included with the NetBeansTM 5.5 Enterprise Pack. Changes to the BPEL SE runtime properties are made from within NetBeans IDE.
Starting the Application Server
Configuration of BPEL SE runtime properties requires first starting
the Sun Java System Application Server in the NetBeans window.
- Click the Runtime tab.
- Right-click the Sun Java System Application Server and click Start.
Displaying the Runtime Properties
Once the application server is started, the BPEL SE runtime properties
can be accessed.
- Expand the Sun Java System Application Server link, and then expand
the JBI > Service Engines links.
- Right-click com.sun.bpelse-1.0.2, and click Properties.
- The com.sun.bpelse-1.0.2 properties window appears.
Runtime Property Descriptions
The following table includes descriptions for the BPEL SE properties.
| Property Name |
Description |
Default Value |
| DB_JNDIName |
Used to configure a database that captures persistance of the BPEL conversation state. This property only applies if PersistenceEnabled is set to true. For more information, see PersistenceEnabled. |
jdbc/__default |
| DB_Password |
Used to configure a database that captures persistance of the BPEL conversation state. This property only applies if PersistenceEnabled is set to true. For more information, see PersistenceEnabled. |
pass2 |
| DB_Type |
Used to configure a database that captures persistance of the BPEL conversation state. This property only applies if PersistenceEnabled is set to true. For more information, see PersistenceEnabled.
|
4 |
| DB_URL |
Used to configure a database that captures persistance of the BPEL conversation state. This property only applies if PersistenceEnabled is set to true. For more information, see PersistenceEnabled. |
jdbc:derby://localhost:1527/derbyDB |
| DB_UserName |
Used to configure a database that captures persistance of the BPEL conversation state. This property only applies if PersistenceEnabled is set to true. For more information, see PersistenceEnabled. |
usr2 |
| DebugEnabled |
When set to true, you can attach a debugger to debug the business process definition. |
false |
| DebugPort |
Specifies the port number
at which the debug server listener listens for the debugger UI
to connect. The default value is sufficient for most cases.
Make sure that this port is not used by other applications. If
you are running more than one instance of BPEL SE on this computer,
make sure that you assign non conflicting unique ports.
|
3343 |
| Description |
Description of the JBI Component. |
This is a bpel service engine. |
| MaxThreadCount |
An integer that specifies
the number of threads executing BPEL definitions. This is the
number of computers needed for maximum throughput.
Note that you must set associated BCs with same number of threads.
This combination is the optimal configuration for most cases. |
10 |
| Name |
Name of the JBI Component. Specifies a unique name in the JBI
environment.
If you are installing more than one BPEL SE in a JBI environment,
make sure that each BPEL SE is unique. This can be changed in the descriptor
(jbi.xml) for the component. When the SU deploys the component,
it is matched with the target component name defined in the component's descriptor
– jbi.xml. |
com.sun.bpelse-1.0.2 |
| PersistenceEnabled |
When set to true,
the BPEL conversation state is persisted to a database that is configured
using the DB parameters (DB_JNDIName, DB_Password, DB_Type, DB_URL,
DB_ UserName).
In case of a crash or scheduled shutdown, when the engine is
restarted it can continue from the state before the
crash or shutdown occurred.
|
false |
| State |
State of the JBI Component. Start, Stop, or Shutdown. |
Started |
| Type |
Type of the JBI Component. SE (for BPEL SE) or BC |
SE |
BPEL SE Deployment Artifacts
The BPEL SE requires the following artifacts to execute a business
process:
- BPEL documents that define the activity sequence to execute
- WSDL documents that describe the contract between the business
process and partner services
- XSDL that define the documents to be exchanged.
These artifacts are packaged into a Service Unit (SU), and in
turn packaged into the Service Assembly (SA), along with other JBI
component's SUs, based on the internal and external partner services
requirements.
SAs and SUs can be deployed to JBI runtime and corresponding components
using ANT scripts provided with the JBI runtime or by using the Netbeans 5.5 Enterprise Pack
IDE. The JBI DeploymentServiceMBean interprets
the deployment descriptor, jbi.xml, and deploys the SU to the associated
component.
top
BPEL BluePrint Projects
BPEL BluePrint Projects are developed to teach and promote good practices
in developing business process. Together they present solutions for
developing composite business processes that logically combine, orchestrate,
and consume web services.
The BPEL BluePrint Projects are:
- BPEL BluePrint 1: Synchronous Web Service Interactions Using BPEL
- BPEL BluePrint 2: Asynchronous Web Service Interactions Using BPEL
- BPEL BluePrint 3: Fault Handling Using BPEL
- BPEL BluePrint 4: Message-Based Coordination of Events Using BPEL
- BPEL BluePrint 5: Concurrent Asynchronous Coordination of Events
Using BPEL
BPEL BluePrints are located at:
https://blueprints.dev.java.net/bpcatalog/ee5/soa/index.html
BPEL 2.0 Language Constructs
The following table lists the supported and non-supported BPEL 2.0
language constructs.
| Feature |
Description |
| <variables> |
For messages or intermediate data.
Supports:
Variables of WSDL message and XML schema
* messageType
* type
* element
Does not support:
* from-spec
|
| <invoke> |
Invokes operations on web services provided by partners
Supports:
* asynchronous one-way invoke
* synchronous request-reply invoke
* fault handling
* correlation
* virtual assign: fromPart and toPart
Does not support:
* compensation handler
* suppressJoinFailure
* targets/sources
|
| <receive>/<reply> |
Business processes use receive activities and corresponding
reply activities to provide web services to partners
Supports:
* association between Receive and Reply activities done by using
MessageExchange attribute
* start activity
* variable
* correlation
* indicating fault in Reply
* virtual assign: fromPart and toPart
Does not support:
* targets/sources |
| <assign> |
Supports:
* <from variable="ncname" part="ncname"?/>
* <from> <expression>general-expr</expression>
</from>
* <from> <literal> ... literal value ... </literal>
</from>
* <to variable="ncname" part="ncname"?/>
* <to queryLanguage="anyURI"?>query</to>
Does not support:
* <from partnerLink="ncname" endpointReference="myRole|partnerRole"/>
* <from variable="ncname" property="qname"/>
* <to partnerLink="ncname"/>
* <to variable="ncname" property="qname"/>
* <copy keepSrcElementName="yes|no"?>: keepSrcElementName
attribute is not supported.
* <assign validate="yes|no"?>: validate is not
supported.
* atomic assign
* bpel standard faults.
* bpel:doXslTransform
* bpel:getVariableProperty
* expressionLanguage is limited to XPATH 1.0 |
| Signaling faults: <throw> |
Throw activity is supported, but does not support:
* targets/sources |
| <faultHandlers> |
Supports:
* Handling faults at Process and Scope level
* Handling faults caused by invoke and throw
* Handling faults with associated data defined using WSDL Message
types
* Handlings faults generated within fault handlers
* Default fault handling behavior – rethrowing unhandled faults
to an enclosing scope
Does not support or has partial support for:
* Handling faults at Invoke level
* Generating and handling standard faults
* Handling and sending server faults - faults not defined on the
WSDL operation.
Server faults caused due to invoke can be caught using CatchAll.
Faults not
handled within the business process are sent to the caller with
an XML message.
A standardized way of communicating and catching these faults
is not supported.
* Support for <rethrow>
* Handling faults with associated data defined using XML Elements
* Access and scoping of the fault variables
* Termination semantics for a scope in which fault occurs
* Handling faults generated within other handlers, event handlers,
compensation handlers, or termination handlers
* Default compensation handling behavior.
|
| <wait> |
Wait activity is supported, but does not support:
* targets/sources
* expressionLanguage |
| <empty> |
Empty activity is supported, but does not support:
* targets/sources |
| <exit> |
Exit activity is supported, but does not support:
* targets/sources |
| <sequence> |
Sequence activity is supported, but does not support:
* targets/sources |
| <if> |
If activity is supported, but does not support:
* targets/sources
* expressionLanguage |
| <while> |
While activity is supported, but does not support:
* targets/sources
* expressionLanguage |
| <pick> |
Supports:
* Pick used as start activity
* association of onMessage by using messageExchange
* onMessage variable
* onMessage correlation
* onMessage virtual assign: fromPart
* onAlarm
Does not support:
* targets/sources |
| <flow> |
Flow activity provides synchronization and concurrency.
Supports:
* concurrency
does not support
* links
* targets/sources |
| <sequence> |
Supports:
* variable
* fault handler
* event handler
* partnerLink
* correlation
Does not support:
* compensation handler
* termination handler
* targets/sources |
| <correlationSets>/<correlations> |
Supports:
* Receive as initiating activity and/or correlating activity
* correlated Receive within Flow
* correlated Invoke within Flow
* correlated Invoke within While
* Invoke correlation attribute pattern: in, out, out-in
* correlated Reply within Flow
* onMessage as initiating activity and/or correlating activity
* correlated onMessage within Flow
* recycling correlation at process level
* In flow, with multiple initiating activities with createInstance
"yes", all those
multiple initiating activities should use only "join"
initiate flag
Does not support:
* correlations defined on Scope and their usage
* correlated Receive within While
* correlated Reply within While
* correlated onMessage within While
* request time out
* duplicating operations |
| <forEach> |
Supports:
* ForEach parallel="no"
* CompleteCondition
* countCompletedBranchesOnly="yes|no"
Does not support:
* ForEach parallel="yes"
* targets/sources
* Throw standard faults |
| <repeatUntil> |
RepeatUntil activity is supported, but
Does not support:
* targets/sources
* expressionLanguage |
<eventHandlers>
|
Supports:
* On Process level
* On Scope level
* OnEvent
* OnAlarm
* OnAlarm with RepeatedEveery
Does not support:
* Fault handling
* Throw standard faults |
top
|