internal seminar mar06

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

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

Outline: 

Outline Background Information Web service architecture Current solutions; Motivation; Foundational aspects; Policies; Operators; Further aspects: Negotiation; Cancellation; Holiday Example; Conclusions and further work.

Web Service Architecture: 

Web Service Architecture Composition often the top layer; Composition and orchestration still a blur! Little regard for a more abstract requirements layer.

Current Solutions 1: 

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

Current Solutions 2: 

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.

Motivation: 

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.

Foundational Aspects 1: 

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

Foundational Aspects 2: 

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.

Wedding Example: 

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.

Holiday sub-example: 

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.

Notation 1: 

Notation 1 Tasks and Composite Tasks: Flows: Control input and output; Data input and output; Resource?? External inputs; Error outputs.

Operators 1: 

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.

Operators 2: 

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.

Operators 3: 

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.

Cycles: 

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

Negotiation: 

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

Cancellation 1: 

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.

Cancellation 2: 

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

Holiday Example revisited: 

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

Holiday Example cont.: 

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

Conclusions: 

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?