LaQuSo is an activity of Technische Universiteit Eindhoven and Radboud University Nijmegen Dagstuhl, July 2006 Relationships between services, components and workflows Kees van Hee

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 1/27 AGENDA Service Oriented Architecture Role of process models Components framework Patterns for SOA Verification

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 2/27 Components and services Components deliver services to their clients So components have a role as service provider Components often use services offered by other components So components have often the role of service client software interface component monitor interface configuration interface user interface Systems are networks of cooperating components Systems can be considered as components themselves Components may reside anywhere Synonyms Capsules Modules Packages Classes

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 3/27 Role of software architecture An architecture is used to divide and conquer in development process to identify, specify and select components to test and integrate components to manage a system when it is operational The architecture of a system should be a “living document” of the system

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 4/27 business architecture process model information model  software architecture: logical model…………..... physical model Infrastructure Typical way of architecture modeling

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 5/27 Service Orientation Architecture Supplier Service contract Service Client Service broker Search Publish ttp function

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 6/27 Unique features of SOA A SOA component is a service provider or “business unit” A SOA component will only survive if it offers added value Dynamic binding: services are requested when they are needed services can be obtained from different providers. Components do not have to know each other: the meet via a broker A simple, universal protocol is required One service may be composed of many levels of components. We only have to consider two:

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 7/27 AGENDA Service Oriented Architecture Role of process models Components framework Patterns for SOA Verification

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 8/27 Different roles of process models Business processes: Enterprise Information Systems (EIS) are developed to automate or support business processes So they have to be modeled, verified and validated before Workflow processes in the EIS: an EIS takes care of enactment: the process model is the configuration parameter Configuration of middleware: Components of an EIS cooperate by means of middleware; process models are the configuration parameters of orchestration

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 9/27 Academic formalisms (Labeled)Transition system Process algebra (e.g pi-calculus) Petri net (e.g.colored nets) Engineering frameworks UML Activity Diagram UML State Chart BPMN BPEL EPC (defacto standard) Rose RT Types of process models

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 10/27 AGENDA Component-based world Service Oriented Architecture Role of process models Components framework Patterns for SOA Verification

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 11/27 Reasons for a framework We need to verify the behavioral properties of component- based (SOA) systems Process models are good for modeling system dynamics But are often too abstract or too restrictive Therefore we need models that are closer to the software systems and their “engineering models” We may check these models with formal methods, but we must explain errors in terms of engineering models.

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 12/27 Essential features of a component Every part of a system is a component: so the service brooker, the middleware and the service’. Each component consists of: Monitor (with history log) Exception handler (with roll back mechanism) Communication ports (with message queues) Service catalog (workflow per offered service) Orchestrator (for workflow enactment) Clock (with timer and alarm) Configurator (for updating the service catalog) Application-specific subcomponents Application-specific datasets (variables)

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 13/27 Generic view: component infrastructure P: ports H: history log C: service catalog V: application specific variables S: application specific sub- components Client ports Provider ports Exception Handler Monitor C Configurator H P P P P PP Clock Orchestrator V S

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 14/27 Application specific view (1) Here we define the services of a component by two connected models: Process layer (wf model) Events, activities, tasks Object layer (class model) Variables (volatile and persisitent) Functions (of input and variables to variables and output) Connection: tasks call functions and update variables

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 15/27 Application specific view (2) Workflow model: Each service instance is a case or thread Case tokens are references to case objects Each task may have  Input and output messages (tiggers, events)  Access to case object and other base objects  Tasks exchange messages through ports with other components  Tasks execute operations on objects by method calls Class model: Per service a case class: attribute types and methods (functions on the attributes) Per case one object with its own attributes (variables) “Base” classes: objects that are independent of cases. Like code tables, reference tables. It is persistent data.

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 16/27 Workflows for services Made with Yasper Intertwined workflows Open workflows Transtion boardered Case identities=thread Case sensitive: E:emitor C:collector

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 17/27 Choices to be made Communication ports: 1,2,3 asynchronous, 4,5 synchronous 3,4,5 need only arcs as glue 3 is favourite? (input place, output transition) Reset and inhibitors only within components: so a component can not reset an input of another Time-outs only within components Identity management per component: add per service a case id. “Case sensitivity”. Exception handling per component: triggered by a task, stops orchestration and activates the compensation process based on the history log Component 1 Component

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 18/27 Subcomponents Subcomponents do not have the full functionality of a component: they use the infrastrucure of the component. They are used as modules in a programming language: to manage complexity and for reuse in other components. Subcomponents may have access to objects of their parents. So shared memory in the hierarchy. Orchestrator Component Subcomp Workflow

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 19/27 AGENDA Component-based world Service Oriented Architecture Role of process models Components framework Patterns for SOA Verification

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 20/27 Example: service consumption Made with Yasper An RFI is broadcasted to providers. From the ones that react 5 are selected for an RFP. From 3 of them a selection is made and negotiations are started. Missing: at the end the input place should be reset

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 21/27 Example: execption handler History log contains the trace of tasks. For each updated variable there is a compensation action

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 22/27 Example: communication bus Every components is connected to the bus. The bus filters the data, keeps a log and sends P2P or broadcast. If the service directory is used, is it a broker

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 23/27 AGENDA Service Oriented Architecture Role of process models Components framework Patterns for SOA Verification

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 24/27 Verification: service integrity Components deliver services, tiggered by a client A service may start up sub-services in other components Services should have a clearly defined start and end event; also when a subservice does not deliver (X) A simple service has a Query-Answer protocol and behaves as an RPC. These services are in fact transactions X

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 25/27 Two important correctness criteria Proper completion: services should always be able to terminate with an end event, and they should not leave any unfinished work Invariants: constraints on case and base objects should be valid as soon as a service has finished If we use Petri nets as modeling vehicle: Proper completion is called soundness Soundness is decidable and there are software tools to check it Many other properties can be verified by model checking with (e.g. reachability/coverability graph) often after applying reduction techniques In practice we need to verify business rule like: “always the total of received invoices should not exceed total of delivered services / goods”

Copyright © 2005 LaQuSo Eindhoven/Nijmegen050615_HS_LQS 26/27 Wish list Patterns for the generic components to be combined with application specific models to verify the complete behavior These patterns need to be verified in isolation and be combined using construction rules that guarantee correctness. (nested Petri nets could be a solution here!) State space checking should be combined by reduction techniques. We need also symbolic model checking (see example business rule) The answers of verification should be translated into the original frameworks of the engineers

LaQuSo is an activity of Technische Universiteit Eindhoven and Radboud University Nijmegen Visit Address: Technische Universiteit EindhovenRadboud Universiteit Faculteit NWI Hoofdgebouw (HG) 5.91Hoofdgebouw A6034 Den Dolech 2, EindhovenToernooiveld 1, Nijmegen Postal Address: HG 5.91RUN-FNWI A6034 P.O. Box 513P.O. Box MB Eindhoven6500 GL NijmegenThe Netherlands Phone:+31 (0) (0) Fax: +31 (0) (0) Website: LaQuSo is an activity of Technische Universiteit Eindhoven