a university for the world real r © 2009, chapter 7 the architecture michael adams marlon dumas...

a university for the worldrealR

WW LLLYYY AA

© 2009, www.yawlfoundation.org YYY

Chapter 7The Architecture

Michael Adams

Marlon Dumas

Marcello La Rosa


2WW LLLYYY AA

YYYYY

© 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


3WW LLLYYY AA

YYYYY


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+


4WW LLLYYY AA

YYYYY


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


5WW LLLYYY AA

YYYYY


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


6WW LLLYYY AA

YYYYY


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


7WW LLLYYY AA

YYYYY


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


8WW LLLYYY AA

YYYYY


REST Example

Client Server

request

response


9WW LLLYYY AA

YYYYY


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


10WW LLLYYY AA

YYYYY


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


11WW LLLYYY AA

YYYYY


3 Tier (Holistic) View


12WW LLLYYY AA

YYYYY


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


13WW LLLYYY AA

YYYYY


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


14WW LLLYYY AA

YYYYY


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


15WW LLLYYY AA

YYYYY


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

•


16WW LLLYYY AA

YYYYY


Typical Work Item Execution Path


17WW LLLYYY AA

YYYYY


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


18WW LLLYYY AA

YYYYY


Workflow Reference Model


19WW LLLYYY AA

YYYYY


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


20WW LLLYYY AA

YYYYY


YAWL System Architecture


21WW LLLYYY AA

YYYYY


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


22WW LLLYYY AA

YYYYY


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.


23WW LLLYYY AA

YYYYY


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


24WW LLLYYY AA

YYYYY


Interface B Events

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

– EnabledWorkItem– CancelledWorkItem– CompletedCase– CancelledCase– TimerExpiry– EngineInitialised– WorkItemStatusChange


25WW LLLYYY AA

YYYYY


EnabledWorkItemEvent

Engine

check enabled

enable workitem

start workitem

complete workitem

complete task

Service

handleEvent {

checkout

// process item

checkin

}

event + wi ref

wi ref

child wi

child wi

P C


26WW LLLYYY AA

YYYYY


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.


27WW LLLYYY AA

YYYYY


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.


28WW LLLYYY AA

YYYYY


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


29WW LLLYYY AA

YYYYY


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


30WW LLLYYY AA

YYYYY


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.


31WW LLLYYY AA

YYYYY


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


32WW LLLYYY AA

YYYYY


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

a university for the world real r © 2009, chapter 7 the architecture michael adams marlon dumas...

Documents

yawl system yawl services

rest yawl services

services slide

world real r

yawl language

web services web services

resource service

rosa slide