The Choreography research goal consolidates and drives all research in the area of Choreography at DERI Innsbruck. More specifically, on the Web and in Semantically-Enabled Service-Oriented Architectures (SESOA).
Leader: James Scicluna
- 1 Mission Statement
- 2 Team
- 3 Roadmap
- 3.1 Current Status
- 3.2 Future Steps
- 4 Publications
- 5 Implementations
- 6 Contributing Projects
The Choreography part of SEE is meant to provide a process language which should allow for formal specifications of interactions and processes between the service provideres and clients, define reasoning tasks that should be performed using this language, and implement an engine to support the execution of interactions, as well as to support reasoning in this language.
On a short term, the Choreography Component in the SEE architecture has three main responsibilities:
- Evaluating the transition rules defined in the Choreography Interface descriptions in WSMO Web Service descriptions
- Determines the legal instances for the last choreography step
- Appropriately managing invocation requests to and from the Communication Manager
During the first step, the interface descriptions are either fetched from the Resource Manager Service or appropriately parsed from the description (this depending on whether the requester sends her/his own descriptions). Once the choreographies of both parties are initialized, the start of the conversation is triggered by the instance data sent by the requester. This leads to the second step where the conversation is handled. During the interaction between the two choreographies, the data being exchanged is appropriately checked for conformance with respect to the choreography description and is always sent through the Process Mediation which determines which kind of data should be sent (if any) to the other party. Furthermore, during the evaluation of the rules, the choreography engine sets up the data required for invocation from the choreography description. The Choreography Engine does not perform the invocation itself but it rather forwards the invocation data to the Communication Manager which then processes this information appropriately and performs the invocation. The interaction between the two parties stops when either a choreography fails or all the required input data from the requester is consumed.
Dumitru Roman James Scicluna Thomas Haselwanter
This section outlines the work related to this component that has been already carried out. We will first describe the status of the model, the language related tasks and then carry on with the design and implementation of the component itself.
The model for WSMO Choreographies is currently stable. It is inspired by the ASM methodology and inherits the core principles such as the state, transition rules and flexibility to model any kind of behaviour.
The syntax of the choreography language has been defined as a result of the model. It is similar to the ASM language with some obvious constructs that have been introduced in order for it to fit with the WSML language. The semantics are defined using a set-based approach and describe the operational behaviour of choreographies on the same lines as for ASMs.
WSMO4J Choreography API
The work of the Choreography API has been divided in different parts, namely, the API (i.e. the interfaces), the implementation, the parser and the serializer. The API defines the interfaces and methods (with no implementation) for the objects within the language constructs. The implementation part implements the interfaces so that a user can easily create and manage the language constructs. The parser loads up an object model representation in the memory from a choreography description in a WSML file. The serializer, performs the reverse operation, that is, it saves the memory representation of the language to the equivalent syntax representation in a WSML file. All of these modules have been completed.
The main steps involved in the implementation of the choreography engine are the design – with particular emphasis on the interaction with other WSMX components – and the actual programming. Both of these aspects are in a stable condition but eventually they evolve as WSMX gets better and as requirements change.
The future steps consist of three core tasks that will run in parallel, and will follow an iterative approach:
Task 1: define reasoning tasks for interactions/process descriptions
Since Semantic Web Services are about providing a higher degree of automation when dealing with services, the tasks that need automation in this context need to be identified and clearly defined before conceptual models and languages are provided to support automation of such tasks. Since choreography is related to interactions and processes, this task will identify and define what reasoning tasks are needed when dealing with interactions and processes as far as services are concerned. One particularly interesting reasoning task is that of compatibility checking between choreography interfaces, that is, determining whether two choreography interfaces can successfully communicate with each other. Other related problems will also be considered in the course of our research.
Task 2: define higher level languages to directly support the tasks identified in task 1
The current language for representing WSMO Choreographies is based on ASMs – a very general model for describing computations. Because of its generality, the model was not designed with the focus to support automation of specific tasks related to interactions and processes. Thus, the current model (and language) will need to be constrained in some ways in order to allow for efficient reasoning and direct support for the identified reasoning tasks. The approach we will follow is that of formalizing Workflow Patterns (a procedural specification) and DecSerFlow Relations (a declarative specification) with CTR (Concurrent Transaction Logic). We will then combine these formalizations into a Declarative & Procedural Specification and Execution language and continue towards solving the identified reasoning tasks using such a language.
Task 3: implement an execution tool for interactions/processes
The choreography engine will have to incorporate and implement integrated support for both executions of processes, as well as for reasoning about the processes. Thus, the choreography implementation will address the execution of the processes and also integration with IRIS platform in order to perform the required reasoning tasks.
José-Manuel López-Cobo, Alejandro López-Pérez and James Scicluna: A Semantic Choreography-driven Frequent Flyer Program in Proceedings of the Future Research Challenges of Software and Services Workshop, Vienna (Austria), April, 2006
James Scicluna and Axel Polleres: Semantic Web Service Execution for WSMO Based Choreographies in Proceedings of the Semantic Web Applications Workshop, EuroMedia ’2005, Toulouse (France), April, 2005
- Syntax Specification
- Choreography API for WSMO4J
- Choreography Engine (ongoing)