Web Service Composition workflow patterns in BPEL4WS

Document Sample
Web Service Composition workflow patterns in BPEL4WS Powered By Docstoc
					         Web Service Composition
       workflow patterns in BPEL4WS


                            Eyal Oren
•   Goal
•   Workflow Patterns
•   Supported by BPEL4WS
•   YAWL: Yet Another Workflow Language
•   Relevance to WSMO

                     Eyal Oren            2
• 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
• it‟s not expressivity, almost all Turing complete
  it‟s about suitability, direct support
   – how good (necessary) are the patterns?

                                   Eyal Oren          5
• 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       flow/link
(wait for all)

exclusive choice      switch/link
                      (if you want OR: no switch)

simple merge          switch/link
(one active branch)

                            Eyal Oren               7
          Advanced Patterns
multi-choice         link
sync. merge
(one or more)
multi-merge         no support
(one or more)
                                         A1 = audit_application
C as often as A1/A2                      A2 = process_application
                                         C = close_case
discriminator        no support
                     (join only evaluated after all links determined)
                                         paper accepted if both reviews positive, author notified
                                         if first=negative, notify author immediately
n-of-m join          no support
                                         paper accepted if all 2 out of 3 positive, author notified
                                         if 2=negative, notify author immediately

                             Eyal Oren                                                                8
              Structural Patterns
arbitrary cycles        no support
loops nested, ‘goto’
implicit termination    by default

multiple instances      flow, multiplying the number of
nr. known design time   instance invocations (hard code)

run time                no support
before initiation

run time, during        no support

                           Eyal Oren                       9
                        State-based Patterns
deferred choice                                     pick, based on messages
choose transportation based on then-available
interleaved par. routing                            serializable scopes
end-of-year: add-interest, charge yearly cost       (semantics unclear, depends on
in any order, but not at same time                  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
• 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
•   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
milestone                    multi-merge

                 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

Shared By: