Transcript The Architecture - YAWL: Yet Another Workflow Language

Y
A W L
Chapter 7
The Architecture
Michael Adams
Marlon Dumas
Marcello La Rosa
a university for the
real world
R
© 2009, www.yawlfoundation.org
Y
Topics
Y
• Architectural Foundations
• 3-Tier View of the YAWL System
• YAWL Services and Interfaces
–
–
–
–
–
Architecture Specifics
The Engine
The Editor
The Resource Service
Other Services
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
2
Overview
Y
• 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
• There have been 25 full releases to date
• Downloads: 85,000+
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
3
Service-Oriented Architecture
Y
• The YAWL System has an SOA structure
• Basically, a service is a software module or unit that:
– is self contained
– performs some service
– has an endpoint (or entry point) through which communication
occurs via one or more interfaces
• So, an SOA is a set of interoperable services that:
– each have a unique address
– are aware of each other’s addresses (and thus each other’s
endpoints)
– can pass requests and data via those endpoints
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
4
Service-Oriented Architecture
•
•
•
•
Y
One way to implement SOA is with web services
Web services are discrete functional software modules
Can be uniquely addressed via URL
Can communicate via standard Internet protocols, using
established architectural styles
– REST, SOAP, RPC, DCOM, CORBA etc
• Can communicate regardless of operating platform or
programming language
• Standalone (desktop) applications can also interact with
services
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
5
YAWL System: SOA
Y
• The YAWL system comprises 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
6
Representational State Transfer
Y
• REST consists of clients and servers
– a service may be a client and a server
• A client makes a request to a server, which processes it
and returns a response
• Each request and response involves the transfer of
some ‘representation’ to or from a ‘resource’
– resource: a source of specific information, referenced by a
global identifier
– representational state: typically a data document of some kind
• Typically, REST uses HTTP (but doesn’t have to)
• The WWW is the largest implementation of REST
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
7
REST Example
Y
Client
Server
request
response
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
8
YAWL System: REST
Y
• YAWL Services provide access to resources, each
referenced with a URI
– e.g. a workflow specification, a case, a work item are all
resources exposed by the YAWL Engine
• YAWL Services communicate via HTTP GET and
POST operations
– GET: retrieve information about a resource
– POST: create or update a resource
• Transferred data documents are in XML format
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
9
YAWL System: Language & Deployment
Y
• The YAWL System is written in Java
• Each service is, at its base, a Servlet
– a Servlet is an object that can dynamically process requests
and generate responses
• Each service is packaged as a web archive (war) file
– also contains a number of 3rd party libraries (e.g. JDOM,
Xerces, Saxon, Apache Commons etc.)
• Each service is deployed in a Servlet Container
– a specialised server that supports Servlet operations
– translates URLs into Servlet requests
– YAWL uses Apache Tomcat
• Each service can be deployed to the same or
different containers, local or remote, to other YAWL
Services
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
10
3 Tier (Holistic) View
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Y
A W L
11
Data Layer
Y
• Specifications: consisting of control-flow logic, data
definitions and data & resource mappings
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
12
Business Logic Layer (1)
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
13
Business Logic Layer (2)
Y
• 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, other user-defined
custom services
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
14
Presentation Layer
Y
• 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
•
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
15
Typical Work Item Execution Path
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
16
YAWL Services and Interfaces
Y
• 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
*www.wfmc.org/standards/docs/tc003v11/pdf
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
17
Workflow Reference Model
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
18
YAWL Engine Interfaces
Y
• The YAWL Engine provides four interfaces, three of
which broadly correspond to the WRM 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
19
YAWL System Architecture
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
20
The YAWL Engine
Y
• The Engine manages the execution of instances
(cases)
– Each case is progressed according to its current state and
control-flow description
– 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).
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
21
Engine Agnosticism
Y
• 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
• This is in contrast to traditional workflow systems
where, for example, the worklist handler is treated as
being part of the engine
• This approach makes the Engine more lightweight,
while providing a flexible and extensible framework for
plugging in additional (custom) services into the YAWL
System.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
22
Interface B
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
23
Interface B Events
Y
• Interface B also generates a number of events in the
lifecycle of each case:
–
–
–
–
–
–
–
EnabledWorkItem
CancelledWorkItem
CompletedCase
CancelledCase
TimerExpiry
EngineInitialised
WorkItemStatusChange
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
24
EnabledWorkItemEvent
Y
Service
Engine
check enabled
event + wi ref
enable workitem
handleEvent {
checkout
start workitem
P
child wi
// process item
C
checkin
complete workitem
}
complete task
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
25
The YAWL Editor
Y
• The YAWL Editor is a Java desktop application for the
creation and verification of YAWL 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
26
The YAWL Editor
Y
• The Editor provides a
tool palette from which
modeling elements (such
as tasks or conditions)
may be chosen.
• At any time, a process
may be verified and
analyzed to ensure
completeness,
soundness and so on.
• When complete, the
process definition may
be saved to a disk file, in
XML format.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
27
The Resource Service
Y
• Provides the resource perspective for specifications
– 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
28
The Resource Service
Y
• A resource may be a person (participant), or an
application, service or codelet
• Each participant may perform one or more Roles, hold
one or more Positions (each of which belongs to an Org
Group) and possess a number of Capabilities
• Workflow tasks that require resourcing at runtime have
their resourcing requirements specified at design time
using the Editor
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
29
The Resource Service Interfaces
Y
• In addition to communicating with the Engine through
Interfaces A and B, the Resource Service exposes
functionality through three interfaces of its own:
– Interface O provides an interface to organizational data
sources, allowing pre-existing data sources to be directly
‘plugged in’ to the service.
– Interface R provides access to the organizational data by
authorised external clients (such as, but not limited to, the
Editor).
– Interface W exposes the entire worklist routing functionality, to
allow external, specialised worklists to be developed and
implemented.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
30
Other Services
Y
• Worklet Service: enables dynamic flexibility and exception
handling for cases
• Web Service Invoker Service: invokes external SOAP
web services for processing tasks
• Declare Service: enables process flexibility through
loosely structured specifications and constraints
• SMS Service: allows tasks to send and receive SMS
messages
• Digital Signature Service: ensures authenticity of form
data
• Mail Sender Service: allows the sending of email from a
task generated form
• Twitter Service: allows tasks to send twitter status updates
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
31
Summary
Y
• Architectural Foundations
• 3-Tier View of the YAWL System
• YAWL Services and Interfaces
–
–
–
–
–
Architecture Specifics
The Engine
The Editor
The Resource Service
Other Services
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
32