1 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

2 Terminology Clarification Behavior Interface how entity can interact Requested Interface 1)send request 2)select from offer 3)receive confirmation Goal defines VTA VTA WS ‘Trip Booking’ Capability Interface (Chor.) 1)get request 2)provide offer 3)receive selection 4)send confirmation Interface (Orch.) 1)flight request 2)hotel request 3)book flight 4)book hotel Flight WS Capability Interface (Chor.) 1)get request 2)provide offer 3)receive selection 4)send confirmation Orch... Hotel WS Capability Interface (Chor.) 1)get request 2)provide offer 3)receive selection 4)send confirmation Orch... provides Requested Capability book flight & hotel Choreography interaction between entities Orchestration 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.

3 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

4 D3.4 / D3.5 as meta-level ontologies M0: information layer M1: model layer M2: meta-model layer M3: meta-meta-model layer real data exchanged Concrete WSMO Element WSMO Ontology definition Language for describing M2 WSMO real data exchanged Concrete Service Interface descrip. D3.4 / D3.5 Language for describing M2 DIP WP 3 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

5 “DIP Service Interface Description Languages” (WSMO) Ontologies as data model: - every resource description based on ontologies - every data element interchanged is ontology instance Formal Description of SWS interfaces: - WSMO model (“sound formalism”), WSMO D14 - maybe extended, e.g. Events (see KMi) Cashew (work from Barry Norton, KMI): - a “process description model” for dynamics in Semantic Web services - based on a process algebra (subset of v. d. Aalst workflow pattners) - can be represented in UML2 - allows semantically translation to ASMs / WSMO model Grounding: - making service interfaces executable - currently grounding to WSDL - based on WSMO & IRS work DERI (UIBK, NUIG) OU for Choreography Engine like in WSMX / IRS DERI (NUIG), OU ILOG “Downwards Translation” SAP User language - basis for graphical UI for editing & browsing Service Interface Description - based on UML2 activity diagrams “upward translation”, graphical representation OU (Barry Norton)

6 Intended Tooling Scenario User Interface for creating WS Interface descriptions (e.g. WSMO Studio) Formal Description of Interface (‘extended’ WSMO Model) UML2 Activity Diagrams, based on workflow constructs SWS Technologies on formal model (e.g. Choreography Discovery, WSMX Process Mediation) Grounding / Execution (DIP / WSMX Choreography Engine, IRS Choreography Grounding) “Lowering / Lifting” by semantically defined translations on basis of Cashew aim of WSMX Choreography Engine approach existing in IRS what we want to do with Semantic Web Services SWS Technologies on workflow descriptions (e.g. ILOG composer)

7 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”

8 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”

9 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

10 Overall Picture -decomposition of service functionality -interaction with aggregated Web Services -all service interaction via choreographies Control Structure for aggregation of other Web Services and interaction behavior of orchestrating Web Service WS Web Service Business Logic WS State in Orchestration Control Flow Data Flow Service Interaction

11 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)

12 “design time” Orchestration as “process of goals” VTA VTA WS ‘Trip Booking’ Capability provides Chor. Interf. Flight Request Hotel Request Book Flight Book Hotel if hotel = Øflight.arrivaltime = hotel.arrivaltime flight information if flight = Ø hotel information process (control + data flow) of goals

13 “design time” Orchestration as “abstract composite goals” [ILOG] VTA VTA WS ‘Trip Booking’ Capability provides Chor. Interf. Flight Request Hotel Request Book Flight Book Hotel As basis / input for automated WS composition [ILOG approach] Constraints on workflow / process of composite WS (that is to be composed)

14 “execution time” Orchestration VTA VTA WS ‘Trip Booking’ Capability provides Chor. Interf. Flight Request Hotel Request Book Flight Book Hotel if hotel = Ø if flight = Ø process (control + data flow) between “states” + communication behavior of orchestrating Web Service Flight WS Capability Interface (Chor.) 1)get request 2)provide offer 3)receive selection 4)send confirmation Orch... Hotel WS Capability Interface (Chor.) 1)get request 2)provide offer 3)receive selection 4)send confirmation Orch... flight request avaiable flights hotel request avaiable hotels book requestbooking confirmation book request booking confirmation this is what is achieved by running different SWS technologies on a design time orchestration

15 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