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