task-oriented, policy driven business requirements elicitation for web services
DESCRIPTION
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. Background Information Web service architecture Current solutions; Motivation; - PowerPoint PPT PresentationTRANSCRIPT
Task-Oriented, Policy Driven Business Requirements Elicitation for Web Services
Stephen Gorton
Department of Computer Science, University of Leicester, University Road, Leicester LE1 7RH
02/03/06 Task-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.
02/03/06 Task-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 service service service
Composite service
Exportable service
02/03/06 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
02/03/06 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.
02/03/06 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.
02/03/06 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}.
02/03/06 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.
02/03/06 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.
02/03/06 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.
02/03/06 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.
02/03/06 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.
02/03/06 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.
02/03/06 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.
02/03/06 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).
02/03/06 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”.
02/03/06 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.
02/03/06 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).
02/03/06 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
02/03/06 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
02/03/06 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?