Workflow patterns in BPEL4WS

Download Report

Transcript Workflow patterns in BPEL4WS

Web Service Composition
workflow patterns in BPEL4WS
http://tmitwww.tm.tue.nl/research/patterns/download/wfs-pat-2002.pdf
http://tmitwww.tm.tue.nl/research/patterns/download/bpel_er.pdf
http://www.big.tuwien.ac.at/research/publications/2003/0603.pdf
Eyal Oren
DERI
2004/06/02
Overview
•
•
•
•
•
Goal
Workflow Patterns
Supported by BPEL4WS
YAWL: Yet Another Workflow Language
Relevance to WSMO
Eyal Oren
2
Goal
• To analyse web service composition languages,
specifically BPEL4WS
• Focus on control flow
• Learn from workflow management research
• “industry ignores established formal process
modeling techniques: ignore the industry”
Eyal Oren
3
Bernauer et. al. –
Comparison Framework
• comparing interorganizational workflow
• different than intra-organizational workflow:
– interoperability
– autonomy (of participating organizations)
– trust, privacy and security
• requirements:
– re-usable workflow types (private/public, roles)
– profile specifications (organization, role, technology)
– implementation details (executable specification)
Eyal Oren
4
Workflow patterns
• workflow:
•
•
•
•
•
process (control flow)
information (data)
organization (resource)
operation (implementation)
integration
• gathered control-flow patterns
(www.workflowpatterns.com)
• it’s not expressivity, almost all Turing complete
it’s about suitability, direct support
– how good (necessary) are the patterns?
Eyal Oren
5
Patterns
• often-used patterns but often no direct support: providing
solutions in ‘simpler’ language
• can also be used to analyse language usability
(you would like direct support)
not 8,9
not 10
not 18
not 14,15
Eyal Oren
6
Basic Patterns
sequence
sequence
parallel split
flow (XLANG-style)
or link (WSFL-style)
synchronization
(wait for all)
flow/link
exclusive choice
switch/link
(if you want OR: no switch)
simple merge
(one active branch)
switch/link
Eyal Oren
7
Advanced Patterns
multi-choice
sync. merge
(one or more)
link
multi-merge
no support
(one or more)
C as often as A1/A2
discriminator
no support
A1 = audit_application
A2 = process_application
C = close_case
(join only evaluated after all links determined)
n-of-m join
no support
paper accepted if both reviews positive, author notified
if first=negative, notify author immediately
paper accepted if all 2 out of 3 positive, author notified
if 2=negative, notify author immediately
Eyal Oren
8
Structural Patterns
arbitrary cycles
loops nested, ‘goto’
no support
implicit termination
by default
multiple instances
nr. known design time
flow, multiplying the number of
instance invocations (hard code)
run time
before initiation
no support
run time, during
no support
Eyal Oren
9
State-based Patterns
deferred choice
choose transportation based on then-available
pick, based on messages
interleaved par. routing
end-of-year: add-interest, charge yearly cost
in any order, but not at same time
serializable scopes
(semantics unclear, depends on
transaction engine)
milestone
cancel order, if order placed, but only as long
as not shipped
no support
cancel activity/case
terminate
Eyal Oren
10
BPEL Summary
• BPEL supports a lot of patterns
(compared to languages considered)
• positive:
– expressive
• negative:
– should be simplified (WSFL, XLANG overlap)
– should be formalized
Eyal Oren
11
YAWL
• Petri nets for workflow modeling:
– formal semantics, yet graphical
– state-based (not just event-based)
– analysis techniques
• Problems:
– (keeping track of) multiple instances
– advanced synchronization patterns
(either AND or XOR, depending on context)
– cancellation pattern (vacuum cleaner)
• you can model everything, it just becomes unreadable
and unmaintainable
Eyal Oren
12
YAWL
•
•
•
•
•
•
•
Petri-net based language
Directly supports all patterns
Formal semantics
Control flow, data flow, operational perspective
Supports web services
Prototype software
Future:
– transactions, communication patterns
– analysis techniques/tools
Eyal Oren
13
YAWL Examples
multi-merge
milestone
Eyal Oren
14
Relevance to WSMO
• Orchestration is (or needs)
a way to describe composite processes
• Orchestration shouldn’t re-invent the wheel
• Orchestration should (partly) support patterns
• Orchestration should use either
– BPEL
– YAWL
Eyal Oren
15