d33.2 fi utility services specifications and architecture...

Project ID 284860 MSEE – Manufacturing SErvices Ecosystem

Date: 04/07/2013 D33.2 FI Utility Services specifications and architecture – M21 issue

D33.2

FI Utility Services specifications and

architecture

M21 issue

Document Owner: Mauro Isaja [ENG]

Contributors: Giovanni Casella [SOFTECO], Ioan Toma [UIBK], Iker Larizgoitia [UIBK], Jerry

Dimitriou [SINGULAR]

Dissemination: Public

Contributing to: WP 33

Date: 04/07/2013

Revision: 1.1



MSEE Consortium Dissemination: Public 2/58

VERSION HISTORY

VERSION DATE NOTES AND COMMENTS

0.1 01/06/2013 INITIAL VERSION

0.2 24/06/2013 CONTRIBUTION FROM ENG

0.3 27/06/2013 CONTRIBUTION FROM SOFTECO

0.4 27/06/2013 CONTRIBUTION FROM SINGULAR

0.5 28/06/2013 CONTRIBUTION FROM IUBK

1.0 28/06/2013 VERSION FOR PEER REVIEW

1.1 04/07/2013 FINAL VERSION

DELIVERABLE PEER REVIEW SUMMARY

ID Comments Addressed ()

Answered (A)

1

P. 21 - Trust Management: it is not clear where this concept, which is essential within a MSE, is mentioned in Fig. 6.

A

2

P. 33 - It should be emphasized the relationship between the VER and the Tangible/Intangible assets (i.e. T/IA), which are exposed by the SMEs on the Manufacturing Service Ecosystem.

A

3 The term ”performance indicator” should be used instead of ”process indicator”

4 (typos)




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 ......................................................................... 21

4.1 CATEGORIES OF UTILITY SERVICES .......................................................................................................... 21 4.1.1 Trust Management ......................................................................................................................... 21 4.1.2 Data Management ......................................................................................................................... 22 4.1.3 Product-related services ................................................................................................................ 22 4.1.4 Enterprise Interoperability ............................................................................................................ 22 4.1.5 Enterprise Collaboration ............................................................................................................... 22 4.1.6 Privacy and Security ...................................................................................................................... 22

4.2 SPECIFICATION OF UTILITY SERVICES ...................................................................................................... 23 4.2.1 Federated Single-Sign-On ............................................................................................................. 23 4.2.2 Virtual Enterprise Registry ............................................................................................................ 32 4.2.3 Performance Indicator Registry .................................................................................................... 37 4.2.4 Feedback Management Service ..................................................................................................... 50

5 CONCLUSION .......................................................................................................................................... 57

6 REFERENCES ........................................................................................................................................... 58




LIST OF FIGURES

Figure 1 - Structure of the deliverable ........................................................................................ 7 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 1

st MSEE General Meeting ............. 21

Figure 7 - No SSO approach Vs SSO approach ....................................................................... 24

Figure 8 - CAS authentication process ..................................................................................... 25 Figure 9 - Federated SSO overview ......................................................................................... 27 Figure 10 - LSA delegation ...................................................................................................... 28 Figure 11 - SSO login sequence diagram ................................................................................. 28 Figure 12 - LSA Service pluggable connector architecture ..................................................... 29

Figure 13 - Virtual Enterprise Registry positioning in MSEE ................................................. 32 Figure 14 - Performance Indicator Registry positioning in MSEE .......................................... 37

Figure 15 - PIR logical data model ........................................................................................... 39 Figure 16 – Feedback Management Service Architecture........................................................ 51

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..

In the first iteration of this document (M12 issue) we described the specifications of two

concrete utility services that were actually needed by the MSEE use cases: Single Sign On

and Feedback Management. In this second and final iteration we introduce two totally new

services: the Virtual Enterprise Registry (section 4.2.2) and the Performance Indicator

Registry (section 4.2.3). The Single Sign On service specifications have been extensively

refactored in order to reflect the current state of development, and to integrate the Virtual

Enterprise Registry – to the point that the service has been renamed to Federated Single-Sign-

On (section 4.2.1). Finally, the specifications of the Feedback Management service were also

updated (section 4.2.4).

These specifications will lead to the prototypical implementations released as part of

deliverable D33.4 by month 24.




2 Introduction

2.1 Objective of the deliverable

The main objectives of this document are to provide the definition of the concept of utility

services and to provide the specification of a 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, to be integrated and evaluated in the test cases

In particular this deliverable is the final result of Task T33.1: FI Utility Services specification

and Design.

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 four 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 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 four 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 four utility services that have been chosen with respect to the

user requirements from the MSEE use cases. Finally this block provides conclusions of the

activity done in this task.

2.3 Relations with other deliverables

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

Deliverable Relation

D33.1: FI Utility Services

specifications and architecture - M12 issue

Previous version of this document.

D33.4: FI Utility Services final

Prototype - M24 issue (to come)

Prototypes based on the specifications

included in this document.

D52.2 – User Requirements Analysis for

Virtual Factories & Enterprises in MSEE -

M15 issue

User requirements collection from the MSEE

Use Cases.

D31.2: Functional and Modular Architecture

of Future Internet Enterprise Systems - M18

issue

Architectural considerations about the FI

context in which utility services are placed

D34.4: Final specs of next generation ESA

Value Added Services - M21 issue

From an architectural point of view utility

services are used by Smart Enterprise

Applications defined in D34.4

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 as the two families of services addressed by the project are complementary:

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,

providing a mapping with the context of the COMMIUS architecture. The mapping

5 http://www.commius.eu/




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, Octopart

7).

Attachment Manager

6 www.google.com/products

7 Octopart:_electronic parts, electronic components, datasheets search engine octopart.com/




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

interoperability [9]. In particular the iSURF Interoperability Service Utility provides a generic

8 http://www.iSURFProject.eu




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.




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. The following sections provide a description of these categories

4.1.1 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, virtual

enterprise management.

4.1.2 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, performance indicator

management.

4.1.3 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:

services for collecting run-time data from the products, services for monitoring the status of

products, services for collecting feedback from the users of the products.

4.1.4 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.

4.1.5 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.

4.1.6 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.

OAuth14

, XACML15

, SAML16

), frameworks and open software libraries/components (e.g.

OpenIAM17

, IAMSuite18

, VELO19

, JBoss Identity20

) that address such issues.

14

oauth.net/ 15

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml 16

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 17

http://www.openiam.com/ 18

http://sourceforge.net/projects/iam-suite/ 19

http://sourceforge.net/projects/velo/




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 User Requirements

(UR) collected in MSEE SP5 and matched them with the categories of Utility Services

described in the previous sections. Such requirements highlighted some fundamental

necessities:

1. UR3 - Tools to collect feedback on the usability/acceptance of the service from the

company/customers viewpoint

2. UR9 - Methodologies to measure the service performance and impact

3. UR11 - Single Sign On Service

In the first iteration of this document (M12 issue) we addressed only UR3 and UR11, while

UR9 was partially fulfilled by methodologies and tools provided as part of WP13. The

software prototype released by M18 as deliverable D33.3 was based on these specifications,

but with some significant enhancements introduced to meet new IT-related requirements

which emerged from system integration (SP4) and pilot implementation (SP6) tasks.

In this second and final iteration of the document we introduce two totally new services, both

targeted at UR9: the Virtual Enterprise Registry and the Performance Indicator Registry. The

Single Sign On service specifications have been extensively refactored in order to reflect the

current state of development, and to integrate the new services – to the point that it has been

renamed to Federated Single-Sign-On. Finally, the specifications of the Feedback

Management service were also updated.

All the Utility Services here specified will be implemented in the scope of deliverable D33.4

“FI Utility Services final prototype – M24 issue”.

4.2.1 Federated Single-Sign-On

Categories: Privacy and Security / Enterprise collaboration

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. In the context of the MSEE project, several

heterogeneous services and applications based on different technologies are accessed by the

final user, so the availability of a Single-Sign-On service is – as stated by User Requirement

11 (see above) – mandatory.

4.2.1.1 Introduction to Single-Sign-On

Single-Sign-On (SSO) provides a central authentication point for users of complex,

distributed, multi-tier web applications and services: users authenticate themselves once

and then are granted access to the entire environment, without repeating annoying

login operations. Furthermore, the overall security level of the environment is enhanced with

respect to application-based sign-on, as user credentials remain invisible to applications.

20

http://www.jboss.org/picketlink




Figure 7 - No SSO approach Vs SSO approach

There are two basic approaches at implementing SSO:

Centralized – All users, and their credentials, are registered in a single repository. This

approach is most effective when used to centralize the management of security

policies, e.g., within a single company. Each organization tends to keep an internal

centralized repository of users and groups, often provided by a LDAP21

server, in

order to control access to corporate resources.

Federative – Users and credentials are stored in local systems, or nodes, which are

grouped in a federation. Accessing one of the federated nodes grants also access to all

the others. This approach is particularly useful when different organizations want to

keep control over their own security policies.

As will be clarified in the following sections, in the MSEE context we apply a federative

approach, further enhanced in order to support MSEE-specific requirements.

4.2.1.2 Open technologies

Several open technologies and standards have been developed in the last years to address

authentication and authorization issues in distributes systems. Here we present two of them,

CAS and SAML, as they are the foundation on which the MSEE SSO solution is built.

21

Lightweight Directory Access Protocol




Central Authentication Service

Jasig’s Central Authentication Service (CAS) is an open source authentication system,

developed by Yale University22

, which manages all authentication requests by means of a

centralized server.

This solution is characterized by the following features:

Security

o Passwords are never transmitted to applications

o All tickets exchanged are encrypted

Simple integration and portability

o Several clients are available for free, including libraries for Java, Microsoft

.Net, PHP, Perl, Apache, Liferay

Open source codebase

The CAS authentication protocol is illustrated in Figure 8 and is briefly described here:

When the user first reaches a web application, she is redirected to the CAS login page

on a secure connection, where she enters her username and password.

When user credentials are submitted, CAS verifies them:

o If authentication fails, the user receives an error page.

o If authentication is successful, the user is redirected again to the originating

web application, this time carrying an authentication token; from this point on,

CAS maintains an active user session to “remember” that this user has been

authenticated.

The web application receives again the same user request, but this time with an

authentication token attached: before granting access, it validates the token with the

CAS service:

o If validation fails (the problem might be a session timeout, or a faked token),

the user is redirected to the CAS login page.

o If validation is successful, the user finally receives the requested resource.

When a different web application is accessed by the same user, the handshake

sequence is started again, but this time when the user reaches the CAS server she is

recognized as authenticated (she owns an active session on CAS), so she does not go

through the login form and is immediately directed back with a new authentication

token. From the user point of view, this second handshake is totally transparent.

Figure 8 - CAS authentication process

22

http://www.jasig.org/cas




SAML

SAML23

(Security Assertion Markup Language) is an open standard based on XML for the

exchange of information between different entities during authentication and authorization

operations. It was developed by SSTC (Security Services Technical Committee), which

belongs to OASIS (Organization for the Advancement of Structured Information Standards).

The purpose of SAML is to provide a standard XML syntax to represent security assertions

made by an IT system. The SAML standard allows interoperability between different

infrastructures / software / business partners, enabling the creation of an application platform

based on a single shared authentication process.

SAML supports the interaction between 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 her.

Identity Provider: also called SAML Authority or Asserting Party, keeps track of the

credentials of the Principal and provides the associated information. 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: also called Relying Party, represents the entity that receives the

information on a Principal released 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”. An assertion is the reply to a question made by

a Service Provider to a SAML Authority. 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 or not to

service a request from the connected Principal. Before delivering the identity assertion to the

Service Provider, the Identity Provider may in turn request some information from the

Principal - such as a user name and a password - in order to authenticate its identity. In

SAML, one Identity Provider may provide SAML assertions to many Service Providers.

Conversely, one Service Providers may rely on and trust assertions from many independent

Identity Providers.

4.2.1.3 Single-Sign-On in MSEE: leveraging the federative approach

Due to its composite and distributed nature, the MSEE system can really benefit from SSO.

However, it is also true that a plain and centralized SSO service, like the one offered by CAS,

can only partially meet MSEE requirements. These are the main issues that must be tackled:

1. Several different MSEE Platform instances may exist, each serving a specific

Manufacturing Service Ecosystem (MSE) and providing its own set of SSO-enabled

web applications and services.

2. MSEs are created from the collaboration of several Enterprises, but the same

Enterprise may be a member of more than one MSE. On top of that, multiple MSEs

may be part of a MSE Federation – i.e., an integrated SSO environment encompassing

several MSEE Platforms with all their users, applications and services.

3. Enterprises should be able to join any MSE, and consequently any MSE Federation,

without the need of sharing their private user’s data with external systems. E.g., it

should not be a requirement that corporate user credentials are copied on a central

authentication system’s database.

23

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

http://en.wikipedia.org/wiki/Access_control




4. Within any given MSE, Enterprises may also join (and leave) finer-grained groups

called Virtual Manufacturing Enterprise (VME). These groups exist in the context of

their parent MSE, but represent a security domain of

5. In this heterogeneous environment, SSO-enabled web applications and services must

rely on a common model for assessing authorization: a set of standard, security-related

attributes attached to each user by the SSO system, by which MSEE global roles and

which are the MSEs, VMEs and Enterprises the user is associated with.

In the above described scenario, the federative approach SSO is better suited. The SSO

functionality in MSEE will then be implemented by a Federated Single-Sign-On Utility

Service (Federated SSO).

4.2.1.4 Federated SSO global architecture

The MSEE Federated SSO service is designed on top of Jasig’s CAS. This was an easy

choice, as CAS is not only an open source, easily extendable, stable implementation of SSO,

but is also a de-facto industry standard.

Federated SSO introduces some new extension elements in the standard CAS architecture:

A distributed user database: seamless integration with a network of Enterprise-level

and/or MSE-level local databases. This addresses points #1, #2 and #3 of the issue list

in the previous section.

The notion of MSE, VME and Enterprise as properties of the authenticated user,

which in the MSEE context implies the integration with a network of local VME

registries (see the VER Utility Service described below). This addresses point #4.

An attribute release feature: a standard way of passing additional user information to

SSO clients. This addresses point #5.

An MSEE model for user attributes. This also addresses point #5.

This architecture in implemented in two modules: the Federated SSO Server and the Local

Security Authority (LSA) Service. The following figure illustrates the relationship between

these components and the VER Utility Service in the context of an MSEE Federation.

Figure 9 - Federated SSO overview

An MSEE Federation is composed by one or more independent Ecosystems (MSEs), each one

running one or more LSA (public) Services and exactly one VER (private) Service. A

common, centralized Federated SSO Server provides a unified login page and coordinates

user access to MSEE applications.




4.2.1.5 Federated SSO Server module

The Federated SSO Server is a regular CAS distribution, customized to delegate user

authentication and attribute release to a Local Security Authority Service chosen from a

registry. The target LSA Service is identified from the credentials presented by users (LsaId),

as demonstrated by the following sequence diagram.

Figure 10 - LSA delegation

The Federated SSO Server exposes a customizable login page to the users and, with the

exception of LSA delegation, behaves as described for the Central Authentication Service

(see Figure 8).

For each MSEE Federation there is one single deployment of the Server – some place of the

network where it is visible to each client and can reach every LSA Service. On each user

login request, the central Federated SSO Server extracts the LSA Service ID from user-

provided information, locates the LSA Service endpoint and invokes it on a secured channel,

forwarding the user’s credentials. The following diagram illustrates this protocol:

Figure 11 - SSO login sequence diagram




4.2.1.6 Local Security Authority Service module

All users in a MSEE Federation are registered with a Local Security Authority, which is an

abstraction for a user repository exposed as a service. Each MSE deploys at least one instance

of LSA Service, which is the default handler for authentication requests within the given

Ecosystem. Optionally, each MSE can have any number of additional federated LSA

instances, typically connected to some corporate system of an Enterprise which participates in

the same MSE. All LSA instances in a MSEE Federation are registered with the central

Federated SSO Server, identified by their unique LsaId.

The LSA module is a two-faced object. On one side it exposes a public endpoint for user

credential validation and user attribute release; on the other, it connects with some pluggable

user data repository.

The public endpoint is a RESTful service that accepts GET requests, issued on a

secure channel (HTTPS), with username and password parameters; the response body

is a SAML document stating the authenticated identity of the user and a set of

attributes as specified by the MSEE User Model (see section below).

The user repository connector is a plug-in module chosen from a library of off-the-

shelf (e.g., for LDAP or JDBC-based integration) or custom-built adapters. As the

LSA module is binary compatible with the AuthenticationManager architecture of

CAS, the entire library of connectors from the CAS standard distribution is available

for reuse.

In order to retrieve Virtual Enterprise membership information and populate the attribute set

of an authenticated user, the LSE module also interacts with the Virtual Enterprise Registry

(VER).

Figure 12 - LSA Service pluggable connector architecture




4.2.1.7 The MSEE User Model

The Federated SSO Utility Service provides an attributes release feature; i.e., the capability of

assigning a set of attributes to an user as the result of a successful login. In order for this

feature to be actually useful in a federation of connected systems, the format and the

semantics of the attribute set must conform to a common standard.

The MSEE User Model defines a generic set of user attributes and roles for use in the MSEE

environment. All LSA Service instances in a MSEE Federation are required to provide this set

of attributes in the SAML response that they send to the SSO Server on each successful login.

The SSO Server will eventually forward the same SAML response to the calling application.

ID of the user (login name)

MSEE_Name (1 occurrence): Screen name of the user

MSEE_Email (0-1 occurrence): Email address of the user

MSEE_Ecosys (1 occurrence): Ecosystem (MSE) the LSA belongs to

MSEE_Organization (0-* occurrences): List of Enterprises the user belongs to

MSEE_VirtualOrganization (0-* occurrences): List of Virtual Enterprises (VMEs) the

user is indirectly member of

Role (0-* occurrences) - List of MSEE roles that the user has in the scope of the LSA

The list of MSEE roles is an open domain, as additional roles may be easily integrated as

needed. At the time of this writing, the current set is the following:

MSEE_Administrator – super-user enabled to system administration operations

MSEE_Business_User – user with business-related responsibilities

MSEE_IT_User – user with IT-related responsibilities

MSEE_User – generic user who belongs to one (or more) Enterprise

Note that the roles are assigned to users by the Local Security Authority where they are

registered, but have a scope encompassing the entire MSEE Federation. It's up to application

and services to apply the correct profiling - e.g., typically the MSEE_Administrator role will

be honored only within the same Ecosystem.

Special roles and / or extended attributes may also be defined by each LSA, targeted to some

specific application; they will be ignored by "standard" MSEE software.




The following is an example of SAML response issued by an LSA Service:

<?xml version="1.0" encoding="UTF-8"?>

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"

Version="2.0"

IssueInstant="2012-12-27T16:20:22.664Z">

<saml2:Issuer>http://lsa.mydomain.com/lsaservice</saml2:Issuer>

<saml2:Subject>

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

NameQualifier="MSEE">myuserid</saml2:NameID>

</saml2:Subject>

<saml2:Conditions>

<saml2:OneTimeUse />

</saml2:Conditions>

<saml2:AttributeStatement>

<saml2:Attribute Name="MSEE_Name">

<saml2:AttributeValue xmlns:xs=http://www.w3.org/2001/XMLSchema

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:type="xs:string">John Doe</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="MSEE_Email">



xsi:type="xs:string">[email protected]</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="MSEE_Ecosys">



xsi:type="xs:string">MSEE Instance One</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="MSEE_Organization">



xsi:type="xs:string">Acme Inc.</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="MSEE_VirtualOrganization">



xsi:type="xs:string">Acme Inc.</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="Role">



xsi:type="xs:string">MSEE_IT_User</saml2:AttributeValue>



xsi:type="xs:string">OTHER_ROLE</saml2:AttributeValue>

</saml2:Attribute>

</saml2:Attribute>

</saml2:AttributeStatement>

</saml2:Assertion>

http://www.w3.org/2001/XMLSchema

http://www.w3.org/2001/XMLSchema-instance
















4.2.2 Virtual Enterprise Registry

Categories: Trust management / Enterprise collaboration

Virtual Enterprises are a core concept in MSEE, but are not limited to the domain of

manufacturing. As defined in literature, a Virtual Enterprise (VE) “… represents a temporary

alliance of enterprises that come together to share skills or core competencies and

resources in order to better respond to business opportunities, and whose collaboration

is supported by computer networks”. (Camarinha-Matos, Afsarmanesh, Galeano and

Molina, 2008) [17]. In the context of the MSEE project, members of a Manufacturing Service

Ecosystem (MSE) can set up a Virtual Manufacturing Enterprise (VME) to face and tackle

business opportunities. Once set, VMEs implement a Service Life Cycle process [18].

Several reasons exist for making the existence of a VME explicit within the parent MSE:

separation of concerns, confidentiality of information, etc. Operating and monitoring a

Service means, for example, that the relevant Performance Indicators should be accessible to

VME stakeholders but not shared with the entire MSE. However, MSEE applications like the

Innovation Ecosystem Platform (IEP, WP26) and the Service Life Cycle Management

Toolbox (SLMToolbox, WP15) have no built-in support for VME management. This stems

from the fact that IEP, as its name implies, is MSE-oriented, while the SLMToolbox is an

MSE-level application used to design new VMEs. Moreover, VME entities are, like Users,

Enterprises and Ecosystems, a cross-application notion; as such they should be managed at a

higher level.

FI Utility Services are the proper context for addressing these requirements. Users,

Enterprises and Ecosystems are already managed by the Federated Single-Sign-On Utility

Service (Federated SSO). The Federated SSO is a cross-MSE service which supports the

federation of multiple ecosystems. Here we introduce a new Utility Service, which will

support the notion of VME inside each single MSE: the Virtual Enterprise Registry. The

figure below describes the relationship between these components:

Figure 13 - Virtual Enterprise Registry positioning in MSEE




The Virtual Enterprise Registry (VER) is an Utility Service addressing the needs described

above. Given its extreme simplicity, it is not meant to be used standalone, but rather as an

enabler, a building block of more complex services. At the same time, unlike FI-WARE

Generic Enablers, VER is targeted at a specific, although vast, usage area, which is Virtual

Enterprise Environments [15]. Although stemming from MSEE requirements, the scope of

VER is not limited to the MSEE project: it is a commodity service which can be exploited in

any environment, as it contains no MSEE-specific functionality.

4.2.2.1 Features of the service

The main features of Virtual Enterprises Registry are the following:

The scope of a registry instance is a specific Ecosystem

Users of the service are subject to authentication & authorization

Authorized users can create a new Virtual Enterprise entry

A Virtual Enterprise entry has a name and a description; the name is also an identifier,

so it is unique in the scope of the registry

A Virtual Enterprise entry has a set of members, consisting of 0-N Enterprise names

Enterprise names are arbitrary, but are typically a reference to an existing organization

in the Ecosystem

The same Enterprise name can appear under more than one Virtual Enterprise

Authorized users can modify an existing Virtual Enterprise entry, editing its attributes

and its member set

Authorized user can delete an existing Virtual Enterprise entry, removing it from the

system.

Some non-functional features are also relevant:

All functionalities are exposed through web API (VER plays the role of back-end

service)

Web API follow the REST standard for easier integration and better performance

Users are authenticated through the Federated SSO Utility Service

Users are authorized on the basis of attributes released by the Federated SSO Utility

Service

A special channel, where authentication and authorization are handled by an internal

mechanism, is reserved for integration with the Federated SSO (more specifically,

with its LSA Service module): the Federated SSO cannot obviously be used to

authenticate itself.

Small IT footprint: can be installed on non-dedicated commodity hardware

4.2.2.2 Implementation of the service

The VER is implemented as an autonomous, headless service, exposing its functionality only

through a RESTful API. The implementation is Java-based, leveraging on the JAX-RS

specification. A single instance of the VER service is installed for each MSE, as in the case of

the Innovation Ecosystem Platform – typically, IEP and VER, which share the same

technology, will be deployed on the same application server.

Access to the API is secured through the Federated SSO Utility Service. This means that the

web endpoint uses the extended CAS (Central Authentication Service) client provided by the

Federated SSO package. It also means that front-end applications that consume VER services

must also integrate with Federated SSO, and must be configured to play the “proxy” role in

the single-sing-on protocol24

. To call any API operation, the caller must be an authenticated

24

See the CAS documentation for additional details: http://www.jasig.org/cas/proxy-authentication, https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough, https://wiki.jasig.org/download/attachments/729/cas_proxy protocol pdf

http://www.jasig.org/cas/proxy-authentication

https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough

https://wiki.jasig.org/download/attachments/729/cas_proxy_protocol.pdf‎




user belonging to the same MSE. In the case of a write operation, the user must also have a

special global role25

named “MSEE_Administrator”.

The operations exposed by the API are the following. Note that this is not the actual

specification of the API, which follows REST conventions (HTTP verb, URI template and

response body format must be specified) – this will be detailed in the D33.4 prototype release.

Name GetVEList

Input

Output List of existing VEs

Result

Restrictions Caller must be authenticated, and must belong to the same Ecosystem

Name GetVE

Input Name of VE

Output A data structure representing the given VE and all its Enterprise

members; no output if the given VE is not registered

Result


Name GetEnterpriseList

Input

Output A data structure representing the list of distinct Enterprises which are

members of any registered VE; each Enterprise is represented by its

name

Result


Name GetEnterpriseMemberships

Input Name of Enterprise

Output A data structure representing the list of VEs of which the given

Enterprise is member; each VE is represented by its name

Result


25

Global roles are a special set of MSEE-specific role names that are released by the Federated SSO service as part of the authentication of a user.




Name GetEnterpriseMembershipsDirect

Input Name of Enterprise

Sid (identifier of the calling system - must be registered in VER)

Pwd (password of the calling system - must match with VER

registration)

Output A data structure representing the list of VEs of which the given

Enterprise is member; each VE is represented by its name

Result

Restrictions This call is not protected by SSO - see VER prototype documentation for

details

Name PutVE

Input Name of VE (must be unique)

Short description of VE (optional)

Long description of VE (optional)

Output

Result A new VE entity with the given attributes is added to the registry

Restrictions Caller must be authenticated, must belong to the same Ecosystem and

must have MSEE_Administrator role

Name DeleteVE

Input Name of VE (must match a registered VE)

Output

Result The given VE is removed from the registry



Name PostVE


Short description of VE (optional)

Long description of VE (optional)

Output

Result The given VE is updated



Name PutEnterpriseMembership


Name of Enterprise (must be unique in the scope of the given VE)

Output

Result The given Enterprise is added to the member list of the given VE






Name DeleteEnterpriseMembership


Name of Enterprise (must match an Enterprise which is member of

the given VE)

Output

Result The given Enterprise is removed from the member list of the given VE



Name DeleteAllEnterpriseMemberships


Output

Result The member list of the given VE is cleared






4.2.3 Performance Indicator Registry

Categories: Data management / Product-related services / Enterprise interoperability

Key Performance Indicators (KPI) are a frequent topic in literature. Some relevant examples

can be quoted here:

“Process outputs determine the KPIs … of an organization, and as far as possible the KPIs

should be standardized across the processes.”

(Rosemann & vom Brocke, 2010).

“The strategy is linked to processes through the KPIs. They determine the process’s

key-performance and strategically important factors, such as for example customer

satisfaction. By acting according to the processes, organization carries out its strategy.”

(Laamanen, 2001)

KPIs represent the metrics for evaluating the performance of service ecosystems (MSEs) and

of operational processes (within VMEs). Several work packages are involved in this matter,

most notably WP13 “Services Performance Assessment & Governance”, WP15 “Service

Lifecycle Management Tools”, WP25 ”Service-based Innovation Ecosystems” and WP26

“Innovation Ecosystem Platform”. WP15 considers the activity of KPI definition as an

integral part of Business Service Modeling, and aims at providing specific tools in the SLM

Toolbox (Task T15.4). On the opposite side, WP26 is concerned with KPI monitoring – i.e.,

the IEP should offer to MSE and VME users a live view on KPI data and KPI management

functionality.

This scenario, to be complete, needs a bridge across the gap between KPI modeling (SLM

Toolbox) and KPI management (IEP). More specifically, a space within the MSE where KPI

definitions can be published, and where KPI data can be collected. In the context of FI Utility

Services we then introduce a new service, which will offer the required support: the

Performance Indicator Registry. The figure below describes the positioning of this service

within MSEE:

Figure 14 - Performance Indicator Registry positioning in MSEE

The Performance Indicator Registry (PIR) provides the base capabilities for creating and

sharing KPI models, KPI definitions and KPI historical values, in well-defined scopes like

that of a single Enterprise, of a specific Virtual Enterprise (VME) or of an entire Ecosystem

(MSE). To manage KPI scopes, it depends on functionality provided by the VER Utility

Service (see the above section). Like VER, the PIR is an enabler, but with a more focused

usage area. In the MSEE project, it will be exploited as the foundation of KPI authoring (SLM




Toolbox) and management (IEP) tools. As the VER, it is designed on top of MSEE

requirements, but is not MSEE-specific.

4.2.3.1 Features of the service

The main features exposed by the Performance Indicator Registry are the following:

Create and manage PI models

Create and manage collections of individual PI definitions conforming to a registered

common model

Define a visibility scope for each PI collection, choosing from public (within the

MSE), a specific Virtual Enterprise (VME), a specific Enterprise, private (the user

who owns the collection)

Create and manage individual PI definitions, each with its own set of attributes as per

the PI model associated to the collection they belong to

For each PI definition, define how “facts” (measurement instances) are collected: time

frequency and source (retrieved from a publishing service, manual input, input

restricted to PI collection owner)

For each PI definition, optionally define a data schema for facts (see next point)

For each PI definition, collect an historical series of fact issues; these may be single

measurement values or, if a data schema is defined, cubes (a set of values aggregated

along dimensions); each fact issue is related to a given period of time, as defined by

the “fact frequency” attribute

Query the registry for facts related to a given PI, specifying filtering rules that may

apply to time and, when a data schema is defined, to attributes of individual facts

Some non-functional features are also of interest:

All functionalities are exposed through web API (PIR plays the role of back-end

service)

Web API follow the REST standard for easier integration and better performance

Users are authenticated through the Federated SSO Utility Service

Users are authorized on the basis of attributes released by the Federated SSO Utility

Service

A special channel, where authentication and authorization are handled by an internal

mechanism, is reserved for massive import of PI facts.

4.2.3.2 Implementation of the service

The PIR is implemented as an autonomous, headless service, exposing its functionality only

through a RESTful API. The implementation is Java-based, leveraging on the JAX-RS

specification. An single instance of the PIR service is installed for each MSE, as in the case of

the Innovation Ecosystem Platform and of the VER – typically, IEP, VER and PIR will be

deployed on the same application server.




In the figure below, the logical data model of the service is illustrated:

Figure 15 - PIR logical data model

Access to the API is secured through the Federated SSO Utility Service. See the

implementation notes of the VER Utility Service for information on this topic, as the same

applies here. To call any API operation, the caller must be an authenticated user belonging to

the same MSE. Some operations have more strict authorization rules, which depend on some

special global roles26

named “MSEE_Administrator” and “MSEE_Business_User” and on the

scope of the resources that are accessed: see the description of each single operation.

The operations exposed by the API are the following. Note that this is not the actual

specification of the API, which follows REST conventions (HTTP verb, URI template and

response body format must be specified) – this will be detailed in the D33.4 prototype release.

Performance Indicator Model Management

Name GetModelList

Input

Output A data structure representing the list of Performance Indicator Models

(PMI) in the registry; each PIM is represented by name, description and

list of attributes (attributes values are not expanded: use

GetModelAttributeValueList)

Result

Restrictions Caller:

Is authenticated

Belongs to same Ecosystem (MSE)

26

Global roles are a special set of MSEE-specific role names that are released by the Federated SSO service as part of the authentication of a user.




Name GetModel

Input Name

Output A data structure representing the given PMI (see GetModelList); no

output if the given PMI is not registered

Result


Is authenticated


Name PutModel

Input Name (must be unique)

Description (optional)

Output

Result A new PIM with the given name and description is registered


Is authenticated


Has “MSEE_Administrator” role

Name PostModel

Input Name (must match a registered PIM)

Description (optional: if omitted, the original value is retained)

Output

Result The given PIM is updated with the new description


Is authenticated



Name DeleteModel


Output

Result The given PIM is removed from the registry


Is authenticated



Name GetModelAttribute

Input Name of PIM

Name of PIM Attribute

Output A data structure representing the given PIM Attribute, not expanded

(use GetModelAttributeValueList); no output if the given PIM attribute

is not registered

Result


Is authenticated





Name PutModelAttribute

Input Name of Performance Indicator Model (must match a registered PIM)

Name of PIM Attribute (must be unique in the scope of the PIM)

Description of PIM Attribute (optional)

Mandatory (optional, legal values: 0, 1; if missing the default is 0)

Output

Result A new PIM Attribute with the given description and flag is added to the

given PIM


Is authenticated



Name PostModelAttribute

Input Name of PIM (must match a registered PIM)

Name of PIM Attribute (must match an Attribute of the given PIM)


Mandatory Value (optional, legal values: 0, 1; if omitted the original

value is retained)

Output

Result The given PIM Attribute is updated with the given description and flag


Is authenticated



Name DeleteModelAttribute


Name of PIM Attribute (must match a PIM Attribute of the given PIM)

Output

Result The given PIM Attribute is removed from the registry


Is authenticated



Name DeleteAllModelAttributes


Output

Result All the Attributes of the given PIM are removed from the registry


Is authenticated






Name GetModelAttributeValueList

Input Name of PIM


Output A data structure representing the list of legal values for the given PIM

Attribute; no output if the given PIM attribute is not registered

Result


Is authenticated


Name GetModelAttributeValue

Input Name of PIM


Value

Output The same value provided in input; no output if the given PIM Attribute

is not registered or if the given value is not in the value list of the PIM

Attribute (this call is just a check)

Result


Is authenticated


Name PutModelAttributeValue



Value (must be unique in the scope of the given PIM Attribute)

Output

Result The given value is added to the list of legal values for the given PIM

Attribute


Is authenticated



Name DeleteModelAttributeValue



Value (must match an item of the legal value list of the given PIM

Attribute)

Output

Result The given value is removed from the list of legal values for the given

PIM Attribute


Is authenticated






Name DeleteAllModelAttributeValues



Output

Result The list of legal values for the given PIM Attribute is cleared


Is authenticated



Performance Indicator Collection Management

Name GetCollectionList

Input

Output A data structure representing all the Performance Indicator Collections

(PIC) in the registry; each item is represented by its Id, Name,

Description, Model, Owner and Scope; collection items are not

expanded (use GetIndicatorList)

Result


Is authenticated


Data:

Item is listed if ANY of the following is true:

Caller has “MSEE_Administrator” role

PIC.Scope = Public

PIC.Scope = VE:<ve_name> AND Caller is member of

<ve_name>

PIC.Scope = Enterprise:<enterprise_name> AND Caller

belongs to <enterprise_name>

PIC.Scope = Private AND Caller = PIC.Owner

Name GetCollection

Input Id

Output A data structure representing the given PIC (see GetCollectionList); no

output if the given PIC is not registered

Result


Is authenticated


Data:

Item is accessible if ANY of the following is true:

Caller has “MSEE_Administrator” role

PIC.Scope = Public

PIC.Scope = VE:<ve_name> AND Caller is member of

<ve_name>

PIC.Scope = Enterprise:<enterprise_name> AND Caller

belongs to <enterprise_name>

PIC.Scope = Private AND Caller = PIC.Owner




Name PutCollection

Input Name


Model (optional: reference to a registered PIM)

Scope

- legal values:

o Public (globally visible)

o VE:< ve_name> (visible to members of the given Virtual

Enterprise)

o Enterprise:<enterprise_name> (visible to members of the

given Enterprise)

o Private (visible to the owner)

Output The UUID assigned to the new PIC by the system

Result A new empty PIC is registered with auto-assigned Id (UUID) and

Owner (Id of the authenticated caller), and with the given Description /

PIM / Scope


Is authenticated


Has “MSEE_Administrator” OR “MSEE_Business_User” role

Data:

Scope=VE:<ve_name> is legal only if Caller is member of

<ve_name> OR has “MSEE_Administrator” role

Scope:Enterprise:<enterprise_name> is legal only if Caller

belongs to <enterprise_name> OR has “MSEE_Administrator”

role

Name PostCollection

Input Id (must match a registered PIC)

Name (optional: if omitted, the original value is retained)


Scope (optional: if omitted, the original value is retained - see

PutCollection for legal values)

Output

Result The given PIC is updated with the given values; note that the Model

value cannot be changed after a PIC is created


Is authenticated



AND is Owner




Name DeleteCollection


Output

Result The given PIC is removed from the registry


Is authenticated



AND is Owner

Performance Indicator Management

Name GetIndicatorList

Input Id of PIC container

Output A data structure representing the list of Performance Indicators

contained in the PIC; each PI is represented by a reduced attribute set:

Id, Name, Description, Frequency, Value Provider, Restricted Fact

Publishing; no output if the given PIC is not registered

Result

Restrictions Inherited from GetCollection of the PIC container

Name GetIndicator

Input Id

Output A data structure representing the given Performance Indicator,

represented by the full attribute set: Id, Container Id, Name,

Description, Notes, Fact Frequency, Fact Provider, Fact Publishing

Restricted, Fact Dimension Schema + a name-value map for Attributes

in the Performance Indicator Model declared by the PIC container; no

output if the given PI is not registered

Result





Name PutIndicator

Input Id of PIC (must match a registered PIC)

Name


Notes (optional)

Fact Frequency

- legal values:

o Year

o Semester

o Quarter

o Month

o Week

o Day

o Spot

Fact Provider (optional: HTTP/HTTPS URL of an online REST service

which, when called with a GET operation, will return a set of „most

current“ facts as the reponse body)

Fact Publishing Restricted (legal values: 0, 1; if 1, only the Owner of

the PIC container can add / delete Facts)

Fact Dimension Schema (optional: array of 10 strings, each declaring

the name of a dimension which can be used to create aggregations

on Performance Indicator Facts)

for each Attribute in the PIM declared by the PIC container:

o attribute value (optional if Attribute.Mandatory = 0)

Output The UUID assigned to the new PI by the system

Result A new Performance Indicator with the given data is registered

Restrictions Inherited from PostCollection of the PIC container

Name PostIndicator

Input Id (must match a registered PI)

Name (optional: if omitted, the original value is retained)


Notes (optional: if omitted, the original value is retained)

Fact Provider (optional: if omitted, the original value is retained)

Fact Publishing Restricted (optional: if omitted, the original value is

retained – see PutIndicator for legal values)

for each Attribute in the PIM declared by the PIC container:

o attribute value (optional: if omitted, the original value is

retained)

Output

Result The given Performance Indicator is updated with the new data; note that

Fact Frequency and Fact Dimension Schema cannot be changed after

the PI is first registered





Name PostIndicatorFactRequest


Output

Result The Fact Provider is queried for a set of “most current” facts

Restrictions Inherited from PostCollection of the PIC container; in addition: if the

Caller does not have “MSEE_Administrator” role AND PIC.Fact

Publishing Restricted = 1, then PIC.Owner = Caller is required

The PI must also have the following attributes:

Fact Provider must contain the URL of the callable service

Fact Publishing Restricted must have the value “0”

Name DeleteIndicator


Output

Result The given Performance Indicator is removed from the registry


Name DeleteAllIndicators


Output

Result The contents (PIs) of the given PIC are removed from the registry


Performance Indicator Fact Management

Name GetFactList

Input Id of Indicator (must match a registered PI)

(search parameters, limits, etc. – see the PIR prototype

documentation for details)

Output A data structure representing the PIFs matching the query; each PIF is

represented by Id, Time In, Publisher, Measurement Value,

Measurement Date, Reference Date, Virtual Enterprise, Enterprise,

Year, Semester, Quarter, Month, Week, Day + a name-value map of

Dimension References as per the Fact Dimension Schema declared in

the PI container.

Note that Time In and Publisher are values assigned by the system

(timestamp and identity of PutFact caller, respectively); Year, Semester,

Quarter, Month, Week, Day are calculated by the system on the basis of

Reference Date and PI.Fact Frequency.

Result





Name GetFactCount


(search parameters – see the PIR prototype documentation for

details)

Output An integer number representing the total count of PIFs matching the

query

Result


Name GetFact

Input Id of Fact

Output A data structure representing the given PIF (see GetFactList)

Result


Name PutFact


Measurement Value (decimal value: precision 19, scale 6)

Measurement Date (yyyymmdd)

Reference Date (only if PI.Fact Frequency <> Spot, yyyymmdd)

Virtual Enterprise (optional, if provided must match with one of the

Virtual Enterprises the caller is member of)

Enterprise (optional, if provided must match with one of the

Enterprises the caller belongs)

Dimension References (array of 10 strings, each providing a value for

the corresponding dimension declared by PI.Fact Dimension Schema;

values can be anything, but array slots must match with the schema)

Output The UUID assigned to the new PIF by the system

Result A new Performance Indicator Fact with the given data is registered




Name PutFactStream


Sid (identifies the calling system, which must be registered in PIR)

Pwd (password of Sid, must match with PIR registration)

(an XML-serialized stream of PIF data - see the PIR prototype

documentation for details)

Output

Result The uploaded Performance Indicator Facts are registered

Restrictions This call is not protected by SSO - see the PIR prototype documentation

for details




Name DeleteFact

Input Id of Fact (must match a registered PIF)

Output

Result The given Performance Indicator Fact is removed from the registry




Name DeleteAllFacts


Output

Result All the Performance Indicator Facts related to the given PI are removed

from the registry







4.2.4 Feedback Management Service

Category: Product-related services

In today’s highly connected world, being close to the customers, understanding their needs

and especially responding timely to their needs, requests and comments is of the most

importance for enterprises in order to stay in the market. For manufacturing enterprises in

particular, knowing the “pulse” of the market and customers is important for shaping

strategies both for existing and new products and services. Known as feedback management,

it is one of the most important means to gather valuable information from customers and from

other stakeholders. With the advance of ICT technologies, in particular Web2.0, Social

Media, the feedback collection become even more important. To support manufacturing

enterprises in disseminating information about their products and services, collecting

feedback about them and reacting through a proper engagement strategy, MSEE is developing

a feedback management as one of the core utility services in SP3. As described in the

corresponding factsheet for feedback management service of D33.3, from an architectural

point of view, this service (branded as dacodi) is composed of three modules:

Role Management –this module provides role management functionality for those that

are using the Feedback Management Service. Two roles are envisioned and supported

for the moment i.e. system user and administrator. A user is allowed to use the

functionality of the service. An administrator has additional rights being able to

administrate (add, delete, etc.) user accounts and has an overview about the health of

the service.

Publication –this module is responsible for the publication of content into channels.

The Publication module is also responsible for adaptation of content to be published to

the specific requirements of the different channels. The adaption is made on the base

of the channel capabilities, e.g. shortened messages are posted to microblog platform,

such as twitter. To achieve scalability the Feedback Management Service uses a

message-oriented architecture to implement an asynchronous publication process. For

this purpose the Advanced Message Queuing Protocol, short AMQP27

is used.

Feedback Collection –this module is responsible for the collection of various

feedbacks across multiple channels.Feedback can have different forms. It can either be

textual (comments, replies, etc.), a certain amount of positive (like, +1, thumbs up,

etc.) or negative feedback (thumbs down, bury, down vote, etc.), or some other

measurement of a user’s response to a published item. The Feedback Management

Service can collect all these different types of feedback using various polling

strategies. The Feedback Collection module is part of a larger module, called

Engagement Module that includes also support for interaction and engagement with

users via the Interaction Component.

The architecture of the Feedback Management Service is available in Figure 16.

27

http://amqp.org/

http://amqp.org/




Figure 16 – Feedback Management Service Architecture

The Feedback Management Service and its components are provided as a RESTful service.

We also provide a Front-end Web application UI (dacodi UI) that enables a user friendly

access to the functionality offered by the Feedback Management Service including

publication, feedback collection and role management.

The public instance of the service is installed and available to be used at:

https://dacodi.sti2.at/api/. As part of the second version of the feedback management service,

we are focusing on two important aspects:

1. Improving the stability of the 1st release of the service

2. Extending the functionality of the 1st release of the service by:

a. Incorporating sentiment analysis on received feedback

b. Providing an integrated view on the feedback

To implement the sentiment analysis functionality in the feedback management service we are

planning to use the Viralheat service28

. The feedback management servicewill call the

Viralheat service for sentiment detection of online posts related to manufacturing products

and services of an enterprise. Feedback, coming in multiple forms, will be collected from the

supported channels. It can either be textual (comments, replies, etc.), a certain amount of

positive (like, +1, thumbs up, etc.) or negative feedback (thumbs down, bury, down vote,

etc.), or some other measurement of a user’s response to a published item. In addition to the

first prototype, the feedback management service will support sentiment analysis.

A second new feature of the updated feedback management service is to provide an integrated

view on the feedback. More precisely, we will support integrated views over all posts and

channels that are related to one campaign of advertising a service, idea, etc. In the first

version of the feedback management service, feedback was collected and visualized at a

micro level i.e. at the level of each channel and post. The integrated feedback feature of the

updated service will enable visualization and analysis of the feedback at more macro level,

28

https://www.viralheat.com/solutions/sentiment-analysis/

https://dacodi.sti2.at/api/

https://www.viralheat.com/solutions/sentiment-analysis/




e.g. for the same post over multiple channels an integrated feedback will be available e.g.

likes on Facebook, retweets on Twitter, etc.

We list below the updated API of the feedback management service.

4.2.4.1 Authentications API

The Authentications API can be used to return all Authentications for the authenticated user.

More details about the Authentications API including examples on how to use it are available

at: https://dacodi.sti2.at/api/v1/authentications.html. The API includes the following methods:

GET /api/authentications

Returns all Authentications for the authenticated user

Supported Formats: json

Parameters:

GET /api/authentications/:id

Returns a single Authentication for the authenticated user


Parameters:

4.2.4.2 Channels API

The Channels API can be used to return all Channels for the authenticated user. More details

about the Channels API including examples on how to use it are available at:

https://dacodi.sti2.at/api/v1/channels/index.html. The API includes the following methods:

GET /api/channels

Returns all Channels for the authenticated user


Parameters:

GET /api/authentications/:id

Returns a single Channel for the authenticated user


Parameters:

4.2.4.3 Common Weaver Models

The Common weaver models API can be used to return all common weaver models for the

authenticated user. A Common Weaver Model (CVM) is the common representation of an

information item from which the transformation to the different channels can happen.

Parameter name Description

Id (optional) Value: Must be a number







https://dacodi.sti2.at/api/v1/authentications.html

https://dacodi.sti2.at/api/v1/channels/index.html




More details about the Common Weaver Models API including examples on how to use it are

available at: https://sesa-dev.seekda.com/api/v1/common_weaver_models.html. . The API

includes the following methods:

GET /api/common_weaver_models


Parameters:

4.2.4.4 Feedbacks API

The Feedbacks API can be used to return all Feedbacks received for the current user. More

details about the Feedbacks API including examples on how to use it are available at:

https://sesa-dev.seekda.com/api/v1/feedbacks.html. The API includes the following methods:

GET /api/feedbacks

Returns all Feedbacks of the current user


Parameters:

GET /api/feedbacks/:id

Retrieves a single feedback


Parameters:

4.2.4.5 Images API

The Images API can be used to handle images, namely to publish into and to retrieve them

various channels. More details about the Images API including examples on how to use it are

available at: https://dacodi.sti2.at/api/v1/images.html. The API includes the following

methods:

GET /api/images/:id

Retrieves a single Image


Parameters:

POST /api/images

Publishes an Image


Parameters:


- -








- -

https://sesa-dev.seekda.com/api/v1/common_weaver_models.html

https://sesa-dev.seekda.com/api/v1/feedbacks.html

https://dacodi.sti2.at/api/v1/images.html




4.2.4.6 Links API

The Links API can be used to retrieve links that are published by the authenticated user. More

details about the Links API including examples on how to use it are available at:

https://dacodi.sti2.at/api/v1/links.html. The API includes the following methods:

GET /api/links/:id

Retrieves a single Link


Parameters:

4.2.4.7 Microblogs posts API

The Microblog posts API can be used to retrieve microblog post for the authenticated user.

More details about the Microblogs posts API including examples on how to use it are

available at: https://dacodi.sti2.at/api/v1/microblog_posts.html. The API includes the

following methods:

GET /api/microblog_posts/:id

Returns a single MicroblogPost for the authenticated user


Parameters:

4.2.4.8 Organizations API

The Organizations API can be used to retrieve the organizations of the authenticated user.

More details available at: https://dacodi.sti2.at/api/v1/organizations.html. The API includes

the following methods:

GET /api/organizations

Returns all Organizations that the user is associated with


Parameters:

4.2.4.9 Publications API

The Publications API is a core API of the Feedback Management Service that can be used to

retrieve publications made by the authenticated user. More details about the Publications API

including examples on how to use it are available at:

https://dacodi.sti2.at/api/v1/publications.html. The API includes the following methods:

GET /api/publications

Returns all Publications for the authenticated user


Parameters:






- -


https://dacodi.sti2.at/api/v1/links.html

https://dacodi.sti2.at/api/v1/microblog_posts.html

https://dacodi.sti2.at/api/v1/publications.html




GET /api/publications/:id

Retrieves a single Publication


Parameters:

GET /api/publications/:id-status

Retrieves the Publication's status


Parameters:

4.2.4.10 Remotes API

Information items that have been published - either via our system, via the platform directly,

or via 3rd party apps - are called Remotes (remote information items).

The Remmotes API can be used to retrieve all remotes of the authenticated user. More details

about the Remotes API including examples on how to use it are available at:

https://dacodi.sti2.at/api/v1/remotes.html. The API includes the following methods:

GET /api/remotes

Retrieves all Remotes of the current user


Parameters:

GET /api/remotes/:id

Retrieves a single Remote


Parameters:

4.2.4.11 Token Authentications

For authentication the feedback management service uses tokens. More details about the

Tokesn Authentication API including examples on how to use it are available at:

https://dacodi.sti2.at/api/v1/token_authentications.html. The API includes the following

methods:

GET /api/token_authentications/:id

Retrieves the users authentication token


Parameters:

- -






- -



https://dacodi.sti2.at/api/v1/remotes.html

https://dacodi.sti2.at/api/v1/token_authentications.html




POST /api/token_authentications

Creates a new token for the currently logged in user, or the user that is authorized via

the given parameters user and user


Parameters:

DELETE /api/token_authentications

Destroys the authentication token of the currently logged in user


4.2.4.12 Videos API

The Videos API can be used to handle videos namely to publish into and to retrieve them

various channels. More details about the Video API including examples on how to use it are

available at: https://dacodi.sti2.at/api/v1/videos. html. The API includes the following

methods:

GET /api/videos/:id

Retrieves a single Video


Parameters:

POST /api/videos

Publishes a Video


Parameters:




- -




- -

http://email/

http://password/

https://dacodi.sti2.at/api/v1/videos.%20html




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 four concrete utility services that are

required by the MSEE use cases.

The first service is Federated Single-Sign-On, which is considered as a basic means to control

user access to services and applications in vastly distributes systems like MSEE Federations,

where different autonomous organizations participate.

The second is Virtual Enterprise Registry, enabling Virtual Enterprise (VME) management

within each MSEE Ecosystem (MSE). This service also extends the capabilities of Federated

Single-Sing-On, introducing the concept of Virtual Enterprise membership.

The third is Performance Indicator Registry, a space within the MSEE Ecosystem where

Performance Indicators definitions can be published, and where Performance Indicator data

can be collected.

The fourth is Feedback Management, which enables enterprises to collect comments and

feedback from customers and partners for improving their products and services.

These specifications will lead to the prototypical implementations released as part of

deliverable D33.4 by month 24.




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.2 - Detailed Specifications of Next Generation ESA value-added

services

[5] MSEE D32.2 - 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.2 – 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.

[15] BIVEE Project website, http://www.bivee.eu/, last accessed 15/06/2013.

[16] FI-WARE Registry GE Open Specifications, FI-WARE web site, http://forge.fi-

ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Ap

ps.Registry, last accessed 15/06/2013.

[17] Camarinha-Matos, Afsarmanesh, Galeano, Molina, “Collaborative networked

organisations - Concepts and practice in manufacturing enterprises”, Elsevier, 2008

[18] MSEE Deliverable D25.1 – State of the Art of collaborative networks for service-

based innovation ecosystems

http://www.bivee.eu/

http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Apps.Registry



d33.2 fi utility services specifications and architecture...

Documents