1

Intention of slide setInform 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 Interfacehow entity can interact

Requested Interface1) send request2) select from offer3) receive confirmation

Goal

defines

VTA

VTA WS ‘Trip Booking’

Capability

Interface (Chor.)1) get request2) provide offer 3) receive selection4) send confirmation

Interface (Orch.)1) flight request2) hotel request 3) book flight4) book hotel

Flight WS

Capability

Interface (Chor.)1) get request2) provide offer 3) receive selection4) send confirmation

Orch. ..

Hotel WS

Capability

Interface (Chor.)1) get request2) provide offer 3) receive selection4) send confirmation

Orch. ..

provides

Requested Capabilitybook flight & hotel

Choreographyinteraction between entities

Orchestrationinteractions 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 ScenarioUser 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 Engineapproach existing in IRS

what we want to dowith 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 S

ervice Business Logic

1

2

3

4

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” Orchestrationas “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” Orchestrationas “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 request2) provide offer 3) receive selection4) send confirmation

Orch. ..

Hotel WS

Capability

Interface (Chor.)1) get request2) provide offer 3) receive selection4) send confirmation

Orch. ..

flight request

avaiable flights

hotel request

avaiable hotels

book request booking confirmation

book request

booking confirmation

this is what is achieved by running different SWS technologies on a

design time orchestration

15

Open Questions for WSMO1. 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