Contracts, Workflows, and Beyond...

1. Contracts, Workflows, and Beyond... Christian StefansenIT University of Copenhagen, December 5, 2006

2. The NEXT Research Group • NEXT generation Enterprise Resource Planning (ERP) systems • ”The over-all goal of the project is to develop software technology and methods for development of the next generation of [...] ERP-systems.” • Microsoft Dynamics is the former Navision/Damgaard plus Great Plains etc. ITU, Dec. 5, 2006

3. Compositional Commercial Contracts Jesper Andersen Ebbe Elsborg Fritz Henglein Jakob Grue Simonsen Christian Stefansen

4. Paper-Based Contract-Handling is Costly • No formal representation results in: • Manual handling in auxiliary systems • Ad hoc deadline management • Ambiguous semantics • Time-consuming valuation • Cannot report on future events • No coordination with production planning or supply-chain management • Missed opportunities (call options etc.) • Potential benefits of formal representation: • Alleviate the problems above • Several consistency checks at time of writing contract • (Semi-)automated contract analysis (incl. valuation)(DSL programs are in a sense ”intelligent data”) ITU, Dec. 5, 2006

5. Example: Agreement to Provide Legal Services • Section 1. The attorney shall provide, on a non-exclusive basis, legal services up to (n) hours per month, and furthermore provide services in excess of (n) hours upon agreement. • Section 2. In consideration hereof, the company shall pay a monthly fee of (amount in dollars) before the 8th day of the following month and (rate) per hour for any services in excess of (n) hours 40 days after the receival of an invoice. • Section 3. This contract is valid 1/1-12/31, 2008. ITU, Dec. 5, 2006

6. Example: Legal Agreement Code ITU, Dec. 5, 2006

7. Data Agents Resources (goods, services, rights) Commitments/Events Time Structure Sequential execution Concurrent execution Repeated execution Alternative execution (choice between subcontracts) We Analyzed and Wrote 15 Full-Length Contracts ITU, Dec. 5, 2006

8. Syntax *** ITU, Dec. 5, 2006

9. Deterministic Reduction with Delayed Matching • Consider some of the reduction rules: ITU, Dec. 5, 2006

10. Example Reduction ITU, Dec. 5, 2006

11. Example Reduction - Step 2 ITU, Dec. 5, 2006

12. Expressing Workflows in a Process Calculus Work in progress...

13. Why Formal Workflows? • Users • can easily adhere to established best practice • know what tasks kan be dealt with now/later • receive help to delegate tasks appropriately • need only local knowledge about the tasks they solve (as opposed to global knowledge about the entire workflow) • Designers/planners • can more easily map out and change processes • can introduce structure along the way (ad hoc) • can perform formal analysis on workflows • can partially automate outsourcing etc. • Controllers • gain finer registration of resource consumption (e.g. time) and thus costs (get Activity-Based Costing for free) • can carry out performance analysis more easily ITU, Dec. 5, 2006

14. Design(consultants/users) Book flight Recv.ticket Recv.confirmation Get permissionto travel Book hotel File expensesfor reimbursem. Reserve car Recv.confirmation Recv.reimbursement How not to design one’s processes... • See any problems? • Too rigid(Do we always get permission first before booking?) • Omissions/errors/simplifications(What if we do not receive the ticket?) • Requires many programmer hours(Write everything in BPEL! But who is skilled to change it then?) ITU, Dec. 5, 2006

15. ...but this is Taylor’s Scientific Management all over again! • Workflows can be as freeform or as rigid as one designs them. Runtime allocation optimization is key! • The simplest workflow is just an unordered task list. • Workflow can be adaptive, starting with the completely unstructured workflow first and imposing structured constraints over time. ITU, Dec. 5, 2006

16. Design(consultants/users) Book flight Recv.ticket Recv.confirmation Get permissionto travel Book hotel File expensesfor reimbursem. Reserve car Recv.confirmation Recv.reimbursement Helping Yourself: An Improved Model Automated process analysis max  ...s.t. ... ! ? Optimal runtimeallocation Process mining Auditing, reporting, outsourcing ITU, Dec. 5, 2006

17. Focus thus far Is There a Standard for Workflows? • No widely accepted standard so far. • Studies by Aalst et al. proposed: • 20/43 control-flow patterns(parallel, sequence, choice, repetition etc.) • 39 data patterns(scope, call-by regime, parameters etc.) • 43 resource patterns (delegation)(implicit, queue, role, case, quality check) • Can a process calculus handle this? ITU, Dec. 5, 2006

18. The 20 Control-Flow Patterns ITU, Dec. 5, 2006

19. Pattern 6: Multiple ChoiceChoose several execution paths from many alternatives. Pattern 16: Deferred ChoiceExecute one of two alternative threads. The choice [...] should be implicit. Def’d Pattern 20: Cancel CaseCancel (disable) the process) Pattern 13: Multiple Instances [...] Generate many instances of one activity [...] with synchronization. Pattern 10: Arbitrary Cycles Merge Choice a b c d e Mult ... Merge Choice Cancel A Look At Some Patterns ITU, Dec. 5, 2006

20. Workflow-mønstre Kodning SMAWL Intro Kontrakter CDL Arkitektur Afslutning Synch.merge REA Synch. Merge Has Non-Local Semantics • Workarounds • Integrate with split-end pattern(thus loosing free-form property) • Decide runtime(thus loosing some static checks) • Pass around meta-information from previous split(s)(thus complicating distribution and introducing complexity, also insufficient in degenerate cases) ITU, Dec. 5, 2006

21. CCS syntax:Atomic tasks are simply written as a,b,c etc. P Q Calculus of Communicating Systems • Pattern 1: Sequence • a.P – not general enough • P.Q – not syntactic • Require processes to signal termination explicitly on a designated channel, e.g. ok • new go (P [go/ok] | go?.Q) ITU, Dec. 5, 2006

22. P1 Mult Disc ... ... Q Pn Example Encoding • Pattern 7/9: Multiple Choice/Discriminator • (.P1 + .skip!) |  | (.Pn + .skip!) |ok?.(Q | skip?*.0 | ok?*.0) ITU, Dec. 5, 2006

23. Merge Choice a b c d e Merge Choice Example Encoding • Pattern 10: Arbitrary Cycles • new gob, goc(a.gob! | gob?*.b.goc! | goc?*.c.(gob! + d.(goc! + e)) ITU, Dec. 5, 2006

24. What Really Is Needed • Free structure or block structurePatterns have graph-type structure (YAWL, Petri nets, WFDL) as opposed to block structure (XLANG, parts of BPEL). Free structure creates nasty caveats and necessitates synchronizing merge. • Deferred vs. explicit choiceBoth must be supported • Many split and join variantsBut many seem better expressed by simple data-language. Need to support forks without synch. • Cancellation and CompensationNeither Petri nets nor pi-calculus handle this very well. LOTOS and CSP have operators for this. • Multiple InstancesGenerativity is essential ITU, Dec. 5, 2006

25. ...And Can CCS Handle It Elegantly? • First Approximation of Expressiveness:local vs. global rewrites (Felleisen) • CCS cannot macro-express: • Sequence (!) • Cancellation • ...more of the new patterns? • Some patterns blow up source code size ITU, Dec. 5, 2006

26. Future Research on Business Processes • Language for distributed processes with behavior types • Find/adapt/design suitable process calculus • Part of larger ERP architecture (3gERP project) ITU, Dec. 5, 2006

27. Related Work • PiDuce – a project for experimenting with web services technologiesSamuele Carpineti, Cosimo Laneve, Luca Padovani, Jan. 2006 • Compositional ContractsPeyton Jones, Eber, Seward, 2001 • Process Mininghttp://processmining.org • Workflow Patternshttp://workflowpatterns.com ITU, Dec. 5, 2006

28. Q&A and thanks! • Thank you for having me! • Questions? • More info on:http://www.stefansen.dkhttp://www.it.edu/next/ ITU, Dec. 5, 2006

29. A Workflow in SMAWL workflow Q = Intro; choose any {  Workflowmønstre; Kodning; SMAWL  Kontrakter; CDL  REA }; Arkitektur; Afslutning end Workflow-mønstre Kodning SMAWL Intro Kontrakter CDL Arkitektur REA Afslutning ITU, Dec. 5, 2006

30. Transforming SMAWL to CCS • Sequence • Multiple Instances ITU, Dec. 5, 2006

31. A Process-Oriented System Architecture (Highly speculative)

32. events Log environment Processes push/pull observations Reports/monitors Future: A Process-Oriented Framework • Data model • Process mining • Inter-operability (ontology) • Process language • Base (data) language • Service patterns • Auto. GUI-generation • Runtime verification • Incrementalization of reports • Stream processing • Dynamic operator placement in overlay networks ITU, Dec. 5, 2006