A Pathak

D Cukier

F Besson

F Kon

T Colucci

G Silingas

De Angelis

R Mazza

A Ben Hamida

UOI), F. KON (USP A Zarras

H Vincent

Keywords: IDRE, Requirements, Service Choreography, Service Composition, Choreography Enactment, Runtime, Middleware, ESB, Future Internet, Large Scale, Design, Development, Governance, Monitoring CHOReOS

The goal of this document is to elucidate the requirements that the various actors involved with future Internet choreographies will have from the CHOReOS Integrated Development and Runtime Environment (IDRE). Since the IDRE integrates the work performed in the work packages WP 2 -4, the aforementioned requirements lead to the specification of requirements for WP 2 -4, specifically those requirements which will govern how they will integrate with each other.

We base our work on the conceptual model of CHOReOS defined in D1.2, and first present the main concepts used while discussing the IDRE, including the actors and use cases. This is followed by an exhaustive list of requirements pertaining to each functionality that the IDRE will provide with regard to design, development and deployment of choreographies.

Acronyms & abbreviations

Choreography (in general): it is a multi-party and decentralized protocol that when put in place by the cooperating parties will permit to reach the overall choreography goal (i.e. its business purpose). In reaching the overall goal each party in general pursues a local goal, which often is related to its business. Each party in choreography can derive a precise protocol that it has to use in order to interact with the other partners with which it has a direct contact.

Choreography (of services): as a specialization of the previous definition in the SOA context, it is a composition of distributed (Web) Services in which there is no single point of control, i.e., control is distributed. Usually, choreographies are composed of heterogeneous collaborating services built by different groups and executed in multiple administrative domains..

Choreography Design:

This process involves the specification of the choreography at a high level, using a dedicated modelling language, and based on the goal and requirement provided by the domain expert and consumers.

Choreography Development: This process produces (possibly with partial human intervention/inspection) the abstract proxies/adaptors that, supported by the CHOReOS serviceoriented middleware, will enact choreographies at runtime.

Enactment (of a choreography):

It is the process that makes a choreography come to existence at runtime, through the realization of its goals (global and locals). Enactment involves locating and instantiating services to participate in the composition. It also involves dynamically establishing the bindings among these services. This process includes deployment of proxies/adaptors and their execution. Typically, enactment of a complex choreography is performed incrementally at multiple times by multiple administrators or operators in multiple administrative domains.

Runtime: the meaning of this word depends on the context. Used as in "(...) at runtime", means that an event takes place during system execution. Used as in "the Runtime (...)", designates a system (e.g., middleware, tooling) that supports this execution.

Hereafter, the CHOReOS Runtime (with a capital 'R') is a collection of libraries, services, and middleware components that support choreography enactment. This comprises facilities for monitoring, V&V, fault-tolerance, and dynamic reconfiguration and adaptation of choreographies.

Service Contract: Is comprised of one or more published documents that express meta information about a service. The fundamental part of a service contract consists of the service description documents (as WSDL definition, XML schema definition, WS-Policy definition, and Service Level Agreement (SLA)) that express its technical interface. These form the technical service contract, which essentially establishes an API into the functionality, offered by the service. Introduction .................................................................................................................. 2 2.2. Actors and use cases ................................................................................................... 3. 1. IDRE main features ...................................................................................................... 7 3.2. Feature related requirements ....................................................................................... 7 3.2.1. Choreography design requirements .................................................................. 9 3.2.2. Choreography development requirements ...................................................... 11 3.2.3. Choreography enactment requirements .......................................................... 13 3.2.4. Choreography governance and monitoring requirements ............................... 15 3.3. IDRE implementation requirements ........................................................................... 17 3.3.1. IDRE design requirements .............................................................................. 18 3.3.2. IDRE development requirements .................................................................... 20 3.3.3

Introduction: document rationale

Software integration is an important activity in the software engineering process. It relies on an integration plan, a set of collaborative development tools and well identified software development guidelines. This work package deals with the entire integration process of all software components produced in WP2, WP3 and WP4 into one platform, called the CHOReOS Integrated Development and Runtime Environment (IDRE). This process is based on four main tasks. The first fundamental task is to identify major integration requirements that need to be satisfied. Second, a design activity is undertaken on the basis of the requirements. Third, the valid execution of the IDRE needs to be assessed with implemented test beds. The fourth task of providing the collaborative development tools and platforms and disseminating the CHOReOS results will be carried out in parallel with other tasks.

This deliverable (D5.1) is the result of the first task mentioned above, and provides integration requirements. The functionalities introduced in Section 4 of D1.2 --Conceptual model for choreography-based Future Internet --are considered as a starting point. Also, since the CHOReOS IDRE is geared towards to Ultra Large Scale systems, we need to cope with Future Internet Challenges such as Scalability, Heterogeneity, Mobility, Awareness and Adaptabiliy (as defined in Section 2.1.2 of D1.2; and take them into account in the integration requirements.

The rest of this document is organized as follows:

 Chapter 2 deals with the definition of an overall view of the CHOReOS IDRE. It recalls and classifies the functionalities discussed in D1.2. This chapter separates the IDRE into the Development and Runtime environments and identifies the specific functionalities related to them. We also identify actors and use cases, and classify the latter according to related requirement types and the CHOReOS concerns.  Chapter 3 provides a threefold approach to integration requirements. First in Section 3.1 the overall requirements from the IDRE (its main features) and their priority levels are introduced. Then, in Section 3.2, requirements are listed for each feature -choreography design, development and enactment. Section 3.3 deals with the IDRE Implementation requirements, categorised according to whether they are related to the design, development or deployment feature of the IDRE.  Finally, Chapter 4 (an annex) presents an early work identifying the requirements in the "Passenger Friendly Airport" case study. An overview of the case study is presented and a list of requirements is elucidated. FP7-257178

CHOReOS IDRE overview

Introduction

In CHOReOS, WPs 2, 3, and 4 develop techniques for development, enactment, and monitoring of choreographies for the ultra large-scale future Internet. The entity that integrates the distinct but inter-related components resulting from this research is the CHOReOS Integrated Development and Runtime Environment (IDRE). This section provides an overview of the CHOReOS IDRE, and provides description of IDRE actors and use cases based on consolidating the information introduced in the CHOReOS conceptual model in D1.2. The use cases and actor definitions are then used in Section 3 to elicit the initial set of IDRE requirements.

CHOReOS IDRE high-level overview

The high-level representation of the overall structure and functionalities of the CHOReOS IDRE is shown in Figure 1. The IDRE, as its name suggests, consists primarily of the Development and Runtime environments. The figure maps the concerns discussed in the CHOReOS conceptual model (see D1.2) onto these two components of the IDRE. It also associates the key actors in CHOReOS (further defined in Section 2.2) with the components.

From a functionality point of view, the IDRE will be used to design, develop and enact choreographies, as well as monitor, test and debug them. From a technical standpoint, the final purpose of the IDRE is to produce an enacted choreography, from a context (which includes expert requirements, choreography specification, available related models, etc.), taking into account the execution environment (which includes available services).

The enactment of a choreography will be supported by the CHOReOS Middleware defined in WP3. Also, the CHOReOS Runtime should also have support for awareness and adaptability; this means that if there are any modifications to the execution environment, the system should be able to adapt to them to ensure ongoing enactment of the choreography while still satisfying its global requirements. Another aspect is that a domain expert should be able to make modifications to the initial requirements during runtime; thus the development and runtime environment work in synergy.

Actors and use cases

Defining actors and use cases for the CHOReOS IDRE enables the identification of the main functionalities and stakeholders of the system. This section describes the actors involved in the CHOReOS use cases, as defined in D1.2 various use case diagrams, and discussed below. We recall their definitions from the CHOReOS conceptual model where necessary. Their associations with the IDRE components can be seen in Figure 1.

First, related to CHOReOS Development Environment, we identify the following actors, as was elicited in document D1.2:  Domain expert. A domain expert has the responsibility of defining, among other things, global choreography requirements, in order to produce goal-based models of services and service-based applications. It includes the definition of high-level business needs where both the domain expert and the (service) consumer (see definition below) can specify business high-level requirements. These can be represented using a structured natural language, as will be investigated in WP2.  Choreography designer. This actor has the responsibility of defining and/or finalizing the specification of the choreography, using the BPMN 2.0 modelling language and based on the refinement of the previously obtained domain expert specification by means of a top-down transformational process. The choreography designer is also responsible for the definition of the governance and analysis parameters that will be considered later by the CHOReOS work package 4 "Governance and V&V".  Choreography developer. The developer has the responsibility of writing source-code for Web services, requesting bytecode generation, creating configuration files, writing and executing tests, and debugging services.  Governance manager. This actor manages the governance of services and their choreographies, Service Level Agreements (SLAs) and their Life Cycles, policies for services, choreographies and SLAs. This actor also interacts with the CHOReOS Runtime system.

The following actors in CHOReOS interact primarily with the CHOReOS Runtime Environment:  Operator. An operator is an actor who has the responsibility of launching the enactment of a choreography, following the design phase. An operator may also monitor and enforce the system at runtime. The operator can also deploy, enable or disable a specific choreography. Finally, at runtime the operator is able to update the specification requirements that need to be taken into consideration.  Consumer. A choreography consumer can be a person or an application or a service that calls some business functionality of a given choreography. Calling choreography can trigger choreography or an orchestration process.  Service provider. A service provider is responsible for publishing services and SLA templates including the services behaviour according to runtime parameters. This actor relates to the discovery concern of D1.2 and also activates testing activities to test specific services.  Runtime system. In this actor, we combine the actors "Broker", "Message Broker", and "Run-time system" from the CHOReOS conceptual model of D1.2. This actor then is involved in service discovery and publishing, messaging between services, as well as executing a testing session to evaluate a service.  Communication party. The Communication party is an actor which performs exchange of messages with other Communication party.

The

IDRE global requirements

The main features of the IDRE are detailed in the form of requirements in Section 3.1. Following that, the requirements pertaining to these features are described in Section 3.2 and its sub-sections (one for each main feature of the IDRE). These requirements will serve as input to software components designed and developed in:  WP2 -Dynamic development of adaptable, QoS-aware ULS choreographies,  WP3 -Service-Oriented Middleware for the Future Internet  WP4 -Governance and V&V support for choreographies for the Future Internet

For each requirement we also point out the related concern(s), the involved CHOReOS work packages, and finally the proposing partners.

General requirements also encompass the design and implementation of the IDRE itself by the CHOReOS partners. These requirements, described in section 3.3, are oriented towards easing the integration of the components to be developed within WP2-3-4 during the lifetime of the CHOReOS project. Finally, in this section, we make reference, to already established early business requirements from the "Passenger Friendly Airport" use case from WP6 (see Annexe A -Airport Case Study requirements).

Terminology Reminder for requirements

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (http://tools.ietf.org/html/rfc2119):

 MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.  MUST NOT: This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification.  SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.  SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.  MAY: This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.  Requirements priority levels:

 VERY LOW: Do if there is enough available time before the end of the project  LOW: Nice to be delivered by the end of the project but not required  MEDIUM: Important to be delivered by the end of the project  HIGH: Essential to be delivered by the end of the project  VERY HIGH: Fundamental pieces that must be done first so we can progress FP7-257178

IDRE main features

Goal: describe the main features of the IDRE as requirements on the IDRE, while other tables in following section 3.2 describe all the specific requirements pertaining to these features.

ID Name Priority Description WP

IDRE-FEA-001

Choreography design

VERY HIGH

The IDRE SHALL support the design of ultra large scale (ULS) choreographies. This includes the fact of having the needed specification language elements expressing choreographies.

WP2

IDRE-FEA-002

Choreography development

VERY HIGH

The IDRE SHALL support the development and implementation of ULS choreographies.

WP2

IDRE-FEA-003

Choreography enactment

VERY HIGH

The IDRE SHALL support the enactment of choreographies on top of ultra large scale systems. The CHOReOS middleware needs to cope with Future Internet environments and hence targets the enactment of choreographies and services on top of scalable, hetergeneous and highly mobile infrastructures as distributed service bus, smart devices and cloud platforms.

WP2-3

IDRE-FEA-004

Choreography governance and monitoring

HIGH

The IDRE SHALL support the governance, V&V and monitoring of choreographies for the Future Internet.

WP3-4

Feature related requirements

Goal: describe the main requirements associated with the functionalities of the IDRE

The functionalities that the IDRE shall provide are related to the activities of the WP2 development process shown in Figure 2. Such a process is in an early stage and will be refined and enhanced by WP2 throughout the duration of the project. However, by exploiting model-driven techniques, the final goal is to devise a systematic development of choreographies from their design to their execution. The main activities of the process in Figure 2 are represented with ellipses, whereas the artifacts and the models, which are produced and that the IDRE shall be able to manage, are represented with boxes. FP7-257178

Figure 2 -WP2 development process

The IDRE shall support two orthogonal transformational approaches: (i) a top-down transformation process and (ii) a cross-cutting transformation process. The former will serve to refine a domain-expert requirements specification into analysis-technique-specific models. The latter will serve to integrate the different modeling/reasoning technologies by passing from a technique-specific model to a different one. This will bridge the gap between the various models that have to be used for choreography specification, analysis, validation, and synthesis. Moreover, the IDRE shall be able to manage a distributed service base, which organizes available services into functional and non functional views. Such a service base is used during the choreography synthesis activity. In fact, starting from the choreography specification, the required services are discovered in the service base with respect to functional and non-functional requirements. The synthesis produces (possibly with partial human intervention/inspection) the models of proxies/adaptors that, accounting for service functional and non-functional abstractions, distributedly support the enactment of choreographies. The proxy/adaptor models can then be deployed, e.g., as a set of wrappers, each of them local to each service involved in the choreography.

The process in Figure 2 has to be considered perpetual in the sense that it extends to runtime and does support domain expert developers and (end-)users in all the phases of the choreography life cycle. Consequently, the IDRE has to support complex analysis and validation steps at run-time when all the necessary pieces of information are available. In other words, some activities of the process may be executed at run-time, as specific internal capabilities of the choreography engineered through the process itself.

In the next sections the functionalities that the IDRE shall provide with respect to the previous discussion, are presented in detail. FP7-257178

Choreography design requirements

Goal: describe the requirements for choreography design, which shall guide the development of the choreography design tool integrated in the IDRE must support these requirements.

ID

CHOR-DES-006

Transform between collaboration-like and choreographylike exchanges LOW EBM Transformations between collaboration-like diagrams and choreography-like diagrams MAY be interesting to be supported by the IDRE.

WP2 Composition

CHOR-DES-007

Identify error messages and status codification

HIGH CNR-UNICAM

During the enactment of a choreography, error messages, and the status codification of response messages of any interaction MUST be identifiable as such, e.g. through a special field in the message header.

WP1-5

Analysis, Composition

CHOR-DES-008

Refine participants and actions identification

HIGH CNR-UNICAM

During the enactment of a choreography, the participants and the actions involved in every message exchange MUST be identifiable as such, e.g. through a special field in the message header. This needs to be defined at design time

WP1-5

Composition CHOReOS 11 FP7-257178

Choreography development requirements

Goal: describe the IDRE requirements for choreography development, including writing source-code for the mediators and other non-existing web services, testing, and debugging choreographies. In addition, a framework for applying automated unit, integration, and acceptance testing on running choreographies will support the automated testing of choreographies, enabling test-driven development (TDD) of choreographies.

CHOReOS will enable the development of choreographies in two different ways:

1. Programmer-based development of mediators and web services code: Not necessarily all web services needed by the choreography will be available previously. Thus a developer must implement them and also create manually the mediators used to adapt the already existing services, so that the choreography can be enacted. This way of enacting allows quick choreography prototyping and relies only on software developers. This it can be performed without requiring any high-level specification language for the development.

2. Automatic code generation of mediators using MDE and synthesis mechanisms: All choreography services already exist before the enactment and they are composed into a choreography through the use of automatically generated mediators that adapt those services to meet the high-level specification given by the Choreography Designer based on input from Domain Experts and the User. This way of enacting depends on the existence and maturity of the MDE and synthesis mechanisms; thus it will be implemented mostly during the second half of the project.

ID Name Priority

Partner Description WP Concern(s)

CHOR-DEV-001

Use abstract choreography models VERY HIGH

USP

The elements of a choreography (partners, services, messages exchanged, etc.) MUST be represented by an object in an object-oriented language (called abstract choreography). Through these objects, the developer will interact easily with the choreography elements to write automated tests.

WP4 Composition

CHOR-DEV-002

Generate automatically web service client (stubs)

VERY HIGH USP Given a web service URI, the framework SHALL build a client (stub) for this service automatically. Through this client, the tester will be able to invoke all web service functionalities.

WP4 Composition

CHOR-DEV-003

Provide Message interceptors VERY HIGH USP SHALL intercept, and then, collect the service operation name and the content of the messages exchanged among the services the developer wishes to monitor.

WP4 Messaging Management

CHOR-DEV-004

Provide unit, integration, and

CHOR-DEV-005

Mock Services MEDIUM USP MUST enable the creation of a service double (e.g., a mock). Through this object, all web service functionalities can be mocked. This will be useful at development time to test the choreographies when not all real services are available or when a specific scenario needs to be simulated.

WP4 Composition

CHOR-DEV-006

Generate a mocked service for part of a choreography MEDIUM USP MUST generate a mocked service for part of a choreography. This service will simulate the process performed in that part of the choreography. This will be particularly important for integration tests.

WP4 Composition

CHOR-DEV-007

Interact with version control client MEDIUM USP MUST provide a client for interacting with version control systems such as svn, git, and bazaar.

WP5 IDRE implementation

CHOR-DEV-008

Provide GUI -Graphical User Interface for collecting technical requirements MEDIUM USP All the technical requirements of this section will be available through a GUI with views, buttons, graphics, editors, lists, etc.

WP2 Presentation, Composition

CHOR-DEV-009

Manage

CHOR-DEV-015

Model management VERY HIGH

UDA

The IDRE SHALL provide an infrastructure to manage the different models which are produced/analyzed/transformed during the overall choreography life-cycle (Figure 1)

WP2-4

Composition, Analysis

Choreography enactment requirements

Goal: describe the requirements for choreography enactment. These requirements should be closely related (but at a higher abstraction level) to the ones that will be defined by WP3, since enactment is enabled and supported by the CHOReOS middleware.

These features will enable the instantiation of choreographies at runtime. The Middleware will provide all the required software infrastructure to instantiate the required services such as mediators, proxies and other choreography-aware services. It will also provide the bindings from these services to existing web services that will be composed in the choreography.

ID

WP3 Composition

CHOR-ENA-FUN-013

Reconfigure dynamically VERY HIGH

USP+MLS

In order to enable adaptability, the IDRE SHALL be able to replace parts of a running choreography without shutting it down. This can be used for example, to cope with failures, to optimize performance, to upgrade components, etc.

See AIRPORT-RUN-001.

WP3 Management

Choreography governance and monitoring requirements

Goal: Describe the requirements for choreography governance and monitoring at runtime.

ID

CHOR-MON-FUN-001

Monitor the system at runtime VERY HIGH USP At runtime, the IDRE SHALL collect information on running choreographies and offer ways (visual feedback, API, …) to take actions according to the monitored data. The monitoring infrastructure needs to be able to deal with ULS choreographies and services.

See AIRPORT-FUN-009, AIRPORT-RUN-003.

WP4 Management

CHOR-MON-FUN-002

Perpetual Testing HIGH USP The IDRE MUST support perpetual (i.e. event-driven, periodical) and automated V&V activities.

WP3-WP5

Management

CHOR-MON-FUN-006

Handle exceptions VERY HIGH

USP

The IDRE MUST provide mechanisms for exception handling and compensation of transactions for the enforcement of enacted choreographies at runtime.

WP3 Management

CHOR-MON-FUN-007

Handle Faults VERY HIGH USP Detect failures in the enactment of a choreography and automatically reconfigure it to fix the faults detected as failures.

WP3-4

Analysis Management

CHOR-MON-FUN-008

Monitor time availability

MEDIUM MLS

Monitoring time on an enacted choreography will be effective for load balancing issues in cooperation with monitoring resource availability.

WP5 Management

CHOR-MON-009

Handle Verification and Validation

VERY HIGH

MLS+CNR UNICAM

Provide mechanisms for verification and validation handling of a running ULS choreography.

WP4-5

Analysis

CHOR-MON-011

Handle metadata from services or choreographies

MEDIUM CNR-UNICAM

The IDRE SHOULD be able to collect and convey service description and its metadata [including perhaps a abstract model] from the service and/or choreography developer to the monitoring subsystem [and any other subsystems which need it]

WP3-5

Composition

CHOR-MON-012

Provide hooks to the service registration process

LOW CNR-UNICAM

The CHOReOS middleware, an integral part of the IDRE, SHOULD provide hooks to the service registration process so, for example, validation processes can be added in the service registration phase

CHOR-MON-013

Monitor scalability

HIGH CNR-UNICAM

The monitoring infrastructure of the IDRE MUST be scalable and distributed

WP3-4

Management

CHOR-GOV-001

Governance Scalabilty

HIGH EBM

The governance infrastructure MUST be scalable and distributed

WP4 Mangement

CHOR-GOV-002

Govern Services, Choreographies and SLAs VERY HIGH

EBM+CNR-UNICAM

The IDRE MUST provide a governance infrastructure for a very large number of services, choreographies and Services Level Agreements. Indeed, this infrastructure MUST be able to provide governance abilities (such as registries, rules, etc.) in a highly distributed and scalable environment dealing with large numbers of dynamically discovered services.

WP4 Management

CHOR-GOV-003

Manage Governance Policy

HIGH EBM

The IDRE MUST provide management capabilities for creating, updating, removing governance policies. This feature may also include Governance rules management as creation, update, removal, etc.

WP4 Management

CHOR-GOV-004

Provide a registry for choreographies, services and SLAs VERY HIGH

EBM

The IDRE MUST Provide a registry for choreographies, services and SLAs. This allow their discovery at design and run-time. The registry must be able to deal with a scalable number of services and choreographies.

WP3-4

Management

CHOR-GOV-005

Provide test activation

HIGH CNR-UNICAM

The IDRE MUST Provide test activation mechanisms.

WP4 Analysis

IDRE implementation requirements

Goal: This section describes those requirements that need to be satisfied in the activities related to the implementation of the IDRE. They add technical and methodological details to what is described in section 3.1, which lists important features that have to be considered by the IDRE to support the whole lifecycle of a choreography.

Such requirements aim at making technically easier the integration of the software artifacts developed within the different WPs, FP7-257178

IDRE design requirements

Goal: describe the requirements for the design of the IDRE.

ID Name Priority Partner Description WP

IDRE-DES-001

Provide application independence

HIGH CNR-UNICAM

The IDRE MUST be application independent WP5

IDRE-DES-002

Transform data formats

LOW CNR-UNICAM

The data formats e.g. for service level agreements, exchanged messages, and governance policies, MAY be converted into a different target data formats. In such transformation, the IDRE SHOULD grant for preserving the semantic of the data.

WP1-5

IDRE-DES-003

Legacy System LOW CNR-UNICAM

The IDRE MAY support facilities for legacy integration using a wide range of technologies, e.g. migration or wrapping, using various technologies, e.g. model driven approaches.

WP1-4-5

IDRE-DES-004

Identify different software components VERY HIGH VTRIP Software components derived by WP2-4 MUST be defined explicitly, in order to be integrated in the IDRE platform.

WP2-4

IDRE-DES-005

Maintain interoperability for IDRE components VERY HIGH

VTRIP

The IDRE software components MUST be able to communicate together through well defined interfaces ad behaviour WP2-4

IDRE-DES-006

Define a specific IDRE communication protocol

VERY HIGH

VTRIP

The communication between different software components of the IDRE MUST be delivered with a predefined set of rules and admissions constituting the protocol WP2-4

IDRE-DES-007

Account for fault tolerance in the IDRE protocol HIGH VTRIP Protocol definition SHOULD encompass error handling towards the direction of sustaining interoperability between the software components.

WP2-4

IDRE-DES-008

Maintain data consistent between IDRE processes MEDIUM VTRIP Any data that is used across the IDRE MUST be consistent. Input, configuration, models representation, rules & policies that are used by more than one component must have the same content.

WP2-4

IDRE-DES-009

Design the Architecture Model in UML HIGH NME IDRE architecture MUST be captured using UML based models WP2-4-5

IDRE-DES-010

Conceptual Model HIGH NME IDRE architecture MUST capture its major concepts and their relationships in Class Diagrams.

WP2-4

IDRE-DES-011

Process Model HIGH NME IDRE architecture MUST capture processes for developing and running choreographies using IDRE capabilities in Activity Diagrams.

WP2-4

IDRE-DES-013

Component Model HIGH NME IDRE architecture MUST contain its decomposition into components and specify their interfaces, interconnections, and data flows.

WP2-FP7-257178 WP2-3-4-5

IDRE-DEV-002

Adopt common developing rules VERY HIGH EBM All components of the IDRE, across each WP, MUST be developed by using common developing rules shared between partners.

WP2-3-4-5

IDRE-DEV-003

Apply the separation of concerns VERY HIGH EBM Each software library MUST be developed by separating the implementation from the interfaces. Interfaces of components are exposed in order to be used by consumers.

WP2-3-4-5

IDRE-DEV-004

Realize Functional tests HIGH EBM Functional tests for each software project/components MUST be implemented.

WP4-5

IDRE-DEV-005

Realize automatic tests HIGH EBM Automatic tests MUST be continuously realized while developing the software libraries.

WP5

IDRE-DEV-006

Separate Use Cases projects HIGH EBM Each use case MUST be put in a separate project.

WP5

IDRE-DEV-007

Use non duplicated resource files for the use cases HIGH EBM Resource files of use case MUST be unique and not duplicated or cloned.

WP5

IDRE-DEV-008

Adopt a common Choreography language HIGH EBM A common choreography language MUST be adopted. BPMN2.0 is a graphical language for the choreography and orchestration design.

WP2-3-4-5

IDRE-DEV-009

Consider

IDRE-DEV-012

Documented installation procedure

MEDIUM MLS

The installation procedure for the IDRE as well as its components SHOULD be documented.

WP5

IDRE-DEV-013

Programming language independence HIGH CNR-UNICAM

The IDRE MUST be programming language agnostic WP5

IDRE-DEV-014

Use of standard components

HIGH CNR-UNICAM

The IDRE SHOULD adopt and deploy standard software components to perform well-defined tasks instead of integrating these tasks into custom software.

WP2-3-4-5

IDRE-DEV-015

Use of standard protocols

HIGH CNR-UNICAM

The IDRE MUST adopt standard protocols to for the communications among both its services and components.

WP2-3-4-5

IDRE-DEV-016

Data format LOW CNR-UNICAM Independently from the communication protocol, the data itself may be described in multiple formats. For exchanging order information, the most common formats found in real world examples are XML, TXT, and CSV.

WP2-3-4-5

IDRE deployment requirements

Goal: describe the requirements for the deployment of the IDRE.

Annexe A -Airport Case Study requirements

As an identified case study for CHOReOS deployment, the "Passenger Friendly Airport" case study (herein also called "Airport CS) is of particular interest for this deliverable as it gives early business requirements that can be linked, as examples, to the higher level requirements defined in this document.

Overview of the case study

The Airport CS takes place in the context of air transportation, which is becoming a major activity in our everyday life either for business or leisure. Air transportation has indeed proven to be particularly safe and reliable, which will remain the primary objective for all actors of a flight. However, improvements in the services provided by air transportation are much needed, especially when one considers capabilities brought by the networking of the various services provided by the multiple stakeholders involved.

One can consider that there are two main directions for improvements: (i) continue optimisation of air traffic to, in particular, reduce delays, and (ii) better serve passengers.

We propose to focus this scenario in the latter direction where the choreography approach will prove to be an efficient means for improving services provided to passengers. Thus, it aims to demonstrate and assess the exploitation of choreographies in day-to-day large-scale coordination of air transportation stakeholders (Air traffic control authorities, Airports, Airlines…) and associated logistics partners (ground transportation, hotels…).

For more details about the particular scenario followed by the Airport CS and the involved actors, please refer, for the time being2 , to section B.1.3.2 of the CHOReOS DoW -Part B -Narrative Part document.

Requirements

In this annex, we identify a preliminary list of business-related requirements dedicated to the Airport CS. From these requirements, we may infer global requirements for the CHOReOS IDRE (in a typical bottom-up fashion), or even provide concrete example to support these global requirements (top-down approach).

Still, note that at this relatively early stage, the provided list of requirements is only partial and will be completed as part of the dedicated task within WP6 2 , which is to be initiated after the publication of the first version of this document. However, by collaborating early with a domain expert, who happens to also be a computer scientist, we inform the early elicitation of the IDRE requirements reported in this document, so that they can be effectively reused and form a solid basis for other work packages.

In the following, business requirements are categorized according to:

 Functional requirements: requirement that pertain to the intrinsic features of the system.  Non-functional requirements: requirement that pertain to the realization modalities of the feature of a system (i.e. its Quality of Service).  Design requirements;  Runtime requirements.

CHOReOS ii FP7-257178

Airport UC -Functional requirements

ID

Name Description

AIRPORT-FUN-001

Dynamic service discovery

In the Airport UC, a flight can be rerouted and critical services from new destination infrastructures need to be discovered since they differ from the original destination. As such, the IDRE MUST support the dynamic discovery of services during the enactment of orchestrations.

AIRPORT-FUN-002

Ultra Large Scale (ULS) choreography support Due to its large list of actors (ATC, Airline and Airport entities, including all its members, as well as all passengers in need of information), the Airport UC MUST have encompassing ULS support at design and at runtime.

AIRPORT-FUN-003

Dynamic access control to services

In the context of airport crisis, services SHOULD have their access control relaxed to authorize temporary consumption.

AIRPORT-FUN-004

Dynamic access control to passenger data

In order to personalize services provided to the passenger, access to travel data SHALL be granted to applications/operators due to circumstances. Modification of access rights SHALL be temporary and attached to the context.

AIRPORT-FUN-005

Search for flight related choreographies Administration interface SHALL provide easy way to search for choreographies related to a flight call sign

AIRPORT-FUN-006

Control of flight related choreographies

Administrator SHALL be able to suspend, stop, or restart any choreography.

AIRPORT-FUN-007

Choreography with human interaction

Choreography SHOULD allow for human interaction in the loop in order to apply modifications at runtime.

AIRPORT-FUN-008

Choreography manual control

When decision is made to reroute a flight, the decision SHOULD appear on a supervision interface, with a list of associated choreographies. Operator would be able to confirm the start of all choreographies or even cancel some of the list.

AIRPORT-FUN-009

Choreography overview

At any time, administrator SHALL be able to see the status (failed, successful, aborted, suspended…) of all choreographies associated to a flight

AIRPORT-FUN-010

Choreography definition

A choreography designer SHALL be able to design new choreography (or modify existing ones) using a graphical notation and exploiting repository of available assets (organisations, services…)

Airport UC -Non-functional requirements

ID

Name Description

AIRPORT-NFU-001

Circle of trust Organisations collaborating within the scenario SHALL share user identities or system identities to grant access to their services and data (No central identity management)

AIRPORT-NFU-002

Confidentiality Interactions between service consumers and providers SHALL be secured to guarantee confidentiality of exchanged data.

AIRPORT-NFU-003

Message queuing

Exchanges between organisations SHALL be performed in a secured way so that interactions may recover from temporary unavailability of services CHOReOS iii FP7-257178

AIRPORT-NFU-004

Integrity

Exchanges between organisations SHALL be secured to avoid any corruption of data in between Airport UC -Design requirements ID Name Description

AIRPORT-DES-001

BPMN 2.0 support From an industrial standpoint, the BPMN 2.0 specification is well known, supported by OW2, and provides the paradigms to define elaborated and nested choreographies necessary in the Airport UC. As such it MUST be included in the IDRE.

AIRPORT-DES-002

BPMN 1.x support BPMN 2.0 is quite new and already existing BPMN 1.x choreographies from Airport Authorities and actors, if they exist, SHOULD be integrated in the IDRE.

AIRPORT-DES-003

Collaborative choreographies Since many different actors (from ATC down to personnel) are involved in (or in charge of) parts of the journey of a typical passenger, each of these actors SHALL define their own parts in choreographies, since they are the experts to talk to.

AIRPORT-DES-004

Ultra Large Scale (ULS) choreography design (inherits from AIRPORT-FUN-002, AIRPORT-DES-003)

Support of an ULS choreography in the Airport UC also mean that each of its "decision making participant" (e.g. ATC, Airline and Airport entities) could also be one of its potential designer.

As such, CHOReOS IDRE MUST also support the design of ULS choreographies, in a collective fashion.

Airport UC -Runtime requirements

ID Name Description

AIRPORT-RUN-001

Runtime flexibility

The coordination of all services SHALL be highly flexible due the heterogeneity of services between airports.

AIRPORT-RUN-002

Runtime Distributivity

Since there MUST NOT be any single point of control or failure in a choreography (especially critical airport regulation ones), the responsibility of the execution MUST be distributed through all its participants. The Runtime MAY support such an enactment feature (e.g. by translation of a given choreography into multiple orchestrations).

AIRPORT-RUN-003

Runtime monitoring of choreographies

The architecture SHALL support the monitoring of enacted choreographies at runtime, particularly according to nunfunctional characteristics specific to the Airport UC.

AIRPORT-RUN-004

Ultra Large Scale choreography enactment (inherits from AIRPORT-FUN-002)

Due to ULS constraints in the Airport UC, the Runtime environment MUST support ULS choreographies.

AIRPORT-RUN-005

Surveillance of choreography

Any running choreography SHALL be monitored and controlled from remote client position.

AIRPORT-RUN-006

Traceability Choreographies SHOULD log all service calls and their status changes with time and unique ID (per choreography).

CHOReOS iv FP7-257178

3 3.

 3 IDRE global requirements ............................................................................................. 6

Figure

  Figure 1 -CHOReOS IDRE Overview

Work Package (WP) 6, starting at T0+6 will provide more details on the Airport UC scenario and will refine this preliminary list of requirements.

testing & debugging lines) Updated Requirements tables (according to Amira) CHOReOS

section 3.3 on requirements by VTRIP and CNR-UNICAM. Updated IDRE requirements table (new text + deleted