Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

DIP

VIEWS: 34 PAGES: 15

									                   Intention of slide set
                          Inform WSMOLX of what is planned for
                            Choreography & Orhestration in DIP

CONTENTS

•   Terminology Clarification / what will be described

•   Structure of deliverables
     –   a meta-level description ontology for each Chor & Orch
     –   a common “integrated set of description languages for SWS Interfaces”

•   DIP Choreography Ontology (D3.5)
     –   Aims / Content
     –   Deliverable Structure
•   DIP Orchestration Ontology (D3.4)
     –   Aims / Content & Deliverable Structure
     –   “design time” and “executable” orchestration specifications
     –   DIP Orchestration Ontology description elements

•   Open Questions for WSMO

                                                                                 1
                      Terminology Clarification
                                                            VTA                                                      Capability

                                                                                              Interface (Chor.)                   Orch.
    defines                                          provides                                 1) get request                      ..
                                                                                                                     Flight WS
                                                                                              2) provide offer
                                                                                              3) receive selection
         Goal                                              Capability
                                                                                              4) send confirmation
Requested Capability              Interface (Chor.)                       Interface (Orch.)
                                  1) get request                          1) flight request
book flight & hotel                                         VTA WS
                                  2) provide offer                        2) hotel request
Requested Interface               3) receive selection   „Trip Booking‟   3) book flight                             Capability
1) send request                   4) send confirmation                    4) book hotel
2) select from offer                                                                          Interface (Chor.)                   Orch.
3) receive confirmation                                                                       1) get request         Hotel WS     ..
                                                                                              2) provide offer
                                                                                              3) receive selection
                                                                                              4) send confirmation



 Behavior Interface                                      Choreography                              Orchestration
 how entity can interact                     interaction between entities                        interactions with
                                                                                                  aggregated WS for
                                                                                               realizing functionality
              Terminology Definitions from:
              Barros A.; Dumas, M.; Oaks, P.: Standards for Web Service Choreography and Orchestration: Status and
              Perspectives. In Proc.of 1st International Workshop on Web Service Choreography and Orchestration for
              Business Process Management at the BPM 2005, Nancy, France, September 2005.
                                                                                                                                  2
      DIP Chor. / Orch Ontologies
•   Each M2-layer ontology needs to define:
     –   Conceptual Model (what & why)
     –   Detailed Description Elements Specification (really detail)
     –   Showcase usage in simple scenario
     –   Related Work / Discussion / Standard Compatibility

WHAT we need to describe (I think so):
• Behavior / Choreography Interface & Orchestration of Semantic Web Services (=
  WSMO Service Interfaces)
• NOT Choreography (= interaction protocol), reasons:
     –   Web service interaction happens in a peer-2-peer manner
     –   For determining whether the interaction of 2 .. N services / clients can be executed
         successful, we only need to determine whether there exists a valid interaction protocol wrt
         the behavior interfaces of interacting Web services (“Choreography Discovery” as in WIW
         2005 paper)
     –   Choreography (= global interaction protocol) descriptions like done in WS-CDL are optionally
         and might be a future aspect
•   For Orchestration (below more explanation): 2 types
     1. “Design Time Orchestration”: a specification of the functional decomposition of a Web
        service functionality by its provider, described as a “process of goals / capabilities”
     2. “Executable Orchestration”: detailed specification of service2service interactions that is
        achieved after running several mechanisms (e.g. discovery, composition, conversation
        validation) on the „design time orchestration‟; serves as basis for executing service2service
        interactions
                                                                                                        3
 D3.4 / D3.5 as meta-level ontologies
          WSMO                                                       DIP WP 3

Language for describing M2   M3: meta-meta-model layer     Language for describing M2

WSMO Ontology definition        M2: meta-model layer              D3.4 / D3.5

Concrete WSMO Element              M1: model layer       Concrete Service Interface descrip.

 real data exchanged             M0: information layer      real data exchanged



        • D3.5 is about Choreography Interfaces description
        • D3.4 is about Orchestration description
        • each document will have an appendix with a document “DIP
         Service Interface Description Languages” that defines the
         „integrated description languages” used for both
         Choreography Interfaces and Orchestration description

                                                                                         4
           “DIP Service Interface Description Languages”

                            User language
                            - basis for graphical UI for editing & browsing Service
                              Interface Description                                          ILOG
                            - based on UML2 activity diagrams

                                                             “upward translation”, graphical representation

                     Cashew (work from Barry Norton, KMI):
                     - a “process description model” for dynamics in Semantic Web services       OU (Barry Norton)
                     - based on a process algebra (subset of v. d. Aalst workflow pattners)
                     - can be represented in UML2
                     - allows semantically translation to ASMs / WSMO model

                                                             “Downwards Translation” SAP

                               Formal Description of SWS interfaces:
       DERI (UIBK, NUIG)       - WSMO model (“sound formalism”), WSMO D14                      for Choreography Engine
                     OU        - maybe extended, e.g. Events (see KMi)                         like in WSMX / IRS
                                                                                               DERI (NUIG), OU


(WSMO) Ontologies as data model:                                      Grounding:
 - every resource description based on ontologies                     - making service interfaces executable
 - every data element interchanged is ontology instance               - currently grounding to WSDL
                                                                      - based on WSMO & IRS work



                                                                                                                     5
         Intended Tooling Scenario
                                 User Interface for creating           UML2 Activity Diagrams,
                                 WS Interface descriptions             based on workflow constructs
                                   (e.g. WSMO Studio)
   SWS Technologies
on workflow descriptions                            “Lowering / Lifting” by semantically defined
 (e.g. ILOG composer)                               translations on basis of Cashew


                               Formal Description of Interface
                                 („extended‟ WSMO Model)
  what we want to do                                            aim of WSMX Choreography Engine
  with Semantic Web Services                                    approach existing in IRS


  SWS Technologies on formal model                        Grounding / Execution
    (e.g. Choreography Discovery,                  (DIP / WSMX Choreography Engine,
     WSMX Process Mediation)                          IRS Choreography Grounding)


                                                                                                   6
                 D3.5 “Choreography”
                  Structure Proposal
conceptual model is exactly the same as what we do in WSMO (i.e.
              Choreography Interface descriptions)

1. Introduction
2. Conceptual Model
    •   what we are talking about
    •   why we what to describe what (global picture)
3. Example
4. Related Work
    –   Existing work
    –   Differences & explanation for this
    –   Compatibility / Impact to standards
5. Conclusions

Appendix: “DIP Service Interface Description Languages”



                                                               7
              D3.4 “Orchestration”
               Structure Proposal
1. Introduction
2. Conceptual Model
   • what we are talking about
   • why we what to describe what (global picture)
3. Example
4. Related Work
   – Existing work
   – Differences & explanation for this
   – Compatibility / Impact to standards
5. Conclusions

Appendix: “DIP Service Interface Description Languages”
                                                          8
       Orchestration Properties
• Orchestration provides a technique that allows service providers to
  realize the functionality of a Web service by aggregation of other
  Web services
• An Orchestration … :
   – describes those aspects of the internal (private) business process of a
     Web Service where functionality of other Web services is utilized
   – is only the description (not how this is achieved) of how other Web
     services are aggregated in order to achieve the functionality of the
     orchestrating Web services
   – contains the control and data flow of the decomposed service
     functuionality and the interaction of the orchestrating Web services with
     the aggregated ones
   – denotes a multiple service interaction controlled by one entity
• All interaction happens between the Behavior Interfaces of the
  aggregated Web Service
• can be automatically generated by composition if the engine results
  in a complete orchestration description


                                                                            9
                                           Overall Picture
Control Structure for aggregation of other Web Services
and interaction behavior of orchestrating Web Service
  Web Service Business Logic




                                                           State in Orchestration
                                                           Control Flow
                                   1
                                               WS          Data Flow
                                                           Service Interaction
                                           3

                               2                      - decomposition of
                                                        service functionality
                                       4       WS     - interaction with
                                                        aggregated Web
                                                        Services
                                                      - all service interaction via
                                                        choreographies


                                                                                    10
              Orchestration Types
[new aspect] it appears to be beneficial to have:

1) “Design Time” Orchestration Description
    – functional decomposition of orchestrating Web service (aspects of private
      business process where functionality of other Web services are used)
    – concrete Web services to be used (aggregated) are not known
    – specifies control & data flow + requested functionalities
    – described as a “process of goals / capabilities”

2) “Execution Time” Orchestration Description
    – concrete Web services to be used (aggregated) are known; determined by
      running various SWS mechanisms (e.g. discovery, composition, conversation
      validation)
    – specifies control & data flow + communication behavior of orchestrating Web
      service for consuming aggregated Web services
    – described as “process of communication”; communication similar to
      Choreography Interface descriptions
    – serves as basis for orchestration execution (i.e. attaining the functionality of the
      orchestrating Web serivce by consuming aggregated Web services)


                                                                                       11
                    “design time” Orchestration
                       as “process of goals”

                                       Flight Request
             VTA
                             if hotel = Ø          flight.arrivaltime = hotel.arrivaltime
      provides

            Capability
Chor.                                       Hotel Request
Interf.                    if flight = Ø
             VTA WS
          „Trip Booking‟                                 flight information

                                     Book Flight


                                                                    hotel information
                                            Book Hotel




                               process (control + data flow) of goals
                                                                                            12
           “design time” Orchestration
      as “abstract composite goals” [ILOG]

                                          Flight Request
             VTA
      provides                             Hotel Request
            Capability                                     Constraints on workflow / process
                                                                   of composite WS
Chor.                                     Book Flight
Interf.                                                        (that is to be composed)
             VTA WS
          „Trip Booking‟
                                           Book Hotel




                         As basis / input for automated WS composition [ILOG approach]
                                                                                               13
                           “execution time” Orchestration

                                                                                                                  Capability

                                                                                           Interface (Chor.)                   Orch.
                                                                 flight request            1) get request                      ..
                                                                                                                  Flight WS
                                            Flight Request                                 2) provide offer
                                                                                           3) receive selection
             VTA                                                     avaiable flights      4) send confirmation
                               if hotel = Ø
      provides
                                                                book request          booking confirmation
                                                                                                                  Capability
            Capability
                                                                     hotel request
Chor.                                       Hotel Request                                  Interface (Chor.)                   Orch.
                                                                                           1) get request         Hotel WS     ..
Interf.
             VTA WS         if flight = Ø                           avaiable hotels        2) provide offer
          „Trip Booking‟                                                                   3) receive selection
                                                                                           4) send confirmation

                                        Book Flight
                                                             book request
                                                                            booking confirmation

                                               Book Hotel
                                                                                  this is what is achieved by running
                                                                                   different SWS technologies on a
                                                                                        design time orchestration
        process (control + data flow) between “states”
    + communication behavior of orchestrating Web Service
                                                                                                                           14
     Open Questions for WSMO
1.   Formal Semantics of WSMO Service Interfaces Description
     Language
     –   are nearly finished (cf. Axel)
     –   when expected to be completed?
2.   What type of ASMs are used?
     –   IMHO: only basic ASMs
             •      You only need multi-agent ASMs when concerned with multiple party
                    interactions
             •      Both Chor & Orch in WSMO / SWS are descriptions of interfaces of single
                    WS (we do not describe global interaction protocols as this is contradictory to
                    peer-2-peer idea of WS interactions)
     –   Correct?
3.   Completed examples needed for demonstration / showcasing
     –   Chor: Amazon-example in WSMO D14
             •      Is this finished / complete?
             •      If not, when expected?
     –   Orch: is there any example?

This is required input for the DIP meeting on Chor & Orch
     –   fixing the presented model
     –   10th – 11th October in Marseille
     –   Follow-up presentation of Cashew and DIP model                                         15

								
To top