7 The Architecture - YAWL

judgedrunkshipΔιακομιστές

17 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

124 εμφανίσεις

a university for the

world

real

R

W
W
L
L
L
Y
Y
Y
A
A
© 2009, www.yawlfoundation.org

Y
Y
Y
Chapter 7

The Architecture

Michael Adams

Marlon Dumas

Marcello La Rosa

a university for the

world

real

R

2

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Topics


Architectural Foundations


3
-
Tier View of the YAWL System


YAWL Services and Interfaces


Architecture Specifics


The Engine


The Editor


The Resource Service


Other Services



a university for the

world

real

R

3

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Overview


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+


a university for the

world

real

R

4

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Service
-
Oriented Architecture


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



a university for the

world

real

R

5

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Service
-
Oriented Architecture


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

a university for the

world

real

R

6

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

YAWL System: SOA


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


a university for the

world

real

R

7

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Representational State Transfer


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

a university for the

world

real

R

8

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

REST Example

Client

Server

request

response

a university for the

world

real

R

9

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

YAWL System: REST


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

a university for the

world

real

R

10

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

YAWL System: Language & Deployment


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 3
rd

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


a university for the

world

real

R

11

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

3 Tier (Holistic) View

a university for the

world

real

R

12

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Data Layer


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

a university for the

world

real

R

13

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Business Logic Layer (1)


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

world

real

R

14

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Business Logic Layer (2)


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


a university for the

world

real

R

15

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 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

world

real

R

16

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Typical Work Item Execution Path

a university for the

world

real

R

17

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

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

*
www.wfmc.org/standards/docs/tc003v11/pdf

a university for the

world

real

R

18

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Workflow Reference Model

a university for the

world

real

R

19

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

YAWL Engine Interfaces


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

a university for the

world

real

R

20

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

YAWL System Architecture

a university for the

world

real

R

21

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

The YAWL Engine


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).

a university for the

world

real

R

22

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Engine Agnosticism


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.

a university for the

world

real

R

23

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 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

a university for the

world

real

R

24

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Interface B Events


Interface B also generates a number of events in the
lifecycle of each case:


EnabledWorkItem


CancelledWorkItem


CompletedCase


CancelledCase


TimerExpiry


EngineInitialised


WorkItemStatusChange


a university for the

world

real

R

25

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

EnabledWorkItemEvent

Engine


check enabled


enable workitem




start workitem





complete workitem


complete task

Service




handleEvent {



checkout




// process item




checkin


}



event + wi ref

child wi

P

C

a university for the

world

real

R

26

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

The YAWL Editor


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.

a university for the

world

real

R

27

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

The YAWL Editor


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.


a university for the

world

real

R

28

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

The Resource Service


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

a university for the

world

real

R

29

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

The Resource Service


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

a university for the

world

real

R

30

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

The Resource Service Interfaces


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.

a university for the

world

real

R

31

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Other Services


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


a university for the

world

real

R

32

W
W
L
L
L
Y
Y
Y
A
A
Y
Y
Y
Y
Y
© 2009, www.yawlfoundation.org

Summary


Architectural Foundations


3
-
Tier View of the YAWL System


YAWL Services and Interfaces


Architecture Specifics


The Engine


The Editor


The Resource Service


Other Services