Demonstration material and events from Phase 2

Transcription

Deliverable ID:
Preparation date:
D9.1
July 31, 2012
Milestone: Released
Title:
Secure and Trustworthy Composite Services
Demonstration material
and events from Phase 2
Editor/Lead beneficiary (name/partner):
Seventh Framework Programme:
Call FP7-ICT-2009-5
Priority 1.4 Trustworthy ICT
Integrated Project
G. Fausto ANDREOTTI / ITALTEL
Internally reviewed by (name/partner):
Marina EGEA / ATOS
Erno JEGES / SEARCH
Approved by:
Executive Board
Abstract:
Aniketos is about establishing and maintaining trustworthiness and secure behaviour in a constantly
changing service environment. The project aligns existing and develops new technology, methods, tools
and security services that support the design time creation and run-time dynamic behaviour of composite
services, addressing service developers, service providers and service end users.
This deliverable presents the result of activities carried out in work package WP9 (Demonstration) during
the Phase 2 of the Aniketos project. The demonstration work package will basically deal with the
identification of different demonstration target user groups and scenarios, the development of
demonstration material and the intermediate reporting about demonstration events. This document
describes the planning of demonstration activities and the strategy we followed to support the outreach
activities in Aniketos. Based on the analysis of the outcomes from technical work packages during the
lifetime of the deliverable, we identified a set of potential targets user groups and scenarios and developed
material suitable for demonstrations. Finally, the document reports about the description of events and the
feedback collected from the target audiences.
Dissemination level
PU
Public
CO
Confidential, only for members of the consortium (including Commission Services)
X
The research leading to these results has received funding from the European Community's Seventh
Framework Programme (FP7/2007-2013) under grant agreement n° 257930.
D9.1:Demonstration material and events from Phase 2
iii
Aniketos consortium
Aniketos (Contract No. FP7-257930) is an Integrated Project (IP) within the 7th Framework
Programme, Call 5, Priority 1.4 (Trustworthy ICT). The consortium members are:
SINTEF ICT (SINTEF)
NO-7465 Trondheim
Norway
www.sintef.com
Project manager: Richard T. Sanders
[email protected]
+47 73 59 30 06
Technical manager: Per Håkon Meland
[email protected] +47 73 59 29 41
Tecnalia Research & Innovation
(TECNALIA)
E-20009 Donostia - San Sebastian
Gipuzkoa (Spain)
www.tecnalia.com/en
Contact: Erkuden Rios Velasco
[email protected]
Consiglio Nazionale delle Ricerche
(CNR)
00185 Roma, Italy
www.cnr.it
Contact: Fabio Martinelli
[email protected]
Thales Services SAS (THALES)
78140 Velizy-Villacoublay, France
www.thalesgroup.com
Contact: Dhouha Ayed
[email protected]
Liverpool John Moores University
(LJMU)
Liverpool, L3 5UX, United
Kingdom
www.ljmu.ac.uk/cmp
Contact: Madjid Merabti
[email protected]
Selex Elsag S.P.A. (ELSAG)
16154 Genova, Italy
www.Selex Elsag.com
Contact: Paolo Pucci
[email protected]
SEARCH-LAB Ltd. (SEARCH)
Budapest 1117, Hungary
www.search-lab.hu
Contact: Zoltán Hornák
[email protected]
Atos Origin (ATOS)
28037 Madrid, Spain
www.atos.net
Contact: Pedro Soria-Rodriguez
[email protected]
Telecommunication Software and
Systems Group (TSSG)
Waterford, Ireland
www.tssg.org
Contact: Miguel Ponce de Leon
[email protected]
iv
Universita Degli Studi di Trento
(UNITN)
38100 Trento, Italy
www.unitn.it
Contact: Paolo Giorgini
[email protected]
Athens Technology Center SA
(ATC)
15233 Athens, Greece
www.atc.gr
Contact: Vasilis Tountopoulos
[email protected]
SAP AG (SAP)
69190 Walldorf, Germany
www.sap.com/research
Contact: Achim Brucker
[email protected]
ITALTEL S.P.A. (ITALTEL)
20019 Settimo Milanese, Italy
www.italtel.it
Contact: Maurizio Pignolo
[email protected]
Paris Lodron Universität Salzburg
(PLUS)
5020 Salzburg, Austria
www.uni-salzburg.at
Contact: Manfred Tscheligi
[email protected]
Deep Blue SRL (DBL)
00193 Roma, Italy
www.dblue.it
Contact: Valentino Meduri
[email protected]
Wind Telecomunicazioni S.P.A.
(WIND)
00148 Roma, Italy
www.wind.it
Contact: Rita Spada
[email protected]
Dimos Athinaion Epicheirisi
Michanografisis (DAEM)
10438 Athens, Greece
www.daem.gr
Contact: Ira Giannakoudaki
[email protected]
v
Table of contents
Aniketos consortium.............................................................................................................................. iii
Table of contents .....................................................................................................................................v
List of figures ....................................................................................................................................... vii
List of tables ........................................................................................................................................ viii
Executive summary .................................................................................................................................9
1 Introduction ...................................................................................................................................11
1.1
Aniketos motivation and background ..................................................................................11
1.2
Summary ..............................................................................................................................11
1.3
Structure of this document ...................................................................................................12
1.4
Relationships with other deliverables ..................................................................................13
1.5
Contributors .........................................................................................................................14
1.6
Acronyms and abbreviations................................................................................................14
1.7
Change log ...........................................................................................................................15
2 Demonstration strategy and planning ............................................................................................17
2.1
Demonstration strategy ........................................................................................................17
2.1.1 RTD work packages ........................................................................................................17
2.1.2 User Group/Validation work packages ............................................................................19
2.1.3 Outreach work packages ..................................................................................................20
2.2
Demonstration planning .......................................................................................................21
2.2.1 On-line demonstrations and presentations .......................................................................21
2.2.2 Local industry demo events .............................................................................................21
2.2.3 Other events with industry target.....................................................................................22
3 Identification of targets .................................................................................................................23
3.1
User groups and material .....................................................................................................23
3.1.1 User groups ......................................................................................................................24
3.1.2 Demonstration material formats ......................................................................................31
3.2
Business scenarios ...............................................................................................................32
3.2.1 Analysis of scenarios .......................................................................................................32
3.2.2 Comparative analysis and conclusions ............................................................................35
4 Development process ....................................................................................................................37
4.1
Aniketos platform ................................................................................................................37
4.2
Tools and Methods...............................................................................................................44
4.2.1 Development tools ...........................................................................................................44
4.2.2 Feedback methods ...........................................................................................................45
4.3
Storage and availability........................................................................................................47
5 Results ...........................................................................................................................................49
5.1
Demo material ......................................................................................................................49
5.1.1 Design of a trustworthy composite service ......................................................................50
5.1.2 Case study “A” User Story A1 ........................................................................................63
5.1.3 Case study “C” User Story C1 .........................................................................................69
5.2
Report on events ..................................................................................................................72
5.2.1 Aniketos plenary meeting in Paris ...................................................................................72
5.2.2 Selex Elsag internal demonstration .................................................................................73
5.2.3 Local industry demonstration in Wind ............................................................................74
5.3
Outreach support ..................................................................................................................76
5.3.1 Training support (WP8) ...................................................................................................76
5.3.2 Community support (WP10) ...........................................................................................76
6 Conclusion/Further work ...............................................................................................................79
vi
References .............................................................................................................................................80
Appendix A ...........................................................................................................................................81
A.1
Demo report template ..........................................................................................................81
A.2
Feedback form example .......................................................................................................81
A.3
Comparisons of screen-casting software..............................................................................83
A.4
List of animation software ...................................................................................................86
vii
List of figures
Figure 1: Goal: establish and maintain security and trustworthiness in composite services ................. 11
Figure 2: WP9 tasks in Aniketos ........................................................................................................... 12
Figure 3: Role of WP9 in Aniketos ....................................................................................................... 17
Figure 4: Identification process ............................................................................................................. 23
Figure 5: Aniketos platform and Environment decomposition model .................................................. 40
Figure 6: Design time service composition modules ............................................................................ 50
Figure 7: Overview of InfoService components ................................................................................... 52
Figure 8: InfoService social view .......................................................................................................... 53
Figure 9: InfoService information view ................................................................................................ 54
Figure 10: InfoService authorization view ............................................................................................ 55
Figure 11: Setting of security requirements .......................................................................................... 56
Figure 12: Authentication required for the Service Composition Framework ...................................... 57
Figure 13: Workbench of the Service Composition Framework ........................................................... 57
Figure 14: BPMN model of Infoservice ................................................................................................ 58
Figure 15: Excerpt of the XML representing the InfoService BPMN annotated model ....................... 58
Figure 16: Selection of the operation for the binding process ............................................................... 60
Figure 17: Creation of composition plans ............................................................................................. 60
Figure 18: The composition plans created for InfoService ................................................................... 61
Figure 19: Composition plans returned by the SCPM........................................................................... 62
Figure 20: Further operations once selected a composition plan .......................................................... 63
Figure 21: The design time of the Case study A use story A1 demonstration ...................................... 65
Figure 22: Run-time processes for the service end user and service provider of the Case study A use
story A1 demonstration ......................................................................................................................... 67
Figure 23: Run-time processes for the re-composition agent and service provider of the Case study A
use story A1 demonstration ................................................................................................................... 68
Figure 24: Run-time verification of the new composition of the Case study A use story A1
demonstration ........................................................................................................................................ 69
viii
List of tables
Table 1: List of potential events for demonstrations for Phase 2 .......................................................... 21
Table 2: Aniketos community members ............................................................................................... 23
Table 3: Approach to categories of user groups to be addressed .......................................................... 25
Table 4: Definition of users in case study A ......................................................................................... 27
Table 5: Definition of users in case study B.......................................................................................... 28
Table 6: Definition of users in case study C.......................................................................................... 28
Table 7: User groups and targets in WP7 .............................................................................................. 29
Table 8: Type of material ...................................................................................................................... 31
Table 9: Example list of targets and material ........................................................................................ 32
Table 10: Relevant features of the industrial case studies ..................................................................... 35
Table 11: Analysis of Aniketos scenarios ............................................................................................. 35
Table 12: Aniketos components ............................................................................................................ 37
Table 13: Aniketos components status of implementation .................................................................... 41
Table 14: Aniketos integration status (as of July, 2012) ....................................................................... 42
Table 15: Examples of open-source tools for screen-casting ................................................................ 44
Table 16: Examples of open-source tools for video editing .................................................................. 45
Table 17: Examples of open-source tools for animation ....................................................................... 45
Table 18: Examples of open-source tools for surveys........................................................................... 46
Table 19: InfoService model actors and goals ...................................................................................... 53
Table 20: InfoService information owners ............................................................................................ 54
Table 21: Selex Elsag internal demonstration ....................................................................................... 73
Table 22: Demo event (Wind) ............................................................................................................... 74
Table 23: Demo event questionnaire and results (Wind) ...................................................................... 75
9
Executive summary
This deliverable presents the demonstration activities carried out during the Phase 2 of the Aniketos
project. The demonstration work package is mainly based on following tasks:
 Task 9.1 Identification of relevant user groups of Aniketos results
 Task 9.2 Development and integration of demonstration materials
 Task 9.3 Execution of demonstration events
The main objective of this work package is to demonstrate the viability of the results produced in
Aniketos targeted towards different groups in the community. The demonstration activities play an
essential role in the validation of Aniketos technical results. Therefore, such activities shall be
considered as integral part of the project because they are the first step to approach the end-users and
get early feedback of the acceptance and exploitation possibilities. The demonstration is not tightly
linked to the 3 case studies, but aims at audiences and communities over and above these three
domains. This work package supports the Outreach group (WP8-10-11) thus ensuring that the
Aniketos platform can be applied to future European services in other domains than the case studies as
well.
In the identification task, we carried out analysis of stakeholders and a suitable approach to user
categories. Then we analysed technical deliverables for availability of material and usable scenarios.
Finally, we outlined a strategy and a planning of demo events for supporting outreach.
In the development task, we analysed tools for production and storage of material, as well as methods
to collect feedback. Then, we identified a list of candidate demonstrations, supported by the
capabilities of the Aniketos system, related to the outcomes of technical work packages (mainly WP5
and WP6).
In the final part of the document, we reported about events devoted to both internal and external
dissemination of the Aniketos results supported by demonstrations.
11
1 Introduction
1.1 Aniketos motivation and background
The Future Internet will provide an environment in which a diverse range of services are offered by a
diverse range of suppliers, and users are likely to unknowingly invoke underlying services in a
dynamic and ad hoc manner. Moving from today’s static services, we will see service consumers that
transparently mix and match service components depending on service availability, quality, price and
security attributes. Thus, the applications end users see may be composed of multiple services from
many different providers, and the end user may have little in the way of guarantee that a particular
service or service supplier will actually offer the security claimed.
Service developers
Service providers
Service end users
• End user trust
assurance and
acceptance
• Identification of
responsible party
Invoke
•Self-protection
•Trust evaluation
•Security validation
Provide
Compose
Adapt/recompose
• Discovery and composition support
based on trustworthiness, security
properties and metrics
• Relevant threat awareness
Design-time
• Trust and security
monitoring
• Threat notification
Component change
Change of threats
Change of environment
Runtime
Figure 1: Goal: establish and maintain security and trustworthiness in composite services
Aniketos is about establishing and maintaining trustworthiness and secure behaviour in a constantly
changing service environment. The project aligns existing and develop new technology, methods,
tools and security services that support the design time creation and run-time dynamic behaviour of
composite services, addressing service developers, service providers and service end users.
Aniketos provides methods for analysing, solving, and sharing information on how new threats and
vulnerabilities can be mitigated. The project constructs a platform for creating and maintaining secure
and trusted composite services. Specifications, best practices, standards and certification work related
to security and trust of composite services are promoted for inclusion in European reference
architectures. Our approach to achieving trustworthiness and security of adaptive services takes
account of socio-technical aspects as well as basic technical issues.
1.2 Summary
The main objective of the WP9 work package is to demonstrate viability of Aniketos results targeted
to different groups in the community. The aim of deliverable D9.1 is:

to identify a suitable set of user groups in order to demonstrate the benefits of the Aniketos
platform;
12

to select a number of scenarios which are compatible to the outcome of technical work packages
and provide demonstration material;
 to elaborate a demonstration strategy and a planning to execute demonstrations thus producing
intermediate reports on participated events.
The present deliverable addressed all the tasks foreseen in the demonstration work package, in
particular:



Task 9.1 - Identification of relevant user groups of Aniketos results, deals with the identification
of specific targets to which demonstrations will be aimed; in this task we considered a number of
stakeholders (user groups) that could be interested in Aniketos results and analysed which kind of
business scenarios are more suitable for Phase 2. By their nature, the industrial case studies refer
to business scenario demonstrations to show the benefits of the Aniketos approach.
Task 9.2 - Development and integration of demonstrations material, is focused on the
development of demonstration material from WP2-5, but it is worth to consider that the output of
technical work packages is still at an early stage. Thus, it was necessary to monitor accurately the
evolution of the implementation of the Aniketos platform throughout the deliverable lifetime in
order to provide suitable demonstration material.
Task 9.3 - Execution of demonstration events, a demonstration strategy and planning has been
sketched in a dedicated section of this deliverable. However, due to the relatively short duration
of this deliverable and the fact that the technical material has been made available during the
same period, most of the planned events are expected to be realized in the second half of the
project (i.e. Phase 3 and Phase 4).
The relationship among WP9 tasks has been shown in the following picture: the identification task is
part of the activities foreseen in the demonstration work package, aimed to the identification of targets
and events. The development task will provide demonstration material that is used by the execution
task for demonstrations to selected targets during relevant events within academia, industry and
general public.
Figure 2: WP9 tasks in Aniketos
The two main phases in WP9 are related to the delivery of the Aniketos integrated platform and for the
realization of the case studies. Specifically, the initial and the final platform integrations from WP5 are
due in May 2012 and in November 2013, while the initial and the final application of Aniketos
platform to the case studies are due in July 2012 and December 2013.
This fact has been taken into account in the demonstrations strategy related to the case studies, as well
as in the planning of platform and environment modules. In fact, some functionalities of the Aniketos
system are likely to change as the specification of the architecture (D1.5) will not be finalized until
April 2013.
1.3 Structure of this document
This document is structured as follows:


Chapter 1 – Introduction
Chapter 2 – Demonstration strategy and planning, describes the general approach that we
followed and the role of this work package inside Aniketos, i.e. the relationships with the
technical work packages (WP1-WP6) and with the outreach as well. Planning of activities will




13
provide a list of potential events and activities linked to outreach work packages (WP8, WP10
and WP11).
Chapter 3 – Identification of targets, will deal with the identification process in terms of selection
of user groups, type of demo material and reference scenarios. The identification of targets will be
strongly related to the strategy and the availability of material from technical work packages.
Chapter 4 – Development process, is focused on the description of the process of development
that will use (part of) the Aniketos system. An overview of the modules available from Aniketos
will be given in this chapter, together with tools and methods we will use for the development and
the storage of the demo material.
Chapter 5 – Results, will describe the achievements in this work package. A part will describe in
detail the demo material, while another part will be focused on reporting about demonstrations
and events, including support of outreach activities.
Chapter 6 – Conclusions, in which we provide considerations about further work and future
developments.
1.4 Relationships with other deliverables
The D9.1 document relates to the following deliverables, which have been scheduled within the
timeframe of the present deliverable.
Deliverables coming from work packages WP1-WP6 and WP7 will be mainly used in the
identification and development tasks of the WP9 work package. On the other hand, deliverables from
WP10 and WP11 work packages will be useful for identification of targets and the scheduling of
demonstrations for an effective support of outreach activities.











D1.2 - First Aniketos architecture and requirements specification: this deliverable [2] contains
the list of the platform related requirements and scenarios that we will refer to in order to develop
the case studies demonstrations.
D1.3 - Initial version of the socio-technical security modelling language and tool: this deliverable
[3] provides a specification of modelling language and a base prototype of the modelling tool.
D2.2 - Initial prototype of trust management, security-by-contract and verification modules: this
deliverable [4] presents the first implementation of the trust management module.
D3.2 - Initial prototype of secure service composition: this deliverable [5] provides a
demonstrable set of tools as a prototype for the methods that are identified in D3.1 as being
needed in order to support dynamic service composition.
D4.2 - Initial prototype of the mechanisms for the response to changes and threats: this
deliverable [6] implements the responses to changes and threats.
D5.1 - Aniketos platform design and platform basis: this deliverable [7] is about the description of
the Aniketos platform and gives some guidelines for implementing the functionalities of the
platform.
D5.2 - Initial Aniketos platform integration: this deliverable [8] provides the initial integrated
Aniketos platform, which is exploited in the development of the case studies.
D6.1 - Initial analysis of the industrial case studies: this document [9] presents the user scenarios
and the relevant storyboards, on the basis of which the requirements for the case studies have
been identified and are transformed to functionalities in D6.3.
D6.2 - Case study work plan: this document [10] describes the planning activities for the
development of the application specific modules and their connection with the Aniketos
components.
D6.3 - First report on Aniketos applied to industrial case studies: this deliverable [11] is a report
of the results and recommendations after initial appliance of Aniketos in the case studies.
D7.1 - Validation and evaluation plan: this deliverable [12] describes the plan to perform the
evaluations of Aniketos. The document has served as reference for the demo feedback collecting
14






methods and tools, demo scenarios, and to align demo development with the planned platform
evaluation.
D7.2 - Results of the first validation and evaluation of the Aniketos platform: this document [13]
provides a report on the evaluation results from Phase 2 and specifies the evaluation criteria as
well as the methods and tools used in the evaluation.
D10.1 - Initial plan on Aniketos community building and standardisation: this deliverable [14]
will plan and report on the initial efforts towards community establishment including open-source
community during Phase 1. It outlines steps and procedures to be followed to create and maintain
the user community to ensure project quality, impact and visibility within the relevant
communities of practice.
D10.2 - Initial report on network participation, community building and standardisation efforts:
this document [15] will report on the activities performed with respect to partner efforts, events,
material, infrastructure, and achievements made within European and International networks, on
standardisation and Aniketos community establishment, including open source community during
Phase 2.
D11.1 - Aniketos brochure and public website: this deliverable [16] makes project known to the
public and initial version of Aniketos brochure and project website with at least project abstract
and contact details. Both will be continuously updated and enhanced.
D11.2 - Initial dissemination and exploitation plan: this deliverable [17] develops a strategy for
focussed and effective contribution to the project outputs. First planning and strategy for the
dissemination and exploitation activities.
D11.3 - Second dissemination and exploitation plan: this deliverable [18] is about informing the
dissemination target groups of Aniketos benefits. Revised plan augmented with a more detailed
exploitation strategy and business models, and report of the dissemination and exploitation
activities performed, including preliminary case studies results and preliminary project results
will be presented to scientific community, end-users and key market actors.
1.5 Contributors
The following partners have contributed to this deliverable:




ELSAG (now Selex Elsag)
ESI (now Tecnalia)
ITALTEL
TSSG
1.6 Acronyms and abbreviations
ARPU
Average Revenue Per Unit (or User)
SCPM
Secure Composition Planner Module
ATM
Air Traffic Management
SRCM
Security Requirements Compliance
Module
BP
Business Process
SRE
Service Run-time Environment
BPMN
Business Process Modelling Notation
STS
Socio-Technical Security
DoW
Description of Work
STSml
Socio Technical Security modelling
language
DT
design time
STStool
Socio Technical Security tool
ICT
Information Communication Technology
SWIM
System Wide Information
Management
IdM
Identity Management
TLC
Telecommunication
15
ISP
Internet Service Provider
TM
Trustworthiness Module
MTM
Model Transformation Module
VM
Virtual Machine
RT
run-time
XML
eXtensible Markup Language
SCF
Service Composition Framework
SRS
Security Requirements
Specifications
1.7 Change log
No change log entries.
17
2 Demonstration strategy and planning
The purpose of the demonstration strategy is to identify audiences and communities above and beyond
those participating in the case studies of WP6 and to take some first steps to approach these end-users
and get early feedback on the acceptance and exploitation possibilities of the Aniketos platform.
Work package 9 acts as an output conduit for the results of the R&D work packages of Aniketos and
given that WP9 is part of the outreach programme of the project it can leverage WP8, WP10, WP11,
and essentially align to the training, community building and dissemination activities of the project.
The following sections will describe the strategy followed in WP9, its’ role and relationships inside
Aniketos and the plan for demonstration events in the upcoming phase of the project.
2.1 Demonstration strategy
In order to develop a strategy for demonstrating the Aniketos platform, whether it will be online or in
live situations, the relationships between this work package Demonstration (WP9) and the other work
packages needs to be explained.
In Section 2.1.1 we look at the R&D work packages of Requirements and architectural approach
(WP1), Define, establish and maintain trust (WP2), Secure composition of dynamic services (WP3),
Response to changes and threats (WP4), and the Platform construction (WP5) and explore what they
are developing for WP9.
In Section 2.1.2 we identify the relationship with the User Group/Validation work packages, of
Realisation of industry case studies (WP6) and Validation and end user evaluation (WP7).
Finally in Section 2.1.3 the relationship with the other outreach work packages of Tutorials and
training (WP8), Community building and standardisation (WP10) and Dissemination and Exploitation
(WP11) is described.
Figure 3: Role of WP9 in Aniketos
Coordinating these relationships through WP9 is important as it has a serious effect on the quantity
and quality of demonstrations that can be undertaken via WP9.
2.1.1 RTD work packages
The purpose of this section is to give an overview of the results developed during Phase 2 of the
project.
The Requirements and architectural approach as specified via WP1 gives the context of the Aniketos
platform, a description of the platforms role and interaction in its environment. The environment
18
includes both stakeholders and other systems. D1.2 of WP1 gives scenario descriptions, an
environment description and business processes for the platform.
Based on this, D1.2 presents the current state of the project requirements. This is followed by the
descriptions of the information, subsystems and interfaces within the Aniketos platform itself. The
document has two appendices; the first one a snapshot of the project glossary, and the second one an
elaborated version of the scenario descriptions.
Of particular interest to WP9 is the set of practical use case scenarios for the Aniketos project which
have been developed to define how Aniketos is envisioned to improve secure service composition.
The Requirements and architectural approach (WP1) also describes the Aniketos socio-technical
security modelling language (STS-ml), and its support tool (STS tool). The STS-ml belongs to a
family of languages for security requirements engineering, as it addresses security aspects early in the
development process. STS-ml captures security requirements at the organisational (business) level,
and enables requirements analysts to represent and reason about security and trust properties that are
fundamental for the design of secure and trustworthy service-oriented applications. The STS tool aims
to assist analysts throughout the secure service engineering process.
The accessibility of STS-ml makes a good candidate for demonstration.
WP2 have split their work according to three technologies:

Trustworthiness component.

Security-by-Contract component.
 Verification modules component.
Deliverable D2.2 presents the first version of the WP2 prototype. It contains the diverse information
about the prototype, its main requirements, design, and a short usage guide. It is to be noted that the
D2.2 version of the prototype has a main focus on the Trustworthiness component, while other
components have only very limited, initial implementation.
Through D2.2 there is a description of the overall requirements for all three components and a
complete vision on the main functionality of the prototype.
At this point WP9 can identify where to place the Define, establish and maintain trust (WP2)
prototype in the overall Aniketos platform at service design time and service run-time. WP2
concentrates on a usage scenario where, in explicit relation to Aniketos use cases a service provider
aggregates services from a number of other service providers in communications and media sectors.
The work package Secure composition of dynamic services (WP3) is producing software and
algorithms that support design time secure service composition. In particular it has split its work into
four core modules:

Secure Composition Planner Module: Coordinates the secure composition workflow. It receives
the composition plans from Aniketos composition framework and triggers the security validation
process.
 Security Property Determination Module: Determines and manages the security properties for
composition plans.
 Contract Manager Module: Provides a comprehensive analysis of agreement templates against
consumer policy. In WP3, its functionality is limited to utilise the trustworthiness in evaluation of
composition plans.
 Composition Security Validation Module: Verifies composition plan against consumer policies
and agreement template.
D3.2 describes the basic functionality of the work package and demonstrates how to use the prototype
to interact with the Aniketos environment and verify composition plans
The most mature elements of the work package Secure composition of dynamic services (WP3) are the
Secure Composition Planner Module and the Composition Security Validation Module. D3.2 gives a
19
comprehensive run-through example of demonstrating the WP3 prototype and how it handles
composition plans sent by the Composition Framework.
The Response to changes and threats (WP4) deals with the run-time reactions of the platform. Since
the service composition environment targeted by Aniketos is by essence always changing, then the
Aniketos platform must provide mechanisms to respond to changes and threats at run-time. The
deliverable D4.2 provides a first version of a demonstrable set of tools that implement the responses to
changes and threats. This prototype includes:
 community support management of the threats and countermeasures,
 tools for the monitoring of changes and the notification of threats,
 support of compliance to security requirements at design time and run-time.
The Response to changes and threats (WP4) prototype includes five modules:

Security Requirements Compliance Module (SRCM): This module supports the response to
changes and threats that affect the satisfaction of the security and trustworthiness requirements
created using the STS-Tool.
 Service Threat Monitoring Module (STMM): This module detects and observes changes or
threats at run-time and notifies corresponding components when there is a change of threat level.
 Notification Module (NM): This module provides a notification mechanism for services created
with the Aniketos platform with respect to changes in the environment (including detected
failures of contracts and trustworthiness values) and threats.
 Threat Response Recommendation Module (TRRM): This module provides recommendations for
threat response at run-time, such as a general plan for the intelligence that will compute the
appropriate response.
 Threat Repository Module (TRM): This module is part of the community support and contains a
repository of threats, dynamically updated, with information about the threat type and
recommended response.
Examples of how the modules are used from a business perspective are given in D4.2 and relate to the
e-Government case study of Realisation of industry case studies (WP6) and payment provider
scenarios.
The work package Platform construction (WP5) presents the layered view on the Aniketos
architecture, and represents the currently adopted components to support the functionalities envisaged
for both the Aniketos platform and the environment.
The Aniketos integration plan via the Platform construction (WP5) has a focus on the design time
support of selected Aniketos platform components, while run-time support follows in both the
intermediate and final version of the initial Aniketos platform integration. Along with that, the
environment components are also considered. Among them, priority has been given to the deployment
of the service composition framework (to address the interaction of the design time components) and
the service monitoring component (to address the interaction of the run-time components).
From the WP9 perspective, the WP5 gives a clearer view of the Aniketos components interfaces,
implementation of the Aniketos platform & environment components, the installation & usage guides
and how the implemented platform addresses the system level requirements.
2.1.2 User Group/Validation work packages
The Realisation of industry case studies (WP6) presents a plan for the realization of three industrial
case studies envisaged for Aniketos, namely future telecommunication services, the emerging
European Air Management systems and land-buying / e-Governance. It is important to note that since
the implementation of the case studies relies on the development of Aniketos services, WP6 have put
together a plan which follows the timeline for deliveries in platform and environment components, as
foreseen in WP5. The plan has been roughly split in two main phases, according to the two milestones
in the Platform construction (WP5) [M22 and M39].
20
From there the case studies have been further split into smaller user stories, for example in the future
telecommunication services there are two, User Story A1 which looks to use Aniketos to discover
service components featuring the desired level of security and trustworthiness and User Story A2
which exposes network resources as services in the Aniketos Marketplace.
WP9 can monitor the work plans of the individual case studies and take drops of functionality from
the integration/test phases of WP6 and use these as targets for demonstration events.
The purpose of Validation and end user evaluation (WP7) is to provide a framework for the validation
and user evaluation activities within the project. It carries out the main validation and evaluation of the
modules, services, tools developed within the technical work packages of Aniketos.
There is a close dependency and cooperation among the case studies of WP6 and the Validation and
end user evaluation of WP7 as WP6 gives early feedback and recommendations to the technical work
packages, based on hands-on experience when using Aniketos outcomes in the case studies while WP7
is more concerned in evaluating the whole set of features offered by the modules, services, tools
developed of Aniketos.
WP9 has learned from the first usability evaluation of the socio-technical security modelling language
and tool (STS-ml) carried out through WP7. A workshop was conducted by PLUS in cooperation with
UNITN in July 2011. The overall aim of the evaluation was to derive conclusions concerning the
usability and adequacy of the STS-ml and tool at its early stage of development. Based on the results
of the evaluation recommendations for improvements of STS-ml and tool could be provided to
UNITN. The following questions were addressed in the workshop:
 How usable are the modelling language and its support tool?
 Are there missing concepts that would be essential to model security aspects?
 Is the graphical representation adequate / easy to understand?
 Are there concepts whose semantics is unclear / underspecified?
 Are there technical issues that limit the usability of the tool?
WP9 will further learn from the user-centred evaluation methods used in WP7.
2.1.3 Outreach work packages
WP9 is part of the outreach programme of the project, and it can clearly leverage the Tutorials and
training (WP8), Community building and standardisation (WP10) and Dissemination and Exploitation
(WP11) activities of the project. Notwithstanding WP9 can also provide materials towards the other
outreach work packages to essentially align the training, community building and dissemination and
exploitation activities of the project.
The tutorials and training activities of WP8 are creating a collection of learning materials, comprising
of programmers guides, reference manuals and code samples, which will be complemented with a
number of webinars that will be made public, explaining the operation and usage of certain Aniketos
components. WP9 re-uses parts of this material in the live and online demonstrations, while WP8 reuses the demo material created by WP9 in its’ live webinars.
The Community building and standardisation of WP10 is concerned with building network
connections with other framework programme projects, technology platforms, participating in
workshops and summer schools and promoting the communities around the open source release of
Aniketos components. WP9 taps into the networks and communities created through WP10, which is
further detailed in Section 2.2.
The Dissemination and Exploitation activities coordinated throughWP11 formulates the projects
dissemination and exploitation strategy and an action plan of dissemination/exploitation activities
concentrated on the second and third periods of the Aniketos project. WP11 has identified open
dissemination opportunities and while some of the events may be too early for demonstration in this
phase of the project, the events should be definitely considered for future phases, which are further
detailed in Section 2.2.
21
2.2 Demonstration planning
In planning possible demonstration events we have considered appropriate events where WP9 could
either present tutorials, posters, and/or live demonstrations.
We have also noted conferences most align to the topics of Aniketos and have thus targeted these
conferences for 2013. The following table is a list of potential events that will be kept up-to-date for
planning purposes, and will be revised accordingly.
Table 1: List of potential events for demonstrations for Phase 2
ID
Schedule
Event
Organized by
Location
Target
1
July 2012
6th Advanced
School on
Service Oriented
Computing 2012
TSSG
Crete, Greece
Academic
2
October 2012
Model Driven
Security (MDsec)
2012 workshop
ATOS (coorganizer)
Innsbruck,
Austria
Industrial /
Academic
3
May 2013
Aniketos /
NESSOS
Summer School
TSSG
Malaga,
Spain
Academic
4
May 2013
TOOLS 2013:
International
Conference on
Objects, Models,
Components,
Patterns
tbd
Location TBC
Academic
5
May 2013
FIA
TSSG
Dublin,
Ireland
Industrial /
Academic
6
June 2013
SEC 2013:
International
Information
Security and
Privacy
Conference
tbd
Location TBC
Academic
7
July 2013
PST 2013:
International
Conference on
Privacy, Security
and Trust
tbd
Location TBC
Academic
2.2.1 On-line demonstrations and presentations
On-line demonstrations are available from the project website [1] that show various aspects of
Aniketos in order to create awareness about the importance of security and trust in a service
composition and deployment framework, and point out the contributions of the Aniketos platform and
tools. Currently the STS-tool is featured.
2.2.2 Local industry demo events
Local industry demo events have been foreseen by the Aniketos partners to take advantage of their
own knowledge in targeting their country industry. These demo events have been taken into
consideration as described in Chapter 3 and in particular concentrating the consortium efforts on
22
presentation and demonstrations of the Aniketos platform and on one-to-one communication with
industry players.
Demo events and related results will be reported in Chapter 5 using the template provided in Appendix
A.1.
2.2.3 Other events with industry target
The consortium members plan to organize workshops co-located with major conferences and summer
school targeting industry. A detailed plan on the activities foreseen is described per partner in D11.3 as
well as in D10.2 chapter 3.6.2.
The events are considered very interesting for the industry audience attending and for the opportunity
they could give us for establishing relations and disseminate the Aniketos platform and components
with industry.
The Aniketos outreach strategy includes the commercial sector and targets the following end users in
the ICT industry domains:
 Software developers,
 Software providers,
 Service providers,
 Service architecture providers,
 Security providers,
 ICT and Telco providers,
 IT and Telco vendors,
 Internet Service Providers,
 Cloud providers,
 End-users from Safety and Security Critical Domains.
Events that target industry are important for exploitation and community building for the following
reasons:



they are potential users of Aniketos project results themselves;
big companies in particular represent the so-called influencers, because of their huge impact on
the ICT and IT security markets. Aniketos plans to take advantage of the major industry
contributors with our consortium to maximise demonstration impact;
industrial stakeholders constitute a natural channel for the dissemination of the project and its
result to other potential Aniketos users. In addition, they are familiar with the needs of the target
groups which is helpful when addressing them.
23
3 Identification of targets
In WP9, target identification is the main objective of Task 9.1 - Identification of relevant user groups
of Aniketos results. In Aniketos, the work packages in the outreach group are relatively small and
closely related, but are kept separated due to the different activity types and funding rules. For this
reason, in this particular task, we exploit as much as possible cross-work package coordination. Thus,
the identification activity is closely coordinated within the outreach work packages, i.e. with WP8
(Tutorials and training), WP10 (Community building and standardisation) and WP11 (Dissemination
and exploitation), under the supervision of the exploitation manager.
As depicted in the following figure, demonstrations to be performed to a specific target are usually
referred to a particular scenario.
Figure 4: Identification process
The content of this chapter deals with the identification process in terms of:



user groups – stakeholders the demos will be targeted to;
demo material – material that will be produced;
scenarios – selection of meaningful business scenarios for the particular user groups.
It is worth noting that the identification process depends on:


the events to be addressed - the strategy to be followed in identification could be either to go
alone for events or to support (or piggyback on) outreach activities. The collaboration strategy
within outreach (WP8-WP11) has been extensively described in Chapter 2;
the availability of material - the outcome of work packages (WP1-WP5,WP6) and the degree of
integration of software modules will have an influence on the identification process, as described
in Chapter 4.
3.1 User groups and material
In order to better understand end-user roles, in Table 2 we recall the description of Aniketos
community members, i.e. the stakeholders that represent different Aniketos platform end users from
D1.2.
Table 2: Aniketos community members
User
Role
Aniketos authority
Maintains the software and service part(s) of the Aniketos platform, such as
Marketplace and Threat repository
Aniketos platform
contributor
User able to enrich the Aniketos platform with content like reference material,
demonstrations, examples services, guidelines and threat repository information
Service consumer
Service end user – final recipient of a service developed/composed with the
Aniketos platform
Service mediator – entity that both consume and provide service(s) with the aim to
provide added-value feature to services
24
User
Role
Service provider
Service mediator – (same definition as above)
Entity responsible for and offering services to service consumers at run-time
Service owner
Person/organization behind a service (liable responsible) that makes profit on it
Service developer
Stakeholder involved in the creation of a service
Service implementer/creator – builder of Aniketos compliant services (usually from
scratch)
Service composer – uses Aniketos platform to compose aggregate service(s) from
existing and compliant services
Re-composition agent1 – software that re-composes a composite service
Service designer – design/implement services by using Aniketos platform
Third-party
Certifier of trust for stakeholders involved in a service invocation
This section of the deliverable describes the user groups and the types of demonstration material to be
developed. The community of the above mentioned stakeholders will be used as a reference for the
identification of end-users for demonstrations. We will provide a list of user’s categories, and a
preliminary set of targets that will be addressed in Phase 2 demos. Then, we will consider the different
types of demonstration material that are suited to the envisaged categories of end-users.
3.1.1 User groups
This paragraph deals with user groups that will be targeted by demonstrations. As described in the
DoW, the list of potential targets belongs to the following categories: service developers, service
providers, consumers/citizens, media, industry, academia, standardisation bodies, etc.
Based on the above list, considering their motivations and needs, we have classified the user groups
into the following categories from the point of view of the demonstrations.

General public/customers – this category is composed by consumers that will be the end users
of Aniketos-enabled applications and services. The reason to address this group is to increase
end users’ care in services by offering high level of security and trust.

Industry –a very wide category that encompasses Telecom and ICT enterprise(s), Finance and
Health institutions, Public Administration(s), Local Public Sector, etc. that should be among
the main targets of the project results. So, there is a strong motivation to promote the Aniketos
philosophy to these categories, thus enabling new business opportunities in SOA.

Media – is intended all mass media that include also Internet. The reason behind this category
is general dissemination, but more importantly, the capability to reach a very large number of
users and entities by using web technologies.

Education & Research – is referred to any institutional and academic research activity and
related events (e.g. participation to conferences with papers, workshops and demos). In this
category we also include the standardization bodies. The main scope of this target is related to
the support of other outreach activities in Aniketos that will be carried out in the context of
WP8, WP10 and WP11 work packages. This category also includes the activities carried out
to demonstrate Aniketos outcomes during the periodic project’s reviews of the commission.
Table 3 represents a tentative strategy and the approach to demonstration activities for each category
of user groups that will be potentially addressed.
1
Re-composition agent is listed here even if it is neither a person nor an organization/entity.
25
Table 3: Approach to categories of user groups to be addressed
Category
Approach to demonstration
General public/customers
Ordinary people usually have a limited technical background. The approach to
demos for them could be to present Aniketos philosophy and practical objectives,
putting our stress into general concepts and examples of use, omitting the
technological details. The argument here is that end-users should be more interested
in having security and a single point-of-trust instead of understanding the
technology.
Consumers/citizens
Industry
-
Telecom and ICT enterprise(s), Health, (local) Public Administration, Finance, ...
Service developers
Application developers
Service providers
The industry sector is the main target for Aniketos. These categories usually include
other sub-categories that could be part of the Aniketos community. In general,
Service Providers, Application Developers and Service Developers are the most
suitable targets to show technical details and the underlying concepts of Aniketos.
Media
Radio, Television
These mass media are reaching a large and heterogeneous audience; then, a suitable
approach could be the same as that described for consumers/citizens. Presentations
will be audio/video samples.
Newspapers, Magazines
The level of demonstration should be tailored according to the type of publication
and the expected readers. Presentations will be limited to articles and interviews.
Internet
It is the most efficient and pervasive way to reach a wide and heterogeneous
audience, due to the availability and on-demand repeatability of e-communication
techniques. Powerful tools and extreme flexibility in designing and showing
demonstrations to specific target(s). In this sense, the Internet is to be considered an
enabler as well as a repository of Aniketos results for dissemination and
advertising. See D10.2.
Education & Research
Academia
Community of students and scholars engaged in higher education and research.
Possible approach is co-operation with tasks in Training (WP8) and Community
building (WP10).
Conference
Academic and/or trade conferences or workshops. Go alone for events or co-operate
with tasks in Communities (WP10) and Dissemination (WP11).
Standardization bodies
Aniketos studies and results could be submitted to standardization fora, supported
by practical demonstrations when needed. Task for Community building (WP10)
with the support of technical work packages (WP1-WP6).
As described in DoW the task of identification will take inputs from partners contributing to WP6
(Case studies) and WP7 (Validation and end user evaluation). However, demonstrations will not be
only linked to the three case studies (WP6), but will be aimed to audiences and communities over and
above those three domains.
Partners involved in WP9 have discussed potential targets for demonstrations which should consider
exploitation purposes and stakeholders interested in Aniketos results, and the conclusion was that
target groups should include at least user groups from the community build by WP10 plus other
stakeholders interested in WP6 and WP7 outcomes.
26
The reason behind considering WP6 is mainly that this work package is focussed on demonstrating the
applicability of Aniketos concepts to a selected set of case studies, each having a list of potential
stakeholders that belong to the industrial realm.
On the other hand, WP7 concentrates on evaluation and validation of Aniketos concepts (platform,
scenarios and case studies) with particular regards to end users’ experience. WP7 receives and
provides input to and from WP9, thus ensuring constant improvement of results.
Finally, WP10 deals with all the activities devoted to establish and enlarge a community around
Aniketos that include networking and dissemination of results.
In the following we give a brief analysis of stakeholders from the above mentioned work packages that
could be potentially addressed in demonstrations.
3.1.1.1 Realization of industry case studies (WP6)
The industrial case studies that are under development in Aniketos should be considered as a valid
reference for identifying business scenarios and potential stakeholders.
It is common sense to capitalize as much as possible on the partner’s expertise and on collaborations
inside Aniketos. Thus, the preliminary approach we decided to follow in the identification process was
to search for possible stakeholders inside the case studies.
Due to the involvement of some WP9 partners in the realization of Aniketos industrial case studies,
namely ITALTEL and ELSAG (lead of WP6), we have started to identify in these activities the
potential community of users that are suitable for demonstrations.
The case studies have been described in deliverable D6.1 in terms of user stories, technology domains,
domain specific requirements and security issues, and have identified an extensive list of users. This
section will analyse the categories of user groups that could be addressed in industrial case studies.
In our view, the most important stakeholders that should be considered from a commercial and a
business point of view are those getting advantages (revenues, savings) in adopting the Aniketos
framework.
For Case study A (telecom) the actors who can get revenues by using the Aniketos framework are, by
definition, Service Providers that earn money from the sale of services, and commercial Service
Developers (implementers, designers, composers) that could be considered as stakeholders induced by
the Service Providers’ commitments. In general, Service Providers will commit to Service Developers
in order to have their customer needs fulfilled.
It is well known that the direct business revenue for the Service Provider is in terms of ARPU
(Average Revenue Per User or Per Unit), that is used by all the companies that offer subscription
services to clients, for example, to telephone carriers but also to Internet Service Providers and hosts.
This measure of the revenue generated by one customer will be enhanced by Aniketos by promoting,
enabling and provisioning of new services to customers. The ARPU increase will include not only the
revenues directly billed to the customers, but also the revenues generated from service cross-usage
among Service Providers in a federated environment, payable in a well-defined regulatory federated
regime.
Case study A is mainly focused on end-users and the role of telecom operators in the future Internet,
with the applications being in the business of e-Commerce. Two main categories of users have been
described for case study A: end users and developers. End users are intended to be the consumers of
services. Developers use the Aniketos framework to produce a series of services that can be
dynamically composed or adapted while maintaining specific trust and security requirements.
In the table below we provide the list of users that could be addressed for case study A, together with
their role and some potential user group categories.
27
Table 4: Definition of users in case study A
Case study A - Future Telecom Services
Target users
Role
End users
Consumers
services
Providers
Service Provider
(SP)
Relying
(RP)
Developers
of
Party
Description
Example
Requestor of service
Customer participation in the
shopping process is the key element
vendors should incorporate in their
on-line shopping concepts. Social
shopping, private shopping and live
shopping reinvented the way
consumers purchase goods and
services in the Internet world.
Service Providers - Internet and
mobile on-line market segments,
e.g. Travel, Fashion, Dating
Sports, Media (audio/video), Health,
Banking,
Payments, Gambling/Gaming,
Branded resellers
Players in the mobile advertising
arena
Telecom operators
Network operators
Mobile enablers
Mobile Network Operators (MNOs)
Mobile
Virtual
Network
Operators/Enablers
(MNVOs,
MVNEs)
Offer
(composite)
services
and
applications
TLC operator
Aggregate and offer
secure
composite
services
Identity Provider
(IdP)
Authenticate users and
return attributes to
SP/RP
TLC operators could play the role of
IdP to 3rd parties
Service
developers (SD)
Application,
component
and
integration developers
that have access to
Aniketos Marketplace
Mobile application developers
The identification process in case study A is still underway and it will require further investigation.
Considering that TLC operators will play a central role in the definition of the case study A, we
consider it as a natural approach to develop demonstrations firstly towards the telecom operator that is
collaborating to the development of the case study (WIND). The involvement of other TLC operators
will be evaluated in the future, taking into account the potential conflicts that could arise among
competitors.
Case study B is focused on a specific safety-critical area, with very comprehensive requirements for
security, trustworthiness and standardization, namely Air Traffic Management (ATM). One of the
main identified operational enablers is the System Wide Information Management (SWIM). SWIM is
a distributed processing environment, which replaces data level interoperability and closely coupled
interfaces with an open, flexible, modular and secure data architecture totally transparent to users and
their applications. For the full description of categories, see descriptions in deliverable D6.1.
28
Table 5: Definition of users in case study B
Case study B - Air Traffic Management
Target users
Description
Example
SWIM
participants
–
i.e.
organizations involved in the
preparation and execution of the
flights
Aircraft
Boeing 787
Aircraft operator
Airport operator
National air carriers
AdR (Aeroporti di Roma)
SEA
(Società
Esercizi
Aeroportuali, Milano)
Radar
ENAV (flight controllers)
Meteorological services
Multi-role players within the
SWIM ecosystem
ANSP, AIS, CAA, Commercial
Operator, EU, GA, GAT, ICAO,
Industry, Military, AT, PSSG,
PUG, PMU, States, UAV/UAS
Air traffic control unit
Air traffic service unit
MET provider
EUROCONTROL
SWIM non-participants – i.e. legal
authorities,
aeronautical
standardization bodies and tax
collecting organizations
Complementary roles
Considering that it covers a very special field, and given that partners in WP9 have a very limited
experience in this realm, for the identification of user groups a support would be necessary from
partners working in case study B. Moreover, due to the huge complexity of the system, only design
time capabilities are going to be provided. For the reasons above, the consortium of partners in WP9
decided not to consider user groups (and thus demonstrations) from this case study. However, we
leave open the possibility to collaborate and give support for some case study B specific demo(s)
beyond Phase 2 of Aniketos.
The main purpose of Case study C (e-Government) is fully aligned with the strategic agenda for
Digital Europe and the i2010 initiative, which will guide the activities in the area of public service
delivery for the next few years. The identified gaps between the existing solutions and the
requirements of security and trustworthiness can be effectively addressed by Aniketos.
Table 6: Definition of users in case study C
Case study C - Land buying and e-Government
Target users
Role
Description
Example
End users / private
sector
Interested Party (IP)
Party interested in the
acquisition of a lot and the
construction of a building
Person/company owning a
lot that wants to sell
Offers his service in an
online database
Civil contraction enter-premier
Certified professional to
assist an interested party in
the construction of a
building
Company that holds a
database of lots available
for sale
Civil contraction employee
Lot owner
Solicitor
Civil Engineer (CE)
Real estate
(REA)
Organizations
agent
Municipality
of
Athens/Department
Issuance of building permits
Common person
Building
employee
Trade
Agencies
Building Trade Agencies
Building Trade Associations
Building
Trade
services
merchandising
Public
Local
Administration
Authorities
29
Case study C - Land buying and e-Government
Target users
Role
Description
Example
of Urban Planning
(DoUP)
Technical chamber of
Greece (TEE)
Database to look for CEs
Greek Government
Organism setting legislative
framework
Bank
Fora/citizen
communities
Providers of additional or
supportive information
Administrative Districts
Urban Planning Committees
Planning Permission Entities
Public
Local
Administration
Authorities
Administrative Districts
Public Central Administration
Authorities
National Banks
Public
Local
Authorities
Administration
The identification process in case study C is still underway and requires further investigation. Case
study C involves, apart from private parties, a lot of Public Administration entities.
Considering that some partners (e.g. DAEM) are organisations dedicated in developing and providing
e-Government implementation services to local government authorities and other public organisations,
we believe it is a suitable approach to support these partners in building demonstrations aimed to
promote e-Government applications to interested stakeholders.
Finally, it is worth observing that demonstrations, apart from the above mentioned stakeholders, could
be aimed to other categories of users (e.g. general public, conferences, media, ...), as explained in
section 3.1.1.
3.1.1.2 Validation and end user evaluation (WP7)
As part of user evaluation studies being carried out in WP7 a number of studies involving the initial
evaluation of project artefacts, the interview study for evaluating Aniketos scenarios and approach,
and the user acceptance assessment of Aniketos concepts helps identifying new user groups that could
view WP9 demonstrations at a later date.
The following table resumes the targets of evaluation and validation that will be addressed by
Aniketos partners in WP7 and the potential categories of the target user groups.
Table 7: User groups and targets in WP7
Target
Partner
User groups
1: Socio-technical security modelling
language and tool
PLUS
All types of intended users of the modelling
language and tool
End-user
groups
interested
in
modelling/analysing security and trust
properties in service compositions
End-user groups interested in assessing
security and trust properties in service
compositions
System security risk manager, System
security architect, System architect, System
engineering manager
Aniketos Authority, Aniketos platform
contributor, Aniketos community member
Service developers, Service providers
Service developer, Service provider, Service
end user
DBL
2: Security & risk
methodologies and tools
assessment
DBL
3a-d: Aniketos results for architecting
and design phases
TRT
4a-b: Community support module
TSSG
5: Trustworthiness prediction module
6: Monitor trustworthiness module
7a,b: Contract negotiation module
ITALTEL
TSSG
TSSG
TSSG
30
Target
Partner
User groups
8: Security verification module
LJMU
Service composer, (Re)composition agent,
Aniketos community
Aniketos framework administrator, Services
developers
end user
Service developers, Service composer,
(Re)composition agent
Service developers at design time
end user
(Re)composition agent, End user and service
developer
System (Aniketos) administrator
end user
Service developers at design time
end user
Aniketos platform administrators
end user
Aniketos platform administrators
end user
Service end users
ATOS
TSSG
9: Security property determination
module
LJMU
ATOS
TSSG
10: Security
module
policy
monitoring
LJMU
ATOS
TSSG
11: Threat response recommendation
module
ATOS
TSSG
12: Service threat monitoring module
ATOS
TSSG
13: Notification module
14: Threat repository module
ATOS
TSSG
15: Aniketos platform concepts and
user interface
ITALTEL,
WIND
PLUS
16: Secure
module
composition
planner
DAEM
LJMU
All types of intended users of the Aniketos
platform
Service end users
(Re)composition agent, End user and service
developer
All partners working in WP9 are also involved in WP7.
ELSAG is mainly involved in scenario based evaluation and Aniketos platform evaluation. This will
be mainly targeted to service developer and service providers involved in case studies realization.
ITALTEL is mainly involved in evaluation of the Community Support both from the point of view of
platform components and of industrial case studies. Possible target(s) will be the end users involved in
the execution of case study A – ‘future telecommunication services’.
TECNALIA leads the D1.2 scenario evaluation and the evaluation of the Model Transformation
Module of the platform, which is used by the developer through a User Interface and therefore it is
important to assess the understandability, usability and performance satisfaction.
TSSG is mainly involved in the scenario-based evaluation of modules.
The works of validation and evaluation work package will be continuously monitored even beyond the
Phase 2 of the Aniketos project in order to find suitable categories of user groups to be addressed by
demonstration activities. In particular, the works carried out in the following tasks:

Task 7.3 – Scenario based evaluation;

Task 7.4 – Validation and evaluation of the Aniketos platform;

Task 7.5 – End user evaluation of the industrial case studies,
31
will be useful to address suitable targets. At the time of writing, the most mature activities are those
related to Task 7.4 that are aimed to service developers and service providers as end-users of the
Aniketos platform modules. A category that could be potentially addressed will be the users of the socalled interaction layer of the Aniketos environment (e.g. designers using STS-tool and SCF modules
of Aniketos for creating secure service compositions).
3.1.1.3 Community building and standardization (WP10)
In a nutshell, as described in [4], WP10 will address:
 (open-source) communities
 commercial developers (implementers, designers, composers, providers)
 networking with EU projects
 research communities
 technical platforms.
Networking with target communities have been extensively described in deliverable D10.2 and will be
leveraged by WP9 materials. WP10 is aiming to use the demo material for outreach purposes as a
tangible integrated Aniketos solution for the above mentioned stakeholders. In addition, the WP10
work package have realised many outlets for communications such as the project website and several
Aniketos accounts (e.g. Twitter, LinkedIn, SlideShare, GitHub and YouTube) that could be potentially
used as dissemination channels for the material produced in the demonstration work package.
3.1.2 Demonstration material formats
This paragraph deals with the type of demonstration material. According to what is described in DoW,
the material could be produced in different formats, like videos, screencasts, interviews, software and
manuals, that will be usable for demonstration purposes as described in the following table.
Table 8: Type of material
Material
Usable for
Video
Registration
of
live
presentations or interviews
demonstrations,
animated
Screen-cast
Registration of a demonstration storyboard
Interview
Discussion aimed to a specific target or collection of
feedback after a demo event (in written/electronic form)
Demo software
Support for live demonstrations
Customization of WP5 (platform/environment)
and WP6 (models) outcomes
Demo software distributed to third parties for evaluation
purpose
Manuals and installation instructions for the
software
Demo software support
The material will be usually presented during demonstration events and be available on our web site,
but it is also envisaged to send material in electronic form to interested users or to grant the access to a
web-site storing on-line material. Doing this way, there is also the advantage that feedback could be
directly collected in electronic form. Another advantage of on-line demonstrations is the considerable
number of users that could be reached in a single event. In Chapter 4, we will examine in detail the
tools available for content sharing and the methods for collecting feedback.
The accomplished analysis can be summarized in the following table, giving an overview of the
combinations of target user groups and material that will be potentially useful for demonstrations
during the Phase 2 of the project.
32
Table 9: Example list of targets and material
6
Manuals
x
Software
1
2
3
4
5
Interview
Video
ID
Screencast
Material
Targets
x
x
x
x
x
x
Edu & Research
SP, SD, users
Edu & Research
Internet
Edu & Research
x
x
x
Demo type
Live demo held at first periodic review
Demo case study A or C (design time)
Live demo for second periodic review
Animation presenting Aniketos philosophy
Video of demo to be presented at workshop or
conference
Media (Magazine)
Report of demo activities and discussion of results
It is important to note that this preliminary list needs to be consolidated by taking into account the
availability of the Aniketos system that will be further analysed in Chapter 4. A comprehensive list of
the demonstration material and events for Phase 2 will be fully described in Chapter 5.
3.2 Business scenarios
As suggested during the first project review, a major driver for exploitation could be to build a real
business case by involving real service providers and users. As WP9 aims to support outreach it is
worth to examine in brief which kind of scenarios the demonstrations will be referred to.
The scope of this paragraph is to identify a suitable set of business scenarios that could be used to
demonstrate the benefits of the Aniketos platform.
3.2.1 Analysis of scenarios
This paragraph deals with the analysis of the scenarios, by taking into account that:


business scenarios could be very demanding in terms of resources for their implementation;
WP9 is aiming to demonstrate scenarios but with a relatively small effort available for the actual
developments.
Although it is possible to start thinking to business scenarios by adopting a clean slate approach, it
seems reasonable to begin with an analysis of the multitude of scenarios that have been produced in
Aniketos by other work packages during the project’s timeframe.
So far, scenarios produced by Aniketos could be classified into the following categories:





basic scenarios (WP1)
development scenarios (WP1,2,3,4)
integration scenarios (WP5)
industrial case study scenarios (WP6)
evaluation/validation scenarios (WP7).
In the following, we will briefly recall the approach adopted in each category; for every Aniketos’
project work package, we describe the scope of deliverables and the contents that are relevant (or
useful) to build business scenarios.
Conclusions and implications to WP9 will be given in the subsequent section 3.2.2.
33
3.2.1.1 Basic scenarios (WP1)
Deliverable D1.2 provided a view of the system architecture. A brainstorming generated a set of
envisaged scenarios for Aniketos platform usage that has been used as a basis for requirements
extraction, the architecture design and as starting point for user stories in several other deliverables.
The scenario development has been essential as they define the project context and function as a mine
for requirements and possible demonstration scenarios. Appendix B of D1.2 gives an overview of the
scenario handling process and contains the full scenario descriptions.
WP9 have used this list of use case scenarios to identify the best demonstration of the Aniketos
platform. Scenarios produced by deliverable D1.2 are very heterogeneous as they approach a large
variety of stakeholders in different application realms with different levels of complexity. Scenarios
and requirements contained within these views have been guiding us and contributed to a common
understanding on the goals and vision of Aniketos. However, it is not easy to formulate a selection
based on those business scenarios that could be useful for demonstrations in Phase 2, because the
descriptions do not take into account the resources that will be needed for their implementation.
Moreover, it is worth mentioning that the scenarios provided in deliverable D1.2 should be considered
preliminary as they will be iteratively extended and improved by WP1 activities in subsequent
deliverables (e.g. D1.5) thus following the evaluations of technical results (WP7) and the case studies
settings (WP6).
3.2.1.2 Development scenarios (WP1, WP2, WP3, WP4)
In this paragraph we give a short overview of scenarios provided by technical work packages for
deliverables which have been scheduled for Phase 2.
Deliverable D1.3 presents the initial version of the socio-technical security modelling language of the
Aniketos project (STS-ml, for brevity) and describes the initial prototype of the support tool for such
language. This deliverable presented several extended usage scenarios (mainly from D1.2) for the
applicability of the modelling language. The addressed realms for scenarios are the same as those from
industrial case studies.
Deliverable D2.2 presents the first version of the WP2 prototype, composed by three physical
components (i.e. the Trustworthiness component, the Security-by-Contract component and the
Verification modules component) that will be used in Aniketos either in composite service creation
phase or in service run-time phase. It is worth noting that some functionalities of WP2 components
will be shared with other WP3 components. As regarding scenarios, a typical usage scenario has been
created for each component thus driving design and consolidation of requirements. For example, a
usage scenario is related to a service provider TrustedMedia that aggregates services from a number of
other service providers in communications and media sectors including TV, phone, online games,
news and entertainment to fulfil customer requests. For each type of service providing the same (or
similar) functionality, TrustedMedia has to select from a collection of services from a number of
service providers. In order, to help its own business’s trustworthiness, reputation and the reuse of its
services, TrustedMedia needs to select the services that meet the highest expectations. Hence, it
decided to rank services in each service type (e.g. A, B) based on their trustworthiness into A1, A2,
A3, B1, B2, B3, etc. TrustedMedia then selects the services with best trustworthiness.
Deliverable D3.2 presents the first version of the WP3 prototype, composed by four physical
components (i.e. the Secure Composition Planner module, the Security Property Determination
module, the Contract Manager module and the Composition Security Validation module). For SCPM,
usage scenarios have been defined in order to demonstrate the functionality of the module. In addition,
relevant scenarios of D1.2 were considered to check whether the overall design fulfils the
requirements for design time secure service composition. Some functionalities of WP3 components
will be shared with WP2 components, but are limited only to design time secure service composition
process (run-time service composition will be supported in the future).
34
Deliverable D4.2 provides a demonstrable set of tools as a prototype for the methods that are
identified in D4.1 as being needed in order to respond to changes and threats. The WP4 prototype is
composed by the Notification module, the Threat Repository, the Threat Response Recommendation
module, the Service Threat Monitoring and the Security Requirements Compliance Module
The status of implementation of components from work packages WP1, WP2, WP3 and WP4 are
analysed in detail in Chapter 4.
3.2.1.3 Integration scenarios (WP5)
Deliverables D5.1 and D5.2 deal with design and initial integration of the Aniketos platform. The
Aniketos platform, described in D5.1, will offer design time and run-time support for a secure and
trustworthy service composition. In addition, deliverable D5.2 provides test and integration scenarios
that will be adopted to assess that the integration activities have succeeded in their goals for Phase 2.
In addition, it is worth to mention that a number of demos with some degree of integration have been
presented in a session during the Aniketos plenary meeting held in Paris (February, 2012). These
demonstrations provided in some way a first attempt to show part(s) of the Aniketos system and the
interworking among modules and components, namely:




STS Tool – a fully graphical tool to model an organization and express security needs
Threat Repository Module – a searchable directory for threats and link to countermeasures
Marketplace module – a module for storing Aniketos services’ descriptors
Notification Module – a module that allows other modules to register for certain types of events
and be notified
 Trustworthiness module – an integrated version of the WP2 prototype, i.e. the first release of
Trust Management, Security Contract and Verification Modules
 Secure Composition Planner Module – a module in which composition plans can be verified and
ordered by trustworthiness, availability, privacy and confidence
 Service Composition Framework - a module that can discover services registered in the
Marketplace and bind service tasks with them, thus generating composition plans.
 Verification module - a module for validation of a composed service. A security requirement can
be read from the contract: when a goal is violated the attack is visualized.
The activities of WP5 work package are crucial as WP9 will rely upon the deliveries of the Aniketos
platform in order to build demonstrations: for this reason, the status of integration activities in WP5
will be continuously monitored. The status of implementation of components from WP5 will be
analysed in detail in Chapter 4.
3.2.1.4 Industrial case study scenarios (WP6)
Deliverables D6.1 and D6.2 give the description and the realization planning of industrial case studies
(A, B and C). In D6.1, the case studies are described in terms of user stories description, technology
domains, domain specific requirements and security issues.
Case Study A deals with telecom operators that use the Aniketos platform in order to support the socalled Telco 2.0 business model. In order to improve end user experience in accessing these services,
the realization of this case study foresees the usage of a Federated Identity Management system. In
particular the Telco operator wants to exploit Aniketos platform in order to build two user stories:


User Story A1 - web portal development - the operator wants to discover service components that
conform to its security requirements in order to build composite services or web applications
featuring the desired level of security and trustworthiness.
User Story A2 - IdP service development – the operator is willing to expose its network resources
as services in the Aniketos Marketplace.
35
Case Study B is devoted to ensure a secure and trustworthy exchange of safety-critical information
among all the Air Traffic Management (ATM) and aviation stakeholders after the introduction of the
System Wide Information Management (SWIM). The SWIM case study is restricted to design time.
Case Study C targets the e-Government domain. It involves multiple service providers and
consumers, who interact with each other to enable accessing the most up-to-date procedures,
information on relevant regulations and advice on associated costs, which affect decisions when
acquiring land and issuing the respective building permit. The business process is carried out in three
steps:



searching for the lot (User Story C1),
managing the lot (User Story C2),
issuing the house building permit (User Story C3).
User stories have been fully described in deliverable D6.1. The following table summarizes the
scenarios and the relevant design time (DT) and run-time (RT) features of each industrial case study.
Table 10: Relevant features of the industrial case studies
Case study
Description
DT
RT
A1
Portal development & user experience in TLC/web services
x
x
A2
IdP service development (service exposure)
x
NA
B
SWIM validation by using modelling tools
x
NA
C1,C2,C3
Search for a lot, get support for purchase and building permission(s)
x
x
Design time features will be used essentially for building the framework of the application (i.e. the
services), while RT will be used during the execution of the user story.
It is important to note that in the Phase 2 of the Aniketos project, design time features were in focus in
WP6, thus the scenarios related to industrial case studies were built taking this into account.
3.2.1.5 Evaluation and validation scenarios (WP7)
In deliverable D7.1 it was stated that Aniketos evaluation approach will be mainly based on a scenario
based methodology, because they are the most mature evaluation approaches. They are founded on the
definition of some scenarios that are meant to describe the behaviour of the system with respect to a
particular quality attribute and in a particular context. Typical examples of scenario-based methods
are: Software Architecture Analysis Method (SAAM), Architecture Trade-off Analysis Method
(ATAM) and Architecture Level Modifiability Analysis (ALMA).
For the evaluation of Aniketos architecture quality attributes in WP7 (deliverable D7.2) a set of
scenarios (specified set of steps related to specific attributes) involving different components of the
architecture has been designed. WP9 takes profit of such work and extends or adapts it to identified
target groups for the demonstrations.
3.2.2 Comparative analysis and conclusions
The following table summarizes the scenario’s categories described above with pros and cons
stemming from their potential implementation.
Table 11: Analysis of Aniketos scenarios
Scenario
WP
Pros
Cons
DT/RT
support
Generic
business
scenarios, addressing many
High-level – i.e. somewhat
difficult to implement.
Any
(Deliverable)
Basic
WP1
(D1.2)
36
Scenario
WP
Pros
Cons
DT/RT
support
different realms.
Not considering the system
complexity to build the use
case around the selected
scenario. Need of resources
for additional developments
and refinements.
(Deliverable)
Development
WP1,2,3,4
(D1.3, D2.2,
D3.2, D4.2)
Relatively
implement.
easy
to
Low-level – i.e. specifically
aimed to development of
software modules and
components.
Limited coverage
Aniketos system.
Integration
WP5
(D5.1, D5.2)
Industrial case
study
WP6
(D6.1, D6.2)
of
DT
RT limited
the
Based on the current status
of developments (up-todate implementations).
Not all functionalities will be
covered in Phase 2.
DT
Aniketos applied to real
business scenarios.
Not all functionalities will be
covered in Phase 2.
DT
only
(Phase 2)
RT limited
(imposed by
technical
WPs)
From the analysis of scenarios we can draw the following conclusions, related with their use as
baseline work for demonstration scenarios in WP9:

Basic scenarios could be interesting but some of them would be either too generic or very
demanding in terms of resources for implementation. Refinements are supposed to generate new
interesting business scenarios or to update existing ones, but this process probably will extend
beyond Phase 2 of the project.
 Development scenarios are relatively easy to implement but often too low-level and will be
suitable for showing only limited part(s) of the Aniketos system. However, it should be worth to
consider the possibility to deploy and to extend the scenarios covered by demos that are already
available, taken from the outcomes of technical work packages (WP1-WP4).
 Integration scenarios will be useful for showing the real capabilities of the Aniketos system. With
all the limitations imposed by the underlying technical work packages deliveries, some design
time capabilities and (to a less extent) RT capabilities will be available during the timeframe of
D9.1.
 Industrial case study scenarios will have a direct impact on real business opportunities as
explained in DoW, even if for Phase 2 the consortium decided to provide only design time
features, so we should take into account this limitation in building demonstrations.
 Evaluation/validation scenarios for Phase 2 demonstrations are not available because they are
being developed currently. For Phase 3 we will take profit of such work and consider the need of
improving or adapting such scenarios to be used as demonstration scenarios.
In conclusion, a suitable approach in WP9 will be to give some priority to industrial case studies dealt
with in WP6, but the development of demonstrators (presented in Chapter 5) will also take into
account the level of maturity of the modules, material and additional scenarios that WP5 will produce.
37
4 Development process
This section explains the development process and the tools used for demonstration material
development in WP9.
The next sections will briefly describe:




the Aniketos platform which is the core of the demonstration material,
the software tools used in the creation of the material,
the methods identified in order to collect feedback from the demos,
the tools adopted to store and make the material available to the different stakeholders.
4.1 Aniketos platform
This section describes the Aniketos platform and the different parts it comprises with regards to the
demo material that will be developed in the project.
According to the D1.5 realisation viewpoint, the Aniketos platform consists in the following physical
components:
Table 12: Aniketos components
Physical components
Name: STS tool
Reference:

D1.3 - Initial version of the socio-technical security modelling language and tool, section 5.

D5.1 – Aniketos platform design and platform basis, section 4.1.1.
Name: Microsoft Visio (used prior to the STS tool)
Reference:

D1.3 - Initial version of the socio-technical security modelling language and tool, section 6.2.
Name: Model Transformation Module (MTM)
Reference:

Name: Trustworthiness component
Reference:

D2.2 - Initial Prototype of Trust Management, security-by-contract and Verification Modules, section
2.2 and 3.1.

Name: Contract Manager module (CMM) (part of the SxC component)
Reference:

2.2 and 3.2.

D3.2 – Initial Prototype for Secure service composition, sections 3.3.2 and 4.3.2.

Name: Security Property Determination Module (SPDM)
Reference:

D3.2 – Initial Prototype for Secure service composition, sections 3.2 and 4.2.

38
Physical components
Name: Security Property Verification module (SPVM) (part of the Verification component)
Reference:

2.2 and 3.3.
Name: Composition Security Validation Module (CSVM) (part of the Verification component)
Reference:

2.2.

D3.2 – Initial Prototype for Secure service composition, section 3.3.1.
Name: Secure Composition Planner Module
Reference:

D3.2 – Initial Prototype for Secure service composition, sections 3.1, 4.1, 5.2 and 6.2.

Name: Security policy monitoring module (part of the SxC component)
Reference:

2.2 and 3.2.

Name: Threat response recommendation module (TRRM)
Reference:

D4.2 - Initial prototype of the mechanisms for the response to changes and threats, section 7

D4.1 - Methods and design for the response to changes and threats, section 5.2.3.3.
Name: Service Threat Monitoring Module (STMM)
Reference:

D4.2 - Initial prototype of the mechanisms for the response to changes and threats, section 6.


Name: Notification module
Reference:



Name: Community Support Module (CSM)
Reference:

Name: Threat Repository Module (TRM)
Reference:



Name: Marketplace
39
Physical components
Reference:

D5.1 – Aniketos platform design and platform basis, section 4.1.13
Name: Training Material Module (TMM)
Reference:

Name: Security Requirements Compliance Module (SRCM)
Reference:

When demonstrating Aniketos platform or its individual components, the demos will make use of
some Environment components that interact with the platform, mainly Service Composition
Framework (SCF), Service Runtime Environment (SRE) and Service registry. In the next figure taken
from the current architecture document (D1.5, due April 2013) we can see the interaction of the
Aniketos logical components with the Environment.
40
Figure 5: Aniketos platform and Environment decomposition model
The following table shows a classification of the demo material in terms of usage of Aniketos
platform, at trustworthy service design time (DT) vs. at service run-time (RT), and according to the
availability and maturity of the needed results to develop the demonstration materials.
In the table we have indicated the implementation status that refers to the availability and/or maturity
of the functionality with respect to the full functionality foreseen for the component for the end of the
project. This gives a degree of how complete the demo will be.
41
Table 13: Aniketos components status of implementation
Demo
material
available for
M24
Component
DT/RT
Interface
Implementation
Status (M22)
Socio-technical
Security
Modelling Tool
DT
IModelling
Dummy
Video
(web
site [1])
Model
Transformation
Module
DT
ITransformation
Dummy
No
Trustworthiness
Component
RT
ITrustworthinessService
First Draft
Video (Paris
meeting)
INotification
First Draft
IMonitoringServiceAccess
Dummy
Contract
Manager Module
RT
IContractManagerService
Dummy
No
Property
Verification
Module
RT
PropertyVerificationService
First Draft
Video (Paris
meeting)
Composition
Security
Validation
Module
RT
CompositionSecurityValidationService
Dummy
Video (Paris
meeting)
Security Property
Determination
Module
RT
IService
First Draft
Video (Paris
meeting)
Secure
Composition
Planner Module
RT
CompositionPlannerInterface
First Draft
Video (Paris
meeting)
Security Policy
Monitoring
Module
RT
ISecurityPolicyMonitoring
Dummy
No
MonitoringServiceAccess
Dummy
Service Threat
Monitoring
Module
RT
IThreatMonitoring
Dummy
IThreatEvent
Dummy
MonitoringServiceAccess
Dummy
No
IAlert
Notification
module
RT
Community
Support Module
RT
IAlert
First Draft
INotification
Dummy
CommunitySupportService
Dummy
Video (Paris
meeting)
No
42
Demo
material
available for
M24
Component
DT/RT
Interface
Implementation
Status (M22)
Threat
Repository
Module
RT
ThreatRepositoryService
First Draft
Video (Paris
meeting)
Marketplace
DT&R
T
IMarketplace
First Draft
Video (Paris
meeting)
Training Material
Module
RT
TrainingMaterialService
Dummy
No
Service
Composition
Framework
DT
ServiceCompositionFrameworkInterface
First Draft
Video (Paris
meeting)
Service Runtime
Environment
(MUSIC)
DT&R
T
INotification
First Draft
Video (Paris
meeting)
Identity
Management
Service
RT
IdM
First Draft
No
Security
Requirements
Compliance
Module
DT
IComplianceVeifcationService
Design
No
In the following, we provide an overview of the integration status, (taken from Aniketos eRoom), in
order to identify the technical stuff which is available for developing demos in Phase 2.
Table 14: Aniketos integration status (as of July, 2012)
Components
Involved
Responsible
Partners
Description
Service Composition
Framework,
Marketplace
ATC,
Elsag
The
SCF
capable
discovering
services in
Marketplace
Selex
is
of
Status
Next
Deadline
Completed
-
Notes
the
Service Composition
Framework, Secure
Composition Planner
Module
Selex Elsag,
LJMU
The SCF is able
to send all the
created
composition plans
to the SCPM
Completed
-
Secure Composition
Planner
Module,
Security
Property
Determination
Module
TSSG, LJMU
SCPM is able to
get
properties
from SPDM
Completed
-
SPDM needs
connect
marketplace
Secure Composition
Planner
Module,
Contract
manager
Module
CNR, LJMU
SCPM
sends
composition plans
to
CMM
for
verification
Completed
-
CMM used here is a
simplified version
without
Trustworthiness
to
to
Components
Involved
Responsible
Partners
Description
43
Status
Next
Deadline
results
Notes
module
Environment
Monitor (PRRS) and
Notification Module
SINTEF,
ATOS
Register
the
PRRS
for
receiving
notifications from
the Notification
module
Completed
-
Environment
Monitor (/PRRS) and
Service
Threat
Monitor
ATOS, Thales
Sending Events
from PRRS to
Threat Monitor
Completed
-
Environment
Monitoring (PRRS)
and Marketplace
ATC, ATOS
PRRS gets the
serviceID
from
the Marketplace
to
build
the
ThreatEvent
Completed
-
Service Composition
Framework,
Composition
Security Validation
Module
SAP,
Elsag
Selex
Both the modules
are
integrated
inside an eclipse
rcp application
Completed
-
Service Composition
Framework, Identity
Management Service
Italtel,
Elsag
Selex
The SCF calls the
IDM in order to
authenticate the
service developer
Completed
-
The PRRS sends 2
events to the STM.
One of them trigger
an alert in the STM
that is shown in the
Notification
Console
The Aniketos system’s demonstrations can be roughly split into the two following categories:


Individual tool demonstration - tool demonstrations show how individual tools are used. Instead of
focusing on development tasks, each demonstration focuses on one specific tool and addresses
mainly the potential users of the tool. The underlying assumption is that the viewer is already
familiar with Aniketos platform but wants to learn more about individual tools.
Aniketos platform demonstration - Aniketos platform demonstrations show the overall added
value provided by Aniketos to the service composition process. The demo does not concentrate on
a particular component of the platform but shows how the platform components interact with each
other to support the secure service composition and run-time adaptation. The Aniketos platform
demos could be focused on either design time support or run-time support or both. The audience
of these demos is enlarged and will contain tool users, SOA architects and product managers.
The provided material will be likely in the form of screen-cast and video, as already described in
Chapter 3.
44
4.2 Tools and Methods
4.2.1 Development tools
4.2.1.1 Screen-casting software
Screen-casts are recorded sessions of the changes over time that a user sees on a computer screen,
enhanced with audio narration and/or subtitles. This medium is appropriate for tool demonstrations,
and for high impact requires the tools to work well and to have well-designed user interfaces. A
screen-cast is an excellent tool for generating interest in a tool, but when used in isolation must be
combined with the availability of demonstration tools that users can try on their own. Screencasts can
also be included as elements in slideshows and videos, in which case access to real tools is not
essential. Audio narrations or voiceovers require a person with a good reading voice.
There is a number of software for recording screen-casts, among which Freeseer and VLC media
player are both GPL and compatible with Windows, Linux and Mac OS X.
Table 15: Examples of open-source tools for screen-casting
Product Name
Publisher
Latest
Stable
Version
OS
Software
License
FFmpeg
CamStudio
RecordMyDesktop
VLC media player
FFmpeg.org
CamStudio.org
SourceForge
SourceForge
0.9
2.6 Beta
0.3.8.1
2.0.1
LGPL
GPL Version 2
GPL
GPL
VirtualDub
Avery Lee
1.9.11
Cross-platform
Windows
Linux
GNU
Linux
Windows
Mac OS X
FreeBSD
Syllable
OS/2
BeOS
Windows
GPL
A complete comparison of available screen-casting tools/software is described in section A.3.
4.2.1.2 Video
Video is perhaps the most flexible medium, capable of conveying both factual and emotional content.
Thanks to the proliferation of video sharing on the Internet, viewers have come to expect high
production values, so for maximum impact, video needs to be planned, filmed and produced at a
professional level.
For professional quality of the videos, to make it more attractive, videos require specialised equipment
(cameras, lights, green screens, video editing facilities), software (video editing, effects, postproduction), skilled staff, actors. But in Aniketos, in a first approach, we will record and edit videos in
post-production with open-source tools and with no professional actors, but consortium members.
Depending on the success got by our demonstrations other more professional alternatives will be
studied.
Video may include elements of slideshows, storyboards, comics, and screen-casts. Tool demonstration
videos are assumed to include screen-casts.
Videos should be combined with printable materials, suitable for off-line reading.
The following table summarizes the most well-known open-source tools for video editing.
45
Table 16: Examples of open-source tools for video editing
Product
Name
Publisher
Latest
Stable
Version
OS
Software
License
Open Movie
Editor
Open Shot
VirtualDub
Kino
OpenMovieEditor.org
0.0.20090
105
1.4.2
1.9.11
1.3.4
Linux
GPL Version 2
Linux
Windows
Linux
GPL
GPL
GPL
openshotvideo.com
Avery Lee
SourceForge
4.2.1.3 Animation software
Nowadays, some impressive computer animation can be achieved even with basic programs; however,
the rendering can take a lot of time on an ordinary home computer. Because of this, video game
animators tend to use low resolution, low polygon count renders, such that the graphics can be
rendered in real time on a home computer. Photorealistic animation would be impractical in this
context.
Creating animations can be easier with the HTML 5 Canvas, but is only supported by limited set of
navigators: Chrome 1.0, Firefox 1.5, Internet Explorer 9, Opera 9.0, Safari 1.3 (and beyond these
versions).
In the following table we have tried to collect the list of well-known open-source tools for 2D
animation.
Table 17: Examples of open-source tools for animation
Product
Name
Publisher
Latest
Stable
Version
OS
Software
License
Pencil
SourceForge
0.4.4b
GPL
Synfig
Studio
synfig.org
0.63.05
KTooN
Tupí
ktoon.net
maefloresta.com
0.9a
0.1
Windows
Linux
Mac OS X
Windows
Linux
Mac OS X
Linux
Windows
Linux
Mac OS X
GPL
GPL
GPL version 3
A complete list of available animation software is provided in section A.4.
4.2.2 Feedback methods
Demonstrations’ feedback will be collected either in written or electronic form. In the latter case,
feedback from targeted user groups is gathered via online surveys, including common types like:



e-mail - survey is emailed to targets, either as a link to a web-based survey, or questions are
included in the body of the email. Often used as a post-transaction survey, as well as for broader
user feedback collection,
pop-up - pops up with a request for feedback after a visitor has landed on a website,
website - a link on a website to a survey.
From D7.1 Chapter 5 - the toolbox of available methods are listed in the following:

List of methods
 Usability testing
46









Usability enquiries
Usability inspection methods
Paper prototype testing scenario
Cooperative evaluation
Surveys
Interviews
Direct observations
Functionality tests
End-to-end/integration test.
From these methods the surveys and interviews seem to be the most proper ones for getting feedback
from the demo target user groups about:


Individual tool demonstrations
Aniketos platform demonstrations.
4.2.2.1 Surveys
In either form (written or electronic), the design of a survey often has an effect on the quality of data
gathered. There are many factors in designing a questionnaire, i.e. guidelines, available question
formats, administration, quality and ethical issues should be reviewed.
The surveys in Aniketos will be in electronic form and when selecting the tool for creating the survey
questionnaires, the criteria are:





Free and online.
Easy design of the survey, good usability.
Export options.
Customization options for an attractive look and feel of the survey design.
Lack of publicity on the header and footer that may disturb the responder.
In the following table, we provide a list of free online survey software:
Table 18: Examples of open-source tools for surveys
Product
Name
URL
Free
Accounts
Export options
Customization
options
kwiksurveys
http://kwiksurveys.com
Available
Yes
Yes
SurveyMonkey
http://es.surveymonkey.c
om/
Available
No (in free account)
Yes
eSurveysPro
http://www.esurveyspro.
com
Available
No
PollDaddy
http://polldaddy.com
Available
No
Wufoo
http://wufoo.com
Available
Yes
Yes
The surveys will be designed for each of the demos presented in Chapter 5.
4.2.2.2 Interviews
In WP9, interviews will intend to collect any feedback from the demo target groups on the technical
concepts underlying the Aniketos platform that have been addressed during the specific demo. User
feedback would be useful in order to assess how the demo actually serves the purpose of explaining
47
the usage of Aniketos platform (or individual component/s) and its associated benefits in the
trustworthy service composition or provisioning.
Compared to the online surveys, the interviews will give more explanatory feedback, as the
interviewer can discuss the answers with the interviewees and go deeper in specific aspects (e.g.
suggestions for improvement). Another important difference is that, whereas the on-line survey can be
filled out at any time by the demo attendees, the interview implies some time is planned after the demo
for face-to-face meeting. As a consequence, the interviews will be done only when the demo audience
has not been too big or particularly relevant attendees have taken part.
Interviews can be made either with individual attendees or with groups, but we judge more appropriate
to have individual interviews so the attendee can answer as freely as possible.
Scripts with questions for semi-structured interviews will be developed for each of the demos
presented in Chapter 5, that could be similar to the online surveys with additional questions targeted to
the particular interviewee (about the company, previous experience, improvement ideas, etc.). We will
take the references in section 5.1.7 Interviews of D7.1 Validation and evaluation plan as starting point
for developing the scripts.
4.3 Storage and availability
Storage of demo material in Aniketos platform will be part of the Community Support features offered
by the platform. Before the platform is completely available at the end of the project, the publishable
material will be stored in the Aniketos website [1] and will be made accessible to the general public.
Access will be provided after registration in order to fully control the down-loads from the webpage.
Once the D5.3 Final Aniketos Platform Integration is published, the demo material will be included in
one of the repositories managed by the Community Support module. This module will be in charge of
controlling user access to particular materials based on user groups, to be defined in D5.3. Statistics on
demo material access and downloads will also be managed by this module.
Meantime, during project execution, the non-yet-publishable demo material will be stored both in the
Aniketos eRoom and in the SVN repository [20] available for the platform implementation in the
project, the same that is used in WP5 for component development and integration. The draft demo
presentations, videos, screen-casts etc. will be stored in the WP9 folder in eRoom while the software
for the demos (developed specific services, VMs, used component versions, etc.) will be stored in the
SVN repository.
These under work material will only be accessible by WP9 members who will have access to read and
to edit it.
49
5 Results
The aim of this chapter is to describe the demo material developed with full details of implementation
although to date not all the demos have been finalized yet.
An overview of the demonstrations is given, by explaining the topic and which parts of the secure
composite service design time and run-time processes are covered. Since for Phase 2 of the project we
only addressed design time features, all demonstrations aiming at showing run-time features are
considered as possible alternatives at the moment.
Basically, the demonstrations in the current period are intended to show:

the exploitation of the Socio-Technical Security modelling tool (STS-tool) as a basis for
designing secure and trustworthy service compositions. This entails the usage of the concepts
supported by the language (actors, goals, resources, delegations, authorizations, commitments);
 the design of composite services exploiting the Service Composition Framework (SCF) made
available by the Aniketos environment. In addition, it is foreseen to carry out the design of the
business process expressing both the functional and security requirements;
 the secure service design time support provided by the Secure Composition Planner module
(SCPM) for the verification of composition plans against specific security requirements.
In the following sections we describe the main results obtained in activities related to the WP9 work
package.
Section 5.1 describes the demo material suitable for demonstrations, either already or partially
available (e.g. only planned).
Section 5.2 describes the report about participated events of different nature that include internal
dissemination events.
Finally, section 5.3 is about the support of outreach work packages with demonstration events. For the
sake of completeness, this section reports also events supported by partners not directly involved in the
activities of the WP9 work package.
5.1 Demo material
Based on the analysis carried out during the identification phase we decided to give some priority to
scenarios related to work package WP6 – Realization of industry case studies, supported by the results
of work package WP5 – Platform construction that has provided an intermediate release of the
Aniketos platform during the D9.1 timeframe. The scenario script for demonstrating the integrated
platform functionalities is based on the realization of a particular industrial case study.
Note that the list of planned demonstrations had to be revised during the lifetime of this deliverable, by
taking into account: (a) availability of the Aniketos framework and interworking capabilities among its
modules and components as detailed in Chapter 4, and (b) constraints and security requirements for
the realization of the case studies in the timeframe of deliverable D6.3 [11].
In paragraph 5.1.1 - Design of a trustworthy composite service, we describe some demo material by
using available design time components of the Aniketos integrated platform in Phase 2. The demo is
focused on the following components: the STS modelling tool (WP1), the Service Composition
Framework (WP5-SCF), the Marketplace Module (WP5) and the Service Composition Planner
Module (WP3-SCPM) while the operations of the Trustworthiness Prediction Module (WP2-TM)
have been emulated.
In paragraphs 5.1.2 and 5.1.3 we describe original plans for the demonstrations that were mainly
focused on the realization of the industrial case studies:

Case study “A”- “Future telecommunication services”- User story A1 demonstration,

Case study “C” - “Land-buying and eGovernance”- User story C1 demonstration.
50
The industrial case studies are important for stakeholders that could take advantage in adopting the
Aniketos framework. Thus, the development of a prototype of case study A is important for TLC
operators from a business point of view in terms of an increase in the average revenue per subscriber.
Moreover, the adoption of the Aniketos framework in the area of e-Government services covered in
case study C could bring some advantages in terms of cost savings and efficiency.
Due to fact that some Aniketos functionalities needed for the full realization of industrial case studies
in Phase 2 are not available yet, we decided to concentrate on more manageable scenarios by this time,
and still keep the description of demos on case studies in the present document for further reference.
So, these are still plans, with assumption that the scenario scripts will be most probably revised
according to the Aniketos’ functionalities that will be available in future releases of the platform.
5.1.1 Design of a trustworthy composite service
This demo material has been developed with the purpose to show the operation of the design time
tools of Aniketos. In the following picture, we describe the main modules involved in the
demonstration process.
Figure 6: Design time service composition modules
A short overview of modules used to build the demonstration is given.





STS-tool - to express security needs and requirements on trustworthiness;
MTM - to provide the mapping between security requirements specification (SRS) in the STSmodel and existing BPMN. The output will be a security EABPM;
IdM - to use the framework the service designer must be authenticated;
SCF - to design service compositions using Marketplace for store/retrieval of atomic services;
Marketplace - to support services discovery/announcement;


51
SCPM - to receive the composition plans from the SCF and return those ones that fulfil the
trustworthiness requirement;
TM - to check for the level of trustworthiness.
Basically the demo shows the interaction layer of Aniketos, e.g. how the service designer will interact
with the STS-tool and the SCF module in order to build a secure composite service.
The material has been used to support the following demonstration events, as also described in 5.2.3
and 5.3.2, respectively:


“Wind demo event” held in Milan (Italy) on July 13th, 2012. The material is provided in the form
of a PowerPoint presentation, a model expressed in STS-ml and a screen-cast showing use of the
SCF tool.
“Trust for communication services and networks” tutorial held at the Summer school on SOC
(July 02-07, 2012 – Crete, Greece). The material is provided in the form of a PowerPoint
presentation plus a screen-cast showing use of the SCF tool.
5.1.1.1 Goal
A service designer wants to design a composite service exploiting the tools made available through the
Aniketos platform. In particular the service designer wants to compose a trustworthy service, so he
needs to specify this security need as a security constraint to be verified by the atomic services that
will be part of the service composition.
The trust relationship that is established between the service designer and the atomic services is based
on the trustworthiness value associated to the atomic services, which is a value computed over a set of
properties and is kept updated by monitoring the services.
The service designer specifies that the minimum level of trustworthiness that makes him trust the
services is trustworthiness_threshold = TT .
To satisfy his security needs, the service designer is going to use the secure composition design time
modules provided by the Aniketos platform. Specifically the service designer uses:

the Socio Technical Security (STS) tool to define security and trustworthiness needs in the design
of the service composition. The resulting Security Requirement Specification (SRS) document
will be used to generate an annotated BPMN model;
 the Service Composition Framework (SCF) to define the business process realizing the composite
service. The resulting BPMN model expresses both the functional and security requirements. As
for the security requirements of the InfoService the BPMN includes the trustworthiness level
required;
 the Secure Composition Planner Module (SCPM) in order to check which composition plans,
among those created by the designer with the SCF, are trustworthy according to the threshold he
has set as requirement. The SCPM, in turn, invokes the Trustworthiness prediction (TM) module
in order to get the trustworthiness value of the composition plans. The atomic services needed by
the composition plans are discovered in the Marketplace module.
Functionally the service designer wants to create a service that takes in input a street address and
shows on a web page some information related to the provided location. In order to obtain such a
functionality, the service designer composes a set of atomic services, namely:




a GeoCoding type service, which takes as input a street address and gets the associated
geographical coordinates;
a PointOfInterest type service that takes as input the geographical coordinates and returns the
places that the end user can be interested to;
an WeatherForecast type service that takes as input the geographical coordinates and returns the
info about the weather observations at the station closest to the end user;
a Map type service that takes as input the geographical coordinates and returns a map showing the
position of the end user;
52

a WebPageInfoCollector type service that takes as input a set of information related to a location
and returns a web page that shows it.
The resulting composite service, named InfoService, takes as input a street address and returns the web
page collecting all the information described above, as depicted in the following figure.
Figure 7: Overview of InfoService components
5.1.1.2 Process view
The demo is composed by two parts: the first is about the description of the tool to express the
trustworthiness as constraint over the atomic services involved in the composition; the second is
related to the business process in order to realize the composite service by using the Aniketos
components available at design time.
Modelling a secure composite service with STS-tool
The first part of the demo initiates with the use of the STS-tool to model the InfoService security
requirements. The aim is to give an overview of the usage of the tool that basically consists in the
following steps:




to identify the principal stakeholders (actors);
to identify and analyse the goals of each actor;
to define the interactions among the actors;
to express the requirements on security and trustworthiness.
For practical purposes, the demo is based on a pre-built model, thus making it possible to show the
relevant parts of the STS diagram during the presentation.
The designer inputs the business view by using the STS-tool, which in turn generates a specification
document expressing the security requirements in the model. The business view is made of three
components: social, information and authorization views.
The social view represents stakeholders as intentional and social entities, representing their goals and
important information in terms of document, together with their interactions with other actors to
achieve these goals and to exchange information.
53
In this model, there are two principal actors: the customer, i.e. the end user of the composite service
and the InfoProvider which is in charge of producing the information required, thus emulating the
operation of the composite service.
Figure 8: InfoService social view
The Info Provider makes extensive use of delegations in achieving the goal to provide the customer
with information about his position. The following table summarize the actors in the model with the
respective goals and delegations (indicated by green boxes).
Table 19: InfoService model actors and goals
The information view depicts the information and the documents representing this information owned
by the different actors in the model and their relationships. It shows the informational content of the
documents represented in the social view (indicated by grey boxes). Information is represented by one
or more documents (made tangible by), and the same document can make tangible multiple
54
information. Moreover, the information view considers composite documents (information) capturing
these by means of part of relations.
Figure 9: InfoService information view
The information view represents also who are the owners of the information that is being manipulated
through the documents that represent them in the social view. The following table represents the
owners of the different information in the STS diagram.
Table 20: InfoService information owners
The authorization view shows the permission flow from a stakeholder to another, that is, the
authorizations stakeholders grant to others about information, specifying the operations the others can
perform over the information. Apart from granting authority on performing operations, a higher
55
authority can be granted, that of further authorizing other actors. Authorizations start from the
information owner. Therefore, in the authorization view, ownership is preserved and inherited from
the information view.
Figure 10: InfoService authorization view
In the following figure, we show how the model allows the designer to express requirements on the
trustworthiness level. In this case, the ‘Pre condition’ field in the delegation property tab has been used
for setting the threshold on trustworthiness.
56
Figure 11: Setting of security requirements
The goal of this part of demonstration is to illustrate the use of the STS modelling tool. The output of
the process is the SRS document expressing a list of requirements written in natural language that will
be used to annotate the business process (BPMN) model generated by the SCF with security
requirements.
The mapping of security requirements between the STS-tool and the SCF is in charge of the MTM
module which, at the time of writing, is still under development. For this reason, the second part of the
demo, which is focussed on the use of the SCF and the creation of a deployable composite service,
assumes that the designer has in input a BPMN model with security annotations (EABPMN).
Design and deployment of a secure composite service using SCF
The trustworthiness value is evaluated by the Trustworthiness Prediction module taking into account a
combination of different trust factors, like (a) cognitive trust of the user, based on the service and
service provider reputation and (b) non-cognitive trust, based on objective and measurable properties
of the service, such as QoS attributes (reliability, performance, availability).
The module used to design the InfoService composite service is the Service Composition Framework
(SCF) which is accessed by the service designer upon authentication, as shown in Figure 12.
57
Figure 12: Authentication required for the Service Composition Framework
Once the designer has logged in, he can start using the tool to create the BPMN model of the
composite service, namely InfoService.
Figure 13: Workbench of the Service Composition Framework
The composite service is made up of the above mentioned services (Geocoding, PointOfInterest,
WeatherForecast, Map and WebPageInfoCollector) which are represented in the BPMN diagram by
service tasks.
58
The way the atomic services are composed is shown in the following BPMN model. It’s worth to be
noted that the first gateway activates two branches that are executed in parallel, while the second
gateway has to wait for the execution of the two atomic services connected to it in order to trigger the
execution of the last atomic service.
Figure 14: BPMN model of Infoservice
The service designer is in charge of designing a composite service with a specific requirement on
trustworthiness value. In particular, the trustworthiness requirement is expressed as a consumer policy
written in ConSpec grammar. The file location is included in an extensionElements tag in the xml
representing the BPMN.
An excerpt of the resulting xml for the annotated BPMN is shown below.
Figure 15: Excerpt of the XML representing the InfoService BPMN annotated model
The extensionElements tag which is about the consumer policy (highlighted in Figure 15) refers to the
following xml expressing the trustworthiness requirement:
59
To make the composition plans the SCF has to bind real web services to the service tasks in the
BPMN. The binding process entails, for each service task, two operations:


service discovery using the ServiceType as search filter;
selection of the specific operation the service designer wants to use in order to compose the
InfoService.
Thus the service designer specifies the service type in the Type field and clicks the “Start discovery
button”. Once discovered the services whose type matches the request, he SCF shows the operations
offered by the services. If the same operation is offered by different atomic services the service
designer will see just one operation.
As an example, let’s see how the service designer discovers GeoCoding type services, which is the
type of service he wants to bind to the GeoCoding service task. First of all he fills out the field Type
typing GeoCoding and clicks on “Start discovery”, then the SCF returns a set of operations among
which the service designer selects getCoordinates() (as shown in Figure 16).
60
Figure 16: Selection of the operation for the binding process
The service designer has selected getCoordinates(), but he doesn’t know how many web services
offers that operation; it is the SCF that will bind the different services to the service task when making
the composition plans.
Once the service designer has selected an operation for each service task the SCF is ready to create the
composition plans.
Figure 17: Creation of composition plans
When the service designer clicks on “Create composition plans” button, the SCF shows a set of
functionally valid composition plans. As we can see in Figure 17 the SCF has created 12 composition
plans realizing the InfoService composite service. The number of composition plans is explained
taking into account that different services can offer the same operation, and thus different services can
be bound to a service task. In this case we have:





61
Geocoding type: bound to 2 web services
PointOfInterest type: bound to 3 web services
WeatherForecast type: bound to 1 web services
Map type: bound to 2 web services
WebPageInfoCollector type: bound to 1 web services.
Thus, the number of composition plans is 2 x 3 x 1 x 2 x 1 = 12.
Figure 18: The composition plans created for InfoService
The composition plans just created bind actual services with the service tasks, but they have been
created without taking into account the trustworthiness requirement. The composition plans have to be
checked against the requirement specified for the trustworthiness value. This check is performed by
the Secure Composition Planner Module (SCPM) which receives the composition plans from the SCF
and returns those ones that fulfil the trustworthiness requirement.
The SCPM invokes the Trustworthiness prediction module to evaluate the trustworthiness value for
the set of composition plans received from the SCF. In order to evaluate the trustworthiness value of a
composite service the weakest link principle is applied, this means that the Trustworthiness module
evaluates the trustworthiness value for each service taking part in the composition and then takes the
lowest value as the trustworthiness value of the composition plan.
This process, initiated by pressing the “Verify All” button, returns the sets of trustworthy composition
plans, that can also be sorted in terms of decreasing trustworthiness (by using the “Order/Rank”
button).
62
Figure 19: Composition plans returned by the SCPM
Finally, the service designer selects one of the trustworthy composition plans and, by using dedicated
buttons, it is possible to upload the BPMN to an Activiti Engine and to deploy it to a web application
server (see Figure 20).
63
Figure 20: Further operations once selected a composition plan
Script:








The service designer accesses the SCF providing authentication data.
The service designer models the BPMN of the InfoService composite service.
The BPMN is annotated with the trustworthiness requirement by adding extensionElements tag to
the XML representing the BPMN.
For each service task in the BPMN the service designer proceeds to discover services in the
MarkepPlace for getting real web services that match the request.
The designer selects an operation for each service task.
The service designer starts the creation of valid composition plans.
The set of valid composition plans are checked against the requirement(s) about trustworthiness.
Secure composition plans are sorted in terms of trustworthiness and can be deployed in the
Activiti engine and deployed as a web service into an application server.
5.1.2 Case study “A” User Story A1
Case Study A focuses on the possible evolutions of the TLC operators in considering an open-platform
business model in order to provide services which are exposed and consumed by using Web 2.0
service technologies.
In the particular case of the User Story A1, the TLC operator is planning to develop a web portal so to
offer a set of applications to its customers. The application developer, who is responsible for
developing the portal using Aniketos platform, will use the Aniketos Marketplace to discover service
components which besides offering the functions he needs to build the application logic comply with
its specific security needs.
64
The usage of the Aniketos platform enables the developer to discover such functional valid service
components based on security and trustworthiness properties. The discovery features provide it with a
list of service components among which it has to choose the components that best fit the security
requirements specified by the TLC operator. In this case it chooses the components having a level of
trustworthiness above a predefined threshold (previously fixed by TLC Operator).
The security requirements are expressly fixed by the TLC operator and the developer must comply
with that.
User story A1 is described from the point of view of an end user (Bob) that utilizes the applications
and services accessible through the TLC operator’s web portal. Basically the web portal collects and
composes services offered by third party Services Providers joined with the TLC Operator.
In particular Bob accesses services offered through a TLC operator’s web portal and provided by
different service providers joined with the TLC operator in an identity federated environment.
In the next subsections we will give an overview of the main elements that define the demo domain
and that will be involved in the realization of the demo.
5.1.2.1 Goal
This demo focuses on the possible evolutions of the Telco services’ role in the Future Internet
landscape.
The goal of this demo is to show how Aniketos platform can really support future telecom business
environment by providing establishing and maintaining trustworthiness and secure behaviour in a
constantly changing service environment.
The TLC operator uses Aniketos to design and offer secure and trustworthy composite services using
the features and technologies of the platform.
The goal of this demo is also to show how the revenue generated by one customer per unit time, (per
year or month) will be supported by Aniketos in promoting and enabling the provision of new services
to Customers.
Anyway target is common to all companies that offer subscription services to customers.
An increase of business for those companies will include not only the revenues billed to the customer
for services usage increase, but also the revenue generated from services mutually offered by Service
Providers in a federated environment, in a defined regulatory federated regime.
The following work process diagram indicates which parts we plan to show (red circles in Case study
A use story A1 demonstration) and which parts we plan to ignore (not yet ready to demonstrate or not
interesting for the target viewers: orange crosses). This is the same method adopted in 1st review
demonstration script.
In Case study A user story A1 demonstration, the TLC operator decides to exploit Aniketos design
time support for secure and trustworthy service composition and run-time support to respond to
changes/security incidents of various types.
In particular the Telco operator wants to exploit Aniketos platform to discover service components
that conform to its security requirements in order to build composite services or web applications
featuring the desired level of security and trustworthiness.
At design time, the application developer will use the Aniketos Marketplace to discover and select
only those service components which besides offering the functionalities that are needed to build the
application logic, have a trustworthiness level above a predefined threshold (as requested by the TLC
operator).
As it can be seen, at design time, the use story A1 demonstration includes the STS modelling tool and
the Service Composition Framework use, the Aniketos platform service invoking and a Service
65
specification supply but not showing the final service specification outcome that is done in the
environment.
We can show a service specification made in the SRE, but it still has no security because the MTM has
not taken part in the process. We could also show a service security specification model example.
This means that in this stage of the project, we skip the model transformation but we show how
Aniketos supports the service discovery and assembly based on security properties of the components.
Refer to following figure to see the Aniketos managed processes.
The main purposes for design time demo are the following:





modelling the composite service (Business Process Modelling Notation model),
modelling and analyse security requirements,
service discovery based on security requirements,
service security verification at design time,
assembling and deploying of composite services.
Figure 21: The design time of the Case study A use story A1 demonstration
We describe next the design-time creation of commitments and complete design time tool chain,
discovery, assembly and deployment.
The Service Composition Framework and the STS modelling tool are open by a Service developer that
will open up a model then add requirements that will lead to commitments.
Two actors might be identified: a developer for business process modelling, and a business expert or
commercial or other player such as system architect for STS-modelling. They could act in parallel, but
the preference is to do STS model first, and then accomplish the business process modelling with the
aid of Aniketos MTM (once it will be available). If they act in parallel the business process model will
be verified against the STS model with the help of Aniketos SRCM.
Script:


The service developer has designed by the Service Composition Framework the business process
of the composite service
The service composition is viewed as a business process and is modelled by using the concepts
made available by the STS-ml
66


The Service Composition Framework invokes the Marketplace to discover services
The business process that is a part of the demo service specification is opened
The design of these processes poses for specific security requirements so:

The service developer has created a model by the modelling tool but this will not be the input to
the agreements/contract needed for a composite service at the moment.
The definition of security properties as commitments and transformation to agreement
templates/contracts is not conceivable as part of this demo, the MTM will be able to do this for M33.






This modelling tool that has different views and high-level security requirements
The model that is a part of the demo service specification is opened
The roles and assets that are realized by the composite service are showed
The service developer desires for one of the atomic service a precise trust value
The service developer retrieve from Aniketos trustworthiness value of service
The Service Composition Framework invokes the Marketplace (as a proxy) to discover services
with the desired trust
 The Marketplace returns a list of Service Security Descriptor containing the service’s information
including trust credential
At run-time (optional2), the user gets access to the Telco portal after a preliminary registration.
Basically, two applications are available, WebShop (e-Commerce) and WebTravel (hotel and ticket
reservation services).
In this story, the aim is to demonstrate how Aniketos manages issues like user’s data exchange
between Service Providers (including Identity Providers) and service re-composition due to User
choice.
For the run-time phase before re-composition we have Bob, a new user that subscribes to the portal
offered by the TLC Operator. So as usual we have an end user using a composite service and a service
provider providing this service.
Bob browses the portal and accesses WebShop application to purchase an item. Since he wants to get
more information about a specific product, he uses other composite services in the Environment.
Once Bob gets the information he needed, he decides to purchase the item he was interested to.
Bob is informed that the StoreLocator service, in its basic configuration, will let him to select
manually the preferred store from a list and will show the position of the store on a map.
Otherwise he can give his authorization to use his position information: in this case the StoreLocator
service will use this information in order to help him to find the closest store.
Thus the StoreLocator service composition is driven by Bob decision to give or not his consent to use
his position.
The most important thing from this scenario is that the StoreLocator service composition is driven by
Bob decision at run-time to give or not his consent to use his position, in particular if Bob decides to
let the service use his position information, this will trigger a re-composition of the composite service.
2
In phase 2, we focused only on design time features.
67
Figure 22: Run-time processes for the service end user and service provider of the Case study A
use story A1 demonstration
During re-composition, the StoreLocator service comes up as:


a service that, when invoked, returns location information of the user;
a service that receives location information as input and gives as result the list of the closest
stores;
 a service that receives the list of address of the closest stores and show them on a map.
The Aniketos platform does an evaluation (hardcoded, for the moment) and returns the results. The
Environment can then make a more informed decision on which service component to choose, selects
and assembles a new running service.
As a part of this process, the Environment can send the new service composition plan to Aniketos
platform in order to check the security properties of the composite service. This means we get to show
both trustworthiness evaluation and security level verification.
68
Figure 23: Run-time processes for the re-composition agent and
service provider of the Case study A use story A1 demonstration
69
Figure 24: Run-time verification of the new composition of the Case study A use story A1
demonstration
As already mentioned in introduction, we decided not to develop this demo but to concentrate on more
manageable scenarios due to fact that some Aniketos functionalities needed for the full realization of
industrial case study A will not be available in Phase 2.
5.1.3
Case study “C” User Story C1
The case study C represents a typical public service, involving multiple stakeholders, ranging from
ordinary citizens to various organizations from different domains. These kinds of services are
becoming more and more available online, and need to address key challenges as they are identified in
Aniketos.
DAEM S.A., the City of Athens IT company, is an organization dedicated in developing and providing
e-government implementation services to local government authorities and other public organizations.
The domain specific case study C represents the implementation of the supporting service framework
related to the scenario of when, where and what to acquire when searching for a piece of land (lot) so
as to build a residence for individual or professional use.
In particular, the use story C1 represents the situation, in which an interested stakeholder wishes to
find an available lot in a specific geographical area within the limits of the Municipality of Athens.
The story assumes that an application developer has implemented the DoUP (Department of Urban
Planning) application for the interested stakeholders to access all the necessary information when
searching for a lot.
In use story C1, the DoUP application deals with public data, which can be accessed by anyone (it is
not confidential), thus the services exposing such data should bear trust properties only with respect to
the data accuracy and their origin (integrity). In fact, it is important that the data are accurate and come
from the correct source, they are not data introduced by any attacker. However, if a security violation
70
occurs in one of the services and the relevant trustworthiness level is not contained, then the impact of
inaccurate data on the process may be critical.
5.1.3.1 Goal
The goal of this demo is to show how Aniketos platform can really support Governments at national,
regional and local levels, together with their agencies and other organizations which deliver public
services in implementing e-Government solutions to get easy access and high quality public services.
Such a scenario involves many factors affecting decisions at various stages. In addition, many security
threats and vulnerabilities are in place as a result of the nature of the e-government related scenario.
Therefore, the objective identified and addressed is to enable both citizens or various service end users
and different organizations interaction into a complex public service provisioning scenario.
A service and application developer from the IT department of the Municipality of Athens wants to
build a Web 2.0 application, which integrates the existing back-office system with the available
commercial services facilitating the interaction of the stakeholders involved in the process of
searching for a lot.
In particular the Municipality of Athens wants to exploit Aniketos platform to discover service
components that conform to its security requirements in order to build composite services or web
applications featuring the desired level of security and trustworthiness.
At design time, using the Aniketos Marketplace the application developer is able to discover and select
service components featuring both needed functionalities and proper trustworthiness level above a
predefined threshold as requested by the IT department of the Municipality of Athens.
At design time, the use story C1 demonstration includes:
 the STS modelling tool use,
 the Service Composition Framework use,
 the Aniketos components service invocation
 service specification supplying
 showing of the final service specification outcome that is created in the Environment.
For the design time of the Case study C user story C1 demonstration refer to the same figure as it was
shown for the work process diagrams of the case study A user story A1 demonstration (see paragraph
5.1.2.2).
The developer uses the Service Composition Framework to define the business process of the
composite service, including the process of advertising the available lots, which are aggregated from
various sources, the process of querying for relevant information about the selected lot, including the
map of the lot surrounding area, the lot building terms and other law information, the process of
identifying a creditable civil engineer.
The design of these processes poses for specific security requirements with respect to the
separation/combination of duties, the trustworthiness of the provided composite services and the level
of data confidentiality.
The developer should make use of the STS modelling tool, so as to design and to show the security
needs.
Script:



The service developer has designed by means of the Service Composition Framework the
business process of the composite service
The service composition is viewed as a business process and is modeled by using the concepts
made available by the STS-ml
The Service Composition Framework invokes the Marketplace to discover services

71
The business process that is a part of the demo service specification is opened
The design of the processes poses for specific security requirements so:








The service developer has created a model by the modelling tool needed for a composite service
This modelling tool has different views and high-level security requirements
The model that is a part of the demo service specification is opened
The roles and assets that are realized by the composite service are showed
The service developer desires for one of the atomic service a precise trust value.
The service developer retrieves from Aniketos trustworthiness value of service
The Service Composition Framework invokes the Marketplace (as a proxy) to discover services
with the desired trust
The Marketplace returns a list of Service Security Descriptor containing the service’s information
including trust credential
In that respect, the developer should make use of the Aniketos platform, so as to design the following
security needs:

Each Real Estate Provider is responsible for offering a service with a defined set of data exposed
for each lot (the lot surface capacity, the location, the area, the price)
 A Real Estate Provider should define which lot data is public and which of them are available
upon authentication of the interested user
 A Real Estate Aggregator Provider is responsible for defining the services of the individual Real
Estate Providers to display on their services, based on the trustworthiness level
 The aggregation service should be trustworthy, so all available lots are being exploited in the
query for a lot
 The DoUP application should integrate trusted services from different Real Estate Providers
 The DoUP application should integrate the existing law information with the location of the lot
and display the information about the building terms into a trusted service
 The Law Framework service is the only responsible for providing creditable data about the
specific law information
 The DoUP application should expose a trustworthy service with the lot information along with
any background information, which is collected from trusted sources
 When a creditable civil engineer has to be selected, the DoUP service should combine the details
of the engineer (contact details) with a list of recommendations about the selected engineer from
different trusted forums
 When a registered to the DoUP application user searches for a lot, the search history and the
user profile should not be communicated other than the DoUP (thus a Real Estate Provider
should not be able to track user actions).
A given set of services are able to play the roles in this model, and the Aniketos Marketplace is used to
find the security descriptors of these services. Selection is based on required trustworthiness level
(retrieved from the Trustworthiness Component), confidentiality properties (checking using the
Contract Manager Module. The composition plans are finally checked with the Security Verification
Module.
As already mentioned in introduction, we decided not to develop this demo but to concentrate on more
manageable scenarios due to fact that some Aniketos functionalities needed for the full realization of
industrial case study C in Phase 2 are not available yet. We decided to keep this demo as planned
while still monitoring the outcomes of the relevant work packages, that is WP6 (Realisation of
industry case studies) for the realization of the scenario and WP5 (Platform construction) which uses
part of case study C user stories as a reference for the integration of Aniketos modules.
72
5.2 Report on events
This section is about the events held in Phase 2 based on the materials presented in 5.1.
5.2.1 Aniketos plenary meeting in Paris
Aniketos plenary meeting held in Paris February, 2012 could be considered as the first internal demo
event aimed to show Aniketos system modules, the status of integration and related next steps.
During that event the following demonstrations have been shown to the participants, based on material
developed by partners responsible of each module:
 demo video of the marketplace module (ATC)
 demo video of the first integrated version of WP2 prototype (CNR)
 demo video of the notification module (SINTEF)
 demo video of secure composition planner module (LJMU)
 demo video of the STS tool (UNITN)
 demo video of threat repository module (THALES)
 demo video validation of service compositions (SAP)
 demo video of the service composition framework (Selex Elsag).
The interworking modules highlighted as mature are:
 Service Composition Framework – Secure Composition Planner
 Service Composition Framework – Verification Module
 Service Composition Framework – Marketplace.
As integration work in progress status:
 Marketplace – Trustworthiness
 Notification Module – Aniketos and Environment Components
and as next steps:



creating a composition plan with Secure Composition Framework
register for Alerts and receive notifications from Notification Module
communication of Monitoring Module with Aniketos and Environment components.
73
5.2.2 Selex Elsag internal demonstration
Table 21: Selex Elsag internal demonstration
Aniketos project demonstration at Selex Elsag
Description of the event
On Thursday the 10th of May, 2012 Selex Elsag had an internal event about presentation of R&D projects in
Selex Elsag Rome site (Italy).
The agenda of the meeting has been the following:

Introduction on Aniketos project

Presentation of the project status

Possible applications of the first results

Demo 1: short overview of an Aniketos module (the STS-Tool)

Demo 2: short overview of an environment module (the SCF module)
Target audience

the responsible of Innovation and Research department

a member of Innovation and Research department

responsible of Telco Service delivery
 a member of Telco Service Delivery - Cloud Computing senior specialist
Purpose of the demo
Selex Elsag have addressed exchange experience with projects and groups working in the domain of services
delivery in order to disseminate the techniques developed during the project and prepare the way for a successful
commercial and non-commercial exploitation of the project outcomes.
Impact:
Effort:
Medium
Type:
Medium
Demonstration of
the DT part of
Aniketos
platform
Date:
Thursday 10th of
May, 2012
Presenters:
Michela D’Errico, Francesco Malmignati, Paolo Pucci, Pierluigi Sciuto
Prerequisites:
SCF, STS modules and Aniketos high-level presentation completed
Objective:
Create awareness of the project, checking about modules use possibilities in production
environment.
Feedback
method:
Discussion after the event - the event has been considered interesting for the industry audience
both from a technical and a business point of view, in order to better achieve security and trust
in deployment and delivery of services.
74
5.2.3 Local industry demonstration in Wind
Table 22: Demo event (Wind)
Aniketos project demonstration at Wind
Description of the event
On July 13th, 2012 a demo event has been held in Wind premises in Milano (Italy) by representatives of two
partners working in WP9, Italtel and Selex Elsag. The presentation was organized according to the following
agenda:






Aniketos project overview
Secure web service composition tools
Security requirement modelling (STS) tool
Service composition framework (SCF)
Demo: application of the design time process to a real example
Open discussion.
Target audience
Wind personnel from the Technology Architecture and Innovation Laboratory






the responsible of Wind Innovation Lab (WIL)
a member of Engagement & Program Management
a member of Early Tech Solution scouting
a member of Innovative Services & Processes scouting
a member of Financed Projects
WIL Aniketos Project Manager
Purpose of the demo
The aim was to give an overview of Aniketos project and to present the relevant case studies to a telecom
operator. Apart from this general introduction, we showed the design time process with focus on the tools for
building secure service compositions.
Impact:
Effort:
Medium
Type:
Medium
Demonstration of
the DT part of
Aniketos
platform
Date:
July 13th, 2012
Presenters:
F.G. Andreotti (Italtel), P. Sciuto (Selex Elsag)
Prerequisites:
STS, SCF, SCPM, TM, Marketplace and Aniketos high-level presentation completed
Objective:
General dissemination of Aniketos concepts. Demonstration of DT process in web services
composition.
Feedback has been collected in written form by means of a questionnaire. Report is
summarized in a dedicated section.
Feedback
method:
A questionnaire for collecting feedback has been distributed to the participants. The main results are
summarized in the following table.
75
Table 23: Demo event questionnaire and results (Wind)
General questions
Company / department
Specific area of work / job
Wind Telecomunicazioni S.p.A.
TLC
How did you know about Aniketos?
We are involved as partners
How do you rate the demonstration according to your expectations and interests?
Applicability of concepts
High/medium/low: MEDIUM
Contents
High/medium/low: LOW
Innovation
High/medium/low MEDIUM
Are you interested in hosting demo events to other
departments inside your company?
Are you interested in organizing specific demo events
to your customers/partners?
Yes/no: NO
Please, help us to improve the demonstration by taking
into account your suggestions.
When all the software components will be available
will be useful to show the complete chain from the
concept definition to production site for testing.
Yes/no: NO
Domain specific questions
Do you think that sharing of services by Aniketos
contracts between telecom operators is in line with
telecom operator goals (e.g. increased revenue per user
and/or revenue among telecom operators)?
The Aniketos approach should be in line with the
Telecom operator goals but some aspects not yet well
defined to reach this goal. For example it is not so
clear the marketplace management and the final
services implementation.
How do you think is possible for NGN operators’ to
provide services to third parties by using Aniketos
framework? What about a well-defined revenue
sharing agreement between them?
The Aniketos framework should be useful but there are
some weak points to solve before evaluate how to
introduce it in a real context.
Do you think that composite service billing mechanism
should be considered at design time?
We suggest to include at design time this service.
How do you envisage the introduction of Aniketos in
the market? In your opinion, which kind of mechanism
is suitable (e.g. pay-per-use or periodic fee) for
Aniketos services offered by a Service Provider to its
customers
as
possible
forms
of
future
commercialization?
For the introduction of Aniketos in the market we
suggest to make available the service using a pay-peruse model, but the current platform is not ready for
this goal.
What do you think about Aniketos case studies, with
particular regard to user stories A1 and A2 presented
during the demo event? Do you think that case studies
will improve Service Providers’ portfolio of services
and consequently contribute to increased revenues and
subscribers’ retention?
The user stories are close to real context; anyway at
the moment the Aniketos platform is not strong
enough to contribute to increase revenues and
subscribers’ retention.
A malicious service component (or Service Provider)
could have a negative effect on the overall service
composition. Do you think that Aniketos could
effectively manage this issue?
This aspect is very important: the Aniketos platform
introduction in the real market context needs to
address it.
Do you think Aniketos could be able to constantly
maintain security and trustworthiness in a serviceoriented environment in the cycle of design,
provisioning, delivering and deploy of services?
From the theoretical point of view the Aniketos
platform is able to guarantee this approach: we have to
verify in the real uses cases how the will implement
this element.
76
Give your opinion on the level of usability of the
platform (e.g. efforts spent in definition of
requirements and adaptation of existing procedures).
Please, refer also to the design time tools showed
during the demonstration.
The level of usability in the real context for people not
involved in the project is low. It is necessary to test the
complete environment with all the software modules.
As a Service Provider do you perceive difficulties in
service specification and announcement by using the
Aniketos Marketplace?
According to our experience the Aniketos
Marketplaces is not yet structured according the real
context because the model for the Marketplace
implementation is not so clear.
Do you think Aniketos philosophy could be potentially
introduced in your environment, even if gradually?
We think that many Aniketos concepts are aligned to
the company requirements; the adopted solutions seem
to be not yet complete as far as requested from the real
context.
What kind of operation and maintenance additional
efforts do you foresee in managing the Aniketos
platform?
According to the Aniketos platform approach, we are
expecting that the global efforts will decrease.
End of questionnaire
The questionnaire is anonymous - if you are interested
in the results of this survey, please indicate your e-mail
address.
5.3 Outreach support
This section describes the reports on participated (or already planned) events dedicated to the support
of outreach work packages in Aniketos, that is:
 WP8 – Tutorials and training,
 WP10 – Community building and standardization,
 WP11 – Dissemination and exploitation.
Moreover, we have included in this section the demo events organized and supported by Aniketos
partners that are not directly involved in the activities of work package WP9.
5.3.1 Training support (WP8)
The tutorials and training activities of WP8 are going to create a collection of learning materials
explaining the operation and usage of Aniketos components. Showing the exploitation of the secure
composition design time modules WP9 refers to STS-ml & tool capabilities to express the
trustworthiness as constraint over the atomic services involved in the composition.
This paragraph summarizes the activities carried out by the partner University of Trento (UNITN) in
the framework of WP8, for the development of demos and presentation at internal events:

A "day-in-the-life of a modeller” a workshop involving the students of two courses held at the
University of Trento on May 11th and 14th , 2012.
 part 1: training students are taught STS-ml and demonstrated STS-tool;
 part 2: students use the tool in practice.
A useful link for STS-tool and modelling language, user manuals, tutorials and demo material can be
found in [19].
5.3.2 Community support (WP10)
The Community building and standardisation of WP10 is concerned to reinforce liaisons with other
projects and technology platforms and participating in workshops and summer schools for promoting
to the communities the release of Aniketos framework.
77
From the list of potential events for demonstrations in Phase 2, as described in section 2.2, we decided
to address the Summer SOC event in order to show to academic community the activities carried out
in Aniketos.
The Advanced School on Service-Oriented Computing (SOC) brings together the best international
experts on software and services with students, young researchers and professionals from leading
academic, research and industrial organizations across Europe and around the world. Topics span the
entire field of SOC from conceptual foundations to industrial applications.
To date we have presented a demo at the 6th Advanced School on Service Oriented Computing (2-7
July 2012). The demo was about the theme of Emerging Topics: “Trust for Communication Services
and Networks: Introduction and Applications and the title is Aniketos Platform: Design of a
Trustworthy Composite Service presented by Dr. Dimitri Botvich TSSG/WIT, Ireland.
The Service Composition Framework (SCF) demo slides [ppt2] and animation [demo] are available at
the SOC Summer School website [21] and is fully described in paragraph 5.1.1 - Design of a
trustworthy composite service. The audience included about 60 people. These presentations are also
available on slide share [22]. It is expected that the demos will also be available on our YouTube
channel [23] in the future. Currently, the Aniketos website links to the STS modelling language and
tool website which provides downloads, documentation and tutorials [19].
79
6 Conclusion/Further work
The present document is a report about demonstration material and events for the Phase 2 of the
Aniketos project with the aim to support outreach. Due to the dependency from the outcomes of the
technical work packages, an important activity is to continuously monitor the status of developments
in order to give visibility and to demonstrate the up-to-date results of the works of Aniketos. The
timeframe of WP9 with respect to the recent results from platform integration (D5.2), its application in
industrial use cases (D6.3) and the validation of results (D7.2) implies that the maturity and volume of
the demonstration material is low at this stage. This should not be a major concern in the next
deliverable D9.2 - Demonstration material and events for the complete project - which is due at the
end of the project (M42). Accordingly, there will be in the next phases more technical material
available (and more time) for producing demonstrations than for deliverable D9.1. For the same
reason, the planning of demonstration activities will be less critical, especially in the submission
process for participating to industry and academia events.
Finally, in the upcoming period of the project, we will continue to put efforts in order to enforce
collaborations inside outreach work packages of Aniketos.
80
References
[1]
Aniketos EU FP7 project, http://aniketos.eu/home, last accessed 2012-07-03.
[2]
Aniketos Consortium, Deliverable D1.2 - First Aniketos architecture and requirements
specification.
[3]
Aniketos Consortium, Deliverable D1.3 - Initial version of the socio-technical security
modelling language and tool.
[4]
Aniketos Consortium, Deliverable D2.2 - Initial prototype of trust management, security-bycontract and verification modules.
[5]
Aniketos Consortium, Deliverable D3.2 - Initial prototype of secure service composition.
[6]
Aniketos Consortium, Deliverable D4.2 - Initial prototype of the mechanisms for the
response to changes and threats.
[7]
Aniketos Consortium, Deliverable D5.1 - Aniketos platform design and platform basis.
[8]
Aniketos Consortium, Deliverable D5.2 - Initial Aniketos platform integration.
[9]
Aniketos Consortium, Deliverable D6.1 - Initial analysis of the industrial case studies.
[10] Aniketos Consortium, Deliverable D6.2 - Case study work plan.
[11] Aniketos Consortium, Deliverable D6.3 - First report on Aniketos applied to industrial case
studies.
[12] Aniketos Consortium, Deliverable D7.1 - Validation and evaluation plan.
[13] Aniketos Consortium, Deliverable D7.2 - Results of the first validation and evaluation of the
Aniketos platform.
[14] Aniketos Consortium, Deliverable D10.1 - Initial plan on Aniketos community building and
standardization.
[15] Aniketos Consortium, Deliverable D10.2 - Initial report on network participation,
community building and standardisation efforts.
[16] Aniketos Consortium, Deliverable D11.1 - Aniketos brochure and public website.
[17] Aniketos Consortium, Deliverable D11.2 - Initial dissemination and exploitation plan.
[18] Aniketos Consortium, Deliverable D11.3 - Second dissemination and exploitation plan.
[19] University of Trento –
http://fmsweng.disi.unitn.it/sts/
STS
modelling
language
and
[20] SVN repository - https://hestia.atc.gr/svn-aniketos
[21] SOC Summer School website - http://www.summersoc.eu/
[22] Aniketos’ slide share - http://www.slideshare.net/Aniketos/
[23] Aniketos’ YouTube channel - http://www.youtube.com/user/aniketoseu
tool
website
-
81
Appendix A
A.1 Demo report template
Aniketos project demonstration at EVENT X
[Description of the EVENT X]
 Very high-level description. Indicate scope of demo and material.
[Target audience at the event and how Aniketos fits with their interests]

Specific target or possible candidates
 Explain the reason why we are addressing those targets
[Purpose of the demo]

For such events, a fairly high-level presentation of the Aniketos project is appropriate, as participants
will come from a variety of industries and backgrounds. The purpose would be to create awareness of
the Aniketos concept and project, not to directly promote participation in or use of Aniketos

Business case description (if applicable)
Impact:
Low/
Medium/
High
Effort:
Low/
Medium/
High
Type:
Demonstration of
the DEMO X part
of Aniketos
platform
Date:
[EVENT X dates]
Presenters:
[Name of people]
Prerequisites:
[Aniketos MODULE X and presentation PRES X completed]
Objective:
[Create awareness of the project, sell MODULE X, get security experts involved in our
Marketplace, …]
Feedback
method:
[Written form for feedback]
A.2 Feedback form example
This section contains an example template usable to collect feedback after demonstration events. The
form has been created with free tool available from http://kwiksurveys.com, a website that allows the
design of online surveys, forms, polls and feedback forms with no limits in time, number of questions
and participants. The tool is able to store, elaborate and display results for reporting and analysis.
The forms could also be exported in various formats that allow us to collect feedback by using written
questionnaires as well.
82
83
A.3 Comparisons of screen-casting software
The next table contains a comparison by specification of screen-casting software (available from
Wikipedia, as of July 04, 2012).
Product Name
Latest
stable
version
Latest
release date
Software license
Open
source
No
ActivePresenter
3.05
07/06/2012
Proprietary
commercial
ActivePresenter Free Edition
3.05
07/06/2012
Freeware
No
5.05
27/05/2011
Proprietary
commercial
No
Adobe Captivate
No
16/03/2011
Proprietary
commercial
No
Bandicam
1.6.1.113
BB FlashBack
2.08
17/02/2011
Proprietary
commercial
BB FlashBack Express
2.08
17/02/2011
Freeware
No
No
5.02.01
18/04/2011
Proprietary
commercial
2.6 Beta
27/10/2010
GPL Version 2
Yes
No
2.00
06/12/2011
Proprietary
commercial
7.01.01
13/01/2011
Proprietary
commercial
No
Camtasia Studio
Capture Fox
0.07.00
25/11/2009
MPL Version 1.1
Yes
No
0,192662
23/06/2012
Proprietary
commercial
23/06/2010
Proprietary
commercial
No
0,0427431
0.09
11/12/2011
LGPL
Yes
No
26/04/2012
Proprietary
commercial
GPL v3
Yes
No
BSR Screen Recorder
CamStudio
Camtasia for Mac
D3DGear
Dxtory
FFmpeg
Fraps
Freeseer
Grabilla
HyperCam
HyperCam
3.05.00
2.05.03
24/05/2011
1.14
20/03/2012
Proprietary
commercial
2.25.01
29/05/2011
Freeware
No
No
16/11/2011
Proprietary
commercial
3.3.1111.16
84
Latest
stable
version
Software license
Open
source
Proprietary
commercial
No
07/12/2011
No
11/01/2012
Proprietary
commercial
Freeware
No
Proprietary
commercial
No
17/04/2012
GPL v3
Yes
No
08/06/2010
Proprietary
commercial
No
10.6.10800
19/04/2011
Proprietary
commercial
1.3.11913
15/01/2010
Proprietary
commercial
No
Pixetell
QuickTime X
10.0 (118)
29/03/2010
Part of Mac OS X
No
0.3.8.1
13/12/2008
GPL
Yes
No
Product Name
iShowU
iShowU HD Pro
Latest
release date
0,1049074
2.02.08
Jing
Jing Pro
Kazam
Microsoft Expression Encoder
Nero Vision
RecordMyDesktop
Screen Capture
Screencam
1.03.00
4
3
2012
Proprietary
commercial
24/03/2009
Proprietary
commercial
No
3.03.00
No
ScreenFlow
3.00.02
11/08/2011
Proprietary
commercial
Screenpresso
1.02.06
28/09/2011
Freeware
No
1.02.06
28/09/2011
Proprietary
commercial
No
Screenpresso Pro
No
16/05/2012
Proprietary
commercial
Proprietary
commercial
No
GPL
Yes
GPL
Yes
Freeware
No
Freeware
No
GPL
Yes
SnagIt
11.00.01
Snapz Pro X
2.02.03
VirtualDub
1.09.11
24/12/2010
VLC media player
2.00.01
19/03/2012
9.00.00.3352
(x86)
Windows Media Encoder
Wink
XVidCap
10.00.00.3809
(x64)
2002
2.00
14/07/2008
1.01.07
13/07/2008
The next table contains a comparison by features of screen-casting software (available from
Wikipedia, as of July 04, 2012).
Product name
Audio
Entire
desktop
85
OpenGL
DirectX
Editing
Output
AVI,
FLV,
MP4,
SWF,
WebM,
WMV
ActivePresenter
Yes
Yes
No
No
Yes
ActivePresenter free
edition
Yes
Yes
No
No
Yes
Adobe Captivate
Yes
Yes
?
?
Yes
Bandicam
Yes
Yes
Yes
Yes
No
BB FlashBack
Yes
Yes
?
?
Yes
BB FlashBack express
Yes
Yes
?
?
No
BSR Screen Recorder
Yes
Yes
Yes
Yes
Yes
CamStudio
Yes
Yes
?
?
Yes
Camtasia for Mac
Yes
Yes
Yes
Yes
Yes
Camtasia Studio
Yes
Yes
Yes
Yes
Yes
Capture Fox
Yes
Yes
?
?
No
D3DGear
Yes
Yes
Yes
Yes
No
Dxtory
Yes
?
Yes
Yes
No
FFmpeg
Yes
Yes
Yes
?
No
Fraps
Yes
Yes
Yes
Yes
No
Freeseer
Yes
Yes
?
?
No
Ogg
Grabilla
Yes
Yes
No
Yes
No
WMV,
Upload
HyperCam
Yes
Yes
?
?
No
AVI,
WMV
iShowU
Yes
Yes
Yes
No
No
.mov
iShowU HD Pro
Yes
Yes
Yes
No
No
.mov
Jing
Yes
Yes
?
?
No
SWF
Jing Pro
Yes
Yes
?
?
No
Kazam
Yes
Yes
?
?
No
Microsoft Expression
Encoder
Yes
Yes
Yes
No
Yes
Nero Vision
Yes
?
?
?
Yes
Pixetell
Yes
Yes
Yes
Yes
Yes
QuickTime X
Yes
Yes
?
?
No
AVI,
MP4,
WebM,
WMV
AVI,
SWF
Motion
JPEG or
Xvid in
AVI
AVI,
WMV
WebM
86
Product name
Audio
Entire
desktop
OpenGL
DirectX
Editing
Output
Yes
Yes
?
N/A
No
Theora in
Ogg
RecordMyDesktop
Screen Capture
Yes
Yes
Yes
Yes
Yes
Screencam
Yes
Yes
Yes
Yes
Yes
ScreenFlow
Yes
Yes
Yes
N/A
Yes
Screenpresso
Yes
Yes
Yes
Yes
Yes
Screenpresso pro
Yes
Yes
Yes
Yes
Yes
SnagIt
Yes
Yes
Yes
Yes
No
Snapz Pro X
Yes
Yes
?
?
No
VirtualDub
Yes
?
?
?
Limited
VLC
Yes
Yes
Yes
?
No
Windows Media
Encoder
Yes
Yes
?
?
No
Wink
Yes
Yes
?
?
Yes
XVidCap
Yes
?
?
N/A
No
AVI,
mpeg,
mp4,
WMV,
mkv, flv,
.mov
A.4 List of animation software
This section contains a list of animation software (available from Wikipedia, as of July 04, 2012).
Free and Open-source
Commercial
Ajax Animator
Adobe After Effects
Creatoon
Adobe Flash
Professional
Dimp Animator
Alligator Flash Designer
EasyToon
Amara Web animation
Ella
Animasher
Go!Animate
Anime Studio
Helix
Antics 2-D Animation
KToon
Artoonix
MonkeyJam
AXA Team 2D
Open Dialect
Cacani
Pencil
CelAction 2D
Pivot Stickfigure Animator
CrazyTalk Animator
Plastic Animation Paper
CTP Pro
ShapeShifter
DigiCel Flipbook
87
Free and Open-source
Commercial
Stykz
DrawPlus
SVGDreams PHP animation
library
Express Animator
SWFTools
KoolMoves
Synfig
Microsoft Silverlight
TISFAT
Motion (software)
Tupi (Ktoon fork)
moviesoup
TweenMax
PICMO
Vectorian Giotto
RETAS
Stickman & Elemento
SWiSH Max
The-TAB
Toon Boom
Toonz
Toufee
TVPaint
TweenMaker

Demonstration material and events from Phase 2

Transcription

Similar documents

PETA

promo bebek betutu website

Develop a lifelong love of reading in every student

The online solution that assesses, instructs, and motivates students!

Calpine Northwest Geysers Enhanced Geothermal

"Amateurs` Revolt" Demonstration against Nuclear - HERMES-IR

ClearPass SE Remote Demo GSG

Anti-Chinese demonstrations in Vietnam looking from the

Ergon_EntertainSchedule_A4