A university for the world real R © 2009, YAWL and its Support Environment Alessandro Russo [email protected] based on the
Embed Size (px)
Citation preview
YAWL and Its Support EnvironmentWil van der Aalst
XPDL
BPEL
BPMN
EPCs
Yet Another Workflow Language
Defined by Wil van der Aalst and Arthur ter Hofstede in 2002
Intention: to provide comprehensive support for the workflow
patterns
Inspired by Workflow Nets, but with direct support for
Cancelation
Multiple executions of the same task in the same process
instance
Synchronization of active paths only (OR-join)
Formal semantics
Lack of commonly accepted conceptual foundations
Lack of proper formal foundations
No lack of proposed standards…
Tools are typically hard to use, expensive and not easily
integrated
Lack of support for processes that need to change on-the-fly
Lack of proper support for exceptions
Limited support for design time analysis (verification and
validation)
Resource perspective does not match real-world needs
Insufficient support for inter-process communication
Workflow Patterns Initiative ( www.workflowpatterns.com )
Joint initiative by Eindhoven University of Technology (TU/e, the
Netherlands) and Queensland University of Technology (QUT,
Australia) started in 1999
Aims to address lack of commonly accepted foundation for workflow
management
WfMC’s proposal lacked precision and expressiveness
This foundation provides:
Patterns-based approach
Technology independent
Description, motivation, issues, solutions
Three point evaluation scale (full support ‘+’, partial support or
workaround ’+/–’, no support ‘–’)
a university for the
Objectives
identify workflow modelling scenarios and solutions
delineate the fundamental requirements that arise during business
process modelling on a recurring basis and describe them in an
imperative way
provide foundations for evaluating and selecting workflow solutions
(benchmarking model)
Results
a set of patterns that provide a comprehensive analysis of
the
various perspectives (control flow, data, resource, and exception
handling) that need to be supported by a process modelling
language
evaluations of commercial offerings, research prototypes, proposed
standards for web service composition, etc
Usage
examining the suitability of a particular process language or
workflow system for a particular project
assess relative strengths and weaknesses of various approaches for
process specification
basis for language and tool development
a university for the
Implementation: how typically realised?
Issues: what problems can be encountered?
Solutions: how and to what extent can these problems be
overcome?
Evaluation criteria
Product Evaluation
* D. Riehle and H. Züllighoven. Understanding and Using Patterns in
Software Development. Theory and Practice of Object Systems
2(1):3-13, 1996.
Abstraction from concrete form which keeps recurring in specific,
non-arbitrary contexts*
In process context:
Imperative in format
Motivated
Solution-oriented
Identify
patterns
Assess pattern support
selection, design and development of
workflow systems and process modeling languages
control flow (43)
Control-flow and Data Perspectives
Control-flow perspective (43 patterns)
Describes the structure of a process in terms of tasks and the
relationships between them defining the overall flow of
control
focuses on the representation and execution of processes in terms
of tasks and arcs indicating how the thread of control is passed
between them
Abstracts from the actual implementation of individual tasks
Data perspective (40 patterns)
Describes data elements consumed, produced and exchanged during
process executions
focuses on the representation and utilisation of data in a process
context
Considers both internal and external data resources and the
interactions between them
a university for the
Resource perspective (43 patterns)
Describes the operational and organizational context for process
execution in terms of
resources (i.e., people, systems and services able to execute
tasks) and their capabilities (i.e., any qualification, skill,
equipment, property etc. relevant for task assignment and
execution)
policies and rules used to assign tasks to resources for
execution
Focuses on the manner in which work is offered to, allocated to and
managed by process participants
Assumes the existence of a process model and related organisational
and work distribution models
Exception Handling perspective (not covered in these slides)
Describes the approaches to be used to deal with undesirable events
that may arise
a university for the
Concurrency Patterns
reflect situations where restrictions are imposed on the extent of
concurrent control-flow in a process instance
Trigger Patterns
catalogue the different triggering mechanisms appearing in a
process context
Cancellation and Completion Patterns
categorise the various cancellation scenarios that may be relevant
for a workflow specification
Termination Patterns
address the issue of when the execution of a workflow is considered
to be finished
Branching Patterns
Synchronisation Patterns
Repetition Patterns
describe various ways in which repetition may be specified (loops,
recursion, …)
Multiple Instances (MI) Patterns
delineate situations with multiple threads of execution in a
workflow which relate to the same activity
OR Split
Multi-choice, thread of control is passed to one or more outgoing
branches
XOR Split
Exclusive choice, thread of control is passed to exactly one of the
outgoing branches (choice made by the system, based on data)
Deferred choice, thread of control is passed to exactly one of the
outgoing branches. Selection decision is deferred to the user
and/or operating environment.
Thread Split
*
© 2009, www.yawlfoundation.org
Data Visibility
the extent and manner in which data elements can be viewed and
utilised by workflow components
Internal Data Interaction
External Data Interaction
workflow and the external operating environment
Data Transfer
data element transfer across the interface of a workflow
component
Data Routing
the manner in which data elements can influence the operation of
the workflow
Single integrated control-flow and data channel
Synchronous passing of control-flow and data between preceding and
subsequent task(s)
Data passing approach used by YAWL and BPEL
*
Distinct Control and Data Channels
Different control-flow and data channel
Timing considerations in order to ensure both control-flow and data
arrive at tasks at the required time
*
No explicit data passing
Data elements held in global data store and used by tasks when
required
*
A
C
D
Creation patterns
design-time work allocation directives (which resources may execute
a work item at runtime)
Push patterns
Pull patterns
Detour patterns
created
Main Creation Patterns
Design time considerations relating to which resources may execute
a work item at runtime
Direct Allocation
The ability to directly specify at design time the identity of the
resource that will execute a task
Role-based Allocation
The ability to specify at design time that a task can only be
executed by resources which correspond to a given role
Capability-based Allocation
The ability to offer or allocate instances of a task to resources
based on specific capabilities that they possess
a university for the
Main Push Patterns
Correspond to situations where newly created work items are
proactively routed to resources by the workflow system
Key dimensions:
Timing of distribution vs enablement
Distribution by Offer – Single/Multiple Resource(s)
The ability to offer a work item to a selected resource or to a
group of selected resources
Distribution by Allocation – Single Resource
The ability to allocate a work item to a selected resource
a university for the
Correspond to situations where a resource proactively seeks
information on available work and commits to undertaking specific
work items
Key dimensions
Resource-Initiated Allocation
The ability for a resource to commit to undertake a work item
without needing to commence working on it immediately
The work item is considered to be allocated to the resource and it
cannot be allocated to or executed by another resource
Resource-Initiated Execution – Allocated/Offered Work Item
The ability for a resource to commence (start) a work item
previously allocated/offered to him/her
a university for the
YAWL Highlights
original control-flow patterns*, resource patterns, and exception
handling patterns
not through a “construct-per-pattern” approach as in BPMN
considered the most powerful process specification language for
capturing control-flow dependencies and resourcing
requirements
Extends Workflow Nets
latest definition: CPN (Colored Petri nets) interpreter
this removes ambiguity and provides opportunities for
verification
Sophisticated verification support
Sophisticated flexibility support
a university for the
The General Synchronising Merge
Patterns involving Multiple Instances
Cancellation of a certain part of a process
For the Control Flow Perspective, YAWL takes some concepts from
Petri/Workflow nets and adds constructs for:
OR-join to deal with General Synchronising Merge
Multiple Instance (MI) tasks
a university for the
The Input condition is where a process starts
The Output condition is where a process ends
The Atomic task represents a single task to be performed by a human
or an external application
The Condition represents a state for the process
The AND-split activates all outgoing links from this task upon
completion
The AND-join activates this task when all incoming links have been
activated
a university for the
YAWL Language Lexicon (2/3)
The OR-split activates a number of outgoing links from this task
upon completion
The OR-join activates this task when one or more incoming links are
activated and there is no possibility for other links to be
activated if the task continues to wait
The XOR-split activates one outgoing link from this task upon
completion
The XOR-join activates this task each time an incoming link has
been activated
a university for the
YAWL Language Lexicon (3/3)
The Composite task is a container for another YAWL process, and as
such provides a decomposition mechanisms
The Multiple Instance task allows multiple instances of a task to
run concurrently. The min and max number of instances, the
threshold for completion and whether new instances can be created
on the fly or not can be specified
In a Cancellation Region, all elements (from single tasks up to
whole processes) within the dotted region are deactivated upon task
activation
Basic Control-flow Patterns in YAWL (1/2)
Sequence: Task B follows task A.
Parallel Split: Task B, task C and task D are executed in parallel
after task A.
Synchronisation: After the execution of task B, task C, and task D,
task E can be executed.
AND-split
AND-join
Basic Control-flow Patterns in YAWL (2/2)
Exclusive Choice: A choice is made to execute either task B, task C
or task D after execution of task A.
Note that such a choice typically involves predicates specified for
the various arcs. Currently such conditions are specified in
XPath.
Simple Merge: Task A will be started when any one of the tasks B, C
or D completes.
This solution is identical to the solution for the Multiple Merge.
This pattern though makes a context assumption: there is no
parallelism preceding task A.
XOR-split
XOR-join
Some Other Patterns in YAWL (1/2)
Multiple Choice: Task B, task C, task D or any combination thereof
is executed after task A
Note that such a choice typically involves predicates for the
various arcs. Currently such conditions are specified in
XPath.
Synchronising Merge: Task A can execute when at least one of the
tasks B, C, or D has completed and there is no possibility of
another incoming branch becoming active in the foreseeable future,
given the current state of the workflow.
OR-split
OR-join
Some Other Patterns in YAWL (2/2)
Deferred Choice: After task A, both tasks B and C are enabled. When
one of them is selected for execution, the other one is
disabled.
Multiple Instances With a Priori Design Time Knowledge: After task
A, n instances of task B are created. When all such created
instances are completed, task C can start.
Source and other patterns
Example: Applying for a Credit Card
Consider a credit card application process.The credit application
process starts when an applicant submits an application (with the
proposed amount). Upon receiving an application, a credit clerk
checks whether it is complete. If not, the clerk requests
additional information and waits until this information is received
before proceeding. For a complete application, the clerk performs
further checks to validate the applicant's income and credit
history. Different checks are performed depending on whether the
requested loan is large (e.g. greater than €500) or small. The
validated application is then passed on to a manager to decide
whether to accept or reject the application. In the case of
acceptance, the applicant is notified of the decision and a credit
card is produced and delivered to the applicant. For a rejected
application, the applicant is notified of the decision and the
process ends.
a university for the
Overview of the Data Perspective in YAWL
The data patterns were finalized after the initial data perspective
for YAWL was developed
the data perspective in YAWL is not based on a comprehensive
analysis of the data patterns
The data perspective in YAWL relies on XML technology
Data Representation and Validation: XML Schema
Data Transfer and Transformations: XQuery
Decision making (data-based conditional routing): XPath
a university for the
Data elements are stored in variables; there are:
net variables for storing data that need to be accessed and/or
updated by tasks in a net
task variables for storing data that needs to be accessed and/or
updated only within the context of individual execution instances
of a task
YAWL applies strong data typing
data types are defined using XML Schema
46 XML Schema simple data types for variable definition (boolean,
string, double, etc.)
the users can also supply their own XML Schema to define more
complex data types
a university for the
The data inside of YAWL exists as many XML documents
a university for the
a university for the
Variables Definition in YAWL
Variables describe what data must be supplied to a running net or
task instance, and what data that net or task instance will
eventually deliver
Each variables has:
a name it may be referenced by
a type dictating valid values it may store (cf. XML Schema)
a designation indicating how that data may be used
a scope defining the visibility of the variable (net or task
variable)
Valid designations for a variable are input, output, both
input&output, and local
in general, data are written to input variables and read from
output variables
only net variables can be defined as local
local variables are used to store data that can be manipulated only
internally within the scope of the corresponding net
they are used to store intermediate data during the execution of a
process instance
a university for the
YAWL does not support direct data passing between tasks
data cannot be directly transferred from one task instance to
another
this is because each task variable is local to the task that the
variable belongs to, i.e., it is not accessible by other
tasks
In YAWL, all data is passed
from net-level variables to task-level variables when a task
instance starts
a task variable with an input designation is one where we expect
data to be delivered from a net-level variable to that variable at
run-time
from task-level variables back to net-level variables when the task
instance completes
a task variable with an output designation can have its data output
to a containing net-level variable once a task instance has
completed
Data transfer from a net to a task and viceversa is achieved via
inbound and outbound mappings defined as XPath or XQuery
expressions
an inbound mapping is a statement that says how to transfer data
from the net's variables to a task's input variables
an outbound mapping is a statement that says how to transfer data
from the task's output variables to its containing net's
variables
a university for the
Data-based Conditional Routing
When tasks have XOR or OR splits, which branch(es) to choose is
determined by conditional expressions associated with
branches
these conditions are boolean expressions that involve data within
the process
In YAWL, the branching conditions are specified as XPath boolean
expressions
the branches whose conditions evaluate to true will be
executed
all true branches for an OR-split
the first true branch for a XOR-split
for each task with XOR or OR split, there is always a default
branch that will be taken if none of the other branch conditions
evaluate to true
Only net variables are allowed to be used in specifying branch
conditions
this is because the evaluation for a task with XOR or OR split is
conducted after completing the execution of the task, and therefore
the task variables are no longer available
a university for the
The resource perspective is primarily responsible for modeling an
organizational structure, and the people who populate it
In general, a resource may be a person (participant), or an
application, service or codelet (piece of code)
Workflow tasks that require resourcing at runtime have their
resourcing requirements specified at design time
a university for the
*all relations are from the perspective of a unique
participant
a university for the
perform one or more Roles
a role is a duty or set of duties that are performed by one or more
participants (e.g., manager, employee, officer, etc.)
hold one or more Positions (each of which belongs to an Org
Group)
a position typically refers to a unique job within an organization
(e.g., CEO) for the purposes of defining lines-of-reporting within
the organizational model (hierarchy)
an organizational group (org group) is a functional grouping of
positions (e.g., marketing, sales, human resources groups)
possess a number of Capabilities
a capability is some desired skill or ability that a participant
may possess (e.g., first aid skills, driving license, etc.)
a university for the
Design-time Resourcing Requirements
For a manual task, a designer may provide details of a distribution
set of resources to which the task should be offered at
runtime
A distribution set may consist of the union of:
zero or more individual participants,
zero or more roles, and
zero or more dynamic variables (which at runtime will be supplied
with details of participants and/or roles)
The resultant distribution set may be further filtered by
specifying that only those participants with certain capabilities,
occupying certain positions and/or being members of certain org
groups, be included
a university for the
Resourcing Interaction Points
There are three interaction points – places in a work item’s
lifecycle where resourcing decisions are to be made – up to and
including the moment the work item is placed in a work queue
At each interaction point, the decision may be:
system-initiated – automatically performed by the system, using
parameters set at design time, or
user-initiated – manually performed by a participant or
administrator at runtime
The three interaction points are:
Offer: The work item is offered to one or more participants for
execution. There is no implied obligation (from a system
perspective) for the participant to accept the offer
Allocate: The work item is allocated to a single participant, so
that the participant is committed (willingly or not) to performing
that work item at a later time. If the work item was previously
offered to several other participants, the offer is withdrawn from
them at this time; and
Start: The work item is started by the allocated participant (i.e.
enters executing state)
a university for the
The YAWL System enacts processes defined in the YAWL language
First prototype was released late 2003
First full open-source release was ‘beta 2’ in July 2004
control flow only
Later releases added the data perspective and, most recently, the
resource perspective
current release: YAWL 2.3 (06/05/2013)
Support environment is open source
currently LGPL
architecture made of an extensible set of YAWL Services
each has a unique address and endpoint
each has one or more interfaces
some offer functionality to end users, some interact with other
services and applications, some do both
The YAWL System uses the Representational State Transfer (REST)
architectural style
YAWL Services provide access to resources (workflow specifications,
data, etc.), each referenced with a URI
YAWL Services communicate via HTTP GET (retrieve information about
a resource) and POST (create or update a resource) operations
transferred data documents are in XML format
a university for the
Each service
is packaged as a web archive (war) file
is deployed in a Servlet Container
YAWL uses Apache Tomcat
Each service can be deployed to the same or different containers,
local or remote, to other YAWL Services
a university for the
a university for the
Execution data: current case instance and archival data, including
data instances and values
Organisational Model: hierarchical resource definitions (roles,
positions, org groups, capabilities)
Worklets: specialised specifications and associated rules
Codelets: executable code fragments that may be triggered by
tasks
a university for the
Workflow Engine: the core service, creates, routes and synchronises
the execution of tasks according to a specification
Resource Manager: assigns tasks to resources according to a
specification and an Org Model
Worklist Handler: presents assigned work to end users via a set of
work queues in a browser form
Process Validator: validates specifications to ensure they adhere
to a schema and are syntactically and semantically correct
a university for the
Forms Connector: loads and populates pre-defined or dynamically
generated forms for task presentation
Worklet Manager: adds dynamic flexibility and exception handling
capabilities to designated specifications
Codelet Manager: executes code fragments of behalf of a task
Other Services: WS-Invoker, SMS-Invoker, Digital Signature Service,
Declare Service, Twitter Service, etc. (and any other user-defined
custom services)
a university for the
© 2009, www.yawlfoundation.org
Presentation Layer
Process Designer: (aka the Editor) a desktop Java application for
designing specifications in the YAWL language
Worklist Dashboard: a set of browser based forms that allow task
management and execution by participants
Administration Console: a set of browser based forms that allow
loading of specifications, case launching, registration of
services, management of Org Model data, work queue administration,
etc.
Worklet Designer: a desktop .NET application that is used to define
Worklet rule sets
a university for the
YAWL Services and Interfaces
The YAWL System architecture is inspired by the Workflow Reference
Model (WRM)
The WRM describes a core engine interacting with a number of
generic components. It identifies 5 major component types and their
interfaces:
1: Process definition import and export
2: Client Application where work items are passed from engine to
client app (e.g. a worklist) and back again
3: Invoked Application where the engine can directly invoke an
external app to process a work item
4: Interoperability with other workflow engines
5: Administration & Monitoring
YAWL Engine Interfaces
The YAWL Engine provides four interfaces, three of which broadly
correspond to the WRM interfaces
YAWL Engine Interfaces
A: Specification upload and unload, service registrations, basic
connectivity services (WRM 1)
B: Establishing sessions, Case launch, passing work items to
services and applications, state retrieval (WRM 2, 3 & 4)
E: Process Log retrieval and analysis (WRM 5)
X: Detection and handling of runtime process exceptions
a university for the
© 2009, www.yawlfoundation.org
Interface B
The YAWL System combines the WRM interfaces 2, 3 and 4 into one
YAWL Interface (B)
done to ensure the Engine remains agnostic to its external
services
delegates management of the interaction of those component types to
a YAWL Service
Thus all communication between the Engine and external components
are handled through a single, generic interface
for example, the Web Service Invoker Service acts as an abstraction
layer between the engine and external web services
*
The YAWL Editor
The YAWL Editor is a Java desktop application for the creation and
verification of YAWL process specifications
It allows the process designer to:
set up process control logic (tasks and control flow)
specify data aspects (net and task level variables)
define resource perspective
verify and analyze process specifications
It communicates with a running Engine through Interface A, to
obtain a list of the YAWL Services currently registered with the
Engine
It also communicates with a running Resource Service through
Interface R, to obtain lists of the various organizational
resources and codelets currently available, so that selected
resources can be associated with particular tasks
YAWL process specifications are serialized into an XML document
with the file extension *.yawl
a university for the
© 2009, www.yawlfoundation.org
Process Specifications
A specification is expressed as an XML document that describes the
structure, format, data and layout of a process that has been
expressed graphically in the Editor, and written when saved to
file
Each specification is loaded into the Engine via Interface A
The Engine can execute a number of cases at the same time, each one
an instance of some specification
several versions of the same specification can be loaded at the
same time
a university for the
Task vs Work Item
A YAWL process specification will contain a number of task
definitions, and control-flow, data and resourcing specifications
are all defined with reference to tasks at design time
At runtime, each task acts as a template or contract for the
instantiation of one or more work items
that is, a work item is a runtime instance derived from a task
definition
task
The Engine manages the execution of instances (cases)
each case is progressed according to its current state and
control-flow description
the engine performs the specified data mappings between the case
and its tasks as required
At each stage of a process, the Engine determines which work items
should be offered, and which events should be announced to the
environment
each task in a process instance is associated at design time with a
YAWL Service (either explicitly or, if not specified, is implicitly
associated with the default worklist handler)
a university for the
The Engine: Basic Operations
The Engine is totally unaware of the operations of external
services, so that each could be served in a generic way
from an engine perspective, each service is a ‘black-box’ that
avails itself to process data served by the engine through its
interfaces
The Engine will prepare work items for execution according to
control-flow, but:
it is not responsible for how the work is performed; rather it
delegates responsibility to a custom service
it knows nothing about users, but only of custom services
it is unconcerned with how work items are resourced
It does manage two perspectives:
control-flow: determining which task(s) are enabled at certain
times during the life-cycle of a process, based on flows,
conditions, splits, joins and so on
data: mapping values to and from tasks and their parent nets,
performing transformations and evaluating expressions using the
specified XPath and XQuery predicates
a university for the
completely separate from the Engine
Basic role is to allocate work items to resources for
processing
It has four primary components:
Resource Manager: handles all the resource patterns
Worklist: a web-based user interface
Forms Connector: show either custom designed or dynamically
generated forms for work items
Codelet Server: for executing codelets
a university for the
Resource Service Runtime
At runtime, the Resource Service receives notifications from the
Engine via Interface B for all enabled work items that are not
specifically registered with another YAWL Service
The service undertakes to distribute the work item to resource(s)
using the resourcing specifications for the task from which the
work item was created, as specified at design time
For manual tasks
it will use the resourcing specification defined at design time to
determine the initial distribution set of participants, and then
apply the defined filters, constraints and allocation strategies to
that set before distributing the work item to the appropriate
participant(s)
For automated tasks
the service retrieves a reference to the specified codelet (if any)
and then executes it using the work item’s data as inputs
a university for the
© 2009, www.yawlfoundation.org
The Worklist
Each participant has access to his/her own worklist, which is a
graphical representation of his/her work queues via a series of web
forms
Each worklist consists of four work queues: Offered, Allocated,
Started and Suspended
depending on a participant’s privileges, there are a number of
actions that can be performed on a work item in each queue
A complete forms rendering engine is encapsulated by the Resource
service
it is responsible for taking a work item’s data parameter set and
rendering it as a web-based form with an appropriate set of input
fields
a university for the
a university for the
a university for the
The Run-time Environment
YAWL refers to both a language and a support environment
YAWL provides support for a broader range of processes than
traditionally covered by workflow management systems
Its development was triggered by limitations in existing
software
Lack of consensus about best approach to process analysis and
enactment
Standardization efforts have failed (e.g. too much driven by vendor
interests)
a university for the
© 2009, www.yawlfoundation.org
The Workflow Patterns initiative was driven by the lack of
consensus and the inherent complexity of business processes
Process modeling requirements are captured through patterns in a
language independent way
Other than control-flow patterns, many other pattern collections
have been developed over the years (e.g. data, resource, exception
handling, flexibility, service interaction)
Many approaches have been subjected to a patterns-based
analysis
Process modeling
Proposed standards
Summary (2/5)
© 2009, www.yawlfoundation.org
A patterns-based analysis provides deep insight into the
capabilities of an approach to process specification
Many gaps were exposed
YAWL was developed to demonstrate that comprehensive patterns
support is feasible by means of a simple yet powerful
language
Petri nets provided the starting point for the YAWL language
The limitations of Petri nets for workflow specification were
overcome through the introduction of some dedicated new
constructs
The resulting language was given a formal semantics to remove any
ambiguity and to allow for verification support
Summary (3/5)
YAWL is more than a pen-and-paper exercise
Open source support environment has been developed
this environment has gradually extended over time and grew into a
full-blown BPM solution
Substantial interest from both academia and business
System uses a service-oriented architecture
Engine provides support for control-flow and data, other
perspectives are supported through custom services (e.g. resources,
exceptions)
YAWL, and associated systems such as ProM, provide a wide range of
sophisticated analysis techniques
Summary (4/5)
© 2009, www.yawlfoundation.org
YAWL is a BPM solution that can be used in practice
Offers expected BPM functionality
Additional aspects can be supported by services (e.g.
flexibility)
Sophisticated analysis support
Use of standard XML technology
Well-defined interfaces
Aims to advance the maturity of other approaches
End-users may develop a better understanding of BPM
requirements
Summary (5/5)
References
A comprehensive overview of YAWL and its support environment is
provided in the book
ter Hofstede, A.H.M.; van der Aalst, W.M.P.; Adams, M.; Russell, N.
Modern Business Process Automation - YAWL and its Support
Environment; ISBN 978-3-642-03120-5; Springer, 2010.
of these slides, available at