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

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.


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


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

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

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

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

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

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.


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

Notation 1

• Tasks and Composite Tasks:

• Flows:– Control input and output;– Data input and output;– Resource??– External inputs;– Error outputs.


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

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

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.


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

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

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

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

Holiday Example revisited

– t1: allocate jobs

– t2: choose destination

– t3: choose budget

– t4: find agencies

– t4: query agency 1




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


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 Elicitation for Web Services Stephen Gorton...

Documents

Transcript of Task-Oriented, Policy Driven Business Requirements Elicitation for Web Services Stephen Gorton...