Orchestrating Services with shortlived changes: the StPowla Approach - PowerPoint PPT Presentation

1 / 21
About This Presentation
Title:

Orchestrating Services with shortlived changes: the StPowla Approach

Description:

Joint work with Stephan Reiff-Marganiec, Carlo Montangero and Laura ... Process languages include BPEL and YAWL. Formal languages include StAC and -calculus ... – PowerPoint PPT presentation

Number of Views:40
Avg rating:3.0/5.0
Slides: 22
Provided by: sys126
Category:

less

Transcript and Presenter's Notes

Title: Orchestrating Services with shortlived changes: the StPowla Approach


1
Orchestrating Services with short-lived changes
the StPowla Approach
  • Stephen Gorton
  • Joint work with Stephan Reiff-Marganiec, Carlo
    Montangero and Laura Semini

2
Overview
  • The meaning of it all??
  • Business Processes and Workflows
  • A simple supplier model
  • Model Refinement
  • Model Reconfiguration
  • StPowla Overview
  • How SOA fits in
  • Workflows
  • Policies
  • Something more interesting
  • Some open issues
  • Summary

3
The meaning of it all?
  • Orchestration?
  • Composition?
  • Business Process?
  • Business Process Management?
  • Business Process Modelling?
  • Workflows?

4
Business Processes and Workflows
  • A set of scheduled abstract activities that
    contribute towards the satisfaction of a business
    goal.
  • BPs can be specified through natural language,
    graphical notation, process languages or formal
    languages (e.g. process algebra or logic).
  • Workflows are process templates, they have
    instances or cases.
  • Analogous to OO classes and instances.
  • Notations include UML Activity Diagrams and BPMN.
  • Process languages include BPEL and YAWL.
  • Formal languages include StAC and -calculus

5
A Simple Supplier Model
  • Supplier receives a valid order from a registered
    customer
  • Supplier packs the order
  • Supplier ships the order to the customer
  • Supplier invoices the customer
  • A simple workflow model

Receive order
Ship
Pack
Invoice
6
Varying the Model 1 Refinement
Receive order
Ship
Pack
Invoice
  • Shipping is done through a contractor.
  • We add the policy
  • message transfer should include 128-bit
    encryption
  • Only to the Ship task
  • No visible change to the workflow, but tasks
    specifications become more specific, i.e.
    refinement.

7
Varying the Model 2 Reconfiguration
Receive order
Ship
Pack
Invoice
  • The general process is fine, but
  • What if the order was in excess of Euro 250k?
  • The supplier might prefer to get some security
    for the order and request a deposit.
  • We add a policy that states
  • if the order is above Euro 250, then get a
    deposit before shipping.

Request Deposit
Receive order
Ship
Pack
Invoice
8
Case Study VoIP Pre-Delivery Process
Policy No test for small customers and orders of
small entity
Policy Avoid legal assistance for small orders
9
The Problem
  • Refinement
  • Our needs change frequently, but we dont
    necessarily want permanent changes.
  • In fact, sometimes we want changes for a short
    time only.
  • Reconfiguration
  • Only in some cases do we want to make a change.
  • This change can change itself!
  • Enter StPowla

10
Overview of StPowla
  • StPowla the Service-Targeted, Policy-Oriented
    WorkfLow Approach
  • Ingredients
  • Workflows
  • Present the core business model
  • Policies
  • Present system variability
  • Service Oriented Architecture
  • Implement the requirements of the end user

11
StPowla and SOA
  • Services are platform independent, hetereogenous
    software components, available through the
    Internet and are
  • Based on open standards
  • composable
  • optionally self-describing and discoverable
  • Services map to tasks as follows

data
control
data
task
service
error
side effect
compensate
data
error
control
data
12
StPowla Workflows
  • Workflows define the core process
  • In a graphical notation
  • Suitable for end users (e.g. business analysts)
  • Actually the workflow specification doesnt
    matter that much
  • The key thing is that a common set of breakpoints
    can be found

random choice
decision point
non-synchronising merge
sequence
parallel split
synchronising merge
strict preference
13
Workflow Breakpoints
  • A couple of slides ago
  • Plus 0a Workflow entry, 0b Workflow Success and
    0c Workflow failure

2a Service invocation/entry
1a Task entry
data
control
data
task
service
error
1b Task exit (success)
side effect
compensate
data
error
control
data
1c Task failure
2c Service failure
2b Service completion
14
StPowla Policies
  • We use the Appel policy description language
  • Specifies Event-Condition-Action (ECA) rules
  • Or goals (just As)
  • Needs some domain specific information to address
    all conditional values (e.g. ontology)
  • Appel has
  • A natural language expression
  • An XML syntax for system processing
  • Formal semantics via mapping to
  • Good for checking for the presence of conflicts

15
StPowla Default Policies
  • Policies in natural English syntax look like
    this
  • Every task has a default policy

Functional requirements specification of the task
SLA dimensions
Invocation parameters
16
Something a little more interesting
  • How exactly can we define reconfigurations
    exactly?
  • Consider this system overview
  • I briefly introduce two complimentary methods

This is where reconfigurations must be specified
This part has no knowledge of policy updates
17
A Process Calculi Approach
  • For system behaviour specification
  • Describes precisely to the programmer what should
    happen
  • Can be analysed easily and verified
  • We need constructs such as
  • Skip
  • Done
  • Fail
  • Sequence
  • Parallel
  • Choice
  • (Non-deterministic) Choice
  • Compensation
  • Scoping
  • Restriction
  • Insertion
  • Deletion
  • Communication

Note the last three constructs are missing!
18
A Graph Transformation Approach
  • For determining what we need to express in a
    policy to present the transformation rule
  • The type of change
  • The location of the change
  • We do not need to express the if part, this is
    done in the policy

Q
P
R
A
B
reconfigured by rule to
Q
P
R
A
C
B
19
Some Open Issues
  • Overarching constraints are not easy!
  • How can we calculate the total cost of the
    process if we dont know what services are going
    to be used?
  • But cant we use a policy?
  • Yes, but that still affects the rest of the
    process! (e.g. insertions)
  • When is it better to override the default policy
    and when is it better to add a new policy?
  • The compensation scoping problem
  • If Q fails, what do we compensate and where to?

20
Summary
  • Business processes are there to satisfy a
    business goal
  • But the requirements may change, especially over
    time
  • And those changes may change between cases!
  • StPowla is being developed to address refinement
    and reconfiguration of service-targeted
    workflows, from the point of the end user.
  • It consists of a graphical workflow specification
  • A set of policies
  • Service Oriented Architecture
  • Formal specification of short-lived
    reconfigurations?
  • With process calculi
  • And graph transformations.

21
Thank you for listening
  • Any Questions?
Write a Comment
User Comments (0)
About PowerShow.com