a university for the world real R © 2009, Chapter 7 The Architecture Michael Adams Marlon Dumas Marcello La Rosa

a university for the world real R 2 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, REST Example ClientServer request response

a university for the world real R 9 © 2009, 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 © 2009, 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 © 2009, 3 Tier (Holistic) View

a university for the world real R 12 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, Typical Work Item Execution Path

a university for the world real R 17 © 2009, 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 *

a university for the world real R 18 © 2009, Workflow Reference Model

a university for the world real R 19 © 2009, 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 © 2009, YAWL System Architecture

a university for the world real R 21 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, EnabledWorkItemEvent Engine check enabled enable workitem start workitem complete workitem complete task Engine check enabled enable workitem start workitem complete workitem complete task Service handleEvent { checkout // process item checkin } Service handleEvent { checkout // process item checkin } event + wi ref wi ref child wi P P C C

a university for the world real R 26 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 © 2009, 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 from a task generated form Twitter Service: allows tasks to send twitter status updates

a university for the world real R 32 © 2009, 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