Task-Oriented, Policy Driven Business Requirements Elicitation for Web Services

1. Task-Oriented, Policy Driven Business Requirements Elicitation for Web Services Stephen Gorton Department of Computer Science, University of Leicester, University Road, Leicester LE1 7RH

2. Outline • Background Information • Web service architecture • Current solutions; • Motivation; • Foundational aspects; • Policies; • Operators; • Further aspects: • Negotiation; • Cancellation; • Holiday Example; • Conclusions and further work. Task-Oriented, Policy Driven Business Requirements for Web Services

3. Web Service Architecture R e q u i r e m e n t s R e q u i r e m e n t s Exportable service service Software Software Composite Composite service service service service service service UDDI, WSDL, etc. UDDI, WSDL, etc. HTTP, HTTPS, SMTP, etc. HTTP, HTTPS, SMTP, etc. • Composition often the top layer; • Composition and orchestration still a blur! • Little regard for a more abstract requirements layer. Task-Oriented, Policy Driven Business Requirements for Web Services

4. Current Solutions 1 • Approach 1: Composition as Requirements • BPEL: • DAML-S Code snippets taken from Milanovic and Malek: Current Solutions for Web Service Composition. IEEE Internet Computing, Nov/Dec 04 Task-Oriented, Policy Driven Business Requirements for Web Services

5. Current Solutions 2 • Approach 2: Specialised Requirements Language • BPMN • Business Process Diagram (BPD); • Process flow modelling; • Little or no support for non-functional requirements; • No support for corporate, environmental constraints. • UML • Processes modelled with activity diagrams; • Does not define any execution meta-model for business processes modelled with it; • “UML lacks mathematical foundation to map to BPEL’s.” • (Owen and Raj, BPMN and Business Process Management, Sep 2003) • Both approaches offer limited support in an automated composition environment. Task-Oriented, Policy Driven Business Requirements for Web Services

6. Motivation • Increase the level of abstraction at the business layer: • Support for functional and non-functional requirements; • Allow generic policies across multiple projects; • Business approach for business analysts; • Built on firm semantics. • Bigger picture: • Define business goal; • Break down goal into sequences of tasks; • Find services to match tasks; • Generate automated orchestrations. Task-Oriented, Policy Driven Business Requirements for Web Services

7. Foundational Aspects 1 • Business goal: • Describes the overall requirement; • Can be broken down into a number of tasks; • Subjected to external constraints: • Not necessarily as part of a project but an implicit requirement nevertheless; • Formally expressed as a set {T, m, O, K}. • Task: • An atomic business activity; • Performed in specific order as defined by the task map; • Defined independently of service knowledge; • Formally expressed as a set {id, Req, Pr, X}. Task-Oriented, Policy Driven Business Requirements for Web Services

8. Foundational Aspects 2 • Build on BPMN idea: • Use a simpler graphical notation; • Introduce policies to define requirements; • Formal semantics allow mapping to composition technology. • Policies: • 3 main parts: • Triggers; • Conditions; • Actions; • Formal description of each task; • Express system, corporate or global constraints. Task-Oriented, Policy Driven Business Requirements for Web Services

9. Wedding Example • Business goal g = “plan wedding”; • Broken down into composite tasks: • ct1 = plan pre-wedding celebrations; • ct2 = plan preparations; • ct3 = plan legalities; • ct4 = plan ceremony; • ct5 = plan post-ceremony celebrations; • ct6 = plan honeymoon. • Tasks are arranged according to result timeline, not according to execution timeline! • e.g. ceremony and post-ceremony celebrations often planned in parallel. • Policies: • The entire event should not cost more than £10k; • The ceremony and post-ceremony celebrations should be on the same day; • The honeymoon should be booked through a known and trusted travel agency. Task-Oriented, Policy Driven Business Requirements for Web Services

10. Holiday sub-example • Booking the honeymoon: • Choose where to go and for how much; • Find travel agencies and get quotes from each of them; • Decide on the best quote received; • Book the favourite holiday; • Change currency at a bank. Task-Oriented, Policy Driven Business Requirements for Web Services

11. Notation 1 • Tasks and Composite Tasks: • Flows: • Control input and output; • Data input and output; • Resource?? • External inputs; • Error outputs. Task-Oriented, Policy Driven Business Requirements for Web Services

12. Operators 1 • Flow Split: • FS: in -> OUT; • Control proceeds down each output simultaneously; • No limit on number of output flows; • Parallel split workflow pattern. • Conditional Merge: • CM: IN -> out; • Forces synchronisation; • Mandatory and optional flows; • Specifies minimum number of flows; • Discriminator workflow pattern. Task-Oriented, Policy Driven Business Requirements for Web Services

13. Operators 2 • Strict Preference • SP: in -> out; • Input is a set of pairs {c, d} • c is a control flow; • d is a priority rating; • New workflow pattern. • Random Choice • RC: in -> out; • All tasks invoked; • When a first gets to a “commit”, all others are cancelled; • New workflow pattern. Task-Oriented, Policy Driven Business Requirements for Web Services

14. Operators 3 • Flow Junction: • FJ: in -> {out1, out2}; • Left output is primary; • Output flow chosen according to a test; • Exclusive choice workflow pattern. • Flow Merge: • FM: IN -> out; • Incoming set of control flows contains only one active flow; • No synchronisation issue; • (Multiple) Merge workflow pattern. Task-Oriented, Policy Driven Business Requirements for Web Services

15. Cycles • Bounded cycles allowed: • For both composite and atomic tasks; • Can be modelled with flow junction and flow merge. • (since we only allow one control flow input, a flow merge function should be used). Task-Oriented, Policy Driven Business Requirements for Web Services

16. Negotiation • Two or more data values prove little to no use together: • E.g. wanting to go to the Seychelles on £10. • Not a compatibility issue. • Basic negotiation base: • Each requirement given rating: • “must”; • “must not”; • “should”; • “should not”; • “prefer”; • “prefer not”. Task-Oriented, Policy Driven Business Requirements for Web Services

17. Cancellation 1 • State independent tasks: • Does not alter system state during computation; • May result in state change; • Pre-computation stage; • Commit stage; • Cancellation can occur before commit; • More like an interrupt. Task-Oriented, Policy Driven Business Requirements for Web Services

18. Cancellation 2 • State-dependent tasks: • Change system state during computation; • N pre-computation stages, each followed by a commit; • With no history buffer, cancellation can only occur before the first commit; • A history buffer can lead to quasi-atomicity (Gaudel, 2004). Task-Oriented, Policy Driven Business Requirements for Web Services

19. Holiday Example revisited • t1: allocate jobs • t2: choose destination • t3: choose budget • t4: find agencies • t4: query agency 1 • t5: query agency 2 • t6: query agency 3 Task-Oriented, Policy Driven Business Requirements for Web Services

20. Holiday Example cont. • t8: arrange two quotes in order of preference • t9: attempt to book primary choice • t10: attempt to book secondary choice • t11: exchange currency at bank A • t12: exchange currency at bank B Task-Oriented, Policy Driven Business Requirements for Web Services

21. Conclusions • Current notations not appropriate: • UML has some merits but does not support many workflow patterns; • BPMN is the nearest to a complete solution; • None allow for the expression of all requirements. • A simple graphical notation: • Describing process flows; • Scope for core and non-core (non-functional) requirements; • Based on policies. • Further work: • Data flow patterns; • Resource flow patterns; • Formal specification of policies; • A workbench? Task-Oriented, Policy Driven Business Requirements for Web Services