1 / 21

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. Background Information Web service architecture Current solutions; Motivation;

rhea-cook
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related