Dagstuhl, July 2006

1. Relationships between services, components and workflows Kees van Hee Dagstuhl, July 2006

2. AGENDA • Service Oriented Architecture • Role of process models • Components framework • Patterns for SOA • Verification

3. user interface monitor interface component configuration interface software interface Components and services Systems are networks of cooperating components Systems can be considered as components themselves Components may reside anywhere • 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 Synonyms Capsules Modules Packages Classes

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

5. Typical way of architecture modeling business architecture process model.................. information model............ software architecture: logical model…………..... physical model................. Infrastructure.....................

6. Service Orientation Architecture Service broker Search Publish Service contract Client Supplier Service ttp function

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

8. AGENDA • Service Oriented Architecture • Role of process models • Components framework • Patterns for SOA • Verification

9. Different roles of process models • Business processes:Enterprise Information Systems (EIS) are developed to automate or support business processesSo 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

10. Types of process models • Academicformalisms • (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

11. AGENDA • Component-based world • Service Oriented Architecture • Role of process models • Components framework • Patterns for SOA • Verification

12. Reasons for a framework • We need to verify the behavioral properties of component-based (SOA) systems • Process models are good for modeling systemdynamics • 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.

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

14. Generic view: component infrastructure P: ports H: history log C: service catalog V: application specific variables S: application specific sub-components Client ports P P S Exception Handler Clock H C P P Orchestrator V Monitor Configurator P P Provider ports

15. Applicationspecificview (1) Here we define the services of acomponent 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

16. Applicationspecificview (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 • Classmodel: • 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.

17. Workflows for services • Intertwined workflows • Open workflows • Transtion boardered • Case identities=thread • Case sensitive: • E:emitor • C:collector Made with Yasper

18. 1 2 Component 2 Component 1 3 4 5 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

19. Component Orchestrator Subcomp Subcomp Workflow Workflow 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 sharedmemory in the hierarchy.

20. AGENDA • Component-based world • Service Oriented Architecture • Role of process models • Components framework • Patterns for SOA • Verification

21. Example: service consumption 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 Made with Yasper

22. Example: execption handler History log contains the trace of tasks. For each updated variable there is a compensation action

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

24. AGENDA • Service Oriented Architecture • Role of process models • Components framework • Patterns for SOA • Verification

25. X 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

26. 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 modelchecking 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 notexceed total of delivered services / goods”

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

28. Visit Address: Technische Universiteit Eindhoven Radboud Universiteit Faculteit NWI Hoofdgebouw (HG) 5.91 Hoofdgebouw A6034 Den Dolech 2, Eindhoven Toernooiveld 1, Nijmegen Postal Address: HG 5.91 RUN-FNWI A6034 P.O. Box 513 P.O. Box 9010 5600 MB Eindhoven 6500 GL Nijmegen The Netherlands The Netherlands Phone: +31 (0)40 247 2526 +31 (0)24 365 3410 Fax: +31 (0)40 247 4252 +31 (0)24 365 3137 E-mail: info@laquso.com nijmegen@laquso.com Website: www.laquso.com LaQuSo is an activity of Technische Universiteit Eindhoven