Patrick Sitek, Sergio Gusmeroli

Marco Conte, Kim Jansson, Iris Karvonen (Editors)

The COIN Book
Enterprise Collaboration and Interoperability
Bibliografische Information der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der
Deutschen Nationalbibliografie; detaillierte bibliografische Da-
ten sind im Internet ber http://dnb.ddb.de abrufbar.
Vertrieb:
1. Auflage 2011
Verlagsgruppe Mainz GmbH Aachen
Ssterfeldstr. 83, 52072 Aachen
Tel. 0241/87 34 34
Fax 0241/875577
www.Verlag-Mainz.de
Herstellung:
Druck und Verlagshaus Mainz GmbH Aachen
Ssterfeldstrae 83
52072 Aachen
Tel. 0241/873434
Fax 0241/875577
www.DruckereiMainz.de
www.Druckservice-Aachen.de
Satz: nach Druckvorlage des Autors
Umschlaggestaltung: Druckerei Mainz
printed in Germany
Das Werk einschlielich seiner Teile ist urheberrechtlich geschtzt. Jede Verwendung ist ohne die
Zustimmung des Herausgebers auerhalb der engen Grenzen des Urhebergesetzes unzulssig und
strafbar. Das gilt insbesondere fr Vervielfltigungen, bersetzungen, Mikroverfilmungen und die
Einspeicherung und Verarbeitung in elektronischen Systemen.
Patrick Sitek, Sergio Gusmeroli, Marco Conte, Kim Jansson, Iris Karvonen (Editors)
The COIN Book
Enterprose Collaboration and Interoperability
1. Auflage 2011
ISBN 3-86130-713-8


I
List of Authors
Achilleas Achilleos (University of Cyprus), Juncal Alonso (TECNALIA), Leyla Arsan
(LODER), Gorka Benguria (ESI), Duan Buen (GIZ-ACS), Gulcin Buyukozkan (LODER),
Vittorio Cannas (CANNAS), Davide Cerri (STI-Innsbruck), Otakar erba (WirelessInfo), Karel
Charvt (WirelessInfo), Karel Charvt jr (WirelessInfo), Elia Conchione (Soluta.Net), Marco
Conte (ESoCE-Net), Enrico Del Grosso (TxT e-Solutions), Brian Elvester (SINTEF), Jens
Eschenbcher (BIBA), Andrew Faughy (VEN), Pierfranco Ferronato (Soluta.Net), Daniel Field
(ATOS), Klaus Fischer (DFKI-GmbH), Pavel Gnip (WirelessInfo), Sergio Gusmeroli (TxT e-
Solutions), Konstantin Hristov (FAVIT), Mikko Hynlnmaa (POYRY), Kim Jansson (VTT),
Francisco Javier Nieto (ATOS), Aslihan Kagnici (LODER), Iris Karvonen (VTT), Mindaugas
Kiauleikis (Kaunas University of Technology), Valentinas Kiauleikis (Kaunas University of
Technology), Srdjan Komazec (STI-Innsbruck), Szabolcs Ktai (IND/IVSZ), Gerardo Lancia
(FILAS), Man-Sze Li (IC Focus), Aurelian Mihai (University Polytechnic Bucharest),
Alexandru Mihnea (University Polytechnic Bucharest), Nerijus Morkeviius (Kaunas University
of Technology), Zoltn Mzes (IND/IVSZ), Alberto Olmo (ISOIN), Simon Oman (Polycom
d.o.o.), Leire Orue-Echevarria (TECNALIA), George Papadopoulos (University of Cyprus),
Antonio Panazzolo (Soluta.Net), George Sielis (University of Cyprus), Michele Sesana (TxT e-
Solutions), Patrick Sitek (BIBA), Florian Skopik (Distributed System Group Vienna University
of Technology tuwien), Fabrizio Smith (TxT e-Solutions), Ioan Stefan Sacala (University
Polytechnic Bucharest), Hannes Suttner (Siemens), Timo Syrjnen (POYRY), Jess Snchez
(ISOIN), Francesco Taglino (CNR-IASI), Mehmet Tanyas (LODER), Drago Trebenik (Joef
Stefan Institute), Hong-Linh Truong (Distributed System Group Vienna University of
Technology tuwien), Mikel Vergara (TECNALIA), Ingo Zinnikus (DFKI-GmbH)


Thanks to all the Authors for their valuable contributions.
II
Preface of the Series
High performing co-operations between independent companies with the aim to develop and to
realise customised products are an important success factor for the competitiveness of the
European industry. Due to immense political changes and global markets, new ways of co-
operations, so called enterprise networks, can be seen in addition to the traditional supply chains.
These enterprise networks are often formed to realise a single customers order and play an
important role during the conceptual phase (product design) as well as during the realisation
phase (production).
The Bremer Schriften zur integrierten Produkt- und Prozessentwicklung (Bremen scientific
series for integrated product and process development) bases on the works performed by the
research field ICT application for production (IKAP) from BIBA Bremer Institut fr
Produktion und Logistics GmbH (www.biba.uni-bremen.de) and on the works performed by
BIK Bremer Institut fr integrierte Produktentwicklung (www.bik.uni-bremen.de).
The research unit IKAP prepares, develops and realises methods and tools to support co-
operative, inter-organizational enterprise networks. The research concentrates on efficient and
effective collaborative design and production processes by applying innovative information and
communication technologies (ICT). As focus can be seen the collaborative acting of enterprises
during distributed design and production processes as well as during the late processes of the
product life cycle such as the usage phase or the recycling phase.
Additionally, the BIK research expertise is concentrated on the integrated development of
products focusing on methods, tools and systems (like FMEA, QFD, CAD, CAE, and PDM).
The main focus lies on products constructed by renewable resources, glass fibre or carbon fibre
materials.
The research results are integrated in the academic education of the next generation engineers
(Production Enginnering, Systems Engineering, Engineering and Management) at the University
of Bremen. Another application field of the research results are industrial projects where
innovative approaches are transferred to practical problems.
The institute is publishing the results of its work in a series. The objective of this series is to
disseminate dissertations, project reports and proceedings of institute-hosted conferences to a
larger circle of interested people.

The Series Editors

Prof. Dr.-Ing. K.-D. Thoben
Prof. Dr.-Ing. D. H. Mller


III
The COIN Integrated Project: a flagship project of the Future
Internet Enterprise Systems domain

The Future Internet Enterprise Systems (FInES) Cluster
1
was launched in 2009 by the
Networked Enterprise and RFID unit of the Information Society and Media Directorate-General
as a follow-up to the work already accomplished in the domain of networked businesses. This
innovative domain was considered necessary given the upcoming challenges for our European
enterprises in the Future Internet era, in a context of increased globalization and competition. The
Cluster inherited the very rich advancements of three research domains previously supported by
the unit: Enterprise Interoperability, Enterprise Collaboration and Digital Ecosystems, but the
domain has never lost its scope on the usage and integration of ICT by enterprises. Encouraging
disruptive innovation, its mission remains to orient research priorities towards new business
approaches and business values supported by Information and Communication Technology,
where the Internet is the business ecosystem.
After the first FP7 call for proposals, COIN became the flagship project of the FInES Cluster and
one of its most ambitious, complex and wide-ranging projects. As the full name of the project
Collaboration and Interoperability for Network Enterprise may suggest, its primary objective was
to aggregate two separated areas Enterprise Collaboration and Enterprise Interoperability -
developed by the precursors of the FInES Cluster. COIN rightfully observed that the two must be
put together in order to have a coherent and efficient approach on the technology needed by our
businesses. In this endeavour, the COIN partners gathered valuable research results from several
EU funded projects that focused, however, solely on one of the two domains (see, for instance,
the European ATHENA, INTEROP, ABILITIES, SATINE and TRUSTCOM projects on
Enterprise Interoperability and the ECOLEAD, DBE, E4 or ECOSPACE projects on Enterprise
Collaboration).
One of COIN's most ambitious objectives is the provision of a universal service infrastructure
capability based on the concept of the Interoperability Service Utility (ISU),
2
a concept of high
importance for the FInES community. The ISU, already announced by the Enterprise
Interoperability Research Roadmap version 4.0,
3
is 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 it supports, in line with the priorities for SMEs
outlined in the Digital Agenda for Europe
4
and in the Innovation Union
5
Europe 2020 Flagship
Initiatives. In this sense, COIN's potential achievements are of tremendous value, tracing the
lines for further developments that the European Commission fully encourages.
However, the numerous and ambitious objectives of COIN could not have been credible if they
were an easy task to accomplish. It is our experience that projects aiming at building service
platforms are bound to be confronted to serious obstacles. Furthermore, a project of the length
(four years), size (twenty-nine partners) and complexity (seven sub-projects) of COIN meets
even more unsteady grounds in conducting its research, having to deal with a continuous

1
http://cordis.europa.eu/fp7/ict/enet/ei_en.html and http://www.fines-cluster.eu
2
The first Grand Challenge of the Enterprise Interoperability Research Roadmap [European Commission, 2006 and
2008
3
ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/ebusiness/ei-roadmap-final_en.pdf
4
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0245:REV1:EN:HTML
5
http://ec.europa.eu/research/innovation-union/pdf/innovation-union-
communication_en.pdf#view=fit&pagemode=none
IV
redefinition of the questions and needs it was trying to answer to. Moreover, the achievements of
the COIN project, as well as the results of the FInES domain, are and will always be "work in
progress". A work that can be a source of inspiration for all of us, interested in the evolution of
applied technology. A work made of blood, sweat and tears reaching out to other communities.
And for all these reasons, a work that needed to be written down and published.
I would like to acknowledge the considerable efforts and the valuable substance that is offered by
the COIN consortium through this book. I congratulate them for its realisation and hope that the
reader will find it an interesting, helpful and rewarding introduction to the subject area of next
generation service platforms.


Cristina Martinez,
Head of Future Internet Enterprise Systems cluster


V
Preface of the Volume
This book presents the key results of the COIN Enterprise Collaboration and Interoperability
project. COIN is an integrated project in the European Commission Seventh Framework
Programme - EU FP7 Project 216256, which has been running for four years from January 2008
to December 2011. COINs dimension and impact is represented by its size of 32 industry,
scientific and technological partners from Western and Eastern parts of Europe.
The COIN book addresses the current state of the art and current practice, future scenarios and
challenges for research and innovation of networking enterprises in the context of Future Internet
Enterprise Systems. The COIN book is made of diverse parts following the projects main sub-
projects trying to cover the broad research results and recapitulate them to a manageable
overview for an interesting reading. The COIN book describes the main parts of the developed
COIN IT Systems as well as consolidated baseline and innovative Enterprise Collaboration and
Interoperability IT-services. It describes the COIN demonstrators in the field of stable industrial
Supply Chains, more dynamic Collaborative Networks and most dynamic Business-Innovation
Ecosystems. One chapter is dedicated to discuss the approach to bring COIN to the market in
order to force our philosophy about the importance of the correlation between the achieved
research results and the business world.
Looking at the COIN main outcomes, the value of the project is not only constituted by the
numerous public research reports which are available through our website www.coin-ip.eu and
about 330 international and national events that we have organized. To our conviction COIN
results may also impact the EU and the Commission in terms of future work and research
priorities in the field of Future Internet Enterprise Systems (FInES).
The COIN consortium wishes to acknowledge all those who have contributed to our results. The
work has been co-funded by the European Commission under the ICT priority within the 7th
Framework programme. We are grateful to the EU project officer Cristina Martinez, Head of
Future Internet Enterprise Systems cluster, who has full supported the project throughout four
years of research work. Our thanks go also to the COIN review committee Alberto Bonetti,
Wolfgang Reisig, Carles Sierra and Joseph Tah for professional and productive discussions and
exchanges at anytime.

Sergio Gusmeroli, COIN Project Coordinator
TXT e-solutions SpA
Corporate Research Manager
VI
Table of Contents
1 The COIN Motivation, Object and Vision ............................................................................... 1
2 COIN IT System ....................................................................................................................... 7
2.1 The COIN Generic Service Platform for Enterprise Interoperability and Collaboration
Service Provision ......................................................................................................................... 10
2.1.1 Introduction ................................................................................................................. 10
2.1.2 The COIN Generic Service Platform ......................................................................... 10
2.1.3 Semantic Execution Environment .............................................................................. 12
2.1.4 Agent-Based Negotiation ........................................................................................... 12
2.1.5 Trust and Security ....................................................................................................... 14
2.1.6 Peer-to-Peer Registry and Repository ........................................................................ 15
2.1.7 Conclusion .................................................................................................................. 16
2.2 The COIN Front End for Generic Service Platform Federation Consuming ............... 18
2.2.1 Introduction ................................................................................................................. 18
2.2.2 GSP nodes and Services provisioning to the GSP Federation .................................. 19
2.2.3 Consume the GSP Federation by a Human Oriented Interface ................................ 25
2.2.4 Guiding User Semantic Search by Free Text Wishes Expression - JSI .................... 28
2.2.5 Conclusion .................................................................................................................. 29
2.3 The COIN Collaboration Platforms Federation for Enterprise Networks and Business
Ecosystems .................................................................................................................................. 31
2.3.1 Introduction ................................................................................................................. 31
2.3.2 Modelling, executing and outsourcing cross-enterprise collaborative business
processes .................................................................................................................................. 31
2.3.3 Extended Products and Distributed Collaborative Innovation in Virtual Factories . 40
2.3.4 Conclusion and Future Work ..................................................................................... 43
3 COIN Enterprise Collaboration (EC) and Interoperability (EI) Services ............................. 45
3.1 COIN research results for enterprise innovation - Enterprise Collaboration Baseline
Services ........................................................................................................................................ 46
3.1.1 Introduction ................................................................................................................. 46
3.1.2 Related Work .............................................................................................................. 47
3.1.3 EC Baseline Reference Model ................................................................................... 48
3.1.4 Conceptual architecture .............................................................................................. 50
3.1.5 Conclusion and key benefits ...................................................................................... 52
3.2 COIN Innovative Enterprise Collaboration Services ................................................... 54
3.2.1 Introduction ................................................................................................................. 54
3.2.2 Methodology and Workplan ...................................................................................... 54
3.2.3 Background and Previous Research ........................................................................... 55
3.2.4 Results - Overview of Developed Services ............................................................... 56
3.2.5 Innovations .................................................................................................................. 58
3.2.6 Conclusions and Key Benefits ................................................................................... 65


VII
3.3 COIN Enterprise Interoperability Baseline Services ..................................................... 66
3.3.1 Towards Enterprise Interoperability services ............................................................ 66
3.3.2 COIN EI framework ................................................................................................... 67
3.3.3 Enterprise interoperability baselines .......................................................................... 69
3.4 COIN Innovative EI Services ......................................................................................... 72
3.4.1 Introduction ................................................................................................................. 72
3.4.2 Information Interoperability services ......................................................................... 73
3.4.3 Process Interoperability services ................................................................................ 73
3.4.4 Knowledge Interoperability services ......................................................................... 74
3.4.5 Main innovation issues ............................................................................................... 75
3.4.6 Conclusions ................................................................................................................. 76
4 COIN Demonstrators .............................................................................................................. 78
4.1 The COIN EI/EC Services in industrial Supply Chains ................................................ 78
4.1.1 An EI/EC Pilot in an Automotive Supply Chain ....................................................... 79
4.1.2 Production Planning and Knowledge Interoperability Services in the Lazio
Aerospace Cluster ................................................................................................................... 85
4.1.3 An EI/EC Pilot in a Railways Supply Chain (KTU) ................................................. 90
4.1.4 An EI/EC Pilot in a Construction Supply Chain (UPB) ............................................ 95
4.2 The COIN EI/EC Services in Collaborative Networks ................................................. 99
4.2.1 An EI/EC Pilot in Andalusia Aeronautics Cluster (ISOIN) .................................... 100
4.2.2 An EI/EC Pilot in The Hungarian ICT Cluster (IND) ............................................. 109
4.2.3 An EI/EC Pilot in a Marine Shipping Network (UCY) .......................................... 114
4.2.4 An EI/EC Pilot in a Logistics Network (LODER) .................................................. 121
4.3 The COIN EI/EC Services in Business-Innovation Ecosystems ................................ 126
4.3.1 An EI/EC Pilot in a Healthcare Ecosystem (VEN) ................................................. 127
4.3.2 An EI/EC Pilot in Pyry business eco-system ......................................................... 135
4.3.3 An EI/EC Pilot in an Agro-Food Living Lab (WirelessInfo) ................................. 139
4.3.4 An EI/EC Pilot in a Digital Media Living Lab (FAVIT) ........................................ 145
5 COIN in the Business ............................................................................................................ 149
5.1 Supporting EC&EI service usability and take-up ........................................................ 150
5.1.1 Introduction ............................................................................................................... 150
5.1.2 Barriers and Challenges for IT take up .................................................................... 150
5.1.3 Development approach: Cross-teams ...................................................................... 152
5.1.4 Contributing to usability in EC &EI context ........................................................... 152
5.1.5 Development of COIN take-up guidelines .............................................................. 153
5.1.6 Conclusion ................................................................................................................ 157
5.2 Saas-U Value Proposition and Business Models ......................................................... 159
5.2.1 Introduction ............................................................................................................... 159
5.2.2 Assumptions and Hypotheses .................................................................................. 161
5.2.3 ISU Value Proposition and Business Model ........................................................... 161
VIII
5.2.4 Conclusions ............................................................................................................... 167
5.3 Bringing COIN to the Market ...................................................................................... 170
5.3.1 Challenges ................................................................................................................. 170
5.3.2 Logic adapted ............................................................................................................ 170
5.3.3 Development of business scenarios ......................................................................... 173
5.3.4 Type of Activity ........................................................................................................ 174
5.3.5 Scenarios in COIN .................................................................................................... 175
5.3.6 Conclusion ................................................................................................................ 178
5.4 Enterprise Collaboration Maturity Model .................................................................... 180
5.4.1 The problem description ........................................................................................... 180
5.4.2 Objectives and Use of the ECMM ........................................................................... 181
5.4.3 ECMM Design Process and Background ................................................................ 181
5.4.4 COIN ECMM Structure and Description ................................................................ 183
5.4.5 ECMM Application into End Users ......................................................................... 185
5.4.6 Conclusions ............................................................................................................... 188
Conclusions - The heritage of the COIN Integrated Project: how to move forward in the Future
Internet Enterprise Systems domain ............................................................................................. 190



IX
Table of Figures
Figure 1 The COIN Butterfly model .............................................................................................. 8
Figure 2 COIN GSP Architecture ................................................................................................ 11
Figure 3 Composed services in the COIN context ...................................................................... 13
Figure 4 - Main components and relationships in the TSD Platform ............................................ 14
Figure 5 - P2P Repository/Registry Architectural viewpoint ........................................................ 16
Figure 6 - GSP evolution cube .................................................................................................... 20
Figure 7 - COIN GSP model ontology stack .................................................................................. 22
Figure 8 - COIN Assets Download ................................................................................................. 23
Figure 9 - GSP Model Configuration .............................................................................................. 23
Figure 10 - nodes waiting for approval ........................................................................................... 24
Figure 11 - The Web form for defining service pre-/post-conditions ............................................ 24
Figure 12 Generic User Functionalities ....................................................................................... 25
Figure 13 - COIN Front-End deployment schema and COIN System upper Cloud interaction .. 26
Figure 14 - Browse & Search interface ........................................................................................... 27
Figure 15 - detail of the semantic search results ............................................................................. 27
Figure 16 - from the left: try-me button form, trust values and COIN SMW for information on
the service ........................................................................................................................................ 28
Figure 17 - FTWE pipeline ............................................................................................................. 28
Figure 18 - Enrichment services ..................................................................................................... 29
Figure 19 - Industrial User - CP Integration Step 1 ........................................................................ 35
Figure 20 - Industrial User - CP Integration Step 2 ........................................................................ 35
Figure 21 - Injection in the business process of a discovered service ........................................... 36
Figure 22 - Industrial User - CP Integration Step 3 ........................................................................ 36
Figure 23 - GAP Identification - Flow diagram ............................................................................. 37
Figure 24 - COIN Step 2 Overview ............................................................................................. 37
Figure 25 - Transformation Found .................................................................................................. 38
Figure 26 - Available Transformations ........................................................................................... 38
Figure 27 - Process Overview ......................................................................................................... 39
Figure 28 - automatic execution ...................................................................................................... 39
Figure 29 - Moving to an Extended Product .................................................................................. 41
Figure 30 - Evolution towards distributed, collaborative innovation ............................................ 42
Figure 31 - Extended products and collaborative distributed innovation in Virtual factories ...... 43
Figure 32 - EC Baseline Reference Model ..................................................................................... 49
Figure 33 - Conceptual architecture of the COIN Baseline EC software services and tools ........ 50
Figure 34 - Example of decoupling of an existing software .......................................................... 51
Figure 35 - Baseline IT Services Portal .......................................................................................... 52
Figure 36 - COIN overall development strategy ............................................................................ 55
Figure 37 - Overview of developed services .................................................................................. 56
X
Figure 38 - Healthcare sector ontology draft .................................................................................. 58
Figure 39 - Collaborative Production Planning .............................................................................. 60
Figure 40 - Example of meeting process and steps ........................................................................ 62
Figure 41 - Interoperability reference model .................................................................................. 67
Figure 42 - Baseline categories according to AIF .......................................................................... 68
Figure 43 Commercial Process .................................................................................................... 81
Figure 44 - Technical process ......................................................................................................... 81
Figure 45 - Integration process for the legacy system users .......................................................... 83
Figure 46 - Integration process for the non-legacy system users ................................................... 83
Figure 47 - Knowledge Interoperability Pilot ................................................................................. 87
Figure 48 - Collaborative Production Planning Pilot ..................................................................... 88
Figure 49 - Manufacturing process of VAE Legetecha (fragment) ........................................... 91
Figure 50 - University Politehnica of Bucharest COIN implementation strategy ..................... 96
Figure 51 - The process of ordering materials from suppliers ....................................................... 97
Figure 52 - The process of collaborative project planning and change management ................... 97
Figure 53 - The Andalusian Aeronautic Cluster main competences and entities. ....................... 101
Figure 54 Workflow example .................................................................................................... 102
Figure 55 - Some COIN Innovative services tested. Collaborative 3D designer service (left) and
Interoperability Spaces (right) have been tested, for product design and contract negotiation,
respectively .................................................................................................................................... 104
Figure 56 Challenges and COIN Expectations .......................................................................... 110
Figure 57 - Use Case 1: Formulating the Recap Pre-Fixture Document ..................................... 115
Figure 58 - Use Case 2 Creation and Settlement of the Proforma Disbursement Account (PDA)
........................................................................................................................................................ 115
Figure 59 - Use Case 1 Formulation of the Recap Voyage Document using ProcessMaker .. 118
Figure 60 - Initialisation of the recap document business use-case ............................................. 119
Figure 61 - Dincer Lojistik business network for collaborative transportation ........................... 122
Figure 62 - The general business processes of Dincer Lojistik for use cases .............................. 123
Figure 63 General development process for order transformation ........................................... 124
Figure 64 - Business Eco-System with actors in facility engineering projects ........................... 135
Figure 65 - Accelerate transition to global operation and networked engineering ...................... 136
Figure 66 - Interrelation of different knowledge levels ............................................................... 140
Figure 67 Three Layers Architecture ......................................................................................... 141
Figure 68 System overview ........................................................................................................ 142
Figure 69 - Architecture of Machine searching ............................................................................ 143
Figure 70 - COIN take-up process ................................................................................................ 157
Figure 71 ISU Summary ............................................................................................................ 160
Figure 72 ISU Stakeholder Categories ...................................................................................... 164
Figure 73 - Applying Competitive Models to the Supply of Utility Services ............................. 167
Figure 74 - Core and peripheral assets .......................................................................................... 172
Figure 75 - Value Chain for the core COIN technology .............................................................. 172


XI
Figure 76 - The complete value chain for COIN .......................................................................... 173
Figure 77 - Legend for value chain activities ............................................................................... 175
Figure 78 - Facebook Scenario 1 .................................................................................................. 175
Figure 79 Facebook Scenario 2 .................................................................................................. 176
Figure 80 - Open Source Scenario ................................................................................................ 176
Figure 81 - Markeplace Scenario 1 ............................................................................................... 177
Figure 82 Franchise Scenario ..................................................................................................... 178
Figure 83 - ECMM Maturity Levels ............................................................................................. 182
Figure 84 - ECMM Results: Comparison between the three companies ..................................... 185




1
1 The COIN Motivation, Object and Vision
COIN Background
Enterprise Collaboration (EC) and Enterprise Interoperability (EI) have represented for
European Commissions FP6 research programme two of the major research domains in the field
of ICT for Networked Enterprises (DG INFSO D4 Networked Enterprise & Radio Frequency
Identification) and aggregated tens of projects and hundreds of researchers in their projects
initiatives.
Research in Enterprise Collaboration comes from a business perspective and identifies the
process of enterprises - mainly SMEs - to set-up and manage cross-enterprise win-win business
relations in response to business opportunities. The aim is to find new paradigms for European
enterprise aggregation, process synchronization and people co-operation in response to the more
and more demanding and complex business opportunities coming from the global market. In
order to fully exploit its tremendous potential, EC research not only aims at achieving important
and relevant results from the scientific, organizational, business standpoint, but it also magnifies
the investments on resources in the Information Technology (IT) implementation of the key
collaboration processes and cross-enterprise applications needed to make collaboration easier
and profitable.
However, most of the completed EU funded EC research initiatives have achieved significant
results in the field of IT support to collaboration management and performance management, but
they couldnt address properly the problem of Enterprise Applications Integration (EAI).
Research in Enterprise Interoperability originated by the IT world and identifies the capability
of enterprise software and applications to be integrated at the level of data, applications,
processes and models. Enterprise Interoperability started from an IT perspective of Enterprise
Application and Software interoperability and focused on enterprise modelling, architecture and
platforms, ontologies and semantics as the basic pillars for EI. This research stream proceeded
very well in an analytical way to deeply investigate the various interoperability problems which
affect European enterprises and has come out with a set of solutions for Enterprise Models
Interoperability, Cross-organizational Business Processes, Semantic Business Document
Reconciliation, IT Service selection and composition and Model-driven Architectures.
However, EI solutions so far have been proved as efficient and effective in the IT and research
community but have some way privileged in their field adoption the big enterprises while there is
a tremendous need for EI efficient and effective solutions in the SMEs environment and in some
less IT-developed sectors. Moreover, it seems that EI solutions so far lack flexibility and
adaptation to different business scenarios and collaboration forms like Supply Chains,
Collaborative Networks and Business Ecosystems.
Hence, it is evident that research in EC lacks the adoption of innovative and advanced IT
architectures and tools, while research in EI lacks best practices, clear business justification
mostly for SMEs and real-life collaborative business applications.
In synthesis, it is true that EC and EI are different concepts which cannot be merged, confused
and mixed up, but that they are so interdependent, interconnected and simultaneously present in
every networked enterprise, that they can be really considered as the two sides of the same coin!

COIN Motivation
Since more than a decade, the adoption of advanced Information Technology methods and tools
has been considered one of the strongest competitive advantages for collaborative enterprises.
However, so far EI/EC solutions in networked enterprises have mostly been implemented in
hierarchical static supply chains, by forcing the installation and adoption of the same IT solutions
2
in all networked enterprises. But what happens in the presence of less hierarchical collaboration
forms like in innovation ecosystems or when SMEs simultaneously belong to different supply
chains and cannot simply adopt one single IT solutions.
Networked Enterprises simply need more flexible and adaptable EC and EI solutions.
On the other hand, the advent of Internet and the so-called Service Web has introduced
unprecedented opportunities for e-commerce and e-business processes: the Internet has become a
Universal Business System and service oriented architectures have completely revolutionised the
traditional software engineering methods and tools. How to implement this huge potential for
innovation in the field of EI/EC among networked enterprises?
Networked Enterprises need more simple and easy to use access to Internet web services.
So, there is a more general question which says How to bridge the gap between Business and
IT, making the Internet of Services easily accessible and integrated in business processes? and a
more specific question which focuses the topic to EI/EC: How could networked enterprises
have access and easily use the most advanced web services available in the Internet to solve their
Interoperability and Collaboration problems?
The EI Cluster [13] in its research roadmap v 4.0 identified in the implementation of the ISU
(Interoperability Service Utility) Grand Challenge a way to provide all enterprises, including
SMEs, with a basic set of Interoperability Services to implement their collaborative business.
Such an ISU was conceived both as a utility infrastructure (i.e. a service delivery platform for
basic fundamental services) and as a set of innovative business models accompanying it.
The fundamental motivation of the COIN project was the urgent need by collaborative business
processes to easily access-compose-orchestrate-execute EI/EC services available to all in the
Internet at a very low cost and under guaranteed service levels; in one sentence to implement the
ISU and its most relevant business models applied to EI/EC services for any form of more or less
hierarchical networked enterprise.

COIN Project 2020 Vision Statement
By 2020 enterprise collaboration and interoperability services will become an invisible,
pervasive and self-adaptive knowledge and business utility at disposal of the European
networked enterprises from any industrial sector and domain in order to rapidly set-up,
efficiently manage and effectively operate different forms of business collaborations, from the
most traditional supply chains to the most advanced and dynamic business ecosystems
The COIN Vision (COIN DoW) implies that in 10 years time, Enterprise Interoperability and
Enterprise Collaboration services will be commoditized and factorized in the Internet of the
Future as a set of Utility Services, available to all enterprises at a very low or zero cost and under
non-discrimination and non-exclusivity policies: Interoperability and Collaboration as Public
Services.
From an IT architectural viewpoint, the COIN Vision implies that commercial Enterprise
Systems of the future [13] should focus on the most added value services they could provide (e.g.
supporting supply chains, customer relationships, product life cycle, financial and HR issues, in
one word supporting Business Innovation) and leave the most commoditized IT services to the
Future Internet open platforms developers.
The COIN Vision is in agreement with the most recent EC policies and in particular with the
Digital Agenda for Europe [12] which identifies 7 key themes to be solved in order to build the
European Digital society. One of these pillars is: Interoperability and Standards: a digital
society can only take off if its different parts and applications are interoperable and based on
open platforms and standards.


3
From a business viewpoint, the distinction between Value Added (pay-as-you-go) and Utility
(free) services is stimulating the development of innovative business models bundling Value
Added services and Utility Services in a very similar way the media industry is bundling free and
premium services. The latest outcomes of COIN business research show however that the full
adoption of so called SaaS-U business models (merging SaaS and Utility models) will be
effective for EI/EC services just starting from 2020, when Value Added services could be on-
the-fly and dynamically selected in the private clouds by Enterprises and therefore the need of
standardized EI/EC services available in the open clouds will become essential.
Moreover, the present perception in COIN is that in the current business and market landscape
for providing enterprises with just EI/EC Utility Services is not guaranteeing the IT providers
with the necessary economical returns from the needed huge investments in ICT, according to
the current costs of Cloud Computing and similar infrastructures.
By 2020, thanks to the implementation of the Digital Agenda for Europe, it is supposed that
current obstacles hindering the implementation of the COIN 2020 Vision (e.g. EI/EC services
hard-wired, high costs to set-up a cloud service infrastructure, low bandwidth and network
performance, predominance of on-premises monolithic solutions, huge availability of EI/EC
services/information in the open Internet, legislative and regulatory issues which will combat
monopoly positions and support open specifications and open standards) could disappear and
make the provision for the ISU profitable also from a mere economic point of view.

The COIN Metaphor
The COIN coin metaphor is also useful to describe the 5 major research topics of the project:
The SIDE A of the COIN: Enterprise Collaboration.
The COIN Project develops innovative services for enterprise aggregation, synchronization
and co-operation, adaptable to any collaboration form and suitable for SMEs needs. COIN
will develop innovative services for Enterprise Collaborative in Product Development (c-
PD), Collaborative Production Planning (c-PP), Collaborative Project Management (c-
PM), as well as in Human Centric Collaboration (c-HI). The first three group of services
directly support the corresponding collaborative operational functions; product
development, production planning and project management, while the forth group of
services are more general and not specifically dedicated to a business function. The c-HI
services encompass services for human collaboration and data sharing and can be utilized
as supporting services, for example in c-PD, c-PP and c-PM. The EC services are
explained in more detail in chapter 3 of this book [4][5][6][7]

The SIDE B of the COIN: Enterprise Interoperability.
Enterprise Collaboration is a term that describes a field of activity with the aim to improve
the manner in which enterprises, by means of information and communications technology
(ICT), interoperate with other enterprises or organisations to conduct their business. In the
COIN context, EI services provide functionality for applying IT solutions that overcome
interoperability gaps between two or more enterprises and thus enabling them to set-up and
run collaborations. The COIN Project provides innovative integrated-unified-federated
solutions for bridging interoperability gaps at the level of data, service, process and
knowledge. The main goal of the EI services is to reduce the costs of data reconciliation,
systems integration and business processes synchronization and harmonization. The COIN
project adopted the ATHENA EI reference framework [1] which addresses interoperability
at different levels, by using two main approaches (i.e., model-driven and semantics-based)
The EI services are explained in more detail in chapter 3 of this book [8, 9 and 10]
4
Interoperability at the information/data level is related to the exchanging and sharing
business documents among organizations, by filling interoperability gaps related to the
format and content and to the messages and/or structures to be exchanged.
Interoperability at the service level is concerned with discovering, ranking, selecting,
composing, orchestrating and executing various applications implemented as a service.
Interoperability at the process level is the capability to make proper external views of
enterprise internal processes synchronised by a collaborative inter-enterprise business
process.
Interoperability at the knowledge level should be seen as the organisational and
operational ability of an enterprise to co-operate with other, external organisations in spite
of e.g., different working practices, legislations, cultures and commercial approaches.
For both sides of the coin, COINs main objective here is i) to be the catalyst of previously
developed EI/EC services, by harmonising their semantic descriptions and by supporting
their registration into the same web site and discovering mechanism and ii) to develop
innovative EI/EC services, extending the available ones with new methods, techniques and
functions, as for instance the implementation of a federated interoperability platform or the
integration of social networks in collaboration.

The Metal of the COIN: Generic Service Platform.
The COIN Project develops a pervasive, adaptive service delivery platform to host COIN
services for Enterprise Collaboration and Enterprise Interoperability. A generic
Semantically Enabled Service Architecture has been customised for the EI/EC domain and
empowered with peer-to-peer, trust & security and intelligent reasoning / negotiation
capabilities.

Here the objective of COIN is to develop an open-trusted federation of service delivery
platforms, namely the ISU (Interoperability Service Utility) aimed at making accessible,
browsable, composable and executable from a single one-stop-shop the myriad of EI/EC
services developed not only in COIN but in any other research project or
standardisation/commercial initiative. In the Future Internet (FI) perspective, the objective
is to integrate such a federation with the FI Core Platform and its Generic Enablers, with
the final aim to develop a set of Enterprise-oriented utilities and to realise the vision of
FI as the Universal Business System. [3]

The Generic Service Platform that has to provide COIN with a platform with a reliable
layer for models and services. Regarding the interaction and interoperability with other
COIN components, the Evolutionary and Pervasive Service Platform is simply seen as a
Web Service, that holds information that is critical to the functioning of the COIN services
and models. The pervasiveness of the platform is accomplished through the usage of a
decentralization technique; the information is distributed and replicated in a set of
connected nodes. The peer to peer protocols are a valuable technology for the organization
of the information and for the communication infrastructure. In a peer to peer network the
information is shared across the members of the community (represented by nodes) and it
is not under the control of a single institution or organization. This approach is a promise
for true equality; there is not a single point of failure inside the network and hence the
services are more reliable.

The Value of the COIN: Software as a Service Utility


5
The COIN project supports the establishment of business models for interoperability
service utilities that will match current market condition and completion. The Information
Technology vision of Software as a Service (SaaS) finds its implementation in the field of
interoperability among collaborative enterprises, supporting the various collaborative
business forms, from supply chains to business ecosystems, and becoming for them like a
utility.

In order to describe, reason and where possible assess change on different levels, the COIN
research into EI Value Proposition needs to integrate the relevant key developments
[11]. There are of course different schematics for integrating and characterising those
developments. Given that the overall context for COIN is enterprise networking, the
research will be concerned with developments that are ICT based and/or ICT enabled. In
conformity with the vision and mission of COIN, the research is particularly concerned
with market developments and trends with reference to the themes of Software as a
Service (SaaS) and Interoperability Service [as] Utility (ISU). SaaS is a market reality
while ISU is a research challenge premised upon a re-structuring of the current Internet.
The notions of interoperability and collaboration are changing in perspective and scope as
a result of both market reality and new research orientation towards a Future Internet. On
the basis that the Future Internet represents the future of ICT, this could be elaborated as
the Future Internet will provide a critical infrastructure for all enterprises, which is itself an
articulation of the FInES Cluster vision of the Internet being a universal business system.

The basic assumptions are that the Future Internet represents the future of ICT, this could
be elaborated as the Future Internet will provide a critical infrastructure for all enterprises,
which is itself an articulation of the FInES Cluster vision of the Internet being a universal
business system. Enterprise processes will be subject to increasing commoditisation and IT
capabilities will be subject to increasing contextualisation in order to better serve business
needs.

The Market of the COIN: Manufacturing Enterprises, mainly SMEs.
The COIN original project encompasses six industrial test cases in different domains
(Automotive, Space, Aeronautics, Healthcare, ICT, Plants Engineering). The test cases
have been extended to twelve, by adding new six domains coming from the so-called
Enlarged Europe (Marine Shipping, Railways Components, Agro-food, Civil
Construction, Logistics & Transport, Media).

All the developed constituents of the COIN metaphor need to be deployed and adopted in
realistic business scenarios and carefully evaluated in their business benefits and
exploitation potential. To achieve this objective, specific attention is being spent in COIN
to cover the different industrial sectors, European Countries, application domains, EI/EC
heterogeneous requirements and legacy systems and applications.

References
[1] Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications
(ATHENA) - IST-507849 FP6 - Integrated Project
[2] Grant agreement for Collaborative Project, FP7 IP 216256 - COIN Large-scale integrating project, Annex I
- Description of Work
[3] COIN deliverable D3.2.1b - Evolutionary and Pervasive Service Platform, 2009
6
[4] COIN Deliverables D4.2.1b - cProduct Development Services, 2009
[5] COIN Deliverables D4.3.1b - cProduction Planning Services, 2009
[6] COIN Deliverables D4.4.1b - cProject Management Services, 2009
[7] COIN Deliverables D4.5.1b - cHuman Interaction Services, 2009
[8] COIN Deliverables D5.2.1b - Information Interoperability Services, 2009
[9] COIN Deliverables D5.3.1b - Knowledge Interoperability Services, 2009
[10] COIN Deliverables D5.4.1b - Business Interoperability Services, 2009
[11] COIN deliverable D6.2.1b - Integrated EI Value Proposition, 2009
[12] DAE: A Digital Agenda for Europe, EUROPEAN COMMISSION Communication from The Commission
to The European Parliament, The Council, The European Economic and Social Committee and The
Committee Of The Regions Brussels, 26.8.2010. COM(2010) 245 final/2
[13] FInES 2010: Future Internet Enterprise Systems (FInES) Research Roadmap FINAL REPORT, June 2010.


7
2 COIN IT System
The COIN system is a complex cross-enterprise environment encompassing several different
components, platforms and services, which could be represented as a double cloud (COIN
butterfly) visible in Figure 1. By mission, COIN aims at attracting as many EI/EC service
providers and as many EI/EC service consumers as possible, becoming this way the reference
service platform for EI/EC services. This means that the architecture of COIN system should be
open, evolutionary, scalable, incremental, so that to become a catalyst for those who want to
publish their services (according to their standards and business models) and those who want to
access EI/EC services from the open Internet. During and after the COIN project life time,
additional nodes have been and will be added to the initial COIN configuration, by integrating
contributions coming from external sources (e.g. research projects like SOA4ALL
6
and
DEN4DEK
7
or business-oriented initiatives like ITA - Information Technology for the German
Automotive Industry - or GENESI DEC - Digital Earth Community -), this way experimenting
and assessing the openness, scalability and interoperability of our technical choices.
The COIN Integrated System is a federation of Platforms, Services and Web Interfaces which
allow EI/EC Services to be searched, discovered, ranked, orchestrated and executed by cross-
organizational business processes.
There are three basic components of the COIN system, which could be interfaced in several
different ways:
A COIN Generic Service Platform (GSP) which is an open source instantiation of a generic
SESA (Semantically Enabled Service Architecture), specialized in the EI/EC domain, and
empowered with advanced capabilities for trust & security, distribution & scalability,
reasoning & negotiation.
A constellation of COIN EI/EC Services which are able to implement state-of-the-art and
innovative technologies to support information, knowledge and business interoperability as
well as Human Collaboration in a collaborative business context of Product Development,
Production Planning and Project Management.
A COIN Collaboration Platform (CP) which is a generic open source web portal
encompassing Social Networking interaction, Knowledge Assets accession and Business
Process management in a unique integrated multi-enterprise collaboration environment
customized for more or less hierarchical organizational networks.
The COIN Integrated System Butterfly Model represents the complete vision of the COIN
system integrating the previous identified basic components with the work provided in the final
part of the project. The focus of the work, apart the empowering of basic components, is the
integration and consumption of them through a more general vision of the system including
several users and methodologies.
The model is made of two distinct clouds, one for service provision (upper cloud) and the other
for service consumption (lower cloud), being also supported the pro-sumers case; in the middle
is the integration software allowing the communication among the two clouds and the service
consumption by other kind of actors.

6
Service Oriented Architectures for All, http://www.soa4all.eu/
7
Digital Ecosystems Network of regions for (4) DissEmination and Knowledge Deployment,
http://www.den4dek.org/
8

Figure 1 The COIN Butterfly model

A first upper cloud of open COIN and non-COIN service delivery platforms (providing utilities
for service development, registration, publication, search & discovery, orchestration &
execution) federated by EI/EC interoperable ontologies forms the COIN Upper Federation,
which could be seen as a subset of the Future Internet of Services core platform (or
Interoperability Service Utility) devoted to provide Smart Applications with common EI/EC
commodities like human interaction, data mapping, service reconciliation and process
synchronization functions.
A second lower cloud of domain- and sector-specific COIN and non-COIN Collaboration
Platforms provides Supply Chains, Collaborative Networks and Business Innovation Ecosystems
with advanced EI/EC services supporting the whole product/service life cycle and collaboration
phases, integrating legacy systems and data, constituting this way the COIN Collaboration
Federation, a part of next generation FI-based Enterprise Systems (FInES).
A third component is the integration software which is called COIN Front End and it is a plug-
in either for the service delivery or for the collaboration platform, depending on the case. The
scope of this component is to provide the communication among the two clouds and a set of
services for the consumption of the capabilities of the upper cloud for users not facing the system
from the lower cloud.
Four main typologies of users could access the COIN System:
i. Individual users (humans COIN Front End) who are browsing the content of the GSP
and of the CPs (e.g. configuration, nodes federation, services, business models, various
info);


9
ii. IT users (humans COIN Front End) who are able to build and develop their own
solutions (with or without the help of COIN platforms) and to link them to the COIN IT
System;
iii. Industrial users (humans and/or automatic business processes COIN Front End and
lower cloud) who are able to model and run their business processes in collaborative
enterprise environments (supply chains, collaborative networks, business ecosystems)
with the help of the COIN System.
iv. Federation Authority (humans COIN Front End) managing administrative issues of the
upper and lower cloud federations.
As depicted in the previous picture, the service delivery and collaboration platforms federations
are made of COIN platforms and non-COIN platforms. The COIN Platforms are platforms
which are based on the COIN open source developments, developed inside the COIN project by
our partners or by external third parties, for example in the community of COIN Multipliers. The
non-COIN Platforms are based on other service delivery and collaboration platforms and could
be provided by COIN Multipliers as well.
Utility and value-added COIN EI/EC services (Value Added Services) are available to both
clouds: they are registered in the COIN service delivery platforms nodes to be discovered-
composed-executed inside the upper cloud federation, they can be downloaded and integrated
with COIN collaboration platforms in order to be directly targeted by Industrial Users.
10
2.1 The COIN Generic Service Platform for Enterprise Interoperability and
Collaboration Service Provision

Srdjan Komazec1, Davide Cerri
1
, Klaus Fischer
2
, Ingo Zinnikus
2
, Francisco Javier Nieto
3
,
Pierfranco Ferronato
4
, Elia Conchione
4
, Antonio Panazzolo
4

1
STI Innsbruck, Universitt Innsbruck, Technikerstrae 21a, 6020 Innsbruck, Austria
{srdjan.komazec, davide.cerri}@sti2.at
2
DFKI GmbH, Campus D3_2, 66123 Saarbrcken, Germany
{klaus.fischer, ingo.zinnikus}@dfki.de
3
ATOS Research and Innovation, Atos Origin, Capuchinos de Basurto 6, 48013 Bilbao, Spain
francisco.nieto@atosresearch.eu
4Soluta.Net, via Edificio 2, 31030 Altivole, Italy
{pferronato, econchione, apanazzolo}@soluta.net

Abstract
The COIN Generic Service Platform (GSP) represents the core pillar of the COIN system. The platform is founded
on top of Semantic Web Service technologies and further extended in order to meet additional enterprise-level
functional requirements in terms of trust and security, negotiation and composition capabilities and scalability. The
platform provides the necessary capabilities for Enterprise Interoperability and Enterprise Collaboration service
provisioning, and at the same time offers a fertile environment to implement novel service provisioning business
models. This chapter sheds some light on the main COIN GSP components and their functionality.

2.1.1 Introduction
The central role of the COIN system is to fulfill a variety of lower-level (i.e., technical) and
higher-level (i.e., business) enterprise-level requirements for Enterprise Interoperability and
Enterprise Collaboration service provisioning, on top of which original business models, such as
Software as a Service (SaaS), can be implemented. In order to reduce difficulties in completing
such a challenging vision, the COIN system identifies the main aspects that need to be covered.
In particular, proper means to enable precise and automated goal-based discovery, selection and
invocation of service offerings is the core of the infrastructure. Additionally, sufficient support to
establish trust and security between the service provisioning stakeholders is needed.
Furthermore, facilities to enable (semi-)automated negotiation of the service provisioning terms
and policies, as well as composition of services are playing a significant role in this environment.
The platform should also exhibit proper means to scale in a peer-to-peer fashion over service
usage tasks exercised over resources contributing to the service descriptions (e.g., service
discovery, ranking and selection and invocation). All those aspects are blended together in a
platform called COIN Generic Service Platform (GSP), explained in the following sections.
2.1.2 The COIN Generic Service Platform
The Web service technology stack allows exchanging messages between Web services (SOAP),
describing the technical interface for consuming a Web service (WSDL), and advertising Web
services in registries (UDDI). However, in traditional Web service implementations, the lack of
information to express the meaning of the data and of the vocabulary referenced by the interface,
as well as the lack of formalisation of the Web service behaviour, implies the requirement of
human intervention in tasks such as Web service discovery, composition, ranking and selection,
thus severely hindering the automation of the envisioned tasks.


11
Semantic Web Services (SWS) [6] aim at providing more sophisticated Web service
technologies through the introduction of semantic Web technologies. SWS utilise ontologies as
the underlying data model in order to support semantic interoperability between Web services
and clients, and apply semantically enabled automated mechanisms that span the whole SWS
usage lifecycle, comprising discovery, selection, composition, mediation, negotiation, and
execution of Web services. More generally, the introduction of semantics as an extension of
Service-Oriented Architectures, and thus the creation of Semantically Enabled Service Oriented
Architectures (SESAs), provides for next generation of service-oriented computing based on
machine-processable semantics. The advantages of SWS stem from the fact that explicit, formal
semantics is associated with the Web service description, and that the execution environment for
SWS is able to interpret and use this semantics appropriately. This supports direct understanding
of the Web service functionality at design time as well as at run time.
The SWS platform represents the heart of the COIN Generic Service Platform (GSP), as shown
in Figure 2. Alongside the core aforementioned tasks, the platform functionality is extended
towards providing support for the platform execution monitoring (Monitoring component) and
deferred goal resolution (Notification Broker component). In addition, the platform is
complemented with the three pillars, addressing following aspects: distributed peer-to-peer
service registries and evolutionary model repositories (P2P Federation Registry) that improve
scalability and availability of the platform and reduce single-point-of-failure risks; trust-security
mechanisms (Trust Negotiator, Trust Manager, TSD Portal and Security ESB components) that
provide support to establish and maintain trust in a transparent way between parties involved in
conversation with the platform (service requesters/providers), as well as secured access to the
resources and dependability policies; and intelligent agent-based service negotiation and
composition (Agent platform with Negotiation and Composition components) which provides
support for flexible service composition and usage policies negotiation.


Figure 2 COIN GSP Architecture

A single instance of a GSP can fulfil the requirements of scenarios characterised by limited scale
and closeness. There are however scenarios in which the above assumptions do not hold, and
which raise the need to support a distributed deployment because of scalability or dependability
reasons. The deployment is achieved thorough federation of GSP instances (Federation Adapter
component) and provided functionalities so that users of each one can benefit also from services
provided by other ones.
12
2.1.3 Semantic Execution Environment
As explained in the previous section, the core of the COIN GSP is a Semantic Execution
Environment (SEE), able to perform Web service discovery, ranking, invocation and monitoring
by leveraging semantic Web service descriptions. The COIN GSP SEE is based on WSMX,
which is the reference implementation of the Web Service Modeling Ontology (WSMO) [3], and
provides functionalities to discover and invoke semantic Web services. The COIN GSP SEE
extends WSMX along several directions, detailed in the following paragraphs.
First of all, the COIN GSP SEE includes a complex event processing engine coupled with
WSMX monitoring facilities. A Semantic Execution Environment constitutes a rich source of
events: at the level of the overall platform (e.g., the start of a Web service invocation process), at
the level of single functionalities (e.g., tracking of the functionality provided by the discovery
engine) and regarding external services (e.g., a fault during a Web service invocation). In order
to monitor such events, all internal components have been appropriately instrumented, thus
enabling detection and extraction of low-level events and generation of semantically-enhanced
event descriptions. These descriptions are defined in the context of the COIN ontology stack and
of the SEE ontology, which specifies structure and relationships inside the SEE. Since events
have an ontological representation, the complete event history is preserved in an RDF repository
for convenience purposes (support for massive storage, inference and querying). Before reaching
this repository, events must be adequately processed in order to detect and react in a timely
manner to potentially complex situations of interest (e.g., three failed attempts to invoke a
particular Web service may trigger another round of Web service discovery, in order to find a
different solution). For this processing step, the COIN GSP SEE integrates an RDF-based
Complex Event Processing engine (RDF-CEP). The primary objective of RDF-CEP is to detect
occurrences of RDF triples which satisfy expressive RDF patterns. When a complex event is
detected, the engine executes the appropriate actions associated with the detected event (e.g.,
updating the aggregated statistical measures, notifying the administrator about successive failed
attempts to access GSP facilities, etc.).
In order to enable asynchronous notification of discovery results, the COIN GSP SEE includes a
Notification Broker component. This component is responsible for registering and storing user
subscriptions and for sending notifications when new results are available. The COIN GSP SEE
supports subscriptions to goal-based discovery, so that a user can register a goal and then be
notified when a service which matches that goal has been registered. The notification can be
delivered via email or by invoking an external Web service. The notification mechanism is not
limited to goal-based discovery, and can be easily extended to other processes.
WSMX can only support single-instance deployments while, as previously discussed, in COIN
there is a need to support a federation of multiple GSPs. The Federation Adapter component is
responsible for forwarding discovery requests (goals) and responses between different GSPs.
Target GSPs for a request can be chosen basing on the category of registered services, on GSP
non-functional properties (e.g., offering free services), and on the platform services provided by
the GSP (e.g., a certain GSP may offer service discovery but not invocation, whereas the client
may want only services that can be automatically invoked). Multiple federations and clusters can
be supported, as each GSP that receives a forwarded request may in turn forward it to another
GSP which is unknown to the previous GSP in the path.
Last but not least, the COIN GSP SEE includes a ranking engine to rank discovered services
according to user preferences. The ranking engine is capable of invoking external services to be
used as additional sources of information, e.g. regarding reputation of services.
2.1.4 Agent-Based Negotiation
In the first place services, as they are registered in the COIN GSP, can be seen as atomic services
provided by individual service providers and made available for execution through the COIN
platform where the details of how the service is actually provided is hidden from the user who


13
requests the service. However, it is not realistic to assume that a user of the platform always
specifies requests which can be directly matched with the available services. Therefore, the
platform should also be capable of handle requests that require combinations of available
services. Such combinations of services are commonly investigated under the topic of service
composition (for an overview see e.g. [5,9]).
Service composition is a complex field and comprises several aspects. For the purpose of this
discussion, the distinction between design time and runtime and the difference between
predefined and automatic compositions is emphasized. These distinctions might be regarded as
related, however they are rather orthogonal, as e.g. automatic composition could be used at
runtime, but also at design time when a process designer requests support for potential service
compositions to be integrated into a workflow at design time. So while the process designer is
quite likely interested in the details of how a service is provided, a platform end-user most
probably wants to use the service in a black box manner and therefore is not interested in these
distinctions.

Figure 3 Composed services in the COIN context

Accordingly, three roles can be distinguished within the COIN setting: the service provider who
owns a service and provides a service description (in WSML) when registering the service, a
process designer who uses and combines available services to define workflows (including
automatic compositions if necessary) providing them through or on top of the platform and a
platform end-user who consumes these services and processes according to his or her business
goals. Note that design time is in general different for service provider and process designer.
Predefined compositions can be further distinguished into static and hybrid compositions. A
static process is usually defined with a business process development tool. An agent-based
modelling and service invocation environment is used, because it allows flexibility in service
composition in the sense that the services can be composed in a goal-oriented manner. Hybrid
processes could contain parts where the concrete service to be used at runtime would be
determined according to runtime information (late binding).
Predefined compositions constitute an essential part of business processes in service-oriented
architectures. The nature of many services requires adjusting the business process in terms of
process adaptation and data conversion. For defining and executing agent-based service
compositions, a modelling environment which allows specifying complex interaction and
workflow patterns for service composition and agent-based negotiations is developed (see e.g.
[4]).
14
For automatic service composition, the approach for semantic services in OWL-S to the COIN
scenario is adopted. For OWL-S, the conversion of services to the planning domain definition
language PDDL has been proposed (see [7]). In an analogous way, the conversion can be done
for WSML services. A WSML service with preconditions and post-conditions defined in a
capability is transformed into a PDDL planning operator with corresponding pre- and post-
conditions. To solve the corresponding planning problem, a PDDL planner can be used. The
result of an automatic composition is in general a sequence of services (see [2]).
2.1.5 Trust and Security
One of the challenges to be solved in COIN is to improve the security in enterprise
interoperability and collaboration scenarios, where it is important to guarantee the secure
interaction between parties. For doing so, traditional security mechanisms have been combined
with so called soft security mechanisms, more oriented to social-based solutions and other non-
functional aspects of the communication, such as trust on services, negotiation of trust-related
aspects for interactions and policy management.
All these elements have been combined in such a way that the information about trust is used as
input for the trust aspects in negotiation and policy management, while the result of the
negotiation, moreover, is an agreement which becomes a policy in the system, to be enforced
with traditional mechanisms already deployed in an Enterprise Service Bus (ESB). All the
components together, interacting automatically, conform the Trust, Security and Dependability
Platform (TSD Platform) in COIN, as seen in Figure 4.
The basic features are provided by the ESB, where typical components for basic security features
are deployed: policy enforcement, authentication and encryption/decryption, etc.
ESB
(PEP, PDP, STS)
Policy
Administrator
Trust
Negotiator
Trust
Manager
SOAP SOAP
Policies
TLA based Policies
Trust Value Trust Value

Figure 4 - Main components and relationships in the TSD Platform

The Trust Manager is a component which calculates the trust associated to services and service
providers based on a wide model divided in four main parts: General (location, releases, age,
etc.), Capability (announced functionalities and non-functional properties), Measure (monitored
values for response time, data volumes, scalability, agreements fulfilment, etc.) and Reference
(evaluation from users and other platforms, information in news, etc.). Using the monitoring
capabilities of the GSP Semantic Execution Environment and other information sources (service
description, information in DBs, etc.), it is able to perform different calculations based on a fuzzy
set and combined with a special weighted average which exploits an ontology containing
information about used aspects in the model and their relationships, performing a specific control
of the consistency between the aspects in the model.


15
One of the components which use the Trust Manager results as input is the Trust Negotiator,
which follows a two stages negotiation. In the first one, credentials are interchanged between
participants, in order to determine which information to disclose and how to advance the
negotiation. Once both parties trust on who they are, a set of concrete security terms are
negotiated (bits number for keys, minimum trust values of services and providers, etc). Finally, a
Trust Level Agreement (TLA) is obtained, and a policy is generated, for the TLA fulfilment.
The Policy Administrator is the component which receives the policies, performing a hot
deployment of those policies in the ESB components, retrieving context information required in
the policies (such as trust values). In the case several policies must be activated at the same time,
this component is in charge of merging the actions.
Finally, there is a portal which serves as a front-end for facilitating management tasks. It
accesses to the Trust Manager, the Trust Negotiator and the Policy Administrator for showing
information about trust values, negotiations performed and policies stored to administrative
users.
2.1.6 Peer-to-Peer Registry and Repository
This section describes the key motivations that were at the base of the definition of the
architecture for the Registry and Repository which are the main components of the COIN
Evolutionary and Pervasive Service Platform.
The strategy is to have a system that does not move data across the architecture when it is not
needed. The goal is also to support different architectures, namely: information, model, and
application.
The service is created and maintained by the service provider, while models are persisted in a
separate repository. Models are horizontal with respect to the information and are also shared
across services. This separation of concerns, as implemented in this project, helps to avoid data
replication and it aims at providing a better alignment between IT and the business.
Inside the COIN Evolutionary and Pervasive Service Platform, registered services are associated
to models that are stored in the Repository. A registry entry contains only attributes that are used
for:
consuming the service,
retrieving the business model instance,
retrieving information about the service vendor,
retrieving the WSDL associated with the service,
retrieving models that are associated with the service.
The service is thus described by models that are associated with it. A user who wants to find a
certain type of services must first of all search the models that contain the desired contents, and
then search for all the services associated with these models.
The Registry works like a DNS server: it does not contain any meta-data that describes services
but rather contains only information for associating a service to a model or an ID. Like a DNS
server, it must have a fully decentralized architecture for ensuring availability and reliability, and
also an automatic synchronization mechanism.
The Registry also manages the deletion of a registered service entry, to support the lease concept,
implemented by a 3rd party COIN component, which is external to the Model Repository and
Service Registry. A dedicated operation, in the Registry interface, is used to delete a specific
service entry.
16
The concept of template is introduced (as defined and used by Jini
8
) to improve models search.
To describe models are used tags as a folksonomy
9
, this is a way for creating a model description
that is driven by the community growing around models development.
The use of standards is considered very important in a project and in this way WSDL are used
for web services, the JAXR
10
API for storing and retrieving models.
Is also suggested the use of a service crawler and a data warehouse for performing data mining
on the data which is collected by inspecting business model instances. The data warehouse can
also contain model meta-data for performing powerful queries on clients requests. The
information contained in business model instances is collected by the service crawler that
retrieves them by querying the service provider, inspecting the business model instances and
reporting information to the data warehouse.

Figure 5 - P2P Repository/Registry Architectural viewpoint

2.1.7 Conclusion
This chapter clarified the notion of COIN GSP and its constituent parts. In the context of the
COIN system the platform serves as the broker, blending together needs of different service
provisioning stakeholders. In a nutshell, the COIN GSP is built on top of Semantic Web Service
technologies which enable basic platform functionality such as service discovery and invocation
in a federated manner. The platform is extended to meet the appropriate means to: establish trust
and security between the service provisioning stakeholders, provide agent-based (semi-)
automated service provisioning negotiation and composition facilities, and enable evolutionary
and pervasive aspects based on the usage of P2P service repository and registry. As such, the
platform provides the needed functionality to implement envisioned service provisioning
business models such as Software as a Service-Utility.


8
http://www.jini.org/wiki/Main_Page
9
http://en.wikipedia.org/wiki/Folksonomy
10
http://jcp.org/en/jsr/detail?id=93


17
References
[1] COIN Deliverable D3.2.1b, Evolutionary and Pervasive Service Platform, Final Specifications, 2010
[2] COIN Deliverable D3.4.1b, Business Knowledge and Negotiation Platform, Final Specification, 2010.
[3] Dieter Fensel, Holger Lausen, Axel Polleres, et al. Enabling Semantic Web Services: The Web Services
Modeling Ontology. Springer, 2007.
[4] Ingo Zinnikus, Xiaoqi Cao, Klaus Fischer. Agent-Supported Collaboration and Interoperability for
Networked Enterprises. In: Marten van Sinderen, Pontus Johnson (Eds.): Enterprise Interoperability. Proc.
of the Third International IFIP Working Conference, IWEI 2011, March 2011, Stockholm. Springer 2011,
pp. 204-215.
[5] J. Rao and X. Su. A Survey of Automated WebService Composition Methods. Proceedings of the1st Intl.
Workshop on Semantic Web Services and Web Process Composition, San Diego, 2004.
[6] Jorge Cardoso (edt.). Semantic Web Services: Theory, Tools and Applications. IGI Global, March, 2007.
[7] Klusch, M., Gerber, A. and Schmidt, M. (2005). Semantic Web Service Composition Planning with
OWLS-XPlan. Proceedings of the AAAI Fall Symposium on Semantic Web and Agents, Arlington VA,
USA, AAAI Press.
[8] Schahram Dustdar, Wolfgang Schreiner. A survey on web services composition, International Journal of
Web and Grid Services, v.1 n.1, p.1-30, August 2005.
18
2.2 The COIN Front End for Generic Service Platform Federation Consuming
Michele Sesana
1
, Sergio Gusmeroli
1
, Srdjan Komazec
2
, Davide Cerri
2
, Drago Trebenik
3

1 TXT e-solutions, Via Frigia 27, 20126 Milano, Italy
{michele.sesana,sergio.gusmeroli}@txtgroup.com
2STI Innsbruck, Universitt Innsbruck, Technikerstrae 21a, 6020 Innsbruck, Austria, {srdjan.komazec,davide.cerri}@sti2.at
3Joef Stefan Institute, Jamova cesta 39, 1000 Ljubljana, Slovenia
drago.trebeznik@ijs.si
Abstract
The involvement of users/stakeholders is a recognized key condition for the consumption of the GSP (Generic
Service Platform for EI/EC service delivery) federation and its further exploitation as well as the possibility to have a
fast and easy way to access the COIN system and to have a prior feedback about the system capabilities to further
adopt it in a deeper way. The COIN Front-End is the unique point of access (one-stop-shop) for both technical and
non-technical users of the COIN system, providing a set of functionalities for the consumption and evolution of the
Generic Service Platform Federation reported in the previous 2.1 chapter of this book. In this chapter two major
developments of the COIN Front End are highlighted and described. The first functionality is devoted to IT user/s
willing to publish their software products EI/EC services and/or platforms - through the COIN GSP federation. An
editable and customizable model of the federation is supporting the registration of new platforms and services, while
an interactive wizard is guiding the IT user step-by-step in the process of downloading COIN open source assets
platforms, services, knowledge bases, ontologies - in several forms (source code, binaries, pre-configured virtual
machines, open data and creative commons knowledge), configuring and customising them and finally linking them
to the existing federation and search-discovery-orchestration-execution functions. The second major development is
devoted to generic users, either registered or not registered, willing to know more about the COIN EI/EC services
and how to access and consume them. A Google-like semantic and contextual search engine is able to analyse
complex queries and find the best matching with COIN service and knowledge bases, while a service try-me
experimental facility is providing users with concrete hands-on technical and business use cases.
2.2.1 Introduction
The Generic Service Platform Federation described in chapter 2.1 is the upper level of the COIN
System, providing a big set of innovative functionalities to handle with registered services. In
order to fully exploit the federation capabilities, it is necessary to have a component able to
communicate with it in different forms and customised for different users and business cases
(automatic or human driven). In particular, in the presence of complex technological artefacts,
human factors in accessing and using conveniently the COIN GSP Federation are a key aspect
for its successful adoption and take-up: likability, friendliness, usability, but above all clear
messages about functionality, costs and business benefits need to be taken in due account; users-
stakeholders early and participative involvement could make the federation a real exploitable
asset of the project. In this chapter, the COIN Front End is described, a COIN System component
focusing on one hand to the consumption of the GSP Federation capabilities and on the other
hand to support the evolution of the system itself acting as a facilitator for the involvement of
service providers in the system.
The COIN Front End supports two access modalities: i) direct access by humans ii) API offered
for the usage by other IT systems. In COIN Front End design, two major users have been
identified to be part of the system: IT user willing to become service providers of different pieces
of software of the COIN System exploiting the evolutionary perspective of the solution and
Generic user willing to explore the COIN capabilities like services discovery, invocation,
composition, etc.. The Generic User is a non-technical person with few or no IT experience (e.g:
a businessman, a manager, a BP designer) without deep knowledge about ontologies
preconditions/postconditions and other technicalities of the EI/EC domain which are indeed
necessary to deeply understand the services the COIN system is hosting.
This book section focuses on the direct access to the Front-End by humans: sub-chapter 2
focuses on the Front End support to IT user, sub-chapters 3 and 4 highlight the access by non-IT


19
people defined as generic users. The following book chapter (2.3) provides a view of the CP
Federation accessing the GSP Federation through the COIN Front End API.
2.2.2 GSP nodes and Services provisioning to the GSP Federation
A single instance of a GSP can fulfil the requirements of scenarios characterised by limited scale
(i.e., in which a single instance can handle all the knowledge, e.g. ontologies and service
descriptions, and all the requests) and closeness (i.e., in which all the relevant knowledge is
available in a single instance, controlled by a single authority). There are however scenarios in
which the above assumptions do not hold, and which raise the need to support a distributed
deployment. Besides cases in which a distributed infrastructure is needed because of scalability
or dependability reasons, but it is still under the control of a single authority, there are scenarios
in which different GSP instances are established independently by different providers or groups.
These providers can then want to allow users of one GSP to be able to use also services provided
by the other ones, and therefore to federate their GSPs. In particular, we can distinguish between
emergent and planned distributed approach. An emergent approach is one in which
different GSP instances are established independently and grow and evolve in a Platforms
ecosystem, e.g. because they are owned by different providers / groups / consortia. A planned
approach is one in which the owner of a GSP decides that a single instance is not enough (e.g. for
scalability reasons, but also for different business models), and therefore needs to deploy a
distributed platform architecture which includes multiple instances. The two approaches can be
implemented at multiple levels: a distributed instance resulting from the planned approach can
act as a single node of the federation in the emergent approach. They are however different, both
technically (e.g., the planned approach naturally brings the accent to topics like scalability and
self-organisation, while trust between different instances is not an issue) and from a business
perspective.
The central question to address is whether the knowledge (e.g. the service descriptions) used by
each GSP node is local (i.e. every instance has its own knowledge, which is not directly
available to other instances) or global (i.e. each instance has access to the same knowledge, by
retrieving it from some globally accessible source, that is accessible to all GSP instances).
With respect to the two approaches, it is quite clear that in the planned approach the issue of
local or global knowledge is mainly a technical choice, because from a higher point of view the
distributed architecture is always seen as a single entity. On the contrary, the emergent approach
seems to present a much better fit with the local knowledge approach, as the owners / users of
each instance may want to keep their own knowledge (e.g. their own service descriptions) in
their own platform, and make it only indirectly accessible to federated platforms (i.e., through the
services provided by the GSP, e.g. service discovery). For this reason, and considering that the
global knowledge approach would be, due to the technical constrains, hard to realise in COIN
GSP, we follow the local knowledge approach. This means that each GSP instance has its own
repository which is not directly accessible to other instances, but only through the services
provided by the GSP. This does not exclude the presence of a more lightweight global
registry/repository used to store general information about GSP instances (used e.g. in order to
discover other GSP instances). Therefore, the starting-point scenario is a single instance
capable of discovering and invoking Semantic Web Services. Starting from this, we envision the
evolution of the GSP along three dimensions:
Goal decomposition and service composition,
ranking based on non-functional properties (nfp),
node federation.
These three dimensions can be used to define a cube, shown in Figure 6, which represents
possible evolutionary paths and points starting from the base. We now describe the issues to be
addressed in each of these scenarios (i.e., each vertex of the cube).
20
A
D
C
B
E
G F
base
+ federation
+

c
o
m
p
o
s
i
t
i
o
n
+

n
f
p

r
a
n
k
i
n
g
+ federation
+ federation
+

c
o
m
p
o
s
i
t
i
o
n
+

c
o
m
p
o
s
i
t
i
o
n
+

n
f
p

r
a
n
k
i
n
g
+

n
f
p

r
a
n
k
i
n
g

Figure 6 - GSP evolution cube

While moving through the cube node the following scenarios and their characteristics are
identified:
Scenario A (Base) in which there is a single GSP instance which is capable to discover and
invoke single services that match the users goal.
Scenario B (Federation) in which each node must be able to forward the user goal to other
nodes. In larger scale deployments a mechanism to identify a subset of relevant nodes as
targets for forwarding the request is needed. Such mechanism can exploit some
specialisation of the nodes (e.g. w.r.t. the domain), however, especially in the emergent
case, this is not by design. Moreover, all nodes will be capable of offering more or less the
same functionalities (discovery, invocation, etc.). Therefore, a lightweight mechanism can
be appropriate, based on some simple categorisation (taxonomy or simple ontology). Such
a mechanism is called COIN GSP Model and it is described below.
Scenario C (Single instance with service composition) in which a composition of services
that can fulfil the users goal, rather than only a single service, can be identified as a match.
Scenario D (Federation with service composition) which is the composition of scenarios B
and C. In this scenario, each node can forward the goal to other nodes as in B, decompose
it into subgoals as in C, and forward subgoals to other nodes. Different decompositions
may be realised by different nodes.
Scenario E (Federation with nfp ranking) which is built on top of scenario B (federation),
adding ranking based on non-functional properties. The federated architecture implies the
fact that multiple lists of matches, coming from different nodes, need to be merged, taking
into account ranking.
Scenario F (Single instance with service composition and nfp ranking) which is built on
top of scenario C (single instance with service composition), adding ranking based on non-
functional properties. In this scenario, matches can be composed by one or more services,
so there is a need to define nfp-based ranks for compositions of services, rather than just
for single services.


21
Scenario G (Federation with service composition and nfp ranking) which is the most
complex scenario, built on top of scenarios E and F. It includes all the three dimensions we
considered.
It is worth noting that each and every next step is adding additional complexity level, thus asking
for advanced solutions when treating interdependencies. COIN project has provided solutions for
the scenarios A, B, C and D while the more complex cases, i.e., scenarios E, F and G, are
considered as future work.
In a federated environment, the different nodes (i.e. GSP instances) of the federation need to be
characterised, so that requests can be directed to nodes that can be able to fulfil them. This
encompasses two different aspects:
Functional aspects. These cover both the functionalities of the GSP itself (i.e. from
service discovery to service invocation) and the functionalities of the services registered in
the GSP. While the former ones can be seen just as regular service platform descriptions
(i.e. what a single GSP node is able to do in terms of service discovery-execution
monitoring cycle, including intelligence, negotiation and decomposition capability), in
order to cover the latter ones, some aggregated and more complex [semantic] descriptions
are needed. In the COIN federation this is done through a functional taxonomy: federation
nodes are therefore annotated with the categories of services registered at them. These
annotations are used for service discovery, in order to decide to which nodes of the
federation a goal (i.e. a request to discover services) should be sent.
Non-functional aspects (e.g., availability, reputation, price). Again, descriptions covering
these aspects can be applied both to the GSP itself and as an aggregated image of the
services registered at the GSP. Non-functional aspects are used together with functional
aspects to support the decision process in discovering and selecting Web services, and in
particular for ranking purposes. A typical case is when two or more services are
functionally equivalent (and thus can functionally fulfil the users goal), but they differ in
some non-functional aspect (e.g. the price). The problem of how to aggregate and
harmonize end-to-end different, heterogeneous non-functional aspects and policies at both
platform and service levels is still an open research domain, which COIN is just partially
and incompletely addressing.

In order to describe federation nodes according to these dimensions, COIN provides a set of
ontologies, as shown in Figure 7. At the top there is the COIN Federation Ontology, which
defines fundamental concepts such as Service Category and Federation Node. On the lower
level, the COIN Platform Taxonomy describes services offered by the node itself, the COIN
Functional Taxonomy provides categories for registered services, and the COIN Non-Functional
Property Taxonomy is used to describe non-functional aspects. All taxonomies are modelled
using SKOS [1]; a fragment of the COIN Functional Taxonomy is shown in Listing 1.
22

Figure 7 - COIN GSP model ontology stack



Listing 1: Fragment of the COIN Functional Taxonomy

This model is used in the COIN Front-End by IT User/s, who are able to build and develop their
own solutions and to link them to the COIN IT System; the COIN Front-End provides a specific
kind of access and set of functionalities allowing him/her to explore the COIN technical assets
(source code, binaries and pre-configured virtual machines), to download and customize them
<http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl> rdf:type owl:Ontology ;
owl:imports <http://www.w3.org/2004/02/skos/core> ;
owl:imports <http://www.coin-ip.eu/ontologies/COINFederationOntology.owl> .

:COINFunctionalTaxonomy rdf:type cfo:ServiceTaxonomy ,

:EnterpriseService rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:topConceptOf :COINFunctionalTaxonomy .

EnterpriseCollaborationService rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseService .

:EnterpriseInteroperabilityService rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseService .

:Messaging rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseCollaborationService .

:SMSMessaging rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :Messaging .

:EmailMessaging rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :Messaging .

:CollaborationNetwork rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseCollaborationService .

:DataTransformation rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseInteroperabilityService .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix cfo: <http://www.coin-ip.eu/ontologies/COINFederationOntology.owl#> .
@base <http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl> .
@prefix : <http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl#> .


23
and finally to exploit such assets by creating a new federation node and merging it in the COIN
GSP Federation (upper cloud of the COIN butterfly model). The human computer interaction
primitives have been specifically designed to support a technical person. New services
registration functionality is also provided by GSP nodes and briefly described afterwards.


Figure 8 - COIN Assets Download

The previously presented model is provided as a wizard to the IT user through the COIN Front-
End; it is pre-configured at the time the user accesses the menu and divided into three different
forms. The user has just to complete the template and to insert the new GSP node characteristics.
Finally the submit form makes the description available to the federation authority that will
check and approve/reject it.

Figure 9 - GSP Model Configuration

The node creation process should be mediated by the COIN Federation Authority taking in
charge of the control of the compliance of the new GSP node registration to the federation.
Browse
Download
24

Figure 10 - nodes waiting for approval

The prerequisite to register a new service at a COIN GSP node is to build its WSMO [3]
compliant semantic description. Such a description dictates, in a formal and unambiguous way,
functional (service capability and behavior) and non-functional (e.g., price, reputation, reliability,
etc.) service aspects. In order to reduce complexities while building the description COIN has
developed a Web-based wizard consisting of five consequitive forms focusing on different
semantic Web service description aspects. Apart from the Web form shown at Figure 11 (which
provides a user friendy way to define service pre-/post-conditions) the other forms include
definition of general Web service atributes (service name and namespace), definition of non-
functional properties (e.g., service price), and definition of behavioral aspects (service
choreography).

Figure 11 - The Web form for defining service pre-/post-conditions



25
2.2.3 Consume the GSP Federation by a Human Oriented Interface
As stated in the introduction, the consuming of GSP federation by non-technical users (e.g.
business man, managers, BP designers) is very important to actually exploit the COIN system.
The generic user is defined as a person willing to explore through a simple web interface the
COIN capabilities like services discovery, invocation, composition, etc. In addition to that,
he/she is a non-technical person with few or no IT experience and without any deep knowledge
about ontologies preconditions/postconditions and other technicalities of the EI/EC domain and
he does not have time/willingness to learn any technical stuff. The COIN Front-End provides this
user with a set of functionalities to explore the COIN assets through an interface and features
specifically designed to support this kind of non technical person and guiding him through in the
COIN assets exploration and understanding. The implementation of the system for the Generic
user comprises the GUI by which the user can access the functionalities visible in Figure 12.

Figure 12 Generic User Functionalities

Services searching by templates allow the user to browse services and interrogate the GSP
federation searching for services. Browse&Search (semantic search) are guided by templates:
pre-configured goals that the user can easily customize for its searches. The understanding of
COIN assets is based on two main streams: on the one hand, knowledge about the service and its
reputation is provided; on the other hand the user can try the services (both automatic web
services and interactive services) from the user interface. The knowledge is based on the
Semantic Media Wiki [2], a free, open-source extension to MediaWiki based on an ontology
driving the link between contents. The user is involved in the process with an additional
functionality that allows him/her also to subscribe to a news notification service about some
goals: for example in case the businessman is not satisfied by found services or he/she did not
find anything, he/she can subscribe itself to the goal created (e.g: transformation from Format a
to Format b) and receive information on further registered services matching with this goal.
Interactions between the COIN Front-End for the generic user and the other components of the
COIN System are depicted in Figure 13
26

Figure 13 - COIN Front-End deployment schema and COIN System upper Cloud interaction

The access to the tool could be done anonymously or by a simple registration (username,
password and email address to receive notifications about services). The Browse & Search
interface (Figure 14) guides the user in the process of easily composing a semantic search; the
panel is composed by 5 main parts:
1. Search scope defining the scope of the search (one specific node or the whole federation).
2. Functional Concept Selection this interface allows the user to select, on top of a
functional taxonomy, the desired functionalities that the service should fulfill. Concept
can be accessed in three different ways: i) exploring the taxonomy tree ii) typing in the
fast search the initial characters of the word iii) insert free text in the proper free text
box and let the system interpret the text and match it with the taxonomy (please refer to
the next subchapter for more details)
3. Template Box: to simplify the creation of the semantic search, a set of templates
associated to functional taxonomy concepts are provided; few intuitive clicks by the user
are enough to create a correct request for the GSP federation.
4. Suggestion Box automatically at the time a functional taxonomy concept is selected, the
system does a fast search to the closest GSP and retrieves some services to be presented
to the user. The search is done by a fast SPARQL query. The goal of this box is to
provide the user with a fast check about what he/she will retrieve with the further
semantic search.
5. Semantic Search based on the selected template, the structure of the semantic search is
provided. User has to click on all the trees visualized selecting the concepts closer to
his/her wishes. Selecting the roots of every tree the user will create the higher level
search available. Clicking on leaves the search will be more specific. The search can be
tailored by the user on its need using the non functional properties expressing its own
preferences that will rank found services; price, reputation and time are available for this
purpose.



27

Figure 14 - Browse & Search interface
Clicking the submit button, a new form shows found services. In this case the search is semantic
and involves the GSP federation. The system hides completely the details of the search process
that is not relevant for the user. As better visible in Figure 15 results are divided in three different
areas:
Exact Match (services marching exactly with user whishes)
Plugin (services more specific in respect with the request)
Subsumption (services less specific in respect with the request)

Figure 15 - detail of the semantic search results

For each service found, the system provides a small description of itself; to let the user
understand better the service purpose and capabilities the system provides different
functionalities accessible by buttons close to the service description:
28
Try-me button shows a pop-up able to invoke the corresponding service. The form is
created automatically starting from the ontological description of the service returned by
the GSP to which is registered.
Wiki The wiki button drives the user to the second tab of the interface (maintaining all
the data in the previous tab) opening the wiki page describing the service. Depending of
the service different information is displayed containing in some cases the example I/O
files for the service test.
Trust button displays summary information of the selected service. A global value is
provided and four sub values composing the global value are detailed: i) general, ii)
capability, iii) measure and iiii) reference


Figure 16 - from the left: try-me button form, trust values and COIN SMW for information on the service

2.2.4 Guiding User Semantic Search by Free Text Wishes Expression - JSI
Free Text Wishes Expression (FTWE) service is aimed at helping users to use natural language
expressions for efficient search through various text descriptions in COIN platform. The first
case in which the service has been used is the natural language search through the extensive
COIN services registered.
The main feature behind is that the free text query as well as documents contained in the COIN
Semantic Media Wiki are being processed through the Enrycher service pipeline. Both
constructed triples graphs are then being matched. By using similarity measures the hit ranks are
being calculated and presented in a ranked list of hits. Figure 17 presents the main FTWE
pipeline which consists of four main service sets that are manipulating texts from the language
level to the document level.
Lnr
CCln LemplaLe
descrlpLlons daLaseL
LAnCuACL-
LLvLL
8CCLSSlnC
Ln1l1?-LLvLL
8CCLSSln
Ln1l1? C8AP
8CCLSSlnC
uCCuMLn1-
LLvLL
8CCLSSlnC

Figure 17 - FTWE pipeline

Languagelevel processing are background services that include sentence splitting, tokenization,
part of speech tagging and entity extraction. Entity-level processing services identify potential
entities. This is done with anaphora resolution, where pronoun mentions are merged with literal


29
mentions, co-reference resolution that merges similar literal mentions and entity resolution,
which links the in-text entities to ontology concepts. Document-level processing operates on the
document instead of entities. Here we first construct semantic graphs out of extracted triples
using several entity and context matching methods. In such graphs nodes are entities (objects,
subjects) that are connected with relations presented by verbs. Such graphs are then being used
for matching functionalities in search but also for other more semantically heavy features like
ontology construction services, taxonomy categorisation and summarisation. Figure 18 presents
the complexity of the enrichment services.

Figure 18 - Enrichment services

This is why all textual documents (templates descriptions in our case) are being processed and
enriched and presented as a graph of triples of all descriptions. The created graph is then used to
create inverted index that enables fast, cheap and efficient search.
FTWE service also includes heavy semantics features like classification, overall semantic graph
construction out of n-grams, cross lingual support and reasoning. In the service search case these
features are not being used since it would be too costly in respect to the preferences. For other
COIN services that are using large scale document repositories like process descriptions, reports,
formalised descriptions, external databases, etc, these features can be easily switched on. By
including neutral language representation model that are being constructed out from many
multilingual aligned corpuses some additional features dealing with cross and multilingualism
can be implemented i.e. multilingual search, cross-lingual search, graphs (ontologies) translation,
language detection, etc.
2.2.5 Conclusion
The implementation and the availability of the COIN Front End for accessing the COIN Generic
Service Platform Federation allows the involvement of stakeholders who are not yet connected to
the COIN system and supports the loyalty of existing stakeholders in collaborative networks
using the COIN Collaboration Platform (see chapter 2.3). The early and participative
involvement of final users is a recognized key condition for the success of the GSP federation
and for further take-ups and exploitation opportunities. There are two major developments
reported in this chapter. The former one is related to the nodes and services in the GSP
Federation and supports IT user/s willing to publish their software products through the COIN
System, an editable and customizable model of the GSP is provided to support the registration of
30
a new GSP node to the federation and a GUI supports the user in the process of downloading
COIN assets in several forms (source code, binaries and pre-configured virtual machines) and of
providing new ones. The second major development is the support to the generic user by
Consume the GSP Federation by a Human Oriented Interface and Guiding User Semantic
Search by Free Text Wishes Expression. By using this interface non-IT user/s can easily search
for COIN services, understand them by accessing related knowledge and experiment them. The
COIN Front End has been integrated in the Final COIN System and demonstrated in COIN
project reviews.

References
[1] SKOS Simple Knowledge Organization System Reference, W3C Recommendation 18 August 2009,
http://www.w3.org/TR/2009/REC-skos-reference-20090818/
[2] Semantic Media Wiki http://semantic-mediawiki.org/wiki/Semantic_MediaWiki
[3] Dieter Fensel, Holger Lausen, Axel Polleres, Jos de Bruijn, Michael Stollberg, Dumitru Roman, and John
Domingue. 2006. Enabling Semantic Web Services: The Web Service Modeling Ontology. Springer-Verlag
New York, Inc., Secaucus, NJ, USA.


31
2.3 The COIN Collaboration Platforms Federation for Enterprise Networks and
Business Ecosystems
Michele Sesana
1
, Sergio Gusmeroli
1
, Jens Eschenbcher
2

1 TXT e-solutions, Via Frigia 27, 20126 Milano, Italy
{michele.sesana,sergio.gusmeroli}@txtgroup.com
2

BIBA - Bremer Institut fr Produktion und Logistik GmbH, Hochschulring 20, 28359 Bremen, Germany, esc@biba.uni-bremen.de
Abstract
In a global economy, Enterprise Collaboration represents the most promising solution for European industry (and
SMEs) to stay competitive and to continuously innovate its products and services. IT support to collaboration among
the members of a networked enterprise, being it a supply chain, a collaborative network or a business ecosystem, is a
central point of the COIN system. The possibility to promptly react to a Business Opportunity (BO) building Virtual
Organisations, managing the operational and dissolution phase as well as the support to the interoperability among
different partners is addressed by the COIN Collaboration Platforms Federation. In this paper it is presented how
COIN supports networked enterprises by the COIN Collaboration Platform (CP) illustrating its functions,
characteristics, BPM facilities and the implementation connected to the other parts of the COIN system allowing the
injection of a smart support in the construction of the collaborative business processes. At the end of the paper, the
concept of Extended Products and Distributed Collaborative Innovation in Virtual Factories is also introduced as a
promising future research topic in which the support on networked enterprises by COIN Collaboration Platforms
federation could be exploited.
2.3.1 Introduction
In the overall COIN Vision, networked enterprises are organized in supply chains, collaborative
networks and business/innovation ecosystems. Their collaboration is often supported by IT
Collaboration Platforms (CP) and whenever cross-network interconnection is needed the
community of CPs in different domains and sectors needs to be supported by an open and trusted
federation of CPs. Lets imagine for instance cross-sector collaborations like those established
between textile industry and automotive to build innovative car seats covers, between furniture
industry and shipbuilding to build cruise ships interiors resistant to marine environments; or also
imagine cross-domain collaborations when a product-oriented collaboration (design,
development, production, post-sales, end-of-life) needs to be extended and complemented by a
service-oriented collaboration (service life cycle management to be reconciled with the PLM) or
by a market-oriented collaboration (marketing & sales, new business and revenue models, online
vs. physical selling).
In the COIN interpretation, Collaboration Platforms [1] [2] [3] provide utilities for social
collaboration (e.g. wikis, blogs, communities, user profiling), knowledge collaboration (e.g.
repositories, search engines, up- down-load facility, classification) and business collaboration
(e.g. workflow, workgroup and business process management services). A Collaborative
Platform is not a monolithic and static entity but it is very modular and easily composable in
order to adapt itself to the specific characteristics of the enterprise network, giving to every
cluster the possibility to work in a personalized environment built on top of their specific needs
such as domain, sector, country, i.e. via the ontology for classifying documents or the ontology
for classifying human competencies in the different domains. Next chapters of this paper will
show how COIN supports Networked Enterprises and Business Ecosystem by a Collaboration
Platforms Federation.
2.3.2 Modelling, executing and outsourcing cross-enterprise collaborative business processes
The lower cloud of the COIN System (please refers to the introduction of chapter two for more
information) is composed by an incremental set of domain- and sector-specific COIN and non-
COIN Collaboration Platforms (CPs).
32
2.3.2.1 The COIN Collaboration Platform: main functions and characteristics
The COIN collaboration platform provides a complete set of collaboration functionalies to
support the human collaboration on the CP; the basis set of fuctionalites provided natively by the
portal is increased by COIN service (both baseline and innovative) that can be plugged into the
environment; messaging services, maps about the human collaboration in the portal, blogs,
shared calendars are just a part of the big set of collaboration services available. The huge data
set of the portal composes the Knowledge Base of the cluster that can be used as base for further
smart services.
COIN Collaboration Platforms are also addressing web services to implement business
processes: such web services allow the integration of legacy databases and legacy system and the
direct invocation of EI/EC services. Such web services could be concentrated in the center of the
network (hierarchical supply chains) or be fully distributed among the network partners,
depending on the organizational form chosen by each network. In any case, a distributed or
concentrated Enterprise Service Bus, interoperable with the ESB of the COIN EI/EC Platforms,
is the best technical solution to integrate them.
2.3.2.2 The COIN Collaboration Platform in the COIN System: the BPM facility
A first key aspect of the COIN System is how to connect the Internet of Enterprises (including
hierarchical and non-hierarchical collaboration forms) with the Internet of Services (including
clouds of automatic web services and user generated services perhaps generated from linked
open data), i.e. to link service providers with service consumers or to finally bridge the gap
between IT and Business in the field of EI/EC obviously. For instance, it is foreseen that big
ESA (Enterprise Software and Applications) providers will soon put in the public domain or
provide at a very low cost their interoperability services/information as an adjunct to their Cloud
SaaS offer (e.g. under freemium-like business models); on the other side, the Service Web and
Linked Open Services movements will allow non-profit and/or standardization organizations to
publish their open standards and specifications to support every single Internet user (SMEs,
micro-enterprises but also individual entrepreneurs) in developing and using his/her own EI/EC
solution. The COIN system is giving visibility of both Internet of Services opportunities to the
Internet of Enterprises.
Secondly, in a Future Internet perspective the same challenge could be seen as how to link FI
platforms services (in this case EI/EC services) with Smart Socio-technical Applications (in this
case Smart Enterprises). In the FI PPP, the so-called Core Platform is providing Generic
Enablers to be accessed, composed, customized and used by the chosen Use Cases (ICT for
environment, healthcare, transport, mobility, smart city, safety, etcetera). COIN adds a new layer
to the Core Platform Generic Enablers with its EI/EC utility services and knowledge, some of
them domain-independent (e.g. UBL data transformation services), some others domain-
dependent (e.g. Odette or MODA-ML data transformations). In this perspective, COIN can be
seen as an additional layer to the FI architecture centered upon the Core Platform.
A third key aspect of COIN System is the distinction between service engineering-development
platform and service delivery platforms. A service delivery platform is a catalyst for service
providers who already developed their own services and just want to give them visibility and
access to service consumers (i.e. providing utility services for easy registration, search,
discovery, orchestration, composition, execution, authorization-authentication-accounting,
monitoring); a service engineering platform is instead providing an Integrated Development
Environment for IT professionals (e.g. a Service Development Kit) and/or for nave providers
(e.g. a Mash-up environment) in order to facilitate the creation and development of new services.
Indeed, COIN was initially conceived with the notion of being a GSDP (Global Service Delivery
Platform) for EI/EC services and the notion of development platform was just marginally
addressed. In fact, the COIN view of Plug-Switch-Tap evolution is suitable for industrial end
users willing to access EI/EC services, as normal telephony users see the different contracts with


33
operators: in a plug mode you just need the right adapter in order to change operator; in a switch
mode you can close your contract with one operator and open a new one on-the-fly and in a
seamless way; in a tap mode several parallel contracts do exist and an intelligent decision support
system (fully automatic in some cases) is able to dynamically match and select the best offer
with users requests, also within the same day, the same hour or the same phone conversation.
More recently, the convergence between user-oriented development platforms and globally
accessible delivery environments (e.g. the so-called Application Stores) as well as the open
innovation, crowd-sourcing and co-creation societal trends has inspired in COIN a fourth
evolutionary step (named EI/EC Store) where the borders between development and delivery is
blurring. In this Store evolution, the need for model-driven architecture methodology and tools to
bridge the gap between CIM-PIM-PSM specifications is becoming more and more urgent again,
calling for a new revision of EI life cycle under this new Store dimension.
The key question of the COIN System is How to integrate the life of Enterprises with the
Internet of Services and simultaneously taking into account the three aspects of: i) The co-
existence of Cloud Computing SaaS and Open Services; ii) The architecture of the Future
Internet and its first implementations; iii) The Store model and the convergence between
development and delivery platforms?
In the COIN system architecture, the role of zip between the two clouds is played by our
Business Process Management facility of the Collaboration Platform. We in fact postulate that
business men design and develop their collaborative business processes across organizations and
across their information systems, this way encountering and facing collaboration and
interoperability gaps.
Business Interoperability challenge in COIN is intended neither horizontally (different
languages to express BPs at the same level of abstraction, e.g. xPDL or BPEL), nor vertically
(same notations/language at different levels of abstraction e.g. CIM-PIM-PSM), but across
organizations: how to synchronize internal Business Process across organizations, by avoiding in
the meantime interoperability gaps like deadlocks, interface mismatches and
synchronism/visibility problems derived from the juxtaposition of BP pieces, which are
individually correct but do not work well if put together in collaboration.
The COIN BPM facility is therefore facing:
i. The co-existence of Cloud Computing SaaS and Open Services. In the EI/EC domain,
there is the co-presence of de-jure open standards, de-facto industrial standards (mostly
not open) and a myriad of non-standard solutions which however are the most simple and
immediate solution to EI/EC problems. For instance, we have well defined de-jure
standards for Automotive, Fashion, Furniture Business Documents interoperability, as
well as de-facto standards given by software vendors like IBM or SAP or Oracle.
However, both resources solve just a minimal part of the EI/EC problems and in most of
the cases, the most simple and cheap method is to look for a similar case and adapt the
existing solution to the new requirements or to dynamically compose together micro-
services solving micro-gaps into an overall solution. The COIN BP facility shall have an
efficient and rigorous access to well coded standards as well as a more intuitive
constructionist approach in the absence of standards and in the presence of a myriad of
solutions available in the open Internet (e.g. support to the so-called federated approach
to interoperability).
ii. The architecture of the Future Internet and its first implementations. In the
preliminary FI Architecture, three main functions are deemed necessary to link core
services with applicative services: virtualization, self-management and orchestration. The
COIN BPM facility represents the orchestration function but with a much wider
perspective than just sequence of web services. One important aspect in COIN is the
possibility to hide from the business men all the technical details of the EI/EC
34
implementations by providing him/her a semi-automatic decision support for the
selection and implementation of the most suitable EI/EC services.
iii. The Store model and the convergence between development and delivery platforms.
In the EI/EC domain, it is very seldom that a given automatic service is best suitable for
many domains and processes: in most of the cases, a process of adaptation and
customization is necessary. In COIN we have automatic web services (to be invoked and
executed without any human intervention and control) and more interactive EI/EC
services which in most of the cases are development environment of customized and
specific EI/EC services (e.g. the semantic reconciliation suite for Business Documents
interoperability). The former ones are therefore available in delivery platforms and
juxtaposed into BPEL automatic service execution environments; the latter ones are
instead activated as intelligent wizards and drive the end-users towards the development
of the required service. In this sense, the Store paradigm is implemented in COIN.
For implementing our BPM facility, weve identified three possible evolutionary steps:
i. Step I, where EI/EC service demand/offer is not supposed to vary along time and also
among different instances of the same business process. In this case, the process of
selection-composition-juxtaposition of EI/EC services can be performed once at design
time and remains unchanged for long time. The human business user is therefore
prompted with the interactive COIN Front End interface where he/she could select the
most suitable service and then link it permanently with the business process in question;
ii. Step II, where EI/EC service requirements are supposed to vary along time for instance
among the different instances of the same business process. The process in this case is
semi-automatic, as the COIN system is invoked by means of automatic APIs, the
selection of the best combination of services is manual, while its juxtaposition into the
chosen instance of BP is again automatic.
iii. Step III, where EI/EC service requirements either change very dynamically or depend on
the execution time of the business process. In COIN, we have identified two distinct Step
III scenarios where human collaboration EC services are automatically selected on the
basis of the context (e.g. user, his/her location/presence, his/her device) in a projects
meeting life cycle domain; and where data interoperability EI services are automatically
composed on the basis of the organizations, their accepted data formats and data access
services.
The three steps are to be intended neither incompatible nor exclusive: for instance, in the same
BP we could have cases where Step I is more suitable, or Step II, or Step III.
2.3.2.3 The COIN Collaboration Platform implementation
The CPs, beyond supporting the collaboration environment for Supply Chains, Collaborative
Networks and Business Innovation Ecosystems, provide the industrial user (business man of
the companies clusters) with a set of functionalities based on the API of the COIN front end
communicating with the GSP federation (please refers to chapter two introduction for more
information). Using them, the Industrial user can access to the whole set of COIN system
functionalities and services to integrate its collaborative environment supporting the whole
product/service life cycle, integrating legacy systems and data and legacy services the COIN
services in a smart way. As mentioned above, there are three different integration scenarios
connecting the CP functionalities to the other components of the COIN System.
The CP Integration Step 1 (Figure 19) is the integration of COIN EI/EC services into some
business processes / workflows in the COIN Collaborative Platform. This means that the
Industrial User needs to insert by hand the end-points of the services in the lowest level of
his/her business process.


35
COIN Collaboration Platform
Knowledge Interaction Social Interaction
Business Interaction
Start
End
Service1 EI Service2 Service3 EC Service4
COIN Collaboration Platform Service Bus

Figure 19 - Industrial User - CP Integration Step 1

The CP Integration Step 2 [4] for the industrial User is the integration between COIN CP and
COIN EI/EC Platform through the API and interfaces of the COIN Front-End. All the
EI/EC Services are brought to the EI/EC Platform and subject to the basic USs of the platforms:
search, composition, negotiation, models distribution. In the BPs of the COIN CP, the Industrial
User (Business Manager) can inject some Service Requests to be managed by the EI/EC
Platform and transformed into service end-points (automatically or semi-automatically). In
implementation terms, there is a Business Process pre-processing (preparation for execution)
phase at modeling time where all the service requests will be sent and substituted with the
relevant service endpoints. If some of them are service generation environments they will be
executed again before the execution time of the BP.
COIN Collaboration Platform
Knowledge Interaction Social Interaction
Business Interaction
Start
End
Service1 Service3
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
Service1 Service3
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
COIN EI/EC Service
Platform
EIServiceRequest2 ECServiceRequest4
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
COIN EI/EC Service
Platform
EIServiceRequest2 ECServiceRequest4
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
COIN EI/EC Service
Platform
EIServiceRequest2 ECServiceRequest4
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
Service1
EI
Service2
Service3
EC
Service4
Service1
EI
Service2
Service3
EC
Service4

Figure 20 - Industrial User - CP Integration Step 2

The graphical User Interface used by the Industrial User to search for EI/EC services is an
adaptation of the Front-End interface accessed by the individual User and providing all the
functionalities of that interface like: search, invocation, ranking based on non-functional
properties, subscription, etc. Finally the user can download the endpoint of the found service in
its own business process.
36

Figure 21 - Injection in the business process of a discovered service

The CP Integration Step 3 [5] aims at injecting smartness in the discovery, link, and usage of
COIN services in the Industrial User business process. This integration process leveraging on
COIN Front-End APIs used to solve in a semi-automatic way a particular set of EI gaps that can
be generalized in the future to cover a wider spectrum of gaps. During the project two
evolutionary solutions have been experimented.
COIN Collaboration Platform
Knowledge Interaction Social Interaction
Business Interaction
Start
End
COIN EI/EC Service Platform
US EI Service2 US EI Service2
EI: Service3
after Service1?
EI: Service3
after Service1?
SaaS Platforms
(legacy systems)
Service1
Service3
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Service1
Service3
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Service1
Service3
Enterprise
Applications
VAs
Enterprise
I/op / Collab.
VAs (Tools)
GSP + EI/EC
U. Services
EI
Service2
EI
Service2
Service1
Service3
Service1
Service3

Figure 22 - Industrial User - CP Integration Step 3

In CP Integration Step 3 for EI aims to solve in a semi-automatic way a particular set of EI gaps
that can be generalized in future implementations to cover a wider spectrum of gaps. The basic
idea of integration step 3 EI is that some EI Services will be specified and requested to the EI/EC
Platform (namely the Value Added EI/EC Services, similarly to Step 2), while some other EI
Services are automatically identified and juxtaposed in the BPs. The two steps could be in
sequence (first EI/EC VAs discovery and then automatically insert the USs ones) but perhaps the
selection of the VAs could be dependent on the USs available, so a closer interaction could be
needed.
The implementation of the EI scenario has focused on the format transformation case in which
the Industrial User could have some format mismatches between electronic business documents
and need, in a smart and automatic way to find a solution. The process for the identification and


37
solving of gaps is available as flow diagram in Figure 23 and based on three cross lights. If the
process check ends without problems the green light is activated and the process could be
executed at runtime. Otherwise gaps identified are warnings or errors. In the first case the gap
could be solved manually changing the business process due to the fact that in the CP knowledge
base are available the formats to accomplish the cooperative work. In case of red light the
services are searched by the COIN Front-End API. If the transformation service is found it is
inserted in the business process that will be checked again before to be run. In the other case
(service not found) the same interface will automatically search for services able to create that
transformation. The generation of the service is manual while the registration of it in the GSP is
automatic; at the end of this process the service is searched again, then found and inserted in the
business process.

Figure 23 - GAP Identification - Flow diagram

The following picture describes the technical overview of EI Step 3; novel developments are on
top of the business process to connect the different items and the connection with the Front-End
API.

Figure 24 - COIN Step 2 Overview
38

1. In the workflow modeler has been created a button; clicking it the XPDL file is sent to the
CBPip web-service (COIN WP5.4) that identifies if there are gaps concerning electronic
business document formats to be exchanged by different actors together with the
permission to access the CP Knowledge base (KB) in which resides the registry of services
of the companies of the cluster. By this KB the service can identify if the mismatch could
be solved inside the cluster or if needs a new external service.
2. If there is an identified gap the user can click on the submission button and send the
request to the GSP federation to fill the gap (e.g: Input invoice in F1 or F2 and Output
invoice in F4 or F5).
3. The GSP federation will search for a direct transformation between formats; if there is a
transformation will be returned to the caller to be inserted in the business process. If not the
federation will search for a composition of services by usage of just PRE or POST
conditions match. If the transformation is found it is returned; null otherwise. The
management of the reasoning in the GSP is handled by the negotiation tool.
4. In the worst case (no direct or composed transformation available) the user is redirect to
search for a service able to create this transformation (e.g: SP5.2 data interoperability
services).

At the time a new web-service able to perform the needed transformation is created the data
interoperability service supports, in a semi-automatic way, its registration in the GSP. This
allows the further reuse of it, increasing the number of services available in the GSP federation.
Without inserting anything the system sends the right credentials to the GSP Federation and
shows the output to the user (Figure 25) that can select one service to be linked in the business
process to solve the gap.


Figure 25 - Transformation Found


Figure 26 - Available Transformations


Step 3 for EC [5] aims to solve in a semi-automatic way a particular set of EC challenge that can
be generalized in the future to cover a wider spectrum of challenges. The focus of the EI
implemented scenario is the message notification applied to a virtual meeting process (provided
by the MSMS service COIN WP 4.4). The system allows the user to dont lose time in notifying
other meeting participant but the system take in charge of it.
In Figure 27 is depicted the architecture of the Integration Step 3 for Enterprise Collaboration


39

Figure 27 - Process Overview

The execution process is composed by several steps:
The user access to a step willing to send messages to individuals (people). The step has
an ontological description that is sent to the Step 3 EC interface based on COIN Front End
API with other parameters:
a. virtualTeamID: containing the IDs of individuals targeted; it comes from the
COIN CP centralized database;
b. Ontological description: pre/post conditions of the needed service, e.g:
messageSent(message, individual, individual)
c. message: string identifying the message to be sent
The interface send the parameters to the expert system that, after a data gathering from
the Knowledge Base, evaluates rules, choose the right terms of the EC ontology, build a
goal and send it to the GSP federation
The GSP federation finds the service and execute it passing the message parameter coming from
the Step 3 EC interface. In tests the Collaboration services from WP4.1 have been used as targets



Figure 28 - automatic execution

40
2.3.3 Extended Products and Distributed Collaborative Innovation in Virtual Factories
The discussion of extended products and distributed collaborative innovation in Virtual Factories
raises a complex discussion. Basically it is necessary to briefly introduce the concept of extended
products, distributed and collaborative innovation processes in order to discuss their
implementation in Virtual Factories.
2.3.3.1 Extended products
The origin of the extended product concept can be clearly traced back to product-centric
engineering and their relation to service engineering in the nineties. Consequently the basis for
the development of the extended product concept was a discussion on product engineering,
innovation processes and virtual, extended enterprises which took place in parallel.
The discussion on product and service engineering that took place in the last centuries (Chao,
1993, Aurich et al 2006, Mont 2002, Bowen et al. 1989). Both time-to-market and service-
product offer leverage to gain sustained competitive advantage. A paradigm shift is taking
place from consumers buying products towards consumers buying solutions and benefits
(Thoben 2003).
Additionally there was an intensive debate on the virtual, extended enterprise concept
(Jagdev and Browne 1998, Thoben & Jagdev, 2001; Jagdev & Thoben, 2001).
Finally innovation processes in distributed setting were subject of many investigation such as
Chesborough (2003), Hippel 2005), Eschenbaecher et al, 2005).

These three developments have contributed to the extended product concept which has been
introduced in 2001 (Thoben et al, 2001). The extended product can be defined as follows:

An extended products itself describes the bundling of value added products and
services to a core product to fulfill customer needs over the whole product
lifecycle. As the term extended enterprise comprises more than just a single
enterprise, the term extended product should comprise more than just the core
or tangible product. Because of these characteristics, our view clearly focuses
on extending a formerly tangible product. For that reason, the intangible shells
and segments around the tangible product should be in the focus. Accordingly,
all services related to an extended product which are relevant for our
discussion do have a certain link to a tangible product.

The concept of extend products grounds on the shift of expectations from customers when
buying new products and services. Today, many customers are interested not only in products
but in a benefiting solution that often go beyond the mere physical core product. In this sense,
Extend Products aim at the provision of benefits and may intertwine many tangible and
intangible product compounds. As an example one could raise the issue of e-mobility: In the
context of e-mobility, the provision of "green mobility" as such would be the main benefit.
Customers do get the feeling to contribute to the environment preservation by reducing e.g. CO2
emissions. Figure 29 shows the development from products in a narrow sense, like physical
products and components systems, as the electric car itself (i.e. the Mitsubishi iMiev) towards
products with a broader perspective (e.g. car sharing service). One major shift is indicated by the
transfer from production of products and components such as cars for a sometimes known and
sometimes anonymous market towards mobility solutions.


41
Core Product Tangible Product Tangible and Intangible Product Assets
Shift of Business Focus
Provision of
Benefits
Manufacturing
of Parts
Offering of
Products /
Systems
Offering of
Solutions

Figure 29 - Moving to an Extended Product

2.3.3.2 Evolution towards distributed, collaborative innovation processes
The term collaborative innovation or distributed innovation (DIN) has been discussed intensively
over the last 10-15 years (OSullivan and Dooley, 2008 Kelly, 2006). Within the framework of
this concept, innovation is seen as a distributed process that involves the collective efforts and
the interaction of heterogeneous organizations. Each actor is specialized in specific activities,
technologies and knowledge and innovation is seen as the result of the combination and
integration of their competences. Coordination is therefore a key determinant for the viability of
distributed innovation stimulating complementary activities across otherwise dispersed
competences (Consoli et al., 2007). The following views on DINs illustrate a few varying
opinions:
Moller and Rajala (2007) define innovation networks as relatively loose science and
technology-based research networks involving universities, research institutions, and
research organizations of major corporations guided by the ethos of scientific discovery.
Nevertheless, innovation networks themselves are seen as relatively loosely tied
organizations (Freeman, 1991).
Rampersad and Quester (2009) point out that innovation networks are relatively loosely tied
groups of organizations that may comprise of members from government, university and
industry continuously collaborating to achieve common innovation goals.
OSullivan (2009) sees DINs as innovation processes that spread across an extended
organization. Distributed innovation is the successful implementation of creative ideas, tasks,
or procedures by employees in different geographic locations. The global availability of ICT-
systems, resources and competencies accelerates the increasing distribution of innovation
processes (Cummings, 2008).
There has been a long discussion about both representation and differentiation of innovation
processes. The following diagram (Eschenbcher, 2009) differentiates between internal
innovation management and in-between innovation management and therefore incorporates two
main concepts. These two general concepts can be divided into five general approaches on how
to deal with innovation processes. Basically, the model shows evolutionary steps towards greater
dynamics of innovation in value creating networks.
42

Figure 30 - Evolution towards distributed, collaborative innovation

The inventor: The very origin of innovation and the imagination is the inventor, who
represents the beautiful mind working in a cellar or garage on new inventions.
R&D department: The R&D (research & development) department is still a pre-dominating
imagination of intra-organisational innovation processes. Even today many companies run
R&D departments for the sake of innovating. Nevertheless the trend of open innovation leads
to a reduction of such traditional departments.
Cross-functional teams: Cross-functional teams are of major importance to successful, intra-
organisational innovation processes. In contrast to the traditional R&D department, here,
many different departments collaborate in a cross-functional manner to enable innovation.
This leads to both higher market orientation and increasing complexity of innovative
products and services.
Supply Chain innovation processes: The supply chain innovation processes deliver a good
example for inter-organisational and distributed innovation processes. The outside world is
integrated into the innovation processes, which leads to distributed innovation processes.
Nevertheless, the innovation process is coordinated from a supply chain hub which means
complete control by a large MNC (multi-national company).
Distributed innovation networks: Currently, only very few world class companies such as
Apple are really able to work in DINs. Here the main focus is the bundling of the best
resources available.

2.3.3.3 Extended products and collaborative distributed innovation in Virtual factories
After the introduction of extended products and collaborative distributed innovation it is
important to understand their role in virtual factories. We have in mind that any production
activity is caused by the needs of a potential customer. Precisely extended products can even
help to define or identify new customer needs. Servicing the customer means also to support the
customer in deriving new business ideas. The new business ideas can be considered as
distributed, collaborative innovation efforts of several companies as shown in Figure 31.
Consequently Virtual Factories of the Future have to extend their offerings in a dramatic way.
Customers may not be interested in buying products; they may very well be satisfied to obtain an
added value and for sure - an innovation. For this reason Virtual Factories of the Future have to


43
collaboratively offer total holistic solutions which might support the customer in achieving these
benefits.
Extension of products in terms of service-products will often constitute physical products as well
as the associated accessories or services. The combined package is supposed to make the
purchase of product attractive to the customer. Thus, depending on the type and core
competencies required to supply the associated services, there may be several business partners
collaborating very closely towards the common goal of making the sale of the package attractive.
This collaborative arrangement may very well operate in Virtual Factories Ecosystems.
We believe that it is necessary to create more than one representation of the service-products.
Here the Supplier bundles additional Accessories and Services around the core product to
develop an Service-Products to make the sale more attractive to the Customer, who is the end
user/consumer. If we take the picture with the shell we should ask who is providing the service-
products? It is not just the manufacturer or supplier of the core / tangible product. To provide
intangible assets of the product the concept of Virtual Factories Ecosystems comes in. These
Virtual Factories Ecosystems are replacing the former single enterprise and take over the lifetime
responsibilities for the product. The following shows a representation of this logic. Every
enterprise provides some part of the extended product.
Enterprise A
Enterprise C
Enterprise B
Enterprise D
Virtual factories to produce
Extended products:
-Preparation of extended products
-Integration of intra-organizational
processes to an inter-organizational
process chain
- Dynamic collaboration (reconfigurable
within one order)
- Duration: max. 1 order
- Allocation of Power: Hub-and-Spoke
(strong centralization of power)
- Web-based ICT-support
- Externally conceived as one enterprise

Figure 31 - Extended products and collaborative distributed innovation in Virtual factories

2.3.4 Conclusion and Future Work
The work reported in this paper has been carried out in the framework of the COIN project by
the implementation of the COIN Collaboration Platform and its usage by the COIN end-users.
The BPM facility has been deeply adopted by COIN partners allowing them to build up this
cross-organisational business processes leveraging on the availability of COIN services put at
their disposal. This process allowed the end users to actually measure the business enhancement
to their business processes. The work carried out, especially in respect with the so-called step2
and step 3 doesnt end in the scope of the project but it is just a starting point to be generalised
and possibly applied to other domains and circumstances. The COIN view of EC services as
utilities could therefore on the one side stimulate the concept of a common Core Platform in the
Future Internet embedding collaboration fundamental services, on the other side it could be the
basis for a new Enterprise Information System supporting open innovation in collaborative
enterprises and SMEs networks.
44

References
[1] COIN D3.5.1a COIN 1st Integrated Service Platform (CP)
[2] D3.5.2a COIN 1st Integrated System (CP2)
[3] D3.5.2b COIN Final Integrated System (CP3)
[4] D3.5.2b COIN Final Integrated System Annex IX (STEP2)
[5] D3.5.2b COIN Final Integrated System Annex X (STEP3EI)
[6] D3.5.2b COIN Final Integrated System Annex XI (STEP3EC)


45
3 COIN Enterprise Collaboration (EC) and Interoperability (EI) Services
The second main objective of COIN was to consolidate and stabilize the ICT results of both EC
and EI FP6 research into some Baseline Services (free or charged; open-source or proprietary)
which constitute the service foundations for COIN. It was not an easy task to put together in a
harmonized and coherent way, so diverse and heterogeneous results, but COIN main partners
have been the most active actors in their respective FP6 projects and could therefore be the boost
for that. So, COIN effectively built and implemented since the beginning of the project a solid
service-oriented Technology Platform for Enterprise (SMEs) Interoperability and Collaboration,
by putting together FP6 research results (chapter 3.1 and 3.2).
Those results have been then enriched by new innovative services developed in COIN (see
chapter 3.3 and 3.4) and in order to improve its usability and accessibility (mostly by SMEs) in
different business and knowledge contexts. The Innovative Services in the EC and EI fields, took
into account the most recent and promising technology challenges (in the field of Web 2.0,
semantic web, space computing) and put them at service of EC and EI purposes. In the field of
EC, we deem essential for SMEs some more configurable and flexible (not sector-specific)
services for collaborative product development, distributed and participative production
planning, co-opetitive multi-project management and finally some standardized services for user
interaction and co-operation. In the field of EI, we basically approached most of the Grand
Challenges identified in the EI Roadmap and we developed services for semantic, web-enabled
business documents interoperability; for Knowledge interoperability and for Business models
and policies harmonization and combination.

46
3.1 COIN research results for enterprise innovation - Enterprise Collaboration Baseline
Services
Patrick Sitek
1
, Michele Sesana
2
, Hong-Linh Truong
3

1 Bremer Institut fr Produktion und Logistik GmbH, Hochschulring 20, 28359 Bremen (Germany)
(sit@biba.uni-bremen.de)
2 TXT e-Solutions S.p.A, Via Frigia, 27, 20126 Milano (Italy)
(michele.sesana@txt.it)
3

Distributed Systems Group, Vienna University of Technology, Argentinierstrasse 8/184-1, 1040 Wien (Austria)
(truong@infosys.tuwien.ac.at)
Abstract
Enterprise Collaboration (EC) is a broad subject. Thus, a variety of different opinions can be formed mainly based on
the scientific discipline behind it. In the context of COIN IP project, Enterprise Collaborations are based on inter-
organisational relationships between network members, making the analysis and support of those relationships one of
our main objectives. To this end, in the first year of the project, we consolidated and harmonised results from
previous RTD projects concerned with Enterprise Collaborations to provide the Baseline Enterprise Collaboration
(EC) Services for the COIN project. In this chapter, we present our consolidating results in which EC Baselines
Services are introduced to support most dynamic enterprise collaborations, like Business Ecosystems, by
harmonising individuals and organisations profiles under the same model.

Keywords: Baseline Services, Enterprise Collaboration, COIN IP
3.1.1 Introduction
Inter-organisational relations are gaining unprecedented momentum for enterprises [9] and are a
widely discussed subject. Many researchers reviewed the topic of such enterprise collaborations
(EC). In collaboration, parties are more closely aligned in the sense of working together to
reach the desired outcome, rather than that outcome being achieved through individualistic
participation constrained by contextual factors such as those imposed by client-supplier
relationships and pre-defined roles, like in supply chains. An EC is an alliance constituted by a
variety of entities (e.g. organisations and people) that are largely autonomous, geographically
distributed, and heterogeneous in terms of their operating environment, culture, social capital and
goals, but that collaborate to better achieve common or compatible goals, and whose interactions
are supported by computer networks [2]. In todays society, enterprise collaborations manifest in
a large variety of forms, including virtual organisations, virtual enterprises, professional
associations, industry clusters, professional virtual communities, collaborative virtual
laboratories, etc.
EC has been a major catalyst in the 6th Framework Program of the European Commission. It led
to several projects aiming at finding new paradigms for enterprises aggregation, synchronisation
and cooperation in response to the more and more demanding and complex business
opportunities coming from customers. The research done so far focuses on three different
collaborative network contexts, from the most static to the most dynamic one:
o Supply Chains, where long term relations and stable organisational and
economic structures among enterprises allow the adoption of the most optimised
and important IT solutions;
o Collaborative Networks, where the SMEs long term aggregations (i.e. clusters,
districts and breeding environments of ECOLEAD IP) are finalised to get the
members prepared to create and sustain more short term and dynamic alliances
based on specific business opportunities (i.e. virtual enterprises, virtual teams);


47
o Business Ecosystems, where SMEs are left free to evolve as they like, just
following the market evolutionary law that it is the fittest species which survive
(i.e. open networks, de-focused networks) and the ecosystem just supports and
encourages this emergent and evolutionary approach by providing SMEs with
several services (e.g. legal, organisational, ICT).

Significant results in the field of IT infrastructure and IT support to EC management have been
achieved so far. But evidently they could not address properly the problem of EAI (Enterprise
Applications Integration) and operational support to collaborative processes in the different
industries and application domains.
3.1.2 Related Work
Recently, many projects have developed various collaborative systems which could be classified
into systems for virtual teams, such as the inContext system (http://www.in-context.eu) or for
virtual enterprises, such as ECOLEAD (http://www.ecolead.vtt.fi) or E4 (http://e4.cognovis.de/).
The first type of systems is generic enough to be used in team collaboration of cross-enterprises
but they are not integrated into real business context of enterprises in collaborative networks. The
latter typically includes separate tools for different purposes in different life-cycle-phases of
virtual enterprises (following [8], [1], [3], [6]):

1. EC Preparation (Sourcing of partners)
2. EC Formation and Setting up (Legal issues, contracts)
3. EC Operation (Day-to-day management)
4. EC Dissolution and Decomposition

While collaborative services are increasingly used for EC, a platform including well-integrated
collaborative services which cover different aspects is missing, forcing the user to utilize
different tools in separate ways. A detailed analysis of existing EC tools, in particular from the
EU IST 6th Framework Program, has been performed. Table 1 summarises some major tools (a
detailed survey can be found in [7]).

Table 1 - Existing EC tools and systems
Category Software Number
of Tools
Tool Name
Web
application
Tomcat 10 Virtual Breeding Environment Management
(VMBS), Professional Virtual Community (PVC)
Management and Governance, PVC Rewarding
Tool, Requirement Identification Service
(refQuest), E4 (Extended Enterprise Management
in Enlarged Europe) Platform, Supported
Indicator Definition (SID), Collaboration
Opportunity Characterization (COC) Plan,
Virtual Organization (VO) Model Repository,
Partner Selection (PS), VO Formation
Apache
Web server
2 Collaboration Opportunity (CO) Finder,
Customer Support Service (DISCO)
Microsoft
IIS
4 PVC Management and Governance, Planned,
Mediated, and Ad-hoc Collaborations
48
Web service Axis 2 Communication Service Set, Activity
Management
Database MySQL 9 PVC Management and Governance, PVC
Rewarding Tool, Planned, Mediated, and Ad-hoc
Collaborations, Communication Service Set,
Activity Management, refQuest, DISCO
PostgreSQL 5 VBMS, E4 Platform, CO Finder, COC-Plan, VO
Formation
Programming
Language
Java 10 VBMS, PVC Rewarding Tool, Communication
Service Set, Activity Management, refQuest,
SID, COC-Plan, VO Model Repository, PS, VO
Formation
C# 5 PVC Management and Governance, Planned,
Mediated, and Ad-hoc Collaborations, E4
Platform
PHP 2 CO Finder, DISCO

Most of the tools are specific for EC but some are generic, such as the Communication service
set and the Activity Management service. Most of the shown tools did not follow the SOA
paradigm but Web application, and they are designed to work in an isolated manner with a focus
on the end user, not the service integrator. Thus, while useful for Enterprise Collaboration, most
of the tools are designed for isolated use, diverse types of data are not integrated and it is difficult
to compose different tools and services for newly-emerging collaboration needs. Moreover, the
tools focus separately on Virtual Organisations and Professional Virtual Communities, while the
business concept presented in this paper concentrates on dynamic enterprise collaborations
between organisations and individuals in business ecosystems.
3.1.3 EC Baseline Reference Model
The formal duration of EC describes the contractually fixed duration of that collaboration. It can
be classified as unique if the intention is to realize just one product/offering based on a specific
customer request. The collaboration can be classified as limited if the intention is to realize a
fixed series of complex products. To support ability of collaboration and rapid formation of
collaborative networks, the researchers came to the conclusion that it is necessary to have
potential partners ready and prepared to participate in such collaboration [5]. Therefore
enterprise collaborations can be differentiated in different life-cycle phases. This preliminary
study on life-cycle phases and on existing EC tools and systems led to the identification of the
EC Baseline Reference Model. The different phase of the life-cycle does require various baseline
services. Therefore they were the best candidates to be part of the EC Baseline Reference Model.
The following picture shows the EC Baseline Reference Model along the EC life-cycle. A set of
EC Services has been designed as an IT solution and implemented according to the EC Baseline
Reference Model.


49

Figure 32 - EC Baseline Reference Model

During the Preparation Phase of EC interested parties register and are able to define their
profiles, e.g. editing administrative, contribution (product/ service), processes and performance
data. The innovation lies in the combination in the management of originations and also
individual profiles. This combination supports the management of highly dynamic collaborative
networks like Business Ecosystems. Life-cycle independent communication web services are
implemented to be used to announce news (like new members) and support communication
between network members. The further innovative EC Baseline Service provides the possibility
to either create a Business Opportunity (product/ service) from inside (based on the network
competencies) or optional discovering Business Opportunity by market research. For the creation
option a new serious game has been implemented that supports the creative ideation process
between networks members. One member opens a creative session to seek for Business
Opportunities and is able to sent invitation to other members by the Communication Service.

Once the Business Opportunity has been identified the Formation Phase starts and with the
Business Opportunity Characterisation Service it is possible to define the Work-Break-Down-
Structure (WBS), the tasks to be performed and the special competencies needed. Active
members can be rewarded for their activities in seeking for Business Opportunities. Right
partners for the characterised Business Opportunity are to find with the EC Partner Search
Service following chosen search criteria. While finding the right partners the support of
communication, discussion and agreements between members is also provided by the
communication service. The selected partners for the specific Business Opportunities are to
register and collaboration performance indicators are to be set for the Operational Phase.

Enterprise Collaboration Service and Product Management Services (PSM) support the
Operational Phase of the collaborative network where the added value for the customer is to be
realised. The PSM Service provides a structured storage in catalogues of all relevant product
information and documentation to be realised. Complex products can be stored in different
configurations. Following the (WBS), planned and mediated tasks can be defined for each
50
network partner. Ad-hoc task force teams can be set up in critical collaboration situations. The
execution of the defined tasks is supported by an activity service, which links acting people with
used resources, and tracks the state of each task. Exchange of product data and progress
information related to the tasks are supported by the communication service again. Good
collaboration performance can be rewarded and has a positive impact on the members profile.

Finally during the Dissolution Phase it is possible to gather feedback from all active partners and
the end customer and store the collaboration experience gained for a reuse in future Business
Opportunities. Finally the end customer receives access to the product catalogue and product
information.

3.1.4 Conceptual architecture
Based on the analysis of existing tools in the field of Enterprise Collaboration, a conceptual
architecture for a Baseline IT-Platform has been designed that follows the SOA model. The
following picture shows the architecture that includes data, service and tool layers which aims at
integrating and harmonising existing EC tools and services.

Figure 33 - Conceptual architecture of the COIN Baseline EC software services and tools

Data, services, and tools for EC that was previously created in an integrated way including strong
relationship between presentation, business logic and data access layers are decoupled in these


51
three layers and integrated through SOA principles and technologies. Through the integration, a
core set of services and tools has been realized available for use; services previously integrated
and used by one tool now can be reused by other services or composed to support more complex
scenarios. The central point of the EC Baseline IT services is the centralized model implemented
as a database; data layer provides necessary data for any activities performed in the four phases
of the EC lifecycle and the Business Opportunity to be achieved.

In the next picture the process of decoupling is shown from a software built to be used alone (on
the left) where the three levels are integrated in the same environment to a software where layers
are completely separated; the business logic is provided as web service and data is gathered by
usage of a centralized model.

Figure 34 - Example of decoupling of an existing software

During the decoupling the attention focused on the harmonisation of concept that previously
have been taken completely separated: the organisation world (organisation, Virtual
Organisation, cluster, etc) and the individual world (individual and virtual teams). The result is a
model more than 60 entities implemented in 80 database tables allowing tools to share data in an
easy way. In order to allow user to experience the whole EC Baseline services and tools has been
provided a single point of access to the entire system: user should access to a portal based on
Liferay by a single sign on mechanism based on Central Autenthication Service (CAS). On the
website are displayed circles representing baseline services available for the user role; by
clicking on that the user can access to the desired tool.
52

Figure 35 - Baseline IT Services Portal

The extension of the baseline IT service by inclusion of other services is easy because on the
access of the common model allows new services to interact with data provided by existing
services without knowledge about their internal processes.

3.1.5 Conclusion and key benefits
Organisations need IT solutions that are able to support dynamic enterprise collaboration
involving many organisations, individuals, resources and software services. First, due to the
dynamics of collaboration and rapid formation of collaborative networks, these networks require
different services for different collaboration phases [2]. By combining the management of
organisations and individuals and their virtual forms, this approach supports the formation of
highly dynamic collaborations including business ecosystems because rich sources of common
data, such as profiles, product/service, processes and performance data, is linked and available in
a common data-as-a-service. Converged collaboration services are provided by composing
different services, i.e., communication services with other services to support realtime
information dissemination among collaborators. Furthermore, a business opportunity
(product/service) can be created from inside (based on the network competencies) or discovered
through third party services. Third, business opportunities and collaborations are manageable
through activities associated with individuals, teams, and their competencies and processes, and
relevant product information and documents. Finally, through the portal, feedback can be
collected and evaluated in a coherent way from individuals, organizations, customers and also
from many software services to evaluate the success of collaborations. Such evaluations are
valuable for determining trust and plans in future business opportunities.

The portal enables the composition of commodity EC services: many existing EC services are
common because we can use them for different purposes. With such a portal, new EC services
can be created through the composition of common EC services. The portal enables the
acquisition of rich data sources for understanding collaboration interactions and performance
evaluation. Without such a portal, it is very difficult, to obtain different kinds of data
characterising interactions for analysis. With the portal, profiles, activities, operations, contexts,


53
etc., can be logged and retrieved through a Web services-based platform, supporting many
research activities, such as trust analysis and collaboration adaptation, which rely on realistic data
for experiments.

Acknowledgment
This work has been partly funded by the European Commission through ICT Project COIN:
Collaboration and Interoperability for networked enterprises (No. ICT-2008-216256). The
authors wish to acknowledge the Commission for their support. We also wish to acknowledge
our gratitude and appreciation to all the COIN project partners for their contribution during the
development of various ideas and concepts presented in this paper. An early version of this paper
appeared in the International Conference on Concurrent Engineering - ICE 2009 conference.

References
[1] Camarinha-Matos, L.M. and Afsamarnesh, H. (2005) Collaborative networks: A new scientific discipline,
in Journal of Intelligent Manufacturing, Vol.16, No.4-5, pp.439-452
[2] Camarinha-Matos, L.M. and Afsamarnesh, H. (2006) Collaborative networks Value Creation in a
knowledge Society, in Proceedings of Prolamat 2006, Shanghai, China
[3] Eschenbcher, J., Graser, F. and Hahn, A. (2005) Governing Smart Business Networks by Means of
Distributed Innovation Management, in: Smart Business Networks, Springer Verlag, Berlin Heidelberg
New York, S. 307-323
[4] Eschenbaecher, J. (2008) Gestaltung von Innovationsprozessen in Virtuellen Organisation durch
Kooperationsbasierte Netzwerkanalyse Dissertation an der Universitt Bremen (to be published)
[5] Romero, D. and Molina, A. (2010) Virtual organisation breeding environments toolkit: Reference model,
management framework and instantiation methodology, in Production Planning & Control, 21: 2, pp. 181-
217
[6] Seifert, M. (2007) Untersttzung der Konsortialbildung in Virtuellen Organisationen durch perspektives
Performance Measurement, Dissertation an der Universitt Bremen
[7] Sitek, P., Eschenbaecher, J., Sesana M., Truong, H.L., Aguilera, C. (2008) D4.1.1 State of the art and
baseline EC services specification. COIN Consortium
[8] Thoben, K.-D. and Jagdev, H. S. (2001) Typological Issues in Enterprise Net-works, in Journal of
Production Planning and Control, Vol.12, No.5, pp.421-436
[9] Zhao, F. (2000) Quality and Collaborative Quality Management in Cooperative Research Centres, in
Conference Proceedings of 4th International & 7th National Research Conference, Sydney
54
3.2 COIN Innovative Enterprise Collaboration Services
Kim Jansson
1
, Michele Sesana
2
, Florian Skopik
3
, Alberto Olmo
4

1 VTT, Technical Research Centre of Finland, kim.jansson@vtt.fi
2 TXTe-solutions S.p.A., Italy, michele.sesana@txtgroup.com
3

Distributed Systems Group, Vienna University of Technology, Austria, skopik@infosys.tuwien.ac.at
4 ISOIN, Ingenieria y Soluciones Informaticas, Spain, aolmo@isoin.es
Abstract
The COIN project has developed services for Enterprise Collaboration. Based on the analysis of industrial needs and
market available enterprise collaboration tools COIN has identified missing services on the market. A special focus
has been put on identifying the needs of SME networks. COIN has specified, developed and delivered services in the
following domains: Collaborative Product Development, Collaborative Production Planning, Collaborative Project
Management and Collaborative Human Interaction. This chapter provides an overview of the methodology and
workplan used together with an overview of the developed services. For each individual service the main innovations
and progress beyond state-of-the-art are presented.

Keywords: Enterprise Collaboration, Enterprise Interoperability, Innovative Services, Product Development, Project
Management, Production Planning, Human interaction
3.2.1 Introduction
Today Internet technology has made it possible to establish different types of Collaborative
Networked Organisations (CNO). The costs of using modern Internet technology is no longer an
obstacle for a large scale take up of collaboration services. The COIN Project develops services
for European SMEs enterprise aggregation, synchronization and co-operation in response to the
demanding and complex business opportunities coming from the global market [COIN]. In
particular the COIN project develops services for Enterprise Collaboration (EC) and Enterprise
Interoperability (EI).
Based on analysis of industrial needs and identification of missing services on the market, COIN
has further specified, developed and delivered services in the following domains.
Collaborative Product Development (c-PD)
Collaborative Production Planning (c-PP)
Collaborative Project Management (c-PM)
Collaborative Human Interaction (c-HI)

In the COIN context the developed services to support the above mentioned domains are called
Innovative Enterprise Collaboration Services.
This article first describe, in section 2, the methodology and workplan used in COIN to identify
needed services. Section 3 will briefly go into the background and previous research on the EC
topic. Section 4 gives an overview of the functionality in the COIN innovative EC services.
More detail can be found in the corresponding COIN Deliverables listed in the References
section. The most important part of this article is the section 5, which presents the main
innovations in the services and the innovative ways of using the services.
3.2.2 Methodology and Workplan
The COIN project has used a research approach that relies on previous research projects and
market available solutions. The development of COIN EC services has been guided by the
following principles:
Build on state-of-the-art knowledge and previous results from research and development.


55
Be continuously open for adopting new emerging and breakthrough technologies and de-
facto standards.
Take advantage of existing work and avoid inventing the wheel again.
Favour open source and free of charge solutions.

COIN has used a user-centric (and SME-oriented) approach in the development work. The
industrial partners networks have a crucial role in ongoing interaction with the research and
development parties.
A two-cycle spiral approach has been followed. Each of the two cycles has delivered
independent prototypes for EC services followed by integrated versions. The main industrial
evaluation and feedback was scheduled between the iteration cycles. However the on-going
interaction, between developers and the industrial partners, throughout the project has
encouraged the development of innovative service features also within the iteration cycles.
The following Figure 36 illustrates the overall development strategy, where the second
development cycle in the approach is followed by an industrial take-up and demonstration phase.


Figure 36 - COIN overall development strategy

3.2.3 Background and Previous Research
In the European CNO research cluster VOSTER, two main concepts for inter-enterprise
collaboration were identified according to the objective and duration of the collaboration [12]:
Network / breeding environment which is a more stable, though not static, group of
organisations which have developed a preparedness to co-operate.
Virtual organisation (VO) / virtual enterprise which is a temporary consortium of partners
from different organisations established to fulfil a value-adding task, for example a product
or service to a customer.
The ECOLEAD-project has enhanced previous frameworks for understanding the relationships
between entities in a CNO [12]. Software tools developed in e.g. the ECOLEAD as well as other
projects have been aggregated into COIN forming the Enterprise Collaboration Baseline
Services, explained in the previous article of this book. They support the collaboration life cycle
for both long-term, mission-driven and short-term, opportunity-driven collaboration [3].
56
3.2.4 Results - Overview of Developed Services
As stated in the introduction section COIN has developed innovative services for c-PD, c-PP, c-
PM and c-HI Services. The first three groups of services directly support the corresponding
operational functions; product development, production planning and project management, in a
CNO, while the fourth group of services are more general and not specifically dedicated to a
function in the CNO. The c-HI services encompass services for human collaboration and data
sharing and can be utilized as supporting services, for example in the c-PD, c-PP and c-PM.
Figure 37 gives an overview of the functionality in the COIN innovative EC services. The
individual services are explained in some more detail in the following section.
Production Planning
Production Planning Portal & Service
Quality Management
Supply Chain Information& Text enrichment
Project Management
Project Alignment
Social Gantt building
Project Meeting Process Management
Human Interaction Support
Collaboration Visualization
Trusted Information Sharing
Trusted Online Help & Support
Product Development
Semantic Cluster Management
Automatic Ontology Building
3D Viewing & Annotation

Figure 37 - Overview of developed services

3.2.4.1 Services for Product Development (c-PD)
Product development is a very wide process, covering different activities from the original ideas
and requirements collection to partner search for production, first prototype building, architecture
and design, product manufacturing, testing, deployment and maintenance. Collaborative Product
Development is the application of team-collaboration practices to an organizations total product
development efforts. It is concerned with creating the necessary environments for effective, free
flowing information and ad-hoc collaboration among peers involved in these mostly external
knowledge worker partnerships [13]. Often used tools include computer-aided design (CAD),
computer-aided engineering (CAE), computer-aided manufacturing (CAM), enterprise resource
planning (ERP) and product data management (PDM) systems, that can be integrated to support
intra- and inter-enterprise collaboration. The following innovative services have been developed:
Semantic Cluster Management Services (SCMS).
Automatic and Intelligent Construction and Instantiation services (AICIS).
Collaborative 3D Designer Service (C3DDS).
3.2.4.2 Services for Planning Support (c-PP)
Production Planning is a large concept and could be defined as the function for the efficient
planning, scheduling, and coordination of all production activities. In this function a huge
number of variables are involved: resources, planning horizon, costs, capacity constraints, bill of
materials, warehouse availability, quantity, delivery dates, etc. The configuration of production
planning system requires the set-up of a large set of parameters comprising the input data related
to the company structure, the environment on which production takes place, and the


57
configuration algorithms for the master production scheduling creation. For those reasons, these
services have been created in complex professional systems for enterprises. The information
flow and the collaboration among actors of the value chain to coordinate their work are also
included in the definition of production planning. The following innovative services have been
developed:
PnP Collaborative Production Planning Portal (C3P).
SaaS Production Planning Service (PPS).
Collaborative Quality Management Service (cQMS).
Supply Chain Intelligence Service (SCIS).
Service-oriented Text Enrichment Services (SOTES).
3.2.4.3 Services for Project Management (c-PM)
Project Management (PM) is the discipline of planning, organizing, and managing resources to
obtain the successful completion of specific project goals and objectives, while adhering to
classic project constraints; scope, quality, time and budget. Collaborative Management of
projects involves, shared and delegated project management responsibility, often self-organized
and trusted approaches, non-hierarchical and participative management organization.
The discipline of project management is well established and an application area well supported
by software solutions. However development within Internet technology, social media,
participative co-creation, and Web 2.0 applications also enables new working methods on the
PM area. Based on industrial requirements and from analysing the current state of the art and
research progress in the area of CNO, PM and Web2.0, COIN has recognized a real need for
development in the area of Collaborative Project Management (c-PM).
The developed c-PM innovative services are grouped into the following three tools with the
objective to support social and collaborative internet based project management
1. Project Alignment Booster (PAB).
2. Collaborative Project Meeting Process Management (PMPM).
3. Collaboration for Project Management (Coll4PM).
3.2.4.4 Services for Human Interaction Support (c-HI)
Web-based collaborations and cross-organizational processes typically require dynamic and
context-based interactions between people and services. Product development, production
planning and project management are supported by services and tools developed by partners as
well as market available complex professional system. However, there is currently only little
support and a lack of solutions to tackle problems arising from dynamic aspects of execution,
e.g. how to handle exceptions and deviations from the planned progress. These situations often
require a human intervention. Thus, there is a need to monitor on-going collaborations,
characterized by human interactions in the operational phase of a virtual organization to retrieve
a holistic view about the performance of a collaboration scenario.
The developed c-Hi concepts and tools support dynamic human interactions in cross-
organizational environments. People use these services to interact in a context-aware manner.
Interactions are monitored by using logging services. On top of logged interactions, trust
relations can automatically be inferred using a rule-based interpretation of interaction metrics.
Using these concepts the following c-Hi services are provided:
1. Collaboration Visualization Tool (CVT).
2. Trusted Information Sharing Service (TIS).
58
3. Trusted Online Help and Support (TOHS).
3.2.5 Innovations
The previous chapter contained on overview of the developed EC services. This chapter will
present the main innovations in the services and the innovative ways of using the services.
3.2.5.1 Progress beyond State-of-the-Art in Semantic Cluster Management Services (SCMS)
Heterogeneous tools and multiple designers are frequently involved in collaborative product
development, and designers often use their own terms and definitions to represent a product
design. Thus, to efficiently share product information, a designers intentions should be
persistently captured and the semantics of the designers terms and intents should be interpreted
in a consistent manner. For this purpose, a standardized data format is a prerequisite.
The objectives of the Semantic Cluster Management are to support engineering knowledge
management to enable the search of right partners for product development, with the needed sub-
products or services, and with the needed competences. The Semantic Web supports integrated
and uniform access to information sources and services as well as to intelligent applications by
the explicit representation of the semantics buried in an ontology. The SCMS extends the
collaborative product development ontologies to the companies that form a CNO (be it supply
chains, collaborative network or business ecosystems), to improve collaborative product
development through a formalised description of companies, competences, services, products
and documentation. The main innovation of this ontology is its interest for diverse end users that
can model their knowledge domain with a more generic tool than those currently available.
Figure 38 shows an example.

Figure 38 - Healthcare sector ontology draft

This service is complemented with Automatic and Intelligent Construction and Instantiation
Services (AICIS), which is explained in the next section.
3.2.5.2 Progress beyond State-of-the-Art in Automatic and Intelligent Construction and
Instantiation Services (AICIS)
The SCMS has been complemented with automatic and intelligent semantic web services that
deals with 1) automatic building of the ontology, based on relational databases used in the cluster


59
or on unstructured data and 2) automatic instantiation of the ontology, based on cluster
documents. The service aims at providing intelligent searching and browsing through crawled
data about cluster companies. The main part of developed services has been integrated in the free
accessible ontology management environment OntoGen [2].
The innovation in COIN is to implement OntoGen services to function automatically i.e., to
build up ontologies automatically from a given set of documents. A part of the ontogeny services
has been redeveloped to offer the option of unsupervised ontology learning. Unsupervised
learning is based on clustering methods from text-mining where the clusters of instances from
selected concept are treated as sub-concept suggestions.
3.2.5.3 Progress beyond State-of-the-Art in Collaborative 3D Designer Service (C3DDS)
3D collaborative product development is essential in current industrial processes. Proprietary file
formats have traditionally locked 3D CAD users into one vendor. The technology of Web
services opens new opportunities for CAD applications, enabling viewing and sharing 2D and
3D designs, without the need to download or install any software, allowing the collaboration of
any user with the only requisite of accessing the Web. With the C3DDS prototype, the following
objectives have been addressed:
Online viewing of 3D files, including a wide variety of formats and de-facto standards.
Web service architecture, avoiding the need to install software.
Online annotations, to enable virtual meetings to comment 3D designs.
History of annotations and authoring of annotations.
Adaptation of C3DDS to different types of CNOs (collaborative networks, supply chains,
business ecosystems) has been the object of development.
3.2.5.4 Progress beyond State-of-the-Art in Collaborative Production Planning Portal (C3P)
Production Planning systems give to the user a great amount of functionalities concerning
product managements, company resources management, scheduling algorithms, warnings and
errors can be defined and evaluated through a graphical user interface (GUI) , and so on, as
shown in figure 39. Employees of the same company can easily work together on company data
and solve internal problems. What is missing in these systems is the collaboration among
different organizations of the supply-chain; this is due to several factors:
Different production planning systems do not give mutual access to company data.
Production agreements between partners (orders) are exchanged in different structures and
usually exchanged by archaic methods (FTP, email).
Collaboration on data is performed only through old communication channels (telephone,
emails, face-to-face meetings, etc.).
There are few data available to actors to solve exceptions and warnings and partners do not
have information about other partners internal processes.
Unavailability of production planning systems for some partners (mainly SMEs).

60

Figure 39 - Collaborative Production Planning

These factors cause an enormous loss of time, that means money, in order to make systems
connected (data exchange, format harmonization, manual data insertion from one system to
another), to solve misunderstandings, exceptions and warnings. SMEs without an interconnected
IT infrastructure (or without any production planning) experience these problems more than big
industries, and their risk is to stay outside the market.
The innovations in C3P include:
The implementation of a Collaborative Production Process composed by internal actors
processes by which different companies can share their production planning to collaborate
with other parties of the chain: collaboration is put on top of arrows connecting different
private blocks of different companies and managed by virtual rooms.
Possibility to have shared changes at public (inter-organisations) or private level (intra-
organisation).
Implementation of a collaborative bill of material.
Agent negotiation implemented through the adoption of the COIN agent negotiation services
generated at the end the agreed order in the UBL standard format.
Possibility, through the collaborative production planning process to start different
negotiations at the same time with different competitors and select the best one.
Native support for the communication among individuals through the inclusion of the virtual
team concept on top of virtual rooms and the integration of human communication services.
3.2.5.5 Progress beyond State-of-the-Art in Production Planning Service (PPS)
Production planning is usually a module of Enterprise Resource Planning (ERP) solution, both
open source and commercial, that are widely adopted and used since decades by enterprises.
ERP systems are widely adopted by medium/big enterprises but not by SMEs that cannot afford
the costs and the complexity of the software. The innovation of PPS is to provide a simple
Production Planning system as a Software as a Service (SaaS) service able to provide common
functionalities such:
Data Import service.
Execution of algorithms to calculate the feasibility of the production and needed time/price.
Data output service.
Warning and Exception service.


61
The availability of this service by web interfaces leverages SMEs from any cost related to the
required technical infrastructure and can be easily adopted by them. The service is natively
integrated in C3P.
3.2.5.6 Progress beyond State-of-the-Art in Collaborative Quality Management Service
(cQMS)
Inter-organisational relations result in inter-organisational interdependencies which make new
demands on managing quality in enterprise networks. Managing interdependencies in enterprise
networks, means to understand that the work, changes in processes and output of any single
network member might have consequences for the work, processes and outputs of other
members in the network. These consequences, if not identified in sufficient time, might result in
not reaching the initial customer requirements and failing in quality of the network product.
cQMS suggest an innovative approach to analyse interdependencies between enterprise network
members by analysing their competence profiles [4]. By combining the information entities
product/service, business processes and technologies a representation of the competence as
definition is given. Each actors unique combination of products, resources and activities
constitutes its identity as competence. The competence defines the actors specific need for
information to be exchanged.
In cQMS a similarity algorithm approach is used to compare the partners competence
descriptions. Through cQMS network members make use of a word comparison algorithm,
which determines the similarity of two word sequences using the dice coefficient and reveals, in
this way, potential interdependencies. With the introduced cQMS members of CNO receive a
comprehensive approach that enables them to investigate inter-organisational interdependencies
based on their competence profile descriptions stored in the C3P [5].
3.2.5.7 Progress beyond State-of-the-Art in Service Oriented Text Enrichment Services
(SOTES)
Service oriented Text Enrichment Services (SOTES) have been developed because they present
the basic infrastructure for many planned and future semantically enriched services. With
SOTES the content is being enriched with the large contextual information that then provides far
better results in semantic services ranging from machine learning algorithms, data, text and Web
mining, social software, network modelling tools to semantics and reasoning. Content is being
enriched through many different types of information ranging from domain specific, common
sense knowledge, technical, multilingual, etc. SOTES presents a unique approach that gathers
together many technology innovations in a software stack for automatic content enrichment.
3.2.5.8 Progress beyond State-of-the-Art in Supply Chain Intelligence Services (SCIS)
Traditional logistics and corresponding Supply Chain Management (SCM) systems rarely use
algorithms from the area of artificial intelligence (AI). This is why they are using very
deterministic approaches that can just partly take into consideration the complexity of a logistic
system. The functionalities that are usually covered are; planning, monitoring and offline re-
planning in the case of problems.
There are two main innovative features in SCIS:
Implementation of new features for prediction, trend detection and anomaly detection.
Services are based on various methods that have been developed to handle vast amounts of
data in real-time.
Integration of top-down (knowledge driven) methods and bottom-up (data driven methods)
for the SCIS. Here the main innovative features comprise among others knowledge
formalization of SCIS domain, justifying methods with reverse reasoning, and integration
62
with a knowledge base and formalized representation of a vast quantity of fundamental
human knowledge: [14].
3.2.5.9 Progress beyond State-of-the-Art in Project Alignment
Collaborative project management requires that the participating organizations and people share
a common commitment and understanding of project objectives, requirements and practices, and
that the partners have sufficient competencies and skills for the project tasks.
PM software is a term commonly used to cover software targeted to aid the project managers in
managing their projects. This type of software usually cover functions for scheduling, budgeting,
forecasting, resource allocation, progress monitoring, quality management, communication and
documentation.
The developed methodology and the Project Alignment Booster services include the following
innovations and new development:
The project alignment process.
Collaborative and participative definition of unified and shared project work processes.
A self-evaluation methodology to announce partners capability and engineering
competence.
Possibility to analyse gaps between project demanded skills and capabilities offered by the
project partners. Based on the analysis, the collaborative project management can identify the
need for additional capabilities and competencies. The monitoring of deviations assists in
detecting project risks and possible timing problems.
The Project Alignment Model (PAM) is a configurable framework that describes for
alignment tasks and elements different levels how they can be carried out. The PAM is
configurable and more flexible than existing Maturity Models as CMMI.
Inclusion of organisational culture elements into the PAM.
3.2.5.10 Progress beyond State-of-the-Art in Collaborative Projects Meeting Process
Management (PMPM)
The development of the PMPM is based on the vision that global collaboration project
organizations need distributed meetings. Distribute meeting should be conducted more
efficiently than a traditional local meeting, through new processes and IT tools. The main
concept of the developed services is to support the management of the whole long meeting
processes. The process extends from the planning of the meeting all the way to finalization of the
meeting, e.g., from agenda planning to distribution of meeting minutes. The individual steps in
the meeting process will invoke existing tools and services, preferably opens source based
services. An example is illustrated in Figure 40.

Figure 40 - Example of meeting process and steps

The development contains the following innovations:
Support of the management of asynchronous and long meeting process involving steps e.g.
participative definition of agenda, call for participation, scheduling, standard agenda,


63
contribution asynchronously in advance, reminding of meeting, online meeting, follow up.
The innovation is in the management of the whole meeting process.
Establishment of application domain specific process libraries for typical project meetings,
for example complex engineering projects.
Integration with the COIN GSP to find most suitable meetings services. The best suited tool
to be used in each step is based on the partners on-line status, role in project, importance
etc. The tools used in the various steps can be defined on forehand or dynamically selected
during the process execution.
3.2.5.11 Progress beyond State-of-the-Art in Collaboration for Project Management
(Coll4Pm)
The Collaboration for Project Management Service (Coll4Pm) focuses on the collaborative
management of a collaborative project, taking as a central point of the application the Gantt chart
on which users coming from different environments and backgrounds can socially collaborate.
There is a wide availability of tools (both open source and commercial) on the market giving the
possibility to work on Gantt charts. Interfaces are mature and the user experience is also mature.
Building and managing a Gantt, in a CNO is a complex task. The complexity is related to the
discussions behind the decision summarized in the Gantt file. Focusing on the collaborative
management of collaborative projects the innovation aspect of the Coll4Pm service is to provide
a collaborative environment in which social interactions among humans takes place based on
trust relationships among humans. To provide this, a number of innovations have been created:
A social integrated web environment in which people can collaborate on Gantt charts.
A personalised notification system by news feeds of events occurred in different
project/discussion rooms.
A social collaborative management of changes based on Web2.0.
Availability of human/company profiles and the management of social relationships among
them by assessment of co-workers, integration of communication services and injection of
trust based mechanism coming from COIN c-HI services in project management.
3.2.5.12 Progress beyond State-of-the-Art in Collaboration Visualization Service (CVT)
Trust relies on previous interactions and collaboration encounters [21]. Recently, trust in social
environments and service-oriented systems has become a very important research area. SOA-
based infrastructures are typically distributed, comprising a large number of available services
and huge amounts of interaction logs. Therefore, trust in SOA has to be managed in an automatic
manner [9]. Although several models define trust on interactions and behaviour, and account for
reputation and recommendation, there is hardly any case study about the application of these
models in service-oriented networks. Fundamental research questions, such as the technical
grounding in SOA and the complexity of trust-aware context-sensitive data management in
large-scale networks are still widely unaddressed.
Depending on the environment, trust may rely on the outcome of previous interactions. Trust is
not simply a synonym for quality of service. Instead, metrics expressing social behaviour and
influences are used in certain contexts. Utilizing interaction metrics, in particular calculated
between pairs of network members, enables the incorporation of a personalized and social
perspective. Progresses beyond the State of the Art include:
Trust models for service-oriented cross-organizational collaborations using data collected
through common human interaction services, such as e-mail or IM; thus, unburden actors
from managing relations manually.
64
Exploiting trust networks to support actor discovery (e.g., in social campaigns) and
compositions (e.g., team formation) in highly dynamic networks that are frequently updated
based on occurring interactions (and not only based on manual relation definitions).
3.2.5.13 Progress beyond State-of-the-Art in Trusted Information Sharing Service (TIS)
In collaborations, activities are the means to capture the context in which human interactions take
place. Activities describe the goal of a task, the participants, utilized resources, and temporal
constraints. Studies regarding activities in various work identify patterns of complex business
activities, which are then used to derive relationships and activity patterns. Studies on distributed
teams focus on human performance and interactions even in Enterprise 2.0 environments. Based
on log analysis, human interaction patterns can be extracted [21].
Trusted information sharing, as applied in COIN, is related to selective dissemination of
information (SDI), that deals with questions regarding which (parts of) data are shared with
others, and mechanisms to disseminate data. TIS adopts the concepts of SDI, such as the
representation of information through mechanisms to process XML-based data. However, SDI
does not deal with underlying social models to control sharing of information. Progresses beyond
the State of the Art include:
Trusted information sharing can be considered as a soft access control model that allows only
trusted partners to see ones private profile or uploaded business documents. Once
configured, TIS adapts the amount of shared information flexibly without human
intervention based on dynamically changing trust relations.
TIS can be used in social campaigns, e.g., to control the dissemination of invitations based on
interest profiles and expertise levels. This way, spamming individuals with documents and
messages that are definitely not of interest for them is avoided.
3.2.5.14 Progress beyond State-of-the-Art in Trusted Online Help and Support (TOHS)
Service-oriented Architectures (SOA) typically comprise software services only. Many
collaboration and composition scenarios involve interactions between human actors as well as
software services. Current tools and platforms offer limited support for human interactions in
SOA, therefore Human-Provided Services (HPS) are introduced. HPSs are offered by human
actors. Web services technology is used to describe HPSs and to enable interactions with real
people. HPSs can be used in various collaboration settings on the Web to facilitate expert
discovery and interactions in a service-oriented manner. In COIN, the concept of HPS enables
the expert seeker to discover the right collaboration partners [7] [10].
Compared to other tools and approaches applying expert discovery, THOS does not demand for
manually maintained skill profiles that need to be frequently updated by the user. The used
approach is based on dynamic profiles and collaboration behavior. Dynamic profiles are based
on monitoring of interactions and analysis of relations.
Progresses beyond the State of the Art include:
Unified view on human and software services capturing characteristics of humans, Human-
Provided and Software-based Services. It enables the specification and matching of
multidimensional service descriptions which is essential in the context of Human-Provided
Services. Such an approach is beyond current state-of-the-art and opens up unprecedented
opportunities for future platforms.
Context model capturing social and community aspects. Social information includes friend
networks and can be used to recommend services or compositions. Community aspects
describe the evolution of, for example, preferences and interests, at a global level.


65
3.2.6 Conclusions and Key Benefits
The developed services support key operational functions in a CNO. In this respect, the COIN
project has gone beyond current work by not only building on various existing work, but also
introducing new innovative concepts and services that support dynamic collaboration models in
networks of enterprises. The COIN Innovative Enterprise Collaboration services have been
successfully demonstrated in real life industrial settings in a number of cases.
The process of analysing the usability and take-up of the services as wells as the process of
bringing COIN to the market and creating value for the various stake holders is being described
in a later section of this book.

References
[1] Ollus M., Jansson K., Karvonen I., Uoti M. Riikonen H. On Services for Collaborative Project
Management Taylor & Francis, Production Planning & Control. ISSN: 1366-5871 (electronic) 0953-
7287 (paper)
[2] OntoGen. Text-Mining Software. http://ailab.ijs.si/publications/ accessed 16.6.2011
[3] Sitek, P., Sesana, M., Truong, H-L. (2009), On Baseline IT-Services to Support Enterprise Collaboration, in
Proceedings of the 15th International Conference on Concurrent Enterprising (ICE2009), Sofia Antipolis,
France
[4] Sitek, P., Seifert, M., Thoben, K.-D. (2010a) Towards an inter-organisational perspective to manage quality
in temporary enterprise networks, in International Journal for Quality and Reliability Management, Volume
27, Issue 2, 2010, pp 231 246
[5] Sitek, P., Seifert, M., Thoben, K.-D., Cannas, V. (2010b) Impact of Inter-Organisational Inter-dependencies
on collaborative Quality Management in Enterprise Networks, in Proceedings of the 16th International
Conference on Concurrent Enterprising (ICE2010), Lugano 2010, Switzerland, ISBN 978 0 85358 2700
[6] Sesana M., Taglino F., Cannas V., Gusmeroli S., Production Planning and Knowledge Interoperability
Utility and Value-Added Services in Aerospace Domain , in proceedings oft he eChallenges 2010
conference 27-29 October 2010 Warsaw - Poland
[7] Schall D., Truong H.-L., Dustdar S. (2008) Unifying Human and Software Services in Web-Scale
Collaborations,
[8] IEEE Internet Computing, vol. 12, no. 3, pp. 62-68, May/Jun, 2008.
[9] Skopik F., Schall D., Dustdar S. (2010). Modeling and Mining of Dynamic Trust in Complex Service-
oriented Systems. Elsevier Information Systems Journal (IS), Volume 35, Issue 7, November 2010, pp 735-
757. Elsevier.
[10] Skopik F., Schall D., Psaier H., Dustdar S. (2011). Adaptive Provisioning of Human Expertise in Service-
oriented Systems. 26th ACM Symposium On Applied Computing (SAC), March 21-25, 2011, Taichung,
Taiwan. ACM.
[11] COIN Project Portal: http://www.coin-ip.eu/ accessed 20.5.2011.
[12] Kurumluoglu, M., Nostdal, R., Karvonen, I. 2005. Base concepts, in Camarinha-Matos, L., Afsarmanesh,
H., Ollus, M. (eds.), Virtual organizations. Systems and Practices, Springer-Verlag. 2005; 11-28.
[13] Mills, A. (1998). Collaborative Engineering and the Internet: Linking Product Development Partners via the
Web. Society of Manufacturing Engineers, Dearborn, Michigan.
[14] CycKB The Cyc Foundation. http://www.cyc.com/ accessed 20.5.2011.
[15] COIN Deliverables D4.2.1b c-Product Development Services, 2009
[16] COIN Deliverables D4.2.2b c-Product Development Services Prototypes and Factsheets, 2009
[17] COIN Deliverables D4.3.1b c-Production Planning Services, 2009
[18] COIN Deliverables D4.3.2b c-Production Planning Services Prototype and Factsheets, 2009
[19] COIN Deliverables D4.4.1b c-Project Management Services, 2009
[20] COIN Deliverables D4.4.2b c-Project Management Services Prototypes and Factsheets, 2009
[21] COIN Deliverables D4.5.1b c-Human Interaction Services, 2009
[22] COIN Deliverables D4.5.2b c-Human Interaction Services Prototypes and Factsheets, 2009
66
3.3 COIN Enterprise Interoperability Baseline Services
Enrico Del Grosso
1
, Gorka Benguria
2
, Francisco Javier Nieto De-Santos
3
, Francesco Taglino
4
,
Brian Elvester
5

1TXT e-Solutions, Italy (enrico.delgrosso@txt.it)
2ESI, Spain (Gorka.Benguria@esi.es)
3ATOS, Spain (francisco.nieto@atosresearch.eu)
4CNR-IASI, Italy (taglino@iasi.cnr.it)
5SINTEF, Norway (Brian.Elvesater@sintef.no)
Abstract
Enterprise Interoperability [3] is a relatively recent term that describes a field of activity with the aim to improve the
manner in which enterprises, by means of information and communications technology (ICT), interoperate with other
enterprises, organisations, or with other business units of the same enterprise, in order to conduct their business. This
paper describes part of the work that COIN project has performed in the context of Enterprise Interoperability.
Starting from past experiences in European projects, COIN has developed a set of baseline interoperability services
that aims to solve and cover most of the Interoperability problems that SMEs are currently facing.

Keywords: COIN, enterprise, interoperability, services, ATHENA, baseline, EI service framework
3.3.1 Towards Enterprise Interoperability services
Experiences from piloting activities in the ATHENA project suggested that Enterprise
Interoperability is very challenging and that the expected gains from interoperability research
will consist in finding technologies and methods that will fasten interconnection of applications
through standardised Web infrastructure for software application communication and for
collaboration [1].
The research projects on interoperability in the European Commission Sixth Framework
Programme have developed a vast set of standalone software products and tools, as well as some
Web-based services to address interoperability issues. However, some of these solutions are
difficult to integrate and use for SMEs because of the lack of technology background.
Furthermore, numerous architectural frameworks and sector-specific specifications have arisen
from the standardisation arena. Moreover, the service-oriented computing paradigm and service-
oriented architecture (SOA) have emerged as a major evolutionary step, with Web services, Grid
services and peer-to-peer (P2P) services comprising the major trends. This has been joined by
developments in Semantic Web Services, enterprise modelling, as well as other modelling and
process languages to describe business processes and their executions.
Today, the market is saturated with technology-based solutions that claim to support
interoperability for enterprises, with several commercial middleware solutions among the most
prominent.

Within the context of an enterprise, flexibility, fast development and re-configuration are
important properties for software applications. This implies to avoid as much as possible the
intervention of software engineers and developers, and to prefer direct parameterisation and
configuration by software users. This also implies accurate ways to architecture enterprise
applications that facilitates publication of information managed by the application, publication of
services made available by the application for other applications and finally publication of
services made available for the human users. Finally such architectures should make it possible
to manage coherency of the application systems despite numerous existing interfaces and
adaptation of the application systems within the whole enterprise.


67
In the COIN context, Enterprise Interoperability (EI) services provide functionality for applying
IT solutions that overcome interoperability gaps between two or more enterprises and thus
enabling them to set-up and run collaborations. The main goal of the EI services is to improve
enterprise interoperability, mainly for SMEs, which means to reduce the costs of data
reconciliation, systems integration and business processes synchronization and harmonization.
Typical indicators will be in the cost of service composition and of data mediation and
reconciliation.
3.3.2 COIN EI framework
The COIN EI Services Framework adopts the ATHENA Interoperability Framework (AIF)
[1].
A framework is a structure for supporting or enclosing something else, especially a skeletal
support used as the basis for something being constructed. An interoperability framework
provides a set of assumptions, concepts, values and practices that constitutes a way of viewing
and addressing interoperability issues.
3.3.2.1 ATHENA Interoperability Framework
The interoperability reference model relates the solution approaches coming from the three
different research areas of ATHENA, namely enterprise modelling, architectures and platforms,
and semantic mediation and ontology. Figure 41 illustrates the reference model that focuses on
the provided and required artefacts of two collaborating enterprises. Interoperations can take
place at the various levels (enterprise, process, service and information/data).
Enterprise
(Business)
Processes
Services
Information/Data
Cross-Organisational
Business Processes
Collaborative Enterprise
Modelling
Flexible Execution and
Composition of Services
Information/Data
Interoperability
M
o
d
e
l
-
D
r
i
v
e
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
S
e
m
a
n
t
i
c

M
e
d
i
a
t
i
o
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
Enterprise
(Business)
Processes
Services
Information/Data
Provided Required

Figure 41 - Interoperability reference model

An interoperability reference architecture relates a set of interoperability levels and a set of
interoperability approaches. An interoperability level denotes the capability level of two or more
collaborating entities to support interoperation.
Interoperability at the enterprise level should be seen as the organisational and operational
ability of an enterprise to factually co-operate with other, external organisations in spite of
e.g., different working practices, legislations, cultures and commercial approaches.
68
Interoperability at the process level is the capability to make proper external views of
enterprise internal processes synchronised by a collaborative inter-enterprise business
process.
Interoperability at the service level is concerned with discovering, ranking, selecting,
composing, orchestrating and executing various applications implemented as a service.
Interoperability at the information/data level is related to the exchanging and sharing
business documents among organizations, by filling interoperability gaps related to the
payload (format and content) and to the messages and/or structures to be exchanged.
The interoperability approaches help us to support interoperations at the various interoperability
levels. A model-driven interoperability approach that cuts across the four interoperability levels
implies that models are used to formalise and exchange the provided and required artefacts that
must be negotiated and agreed upon. ATHENA defines a set of meta-models and languages that
can be supported by tools and methods to construct the models in question.
To overcome the semantic barriers which emerge from different interpretations of syntactic
descriptions, precise, computer processable meaning must be associated with the models
expressed on the different levels. It has to be ensured that semantics are exchangeable and based
on common understanding in order to enhance interoperability. This can be achieved using
ontologies and an annotation formalism for defining meaning in the exchanged models.
3.3.2.2 COIN EI services framework
After a preliminary study of the services and tool that constitute the state of the art, 6 EI service
categories have been chosen from the AIF model:
1. model-driven
2. enterprise modelling
3. business process
4. service*
5. information/data
6. semantic mediation

Enterprise
(Business)
Processes
Services
Information/Data
Cross-Organisational
Business Processes
Collaborative Enterprise
Modelling
Flexible Execution and
Composition of Services
Information/Data
Interoperability
M
o
d
e
l
-
D
r
i
v
e
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
S
e
m
a
n
t
i
c

M
e
d
i
a
t
i
o
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
Enterprise
(Business)
Processes
Services
Information/Data
Provided Required
*Service
interoperability
is addressed by
the COIN Service
Platform (SP3)

Figure 42 - Baseline categories according to AIF

Since the service interoperability is being addressed by the COIN Service Platform the COIN EI
Services Framework adopts five service categories for EI:


69
Model-driven interoperability services support enterprises to formalise, exchange and align
models that are relevant to set up collaborations.
Enterprise modelling interoperability services support enterprises to factually co-operate
with other, external organisations in spite of e.g., different working practices, legislations,
cultures and commercial approaches.
Business process interoperability services support enterprises to make proper external views
of enterprise internal processes synchronised by a collaborative inter-enterprise business
process.
Semantic mediation interoperability services support enterprises to apply ontology-based
techniques for semantic mediation such as semantic reconciliation of business documents in
order to support interoperability among heterogeneous software applications.
Data interoperability services support enterprises to exchange and share business documents
among organizations, by filling interoperability gaps related to the payload (format and
content) and to the messages and/or structures to be exchanged.
3.3.3 Enterprise interoperability baselines
Services to include in the COIN EI Services Framework have been chosen according to a precise
methodology.
First step has been the analysis of existing state of the art. A lot of work has been done in the
field of interoperability by past European Projects, so all the existing work have been evaluated
to choose which one to include and how.
As a result of this first step, a list of sub-service categories has been found for each framework
categories. These sub-service categories represent specializations and specific domains of each
EI service framework category.
Final step of the process has been the definition of the services to implement for some of these
sub-service categories. The ratio used to select the services to implement derived from end user
requirements and available software from previous works.
The following table shows the list of services that constitute the COIN EI Services Framework.
Table 2 - COIN EI Baseline Services and descriptions
# Baseline EI service Service description
1
COIN Model
Transformation
Service Engine
The engine will be a service entry point for storing model transformations that are aimed
at aligning the huge diversity of models used in the design, integration and
implementation tasks of enterprise applications and systems.
2
COIN POP*
Transformation
Service
The service will provide the functionality of modelling in the context of POP* to JPDL
transformation. The results of the transformation should be published into the open
source JBPMN platform.
3
COIN Enterprise
Interoperability
Maturity
Assessment
Service
The service will help to assess an organization's maturity level concerning the use of
enterprise models as well as the capability of these models to enable the company to be
part of collaboration. Based on this assessment, companies will be guided to choose the
right concepts for improving their capabilities, by taking into account actual market and
enterprise challenges.
4
COIN Semantic
Business Process
Modelling Service
The service will help to reduce the complexity of tasks related to transformation
between different BP models as well as transformation in executable process models
with semantic annotations.
5
COIN Semantic
Business Process
Management
Service
The service will manage the life cycle of deployed Business process models
independently on the underlying engines actually executing the model.
70
6
Athos Ontology
Service
The service will provide functionalities for ontology management. Ontology is a pre-
requisite for semantics-based mediation and reconciliation of business documents.
7
Astar Semantic
Annotation Service
The service will provide functionalities for management of semantic annotations.
Semantic annotation allows digital resources to be described in terms of a common
reference represented by a domain ontology. Such an activity represents a first
identification of semantic and structural mismatches among different information
structures, which is needed for fulfilling interoperability issues among heterogeneous
information systems.
8
Argos Semantic
Transformation
Rules Service
The service will provide functionalities for management of transformation rules service.
Transformation rules represent the semantic mapping able to drive the mediation and
reconciliation.
9
Ares Semantic
Reconciliation
Service
The service will represent the final step towards the actual mediation and reconciliation
of business documents among heterogeneous information systems.
10
COIN Massive Data
Interoperability
Service
The service allows communication among a set of multiple data providers and a set of
multiple data consumers. In a multi-point communication, the interoperability problem
grows exponentially according to the number of entities involved in the communication.
The service will allow the data providers to map their data structure to the requested
schema and fill the schema itself with the data coming from their data sources.
11
COIN Transactional
Data
Interoperability
Service
The service allows the communication between two actors; a customer and a supplier.
The scenario of the communication is the exchange of business documents in the order
to invoice procurement process.

In this other table are listed the sub-service categories of each EI service framework category and
which services correspond to each sub-category.
Table 3 - COIN EI Baseline Services according to framework category
Sub-service category Service Name
Model-driven
interoperability
services
Metamodelling -
Language engineering -
Model mapping and transformation COIN Model Transformation Service Engine
Method engineering -
Enterprise
modelling
interoperability
services
Enterprise modelling -
Enterprise models interchange COIN POP* Transformation Service
Enterprise model deployment
Enterprise interoperability maturity
assessment
COIN Enterprise Interoperability Maturity
Assessment Service
Business process
interoperability
services
Cross-organizational business process
modelling
-
Semantic business process modelling COIN Semantic Business Process Modelling Service
Semantic business processes
management
COIN Semantic Business Process Management
Service
Business process monitoring -
Business process analysis -
Semantic
mediation
interoperability
services
Ontology editing Athos Ontology Service


71
Ontology engineering and maintenance -
Semantic annotation Astar Semantic Annotation Service
Semantic transformation rules building Argos Semantic Transformation Rules Service
Semantic reconciliation engine Ares Semantic Reconciliation Service
Data
interoperability
services
Data mapping COIN Massive Data Interoperability Service
Data infrastructure framework -
Business document modelling -
Business document interchange COIN Transactional Data Interoperability Service
Business document process integration -

References
[1] ATHENA A4, "D.A4.2: Specification of Interoperability Framework and Profiles, Guidelines and Best
Practices", ATHENA IP, Deliverable D.A4.2, 2007a. http://interop-vlab.eu/ei_public_deliverables/athena-
deliverables/.
[2] B. Elvester, G. Benguria, A. Capellini, E. Del Grosso, F. Taglino, COIN D5.1.1 State-of-the-Art and
Baseline EI Services Specifications, July 2008.
[3] M.-S. Li, R. Cabral, G. Doumeingts, and K. Popplewell, "Enterprise Interoperability Research Roadmap,
Final Version, Version 4.0", July 2006.
72
3.4 COIN Innovative EI Services
Enrico Del Grosso
1
, Fabrizio Smith
2
, Hannes Suttner
3
, Francesco Taglino
2

1

TXT e-solutions, Via Frigia, 27 20126 Milano)
2

Istituto di Analisi dei Sistemi ed Informatica A. Ruberti, Viale Manzoni, 30 00185 Roma)
3

Siemens IT Solutions and Services, Gudrunstrae 11 1101 Wien
Abstract
To create added value in a highly competitive, global market, nowadays organisations especially Small and
Medium-sized Enterprises (SMEs) more than ever have to cooperate with appropriate business partners, identify
state-of-the-art business processes and select the best technologies available. This business environment positively
affects demand for Enterprise Interoperability Services (EIS) aiming to provide services to facilitate co-creation, and
services to surmount or even to prevent interoperability issues.
The COIN project adopted the ATHENA EI reference framework which addresses interoperability at different levels.
COIN adapted and substantiated the established concepts, and implemented several services particularly with regard
to information interoperability, process interoperability and knowledge interoperability. This summary highlights a
few out of the many COIN results in the EI domain, i.e. semantic reconciliation of business documents, introduction
of the visibility rules concept, business process gap detection, as well as knowledge sharing of key competences and
skills of enterprises cooperating in a cluster.

Keywords: Enterprise Interoperability, Semantics, Business Process, Information Interoperability, Knowledge
Interoperability, Process Interoperability
3.4.1 Introduction
Enterprise Interoperability [3] is a relatively recent term that describes a field of activity with the
aim to improve the manner in which enterprises, by means of information and communications
technology, interoperate with other enterprises or organisations to conduct their business. In the
COIN context, Enterprise Interoperability (EI) services provide functionality for applying IT
solutions that overcome interoperability gaps between two or more enterprises and thus enabling
them to set-up and run collaborations.
The main goal of the EI services is to reduce the costs of data reconciliation, systems integration
and business processes synchronization and harmonization. The COIN project adopted the
ATHENA EI reference framework (see Chapter 3.3 Baseline EI Services), which addresses
interoperability at different levels, by using two main approaches (i.e., model-driven and
semantics-based). In particular, in this chapter we focus on the following three interoperability
levels:
Information/data level which is related to the exchanging and sharing business documents
among organizations, by filling interoperability gaps related to the payload (format and
content) and to the messages and/or structures to be exchanged.
Process level which is the capability to make proper external views of enterprise internal
processes synchronised by a collaborative inter-enterprise business process.
Enterprise (knowledge) level which refers to the organisational and operational ability of an
enterprise to factually co-operate with other, external organisations in spite of e.g., different
working practices, legislations, cultures and commercial approaches.
In the rest of this chapter, COIN interoperability services are presented. In particular, in section 2
Information Interoperability services; in section 3 Process Interoperability services and in section
4 Knowledge Interoperability services. Then, Section 5 presents the main innovative issues of
the COIN Interoperability services.


73
3.4.2 Information Interoperability services
Information Interoperability services are focused on enabling enterprise information systems to
exchange business documents (e.g., invoices, purchase orders) even if they are not natively
conceived for this purpose. In the COIN project, this activity was mainly devoted to allow:
Exchanging business documents written in UBL (Universal Business Language) in new
interoperability spaces, evaluating several possibilities of exchange: 1:1, 1:n and n:m.
Semantic annotation of business object documents in order to automatically derive the
mediation rules necessary for the semantic reconciliation of formats and contents.
Study how to create federated spaces where the business documents can interoperate each
other without the needs of a common reference models.
In the rest of this section, a description of the main aspects of the information interoperability
services is presented.
3.4.2.1 Data Payload Services
Data Payload services consider the interoperability among business documents in UBL format at
payload level. Payload means that only the content of the document is considered (and not the
structure). Data Payload services apply a rule based logic to manage the change of content in the
different documents. Users can write their own business rules using a graphical tool that translate
such rules into an engine specific XML based language. A dedicated engine applies then all the
rules defined according to specific business logic, like the role of the rule creator or the
sender/receiver of the business document.
3.4.2.2 Semantic Reconciliation services
The semantic reconciliation approach [19]is based on the use of domain ontology as common
reference for the harmonization of heterogeneous data. This harmonization is accomplished into
two different moments: a preparation phase and a run time phase.
In the preparation phase, the schemas of the documents from the software applications are
mapped against the reference ontology. The mapping starts from the semantic annotation and
ends with the building of two sets of semantic reconciliation rules for each document schema: a
forward and a backward set of rules, which allow data transformation from the original format
into the ontology representation and vice-versa, respectively.
The run-time phase concerns the actual exchange of data from an application to another. For
instance, when an application, say, SA
1
, wants to send a document to another application, say,
SA
2
, the reconciliation between the format of SA
1
and the format of SA
2
, is done by applying
first the forward rules set of SA
1
, and after the backward rules set of SA
2
.
3.4.2.3 Federated Interoperability
Federated interoperability is a special approach to interoperability that aims to avoid the use of
any kind of reference model. The interoperability domain is the structure of document, but
instead of putting a middle reference model (ontology) between the two documents, federated
approach is based on the application of several micro-services. Micro-services are atomic
functionalities that apply on single pieces of documents, transforming them into other format.
3.4.3 Process Interoperability services
Cross-organisational Business Process Interoperability (CBPip) Services aims at ensuring a
successful business process collaboration of participating enterprises. In the COIN project, we
concentrated on two services [18]:
74
One service is rule-based transformation of private business processes into public processes.
The public processes of different organizations are then joined together thus forming the
cross-organizational business process which defines the way the organizations cooperate.
The other service is to identify and eliminate interoperability gaps in CBPs.
3.4.3.1 Private2Public Process Transformation
The aim of the Private2Public transformation is to produce a public view of a private process of a
given company, in order to hide all the private and critical data of the private process, resulting in
a simplified process. To this end, we adopted the SBVR (Semantics of Business Vocabulary and
Business Rules) [3] business rule language in order to describe the visibility of different process
elements of a private process. Among the several existing rule languages, SBVR allows a
representation of rules in structured English, which is easily understandable by humans.
The proposed approach and developed services allow describing how a public view should be
produced from a private process, by way of business rules. This is achieved through three
principles:
A Vocabulary (in SBVR) which describes the semantic of Process elements, as well as
the roles of partners in a CBP. The vocabulary defines noun-concepts related to the
modelling of Process elements (Activity, Data) or to their semantics (Sales Department,
Customer, etc.), as well as verb-concepts to specify associations.
The SBVR rules are linked to specific elements of Processes. Indeed when reading a rule,
the transformation service needs to know which elements are described in the rule.
Business rules which specify what should be public. By default, nothing is shown to
partners
11
. The rules are then based on the RBAC principle (Rule-Based Access Control
[4]). The business rules are based on the verb-concept is visible to, and tell which element
in the process should be visible to which kind of partner.
Once a private process has been described by rules, its public view can be extracted. This step is
performed by an ATL [5] transformation, which reads the visibility rules in SBVR and operates
on the XPDL representation of the process.
3.4.3.2 Gap Detection
COIN defines Business interoperability as the capability of two or more systems to cooperate
using exchanged information, and an interoperability gap is a situation when interoperating
business processes do not deliver the expected results while each of the business processes does.
The following kinds of interoperability gaps are addressed by COIN:
Deadlocks: According to the literature [2], deadlocks are situations in which a certain
instance of the model (but not necessarily all) cannot continue working, while it has not yet
reached its end). Deadlocks are classified in the following way: Loop deadlock, multiple
source deadlock, improper structuring deadlock.
Interface Mismatches (e.g., Number of Messages Interface Mismatch, Message Types
Interface Mismatch) which are serious impediment that prevents two separately-modeled
business processes of successful interoperation due to different design assumptions.
3.4.4 Knowledge Interoperability services
In the COIN project, Knowledge Interoperability refers to the capability of exploiting at best the
knowledge of each cooperating enterprise, leveraging on their complementarities, avoiding
unnecessary overlapping. To this end, the main functions of the Knowledge Interoperability

11
This is in fact not described in SBVR, but rather implemented in the transformation itself


75
Services are based on the possibility of identifying the key competences and skills of each
enterprise, matching and contrasting such knowledge among the partners cooperating in a
cluster, identifying missing knowledge to allow for a target enlargement of the cluster.
According to that, Knowledge Interoperability services have been developed for:
acquiring, gathering and organizing knowledge about Competencies and Skills (CS) in a
collaborative network (CN) in the form of a reference ontology (Social Ontology Building
and Evolution service [6]);
describing enterprises CS by means of ontology-based semantic profiles (Enterprise
Semantic Profiling service), in order to represent all the enterprises in a CN in terms of the
same common and shared reference Angelucci et al., 2010];
reasoning on profiles, through semantics similarity techniques, to assess the actual CS asset
of the network, and the impact and added value on the CN due to the entrance of a company
in the CN (Enterprise Semantic Matchmaking service [7]).
In the rest of this section, a brief description of the SOBE service is given.
3.4.4.1 Social Ontology Building and Evolution
The Social Ontology Building and Evolution (SOBE) service supports the building of ontology
about competencies in the context of a cluster of enterprises. SOBE is characterized by three
main aspects:
Automatic knowledge extraction from unstructured enterprise documents, by using natural
language processing techniques [8]. Enterprise documents indeed, are pregnant with
enterprise knowledge. They are data containers that record and drive the processes of the
company.
Social participation of a community of experts. Social aspects during ontology building
and evolution are required since an ontology needs community acceptance. To this end,
SOBE enables the community of experts to validate, discuss about for reaching a consensus,
and enrich the results of the automatic extraction [9].
Step-wise approach that, for reaching the final aim of a domain ontology construction, goes
through intermediate results (i.e., lexicon, glossary, taxonomy).
3.4.5 Main innovation issues
This section underlines what are the main innovative issues introduced by the interoperability
services developed in the COIN project.
3.4.5.1 Information Interoperability services
Concerning the Information Interoperability services for semantic reconciliation of business
documents, the main innovations, with respect to existing solutions [15], [16] [17], regard the
automatic support to the mapping process and the adopted pattern-based approach. This
approach hides to the end user the technicalities of the logic-based underline representation, and
allows the definition of complex data transformations through the instantiations of a limited set
of patterns.
Considering the federated approach for information interoperability, based on application of
micro-services in sequence, compared to the semantic approach, it has both pros and cons. The
main pro is that reconciliation is simpler and more immediate, making this approach suitable for
quick, one shot transformations. The main con is that the format of the document should be
comparable (ideal situation is different versions) in order to have an effective transformation.
This makes semantic approach more complete and general, even if the creation of the middle
ontology can be a very complex work.
76
3.4.5.2 Process Interoperability services
COIN introduces the concept of Visibility Rules, which specify what process elements are
visible to which partner. There are two innovation aspects concerning those rules. Firstly,
Visibility Rules are specified in SBVR, which allows a representation in Structured English. This
means that it is easily readable and understandable by business actors, and provides a very high
usability and friendliness profile. Secondly, such rules are specified in a separate file, and are not
specific to a particular private process: they can be applied to the whole set of private processes a
company has.
COIN allows defining several public views from a single private process, without any change
needed in neither the private process nor the Visibility Rules. This is because the transformation
takes into account three parameters: the private process, the Visibility Rules, and, most important
here, for whom the public process is generated for (e.g. a customer, a finance department or
a supplier). This means that the company can easily parameterise the transformation to its
needs, without having to redefine its strategy concerning the choice of what is private/public.
3.4.5.3 Knowledge Interoperability services
With respect to [10], [11], the SOBE service presents the complete ontology evolution process
and provides a detailed description of the collaborative process (i.e., debating, and voting) and
clear indication of the needed steps and relative milestones. Furthermore, SOBE introduces
automatic supporting tools trying to integrate at best human and software-based activities.
Considering the existing proposals of frameworks for enterprise modelling [12] [13] [14], they
are in general rather complex, trying to capture within a single framework all the different
aspects and dimensions that characterise an enterprise. For this reason, enterprise semantic
profile is here represented as a CS profile in the form of an Ontology-based Feature Vector
(OFV) [7], which is basically a set of concepts from the reference ontology adopted by the
enterprise cluster. It avoids entering the complex theory of enterprise frameworks and it
concentrates on the production capacity of an enterprise, synthesized by its competencies and
skills (CS). Representing each profile as an OFV guarantees the uniqueness of the interpretation
representation. The fact that the representation is not ambiguous derives from the nature of the
terms appearing in the vector(s), which are representative of ontology concepts (hence, ontology-
based feature vectors). This non ambiguity of the representation implies that the represented
enterprises CS are universally intended within the enterprise cluster with a (unique) meaning
accessible to all because connected to the clusters ontology.
3.4.6 Conclusions
In this paper, we presented the Enterprise Interoperability services studied and developed within
the context of COIN project. The research work produced a set of services that can be applied in
different kinds of interoperability domains. Current services have been developed following the
ISU (Information Service Utility) idea, and have been thought to be put in clouds of other
services to be found, orchestrated and executed in different kind of processes according to the
needs of the users. At the moment, these services can be seen as working prototypes that
demonstrate that the ISU idea can be applied to interoperability, and that general services can be
developed to address several kinds of problems in different domains. The next step in this path
will be the development of smart services that can auto-configure themselves according to the
specific problem they are facing.

References
[1] [Li, et al. 2006] M.-S. Li, R. Cabral, G. Doumeingts, and K. Popplewell, "Enterprise Interoperability
Research Roadmap, Final Version, Version 4.0", July 2006.
[2] [Awad and Puhlmann, 2008] Ahmed Awad and Frank Puhlmann: Structural Detection of Deadlocks in
Business Process Models, BIS 2008, LNBIP 7, pp.239250, Springer-Verlag Berlin Heidelberg 2008


77
[3] [SBVR, 2010] Semantics of Business Vocabulary and Business Rules, version 1.0, OMG,
http://www.omg.org/spec/SBVR/1.0/, last visited: 16.04.2010
[4] [RBAC, 2010] http://www.techstreet.com/standards/INCITS/359_2004?product_id=1151353.
[5] [ATL, 2010] ATLAS Transformation Language, version 3.0.0, http://www.eclipse.org/m2m/atl/, last
visited: 16.04.2010
[6] [Angelucci et al., 2010] Angelucci D., Barbagallo A., Di Mascio T., Missikoff M., Taglino F.: A social
platform for enterprise ontology building. Proc. of Open Knowledge Models Workshop. October 2010,
Lisbon, Portugal.
[7] [Formica, 2010] Formica A., Missikoff M., Pourabbas E., Taglino F. : Semantic Search for Enterprises
Competencies Management. Proc. of KEOD 2010.
[8] [DAmadio, 2008] D'Amadio P., Velardi P., Navigli R. Mining the Web to Create Specialized Glossaries -
IEEE Intelligent Systems, 2008
[9] [Barbagallo et al., 2010] Barbagallo A., De Nicola A., Michele Missikoff: eGovernment Ontologies: Social
Participation in Building and Evolution, in the Proceedings of Forty-Third Annual Hawaii International
Conference on System Sciences, IEEE Computer Society Press, 2010
[10] [Tempich et al., 2007] Tempich C., Simperl E., Luczak M., Studer R., Pinto H. S.. Argumentation-Based
Ontology Engineering. IEEE Intelligent Systems 22(6): 52-59 (2007).
[11] [Karapiperis and Apostolou, 2006] Karapiperis S. and Apostolou D.. Consensus building in collaborative
ontology engineering processes, Journal of Universal Knowledge Management 1 (3), 2006.
[12] [CIMOSA, 1996] CIMOSA - Open System Architecture for CIM, Technical Baseline; Version 3.2
CIMOSA Association, private publication (March 1996).
[13] [Zachman, 1987] "A Framework for Information Systems Architecture." John A. Zachman. IBM Systems
Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298. 914-945-3836 or 914-945-2018 fax.
[14] [Williams, 1998] Williams T. J. PERA and GERAM - Enterprise Reference Architectures in Enterprise
Integration. Proceedings of the IFIP TC5 WG5.3/5.7 Third International Working Conference on the
Design of Information Infrastructure Systems for Manufacturing II table of contents Vol. 144 archive, pp. 3
- 30 (1998)
[15] [Kerrigan et al. 2007] Kerrigan, M., Mocan, A., Tanler, M., & Fensel, D. The Web Service Modeling
Toolkit - An Integrated Development Environment for Semantic Web Services. Proc. ESWC 2007,
Innsbruck, AU.
[16] [Mocan et al. 2007] Mocan, A., & Cimpian, E. (2007). An Ontology-based Data Mediation Framework for
Semantic Environments. International Journal on Semantic Web and Information Systems , 3 (2), 66-95.
[17] [Kabak et al. 2009] Kabak, Y., Dogac, A., Ocalan, C., Cimen, S., & Laleci, G. B. (2009). iSurf Semantic
Interoperability Service Utility for Collaborative Planning, Forecasting and Replenishment . eChallenges
Conference. Instanbul, Turkey.
[18] [Huber, et al. 2011] S.Huber, C.Carrez and H.Suttner. Development of Innovative Services Enhancing
Interoperability in Cross-organizational Business Processes. IWEI 2011, Lecture Notes in Business
Information Processing, Volume 76, Part 2, Part 2, pp. 75-88, Springer Berlin Heidelberg, 2011.
[19] [Missikoff et al., 2010] Missikoff M., Smith F., Taglino F.: Semantic Services for Business Documents
Reconciliation. Chapter in the book "Interoperability in Digital Public Services and Administration:
Bridging E-Government and E-Business". Ed. Yannis Charalabidis. 2010. ISBN 978-1-61520-887-6
(hardcover); 978-1-61520-888-3
[20] [Angelucci et al., 2010] Angelucci D.., Barbagallo A. , Taglino F D5.3.1b Innovative Knowledge
Interoperability Services Final Specifications (Deliverable COIN project).
78
4 COIN Demonstrators
4.1 The COIN EI/EC Services in industrial Supply Chains
The impact of COIN Project has been spread on four Supply Chains. Supply Chains are the most
static and long-lasting collaboration form addressed by the project; here is where long term
relations and stable organisational and economic structures among enterprises allow the adoption
of the most optimized and important EI solutions, where optimization and efficiency are of key
importance
This chapter focuses on the four COIN supply-chains pilots, two in the Western Europe: the
EIEC Pilot in an Automotive Supply Chain (ACS) and the Aerospace pilot in the Lazio region in
Italy and two in the Eastern Europe: the Pilot in a Railways Supply Chain (KTU) and the pilot in
a Construction Supply Chain (UPB).



79
4.1.1 An EI/EC Pilot in an Automotive Supply Chain
Simon Oman, Duan Buen
2

1 Polycom d.o.o., Poljane nad kofjo Loko 76 d.o.o., Polycom d.o.o., Poljane nad kofjo Loko 76, Slovenija, simon.oman@polycom.si
2 GIZ ACS, Dimieva 9, 1000 Ljubljana, Slovenija, dusan.busen@acs-giz.si
Abstract
In business environment where supply chains strive to remain flexible, data exchange with the use of information
systems represents a competitive advantage. Ontology has been proposed as an important concept of business
collaboration so as to achieve interoperability of information systems in the supply chain. This paper presents internet
based collaboration in the automotive supply chain. Enterprise Collaboration and Interoperability (EC & EI) brings a
new concept of business collaboration into the automotive supply chain, namely the so-called computing in the
clouds. At the same time, the paper demonstrates a prototype solution presenting a model of data exchange in the
Automotive Cluster of Slovenia (ACS). The presented prototype solution facilitates the companies in the Cluster to
operate more swiftly and ensures a more reliable flow of information.

Keywords: collaboration, interoperability, automotive supply chain, pilot solution
4.1.1.1 Brief History of Automotive Cluster of Slovenia
The market conditions pose an additional challenge to the Automotive Cluster of Slovenia
(henceforth also referred to as the ACS), in particularly, to adapt to the renewal of certain
processes. Companies representing the association in the ACS, therefore, pay more and more
attention to research and development with an objective to keep pace with the development in
the most rapidly growing industry in the world, so as to ensure the introduction of new products
and technologies and thus affect the increased volume of demand. The objective is clear,
effective and profitable growth. Potential for scientific and technological breakthrough in the
automotive industry proves to be extensive and extremely diverse. Collaboration and
interoperability, integration and constant search of potential partners in the construction of
electrical machinery and devices represents a huge potential breakthrough for the ACS. In the
search of new partners focus is paid on equipment and systems of power electronics, systems and
algorithms for the management, supervision and management. Furthermore, the ACS wishes to
streamline in the development of methods for rapid prototyping, as well as the design and
integration of different information technology systems. The latter affects not only the events in
business environment, but also acts decisively on setting strategies, reeling business processes
and organization of companies. Information technology provides valuable contribution to the
replacement of more expensive production since the creators of cheaper, established, more
effective connections between processes facilitate simpler and more reliable integration between
processes and thus contribute to value added in designing new products. Information technology
improves business processes by modifying or transforming activities taking place within the
process, thereby replacing expensive or less efficient process with cheaper and more effective
ones.

It still proves extremely important for the Slovenian automotive industry to strengthen its
position in the world markets, namely through innovation and investment in knowledge and
technology. This should be done now when there are many possibilities for the Slovenian
suppliers arising from the transfer of R&D and manufacturing capability of the vehicle
manufacturers to suppliers of systems. Therefore, the ACS intends to accelerate and enhance the
development of more complex products, such as electronics in the passenger compartment
interior, pedal box, hand brake, brake system, body and lighting equipment, systems, doors,
mirrors, exhaust system, suspension, window systems washer, air conditioning, heating, seats
cooling, steering and safety systems, engine and transmission components (including castings
80
and forgings). Simultaneously, the ACS seeks to establish the development infrastructure for the
development of new solutions for the electrification of vehicles, internal combustion engines,
security and comfort, and technological and manufacturing excellence. In order to provide the
integration of the Slovenian and international associations, the ACS shall upgrade network
connections to share and acquire new skills. By providing extremely flexible environment with
the concentration of development resources on specific development areas the ACS shall seek to
position itself as a flexible development and pre-development suppliers to global vehicle
manufactures. Successful implementation of all R&D projects is a lengthy process that requires a
lot of cooperation and may take several years before its objectives are fully accomplished. As
stated above, in addition to single R&D projects and their objectives, great attention should be
paid to the establishment of strong horizontal and vertical, as well as physical and intellectual
integration, taking into account the specificities of various environments and in accordance with
the principle of partnership and concentration. In this way, R&D projects have an additional
positive effect on the ACS as well as in other fields and areas.
4.1.1.2 Description of relevant facts
Modern manufacturing companies need to establish an efficient strategic cooperation with the
purpose of improving their competitiveness on the market [4]. While attention was paid to
optimisation of production processes in the previous decade, now proves to be the right time to
align supply chain all the way from suppliers to customers [1]. The objective of managing the
supply chain is faster and more flexible coordination among customers and their suppliers [7].
Suppliers operating in the manufacturing field, in particularly, small and medium-sized
companies (SME) call for constant improvement of their operations in the business environment,
thus setting such companies in more favourable economic position [8].

So as to improve organisational interoperability into a complex adjustable system definitely
proves as a challenge and at the same time almost an impossible undertaking. The existing
approaches to modelling a company (e.g. UEML, ARIS), modelling of business processes (e.g.
SCOR model) and work process modelling (e.g. BPEL) definitely strive towards establishing
integration among companies [8]. Increasingly present software allows large and small-sized
companies to join computing in clouds. Services in clouds ensure connectivity of databases and
form a part of information infrastructure allowing companies and organisations to move or
integrate a particular quantity of data on the location in the cloud. Disadvantage of such
integration is the difference among the companies and organisations wishing to collaborate. In
particularly, a question arises as to how collaboration of companies using different software may
be improved.

Empirical studies [3,6] show that the integration of supply chain ensure better operative and
business success. In order to make use of all advantages offered by the integration of supply
chain, it is important to reorient operations into an exchange of information among companies
[2]. There are many sub-suppliers in automotive sector using simple software to manage
information flow. However, different translators are used to meet the needs of collaboration. The
role of small and medium-sized companies in the automotive sector has been increasing
dramatically the fact being that they provide various support to large companies. In doing so,
they constantly face with software technology, which proves extremely expensive and hard to
manage for small and medium-sized companies, bearing in mind that software with its
maintenance is becoming more and more expensive, while the needs for staff and knowledge on
managing such software are becoming ever greater. Alignment of processes for joint projects
proves extremely important since the collaboration and alignment of operation in the supply
chain brings valuable value added. The existing solutions represent provision of comprehensive


81
information support for companys internal processes [5]. Said processes are generally roughly
divided into commercial and technical processes both requiring intensive collaboration.

Commercial process (Figure 43) is characterised with the fact that most orders and call-offs are
received with the help of software which enables computer data exchange. All orders and call-
offs are recorded and archived in business information system and allow the company to make
necessary and required forecasts.

Figure 43 Commercial Process

Technical process, on the other hand, requires that business information system accepts
development detailed lists elaborated on the basis of the CAD/CAD/CAE technical system. Each
production detailed list contains all component parts of the tool for injecting thermoplastic
material. Each semi-manufactured product is accompanied with the order system or work order
system. Calculation of needs for material and cooperation is performed on the basis of semi-
manufactured product status. Calculation facilitates elaboration of purchase orders (needs for
cooperation and material). This is followed by processing technology which, in principle,
represents the drawing up of technical processes and work instructions. Feedback serves for
reporting on the status of work order or, in this case, for reporting on the status of tool, however,
it is important to emphasise that technical process envisages managing of data on different levels
which includes also the production of electrodes for a particular semi-manufactured product and
cooperation (Figure 44).

Figure 44 - Technical process
- BOR (Book Of Requirements)
- BOM (Bill Of Materials)
4.1.1.3 Presentation of pilot solutions
A developing software feature enables large and small-sized businesses to take part in computing
in the clouds. Services in the clouds provide database connection and are a part of the IT
infrastructure, enabling companies and organisations to connect or integrate an amount of data
82
on the location in the cloud. All the aforementioned allows the Automotive Cluster of Slovenia
to offer a business model which provides a variety of open source solutions (orders, call-offs,
plans, preview of 3D models, etc.) on the market. These open source services shall allow an
integration of businesses that are different in manpower and industrial branches in the supply
chain. Advantage of business model provides various benefits such as:
new business opportunities;
connections with partners who do not have internal IT platforms (SMEs & smaller);
connections with partners who have different and/or unrelated IT platforms (SMEs &
smaller);
better communication between partners who have different SW or without it (for example
CAD);
safe work on common documents that are on the same platform;
time savings in product development (henceforth referred to as PD) phase;
reduce total cost of PD phase;
From technical point of view the solution provides a new mental dimension which shall be
presented hereafter. First of all, a joint ACS server with different services installed (orders, call-
offs, plans, preview of 3D models, etc.) needs to be set up