BPEL process context
This diagram shows the overall process deployment of a bpel process.
The picture shows the context for one process. Of course the bpel
engine should support multiple processes. The wsdls (PortType's) are
referenced from the bpel process definition.
At runtime the container is responsible for publishing the web-service
endpoints for sending messages to process instances. These endpoints are
bound to a process definition. So when a message arrives at such an endpoint,
the first thing that needs to be done is figure out to which process
instance this message needs to be routed. This covered by message correlation.
A property specifies a data-item in an message with e.g. an XPath expression.
A correlation set is a set of properties that indicate how incoming messages
are related to process instances.
BPEL process
Apart from some decorations such as variables, correlation sets, fault handlers,
compensation handlers and event handlers, the essence of a BPEL process is its
activity. The activity is a program with instructions and control structures like
a very basic programming language.
BPEL partner
A BPEL process definition refers to external actors as partners. The interactions
between partners and the process are expressed in WSDL (PortType). So the target
environment for this specification is an environment where the complete architecture
is standardized on web services. Note that it is possible to bind WSDL to in-JVM
method calls. But regrettably this is waaaay inefficient. For a method call like
e.g. partnerIf.send( invoice ); you would have to specify the WSDL and
perform binding it at runtime.
BPEL activities
Activities are modeled as a composite patterns which means that
the top level activity most likely is a structured activity. Structured activities
contain other activities. Basic activities are just operations. The activities
of BPEL form the analogue of a programming language. The structured activities
are used for control flow, the basic acitivies are operations.
Translating BPEL processes
During this analysis it has become clear that it is possible to implement
a bpel workflow engine on the basis of the nwsp architecture.
A bpel process definition will be translated into a nwsp process definition.
The bpel activities will be translated into a mix of nwsp states and observers.
Since bpel is a block-structured process language and the proposed model has a
free-flow graph structure, translation is rather straightforward.
See also From UML to BPEL - Model Driven Architecture in a Web services world
Basic bpel activities
receive --> state
wait --> state or milestone
reply --> observer that invokes a webservice
invoke --> observer that invokes a webservice
throw --> observer that manipulates the state of the process instance
empty --> no translation necessary
assign --> observer that stores signal-data into a variable
terminate --> observer that cancels the process instance
Structured bpel activities
flow --> fork & join
sequence --> sequence of states or observers
switch --> decision
pick --> state with multiple leaving transitions
while --> decision at end of block with a loopback transition
BPEL Links
BPEL Cookbook Sample Chapter
[ Building Rich Internet Applications for Workflow and Process Monitoring
|http://www.packtpub.com/files/BPELSOA_SampleChapter.pdf]
BPEL Tutorial
BPEL intellectual property and licensing
Referenced by:
Comments