Intention of slide set

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 VTA Behavior Interface how entity can interact Capability • Interface (Chor.) • get request • provide offer • receive selection • send confirmation Flight WS • Orch. • .. defines provides Goal Capability • Interface (Chor.) • get request • provide offer • receive selection • send confirmation VTA WS ‘Trip Booking’ • Interface (Orch.) • flight request • hotel request • book flight • book hotel Requested Capability book flight & hotel • Requested Interface • send request • select from offer • receive confirmation Capability • Interface (Chor.) • get request • provide offer • receive selection • send confirmation Hotel WS • Orch. • .. 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 • “Design Time Orchestration”: a specification of the functional decomposition of a Web service functionality by its provider, described as a “process of goals / capabilities” • “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 WSMO DIP WP 3 Language for describing M2 Language for describing M2 M3: meta-meta-model layer WSMO Ontology definition M2: meta-model layer D3.4 / D3.5 Concrete WSMO Element Concrete Service Interface descrip. M1: model layer real data exchanged real data exchanged M0: information layer • 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” User language - basis for graphical UI for editing & browsing Service Interface Description - based on UML2 activity diagrams ILOG “upward translation”, graphical representation 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 OU (Barry Norton) “Downwards Translation” SAP Formal Description of SWS interfaces: - WSMO model (“sound formalism”), WSMO D14 - maybe extended, e.g. Events (see KMi) DERI (UIBK, NUIG) OU for Choreography Engine like in WSMX / IRS DERI (NUIG), OU (WSMO) Ontologies as data model: - every resource description based on ontologies - every data element interchanged is ontology instance Grounding: - making service interfaces executable - currently grounding to WSDL - based on WSMO & IRS work

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

7. D3.5 “Choreography”Structure Proposal conceptual model is exactly the same as what we do in WSMO (i.e. Choreography Interface descriptions) • Introduction • Conceptual Model • what we are talking about • why we what to describe what (global picture) • Example • Related Work • Existing work • Differences & explanation for this • Compatibility / Impact to standards • Conclusions Appendix: “DIP Service Interface Description Languages”

8. D3.4 “Orchestration”Structure Proposal • Introduction • Conceptual Model • what we are talking about • why we what to describe what (global picture) • Example • Related Work • Existing work • Differences & explanation for this • Compatibility / Impact to standards • 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. WS WS State in Orchestration Control Flow Data Flow Service Interaction Overall Picture Control Structure for aggregation of other Web Services and interaction behavior of orchestrating Web Service 1 Web Service Business Logic 3 • decomposition of service functionality • interaction with aggregated Web Services • all service interaction via choreographies 2 4

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” Orchestrationas “process of goals” Flight Request VTA if hotel = Ø flight.arrivaltime = hotel.arrivaltime provides Capability Hotel Request • Chor. • Interf. VTA WS ‘Trip Booking’ if flight = Ø flight information Book Flight hotel information Book Hotel process (control + data flow) of goals

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

14. “execution time” Orchestration Capability • Interface (Chor.) • get request • provide offer • receive selection • send confirmation Flight WS • Orch. • .. flight request Flight Request VTA avaiable flights if hotel = Ø provides book request booking confirmation Capability Capability hotel request Hotel Request • Interface (Chor.) • get request • provide offer • receive selection • send confirmation Hotel WS • Orch. • .. • Chor. • Interf. VTA WS ‘Trip Booking’ avaiable hotels if flight = Ø 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

15. Open Questions for WSMO • Formal Semantics of WSMO Service Interfaces Description Language • are nearly finished (cf. Axel) • when expected to be completed? • 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? • 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