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. 02/03/06Task-Oriented, Policy Driven Business Requirements for Web Services 2 Outline Background Information –Web service architecture –Current solutions; Motivation; Foundational aspects; Policies; Operators; Further aspects: –Negotiation; –Cancellation; Holiday Example; Conclusions and further work.

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

4. 02/03/06Task-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

5. 02/03/06Task-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.

6. 02/03/06Task-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.

7. 02/03/06Task-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}.

8. 02/03/06Task-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.

9. 02/03/06Task-Oriented, Policy Driven Business Requirements for Web Services 9 Wedding Example Business goal g = “plan wedding”; Broken down into composite tasks: –ct 1 = plan pre-wedding celebrations; –ct 2 = plan preparations; –ct 3 = plan legalities; –ct 4 = plan ceremony; –ct 5 = plan post-ceremony celebrations; –ct 6 = 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.

10. 02/03/06Task-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.

11. 02/03/06Task-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.

12. 02/03/06Task-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.

13. 02/03/06Task-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.

14. 02/03/06Task-Oriented, Policy Driven Business Requirements for Web Services 14 Operators 3 Flow Junction: –FJ: in -> {out 1, out 2 }; –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.

15. 02/03/06Task-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).

16. 02/03/06Task-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”.

17. 02/03/06Task-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.

18. 02/03/06Task-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).

19. 02/03/06Task-Oriented, Policy Driven Business Requirements for Web Services 19 Holiday Example revisited –t 1 : allocate jobs –t 2 : choose destination –t 3 : choose budget –t 4 : find agencies –t 4 : query agency 1 –t 5 : query agency 2 –t 6 : query agency 3

20. 02/03/06Task-Oriented, Policy Driven Business Requirements for Web Services 20 Holiday Example cont. –t 8 : arrange two quotes in order of preference –t 9 : attempt to book primary choice –t 10 : attempt to book secondary choice –t 11 : exchange currency at bank A –t 12 : exchange currency at bank B

21. 02/03/06Task-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?