Web Service Composition workflow patterns in BPEL 4
Web Service Composition workflow patterns in BPEL 4 WS 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 BPEL 4 WS YAWL: Yet Another Workflow Language Relevance to WSMO Eyal Oren 2
Goal • To analyse web service composition languages, specifically BPEL 4 WS • 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 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 switch/link (one active branch) Eyal Oren 7
Advanced Patterns multi-choice sync. merge (one or more) link multi-merge (one or more) C as often as A 1/A 2 no support discriminator no support A 1 = audit_application A 2 = process_application C = close_case (join only evaluated all iflinks determined) paperafter accepted both reviews positive, author notified if first=negative, notify author immediately n-of-m join no support Eyal Oren paper accepted if all 2 out of 3 positive, author notified if 2=negative, notify author immediately 8
Structural Patterns arbitrary cycles loops nested, ‘goto’ no support implicit termination by default multiple instances flow, multiplying the number of nr. known design time instance invocations (hard code) run time before initiation no support run time, during no support Eyal Oren 9
State-based Patterns deferred choice pick, based on messages choose transportation based on thenavailable 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 no support cancel order, if order placed, but only as long as not shipped 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
- Slides: 15