d33.1 fi utility services specifications and …...project id 284860 msee – manufacturing services...

Project ID 284860 MSEE – Manufacturing SErvices Ecosystem

Date: 30/09/2012 Deliverable D33.1 FI Utility Services specifications and architecture – M12 issue

D33.1 – FI Utility Services specifications and

architecture – M12 issue

Document Owner: Martino Maggio ENG, Davide Storelli ENG, Calogero Crapanzano (ENG)

Contributors: Giovanni Casella SOFTECO, Charalampos Vassiliou SINGULAR, Ioan Toma UIBK, Iker Larizgoitia UIBK

Dissemination: Public Contributing to: WP 33

Date: 30 09 2012 Revision: Version 11



MSEE Consortium Dissemination: Public 2/45

VERSION HISTORY

VERSION DATE NOTES AND COMMENTS

1 20/07/2012 INITIAL VERSION WITH TOC

2 10/08/2012 ADDED FIRST CONTRIBUTION TO CHAPTER 3 AND 4

3 06/09/2012 TOC CONSOLIDATED AND ADDED CONTRIBUTIONS TO CHAPTER 3

4 10/09/2012 ADDED CONTRIBUTION TO CHAPTER 4

5 17/09/2012 ADDED FIRST VERSION OF THE SPECIFICATION OF SERVICES IN CHAPTER 4

6 19/09/2012 OVERALL REVISION BY ENG AND ISSUE TO SP3 FOR COMMENTS

7 20/09/2012 INTEGRATION OF CONTRIBUTIONS AND COMMENTS FROM SOFTECO AND SINGULAR

8 21/09/2012 ADDED INTRODUCTION AND CONCLUSION BY ENG

9 22/09/2012 ADDED EXECUTIVE SUMMARY AND FINAL SPECIFICATION OF SERVICES IN CHAPTER 4

10 24/09/2012 INTEGRATION OF CONTRIBUTIONS FROM UIBK AND OVERALL REVISION BY ENG

VERSION FOR PEER REVIEW

11 02/10/2012 INCORPORATED COMMENTS AND SUGGESTIONS FROM INTERNAL REVIEWERS

FINAL VERSION

DELIVERABLE PEER REVIEW SUMMARY

ID Comments Addressed (a) Answered (A)

1 Some examples of commoditized functionalities (section 3.1) could be useful for non-ICT experts a

2 In Figure 3 add some FI Platforms which are not FI PPP Core Platform FIWARE Chapters a

3

In Figure 4 replace the word Platform in use case boxes with “service instantiations”. These are the services (of the three categories) which are registered in the DelPlat and are at disposal of the UseCase MSE to implement operational processes and/or to create VMEs and operate servitisation processes.

a

4

Consider the possibility to extend the concept of “service” to the concept of “Web APIs” or other sw components which are not exactly a Web Service. Also applications should be considered in this sense.

Added as future steps in the conclusion.




TABLE OF CONTENTS

1� EXECUTIVE SUMMARY ............................................................................................................................ 6�

2� INTRODUCTION .......................................................................................................................................... 7�

2.1� OBJECTIVE OF THE DELIVERABLE .............................................................................................................. 7�2.2� STRUCTURE OF THE DELIVERABLE ............................................................................................................. 7�2.3� RELATIONS WITH OTHER DELIVERABLES ................................................................................................... 8�

3� UTILITY SERVICES DEFINITION AND STATE OF THE ART ........................................................... 9�

3.1� THE CONCEPT OF UTILITY SERVICE ........................................................................................................... 9�3.2� THE ROLE OF UTILITY SERVICES IN THE MSEE SERVICE SYSTEM LIFECYCLE .......................................... 13�3.3� ANALYSIS OF RELEVANT PROJECTS .......................................................................................................... 14�

3.3.1� COIN ............................................................................................................................................... 14�3.3.2� COMMIUS ...................................................................................................................................... 17�3.3.3� iSURF .............................................................................................................................................. 19�3.3.4� FI-WARE ......................................................................................................................................... 20�

4� UTILITY SERVICES IN THE CONTEXT OF MSEE ............................................................................ 22�

4.1� CATEGORIES OF UTILITY SERVICES .......................................................................................................... 22�4.1.1� Enterprise Interoperability .............................................................................................................. 23�4.1.2� Enterprise Collaboration ................................................................................................................ 24�4.1.3� Privacy and Security ....................................................................................................................... 25�

4.2� SPECIFICATION OF UTILITY SERVICES ..................................................................................................... 27�4.2.1� Single Sign On (SSO) ...................................................................................................................... 27�4.2.2� Feedback Management Service ....................................................................................................... 37�

5� CONCLUSION ............................................................................................................................................. 44�

6� REFERENCES ............................................................................................................................................. 45�




LIST OF FIGURES

Figure 1 - Structure of the deliverable ..................................................................................... 8�Figure 2 - Enterprise Interoperability Research Roadmap architecture layers [1] .................... 9�Figure 3 - Service buckets provided by SP3 to Smart Enterprise Applications ...................... 11�Figure 4 - Instantiation and aggregation of SP3 services in the four MSEE Use Cases ......... 12�Figure 5 - MSEE Service System Life Cycle ......................................................................... 13�Figure 6 - Categories of utility services discussed in the 1st MSEE General Meeting ............ 22�Figure 7 - No SSO approach Vs SSO approach ..................................................................... 28�Figure 8 - CAS authentication process ................................................................................... 30�Figure 9 - OpenID authentication process .............................................................................. 31�Figure 10 - SSO scenario sequence diagram .......................................................................... 35�Figure 11 - SSO logout scenario sequence diagram ............................................................... 36�Figure 12 - UML Use Cases for the Feedback Management Service ..................................... 38�Figure 13 - Data model for the Feedback Management Service ............................................. 39�Figure 14 - UML Sequence diagram for the Feedback Administration Module ..................... 41�Figure 15 - UML Sequence diagram for the Feedback Operations Module ........................... 43�

LIST OF TABLES

Table 1 - Relations between this document and other MSEE deliverables ............................... 8�

ACRONYMS CAS: Central Authentication Service CCTS: Core Component Technical Specification CRM: Customer Relationship Management CRUD: Create Read, Update, Delete DNS: Domain Name System DNSBL: Domain Name System BlackLists EC: Enterprise Collaboration EI: Enterprise Interoperability EIRR: Enterprise Interoperability Research Roadmap EOS: European Organisation for Security ERP: Enterprise Resource Planning FI: Future Internet FInES: Future Internet Enterprise System FI-PPP: Future Internet Public Private Partnership GE: Generic Enabler GUI: Graphical User Interface HPS: Human Provided Service HTTP: HyperText Transfer Protocol ICT: Information and Communication Technologies IbfP: Internet by and for People IdM: Identity Management IdP: Identity Provider IoCK: Internet of Contents-Knowledge IoS: Internet of Services IoT: Internet of Things




ISU: Interoperability Service Utility LDAP: Lightweight Directory Access Protocol MAC: Message Authentication Code MSE: Manufacturing Service Ecosystem OAGIS: Open Applications Group Integration Specification OASIS: Organization for the Advancement of Structured Information Standards OOS: Open Source Software OP: OpenID Provider OSSIM: Open Source Security Information Management PPL: Privacy Policy Language RFID: Radio Frequency Identification SaaS: Software as a Service SAML: Security Assertion Markup Language SBVR: Semantics of Business Vocabulary and Business Rules SCM: Supply Chain Management SE: Specific Enabler SIEM: Security Information and Event Management SOA: Service Oriented Architecture SME: Small Medium Enterprise SP: Sub Project SSO: Single Sign On SSTC: Security Services Technical Committee UBL: Universal Business Language UML: Unified Modeling Language URI: Uniform Resource Identifier URL: Uniform Resource Locator USDL: Unified Service Description Language VME: Virtual Manufacturing Enterprise WP: Work Package WSDL: Web Service Description Language XACML: eXtensible Access Control Markup Language XML: eXtensible Markup Language XPDL: XML Process Definition Language XRI: Extensible Resource Identifier




1 Executive Summary

This deliverable reports on the current state of the research activities in MSEE WP33 related to utility services in the context of the Future Internet. Starting from the current trends and frameworks related to the Future Internet and to Future Internet Enterprise Systems, the concept of utility service is here conceived as an extension of the well-known concept of Interoperability Service Utility (ISU) [1], thus inheriting its characteristics (e.g. low cost (low margin), high volumes, very little (or no) adaptation requirements, well-defined and standardized interfaces), but broadening its scope to commoditized services that go beyond the provision of functionalities to support interoperability and collaboration among enterprises. Indeed the deliverable identifies, starting from necessities and requirements elicited in MSEE SP5 from the MSEE Use Cases, other categories of utility services that complement the traditional ones of Enterprise Interoperability and Enterprise Collaboration. Such categories are Privacy and Security, Trust Management, Data Management and Product-related services. The list does not pretend to be exhaustive, but represents a first attempt to apply the foundational concepts that underpin ISUs to other services that are becoming more and more commoditized in the context of Future Internet Enterprise Systems and in general of the Future Internet. From an architectural point of view, utility services are part of the conceptual architecture of the MSEE sub project 3 (SP3). Such a conceptual architecture (which comprises partial results from WP32, WP33 and WP34) is composed by three service “buckets”, each one providing a different kind of service to Smart Ecosystem Applications and to any service/application developed in the servitization process. Such services are value-added services, utility services and services offered by FI-WARE Generic Enablers or similar FI-based platforms. A usage relation exists among those kinds of services. In particular FI-WARE Generic Enablers are used by the other two, whereas utility services are used only by value-added services. After the concept of utility service has been clarified and some categories have been identified, the deliverable provides also the specification of two concrete utility services that are actually needed by the MSEE use cases and that enrich the ones already provided by other relevant projects. All together such utility services represent a good starting point for populating the utility service “bucket” for MSEE. The first service that is specified is a Single Sign On service, which is considered as a basic means to ensure access restriction to services and applications while preserving a good level of usability for end-users thanks to the fact that they do not have to remember and re-submit credentials for every application they use. The second is a Feedback Management service which enables enterprises to collect customers’ and partners’ comments and feedback for improving their products and services. The categories and the concrete specifications of utility services provided in this deliverable are to be considered as a first version that will lead to the prototypical implementation of the two services (D33.3 at M18) and that will be refined and extended in the second version (D33.2 due at M21). In particular the categories will be further analysed and more services will be specified, implemented and adopted from other projects in the second cycle of the MSEE project, depending on the emerging requirements from the four MSEE Use cases.




2 Introduction

2.1 Objective of the deliverable The main objectives of this document are to provide the first definition of the concept of utility services and to provide the specification of a first set of concrete utility services to be used in the MSEE use cases. The document is the result of the efforts spent in WP33 the goals of which, according to the MSEE Description of Work are:

• to design the specific architecture of the intermediate layer between Federated Core Platforms (WP32) and Enterprise Applications value added services (WP34)

• to write the detailed specifications of each component • To develop and test the components in two releases (first-final) to be integrated and

evaluated in the test cases

In particular this deliverable is the first result of Task T3.3.1: FI Utility Services specification and Design (the second version of this deliverable, which is D33.2, is scheduled on M21). The deliverable starts by introducing the concept of utility service as an extension of that of Interoperability Utility Service (ISU) and by outlining the role of utility services with respect to FI Federated Platforms (WP32) and to value-added services (WP34). After that, a short review of some relevant projects is provided in order to give some background of the past and current experiences and results in the field of utility-like services. Finally the deliverable presents the categories of utility services that are taken into account for MSEE and for its use cases, and two concrete services are designed in detail in order to be developed as prototypes in the next months. Therefore, the following specific objectives have been identified for the deliverable:

• to define the concept of utility service with respect to current and past initiatives related to Future Internet Enterprise Systems and to the Future Internet in general

• to define a first set of categories of utility services • to define the role of utility services in the conceptual architecture of the MSEE sub

project 3 (SP3) namely “ICT service Clouds for Manufacturing Virtual Enterprises” , and in the overall MSEE project

• to provide the specification of two concrete utility services that are of interest for the MSEE use cases.

2.2 Structure of the deliverable The structure of the deliverable is organized into two major blocks (Figure 1), according to the objectives described in section 2.1:




Figure 1 - Structure of the deliverable

Block A introduces the reader to the deliverable and defines the concept of utility service with respect the key concepts such as ISU and GE, providing also a brief introduction on some reference projects. Moreover this section shows the role of utility services with respect to FI Federated Platforms (WP32) and to value-added services (WP34) and with respect to the overall MSEE service system lifecycle. Block B presents the identified categories of utility services that extend the ones consolidated in previous projects (addressing enterprise interoperability and enterprise collaboration) and provides the specification of two utility services that have been chosen with respect to the currently available user requirements from the MSEE use cases. Finally this block provides conclusions of the activity done in this task and outlines the future work in order to meet the final objectives of the WP.

2.3 Relations with other deliverables The following table shows the relations between this document and the other deliverables.

Deliverable Relation D52.1 – User Requirements Analysis for Virtual Factories & Enterprises in MSEE

User requirements collection from the MSEE Use Cases.

D33.2: FI Utility Services specifications and architecture

Final version of this deliverable.

D33.3: FI Utility Services first Prototype

Prototype based on the specification included in this document.

D31.1: Functional and Modular Architecture of Future Internet Enterprise Systems

Initial architectural considerations about the FI context in which utility services are placed

D32.1: FI Platform Federation specifications and architecture

From an architectural point of view utility services use services offered by Generic Enablers and mediated by the FI Platform Federation

D34.1: Detailed Specifications of next generation ESA Value Added Services

From an architectural point of view utility services are used by Smart Enterprise Applications defined in D34.1

Table 1 - Relations between this document and other MSEE deliverables




3 Utility Services definition and state of the art

The goal of this Section is to introduce the concept of utility service by defining its characteristics (inherited by the concept of Interoperability Service Utility) and by identifying its role with respect to the MSEE project and with respect to the conceptual architecture of the MSEE sub project 3 (SP3). Moreover this Section provides some background on past and on-going projects that are relevant for the definition of utility services for MSEE.

3.1 The concept of Utility Service The concept of Utility Service stems from the well-known concept of ISU (Interoperability Service Utility) [1], as a generalization that includes services that go beyond interoperability issues, addressing any commoditized functionality that is used in enterprise systems (e.g. management of user access to resources, evaluation of inter-enterprise trust-levels, storing and management of “big-data”, etc.). This means that such functionalities can be provided as basic services at low cost (with low margin), with high volumes and with very little (or no) adaptation requirements. According to [2], Utility Services are characterized by the following features:

• Cheap and near universal access • Seamless Quality of Service across multiple providers • Well understood, regulated and monitored service properties • Potentially high internal complexity, but limited external configurability/heterogeneity • Well-defined and standardised interfaces for utility usage and control • Ease of use

The ISU is an integral part of the FInES Research Roadmap [3], which has the following Vision Statement for Future Internet based Enterprise System 2025: “By 2020, the Internet will become a universal business environment on which new values can be created by competing as well as collaborating enterprises through innovation in a level playing field. Within this environment, FInES will become a transparent and invisible part of the business operation, available and affordable to all enterprises as required. It will make optimal use of the capabilities provided by a universal service infrastructure based on the concept of the Interoperability Service Utility (ISU).” Moreover the Enterprise Interoperability Research Roadmap (EIRR) [1] proposes a layered view of the conceptual architecture in which ISU is placed (see Figure 2). Interoperability is seen as a utility-like capability that is supported by a number of basic interoperability services. The term ISU is used to denote the overall system of basic services, which on the one hand relies on standardized infrastructural enablers (telecommunications, Internet and Web), and on the other hand provides the means to build value-added services.

Figure 2 - Enterprise Interoperability Research Roadmap architecture layers [1]




MSEE defines similar concepts in Sub Project 3 (see Figure 3). As stated above, Utility Services have to be considered as an extension of basic interoperability services (ISU). Indeed Utility Services represent what an enterprise has in common with other players in terms of basic routines, procedures and rules, spanning any kind of non-functional necessity beyond interoperability. In a few words: A Utility Service is a non-functional service that has reached such a high level of maturity that it is affordable to all, both from a technical and an economic point of view: in one word the generation of a Utility Service is a result of the diffuse ICT commoditization trend. Value-added services (both in MSEE and in the EIRR) reflect the uniqueness of an enterprise’s value-offering and must be fully aligned with its innovation process. In MSEE, value-added services are realized by the servitization of existing enterprise applications (e.g. ERP, SCM, CRM), which means that their core functionalities are exposed as services to external and/or internal consumers. For more information on value-added service please refer to [4]. As to standardized infrastructural enablers, the EIRR refers to generic domains such as telecommunications, Internet and the Web, whereas MSEE can take advantage of the Generic and Specific Enablers defined in FI-WARE (see Section 0) and of the possibility of federating FI Platforms in order to allow cross-domain scenarios that span instances of the different kinds of FI Platforms: Internet of Services (IoS), Internet of Things (IoT), Internet of Contents-Knowledge (IoCK), Internet by and for People (IbfP), FI Platforms for Logistics, FI Platforms for Mobility, etc. For more information on FI Platform Federation and on FI-WARE Generic Enablers see [5]. Finally Smart Enterprise Applications are complex applications that use at least one value-added service and that may use (directly or indirectly) both utility services and services from FI Platforms (services offered by Generic Enablers and Specific Enablers). The concept of Smart Enterprise Application is exhaustively described in [4]. It doesn’t have a formally defined correspondence in the layered architecture of the EIRR. Although the layered approach defined in the Enterprise Interoperability Research Roadmap could be applied also in MSEE, the three kinds of services provided by SP3 (value-added services, utility services, services related to FI Platforms) should be conceptually thought as independent from each other (see Figure 3). For each kind of service SP3 will provide a “bucket” of services that Smart Enterprise Applications could use (i.e. aggregate, orchestrate and compose in any manner) for providing advanced and value-added functionalities to enterprises in an MSE1 (Manufacturing Service Ecosystem).

1 According to the MSEE internal document ” Definition ME, MSE, VME” issued on August 27th 2012, “A Manufacturing Service Ecosystem (MSE) is a non-hierarchical form of collaboration where various different organizations and individuals work together with common or complementary objectives on new value added combinations of manufactured products and product-related services. This includes the promotion, the development and the provision of new ideas, new products, new processes or new markets. Inhabitants of such an MSE could be big OEMs, SMEs and networked organizations from various branches, ICT suppliers, universities and research centers, local public authorities, individual consultants, customers and citizens”




Figure 3 - Service buckets provided by SP3 to Smart Enterprise Applications

Of course this does not mean that relationships among the three kinds of services are not foreseen. In fact, it is likely that utility services on the one hand will leverage FI standardized infrastructural enablers (Generic Enablers) through the Future Internet Platforms functionality of MSEE, and on the other hand will provide the basic means to build value-added services. Arrows in Figure 3 (which represent the “use” relationship) show the usage relationship that may hold among the three types of service and the possibility for Smart Enterprise Applications to access independently each service. As to the actual leveraging of the three types of services in the MSEE use cases, we can consider the result of SP3 as a collection of services that can be instantiated, orchestrated and aggregated for any necessity of the four scenarios (see Figure 4). Each MSEE use case will be supported by one instance of the MSEE Platform and will choose the most appropriate services to be instantiated and aggregated for implementing the MSE and the VME servitization processes. Such services will be registered in the MSEE Generic Service Delivery Platform (WP4.2) in order to allow developers to search and retrieve them during the operational life of the MSE and when implementing the servitization process. For more information on the MSEE Generic Service Delivery Platform and on the methods and techniques to register services please refer to [6].




Figure 4 - Instantiation and aggregation of SP3 services in the four MSEE Use Cases




3.2 The role of Utility Services in the MSEE service system lifecycle The role of Utility Services in MSEE is to provide basic and generic services that may be used by MSEE Use Cases and that may be useful for any other scenario in a Manufacturing Service Ecosystem (MSE). The scope of those services must be defined in the context of the overall Service System Life Cycle (see Figure 5) that MSEE aims at supporting and guiding in the manufacturing industry.

Figure 5 - MSEE Service System Life Cycle

Such a cycle is composed of two main phases: • The design-time phase, which corresponds to the servitization process. This phase, on

the basis of precise new business opportunities and after the set-up of a Virtual Manufacturing Enterprise (VME)2, aims at grasping such opportunities, transforming the service system from its As-is situation to the most appropriated To-be in terms of operative processes, value-added services and through the leveraging of key assets of the VME. This process is responsible for the design of the VME’s human, physical and IT resources3, leading to a new business model that switches the value offered from physical products to product-service “bundles”.

• The run-time phase, that on the one hand allows the management of an MSE (MSE Governance), fostering and stimulating open innovation actions among the ecosystem actors (MSE Innovation), and on the other hand exploits the new techno-organizational configuration of VMEs (previously designed and developed in the

2 According to the MSEE internal document ” Definition ME, MSE, VME” issued on August 27th 2012, “A virtual enterprise (VE) is a temporary alliance of businesses that come together to share skills or core competencies and resources in order to better respond to business opportunities, and whose cooperation is supported by computer networks (Wikipedia definition). Members of MSE can set up a Virtual Manufacturing Enterprise (VME) to face and tackle business opportunities. In the context of the MSEE project, we will just consider VMEs which are implementing the whole or part of a Service Lifecycle process: its ideation, its development, its operation. A VME can be considered as a spin-off (not spin-out) of the MSE but not only: some partners outside of the MSE can join the VME. At the End of its Life, the VME dissolves and transfers the gained knowledge and outcomes to the MSE which generated it. 3 A human resource can be an operator, a manager or any people performing an activity in the service; Machine type resource are devices and equipments that are needed to provide and deliver services. These components may include: robots, specialized machines and devices for producing, delivering, maintaining services, movers/transport means, as well as any kind of physical facilities used for the creation and consumption of servicee; IT type resources include mainly software used to perform activities in the service to be delivered




design-time phase) in order to deliver the new value proposition to the customer through operational processes (VME Operations).

Figure 5 shows the two phases as separated and consequential: this can be considered only a logic view because in the real world they are performed at the same time influencing each other. Indeed the design-time phase is triggered by the MSE Innovation processes, which feed the servitization process with new potential business opportunities and new innovative ideas. When the servitization process starts, the Governance, Operative and Innovation processes continue to address their objectives independently from the status of the design-time phase. At the end of the servitization process, the newly defined operative processes are deployed and executed by the owner VME until they are dismissed. WP33 provides a set of utility services to the software developers that are involved in the design-time phase. While designing and developing core and value-added services and applications for the VME, indeed, software developers will need complementary services that have no particular value-added for the VME but that are needed to meet the requirements. Those services should be easily retrievable from the MSEE Generic Service Delivery Platform [6] to be readily integrated into the final result. The MSEE Generic Service Delivery Platform is one of the three core pillars of the MSEE IT System that supports the servitization process, being responsible for registering, discovery, ranking, selection, grounding and invocation, and low level monitoring of the services and applications that are used in a manufacturing service ecosystem.

3.3 Analysis of relevant projects This section aims at providing some background on past and on-going projects that are relevant for the definition of utility services for MSEE. In particular we chose a sub-set of projects (COIN, COMMIUS and iSURF) that contributed to the definition of the ISU concept and that developed their own implementation of utility-like services for interoperability. Moreover we provide a short overview on FI-WARE and on the categories of Generic Enablers that it will specify and develop as reference implementations.

3.3.1 COIN The COIN4 “Enterprise Integration and Interoperability” Project is an Integrated Project, under the European Commission Seventh Framework Programme. The Project objectives are to, design and develop an open and integrated ICT solution that is able to support European enterprises of any industry domain in the set-up and management of business collaborations through generic and pervasive utility services. The name “coin” is a metaphor that aims at emphasizing the complementarity of the two families of services addressed by the project: indeed a coin has two faces, which represent two different aspects of the same reality. In the COIN project one side (side A) refers to Enterprise Collaboration (EC) and the other (side B) refers to Enterprise Interoperability (EI). The former is addressed by developing innovative services that are adaptable to any kind of collaboration form and that enable cooperation and aggregation of networked enterprises, with special focus on SMEs. The latter aims at providing IT services that address interoperability issues at different levels: data level, system level and business process level, thus enabling easier and more effective collaboration among networked enterprises. The COIN system is considered as a catalyst for EI/EC service providers and service consumers, providing functionalities to publish, search/discover, orchestrate and execute the services in a cross-enterprise environment.

4 http://www.coin-ip.eu/




3.3.1.1 ISU concept and realization in COIN The concept of ISU is central in the COIN IP, since it is addressed both from a business and a technological point of view. From the business point of view, COIN studied the establishment of business models based on ISUs that reflect the actual necessities of the market. From the technological point of view COIN developed a constellation of EI/EC services to support different scenarios requiring innovative IT solutions for data, system and business integration. According to the Enterprise Interoperability Research Roadmap, COIN sees ISUs as destined to be a “utility-like” interoperable technology capability that can be "invoked on-the-fly by enterprises in support of their business activities". The implementation of the ISU should play a key role in granting easy access for small businesses to the business ecosystem. Moreover COIN anticipates the notion of a FI Core Platform providing applications with basic, universal, available-to-all services, in this case EI/EC services. The Core Platform Generic Enablers could be complemented by enterprise specific EI/EC commodities to fill the interoperability gaps during enterprise collaboration processes [7]. In the following we provide a brief description of the utility services delivered by COIN in the field of Enterprise Interoperability and Enterprise Collaboration. It is to be noticed that the descriptions are adapted from the corresponding Deliverables issued by the COIN IP. Enterprise Collaboration Collaboration Network and Visualization Service: forms of collaboration are becoming more and more flexible and the number of possible partners is rapidly growing due to the availability of cheap but powerful ICT. In such a scenario, the establishment and evaluation of trust among different actors is of primary importance. COIN goes beyond the current approaches based on manual rating and feedback (e.g. eBay) and defined new mechanisms for trust determination based on monitoring and analysing interactions among nodes of a collaboration network. The Collaboration Visualization Service is realized as a set of Web Services and a Frontend-Tool for social network visualization. Trusted Online Help and Support This service provides the means to integrate human capabilities in a SOA-based environment. Indeed users are enabled to register, offer share and consume capabilities as HPS (Human Provided Services) which are described through WSDL. HPS discovery and social-relations visualization are supported by web-based tools. Users can thus search for on-line experts in any moment and have a first automatic evaluation of trust degree based on automatic observation and grade of interactions. Trusted Information Sharing Service This service allows the sharing of information based on emerging and adapting trust, without requiring periodic manual adaptations of sharing rules. Contextual information from various sub-services, including data about collaboration, is used by the service to compute trust degree. Further services providing useful context data can be potentially used as well, such as the Skype Web service for retrieving the online status. Basically the service allows a document provider to upload a full document and select sharing-restriction rules. Other users may retrieve or not the document (or part of it) depending on the social relationship with the provider. Collaboration for Project Management (Coll4Pm) The Collaboration for Project Management (Coll4PM) service aims to solve the collaboration challenges on Collaborative Management of a Collaborative Projects, working as an upper layer relying on existing Gantt tools. Indeed the service provides a web-based application that creates a virtual room for collaborating virtual teams. Members of the virtual team can insert new Gantt proposals and can use communication tools to discuss with the other components of the virtual team as a whole or just to a subset of them.




Collaborative Production Planning Platform (C3P) Service The aim of C3P is to provide a platform where, starting from a business opportunity, companies can invite other partners and cooperate to the definition of the production plan, solving in a collaborative way exceptions, warnings, and so on. C3P service provides a virtual space where they can share documents, share planning and product information, interact in synchronous and/or asynchronous way. SaaS Production Planning Service (PPS) The aim of PPS service is to create a SaaS layer on-top of existing Production Planning systems. Basic functionalities of a PP system are exposed as web service, but also human-oriented access is provided through the C3P service GUI (see above) Collaborative Quality Management Service (cQMS) Usually quality-relevant information in networked organizations flows following the product structure logic. This causes other interdependencies among network members (mainly dependencies among competencies) to be ignored or underestimated, with possible negative impacts on the quality of the final product. The cQM Service aims at reducing such risk by providing a mix of baseline functionalities (partner profiling, product structure) and an innovative algorithm for determining dependencies in partners competencies in respect of a special network configuration. Enterprise Interoperability Payload Interoperability Service The Payload Interoperability Service allows users to create and manage negotiation processes in 1:1 and 1:N scenarios. Negotiations are relate to UBL documents and are guided by rules. Each actor of the negotiation (creator of the negotiation or participant) can define its rules and see their result on the document. COIN Semantic Reconciliation suite This service enables the exchange of documents among non-interoperable information systems by using semantic reconciliation techniques. The service builds on a domain ontology that is used as a common reference for the reconciliation of heterogeneous data. First of all the service automatically identifies semantic correspondence between a document schema and the reference ontology. Then, after validation of such correspondences by a human user, the system generates reconciliation rules. Finally a web service for the actual transformation of documents is automatically generated. Social Ontology Building and Evolution service This service supports enterprises of a collaboration network to cooperate in the building of an ontology about their competencies and skills. The service provides a formal and structured methodology that starts from the definition of the lexicon and of the glossary and then enriches the introduced concepts by classifying them with respect to the OPAL categories and by defining is-a and part-of relationships. Enterprise Semantic Profiling service This service helps enterprises that are part of a collaborative network to specify their profile in terms of concepts that refer to a common and shared ontology that describes the competencies needed in the network (see Social Ontology Building and Evolution Service). The service includes two steps: in the first one knowledge extraction techniques are used to extract relevant concepts from textual documents provided by the enterprise. This first set of concepts represents an initial version of the profile, which can be modified and refined in the second step by adding or removing concepts from the profile.




Enterprise Semantic Matchmaking service This service allows computing the semantic similarity between semantic profiles, supporting reasoning over the knowledge asset (profiles of the enterprises in terms of competences and skills) of enterprises in a collaboration network. The following are some of the functionalities that can be realized through this service: semantic assessment of the competencies of a collaborative network (strengths, weaknesses, gap, …), semantic assessment (positioning with respect to the current competencies of the network) of companies entering a collaborative network, competencies transfer from a virtual enterprise to the collaborative network.

CBPip Private To Public Transformation Service This service performs automatic Model-to-Model transformations for deriving a public version of a process from its private form. The service takes as input an XPDL2 model (the private version of the process), visibility rules expressed in SBVR and a string that specifies the receiver of the public version of the process. The transformation hides tasks that are declared as private. CBPip Gap Detection Service This service analyzes business processes represented in XPDL2 and detects interoperability gaps. Examples of gaps that are detected are: deadlocks caused by improper use of gateways, format mismatch caused by a message flow with a message object that is different from the message object expected by the receiver. The service returns a result report formatted as human-readable text.

3.3.2 COMMIUS COMMIUS5 (COMMunity-based Interoperability Service Utility for SMEs) is a Project funded under the Seventh Framework Programme. It addresses the problem of enterprise interoperability with a specific focus on the necessities of SMEs, which cannot face costly investment, extensive integration effort and significant revision of their working tools and systems. The idea of the project is to allow SMEs to achieve enterprise interoperability by using existing and familiar applications for electronic communications (i.e. email programs and internet browsers) enhanced by the tools provided in the framework of the COMMIUS project. The deployed tools enhance enterprise of interoperability at the levels of system, semantics and process. Systems Interoperability is achieved by leveraging email for exchanging business documents, thus building interoperability solutions above existing simple and widespread ICT infrastructures. Semantic Interoperability addresses alignment of contents using extensible semantic descriptors (ontologies) which characterize relevant business document types. Process Interoperability addresses seamless entry of SMEs into a community of interoperable companies, helping the enterprises to adopt flexible business processes easily adaptable to the requirements coming up when initiating new business relationships.

3.3.2.1 ISU concept and realization in COMMIUS According to what has been defined in the Enterprise Interoperability Research Roadmap, the Commius project conceives interoperability as a utility-like capability (ISU) for enterprises. In particular COMMIUS gives concrete interpretation to some of the characteristics of ISU,

5 http://www.commius.eu/




providing a mapping with the context of the COMMIUS architecture. The mapping represented the initial starting point for the design and development of the COMMIUS architecture:

1. Accessible in principle by all enterprises: COMMIUS is accessible to all enterprises which use email to carry on their business, which is a very weak constraint that is met by the vast majority of enterprises. Different deployment strategies make COMMIUS even more flexible for peculiar necessities and technical infrastructures of an enterprise: indeed the COMMIUS system can be downloaded and installed in the infrastructure of the enterprise and/or the system can be used as a service Software as a Service model without the need to invest on a dedicated ICT infrastructure and staff.

2. Scalable and almost zero cost: the email-based approach allows enterprises to scale the interoperability solution from the local to the Internet-level at almost zero cost. Interoperability solutions based on COMMIUS are almost at zero cost for enterprises since the system can be downloaded for free and is easy-to-use and impose no modification to the usual SME practices (thus requiring minimum training for the employees)

3. “Guaranteed” to a certain extent and at a certain level in accordance with a set of common rules: quality is guaranteed by reusing results from previous research projects, by adopting de-facto standards in the design of the software modules and by building its approach on simple and widespread (highly available) infrastructures such as the Web and email systems. Moreover security and privacy issues are addressed to guarantee trusted interactions among partners.

4. Not controlled or owned by any single private entity: software products that result from the project are not owned by a single entity (e.g., a company or an organization). Moreover the core modules of COMMIUS are released under an OSS (Open Source Software) license and their management is demanded to an OSS community.

The COMMIUS system is composed by a set of independent modules belonging to three layers, addressing different aspects of enterprise interoperability, namely System Layer, Semantic Layers, Process Layer. The functionalities offered by these layers are exploited by COMMIUS interoperability modules providing user-oriented functionalities. A COMMIUS installation can include one or more modules according to enterprise requirements. While some general modules have been developed during the project, new modules can be developed to address the specific requirements of an enterprise. The following is a list of the interoperability modules developed during the project: Mail Template Manager The Mail Template Manager aims at facilitating the user in the management of incoming emails through a proactive proposal of email-templates and documents (documents can be any kind of file) that can be used to quickly reply to or forward these mails. Email templates and document can be defined and/or customized by the user and can be associated to a specific business process or to a particular step of a business process. Search for Partner The Search For Partner module enables SMEs to search for other SMEs by submitting queries on heterogeneous data-sources (private SME database, public web service, private web service, legacy system, …) and by specifying characteristics of the needed product, service or expertise. The COMMIUS project developed several data sources and realized suitable client applications for other existing data-sources (i.e. Google Product6, Octopart7).

6 www.google.com/products 7 Octopart:_electronic parts, electronic components, datasheets search engine octopart.com/




Attachment Manager The Attachment Manager allows users to manage documents attached to sent/received emails and to organize (i.e. store and manage versioning) them according to specific business processes. Indeed each business process instance is associated to a folder where the relevant attachment will be saved. InfoBridge The aim of the InfoBridge module is to enable the storing and retrieving of information from external systems like databases, ERP, spreadsheets, and other structured data sources on the base of some information received by mail. This allows enterprises to fully exploit COMMIUS with their existing system. Email Social Network Search The Email Social Network Search module is used to search/explore objects and resources mentioned in an email (personal email addresses, telephone numbers, company names, company products/services, etc). The module provides a GUI that presents to the user all the objects related to the current email message and allows a deeper navigation in the object-graph by clicking on any object.

3.3.3 iSURF iSURF8 (An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains Supported by RFID Devices) is a FP7 project which aims at sustaining European companies, especially SMEs, in effectively collaborate in supply chains where demand and supply flows are better aligned and exceptions in the management of the production plans are handled in a dynamic and flexible way. As a response to this aim, iSURF provides a knowledge-oriented inter-enterprise collaboration environment to SMEs to share information on the supply chain visibility, individual sales and order forecast of companies, current status of the products in the manufacturing and distribution process, and the exceptional events that may affect the forecasts in a secure and controlled way [8]. Such environment allows:

• achieving semantic reconciliation of the planning and forecasting business documents exchanged between the companies according to different standards;

• integrating the collaborative supply chain planning process with the underlying legacy applications by wrapping the existing legacy applications through a SOA-based approach;

• guaranteeing availability of the right data at the right place at the right time in the right format through an open-source smart-product infrastructure based on RFID technology using EPCGlobal standards. Through this infrastructure, necessary tools and processes are provided to collect, filter, correlate, aggregate and put into business-context real time product visibility events from massively distributed RFID devices;

• handling exceptions in the collaborative supply chain planning process (e.g. logistic problems) through semantic infrastructure for establishing transitory and dynamic collaboration agreements between trading partners

3.3.3.1 ISU concept and realization in iSURF As to the concept of ISU, iSURF is fully aligned to the definition provided by the Enterprise Interoperability Research Roadmap, conceiving it as a utility-like capability that parties can utilize as they need, anywhere and anytime. In accordance to such definition iSURF developed ISU services that facilitate real-time information sharing and collaboration between enterprises by providing semantic support for electronic business document 8 http://www.iSURFProject.eu




interoperability [9]. In particular the iSURF Interoperability Service Utility provides a generic semantic interoperability mechanism which enables mediation among business documents that are based on the any implementation of the UN/CEFACT CCTS standard (e.g. OAGIS9, UBL10, GS111). Indeed, although such standards share some semantics due to the common inheritance from CCTS, they are not fully interoperable. The ISU provides the means to discover relationships among concepts in a semi-automatic way by using ontologies and Description Logic reasoning. Such capability, although not still enabling a fully automatic mapping of concepts among business documents, represents a load-reducing mechanism to domain experts who usually have to do it manually. Although the ISU was conceived with a special focus on inter-enterprise exchange of planning related data, its methods, techniques and tools can be applicable to any domain that needs mechanisms for interoperability among business documents.

3.3.4 FI-WARE The FI-WARE12 project is part of the Future Internet Public Private Partnership (FI-PPP) program of the European Commission. Its main result will be the FI Core Platform, which will introduce a secure and innovative infrastructure for the creation and delivery of digital services, with the aim of making Europe the first ICT economy in the world. The Core Platform comprises a set of technological “Generic Enablers” that are considered as reusable and commonly shared functions for a multiplicity of Usage Areas13 across various sectors. FI-WARE will identify, specify and provide reference implementations of such GEs, thus enabling the development of FI applications and services that relay on a common base of reliable and commoditized infrastructure. GEs currently under development in FI-WARE are related to the following Technical Chapters:

• Cloud Hosting: defines the fundamental computation, storage and network GEs for the provision and management of services;

• Data/Context Management: defines GEs for processing and managing massive quantity of data in order to allow their exploitation as value-added knowledge;

• Applications/Services Ecosystem and Delivery Framework: defines GEs for managing the lifecycle of services both from a technical and a business point of view;

• Internet of Things (IoT) Services Enablement: defines GEs for interfacing services with devices in the Internet of Things;

• Interface to Networks and Devices (I2ND): defines GEs for interfacing services with mobile devices and networks;

• Security: defines GEs for ensuring security and privacy constraints on services delivered and used in the Core Platform.

The adoption and adaptation of Generic Enablers to the necessities of MSEE (with the provision to FI-WARE of relevant feedback and, possibly, requirements) will represent one important result of MSEE since usage areas formally related to FI-WARE (eHealth and Wellbeing, Content, Smart Energy Grids, Utilities and Environment, Transport, Mobility and Logistics) do not include the manufacturing industry and Future Internet Enterprise Systems (see FInES Cluster), which are the focus of MSEE. MSEE is thus both interested in acquiring and contributing to the definition of some GEs, since on the one hand they are good candidates to be included in the bucket of Utility Services for FInES and on the other hand they lack of requirements from the manufacturing industry and are thus potentially not aligned to the actual needs of FInES. 9 http://www.oagi.org/dnn2/ 10 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl 11 http://www.gs1.org/ 12 http://www.fi-ware.eu/ 13 Usage areas are represented by the eight use case projects: ENVIROFI, FI-CONTENT, FINEST, FINSENY, INSTANT MOBILITY, OUTSMART, SAFECITY, SMARTAGRIFOOD.




Considering GEs defined in FI-WARE, the focus of this deliverable is on those related to the Security chapter. This is due to the fact that such services cross the different FI Platforms (described in [5]: IoT, IoS, IoCK IbfP) and present all the characteristics of utility and commoditization described in section 3.1. More detailed information of the services identified in the Security chapter of FI-WARE is given in section 4.1.3. Other types of GEs may be considered in the second cycle of the MSEE project, namely in deliverable D33.2.




4 Utility services in the context of MSEE

The review presented in the previous chapter provided a brief view on projects and services that have been conceived and developed with the common idea of building future ICT systems on top of standardized and utility-like services. The aim of this chapter is twofold:

• to provide a list of categories of utility services that extends the ones identified by such projects and that may serve as a guide for developers that are searching for complementary and commoditized services for their core applications.

• to specify some concrete utility service that can be taken as examples and that respond to actual requirements of the MSEE Use Cases.

4.1 Categories of utility services Defining a list of categories of utility services may seem a simple task, but actually the variety of services that are provided by the market (and by research projects) and that fall under the definition of utility service provided in section 3.1, creates some initial difficulties in identifying those that are more suitable for the scope of MSEE. We started from the two categories that have been widely addressed by projects that refer to the FInES Cluster and/or to the Enterprise Interoperability Research Roadmap (i.e. Enterprise Interoperability and Enterprise Collaboration) and then we identified a few other categories that, starting from the MSEE Use Cases specified in [10], may be of interest for the MSEE project. Figure 6 shows the categories proposed and discussed by MSEE partners during the 1st MSEE General Meeting. Each category has one or more examples of sub-categories with an indication of the use cases that may be interested in corresponding services according to [10].

Figure 6 - Categories of utility services discussed in the 1st MSEE General Meeting

The proposed categories were then refined and elaborated with respect to the preliminary needs coming from the four MSEE Use Cases and formalized in MSEE sub project 5 “User Requirements, Assessment and Validation” as a list of user requirements. The result of this effort is the following list of service categories: Enterprise Interoperability, Enterprise Collaboration, Privacy and Security, Trust Management, Data Management, Product-related services. This document focuses on the categories that are considered as the most urgent from the point of view service/application developers in a MSE (Enterprise Interoperability, Enterprise Collaboration, Privacy and Security), whereas the others will be addressed in the second version of this document (MSEE_D33.2 due at M21).




The following sections provide a description of the prioritized categories, for the others a brief explanation is here summarized:

• Trust Management: trust is here considered as an attribute of parties (and of their relationship) that cooperate in a business network[13], as the “essential 'glue' that holds the network together”[14]. Trust is the result of complex interactions that hold among the members of the network and is influenced by many factors such as social, economical and political conditions. Examples of trust management services are: reputation management, recommendation management.

• Data Management: information collected from different and heterogeneous data sources has to be managed in a coherent way in order to be able to turn it into actionable knowledge. Possible services related to this category are: data mining service, big-data management.

• Product-related services: products are the actual “platform” that vehicles services to the final user. Interacting and collecting row data from the products at run-time is an important way to improve the services and to create added value for the customer. Examples of product-related services are: basic services for bi-directional communication with products, services for collecting run-time data from the products, services for monitoring the status of products.

The following sections provide a description of the prioritized utility service categories. Each description has the primary aim to provide a further classification of the possible services that may belong to that category.

4.1.1 Enterprise Interoperability Enterprise Interoperability (EI) is a concept that refers to a research/industrial field in which organizational, technological and strategic solutions are used to bridge interoperability gaps among enterprises that want to collaborate. EI services provide ICT instruments to actually allow businesses to run collaborations by reducing risks and costs of adaptation and integration of cross-organizational systems, processes and information models. The MSEE project starts from the IE concepts and frameworks defined in some European Projects (COIN, COMMIUS and ATHENA14) and in the European Interoperability Framework15. In particular in the COIN project Enterprise Interoperability is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged”.16 Interoperability is considered as a multi-faceted problem that has to be addressed in a holistic way, considering aspects related to the technological, organizational and conceptual levels. This results in the definition of four inter-connected levels that interoperability should be addressed by networked enterprises:

• the information/data level, which is concerned with the management, exchange and share of different documents, massages and content by different collaborating enterprise. At this level the semantics of contents and of documents’ structures is of primary importance in order to ensure that the exact meaning of exchanged information is understandable by all application involved in the cross-enterprise collaboration. Some of the innovative solutions developed in the previous projects aim at overcoming the semantic barriers through automatic and semi-automatic support to information mapping and through pattern-based approaches that allow end users to define complex data transformations through the instantiations of a limited set of patterns.

14 http://www.modelbased.net/aif/ 15 http://ec.europa.eu/idabc/en/document/2319/5644.html 16 http://www.coin-ip.eu/




• the service level, which is the capability to discover, aggregate, orchestrate and execute various services (i.e. web services) that have ben independently designed and implemented. Interoperability at the service level allows transparent composition and mediation among web services in distributed environments through semantic mediation of service interfaces and functional/non functional parameters in order to allow the creation of complex and value-added functionalities that meet business-level requirements.

• the process level, which aims to synchronise internal processes of an enterprise with the processes of the other networked enterprises to create cross-organisational business process. At this level issues to be solved are related, for example, to i) the detection of parts of the processes that should not be disclosed to other parties due to security reasons and the identification of interoperability gaps among the interested workflows in terms of deadlocks and inter-process message mismatch.

• the enterprise level, which is the organisational and operational capability of an enterprises to cooperate with other enterprises that are under different legislations and that have different cultures and working practices. This aspect of interoperability is concerned with how enterprises collaborate to achieve their mutually agreed goals and considers aspects that go beyond technical ones, including social and strategic ones.

4.1.2 Enterprise Collaboration Enterprise Collaboration (EC) is a research field that aims at defining models and tools for creation and management of effective inter-enterprise business cooperation in response to emerging business opportunities. The need to collaborate can be generated by different kinds of market demands, for example a specific client request can generate a single and “one-shot” collaboration, whereas a stronger market demand could generate collaboration forms that have a longer life-time and that need more complex instruments to be properly managed. Given the broad range of possible collaborations among enterprises, there is the actual necessity to have a structured way to set-up and manage enterprise aggregation, process synchronization and people co-operation through the definition of different life-cycle phases, which are here used to identify families of EC utility services. We take the EC Baseline Reference Model defined in COIN [7] as a reference schema for collaboration life-cycles. Such model is composed of four phases, each of which can be supported by ad-hoc or by cross-phases services. In the preparation phase enterprises enter the collaboration network by registering and defining their profiles. Services developed to support this phase must be compliant to the rules and normative which have been established for the network. Indeed different kinds of collaborations, from simple supply chains to complex and dynamic business ecosystems, and different industrial domains may require specific information and/or the fulfilment of particular procedures. In the formation phase enterprises develop new business opportunities, either through internal activities or by collaborating with other members of the network. Typical services for this phase are those that support ideation processes (in which new innovative ideas are created and evaluated with respect to their business viability), opportunity characterization (in which the needed tasks and competences are identified and defined) and partner discovery/selection with respect to the competences needed to actually pursue the new opportunity. In the management & operation phase members of a collaboration network cooperate to actually deliver value to the customer. Services related to this phase span from repositories for the sharing of product/service documentation/information to systems for the management and tracking of tasks of each partner. In the dissolution phase both the partners and the customers can provide feedback with respect to the collaboration experience, thus allowing the parties to elaborate new lesson learnt to be exploited in next collaborations.




Finally cross-phases services provide the means to facilitate communication among the interested parties in any moment of the collaboration.

4.1.3 Privacy and Security The field of privacy and security management is of primary importance in the context of ICT because of the always-growing amount of critical and sensible information that people and enterprises share/use on the Internet, being exposed on a daily basis to threats and attacks from different sources. The ICT industry is thus involved in a continuous battle for securing data through the development of innovative countermeasures to the emerging and new threats. The market and the scientific community have developed solutions that span from identity management to encryption of data, from context-aware systems to security monitoring and risk assessment (to name just a few). The adoption of such solutions on a global-scale had the natural consequence of requiring the different stakeholders to find common and interoperable ways to implement the security systems in order to assure the quality of the results and to lower the costs of development by reusing best practices and existing well-known solutions to common problems. In this sense, communities of inter-disciplinary experts have issued many standards (e.g. OAuth17, XACML18, SAML19), frameworks and open software libraries/components (e.g. OpenIAM20, IAMSuite21, VELO22, JBoss Identity23) that address such issues. The problem of security is becoming a first-class citizen in the governments’ agendas too. In the “Cybersecurity Act of 2012”24 the US Government recognizes the necessity of fostering a public-private approach on cybersecurity issues because communication and information infrastructures are largely owned by privates and operated at a global level. Also in Europe this problem is strongly discussed and the organization EOS25 (the European Organisation for Security) supports appropriate measures and action plans for the safe of critical information infrastructures, the changes in ICT and the pooling of IT competences in EU institutions. In particular EOS supports the EU Internal Security Strategy, according to the Stockholm Programme in the next perspectives (2014-2020). This organization sustains the European Security Model, covering all main priority areas and EU Industrial Security Policy and developing a full EU Public-Private approach. Moreover, with the rise of the Future Internet, the FI-WARE Project is giving such initiatives a structured framework in order to identify, specify and develop as reference implementations, some utility-like services (called Generic Enablers) that build upon existing solutions and that aim at simplifying secure access to resources over the Internet through services and applications that are “secure by design”26. Considered the current trends that are leading towards standardization and commoditization of security/privacy services and applications, MSEE recognized in such context a good candidate for defining utility services. We take the FI-WARE Security architecture as a reference and inspiration for providing a classification of possible utility service in the area of privacy and security. Such architecture is composed of the following four modules. 17 oauth.net/ 18 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml 19 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 20 http://www.openiam.com/ 21 http://sourceforge.net/projects/iam-suite/ 22 http://sourceforge.net/projects/velo/ 23 http://www.jboss.org/picketlink 24 http://www.gpo.gov/fdsys/pkg/BILLS-112s2105pcs/pdf/BILLS-112s2105pcs.pdf 25 http://www.eos-eu.com/files/Documents/GlobalPositions/Security_Programmes.pdf 26 In this context the concept of “secure by design” means that services and applications built on top of the FI-WARE Core Platform and of its GEs will be granted to adopt SotA solutions to security and privacy threats.




Security Monitoring27 is the primary means that security managers of FI environments will leverage to assess the security state of the system and to detect potential threats and anomalous behaviours. This Generic Enabler provides several functionalities, spanning from normalization and correlation of heterogeneous events that are relevant for security management, to risk analysis that evaluates the profile of typical security threats (including system vulnerabilities) and assesses the impact of such threats with respect to the organization, from decision making support, that helps security managers to select the most appropriate countermeasures for mitigating the risks, to digital forensics for evidence, which allows the acquisition and analysis of data from heterogeneous sources and the identification, preservation and presentation of evidence extracted from those data. Finally the Security monitoring GE provides a visualization and reporting interface that allows the different stakeholders to access the previously described functionalities through a Graphical User Interface. Generic Security Services provide functionalities that are generally needed by Internet users for their day-by-day interaction with services and applications. Such functionalities include identity management28, which provides the means to access resources (networks, services devices, …) in a secure and trusted way, data handling29, which enables access control based on attribute-based methods, building on the XACML standard and the PPL (Privacy Policy Language) language, and privacy management30 which actually enhances the previous two GEs by providing certified credentials to users and presentation tokens which are derived from the credentials and that can selectively reveal attribute values and/or predicates over one or more attributes without disclosing their actual values. Context-Based Security and Compliance31 supports advanced security needs from services and applications by providing the means to process context-related information in order to deal with dynamic and unpredictable context changes. This GE provides an innovative way of describing security-related information of services and applications by leveraging USDL-SEC32, an extension of LinkedUSDL33 for security aspects, and a rule-based mechanisms to allow the management of complex security agreements that must be fulfilled commonly by two (or more) entities. Optional Generic Security Services34 are GEs that provide complementary and non-core functionalities to specialized security applications. Some examples of such services are related to the evaluation of anonymization policies for Data Bases and to the detection of malware in the binary code of software programs.

27 this section is adapted from: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.Security_Monitoring 28 this section is adapted from: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Identity_Management_Generic_Enabler 29 this section is adapted from: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.Data_Handling_Generic_Enabler 30 this section is adapted from: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.Privacy_Generic_Enabler 31 this section is adapted from: http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.Context-based_security_%26_compliance 32 http://www.linked-usdl.org/usdl-sec 33 http://www.linked-usdl.org/ 34 http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.Optional_Security_Enablers




4.2 Specification of Utility Services Given the wide range of possible services that could be considered for specification and development in MSEE, we will focus on some services that are of immediate necessity for the four MSEE Use Cases and that could represent good examples for future improvements and extensions based of final users’ feedback. To this end we considered the preliminary requirements collected in MSEE SP5 and matched them with the categories of utility services described in the previous sections. Such “proposed” requirements (that are still to be elaborated and deeply analysed) highlighted, among the others, two fundamental necessities, one related to security/privacy issues and the other related to basic collaboration necessities. In the first case, the MSEE Use Cases expressed the necessity to elaborate concepts and IT services to “cover/ensure privacy/confidentiality in the network” through the management of roles and permissions in accessing resources and services. Such necessity is strictly related to the nature of ecosystems, which represent an interaction environment where different parties collaborate and cooperate toward common objectives, but with different roles and with potential risks of disclosure of key information assets. Among the different modules of the FI-WARE Security chapter (see section 4.1.3), the Generic Security Service module includes some GEs that fit the requirements and that could be of interest for developers who have to build-up new services and/or applications in a servitization process and might need utility-like security services to complement the core target functionalities. In particular we chose to specify a Single Sign On service, which is considered as a basic means to ensure access restriction to services and applications while preserving a good level of usability for end-users thanks to the fact that they do not have to remember and re-submit credentials for every application they use. In the second case, the MSEE Use cases expressed the necessity to have services for collecting customers’ and partners’ comments and feedback for improving machine design and manufacturing processes. Such services are considered as cross-phases services with respect to the phases described in section 4.1.2. The requirement derives from the actual necessity of enterprises to continuously improve the value-offering by taking into consideration both the voice of the customer and the voice of the partners involved in the VME. We chose to specify a Feedback Management service that is generic enough to be easily integrated and re-used in different scenarios, with different requirements related to the possibility to keep the comments secret or to open them for discussion. It is to be noticed that the choice of the two services was primarily driven by the actual needs of the four MSEE use cases. Of course they don’t fulfill all the necessities of the use cases, but together with the services provided by the projects outlined in section 3.3, they represent a good starting point for building up the Utility Service “bucket”. The two utility services here specified will be implemented as prototypes in MSEE D33.3 - FI Utility Services first prototype due at M18. Prototypes related to other utility service categories will be specified in MSEE D33.2 and implemented in D33.4.

4.2.1 Single Sign On (SSO) Single sign-on (SSO) is an authentication mechanism that allows a user to authenticate only once to access to all the resources (applications, services, files) for which is authorized. In a system based on "Single Sign On" (SSO) authentication, resources requests are not directly managed by the system itself but they are redirected to another authentication system that has previously certificate user credentials: in this way it is not necessary that the user validates his credentials again moving from an application to another one. The objective of the Single Sign On is to make security transparent to the end user perceiving he is working in a secure environment the without repeating annoying log in operations.




In the MSEE project it will be developed several heterogeneous services and applications based on different technologies: for this reason the presence of a Single Sign On service will be important in order to guarantee the security facilitating the user experience that will not be affected by the repetition of authentication operations. The Single Sign On service will avoid the needs to replicate the registration and credential selection process: the user will be able to authenticate himself with the same credential

Figure 7 - No SSO approach Vs SSO approach

There are several architectural approach to implement SSO:

• Centralized: it is a solution which provides a single repository where the users are registered (such as a database). It is not a very flexible approach; it is effective when it is used as a centralized management method of the security policies for example within a company. Each organization tends to keep an internal centralized authentication system of users and groups, to control the access to corporate resources. The most widely system used for this type of authentication service is LDAP (Lightweight Directory Access Protocol) a protocol particularly efficient in user list queries.

• Federative: this type of approach is particularly useful when different federated organizations (nodes), manage user information. Accessing one of the federated nodes allows automatically the access to the other nodes. This approach allows a decentralized user management: every node keeps control of its own security policy.




• Cooperative: the cooperative approach can be used when each user depends, for each

service, from only one of the cooperating nodes. Authentication is performed by the node representing the organization the user belongs. As for the federation approach, also in this case each node independently manages the its security policy.

It is possible to “combine” different approaches among the presented ones allowing the individual nodes to define their own security policies. From the point of view of MSEE, it is important to consider all the aforementioned approaches in order to be able to support any kind of necessity that may arise from MSEs and VMEs that will be developed in the MSEE Use Cases. Anyway the first version of the Single Sign On service will be implemented as a centralized system for management of accesses at ecosystem level. Several technological solutions have been adopted in the last years in order to implement a Single-Sign-On approach. Technologies In the following sections it will be presented some open technologies and products that are related or that implement Single Sign On approach. These technologies will be evaluated in a more detailed way in the following months in order to be used as basis for the implementation of the SSO service. Central Authentication Service (CAS) CAS is open source authentication system, developed at Yale University35, which manages all the authentication requests in a centralized manner redirecting them to one or more trust servers. This solution is characterized by the following features:

• Security o The password is never transmitted to applications. o It is used an encrypted ticket

• Simple integration and portability o Several clients are available for free, including libraries for Java, Microsoft

.Net, PHP, Perl, Apache, Liferay • Open Source.

The authentication process through the use of CAS is illustrated in Figure 8 and is briefly described below.

• When the user accesses to a web application he is redirect to the CAS login page of on

an HTTPS connection, to enter username and password. • After login, the CAS proceeds to authenticate the user verifying his credential

(username and password) • If the authentication fails, the user is redirect to an error page • If the authentication process is successful, the user is redirected to the resource

previously requested associating to this URL a ticket (authentication token).

35 http://www.jasig.org/cas




• After the authentication, the CAS creates an in-memory cookie called ticket-granting cookie to allow the re-authentication for next requests for other resources/services authentication to other services.

Figure 8 - CAS authentication process

Open ID OpenID (Open Identity)36 is an open source authentication protocol created by Brad Fitzpatrick of LiveJournal, which allows you to implement single sign-on authentication systems, in distributed environments, through the use of a URI like username or identifier. In OpenID the credential management is delegated to a provider, which will be responsible to provide, in a transparent way, to the user, the various applications participating in SSO platform. According to the SSO systems criteria, OpenID protocol aims to improve the authentication procedures in terms of speed, ease and safety. Through OpenID is, in fact, possible to create a single account that will be shared between different applications, avoiding to fill different registration form. OpenID allows to have only one identity which eliminates the problems related to storage and management of different username and password. Also OpenID supports the users to choice the information associated to their own identity that can be shared with other applications. In addition, the use of a single set of credentials allows the user to more effectively manage periodic changes of the password. OpenID 2.0 specifications define the entities that are involved in the data exchange process:

• End-user: is the entity that wants to assert a particular identity. • Identifier: can be an HTTP URI or XRI (Extensible Resource Identifier) and it is used

to identify the end-user (User-supplied identifier) or identity provider. • Relying party (RP): is a web site or application that wants to verify the end-user's

identifier. Other terms for this party include "service provider". • Identity provider, or OpenID provider (OP): is a service that specializes in

registering OpenID URLs or XRIs.

OpenID enables an end-user to communicate with a relying party. This communication is done through the exchange of an identifier or OpenID, which is the URL or XRI chosen by

36 http://openid.net/specs/openid-authentication-2_0.html




the end-user to name the end-user's identity. An Identity provider provides the OpenID authentication (and possibly other identity services). The exchange is enabled by a User-agent, which is the program (such as a browser) used by the end-user to communicate with the relying party and OpenID provider. The following picture shows the phases of a typical authentication process with OpenID:

1. Initiation: the End User is the entity that starts the process to be authenticated to a Relying Part, giving it its identifier.

2. Discovery: the Relying Part search for OP location in different ways, depending on the type of identifier inserted by the User.

3. Association: After the Discovery phase, can start the Association session between the Relying Part, and OP, through a direct request by the Relying Part, via an HTTP POST request. If the association request is successful, the OP sends to Relying Part a message containing the parameter that is used as the key to uniquely identify the association throughout the procedure, but it has a limited lifetime after which expires the session of the Association. In this phase, the Consumer and OP share a key MAC (Message Authentication Code) that represents the shared secret used to digitally sign messages.

4. Authentication: If it has been established an association between Relying Part and OP, can begin the final phase of authentication through an indirect request by the Relying Part.. Upon receipt of the request, the OP determines whether or not to authorize End User authentication.

5. Verifying Assertion: When the Relying Part receives the response it checks the parameters associated with the message, including the digital signature which is involved in the shared secret seen before.

Figure 9 - OpenID authentication process

SAML SAML37 (Security Assertion Markup Language) is an open standard based on XML for the exchange of information between different entities during their authentication and authorization operations, implementing the specific of SSO systems. It is developed by the SSTC (Security Services Technical Committee) belonging to the organization OASIS (Organization for the Advancement of Structured Information Standards). The purpose of SAML is to implement a framework that provides an XML syntax, able to standardize the representation of security credentials, and a protocol for transmission. These features allow

37 SAML: http://saml.xml.org/




the management of sensitive data (such as identity, attributes, rights, etc ...) of a generic entity known as Principal, during interactions between the entities participating in its business activities. The SAML standard allows interoperability between different infrastructure software business partners, enabling the creation of an applications platform and online services, which are based on a single shared authentication process. The advantages offered by the introduction of SAML in infrastructure are manifold, including:

• Platform Independence: compatible with the SOA architectural philosophy, SAML allows the implementation of a platform regardless of the technologies and architectures, which support different applications and related services

• Loose coupling between the directories do not need to keep synchronized user information that may be scattered in several instances or directory.

• Improve the online experience for users: SAML includes all the benefits of SSO. In addition, in cases of federated systems, SAML provides several mechanisms for customization of use of services, including for example the account linking, which allows connection to a single profile of different accounts that authenticate to different service providers.

• Reduce the cost of administration of the service provider: the management of user account information shall be delegated to an Identity Provider, which is asked during authentication with different service providers, allowing the simplification of their structure and their function.

• Transfer of risk: the impact of security risks is transferred on identity provider, which, from the structural point of view, has greater strength than a typical service provider.

SAML provides for the interaction of the following entities: • Principal: generic person who actively participates in the process of authentication or

authorization, uniquely identifiable by the system using a profile that collects information about him.

• Identity Provider (IdP): also called SAML authority or asserting Party, keeps track of the credentials of the principal and it can provide the information associated with him. In the most general sense, a SAML authority is considered as an entity capable of responding to requests made through the SAML protocol.

• Service Provider (SP): also called Relying Party, represents the server that receives the information on a principal by the Identity Provider. SAML has mechanisms that allow the service provider to check the validity of this information.

SAML is based on the concept of “Assertions” that are packets of information that are the responses to requests that come to SAML authorities. The service provider requests and obtains an identity assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision - in other words it can decide whether to perform some service for the connected principal. Before delivering the identity assertion to the SP, the IdP may request some information from the principal - such as a user name and password - in order to authenticate the principal. SAML specifies the assertions between the three parties: in particular, the messages that assert identity that are passed from the IdP to the SP. In SAML, one identity provider may provide SAML assertions to many service providers. Conversely, one SP may rely on and trust assertions from many independent IdPs. SAML does not specify the implementation of the identity provider service; it may use a username/password, it may use multifactor authentication, it may have an opaque implementation.




Shibbolet Shibbolet38 is a Single Sign On system based on open standards such as SAML, that transports not only information about user authentication, but also information about authorization, coded in attributes extracted from LDAP and exported via SAML assertions. SAML (Security Assertion Markup Language) is a standard defined by OASIS that allows the exchange of information providing authentication and authorization on the Internet assuring interoperability between different authentication management systems SAML does not define new authentication and authorization mechanisms, but XML schemas that describe how to manage authentication and authorization with specific rules. Shibboleth is the standard adopted by the GARR community39 for federated authentication between research institutions and it allows to establish trusting relationships within the community of the participating entities. Shibbolet is an open source software, released under the Apache license, which allows to manage permissions for access to online resources, supporting the development of Single Sign-On. Shibboleth was developed in the context of Internet2, and that aims at creating and promoting technologies and tools that enable a more effective and efficient use of the web, allowing the development of federated authentication and authorization systems based on the open source standard OASIS SAML. Shibboleth is particularly useful in the context of federated systems where users, besides accessing to services within their organization, they need to use services in other security domains, behaving the need for further credentials for authentication: this scenario is characterized by problems related to sharing of credentials or integration between the different authentication systems. Shibboleth solves these issues adopting the principle that a service provider needs not only the identity of those that want to access its resources, but also a series of attributes that identify the security level of the user. The Shibbolet strong points are the following:

• it uses for the user information the existing identity management systems in the organizations,

• it implements a just-in-time communication, sending to the service provider only the information strictly necessary to access to the resources

• It optimizes the privacy policies management between organizations; The architecture of Shibboleth is composed of the following macro components:

• Identity Provider (IdP), which has the task to authenticate the user and to provide the required attributes. The IdP is composed by the following sub-components:

o SSO Service, which is a service called by the SP to start the authentication process.

o Authentication Authority, which is responsible to delegate the authentication process to the specific components that must implement it. If the authentication has been performed, this authority provides authentication assertions to the SP, indicating if the subject was authenticated, in which mode (eg. Using password) and the authentication time.

o Attribute Authority, which provides attribute assertions to the SP so that it is able to discriminate the access to its resources.

o Artifact Resolution Service, which is another component that provides assertions to answer the request by a SP of a reference artifact called

38 Shiboleth: http://shibboleth.internet2.edu/ 39 http://www.garr.it/b/eng




• Service Provider (SP), which is the entity that provides resources and services, and it is composed by:

o Assertion Consumer Service, that processes the received assertions; o Attribute Requester, which takes care of interacting with the IdP’s Attribute

Authority in order to exchange the users’ attributes in a secure environment; • WAYF (Where Are You From?), Which is the service that allows the user to discover

the IdP with which to authenticate. The role of WAYF is, in fact, to provide the user a list of IdP, relating to the different organizations within the federation, that are able to authenticate the user

4.2.1.1 Single Sign On Module The main aim of the Single Sign On service in MSEE is to provide a common authentication functionality for the application and services developed in the project. The SSO will be an added value service for two different categories of users: the final users of the platform will be able to perform the authentication process only one time for different applications in the MSEE platform, but also the software developers will be able to easy integrate their application services with the SSO without taking care of the authentication issues. The entities involved in the Single Sign On process in the MSEE system are the following:

• User: is the generic user that want to access to a specific resource (application, services etc.) in the MSEE system. The user can be human or can be another application that want to access to the resources.

• Service provider: is the entity that provides the required resource (application, services). In the MSEE Ecosystem there will be several Service Providers

• Identity provider: is the entity that validates the user credential performing login operations. In the MSEE scenario it is possible to have one Identity Provider per ecosystem

The following sequence diagram shows the interaction among these entities in a typical SSO scenario:

• (1) a generic user tries to access to one resource of the Service Provider A: • (2) after the request the Service Provider A asks the Identity provider to verify if the

requiring user has an active authentication session • (3-4) Identity Provider answers with a negative response because the user is not

logged in the system • (5) Service Provider A asks the Identity Provider to create a new authentication

section for the user • (6-7) Identity Provider sends a login page to the user that provide his credential. • (8-9-10) Identity Provider, after the verification of credential, sends some information

about the authenticated user to the Service Provider A that provides the requested resource to the user.

• (11-12-13-14-15) the User requires a resource to another Service Provider (B) which asks for session verification to IDP. The IDP verifying that the user is already logged sends the relative information to the SPB that provides the resource requested.




User Service Provider A Identity Provider Service Provider B

1 : getResource()2 : verifySession()

3 : checkSession()4 : false

5 : createNewSession()

6 : login page

7 : login()

8 : checkCredential()9 : UserInformation

10 : resource11 : getResource()

12 : verifySession()

13 : checkSession()

14 : UserInformation

15 : resource

Figure 10 - SSO scenario sequence diagram

Another typical SSO scenario includes the logout operation. This scenario is illustrated in the following sequence diagram. In this sequence diagram the logout functionality is described by the first 5 steps, whereas the remaining steps serve to show the effect of the logout operation, and correspond to the first 6 steps of the previous diagram:

• (1) a logged user sends a logout request to the Service Provider, • (2) the Service Provider forwards the logout request to the Identity Provider, • (3 - 4) the Identity Provider deletes the current session of the user, and sends a

confirmation message to the Service Provider, • (5) the Service Provider sends a confirmation message to the user, informing him that

he is logged out from the system, • (6) At a later time the user tries to access to one resource of the Service Provider, • (7) the Service Provider asks the Identity provider to verify if the requiring user has an

active authentication session, • (8-9) Identity Provider answers with a negative response because the user is not

logged in the system, • (10) Service Provider A asks the Identity Provider to create a new authentication

section for the user • (11) Identity Provider sends a login page to the user.




Figure 11 - SSO logout scenario sequence diagram

The following table shows the main operations that the IDP provides to the other SP in order to support single sign on authentication: Name login Description Allows the user to perform authentication in the SSO Input User Credential (e.g. username/password, digital sign etc). Output Login response: if the authentication is correct the response contain

user information, if failed the response contains an error message Name logout Description Perform the logout request for a specific user Input User session Output Confirmation/error response Name verifySession Description Verify if the user is already logged in the system Input User session Output Login response: if the user logged in the system the response

contain user information, otherwise the login functionality will be called




4.2.2 Feedback Management Service Feedback management is today one of the most important means that the web2.0 wave has provided to enterprises to gather valuable information from customers and from other stakeholders. Differentiation of the value-proposition is indeed a key objective that businesses pursue in they daily life, trying to understand market trends and customer satisfaction by capturing the “voice of the customer”. According to a study of the Aberdeen Group, which involved 252 organizations in September and October 2011, companies using customer feedback management services and social media monitoring have a 15% better customer retention rate [11]. Services that support feedback management may vary in terms of objective and of the methodology they are based on. We can distinguish three main classes of feedback management services: feedback collection and analysis, surveys and polls, and idea management. However it is to be noticed that real-world services may provide features that hybridize those classes, which of course represent a simplification of the varieties of services available on the web. Feedback collection and analysis: services for feedback collection and analysis provide the means to gather customers’ voice through web-forms that are available in any section of a web site or of an application. Data collected is available for any kind of analysis and metrics evaluation (e.g. sentiment analysis) in order to turn it into actionable knowledge. Usually the feedback is visible only to the enterprise, thus preventing possible brand damages deriving from public negative comments. Surveys and polls: services for managing surveys and polls enable enterprises to prompt customers’ feedback on precise subjects through pre-defined open or closed questions. The results of this kind of services is based on a statistical analysis of the answers, thus, to be meaningful and useful for the enterprise, the service should be used in scenarios characterized by significant number of responding people. Idea management: idea management systems aim at fostering and managing the creation of new and innovative ideas through cross-organizational and user-inclusive initiatives. Such systems provide a structured approach to the collection, evaluation and exploitation of innovative ideas through precise workflows. Usually such workflow is composed of three main phases. In the first phase, idea generation, any interested party can submit ideas both responding to a campaign created and managed by the enterprise or to an on-going theme for which the enterprise always requires ideas. They can associate ideas with some existing categories or tags to help the overall management of the ideas. In the second phase, idea improvement, ideas generated by customers and other stakeholders are improved with votes, comments, more tags and attachments submitted by other users. Votes and comments contribute to the calculation of the rating of the ideas. In the third phase, idea selection, ideas are processed by reviewers (e.g. domain experts), that can create reviews of ideas for better analyze some aspects like financial or technical ones. They can do some studies of ideas like SWOT analysis and attach results to ideas. They can also create interlinks between ideas to identify similar ideas, opposite ideas or extending ideas. Finally the enterprise can access to ideas reviews and ratings and decides which ideas are accepted and which are refused. Usually idea management systems are used to involve customers in suggesting ideas, report problems and evaluate the business’ next developments. Being such systems open to the public, the enterprise brand can be potentially harmed by negative reports and regular customers’ complaints. The necessity that MSEE Use Cases exposed to have services for collecting customers’ and partners’ comments and feedback for improving machine design and manufacturing processes lead us to the definition of a service that falls under the category “feedback collection and analysis” and that is generic enough to be reused for different purpose, thus representing a Utility Service that can address the necessities of any industrial domain. Use cases of the proposed services are represented in Figure 12.




Figure 12 - UML Use Cases for the Feedback Management Service

The involved actors are the enterprise that wants to collect and analyse feedbacks and the stakeholders (here named customer, but not limited to customers) that will provide those feedback. In particular the enterprise manages the topics of the comments (customers are required to choose one topic for each comment). Topics may be referred to specific products, services, initiatives and any entity that the enterprise wishes to collect feedback about. In order to provide flexibility to the system, the enterprise is enabled to specify which comments are going to be visible to the public. This is done by assigning a visibility level to each topic. The visibility level (hidden/not hidden) is inherited by the comments that refer to that topic. Finally the enterprise is enabled to delete individual comments. On the other hand the customer (or any other stakeholder) is allowed to create new comments with respect to one of the existing topics, to reply to comments (if visible), and to search among the visible comments. From a functional point of view the service is composed of two main modules:

• feedback administration module • feedback operations module

The feedback administration module aims at enabling the enterprise to manage topics that comments can be associated to. Operations exposed by this module are typical CRUD (Create Read, Update, Delete) operations, plus basic search, list and filter functionalities that allow the enterprise to always have a clear picture of the supported topics. Moreover this module allows enterprises to decide if comments are to be considered public (thus accessible by subjects other than the enterprise) or private (thus only accessible by the enterprise). The feedback operations module provides to customers and other interested parties the means to submit comments with respect to supported topics (also regarding other comments), and to search for existing comments (of course this feature is available only for comments that are public). The simple data model used for the service is represented in Figure 13.




Figure 13 - Data model for the Feedback Management Service

It is to be noticed that the attribute “replyTo” is used as a pointer to the commentID of the comment replied (if any). In such case the attribute topic remains empty because the topic is inherited from the replied comment. In the following paragraphs the specific operations of each module are described in details.

4.2.2.1 Feedback administration module The operations to be provided by the feedback administration module are the following: Name CreateTopic Input • The name of the topic to be created

• A brief textual description of the topic

Output ID of the newly created topic Result A new topic is created.

If a topic with the same name already exists then the operation has no effect and an exception is raised (topic already created).

Name DeleteTopic Input • The ID of the topic to be deleted

Output ID of the deleted topic Result The topic corresponding to the input ID is removed.

All the comments related to the specified topic are removed. If the input ID does not correspond to any existing topic then an exception is raised (ID not found).

Name HideTopic Input • The ID of the topic to be hidden

• boolean

Output ID of the topic (unchanged) Result If the value of the Boolean is “true” then the comments related to the

topic that corresponds to the input ID are no more visible by the operations of the “feedback operations module”. If the value of the Boolean is “false” then the comments related to the topic that corresponds to the input ID are visible by the operations of the “feedback operations module”.

Name GetTopicByID




Input • The ID of the topic to be retrieved

Output ID, name and description of the topic corresponding to the input ID. Boolean: true if the topic is hidden, false id the topic is not hidden

Result The information of the topic corresponding to the input ID is returned. If the input ID does not correspond to any existing topic then an exception is raised (ID not found).

Name GetTopicByName Input • The name of the topic to be retrieved

Output ID, name and description of the topic corresponding to the input Name Boolean: true if the topic is hidden, false id the topic is not hidden

Result The information of the topic corresponding to the input ID is returned. If the input Name does not correspond to any existing topic then an exception is raised (Name not found).

Name UpdateTopic Input • The ID of the topic to be updated

• The new name of the topic

• The new description of the topic

Output ID of the updated topic (unchanged) Result The name and description of the topic are replaced by the new ones. The

ID is not altered. If the input ID does not correspond to any existing topic then an exception is raised (ID not found).

Name SearchTopic Input • text to be matched with names and descriptions of topics

Output List of IDs of matching topics Result The topics (name and description) are analysed and matched against the

input text. No changes to the descriptions are done. Name ListTopics Input NA Output List of IDs of all existing topics Result All topics IDs are returned. No changes to the descriptions are done. Name FilterTopic Input • boolean

Output If the input Boolean is “true” then the operation returns the list of IDs of topics that are hidden If the input Boolean is “false” then the operation returns the list of IDs of topics that are not hidden

Result All topics (hidden or not hidden) IDs are returned. No changes to the descriptions are done.

Name DeleteComment




Input • ID of the comment to be deleted

Output ID of the deleted comment Result The comment corresponding to the input ID is removed.

All the comments (replies) related to the specified comment are removed. If the input ID does not correspond to any existing topic then an exception is raised (ID not found).

The following figure shows a simple scenario in which the enterprise creates a new topic and then hides another topic that is considered as damaging the brand of the company. The topic is identified through a search upon its name.

Figure 14 - UML Sequence diagram for the Feedback Administration Module

4.2.2.2 Feedback operations module The operations to be provided by the feedback operations module are the following: Name CreateComment Input • The text of the comment

• the name of the creator of the comment (nickname)

• the timestamp when the comment is ctreated

• ID of the topic to which the comment is related

• Score, which is an integer from 1 to 10 used to give a quantitavie evaluation of the entity represented by the topic

Output ID of the newly created comment Result A new comment is created.

If the input ID of the topic does not correspond to any existing topic




then an exception is raised (ID not found). If the input Score has an invalid value than an exception is raised (invalid score).

Name ReplyToComment Input • The text of the comment

• the name of the creator of the comment (nickname)

• the timestamp when the comment is ctreated

• the ID of the comment that this comment is responding to

Output ID of the newly created comment Result A new topic is created.

If the input ID of the comment does not correspond to any existing comment then an exception is raised (ID not found).

Name SearchComment Input • text to be matched with content of cooments that are not hidden

Output List of IDs of matching comments Result The comments (textual content) are analysed and matched against the

input text. No changes to the comments are done. Name FilterCommentByTopic Input • ID of the topic

Output List of IDs of matching comments Result If the topic correspondent to the input ID is not hidden then the list of

IDs of the matching comments is returned. If the topic correspondent to the input ID is hidden then an exception is raised (hidden topic) No changes to the comments are done.

Name GetReplies Input • ID of the comment that replies are related to

Output List of IDs of matching comments Result If the comment correspondent to the input ID is not hidden then the list

of IDs of the matching comments is returned. If the comment correspondent to the input ID is hidden then an exception is raised (hidden comment) No changes to the comments are done.

Name GetTopic Input • ID of the topic

Output ID, name and description of the topic corresponding to the input ID. Result The information of the topic corresponding to the input ID is returned.

If the input ID does not correspond to any existing topic then an exception is raised (ID not found).

Name ListTopics




Input NA Output List of IDs of all existing topics Result All topics IDs are returned for topics The following figure shows a simple scenario in which the customer, after getting the list of topics, choses one topic and visualizes its description. Then the customer requires all the comments of that topic and, after choosing one specific comment, gets all the replies to the comment.

Figure 15 - UML Sequence diagram for the Feedback Operations Module




5 Conclusion

This deliverable reports on the current state of the research in MSEE about utility services. The concept of utility service derives and extends the one of Interoperability Utility Service, inheriting its characteristics, but broadening its scope to commoditized services that go beyond the provision of functionalities to support interoperability and collaboration among enterprises. Indeed the deliverable identifies, starting from necessities and requirements elicited in SP5 from the MSEE Use Cases, other categories of utility services that complement the traditional ones of Enterprise Interoperability and Enterprise Collaboration. Such categories are Privacy and Security, Trust Management, Data Management and Product-related services. The list does not pretend to be exhaustive, but represents a first attempt to apply the foundational concepts that underpin ISUs to other services that are becoming more and more commoditized in the context of Future Internet Enterprise Systems and in general of the Future Internet. Moreover it is to be noticed that the sets of services that are referred to the identified categories are not intended to be disjointed. This means that, for example, a service for user profiling might belong both to the categories “Enterprise Collaboration” and “Privacy and Security”. The identified categories should be seen as a guide to help developers search for utility services they are interested in. The role of utility services is explained with respect to the MSEE project and to the conceptual architecture of the MSEE sub project 3 (SP3). Such conceptual architecture (which comprises partial results from WP32, WP33 and WP34) is composed by three service “buckets”, each one providing a different kind of service to Smart Enterprise Applications and to any service/application developed in the servitization process. Such services are value-added services, utility services and services offered by FI-WARE Generic Enablers and other FI Platforms. A usage relation exists among those kinds of services. In particular FI-WARE Generic Enablers are used by the other two, whereas utility services are used only by value-added services. The deliverable provides also the specification of two concrete utility services that are required by the MSEE use cases. The first is a Single Sign On service, which is considered as a basic means to ensure access restriction to services and applications while preserving a good level of usability for end-users thanks to the fact that they do not have to remember and re-submit credentials for every application they use. The second is a Feedback Management service which enables enterprises to collect customers’ and partners’ comments and feedback for improving their products and services. The categories and the concrete specifications of utility services provided in this deliverable are to be considered as a first version that will lead to the prototypical implementation of the two services (D33.3 at M18) and that will be refined and extended in the second version (D33.2 due at M21). In particular the categories will be further analysed and more services will be specified, implemented and adopted from other projects in the second cycle of the MSEE project. Finally it is planned to evaluate an extension of the “service” concept in order to include not only traditional web-services but also “web-APIs” and applications, with particular reference to those deployed as Service (SaaS).




6 References

[1] Man-Sze Li, Ricardo Cabral, Guy Doumeingts, Keith Popplewell: Enterprise Interoperability Research Roadmap Final Version, 31 July 2006

[2] Man-Sze Li: The Economics of Utility Services in the Future Internet. In Georgios Tselentis, Alex Galis, Anastasius Gavras, Srdjan Krco, Volkmar Lotz, Elena Paslaru Bontas Simperl, Burkhard Stiller, Theodore Zahariadis (Eds.): Towards the Future Internet - Emerging Trends from European Research. IOS Press 2010, ISBN 978-1-60750-538-9

[3] Future Internet Enterprise Systems (FInES) Research Roadmap, June 2010

[4] MSEE D34.1 - Detailed Specifications of Next Generation ESA value-added services

[5] MSEE D32.1 - FI Platform Federation specifications and architecture

[6] MSEE D43.1 - Service Delivery Infrastructure specifications and architecture

[7] “The COIN Book”, written by Patrick Sitek, Sergio Gusmeroli, and Editors Marco Conte, Kim Jansson, Iris Karvonen, 2011

[8] iSURF Deliverable 9.4.1 - Best Practices on Deploying and Using the Results of iSURF Components

[9] iSURF Deliverable 4.3.1- iSURF Interoperability Service Utility

[10] D52.1 – User Requirements Analysis for Virtual Factories & Enterprises in MSEE

[11] Omer, Minkara, Customer Experience Management: Using the Power of Analytics to Optimize Customer Delight. Aberdeen Group (2012)

[12] Cristina Martinez Gonzalez, Man-Sze Li, Nikolas Provatas, Sylvie Woelfflé: Future Internet Enterprise Systems (FInES) Cluster - Cluster Book, ICT2010 EVENT VERSION, June 2010

[13] Bachmann R, Zaheer A (editors), “Handbook of Trust Research”, Edward Elgar Publishing Limited, 2006

[14] Jarillo, J. C. 1990. 'Comments on transaction costs and networks", Strategic Management Journal, 11,6, 497-499.