FInest Future Internet enabled optimisation of transport and logistics networks

Transcription

1 FInest Future Internet enabled optimisation of transport and logistics networks Deliverable D3.4 Technical Specification of the Domain-Specific Future Internet (FI) Platform for Transport and Logistics and Phase 2 Implementation Plan Project Acronym Project Title FInest Project Number Future Internet enabled optimisation of transport and logistics networks Workpackage WP3 (Solution Design and Technical Architecture) Lead Beneficiary SAP Editors Michael Stollberg SAP Andreas Metzger UDE Contributors Michael Stollberg SAP Andreas Metzger René Fleischhauer Stephan Heyne Rod Franklin UDE SAP SAP KN D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 1 of 87

2 Marianne Hagaseth Clarissa Marquezan Guy Sharon Fabiana Fourier Özgür Sönmezer Serdar Arslan Gökhan İşleyen MRTK UDE IBM IBM KOC KOC KOC Reviewers Michael Zahlmann KN Oyvind Olsen Evert-Jan van Harten Kay Fjørtoft NCL AFKL MRTK Dissemination Level PU Contractual Delivery Date Actual Delivery Date Version 1.0 D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 2 of 87

3 Abstract This report presents the fourth and final Deliverable of work package WP3 Solution Design and Technical Architecture that is concerned with the overall design and architectural specification of a Future Internet enabled collaboration & integration platform for transport and logistics business networks. As the closing report on the overall solution design that has been iteratively revised throughout the project, it presents the final technical architecture along with the coordination of the use case driven development of the FInest Core Module prototypes, and a detailed plan for continuation, extension, and implementation Phase 2 of the FI PPP that is manifested in the successful preparation of the cspace project, a Phase 2 Use Case project that presents a merger of the Phase 1 Use Case projects SmartArgiFood and FInest with the aim of developing and validating a Future Internet enabled collaboration platform for business networks in Agri-Food, Transport and Logistics. With this, the deliverable presents the final results of Tasks T3.1 T3.5 as defined in the Description of Work (DoW). With respect to the project objectives and plan for the last milestone (M19-M24, the work has been conducted in two parallel work streams: the Technical Work Stream has been concerned with the technical specifications of the FInest Platform and the coordinated development of the FInest Core Module prototypes, and the Phase 2 Preparation Work Stream that has been concerned with the planning and preparation for the continuation and extension of the FInest results in Phase 2 of the FI PPP. The report is structured into 4 parts: Part (A) introduces into the report with a detailed outline and the relationship to the other work packages, Part (B) provides the results on the technical work stream in close relation with the final deliverables WP5-WP8 wherein the FInest Core Modules have been developed, Part (C) presents the main results of the Phase 2 Preparation Work Stream, and Part (D) concludes the deliverable. The main achievements presented are: The final version of the overall technical architecture that defines the interaction of the FInest Core Modules and other building blocks (refinement of the M18 interim version) The coordinated development of the FInest prototypes, particular the integrating demonstration scenario for the Fish Use Case from WP2 and the deployment on an access-control cloud infrastructure hosted by KocSistem (details on each of the FInest Core Module prototypes are provided with WP5-WP8) A detailed plan for Phase 2 of the FI PPP, particularly including the overall concept of the cspace that leverages on and extends the solution designed in FInest along with the detailed implementation- and time plan for the cspace project indicating how the results of the FInest project shall be continued and when releases are planned The progress towards the technical design for the main building blocks of the cspace, including proof-of-concept implementation for validating Generic Enablers available from FIWARE as well as refined and new conceptual designs for the cspace, therewith providing preparatory works in order to allow for a flying start into the cspace project. Finally, we discuss the experiences and lessons learned from applying modern methodologies for lean and agile software development such as SCRUM and Design Thinking throughout the project, which might be relevant for future projects in Phase 2 of the FI PPP and beyond. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 3 of 87

4 Document History Version Date Comments V Initial TOC + Content Outline V Initial Content V Revised TOC (defined in Plenary Meeting) V Detailed Outline and Write-Up Plan V Integrated contributions (for Parts B and C) V Added Part A, refinements in Parts B and C V Integrated contributions (for Parts B and C) V Added Part D, minor revisions V Prepared for internal review V Incorporated reviews + prepared for submission D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 4 of 87

5 Table of Contents Document History... 4 Table of Contents... 5 List of Tables... 8 List of Figures... 8 Acronyms PART (A): INTRODUCTION & OUTLINE Introduction Outline Relation to other Work Packages and Deliverables PART (B): FINAL ARCHITECTURE & PROTOTYPES Overall Technical Architecture (Final Version) Technical Design Approach Technical Architecture Components Technical Interface Definitions (Core Modules) Interactions between FInest Modules and Components Core Module Prototypes Coordinated Prototype Development Integrating Demonstration Scenario Overall Information about Demonstration Scenario Walk-through on Demonstration Scenario PART (C): PHASE 2 IMPLEMENTATION PLAN The cspace Overall Concept Main Features and Building Blocks D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 5 of 87

6 Stakeholders and Usage Model Relationship to FInest Results Conceptual Design & GE Validation Front-End Conceptual Design for cspace Comparison to existing Solutions cspace Store Initial Conceptual Architecture and Features Initial Assessment of relevant Generic Enables Comparison to Existing Commercial Solutions System & Data Integration Revision of the Technical Architecture Evaluation of Mediation GE (WSO2 ESB) Platform Middleware and Operating Environment Requirements and Initial Conceptual Design Key Features and Relevant Generic Enablers Security, Privacy, and Trust FInest User Management & Access Control Prototype Refined Conceptual Design & Phase 2 Plan Overall Phase 2 Implementation Plan The cspace Project: Overall Aim and Approach cspace Work Breakdown Elaboration of cspace Technical Work Streams cspace Development (WP 200) cspace Hosting & Experimentation (WP 300) Use Case Trials and Domain Apps (WP 400) Mapping of FInest Modules / Components to cspace D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 6 of 87

7 8.5. Overall Milestones and Software Releases PART (D): CONCLUSIONS Summary of Report & WP3 Achievements Solution Design in FInest Lessons Learned REFERENCES D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 7 of 87

8 List of Tables Table 1: Technical Interfaces of FInest Platform (Core Modules) Table 2: Screenshots of demonstration story for the actions associated with the shipper and forwarder issues Table 3: Screenshots of demonstration story for the actions associated with the carrier issues. 35 Table 4: Workflow End-User Table 5: Workflow Business Process Engineer Table 6: Workflow App Developer Table 7: cspace Store Components & Relevant Generic Enablers Table 8: cspace Securitry Requirements and Planned GE Usage Table 9: Mapping of FInest Modules/Components to cspace Table 10: Definition and timing of cspace Technical Milestones (Year 1) Table 11: Definition and timing of cspace Technical Milestones (Year 2) List of Figures Figure 1: Final Overall Technical Architecture of the FInest Platform (High-level View) Figure 2 - Interactions between FInest platform elements Figure 3 Overall scope of the Story Demo Figure 4 Basic graphic elements for describing the demonstration story Figure 5: cspace Overall Vision (multi-domain Collaboration Space for Business Networks). 38 Figure 6: cspace High-Level Conceptual Architecture Figure 7: cspace Front-End (initial concept) Figure 8: cspace Store - High-level Conceptual Architecture Figure 9: Successful response from DAYS_FInestTest service Figure 10: FInest User Management (Screenshot) Figure 11: Start Page for Access-Controlled FInest Prototypes (Screenshot) D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 8 of 87

9 Figure 12: User-specific Start Page of BCM Prototype (Screenshot) Figure 13: FInest User Management based in IDM Generic Enabler Figure 14: Workflow of Single-Sign-On facility Figure 15: Technical Specification of Security-Privacy-Trust Framework Figure 16: Overall project strategy and high-level work breakdown structure Figure 17: High-level structure of WP200 cspace Development Figure 18: High-level structure of WP300 cspace Hosting & Experimentation Figure 19: High-level structure of WP400 Use case trials and domain Apps D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 9 of 87

10 Acronyms Acronym Agile App ASP B2B B2C Back-End BCM BPEL Cloud Collaboration Objects (CO) Explanation Here referring to agile software development as methods for iterative and incremental development where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Short form for an application running in mobile devices Application Service Provisioning (traditional model of software delivery) Business to Business Business to Consumer Layer of the FInest Platform for facilitating the integration of external systems (legacy & standard business systems, 3 rd -party services...) Business Collaboration Module Business Process Execution Language (OASIS standard) Infrastructure for providing computational resources (servers, virtual machines, etc.) in a centrally management environment; platforms, services, and applications can be deployed on this in order to minimize the TCO (total cost of ownership) as well as other issues relevant for enabling cheap and quick development of high-quality solutions Conceptual element for storing transport- and logistics related information within the BCM module Core Modules The central functional components of the FInest Platform developed in WP5 WP8 (BCM, EPM, TPM, ECM) Demonstrator DOM DoW ECM Ecosystem EPM ERP ETA FInest Platform FI-WARE An early prototype showcasing how the FInest Platform shall support future (To Be) business scenarios in the transport and logistics domain Data Object Model (technical term): the technical model of a data object describing its basic structure and data types Description of Work (Annex I of the Grant Agreement describing objectives, organization, and the detailed work plan of the project) E-Contracting Module An economic system comprised of various stakeholders that conduct business together, forming an overall value added network Event Processing Module Enterprise Resource Planning system: overall term for standard business systems for managing the resources of an enterprise (e.g. customers, employees, sales & orders, etc.); often used as synonym for the older solutions from SAP (e.g. SAP R3 systems, SAP Business Suite) Estimated Time of Arrival The overall technical solution that is designed in the project FI PPP project that develops the Future Internet Core Platform, which consists of so-called Generic Enablers that shall be used for realizing the FInest Platform; see public website: D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 10 of 87

11 Front-End GDL GE GUI HTML IaaS ICT IDM Interface IoS IoT IPS LDAP Linked USDL OMG PaaS PCS PKI RESTful REST Service RFID SaaS SLA SOAP SSL The GUI and access points where end-user interact with the FInest Platform Gadget Description Language : technical annotation language for gadgets (self-contained technical elements that can be added & configured to web-based UIs with respect to individual needs) Abbreviation for Generic Enabler ; term used in the context of the FI PPP, referring to one of the specific generic technologies that are developed in the course of the FIWARE project Graphical User Interface Hypertext Markup Language Infrastructure as a Service Information and Communication Technologies Identity Management - general term for authentication, authorization,roles, and privileges/permissions within or across system Technical element for (automated) information exchange between components Internet of Services : any kind of service (technical, business, non-technical) that is accessible over the Web and can be re-used in various application scenarios, fostering the idea of service-orientation Internet of Things : technologies for receiving information about real-world objects (e.g. via sensor networks) and enable their treatment as programmatically accessible entities in software environments Intrusion Prevention System (system for recognition / prevention of attacks on computer systems) Lightweight Directory Access Protocol, protocol for accessing and maintaining information in distributed directories The representation / refined definition of the Unified Service Description Language (see USDL) based on the Linked Data approach; this is the basic service description model supported by FIWARE Object Management Group, technology standardization body Platform as a Service Port Community System Public Key Infrastructure (security technology) Technical design principle for realizing access to web-based services and resources; also see REST Service A Web Service accessible as a Web Resource, applying to the principles of Representational state transfer (REST) Radio-frequency identification : a IoT technology that uses radio waves to transfer data from an electronic tag (RDIF tag) attached to a real-world object into a software environment via specialized readers Software-as-a-Service, modern delivery model for software systems Service Level Agreement Protocol for exchanging structured information, most commonly used in traditional Web Services Secure Sockets Layer: network protocol for secure information transfer D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 11 of 87

12 SSL SSO SVG TAM TEP TPM UI UML USDL VPN VPN W3C Widget WSDL Secure Socket Layer security technology for reliable information exchange over the Web Single Sign on access control model for a user to various systems Scalable Vector Graphic Technical Architecture Modeling ; modeling standard for architecture diagrams used in the project; TAM is a UML2.0 profile with additional extensions from Fundamental Modeling Concepts (FMC). Transport Execution Plan (detailed description of a part of logistics process) Transport Planning Module User Interface, usually referring to graphical user interfaces for human-machine interaction Unified Modelling Language: established standard for model-driven software engineering published by OMG Unified Service Description Language : comprehensive description model for both technical and business services; in standardization process of W3C as an Incubator (see Virtual Private Network (secure & reliable connections for information transfer over the Web) Virtual Private Network security technology for reliable information exchange over the Web World Wide Web Consortium, standardization body for web technologies (see A part of a GUI that can be added to a web-based Front-End Web Service Description Language (W3C Recommendation) D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 12 of 87

13 PART (A): INTRODUCTION & OUTLINE The following introduces into the report and provides a readers guidance. For this, at first Section 1 outlines the context and depicts the main achievements in M19-M24 of the project, then Section 2 explains the structure of the report, and finally Section 3 provides a detailed explanation of the relationship to the other work packages and deliverables. 1. Introduction This report presents the fourth and final deliverable of work package WP3 that is concerned with the overall Solution Design and Technical Architecture of the FInest project. It provides two main results: (1) the final version of the overall technical architecture for the FInest platform, which defines the overarching technical specification for the FInest Core Modules that are developed and detailed in work packages WP5-WP8 and has been continuously developed throughout the project, in close alignment with the domain analysis and industrial applicability studies presented in WP1 as well as the use case analysis and preparation for experimentation from work packages WP2 and WP4, and (2) a detailed implementation plan for Phase 2 of the FI PPP program where the results of FInest shall be implemented and extended in course of the cspace project, a Phase 2 Use Case project that has been successfully prepared as a merger of the Phase 1 Use Case projects SmartAgriFood 1 and FInest with the aim of developing and validating a Future Internet enabled collaboration platform for business networks in Agri-Food, Transport and Logistics. Recalling the FInest project objectives, the overall aim is to develop and validate a Future- Internet enabled business collaboration platform that shall allow for substantial improvements in the communication, information exchange, and coordination of activities in cross-organizational business networks and pioneer towards future business models for cloud-based business software solutions. The goal of FInest as a FI PPP Phase 1 use case project is to design such a software solution and to provide an initial validation using real-world use cases from the Transport and Logistics domain in order to ensure that it properly meets the requirements, demands, and expectations of domain stakeholders and end-users. Those outcomes shall be extended, implemented, and extensively validated within early trials throughout Phase 2 (planned within the cspace project as mentioned above), and be extended towards large scale trials and industrial uptake in Phase 3; this is considered to provide a thorough contribution to the overall goal of the FI PPP program. With respect to this, the FInest project has continuously refined the overall technical design with the early and recursive validation by domain experts. In this context, WP3 has served as the central work package for coordinating the mutual alignment between the domain-focused analysis of requirements, expectations, business models, and experimentation plans at hand of 1 SmartAgriFood project homepage: D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 13 of 87

14 concrete use cases (cf. WP and WP2), and the technical design, specification, and development of demonstrators and prototypes along with validation of the Generic Enablers provided by FI- WARE (the FI PPP Core Platform project 2 ) that has been conducted in work packages WP4 and WP5-WP8. Applying an iterative and domain-driven R&D methodology, the following key results have been presented in the preceding milestones: an initial conceptual design under consideration of the early domain and use case requirements (M6), a refined conceptual architecture along with early demonstrators and a study on satisfying the detailed domain requirements (M12), and the interim technical specification of the FInest Platform along with a refined overall solution design with respect to domain and user expectations as well as the concepts for commercialization (M18). At the final milestone (M24), it has been planned to provide a final version of the technical specifications of the FInest Platform and to define a detailed implementation plan for Phase 2 of the FI PPP that continues and extends the Phase 1 project results. For this, two parallel work streams have been set-up: 1. The Technical Work Stream, continued from the previous milestone, that has been concerned with the technical specifications of the FInest Platform and the coordinated development of the FInest Core Module prototypes (WP3 being concerned with the overall technical architecture and coordination of the technical work, while the details on the technical specifications and prototype developments are subject to WP5 WP8); the main achievements of this work stream are: o Implementation of Prototypes for the four FInest Core Modules: the Business Collaboration Manager (BCM, WP5), the Event Processing Module (EPM, WP6), the Transport Planning Module (TPM, WP7), and the E-Contracting Module (ECM, WP8); see the respective deliverables for details o Final version of the Overall Technical Architecture in form of a refinement of the interim architecture presented in M18 o Definition and Realization of an Integrated Demonstration Scenario for showcasing the business benefits and the envisioned operational model of the FInest Platform, applying real-world test data from the Fish Use Case (i.e. Use Case 1 from WP2) o Testing and Validation of various Generic Enablers provided by FI- WARE, in the course of the Core Module prototypes as well as proof-ofconcept implementations of other technical building blocks o Deployment of the Prototypes and Integrated Demonstration on an accesscontrolled cloud infrastructure hosted by FInest member KocSistem. 2. The Phase 2 Preparation Work Stream that has been concerned with the planning and preparation for the continuation and extension of the FInest results in Phase 2 of the FI PPP program, which manifested in the successful preparation of the cspace project; the main achievements of this work stream are: o Extension of the FInest concept towards cspace, particularly the extension towards a multiple-domain collaboration space for business networks and the identification of additional components to allow for proper technical interaction 2 FIWARE project homepage: D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 14 of 87

15 and commercialization, as well as including a detailed implementation- and time plan wherein the results of FInest are taken up and continued. o Preparatory works on several technical building blocks in order to provide a solid basis for a flying start of the cspace project, including: Proof-of-Concept implementations that test and validate various Generic Enablers available on the FI-WARE test-bed (namely: User Management & Access Control, System & Data Integration) Refined conceptual design for components that are part of the initial FInest platform and have this been already investigated in detail before (namely: Front-End, Security-Privacy-Trust) Conceptual design and initial assessment of Generic Enablers for additional components required for the cspace solution and which thus have not been investigated in previous deliverables (namely: cspace Store, Middleware & Operation Environment) 2. Outline This deliverable reports on the results of work package WP3, referring to the reports of the related work packages for the respective details. It is structured into four parts: Part (A) introduces the context and depicts the main achievements in M19-M24 of the project (Section 1), explains the structure of the report (Section 2), and provides a detailed explanation of the relationship to the other work packages and deliverables (Section 3). Part (B) reports on the achievements of the Technical Work Stream as outlined above. In particular, it presents the final version of the Technical Architecture for the FInest Platform (Section 4). Please note that this is a refinement of the interim version presented in M18, with refined specifications of the technical interfaces and the detailed specification of the interactions of the four Core Modules. Section 5 documents the work on the integration of the proof-ofconcept implementations of the four FInest Core Modules, including the methodology and a detailed explanation of the integrated demonstration story. The deployment of the prototypes along with a running installation of the integrated demonstration on the cloud infrastructure hosted by KocSistem is reported in Section 7.5; important to note is the set-up and hosting of the FInest prototypes has been conducted in addition to the tasks defined in the DoW. Part (C) presents the results of the Phase 2 Preparation Work Stream. At first, Section 6 introduces the overall concept of the cspace, depicting how it builds up and extends the concepts and results of the FInest project. Then, Section 7 presents the preparatory works towards the cspace project. In particular, this includes: A revised conceptual design of the cspace Front-End that defines key features and depicts Generic Enablers as well as other potential candidates for technical realization (Section 7.1), An initial conceptual design of the cspace Store as the central component for enabling commercialization, along with a detailed assessment of the relevant Generic Enablers for implementation (Section 7.2), A report on a proof-of-concept implementation for the System & Data Integration component, which evaluates the Mediation Generic Enabler from FIWARE for integrating legacy systems (Section 7.3) D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 15 of 87

16 A description of the key features and identification of suitable Generic Enablers for the Middleware and Operating Environment that is needed to allow for the proper operation of the cspace as a distributed cloud application (Section 7.4) A report on a proof-of-concept implementation of the for the User Management and Access Control that validates the IDM Generic Enabler and provides the basis for the deployed FInest prototypes, along with a refined conceptual design and implementation plan for the Security-Privacy-Trust framework for cspace (Section 7.5). On the basis of this, Section 8 presents the detailed implementation plan for Phase 2, reflecting the relevant parts of the work plan of the cspace project. This explains in particular the work breakdown structure and the time plan for releases along with a detailed mapping of where the specific results of the FInest project are allocated within the cspace project, therewith depicting where FInest results are planned to be continued in Phase 2 and when releases of the implementations can be expected. Finally, Part (D) concludes the report. Here, we provide a summary of the deliverable and the main achievements of WP3 on the overall solution design and technical architecture (Section 9). In addition, we reflect on the lessons learned on applying a domain-driven, agile R&D methodology for designing, developing, and validating innovative software solutions; this shall serve as a basis for the cspace project methodology, and might be relevant for activities within other FI PPP projects and beyond (Section 10). 3. Relation to other Work Packages and Deliverables As indicated above, WP3 has functioned as the central technical work package for the alignment and coordination of various activities throughout the project. Hence, the work and achievements of WP3 have strongly determined by the work in other work packages (esp. WP5-WP8 where the FInest Core Modules have been developed, and the design of the experimentation environment in WP4), respectively have been directly determined by other work packages (mainly by the domain- and use case analysis from WP1 and WP2, but also by the collaboration with other FI PPP projects that is coordinated in WP9 as well as the insights gained from dissemination and exploitation activities reported in WP10). To clarify this, the following depicts the relationship of this report to other work packages and deliverables in detail; this may serve as a reading guide for gaining a comprehensive picture of the project results. Following the iterative and agile R&D methodology as defined in the DoW, this report builds upon and extends the previous deliverables of WP3. Throughout the project, the activities for requirements-driven solution, the use-case-driven Demonstrators, and the alignment of Core Module prototypes with an integrated demonstration story have been coordinated within WP3. The main results have been developed and reported as follows: The overall solution design has been conducted in a requirements-driven manner based on the general domain analysis from WP1 (esp. from Deliverables D1.1 and D1.3) and from WP2 (esp. D2.2 and D2.3) and has been continuously revised throughout the project: D3.1 presented an initial conceptual architecture, D3.2 provided a substantial refinement with a detailed analysis on the satisfaction of domain- and use case requirements, and D3.3 presented a refined overall concept; this has been further refined and extended towards the cspace concept (see Section 6). D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 16 of 87

17 The technical architecture for the FInest Platform provides a technical specification for the proof-of-concept prototypes of the FInest Core Modules developed in work packages WP5-WP8; this has also been continuously refined at each milestone (see D3.1 D3.3, and Section 4 of this report), where the overall architecture concerned with the module interaction has been elaborated in WP3 while the detailed technical specifications of the Core Modules are provided in the respective reports of WP5-WP8. The FInest Demonstrators are early conceptual prototypes for showcasing how the FInest concept and core modules can improve inter-organizational collaboration in logistics business networks; presented at the M12 milestone, these have been developed for concrete real-world use case scenarios from WP2 (the so-called TO-BE scenarios, cf. D2.3) with detailed reports in the respective Core Module deliverables (i.e. D5.2, D6.2, D7.2, D8.2) complemented with the coordinated methodology reported in D3.2. The FInest Core Module Prototypes are the proof-of-concept implementations of the Business Collaboration Manager (BCM, WP5), the Event Processing Module (EPM, WP6), the Transport Planning Module (TPM, WP7), and the E-Contracting Module (ECM, WP8); these have been developed in the final milestone (M19-M24), and are reported in Deliverables D5.4, D6.4, D7.4, D8.4 along with the final versions of the technical specifications and phase 2 implementations plans (see Deliverables D5.5, D6.5, D7.5, D8.5); these are completed by the final version of the overall architecture (see Section 4) and the integrated demonstration of the prototypes (Section 5). The pro-active alignment with the FI PPP program activities coordinated in WP9 (see Deliverable D9.3 for the final report) has ensured a close interaction with and contributions to the program-level goals and objectives, compliant with the procedures and activities defined with the governance model and working groups. In particular, the testing and validation of the Generic Enablers provided by FIWARE has been an integral activity of the technical work stream; the final results on this are reported in Deliverables D5.5, D6.5, D7.5, D8.5, and in Section 7 of this deliverable. Also, the continuous interaction with INFINITY has been a substantial part for the design of the experimentation environment in WP4 (see Deliverable D4.4 for the final report). Last but not least, the direct interaction with other FI PPP use case projects has led to the successful preparation of the cspace project (also see D9.3 on this). In addition, the results of WP3 and the technical work stream as a whole have provided the basis for the business model and industrial applicability study conducted in WP1 (see Deliverables D1.5 and D1.6), and for the detailed specification of experimentation plans for the use cases in WP2 (see Deliverables D2.4 and D2.5) as well as for the experimentation environment designed in WP4 (see Deliverable D4.4 for the final report), therewith laying a suitable basis for a flying start into the cspace project in Phase 2 of the FI PPP. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 17 of 87

18 PART (B): FINAL ARCHITECTURE & PROTOTYPES This part presents the final results of the technical work stream that has been concerned with the technical specification of the FInest Platform and the coordinated development of the prototypes of the four FInest Core Modules (namely: the Business Collaboration Manager (BCM, WP5), the Event Processing Module (EPM, WP6), the Transport Planning Module (TPM, WP7), and the E-Contracting Module (ECM, WP8). At first, Section 4 provides the final version of the Technical Architecture for the FInest Platform, focussing on the technical integration and interaction of the Core Modules. For this, it is important to note that: This report is a refinement of the interim version presented in M18, with refined specifications of the technical interfaces and the detailed specification of the interactions of the four Core Modules This section is complemented by the final reports of work packages WP5 WP8 (i.e. Deliverables D5.5, D6.5, D7.5, D8.5) that provide the final technical specifications, GE validation, and phase 2 implementation plans for each Core Module. Then, Section 5 documents the work on the integration of the proof-of-concept implementations of the four FInest Core Modules, including the methodology and a detailed explanation of the integrated demonstration story. For this, it is important to note that: The prototypes along with a running installation of the integrated demonstration story have been deployed on an access-controlled cloud infrastructure hosted by KocSistem (see Section 7.5 for details); this has been conducted in addition to the DoW This section is complemented by the prototype deliverables of work packages WP5 WP8 (i.e. Deliverables D5.4, D6.4, D7.4, D8.4) that provide a fact sheet for the proofof-concept implementations and a documentation for the integrated demonstration story as an illustrative example for the functionality provided by the respect prototype. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 18 of 87

19 4. Overall Technical Architecture (Final Version) This section describes the final version of the overall technical architecture of the FInest platform, which has been developed based on an extension and refinement of the initial overall technical architecture delivered in Month 18 of the project (see deliverable D-3.3, [1]). During this process, experiences in prototypically implementing the FInest core modules and linking them with FI-WARE Generic Enablers (see Section 5 and deliverables D-5.4 to D-8.4) have been taken into account. This technical architecture description is complemented by the phase 2 implementation plan, as laid out in Section 8. In Section 4.1, we first recall the methodology that has been followed to deliver this final technical architecture. Then, we provide the high-level view on the final technical architecture, including the structural breakdown into technical components (Section 4.2), a specification of the technical interfaces between those components (Section 4.3), as well as the description of typical interactions between those modules (Section 4.4). A detailed technical design of those components is provided in deliverables D5.5 D8.5. Complementing the technical architecture of the FInest core modules, a refined description of capabilities and conceptual architectures (albeit not on a detailed technical level) of the additional components required for realizing the collaboration space as envisioned for the cspace are provided in Section Technical Design Approach The design work in FInest followed an incremental and iterative design process, such as to allow for incorporating novel findings and developments. Progress has been achieved along three major milestones: Mo 12 FInest conceptual design: The conceptual design (aka. conceptual architecture) describes the logical structure of the FInest solution (in terms of uservisible features and feature-units, aka. modules), as well as the principle interactions between those modules. Mo 18 FInest interim technical specification: The interim technical specification was delivered in the form of an initial technical architecture, providing a first version of the breakdown into technical components as well as technical interfaces between those components. In simple terms, these technical components and interfaces realize the conceptual features and interactions as laid out in the conceptual architecture. Mo 24 FInest technical specification and implementation plan: The FInest technical specification elaborates the technical architecture by providing a further refinement and extension based on the experiences in developing proof-of-concept prototypes for the FInest core modules. As part of the FInest proof-of-concepts the initial architecture has also been refined down to the level of programmatic APIs, including RESTful APIs which allow integrating with FI-WARE Generic Enablers. The deliverable at hand presents the results of milestone Mo 24, which build on and refine the interim results delivered in Mo 18. The overall design approach, mapping from conceptual to technical components, key technical design decisions, languages and guidelines used to define the technical architecture, as well as the organization and facilitation of the design work in general have already been reported in deliverable D-3.3, and thus the interested reader is referred to that document. Also, it should be noted that to keep the deliverable concise, we focus on the model-based specification of the technical architecture, describing key architectural concepts and patterns. The technical aspects of implementing this technical specification, such D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 19 of 87

20 as programmatic and RESTful APIs, have been explored during prototype implementation and are sketched in the respective deliverables D-5.4 to D Technical Architecture Components The FInest platform is realized using service-oriented and cloud technology, facilitating interoperability, openness and extensibility through standard interfaces. The general design pattern we followed to build the FInest platform is the three-tier-architecture. Specifically, the following tiers (called layers in the FInest architecture) are defined: Front End Layer: The front end layer of the FInest platform provides users with role specific, secure, ubiquitous access from different devices to information concerning the operation of the transport and logistics network. The capabilities offered by the FInest platform and its core modules will be offered through a customizable web portal (aka. dashboard). Each user can configure this portal by selecting dedicated apps depending on the capabilities needed to perform a user s respective tasks quite similar to the igoogle or iphone/ipad model. In addition, the front-end will be integrated with messaging systems (such as SMS, and Social Networking) such as to notify users and trigger actions. Back End Layer: The back end layer of the FInest platform provides access to, and integration with, legacy systems, third-party services (Internet of Services) and Internet of Things (IoT) devices. Specifically, the IoT devices will provide (near) real-time information concerning the transport processes as well as their context, thus allowing to quickly and proactively responding. Legacy system integration is facilitated by service-oriented technology, e.g., by exposing features of legacy systems as Web services. It should be noted that FInest does not aim to replace existing legacy systems in the domain, but rather to provide value-add capabilities on top of those systems. Modules Layer: The modules layer of the FInest platform allows plugging in targeted transport and logistics service modules. Those modules in the future may be offered by third parties (such as small and medium enterprises). The initial release of the FInest platform will feature four such modules (called Core Modules) for contracting, planning, monitoring and collaboration. Across all those layers, the use of integrated security, privacy and trust (SPT) mechanisms ensures the secure and reliable exchange of confidential and business-critical information. This includes mechanisms such as access and identity management, artifact-based security control, and secure storage & backup. Figure 1 shows the high-level model (expressed in TAM notation, a UML derivate) of the final overall technical architecture of the FInest platform. The model focuses on the core modules, their interfaces and interactions. The design of the front-end and back-end layers is further elaborated in Sections 7.1 and 7.3, respectively. Similarly, due to the cross-cutting nature of SPT, this is not included in the above figure for readability reasons. Details on the SPT architecture of FInest can be found in Section 7.5, as well as in D-3.3. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 20 of 87

21 Figure 1: Final Overall Technical Architecture of the FInest Platform (High-level View) D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 21 of 87

22 4.3. Technical Interface Definitions (Core Modules) This section provides an overview of the technical interfaces provided by the FInest Core Modules. For each interface, we describe its general intent and capabilities. Detailed interface specifications are found in deliverables D-5.4 to D8.4 respectively. Table 1: Technical Interfaces of FInest Platform (Core Modules) Interface Name Summary Provided by EventSourcing Allows connecting event sources (e.g., pub/sub) to the event processing facilities EPM RulesActivation 3 Allows activating pre-defined event patterns for a specific transport instance EPM EventNotification* Allows being notified about identified complex events EPM TransportExecutionData UserEventNotification* Provides information about completed transports, such as to allow for, e.g., managing contracts Provides events about user-relevant transitions in the business process BCM BCM TransportExecutionInformation Allows accessing transport execution data where not already provided by other sources BCM OnlineContractInformation MarketplaceInteractions Allows entering and retrieving contract data during operation Publish logistics service offerings and demands via marketplaces (connected to FInest) ECM ECM ComplianceChecks Provides for various contract-related checks (such as booking against contract / execution against booking) ECM ContractEventNotification* MarketplaceEventNotification* Notifies about user-relevant events / changes of contracts Notifies about user-relevant events / changes in the marketplaces ECM ECM 3 Note that the definition of event types (i.e., EPA rules) is assumed to be done manually. Tool / IT support is planned for Phase II (see the explanation in D6.3). * Note that the interfaces EventNotification, ContractEventNotification and UserEventNotification are intended to be a specialization of a generic interface GenericEventNotification, providing key data and notification mechanisms for events. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 22 of 87

23 MarketplaceBackendIntegration ContractBackendIntegration Access to transport service marketplaces (external to FInest) Access to legacy/existing contract management systems ECM ECM TransportPlanning Plan and re-plan transport execution chains TPM TransportBooking Perform actual booking of service through legacy / existing services TPM 4.4. Interactions between FInest Modules and Components This section describes a typical flow of interactions between the FInest core modules and components of the three platform layers. The interactions between the elements occur along the interfaces as defined in the previous section. Figure 2 show one typical flow of interactions using the UML/TAM sequence diagram notation. In order to react to specific situation the FInest modules have to adapt to the current situations and requirements. Not all presented interactions are necessary for a specific scenario; some are optional and others have to be executed several times until a satisfying result can be achieved. For this reason the sequence diagram uses blocks labeled with opt for optional interactions and loop for looped interactions in the flow. In the following we describe the different interactions in detail and also point out under which circumstances interactions are optional or looped. The sequence diagram encompasses the planning of a new transport, the observation of its execution and the update of contract information based on the used resources for the transport. For this it is necessary that all four FInest modules interact with each other and exchange information. The prerequisite for observing transport execution on the FInest platform is the configuration of appropriate event rules in order to provide the BCM with the necessary information to update its data models. This has to be done before any transport execution can be observed by the user and for that reason the first interaction is between the Frontend and the EPM (configuringinformation) to configure a set of event rules which can be used for specific transport processes afterwards. After that configuration, user can use the TPM to plan new transport processes. The diagram indicates this by the triggerreplanning interaction between Frontend and TPM. Due to the fact that transport re-planning would require exactly the same module interactions as the creation of a new transport, both scenarios are handled together in the diagram. During the planning process, which is conducted in a semi-automated fashion, the TPM constantly communicates with the ECM in order to fetch relevant contract information (requestcontractinfo, requestspotmarketinfo). This enables the TPM to consider existing contracts of the user. If no appropriate contracts can be found the TPM also considers offers from the spot market. After the calculation of potential routes based on the contract and spot market information the user will pick a route and the TPM starts the booking process in interaction with the EPM (checkbookingagainstagreement). Depending on the acceptance of the booking request by the providing party, the TPM can conclude the booking process or has to search for other options. Transport processes usually consist of several legs, whereas those are usually conducted by different service providers. Hence, the searching and booking process has to be performed several times to create a plan for one transport. For that reason the diagram uses a loop block for all the interaction mentioned above. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 23 of 87

24 Frontend TPM BCM EPM IOT/Backend ECM configuringinformation return triggerreplanning User initiated replanning can go directly to TPM. BCM is notified about the updated plan (new TEPs) when the TPM has completed the replanning. (Planning and replanning is handled in the same way). loop1 opt requestcontractinfo(planid, search condition) findcontracts sendcontractinfo(planid, list of TSDs providers) return opt requestspotmarketinfo(planid, search condition) findoffers sendspotmarketinfo(planid, list of TSD offers) return transportplanning return opt checkbookingagainstagreement(planid, Parties data) checkbooking return return booking/cancellation return bookingcompleted bookingcomplete return return transportplanready ForExecution fetchtransportplan transmittransport Plan activaterules ruleinitialization return(event types) createcos instances return return emitevent(raw event) loop2 sendevent (raw event, data) emitevent (raw event) coming from external D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan sources (IOT Page sensors 24 or of 87 detectsituations The CEP engine can receive at any time events backend systems) OR from BCM

25 Figure 2 - Interactions between FInest platform elements D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 25 of 87

26 After the (re-)planning process is finished the TPM notifies the BCM about the existence of a new transport plan (transportreadyforexecution). The BCM, afterwards, fetches this transport plan (fetchtransportplan), activate the necessary event rules in the EPM based on the contained information (activaterules) and initialize the internal CO-based data model in order to prepare handling execution information (createcoinstances). During the execution of a transport process the EPM constantly receives events originating from different backend systems (emitevent). But also the BCM is a source for events, if the user directly manipulates BCM data through the Frontend (sendevent). The EPM analyzes the events based on previously by the BCM defined event rules and detected the corresponding real-world situation behind this (detectsituations). After the detection of such a situation the BCM is notified about it (putditectedsituation), but depending on the situation also the Frontend can receive proactive notifications (putproactivenotifications). The BCM updates its internal CObased data model based on the information about the detected situations (updatecos) and notifies the user about the recent changes (notifyuser). As the regular operational model i.e. when the transport is executed exactly as planned the reception of events by the EPM, the update of the BCM internal data model, and the notification of the user is executed until the whole transport is finished. The diagram illustrates this by a loop box around the interactions described in the previous diagram. However, the occurrence of deviations during the transport execution is not extraordinary. For this reason, the following optblock describes the interactions if such a situation occurs. In case of a serious deviation, the EPM would be the receiver of an event indication this. In the diagram we used the example of a booking cancellation, although the FInest platform is not limited to it. First, the EPM receives the cancelation event from the backend (bookingcanceled) and forwards this information as detected situation to the BCM after analyzing the data (detectedsituation(booking- Cancellation)). The BCM uses this information to send notifications to the affected users and also sends the current execution status of the transport the ECM. The ECM updates the managed contracts based on the already consumed resources and/or executes penalties for a potential contract violation. The following steps may depend on the configuration by the user. One possibility is that the BCM will trigger a re-planning automatically (triggerreplanning) or let the user decide what to do in this current situations. In the first case the BCM has to provide execution details for the TPM (sendexectutionstatus), whereas in the latter the user may do the replanning completely automatically and jump directly back to loop1. If an automated replanning is activated the TPM may do cancellations of other bookings automatically (autocancellation). However, this also depends on user-settings for the module and may vary from scenario to scenario. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 26 of 87

27 5. Core Module Prototypes This section explains the aligned development of the proof-of-concept prototypes for the four Core Modules. We here depict the methodology and the integrated demonstration scenario, while the details of each prototype are provided in the respective deliverables of WP5-WP8 (more precisely the prototype deliverables D5.4, D6.4, D7.4, D8.4) that respectively refer to the demonstration scenario for illustrating the main features. Recalling the overall aim, the FInest Platform (respectively the cspace, as the extended followup concept for Phase 2) is intended to provide a future collaboration and integration platform for the Transport and Logistics industry that allows for seamless and efficient information exchange, communication, and coordination of activities among the involved actors. For this, the four Core Modules that have been designed and implemented in form of in WP5-WP8 provide basic interoperable technical building blocks that can be combined and re-used to provide specific solutions for various scenarios. In order to explain the overall concept as well as the features and usability of each of the core modules, we have developed an integrated demonstration scenario that clearly outlines the business need and benefits of the FInest Platform and the features and interaction of each of the Core Modules. Based on the Fish Use Case (that is FInest Use Case No. 1 from WP2, see e.g. Deliverable D2.2), the scenario describes a typical transport process along with the activities and challenges that arise in real life; we have on purpose chosen a rather small part of an international shipment with a rather simple set-up, which appears to be sufficient for the purpose of showcasing the overall concept and demonstrating the prototypes Coordinated Prototype Development The experiences in explaining to domain experts from the project consortium as well as to external parties how the FInest Platform shall work very clearly revealed that the features of the Core Modules and their interaction as defined above (see Section 4) are not easy to understand for non-it-experts. This seems to result from the fact that the Core Modules are more reusable technical components than end-user applications: for instance, the BCM and EPM enable that the relevant information can be provided to each stakeholder in real-time, whereupon concrete end-user applications for e.g. transport monitoring and deviation management can be developed; similar, the TPM provides generic transport planning facilities that can be used for several purposes, merely the ECM provides concrete functionalities that are directly usable by end-users. With respect to this, for the development of the proof-of-concept prototypes during M19-M24 the technical team decided to align the prototypes at hand of a concrete real-world example in order to provide a showcase for the overall concept of the FInest Platform wherein the features and business benefits of each Core Module can be demonstrated. This has been agreed before commencing with the implementation activities and has been reviewed and discussed in regular conference calls as well as face-2-face meetings; as a positive side-effect, this close and regular alignment has helped the team to properly align the both the technical specifications and the D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 27 of 87

28 implementations in a way such that the prototypes are actually compatible and can interact as defined in the overall technical architecture. To achieve this, the following coordinated activities have been undertaken: Selection of Use Case: the Fish Use Case (= Use Case 1 as defined in WP2) has been chosen, mostly due to the fact that test data were available before and that several of the FInest partners are actually involved (namely: NCL, Port of Aalesund, and Tyrholm & Farstad); however, any of the other FInest use cases could have also been used Definition of concrete Scenario: the concrete scenario was defined (with several iterations), including the overall story line, the specific steps and activities undertaken by the involved actors, and the detailed information and events that are relevant (see the detailed explanation below in Section 5.2) Specification of Test Data: the concrete test data were defined based on real-world information provided by the use case partners, specified in the respective technical formats expected by the core module prototype implementations, using real-world information from the use case; this includes particularly: o Collaboration Objects as processed by the BCM (see D5.5 for details), o Event rules and specific events for the EPM (see D6.5 and D6.4), o Transport Plans in form of TEPs and TCPs as used by the TPM (D7.5, D7.4) o Exemplary Offers, i.e. transport service descriptions, that are provided by the ECM (see D8.5 and D8.4) o Definition of Test Users for running the integrated demonstration Implementation of Core Module Prototypes: development of the main functionalities of each Core Module, using Generic Enablers provided by FIWARE where appropriate, along with GUIs that allow showcasing selected features in correspondence to the integrated demonstration story line (see the final of deliverables WP5-WP8 for details) Implementation of User Management and Access Control: an initial proof-ofconcept implementation for User Management & Access Control using FIWARE Security GEs (this has been done in addition to DoW obligations) Deployment on Cloud Infrastructure: the prototypes and test data along with a demonstration script (= ordered technical invocation of prototypes) has been deployed on a cloud-infrastructure hosted and operated by KocSistem (also in addition to the DoW obligations), allowing for the online demonstration of the integrated prototypes 4. In addition to the technical set-up and realization, the prototypes and integrated demonstration story has been continuously reviewed by the domain experts. For this, extensive feedback sessions have been held during f2f meetings in (September 2012, January and February 2013), as well as in several conference calls. The gathered feedback has allowed the technical team to realize the prototypes such that they properly address the user requirements, and, on the other hand, enabled the domain experts to gain a better understanding of the technical solution designed in the project. 4 Central access page to prototypes: Note: due to the technical provisioning by FIWARE, you need to add the following entry to your system s hosts file: idm.nsn.com under Windows allocated at %SystemRoot%\system32\drivers\etc\hosts D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 28 of 87

29 5.2. Integrating Demonstration Scenario The following explains the integrating demonstration scenario in detail. As outlined above, its purpose is to illustrate the capabilities of the overall concept and in particular of the 4 Core Modules to support more efficient, reliable, and collaborative transport and logistics processes based on Future Internet technology. The demo showcases the business value of FInest in one of the project scenarios: the Fish Export from Norway to Brazil, via Rotterdam Port. This associated with the real business between these countries. The cod fish (called in Brazil Bacalhao) is one main product exported from Norway to Brazil, being the latter the 5 th largest market for Norwegian cod (c.a tons a year). The main goal of this demo is to demonstrate two main business value added of FInest platform during the exception handling in transport and logistics process. Seamless information integration Through the Finest support for seamless information integration, the stakeholders are simultaneously notified and requested to act upon. This support demonstrates that Finest platform is able to provide the end-to-end visibility in inter-organizational collaborative logistics process. Early Notification and Reaction Time In the Fish Export demo, Finest enables parallel streams of exception handling by different stakeholders. Through FInest platform, the forwarder is able to replan the execution of the Fish export and restart the execution of the suspended process in a semi-automated and transparent manner. In parallel, the carrier is able to use the capabilities of FInest platform to find potential new clients to cover the last minute cancelation of reserved capacity. Finally, the port terminal can internally reallocate the resources based on the early notification of changes in the amount of goods to be loaded in the vessels. The FInest capabilities showcased in this demo enable an overall optimization of resource utilization in global transport and logistics processes Overall Information about Demonstration Scenario The main stakeholders in this scenario are: fish exporters from Norway (West Norway Fish Export), T&F as forwarder, Port of Alesund, and NCL as carrier until Rotterdam. In the Fish Export scenario, many different types of exceptions can happen. For this particular demo story, we focus only on the effects and actions that can be conducted when the import licenses is missing. The lack of such license, in this particularly demo story, impacts the stakeholders, causing the suspension of the ongoing process and the need for replanning of the transportation in the forwarder side, cancelation of the booked capacity in the carrier, and the replanning of terminal resources in the port side. The visual illustration of this scenario is depicted in Figure 3. The upper part of this figure shows the stages of the business process associated with this scenario and the point in time in which the exception happens. We consider in this scenario a process with five stages: start execution, truck pick up, warehousing, loading, and feedering. We consider that this process is D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 29 of 87

30 working accordingly, i.e., all expected events are happening as expected, until the moment that a missing important license is detected 24 hours before loading the vessel with the Fish that has to be exported to Brazil. Without such an import license, it is not possible to load the vessel; this forces the forwarder to replan the transportation of this specific good to take place one day later, assuming that the import license will be available by then (i.e. in the next 24 hours). Figure 3 Overall scope of the Story Demo The main part of this figure describes the stakeholders, effects and FInest support to handle such exception in the perspective of each stakeholder. In the shipper perspective, there will be a delay on the shipment and this partner will be aware in real time about the lack of the import license and will have to handle this situation. The forward will also be aware in real time about the exception, will cancel the loading of goods in the reserved vessel, and will try to find another carrier to take these goods in one day later. The carrier will be notified about the cancelation of reserved capacity and will be able to proactively find clients that could cover this empty capacity. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 30 of 87

31 Walk-through on Demonstration Scenario One of the main characteristics of FInest platform is its ability of supporting seamless information among the stakeholders in during the execution of a transport and logistics service execution. This means that at the same time, multiple users will be logged in on the FInest platform, everyone with his / her personalized view of the system and the access to allowed information and functionalities. In addition, many parallel actions and interactions among the FInest core modules are happening underneath the screen observed by each user. In this demo story, we focus on demonstrating how these interactions happen and in a simplified way, and show how the underneath actions are reflected for each stakeholder logged into FInest platform. The simplified and comprehensive illustration of the demo story is graphically based on the same elements depicted in Figure 4. The upper part of the figure depicts the stage of the business process associated with the scenario. The lower part shows that FInest platform and its core modules. The middle of the figure indicates which information is available to each of the participating stakeholders; note that this is a simplified representation of the actual content provided to the end-user within the individual core module prototypes. Figure 4 Basic graphic elements for describing the demonstration story D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 31 of 87

32 It is important to remark that this illustration does not reflect the actual implementation of the FInest platform and the core modules. Rather, it shows which kind of information each loggedin user would perceived during the exception handling process supported by FInest platform and modules. In addition, in this section we do not show all the stages and actions that can be conducted by FInest in order to support the exception handling of this scenario. Instead, we illustrate two streams of actions of this demo story. The first describe the actions to repair the plan for the transportation process that is on hold because of the lack of import license. The second is associated with the side effect actions that a replan causes to the carrier in this scenario Main Stream of Actions: Replanning the T&L Process This section explains the main steps of the story line. For this, we show the relevant execution steps in the visualization explained above, along with a detailed explanation of the status and the individual stakeholders actions for handling the transportation plan for the export of fish from Norway to Brazil that was stopped due to an exception, i.e. the lack of the import license. As previously defined, the exception forces the forwarder in this scenario to replan the transportation by postponing in one day the loading process of the goods into the vessel. The screenshots in Table 2 illustrate the main situations undertaken by FInest platform, the shipper and forwarder in order to enable the process to proceed. Table 2: Screenshots of demonstration story for the actions associated with the shipper and forwarder issues Screenshot Description of Situation A) Detection of the missing import license. As soon as the process starts (as illustrated in Figure 4) the BCM and EPM modules start to interact based on events coming from IoT and/or backend systems of the users associated with the process. In this screenshot, we present the moment that the ECM identifies the lack of an event confirming the existence of the import license for this process. The ECM notifies the BCM that notifies simultaneously the shipper and forwarder because they are the users that should take actions at this stage. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 32 of 87

33 Screenshot Description of Situation B) Replan Requested After being notified, the shipper starts its own actions to get the import license, the forwarder decides to replan this process. In our scenario, the forwarder starts the process of replanning using for this the TPM module. The first action of the TPM module is to cancel the current bookending for the NCL vessel, because without the import license the fish cannot be loaded onto the vessel. See Section for the stream of actions to handle this cancelation problem. C) Identification of new carriers. In the next step, the TPM module interact with the ECM module in order to find alternative carries with available capacity to transport the fish one day later. After the interaction, the TPM process the list of potential carriers (either the ones with long term contract or the ones found in the marketplaces), presents the new possible plans for this process, and request the user to decide which new plan will be used. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 33 of 87

34 Screenshot Description of Situation D) New Plan is accepted When the forwarder user accepts the new plan, the BCM and TPM modules interact in order to reconfigure the stages of the process and update who are the new parties involved in this plan. Latter, the BCM interacts with the EPM and automatically updates the information of the rules that are used for identifying events associated with the new plan. E) Conformation of the Import License In parallel, the shipper was trying to get the import license for the fishes to be transported. Once the shipper has this document available in its internal systems, the EPM is notified about the availability of such document, and thus notifies the BCM. The replanned process can then proceed to be executed. In our scenario, no other exception happens and the process is finalized Parallel Stream of Action: Handling Late Booking Cancelation This section describes the screenshots of the demonstration story associated with a parallel stream of actions. This stream is not executed to solve the exception generated by the lack of the import license, but it is a stream of action generated because of the action to handle the exception. During a replanning of a transportation service, changes in the plan will affect some of the partners of the collaborative process. In our scenario, the exception handling causes a booking cancelation which affects the carrier business. FInest platform is able to support actions that can in parallel to the import license handling, also address the booking cancelation problem in the perspective of the carrier. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 34 of 87

35 Table 3: Screenshots of demonstration story for the actions associated with the carrier issues Screenshot Description of Situation A) Replanning process cause booking cancelation of capacity for the Carrier The side effect of a replanning process in this scenario is the cancelation of capacity in vessel. The EPM module is notified by the backend systems from the carriers, and through the interactions with the BCM, the cancelation information is then indicate to the carrier user logged into FInest platform. B) Looking for demands to avoid empty cargo Once the carrier is aware of this booking cancelation, this user can use the ECM module in order to automatically find eventual shippers that could fulfil this empty space and interact with them in order to solve the last minute booking cancelation. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 35 of 87

36 PART (C): PHASE 2 IMPLEMENTATION PLAN This part presents the final results of the Phase 2 Preparation Work Stream wherein the FInest project team has planned and prepared for the continuation and extension of the project goals and results in Phase 2 as well as in Phase 3 of the FI PPP program. The main achievement has been the successful preparation of the cspace project. As outlined above, this is a FI PPP Phase 2 use case project that aims at developing and validating a Future Internet enabled collaboration platform for business networks in Agri-Food, Transport and Logistics. It presents the result of merging the Phase 1 use case projects FInest and SmartAgriFood, extending the concepts and leverage on the complementary results from Phase 1. Furthermore, it provides a detailed implementation and delivery plan wherein nearly all FInest results will be taken up, and hence can be considered as the detailed plan for implementation, experimentation, and preparation for large scale update that is planned for Phase 2 of the FI PPP. In addition, the FInest project has utilized the M19-M24 milestone for preparatory work on various technical building blocks that have been identified in the course of the requirements-driven solution design and business validation work throughout the project. In conjunction with the results of the other work packages namely the business models and applicability study from WP1, the experimentation plans from WP2 along with the experimentation environment designed in WP4, and the user-validated technical specifications and prototypes for the FInest Core Modules developed in WP5-WP8 this shall provide a profound basis to allow for a flying start into the cspace project. The following sections present the Phase 2 preparation work in detail. At first, Section 6 introduces the overall concept of the cspace, depicting how it builds up and extends the concepts and results of the FInest project. Then, Section 7 presents the preparatory works on the main technical building blocks of the cspace project. This includes Proof-of-Concept implementations that test and validate various Generic Enablers available on the FIWARE test-bed, namely for User Management & Access Control (Section 7.5) and for the Section System & Data Integration layer (Section 7.3) Refined conceptual design for technical components that have already been considered in previous WP3 deliverables, namely for the cspace Front-End (Section 7.1) and for the Security-Privacy-Trust framework (Section 7.5), and The conceptual design and initial assessment of Generic Enablers for components that have not been investigated before, namely for the cspace Store (Section 7.2) and for the cspace Middleware & Operation Environment (Section 7.4) Finally, Section 8 outlines work plan of the cspace project including the detailed work breakdown structure and time plan, along with a detailed mapping of the FInest results to the cspace project. This can be considered as the detailed phase 2 implementation plan, depicting where and how the results of the FInest project are planned to be continued in Phase 2 and when releases of the implementations can be expected. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 36 of 87

37 6. The cspace This section introduces the overall cspace concept, which shall be implemented, validated in use case trials from areas of Agri-Food, Transport, and Logistics, and prepared for large scale extension and industrial uptake in the course of the cspace project. We explain the overall concept with respect to the main features, the operational model, and the expected business relevance, and depict how this takes up and extends the concepts developed in FInest Overall Concept The cspace is a value added Collaboration Space designed as a Cloud based service enabling actors operating in Collaborative Business Networks (e.g. businesses, authorities, public & private service providers) in various application domains to find out about one another, determine what services others can provide, and to collaborate on developing and executing solutions to business needs that they might have in a seamless and easy manner. In order to allow for rapid development of high-quality ICT solutions at minimal costs, the cspace enables collaborators to select, assemble (mash up), and execute functional applications from its Cloud based application store (the cspace App Store). General business as well as domain-specific functionalities (referred to as Apps, as the envisioned usage and economic model is similar to mobile apps for smartphones) are developed and placed in the cspace App Store, through which the Apps can be employed by collaborators to effect business services through the use of the cspace. New Apps can be developed by re-using features of existing Apps or through the development of completely new Apps using the cspace App Development Environment. Apps are selected based on a number of criteria including their functionality, pricing model, past reliability, focus, etc. The Apps can be mashed up (connected together in an integrated manner) in a rapid and low cost fashion using the mechanisms and tools provided by the cspace, in a rapid manner at minimal costs. These mashed up solutions, composed of perhaps multiple Apps, are targeted to address unique business problems, not general problems, and can be discarded once the problem or business opportunity has been successfully addressed. The cspace facilitates such rapid construction and destruction to ensure that businesses can address issues or opportunities in real time without having to address the overhead and cost that has plagued the development of traditional monolithic applications. Figure 5 below depicts the overall vision for the cspace service. The cspace is a value added Collaboration Space deployed in the Cloud that enables actors operating in Collaborative Business Networks (e.g., enterprises of all sizes, authorities, public and private service providers) in various application domains to seamlessly interact, communicate, and coordinate activities with business partners and to easily create and act in open and dynamic networks of connected businesses similar to modern Web 2.0 solutions that exist in the B2C world (e.g., Facebook, LinkedIn, Xing, etc.). In addition, the cspace instantiates a unique business model for enabling the rapid development of high-quality B2B ICT solutions at minimal costs by enabling the provisioning, consumption, and re-use of on-demand solutions in the Cloud. General business, as well as domain-specific, functionalities are developed by IT solution providers (beneficiaries and external providers). These Apps are provided via the cspace App Store, from which the Apps can be consumed and for which new Apps can be developed D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 37 of 87

38 through the use of the cspace App Development SDK. App mash up services provided by the cspace platform allow business collaborators to rapidly create near real time customized solutions that can be executed and managed through the cspace creating a low cost mechanism for organizations of all sizes to conduct value added business with one another. BUSINESS BENEFITS Industries (actors in collaborative business networks ) Seamless B2B Collaboration (information exchange, communication, coordination of activities) Rapid & easy development of customized solutions at minimal costs Quick formation & evolution of open business networks ICT Industry (Software & Service Providers) Paving the way to the cloud, pioneering on both future technology and business models Enable new market & distribution channels Facilitate novel business opportunities, esp. for market entry & participation for SMEs Figure 5: cspace Overall Vision (multi-domain Collaboration Space for Business Networks) The idea behind the cspace is to truly move forward in conceiving of a new paradigm in computing that is based on emerging Future Internet technologies and leverages the full potential of the cloud-based services concept [2]. The cspace pushes boundaries on how business software will work in the future, facilitating innovation and market impact by laying the foundation for adoption by large user groups and external solution providers that can provide additional, novel, and disruptive Apps for the cspace. In the context of the FI PPP, the cspace complements the mission of the FI PPP Core Platform Objective in addressing the D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 38 of 87

39 overall aim of the FI PPP: while FI-WARE aims to provide a framework for development of smart applications in the Future Internet [3], the cspace will exploit its technologies for enabling substantial increases in the efficiency and effectiveness of cross-organizational business processes and pioneer novel business models that allow for innovation by external stakeholders with high prospects for industrial uptake and market impact. An important point to note is that the innovative aspect of the cspace model is the model itself (covering both the technical solution and the proposed business model) it is not any specific technology innovation such as, e.g., new algorithms, software engineering concepts or the like Main Features and Building Blocks As outlined above, the cspace will be a Future Internet enabled SaaS application for encouraging seamless, efficient, and effective business collaboration across organizational boundaries and facilitating the establishment of ecosystems with business benefits for both users from industrial sectors as well as the ICT industry. The cspace can most suitably be realized on the basis of the Future Internet technologies that are developed in the FI PPP, and will utilize the available Generic Enablers wherever appropriate. In addition, desirable domain-specific capabilities are being developed to demonstrate the value and capabilities of the cspace technology and business model (i.e., for inter-organizational process coordination, operational monitoring and tracking, event-driven re-planning, ecosystem application development, monetization, security and privacy management in business networks, etc.). In order to realize the envisioned features i.e., (a) the future support for collaboration in business networks, and (b) a future business model for rapid development of high-quality ICT solutions at minimal costs the cspace consists of the following primary building blocks: (1) The Front-End that serves as the main point of access for End-Users and offers a novel all you need in 1 place user experience, including the following features: - Customizable End-User Cockpits - Social Networking and Collaboration Features for Business Partners and Communities, and support for seamless collaboration on specific business activities and transactions - Access anywhere via any device (2) The cspace Store that encompasses an extensible collection of Apps that can be used and combined for the individual needs of End-Users and re-used for the rapid and easy development of new Apps, including - The software infrastructure to support the provisioning, consumptions, purchase, and re-use of cspace Apps for both End-Users and App Developers - Financial management of the cspace (pricing, payment, revenue sharing) (3) The Business Collaboration Core Modules ensuring that all information and status updates are provided to each involved stakeholder in real-time, consisting of - A Collaboration Engine that captures, in form of so-called Collaboration Objects, the information that needs to be exchanged among collaborating stakeholders along with the status information of the collaborative business activity, constituting a global knowledge base for collaborative business processes, and D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 39 of 87

40 - An Event Manager that captures and pre-processes both manual (from humans) and automated (from connected systems) events, which trigger the progress and activities of collaborative business processes in a pro-active event-driven manner. (4) A System and Data Integration Layer to allow for the integration and continued usage of existing legacy and business systems and the integration of external systems and services, including support for: - Connecting business and legacy systems used by individual users - Handling heterogeneous data - Connecting external Systems and Services (e.g., IoT systems, 3 rd party and public services) (5) A comprehensive framework for Security, Privacy, and Trust Management to ensure the secure, reliable, and trustworthy handling of business data making the cspace secure by design, including: - Access Control and Identity Management for all users - A set of Security Mechanisms to ensure information security, attack prevention, etc. - Developer support to ensure correct usage of necessary security mechanisms in cspace (6) An Operating Environment that ensures the technical interoperability of cspace Components and Apps and the consistent behaviour of the cspace, including: - Technical Interfaces and Protocols for the cspace Components and Apps - An Enterprise Service Bus to support the interaction of cspace Components and Apps - Replication and Consistency Services to ensure fault-tolerance and transaction support (7) A Development Toolkit providing tool-supported techniques for the cspace, particularly for: - App Developers to support the development and provisioning of Apps in accordance to the technical governance and procedures of the cspace - Business IT Experts who customize and extend the cspace to the individual needs of End-Users at an individual or organizational level Summarizing, the main features of the cspace are: An open application that can be extended and customized for specific stakeholder requirements through the use of Apps that can be mashed up (integrated) using services of the cspace (an extension of the app concepts of mobile telephone providers such as Apple, Google and Microsoft); An integrated Front-End as a central point of access to all features and Apps, enabling an all you need in 1 place user experience with customizable views for individual actors; Integrated novel technologies that provide the basis for future collaboration in business networks, enabling all information to each stakeholder in real-time as well as the seamless interaction and coordination among business partners; Information integration from legacy and third party systems enabled through a service-based integration layer that is enabled and supported by FI-WARE Generic Enablers; Modern technologies that ensure the secure, reliable, and trustworthy handling of business information in the Cloud, and the consistent operation of the cspace; An (App) Store that facilitates the provisioning, consumption, and marketing of novel ondemand solutions for B2B collaboration, along with an integrated toolkit for developers. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 40 of 87

41 Stakeholders and Usage Model In order to illustrate how the cspace shall work, the following workflow description outlines the usage procedures for the three primary user groups that work with the cspace service. 1. End-Users: the business experts using the cspace to conduct the daily business activities, with special focus on their interaction and collaboration with business partners; 2. Business Process Engineers: the ICT experts (internal or external) that support End- Users in the configuration of the cspace for their individual business needs, particularly for the definition of customized business processes by using the cspace Apps and the cspace s customization support services (on various levels: company / organizational unit / individual); 3. App Developers: the software and system providers who offer solutions and applications in form of Apps via the cspace. Table 4: Workflow End-User Step Activity Used cspace Components 1 Registration & User Profile Maintenance Register & Log-In to cspace Create & Maintain User Profile (individual / organizational unit / company level): o Select / define role o Provide basic profile information Personalize Cockpit (appearance, basic notification & communication settings) 2 Find & Manage Business Partners Find business partners (known & unknown) o Via public user profiles o Via offered business services Manage your business contacts o Maintain contact data o Seamless communication via social networking & collab. features Manage business partners o Set-up & manage contracts o Rate partners (public + private) Create Business Communities (for e.g. areas of interest, establishing networks, ) 3 Get & customize Apps for Business Activities Find & get need Apps o Available in cspace Store o Pre-configured by Business Process Engineers Customize for individual needs (only personal configuration, basic configuration / extensions Front-End Registration & Log-in Process User Profile Management Personalization Features Security (indirect, integrated in Front-End) Secure Log-In & Usage Access management Front-End Search for public user profiles Basic Contact Management Basic networking & collab. features Formation of communities Apps (purchased via Store, access via Front- End), e.g. for Advanced business partner mgt Adv. business partner search Adv. networking & collab. features Partner Rating & management Security (indirect) Information Security Access management Front-End Personalization & Configuration for Apps (selection, personal appearance, look & feel) Access Apps (consume Apps via UIs that are provided in Front-End) D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 41 of 87

42 / combination by IT experts / Business Process Engineers) 4 Execute Daily Business Activities Use Apps & cspace Features for conducting daily business, incl.: Define specific notification & comm. settings for business activities Use collaboration features for specific business activities and transactions Continuously manage business partners App Store Find & investigate available Apps Purchase Apps Use pre-configured Apps / cust. solution provided by associated IT Experts / BP Engineers Front-End Access to Apps (UIs integrated in Front-End) Personalization & Config. Features Embedded social networking & collaboration features (basic + advanced) Access to statistics on App Usage, Business Partner Information, etc. Table 5: Workflow Business Process Engineer Step Activity Used cspace Components 1 Find & get relevant Apps Search / browse cspace Store Investigate for suitability o Features & functionality o Interfaces, Data Structures o Options for configuration, extension, re-sue o Pricing & payment models Purchase relevant Apps (for company / org. unit / individuals) 2 Create customized Solution Design desired Workflow for End-Users o Sequence / Process of Apps o Data models and relevant systems o Interaction & collaboration with business partners Configure / extend / define data structures and technical workflow over Apps o Configure / extend Collaboration Artifacts + Event Rules (or define new / additional ones) o Configure / extend selected apps (hide / rename data fields, resp. add additional functionality) o Orchestrate Apps into desired workflow: define / mash-up execution sequence & technical interaction models Connect relevant systems ( legacy systems and external systems & services) and integrate them into the customized workflow o Define & create connectors to between cspace Apps and systems o Define data mediators to integrate data systems <-> cspace App Store App Search & Discovery facilities Investigation Support for Consumers (features + pricing models) and for Developers (technical details) App Purchase Support Ratings of Apps by cspace Community Development Toolkit (encompasses various developer tools) Configuration / Extension for Collaboration Artifacts & Event Handling Rules Customization of Apps (configuration, extension) Mash-Up & Orchestration of Apps System & Data Integration Tool-supported techniques for connecting business systems (legacy & standard systems,...) Tool-supported techniques for connecting external systems & services (e.g. IoT-enabled sensor system, 3 rd -party services) Data mediation & integration facilities D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 42 of 87

43 3 Provide customized solution to End-Users Provision to relevant End-users by making the customized solution accessible in the personal Front-End of relevant End-Users Pre-configure for End-Users: Access Rights, setting for notifications + communication Configure pricing & payment models (for company / org. unit / individual level) [optional] publish re-usable parts of customized solution in cspace Store Front-End Personalization & Configuration for individual End-Users Configuration (Access Rights, Notification & Comm. Settings) App Store Configuration of payment models Publication of Apps Table 6: Workflow App Developer Step Activity Used cspace Components 1 Find existing Apps to build upon Search / bowser cspace Store Investigate for suitability & re-usability o Features & functionality o Interfaces, Data Structures o Options for configuration, extension, re-sue o Pricing models, terms & conditions for re-use Buy Apps for re-use ( development license ) App Store App Search & Discovery facilities Support for Detailed Investigation (features, functionality, technical details, pricing models, terms & condition for re-use App Purchase Support for re-use Ratings of Apps by cspace Community 2 Develop App Using cspace Development Toolkit to develop app to comply with the cspace technical governance incl. in particular: o UI Framework & Technology o Technical Interfaces & Interaction Protocols o Usage of security, privacy, and trust technologies Configure / extend / define data structures and define interaction with re-used Apps o o Configure / extend Collaboration Artifacts + Event Rules (or define new / additional ones) Configure / extend selected apps (hide / rename data fields, resp. add additional functionality) o Define technical interaction with reused Apps ( orchestrate or mashup ) Prepare for re-use and for integration with legacy & external systems o Define interfaces and hooks for connecting systems o Define supported / expected data structures 3 Publish App on cspace App Store Development Toolkit (incl. developer guidelines, suggested development tools) Compliance with cspace technical governance (UI technology, technical interfaces & interaction protocols, security techniques) Configuration / Extension for Collaboration Artifacts & Event Handling Rules Customization of Apps (configuration, extension) Mash-Up & Orchestration of Apps Publication Process for Apps D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 43 of 87

44 Publish new App in cspace Store, incl. Creation of App Description Configure / define pricing models, usage terms & conditions Conduct cspace App Publication Process Configuration / definition of pricing models, usage terms & conditions Technical Governance Check 6.2. Relationship to FInest Results The cspace builds on concepts that have been designed and pre-validated in Phase 1 use case projects, particularly the Collaboration and Integration Platform for Transport and Logistics from the FInest project [4]. The cspace extends this work incorporating a more complete collaboration space model, the addition of the cspace App Store, App mash-up services, App development services, a multi-domain business collaboration capability, and the software infrastructure to support these additional services. From a pragmatic view, all findings of the development of the FInest platform have informed the Phase 2 project called cspace. The FInest platform modules, architecture and business model are foundational components of the evolved cspace platform. Security concepts developed in the Phase 1 effort have informed the proposed security framework for Phase 2 as have integration and interaction designs between the module-based services. While all of the FInest design elements are incorporated in the cspace platform, not all of them have been incorporated in the same manner. The business collaboration and the pro-active event management modules are envisioned in cspace as parts of the core platform. The econtracting and planning modules are conceived of as general purpose Apps that will reside in the App Store and be utilized as needed by cspace collaboration partners. The separation of these modules follows the logic of the cspace, which extends the architectural concepts developed in the FInest project to a multi-domain, cloud based B2B collaboration service. More information on the specific architectural mappings of the cspace can be found in the cspace proposal and DoW as well as in Section 8.4 of this document. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 44 of 87

45 7. Conceptual Design & GE Validation This section presents the results of the preparatory works on the main technical building blocks of the cspace that have been elaborated during M19-M24 of the FInest project. As outlined above, it includes both (a) proof-of-concept implementations that use Generic Enablers that are available on the FIWARE test-bed, and (b) the conceptual technical design of main technical buildings that have been continued from previous deliverables as well as for components that have not been investigated in detail before. It is important to note that these works have been conducted in addition to the tasks defined in the DoW, utilizing the available resources for demands and aspects that have been identified during the course of the project. Figure 6: cspace High-Level Conceptual Architecture Figure 6 shows the high-level conceptual architecture of the cspace, indicating its main technical building blocks as introduced above in Section and their respective main features. This can be considered as a revision of the overall conceptual architecture presented in D3.2 (see [1], [5]), extended with additional features and new components that are needed for realizing the overall vision of the of cspace (namely the cspace Store and the Operating Environment). Following the structure of the high-level conceptual architecture, the subsequent sections present the achievements towards the technical realization D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 45 of 87

46 A revised conceptual design of the Front-End (Section 7.1), An initial conceptual design of the cspace Store along with an assessment of the relevant Generic Enablers for technical realization (Section 7.2), A proof-of-concept implementation for System & Data Integration (Section 7.3), A initial conceptual design and identification of suitable Generic Enablers for the Operating Environment (Section 7.4), and A proof-of-concept implementation of the for the User Management and Access Control validating the IDM Generic Enabler, along with a refined conceptual design for the Security-Privacy-Trust framework (Section 7.5). Please note that the so-called B2B Collaboration Core Modules as shown in Figure 6 denote the continuation of technical design and prototypical implementations of the FInest Core Modules Business Collaboration Module (BCM, cf. WP5) that captures and manages the information that needs to be exchanged among collaborating stakeholders along with the status information of the collaborative business activity in form of Collaboration Objects, and the Event Processing Module (EPM, cf. WP6) that captures and pre-processes various types of events which trigger the progress of collaborative business processes in a pro-active eventdriven manner. As closely aligned and domain-independent implementations, these two components shall allow for all information and status updates are provided to each involved stakeholder in a collaborative business network in real-time, therewith providing central key functionalities for the enhanced business collaboration support envisioned by the cspace. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 46 of 87

47 7.1. Front-End The Front-End is the central access point via which End-Users can access the collaboration features as well as the apps provided within the cspace. A detailed technical specification for such a web-based Front-End with multi-device and channel access support has already been provided with in Deliverable D3.3 (cf. Section 4.1 in [1]), including an assessment of potential technologies for realization, a technical architecture, and the early validation of the WireCloud GE provided by FIWARE. For the realization of the FInest prototypes, it has been decided to not implement a common Front-End technology but utilize the available resources for showcasing the main features of the overall concept and the FInest core modules as described above in Section 5. Nevertheless, the technical specification and technology assessments shall serve as a basis of the detailed implementation plan for the cspace project Conceptual Design for cspace The cspace Front-End shall be the web-based portal that provides the central point of access via which End-Users access and work on the cspace. It shall define a corporate design of the cspace, allow multi-device and channel access, encompass the standard features of the cspace (i.e.: user profile management, business partner & community management, social networking features for business communities), and provide access to the UIs of the cspace Apps. Figure 7 below illustrates the overall concept of the cspace Front-End. It consists of two general parts: a part with standard features of the Front-End independent from a specific domain and a dynamic part where the UIs of pre-defined or user-selected cspace Apps are integrated. Another important feature builds on top of this: the cspace allows an easy configuration and personalization of its Front-End UI by the end-user. This means that positions of the App UIs are not fixed and can either be arranged in the way the user needs them or hided if he/she has no use for it, and all the overall appearance can be configured individually. In order to technically enables this, the cspace Front-End provides a set of pre-defined UI elements for the App developers in order to make it easy to meet the platform design. Additionally, the users or companies can modify the overall design for the platform in order to address their own corporate identity. Finally, the cspace Front-End shall provide advanced collaboration features for business communities, bringing in concepts of social networks to the business world. Endusers are allowed to define preferred partners to have easy access to their information. Advances communication features, such as the integration of telecommunication services, instance messaging features or the sending for pre-structured s, facilitate the communication between stakeholders. The tight integration in the Front-End UI allows the user to start the communication immediately and directly refer to a specific step of the business process (for example: a user detects and issue with a transport order; the cspace Front-End provides a button to start a conversation directly about this transport order with the responsible business partner). D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 47 of 87

48 FP ICT-FI FInest Figure 7: cspace Front-End (initial concept) Summarizing, the main features of the Front-End technology that shall be developed in the cspace project can be divided into 2 main building blocks: (A) The Base Front-End providing the central point of access for End-Users including: General part of the UI (domain independent): o Basic UI design ( corporate design ) o Navigation structure and menu (header/footer) items o Access to user profile management o Access to Business Partner & Community Management facilities o Access to the cspace Store o Provisioning of an API to access features of the Front-End by cspace Apps o Support for company profiles (define profiles on the cspace and to act end-users of the platform as employees of this company o Provisioning of an API to access features of the Front-End by cspace Apps Main Pane for UIs of cspace Apps: o User selects and arranges the UIs of the cspace Apps freely in accordance to his/her needs o Hence, the workspace (main pane) is configurable to user needs o cspace Front-End provisions set of specific UI elements for App developers to achieve a common look & feel D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 48 of 87

49 Personalization Features: o Adapt of arrangements parts = enable the user to define the position of UI parts o Notification Settings = enable the user to define about which events or messages he/she want to be informed over which way and channel o Personalized corporate design of the cspace Front-End = enable companies or users to adapt the corporate design o Enable/Disable of cspace features = users and companies shall be able to disable specific features of the cspace (e.g., certain UI part or access to the App Store) (B) Integrated facilities for enabling Social Networking & Collaboration in Business Networks, including innovative features for e.g. Human-to-Human Communication = integrated telco services for phone / / fax / sms / from UI; chatting & instant messaging facilities Business Partner & Community Networking = advanced features to find & manage business partners, organize communities, easy communication and news distribution Collaboration Features for business process and activities = allow the easy communication about specific business process steps Incentives = add rewards for actions within the cspace portal to motivate and encourage end-users Reputation & Recommendation = store reputation data for business partners and provide a recommendation facility to easily find new partners Company profiles = enables companies to define profiles on the cspace and to act endusers of the platform as employees of this company (e.g. company defines special widget arrangement or companies provides special widgets for their employees) For realizing this, a comprehensive Technology Framework is required that needs to support Web-enabled with support for multi-device access & multi-channel technical communication (HTML5) Technical framework for UI-elements, allowing for easy personalization by modularization, etc. Technical Infrastructure for Main Pane, incl.: o Support for technical approach to enable configuration, customization, combination o Personalization for integrated & high-quality End-User Experience Technical Interfaces for connection to Services & Apps implementations & middleware (RESTful) While the technology assessment provided in [1] can serve as basis, the Generic Enablers from FIWARE provide merely functionalities for parts of the planned features as outlined above. Potential candidates that need to be further inspected for usability and technical integration are: Cloud Edge GE (Apps & Services Chapter) WireCloud: CompositionExecution & -Editor GEs (Apps & Services Chapter) Identity Management GE (Security Chapter) Data Handling GE (Security Chapter). D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 49 of 87

50 Comparison to existing Solutions Established web-portals for Business-to-Consumer (B2C) use cases provide features similar to ones motioned above for the B2B setting. Amazon or Ebay for example, allow access to web shops of very different suppliers through their own portal. Large players in the social networks domain, with Facebook leading the way, have discovered the need for their customers to individualize the appearance of the user Front-end and they allow users to integrate special apps from third party providers. Users are allowed to design the Front-end in accordance to their needs, and social network providers may offer sophisticated frameworks to easily develop custom solutions [6]. However, these existing B2C solutions cannot satisfy the requirements of the B2B setting. In addition to more fundamental security and privacy concerns (see Section 7.5), business users require more flexible configuration and use of Front-Ends due to different business processes and dynamic changes in working tasks. First generation B2B solutions do not address this issue. Solutions from Ariba, for example, mainly focus on the establishment of a business relationship [7]. Ariba customers can search for potential suppliers or retailers and establish contracts in a relatively easy manner. However, the execution of a collaborative business process is out of the scope of Ariba s solutions, and consequently Ariba does not provide suitable solutions for a Front-End integration service such as that being developed under the cspace project. Another example is B-Zone [8], a pre-product developed by SAP. B-Zone also allows the discovery of suitable business partners (in a fashion that is analogous to the adding of Facebook friends); however, it does not provide services for process visualization. Thus, cspace s contribution to the state-of-the-art is the development of Front-End and customization concepts that allow for observing and controlling business process during their execution, such that an all you need in 1 place user experience can be achieved. This requires the development of customization, mash-up and visualization concepts that go beyond those currently found in existing solutions. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 50 of 87

51 7.2. cspace Store This section provides an overview about the cspace Store that shall support the provisioning, consumption, and purchase of cspace Apps. As outlined in Section 6, the notion of Apps in cspace covers baseline apps and pilot apps that are developed directly within the cspace project as well as additional Apps that shall be developed by external 3 rd party providers. It has been decided to refer to all of these as Apps, as in the end the usage experience as well as the economic models shall be similar to today s app stores for Smartphones. The following subsections cover: firstly, the initial high-level architecture as basis for the implementation of the cspace Store; secondly, an initial analysis of the relevant Generic Enablers and what needs to be implemented in addition to them; and finally, a brief analysis of the existing solutions on the market and describe why a dedicated cspace store is needed Initial Conceptual Architecture and Features This section gives an overview about the features of the cspace store which will be realized in the cspace project. Additionally, the initial high-level architecture in a conceptual version is presented Features The cspace Store is concerned with the software infrastructure to allow for the provisioning and consumptions of cspace Apps, therewith providing the core elements for the monetization throughout the ecosystem that shall be facilitated by the cspace. All cspace Apps shall be made available in the Store and consumer will be supported with easy to use search and consumption features. The consumption includes the purchase support as well as the slight execution at runtime. Features for the former contain an App purchase process. Features for the latter include easy download and installation (if components need to be installed on client side) as well as unlocking (for components running directly in the cloud) and execution of Apps and components. Finally, for consumers also a simple right management must be provided which informs the customer about mandatory and optional rights the App requires (before purchase) and enables him or her to configure those for each App (after purchase). For App publishers and developers supportive features will be provided too. Firstly, easy to use discovery for Apps and App interfaces are intended to enable them to find reusable functionalities. Secondly, Publication support is provided together with an integrated compliance check for publishing new Apps in a simple way in the cspace store. Finally, financial management is part of the cspace Store which enables app providers to run statistics and share revenue with involved partners (e.g. developer of re-used component) using different revenue models High-Level Conceptual Architecture In general all Apps are stored in a so called cspace App repository. As shown in the figure below, the cspace Store has 2 main user groups: Consumers as the (Business) End-Users who utilize the cspace apps to conduct business tasks (esp. the collaborative business activities across organizational boundaries), and Developers who develop Apps for the cspace. For both, D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 51 of 87

52 a Consumption Support component is provided which provide the necessary software infrastructure to find, and (re-)use Apps, resp. provide them via the cspace Store. Apart from that, a Purchase component will be implemented which supports the purchasing process including the process support for buying an App (e.g. incl. terms and condition agreement) and paying for it. In the figure below you can also find a Provisioning Support component which enables developers to easily upload and publish newly developed Apps (e.g. including technical compliance checks). In addition, the Financial & Revenue Sharing Manager, who is part of the already mentioned cspace App Repository, handles the economic aspects, i.e. the monetary incomes and the revenue sharing to the providers ecosystem. Figure 8: cspace Store - High-level Conceptual Architecture Technically, the cspace Store and the necessary software infrastructure is planned to be developed on top of existing frameworks and technologies; primary candidates are the Generic Enablers from the FI-WARE IoS Chapter, esp.: using (Linked) USDL as the basis for the App Description Language, using the Service Repository as basis for the cspace App repository and the Marketplace GE as basis for features of the Consumption Support and Provisioning components. The table below shows in more detail the components and main features of the cspace Store and the relevant FI-WARE Generic Enablers used for their implementation. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 52 of 87

53 Table 7: cspace Store Components & Relevant Generic Enablers Component Description Relevant FIWARE GEs cspace App Repository App Discovery Support for Consumers Purchase of Apps (for Consumers) App Discovery & Re-use Support for Developers Provisioning Support for Developers Financial & Revenue Sharing Manager The repository where all registered cspace Apps are available (most likely based on (Linked) USDL descriptions), including: Storage of cspace Apps, resp. their linked USDL descriptions Extension of (Linked) USDL for description of Apps USDL Editor to create descriptions for cspace Apps Basic CRUD (create, remove, update, delete) operations for managing registered Apps Tool Support to allow Consumers to search, find, and inspect available apps, incl.: Search for Apps (UI): repository browsing + advanced search features Support for detailed investigation: what it does, how it works, pricing models, terms & conditions Ratings of Apps by other Consumers Tool Support for allowing Consumers to buy apps, incl.: Procedure for purchase process: select items for purchasing, selected & agree on purchase terms & conditions, confirm purchase ( shopping chart style or the like) Invoicing & payment (via external services?) Purchase of updates and service packages for apps Approval of required rights Tool Support to allow Developers to search, find, and inspect available apps to develop new apps, incl.: Search for Apps (UI): repository browsing + advanced search features Support for detailed investigation: main features, technical interfaces, data models, dependencies, usage terms & conditions, etc. Ratings of Apps by Consumers & Developers Tool Support to allow Developers to publish Apps in the cspace Store, incl.: Provisioning procedure: o register as developer / provider, o create and publish USDL description for App Technical Governance Check : support for cspace Technologies (Interfaces, UIs, APIs, Security), functional check Define / configure pricing model and usage terms & conditions, etc. Manage financials of the cspace: income by enduser payments, revenue sharing among providers, incl.: Tracking of Service & App Usage by Consumers Selection & Configuration of Pricing & Payment Models Revenue Sharing among cspace Operators & Service / Solution Providers Statistical analysis for Consumers, Operators, Providers Apps Registry Apps Repository Linked USDL GE Marketplace GE Repository GE Registry GE Store(s) from FIWARE Discovery & Matchmaking Component Linked USDL GE Linked USDL RSS (Revenue Sharing) GE Marketplace GE Discovery & Matchmaking Component Repository GE Registry GE Apps.Repository Marketplace GE Linked USDL GE RSS (Revenue Sharing) GE D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 53 of 87

54 Initial Assessment of relevant Generic Enables In this section provides an initial evaluation of GEs that are relevant for the technical realization of the cspace Store. This evaluation exclusively focuses on their capabilities relevant for the cspace Store implementation. Finally, at the end of this section it will be described what features must be implemented in addition to the existing GEs Linked USDL GE Linked USDL is a service description language which not only describes the technical aspects of a service but also the business and operational aspects. The language is based on the Resource Description Framework (RDF) and consists of several modules which are mainly optional for a service description. As it is based on RDF, it can be easily extended with additional domain-specific extensions. This means that Linked USDL as the comprehensive description model for both technical and business services that underlies the Generic Enablers offered for the Application and Service Delivery Framework can easily be extended for the description of cspace Apps Marketplace GE The Marketplace provides the basic functionalities that are necessary for bringing together offering and demand for making business. This include basics services for registering business entities, publishing and retrieving offerings and demands, search and discover offerings according to specific consumer requirements as well as lateral functions like review, rating and recommendation. However, the Marketplace GE provides only hub functionalities: this means that it is not an (App) store itself, but allows connecting multiple (App) stores in order to provide a single point of access to them. In addition, the Marketplace offers only APIs but no user interface. However, basic functionalities (e.g. shopping basket) needed for implementation of an (App) store are available, although a store implementation itself is not provided so far. Part of the Marketplace GE is also the Discovery & Matchmaking Component which enables the comparison of several service offers and service demands. For an App store mainly the comparison component of it is relevant. So far there is even a user interface available for comparison of service offers (at least for cloud services) Repository GE The Repository GE should provide a consistent and uniform API to Linked USDL service descriptions and associated media files for applications of the business framework. Service providers can use the Repository GE to publish their Linked USDL descriptions or any other files. However, unfortunately there is no searching functionality available in the repository at all which means that the repository must be connected to a Marketplace GE in order to provide searching. That is the major drawback with the Repository GE at the moment Registry GE This provides basic registry facilities that can be used to register offers and demands stored in different places like e.g. (external) stores places that connected to the Marketplace GE, in other D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 54 of 87

55 Linked USDL repositories, or somewhere else on the Web. The Repository GE is closely integrated with the Marketplace GE Store from FIWARE Discovery & Matchmaking Component The development of the Store GE was frozen in the FI-WARE project for a long time which means, that compared to the other GEs the development progress of the Store GE way behind the progress of the other GEs. Thus, there are not many technical details available about this GE so far. However, it is expected from the FInest perspective, that it can be reused or at least serve as inspiration for implementation of the cspace store Gaps between provided GE Functionalities and intended cspace Store Features In order to implement the cspace Store, at first an infrastructure must be set up that contains at least one instance of Marketplace GE, Registry GE and Repository. Additionally a store is needed which must be connected to the Marketplace. That might be simply an instance of the Store GE in the best case or an own implementation (based on existing technologies) if the Store GE is not ready to use. The main block to be implemented is the user interface of the whole App store because it must be very intuitive (similar to Google Play, for example) to be used by business experts with only minor technical understanding. The mentioned GEs provide already sufficient support for the cspace App Repository and Consumption Support components (see section above), and provide at least some of the features required for the Purchase component (e.g. the shopping basket ). Completely missing so far are the features needed for the Provisioning component (i.e. the compliance check) and the Financial and Revenue Sharing Manager. Those need to be implemented in cspace Comparison to Existing Commercial Solutions Existing Solutions Currently there are different ecosystems in the IT industry in which apps are used and sold in a B2C scenario. Especially, with mobile operating systems like Android, ios and Windows Phone, those concepts are present. Beside those, apps are also present in (more or less nonmobile) operating systems like Windows 8 and Mac OS; as well as, in Browsers like Google Chrome or on Samsung s Smart TVs. All those platforms have in common that for each platform one major store is available which provides apps specific for that ecosystem. For some platforms third parties run minor additional app stores (e.g. Samsung Apps Store for Android 5 ) but in this chapter only the main stores are considered. In this category fit also digital distribution platforms like Steam by Valve 6 or Origin 7 by Electronic Arts which are mainly, but not only, used to sell games for different Windows operating systems. Apart from Android and Windows there is a strong one-to-one relation between platforms respectively ecosystem and app store. All the mentioned app stores and digital distribution platforms (from now on simply called stores) implement the following concepts which can be considered as state-of-the-art: D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 55 of 87

56 1. Direct and simple buying feature (down to 1-click buy) 2. Automated download and installation after purchase (if necessary) 3. Notification and (automated) download and installation of updates 4. Openness for 3 rd party app publishers 5. Purchase for 1 specific platform only Especially the app stores for mobile platforms offer additional features like: 6. Integrated right management and right approval for apps and updates In the B2B world, there are some app stores; however, most application providers sell their apps via personal contact instead of using a dedicated store. The latter approach is applied by Descartes, for example. Descartes solutions are briefly presented via the company website 8, but a customer has to contact the company in order to purchase one of them. In contrast, for example SalesForce runs appexchange 9 which works like an app store for mobile platforms (as described above). The Fraunhofer Institute is working on a digital distribution platform for selling cloud solutions for the logistics domain from various 3 rd party application providers. It is called Logistics Mall 10 and itself runs in the cloud. In terms of payment models the existing stores are inflexible. That is especially the case with the currently very popular app stores like Google Play for the Android platform or App Store for ios (see e.g. [9],[10]). Application purchases are usually paid by a fixed rate within a single transaction. Although some applications also offer a payment based on a monthly basis, this model is only rarely applied and in most of the cases used if a customer books some special additional services from the App developer. Also, an advertisement-based model, as provided by Facebook [11], may not be viable in the B2B setting, which is in focus of cspace Distinctive Features of the cspace Store Above, several app stores and digital distribution platforms have been mentioned. Because of the presence of all those the question may be raised if a dedicated app store for cspace is needed. The answer is yes, because of two reasons: Firstly, cspace is intended to enable establishing a new ecosystem, and the apps developed therein require the cspace infrastructure. Due to the technical requirements, these cannot be sold via an existing app store for a different platform or infrastructure like Android or SalesForce as these do not support the cspace technical governance and commercialization infrastructure. Secondly, cspace has different requirements for app support than other ecosystems. For example, a different right management is needed; although similar to existing mobile apps stores, this requires a much more elaborated and sophisticated security and access control. This is a central aspect for business software on the cloud where more restrictions are necessary than for data and hardware of a mobile phone (see Section 7.5) D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 56 of 87

57 In addition to this, a more flexible revenue system is necessary to fit the needs of the market [12] and need to be implemented in the cspace Store. This enables a broad range of new and different business models like pay per use, pay per cspace API call, flat rates or progressive models. Additionally, the cspace platform involves a multitude of different stakeholders between which the overall revenue has to be shared. The currently available app stores fall short of providing sufficient solutions for the B2B environment cspace is envisioned operating in. Thus, one of the key contributions to the state-of-the-art of the cspace Store is providing a more flexible revenue sharing system with more advanced payment models targeted at the B2B space. The cspace Store, and its included operations, will provide the end-customer, the (external) App developer and the platform provider, with flexible revenue sharing models. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 57 of 87

58 7.3. System & Data Integration As FInest is primarily a collaboration space for inter-organization collaboration and brings a multitude of stakeholders together including their services for interaction, a very important aspects is supporting consumable integration mechanisms with systems and data external to FInest with minimal effort and costs. The studies conducted in D-3.2 and the technical specifications put forth in D-3.3 are basis for the System and Data Integration Layer for the cspace as outlined in Section The focus in this deliverable is the deeper analysis of the available Generic Enablers that were identified to support the requirements, and the following is a report on the evaluation of the Mediation Generic Enabler Revision of the Technical Architecture The specification proposed and described in D-3.2 is still valid. During the evaluation of the Mediation GE it was confirmed that the underlying technology on which the generic enabler is built (that is the WSO2 Enterprise Service Bus 11 ) may be used for supporting the integration requirements in transforming and routing external data to internal FInest components and modules. Still it is recommended to evaluate the Middleware GE during phase 2 once more details on this generic enabler are available and interlock with cspace Platform Middleware and Operating Environment support Evaluation of Mediation GE (WSO2 ESB) In accordance to the aim of the this evaluation, the following provides a description of the external service to integrate with including expected input and output, explains the necessary configuration process that has been conducted with Mediation GE in order to integrate the external service, and discusses the results with respect to suitability of the Mediation GE for system & data integration in the context of the cspace project in Phase Goal of the Evaluation The goals of the evaluation is to successfully demonstrate the integration between FIWARE and an external service that is indicative of a domain partner that would expose services to FInest and understand the configuration process to realize this. Further understanding targeted is the understanding of the skills and role of a person and their affiliation in enabling the integration Arcelik s DAYS_FInestTest Service Arcelik exposed a simple service in their in-house software test environment called DAYS which is used for transport planning purposes. The service accepts a simple input command with no parameters and returns a list of sample orders from their SAP systems. There were two web services prepared; one with SSL security and another without SSL security, because the Mediation GE exhibited some problems with certifications to integrate with the secured service. After this was fixed by the generic enabler s owner as the result of a direct interaction between FInest and FIWARE both modes are now available for use. 11 See technical specification of Mediator GE, available on the FIWARE wiki: D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 58 of 87

59 Both services receive as input the following content in the SOAP message body: <DAYS_FInestTest xmlns=" /> The service returns as output a SOAP message body that looks as follows (content was cropped due to information confidentiality). <DAYS_FInestTestResponse xmlns=" <DAYS_FInestTestResult> <xs:schema xmlns:xs=" xmlns="" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" id="days_finesttest"> <xs:element name="days_finesttest" msdata:isdataset="true" msdata:usecurrentlocale="true">... </xs:schema> <diffgr:diffgram xmlns:diffgr="urn:schemas-microsoftcom:xml-diffgram-v1" xmlns:msdata="urn:schemas-microsoftcom:xml-msdata"> <DAYS_FInestTest xmlns=""> <Table diffgr:id="table1" msdata:roworder="0"> <Department>xyz</Department> <Responsible>xyz</Responsible> <SapOrderNo>N/A</SapOrderNo> <Country>xyz</Country> <PlaceOfDeliveryDefinition>xyz </PlaceOfDeliveryDefinition> <PortOfDeparture>xyz</PortOfDeparture> <PortOfArrival>xyz</PortOfArrival> <CutOff> T00:00:00+03:00</CutOff> <Incoterm>xyz</Incoterm> <ETD> T00:00:00+03:00</ETD> <ETA> T00:00:00+03:00</ETA> <ATD> T00:00:00+03:00</ATD> <ATA> T00:00:00+03:00</ATA> <CreateDate> T12:03:00+03:00 </CreateDate> </Table> Configuration of Mediation GE (WSO2 ESB) Following is a description of the process to configure the DAYS_FInestTest service to be accessible through the Mediation GE and therefore to the rest of FIWARE s components and services. 1. Access the Mediation GE through the catalog entry and notice the credential information to use with the generic enabler: 2. Follow the Service Endpoint (URL) and enter the credentials. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 59 of 87

60 3. Under the Main perspective and Manage accordion, look for the Web Services topic and select the List command. Notice there are 2 entries prefixed with FINEST one for the secure service and the other for the non-secure service. 4. To add a new service, select the Proxy Service command under Web Services -> Add topic and chose Pass Through Proxy. 5. In the following form provide a name to the proxy and enter the URL of the web service (either one provided by Arcelik) 6. The proxy and integration is complete and it can be tried out when selecting the proxy under Web Services -> List and selecting the Try this service command in the Client Operations table Results By selecting the Try this service command for the proxy, a new window pops up where the request can be entered and, if successful, the response from the service is displayed. As can be seen in Figure 9, the integration between FIWARE through the Mediation GE and Arcelik s test environment was successful. Figure 9: Successful response from DAYS_FInestTest service Next Steps The evaluation has shown that with very few steps that are purely configurable and accessible through a web interface a new service may be integrated with FIWARE. There is no requirement for specialized skills and the process is quite intuitive and may be even performed without reading tutorials or user guides. This, however, is not enough. As specified in D-3.3, there are requirements for mediation services, for example, that transform EDI protocols and D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 60 of 87

61 data structures, common in the transport and logistics industry, to RESTful interfaces, supported by FInest components and modules. This work will come to bear in cspace when integrating with external systems in the use case trials. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 61 of 87

62 7.4. Platform Middleware and Operating Environment The following provides an initial conceptual design along with an identification of suitable Generic Enablers as well as other suitable baseline technologies for realizing the Middleware and Operating Environment for the cspace. As outlined above (see Section 6.1.1), this is needed to allow for the proper operation of the cspace as a distributed cloud application Requirements and Initial Conceptual Design As motivated in D-3.3, one important architectural consideration is to provide means to allow an efficient and effective mechanism to deploy, execute and dynamically integrate cspace components, as well as value-added apps and services that shall be developed for the cspace. This includes means to properly deploy, manage and maintain modules, apps and services on a cloud infrastructure supporting a reliable, elastic and sustainable execution of cspace. The aforementioned capabilities extend from traditional middleware solutions, by requiring additional capabilities for service composition and orchestration, such as Enterprise Service Bus capabilities. More specifically, the capabilities significantly extend features available in existing cloud platform solutions that offer Software-as-a-Service and Platform-as-a-Service delivery models. Prominent examples include ebay, the Amazon Retail Platform, as well as force.com. Those offerings, despite their obvious value and acceptance, are either very restrictive (i.e., provide only limited flexibility for delivering novel solutions), might require that all software is deployed on the platform owner s infrastructure (thus possibly raising privacy concerns), or require complex involvement of IT experts to develop Apps. The cspace middleware and operating environment aims to constitute progress from those solutions to (1) support very large scale operations with heterogeneous access points and hosting facilities, (2) allow a domain / business expert to contribute to App development (Section 6.1.2), as well as (3) maintain the quality of service expected by the App developer and possible service-level-agreements. The cspace operating environment aims to deliver the very components that together provide the fabric allowing modules, apps and services to work together in harmony, thereby laying the foundation for application level management and operations. The delivered components will ensure that components, apps and services can technically interact, and they will make sure that the platform behaves in a reliable, trust-worthy, and fault-tolerant manner. The operating environment will include: the technical interface technology and interaction protocols via which components, apps and services communicate, technology (in the form of an Enterprise Service Bus) that facilitates dynamically combining and integrating technical components, apps and services, e.g., if a user performs an action in the UI of an app, then the appropriate backend implementations (typically implemented as a service) are called and if needed data import from a connected legacy system (using the facilities described in Section 6.1.2) is performed, and D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 62 of 87

63 technology that ensures consistency and transaction management, ensuring the same reliable operation that users expect from today s on-premise and desktop IT solutions. Ultimately, the operating environment will provide the key mechanisms for executing, monitoring and managing software and apps. It will allow for deploying and operating the cspace solutions in large-scale heterogeneous cloud environments in a smooth and harmonious manner. In addition, the operating environment will facilitate easy development and deployment of new apps, additional software components and service orchestrations Key Features and Relevant Generic Enablers The operating environment will provide the following key (technical) features: Standardized interface descriptions (SOA based) for composing and interconnecting software components, apps and services; the management of the composed service (application) life-cycle will be based on IaaS Cloud related OSS and BSS coming from FI WARE. Distributed Enterprise-Service-Bus (ESB) solution for consistent component, app and service interaction and composition, exploiting peer-to-peer overlay solutions; due to the distributed nature of the cspace solution, an Enterprise Service Bus that is based on Peer-to- Peer Overlay technology and supports Pub/Sub Abstraction for information dissemination, and Bulletin Board abstraction for filtering and orchestration (workflow) is chosen. Light-weight replication and consistency management supporting strong consistency for critical information (exploiting e.g. solutions from Paxos [13]). The Consistency and Replication Service is partition tolerant and guarantees strong consistency. Monitoring mechanisms and techniques for (composite) apps and services allowing providers to manage performance and quality of service; Monitoring will foster automation of the operation of the platform, enforcing SLAs, facilitating problem determination, as well as allow for continuous optimization during runtime. Multi-tenancy facilities providing transparent and seamless development of multi-tenant apps and services. The following Generic Enablers have been identified as fundamental building blocks to realize the operating environment: DataCenter Resource Management GE (Cloud Chapter) Marketplace GE (Apps & Services Chapter) Mediator GE (Apps & Services Chapter) Things Management GE (IoT Chapter). D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 63 of 87

64 7.5. Security, Privacy, and Trust As the last but very essential technical building block for the cspace, the following provides the progress on the Security, Privacy and Trust (SPT) framework. Referring to Deliverable D3.3 for the technical specification, we here present two distinct achievements from the FInest project: (a) a proof-of-concept implementation of the for the User Management and Access Control that validates the IDM Generic Enabler and provides the basis for the deployed FInest prototypes, and (b) a refined conceptual design and implementation plan for the Security- Privacy-Trust framework for cspace. The aim of the Security, Privacy and Trust (SPT) framework of FInest platform is to provide secure and reliable exchange of confidential business information and transactions with secure authentication to the platform with required minimum access rights. SPT technologies from FI- WARE will provide security mechanism and assurance methods to FInest and cspace, which is a Phase 2 project. Authentication, Authorization and Accounting technologies will provide user management & access control to the FInest and cspace. Developer Framework is supported by SPT technologies to provide right security solutions to the developers. Based on the identification of relevant technologies and usage of the respective FI-WARE results, the following techniques present our work on FInest and in preparation for cspace FInest User Management & Access Control Prototype As outlined in Section 5, FInest has developed the prototypes for the 4 core modules. As indicated in the integrated demonstration story (see Section 5.2), each user is required to access many modules in order to utilize the true potential of the FInest platform. For this, a proof-ofconcept prototype has been implemented that uses and validates the IDM Generic Enabler provided by FIWARE. This serves as the entry point for the integrated prototypes, which are deployed on the cloud infrastructure hosted by KocSistem. The following explains the prototype and its technical realization Prototype As outlined in Section 5.1, for security purpose each of the FInest Core Module prototypes is password protected and user is expected to use credentials to access the password protected area. The central access page to the prototypes is: Single Sign-on gives users the ability to switch between modules without entering credentials once session is started meaning that user enters credentials just once to start a session. Each module uses a certificate that the IdP has generated and any communication is signed with this certificate. Once user is authenticated, information is sent as SAML response which is digitally signed by IdP. This approach helps SP and IdP to recognize signed-on user and avoid security flaws. System gives the user access to the resource, only if the SAML response is properly signed. The use of Single Sign-on allows module users to authenticate themselves once and switch between modules with the same authenticated session. Upon trying accessing the password protected area; user s authority gets checked against One-IDM. Since user credentials are never entered, user lands to One-IDM login page via FInest system. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 64 of 87

65 Figure 10: FInest User Management (Screenshot) Once credentials are accepted, authorization is sent to the module page by Identity Provider. At this point user is actually authorized for all four core modules and stays authorized until the session expires or user logs out. Figure 11: Start Page for Access-Controlled FInest Prototypes (Screenshot) When user accesses different module than the one initially accessed before; module once more checks against One-IDM. Yet this time user is already authenticated, therefore login steps are bypassed. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 65 of 87

66 Figure 12: User-specific Start Page of BCM Prototype (Screenshot) A trust relationship is established between the One-IDM and the FInest Modules. Essentially, the FInest Modules has a certificate that the One-IDM has generated and any communication from the One-IDM to FInest Modules has to be signed with this certificate. Once One-IDM authenticates the user, information is sent to FInest Modules as SAML response which is digitally signed by One-IDM. The browser takes this SAML response and posts it to the FInest Module. The module confirms that the SAML response is properly signed, and if so, gives the user access to the resource Technologies & Generic Enablers The use of Identity Management and Single Sign-on with SAML provide solution to handle individual identities between multiple systems. The practice delivers multiple advantages to user as well as to system security. Users would reduce password fatigue from different username and password combinations switching between applications and reducing time spent re-entering passwords for the same identity. From the security perspective; SAML authentication is standard data format for exchanging authentication and authorization data between identity provider and a service provider that offers applications. Identity Management (IdM): Identity management is an administration of individual identities within a system, such as a company, a network or even a country. In enterprise IT, identity management is about establishing and managing the roles and access privileges of individual network users. ID management systems provide IT managers with tools and technologies for controlling user access to critical information within an organization. Single Sign-on (SSO): Single sign-on (SSO) is an authentication process that permits a user to enter one username and password in order to access multiple related, but independent applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 66 of 87

67 Figure 13: FInest User Management based in IDM Generic Enabler Security Assertion Markup Language (SAML): Security Assertion Markup Language is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and service provider. The primary SAML use case is called Web Browser Single Sign-On (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML service provider. The service provider issues an authentication request to a SAML identity provider through the user agent. The resulting protocol flow is depicted in the following diagram. Figure 14: Workflow of Single-Sign-On facility D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 67 of 87

68 Refined Conceptual Design & Phase 2 Plan Referring to the technical specification for the SPT-framework as already provided in Deliverable D3.3 (see Section 4.3 in [1]), the following provides extensions to the overall framework and architecture that are relevant in the context of cspace and an outlook to the implementation activities planned in Phase Security-Privacy-Trust Architecture for cspace SPT technologies from FI-WARE and necessary technologies from third parties will provide a secure and reliable design of the cspace. Some of the integration of GEs, like IDM, has already begun and some will continue on cspace. Table 8 below shows the main usage scenarios for the FInest Platform has been identified. For each scenario we provide a list of security requirements and present relevant security technologies. Table 8: cspace Securitry Requirements and Planned GE Usage Security Scenario Security Requirement and Current Situation User Management Authentication of Users and profiling. IDM has been integrated on the prototypes Security Technologies IDM, Privacy from FIWARE Version & Release Information IDM from FIWARE Release1 Privacy from FIWARE Release2 Access Control User can see only what he / she allowed to see. Currently, roles will be defined on modules. Role Base Access from FIWARE FIWARE Release2 Private Data User will have an option to define own data as public or private. Secure Storage from FIWARE FIWARE Release2 Monitoring & Alerting Security Incidents Service Provider can see and follow the Security Incidents and take action. OSSIM has been tested on prototype environment Security Monitoring from FIWARE FIWARE Release1 Secure User Data Sharing User has an option to choose sharing his/her own data for other parties Data Handling from FIWARE FIWARE Relase1 Malware Detection Scanning of binary data for the malware check. Anti-Malware from FIWARE FIWARE Relase2 Some intelligent Web 2.0 threats should also be considered. Defensio is a good example for social web security where it can protect personal or corporate web profiles from the spam and malicious content. Along with improved management and control of content posted on any website, Defensio provides superior security against threats that target social media. The figure below shows the planned Security Privacy & Trust framework for the cspace project, indicating the planned usage of FI-WARE GEs and technologies from other providers. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 68 of 87

69 Figure 15: Technical Specification of Security-Privacy-Trust Framework Phase 2 Implementation Plan The following outlines the main development activities that are planned for the cspace project in order to provide a comprehensive SPT framework for the cspace. We refer to Section 8 for further details on the allocation in the project and the release time plan. User Management & Access Control Currently SSO experience is provided to users through FInest Login page. Direct switch between modules are not possible. With the planned implementation; users would be able to switch between the modules. Upon completion of RBAC (Role-Based Access Control) by FI-Ware (ETC: ), login component for each core module should be updated based on SAML 2.0 specs provided. Only D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 69 of 87

70 after the update; modules will be able to provide rights to users based on their roles. Role information should be delivered directly to the module by RBAC. After completion of these processes; SSO concept will be put into practice entirely. Once these steps are done, work for more detailed role analysis can be started up for each module. Security Technologies & Generic Enabler Usage Although current security level of SAML Authentication -supported with digital signatures and SSL 3.0- is strong, level of security should be improved to prevent replay attacks 12 and session hijacking 13. Along with the common prevention technics, -such as generating session tokens randomly, generating MD5-hashed IP or MAC address- multi-factor authentication 14 should also be used to prevent unauthorized accesses. These factors can be; something known, like a PIN or personal information, something possessed, like your ATM card or something unique about you, like a fingerprint. Mobile device software tokens are also a very common practice to handle two-factor authentication. User runs a mobile application to generate one time password. Password expires after a certain time or when it is entered. Unfortunately, each of these extra security practices is handled by users and can cause confusion. Zurich University of Applied Sciences came up with a unique solution to solve this problem on mobile devices. The idea is that if one session is securely authenticated (usually the first one) and shared token is derived, this token can be re-used to authenticate later sessions. More detailed, the approach works as follows: Before a new session is initiated, the mobile device stores a shared token from the previous session then is used to compute the shared token to authenticate the new session. SPT Developer Framework Defined SPT technologies will be used and integrated Developer Framework with proper right security solutions. Correct usage of the security mechanisms will enable the verification of the security policies are enforced across the Finest / cspace platforms. In the following cspace project, related SPT technologies will be defined for proper security solutions, hence applications will be designed with security and reliability. 12 A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. 13 Session Hijacking is an exploitation of a valid computer session to gain unauthorized access to information or services in a computer system. 14 Multi-factor authentication (aka Two-factor authentication) is an approach to authentication which requires the presentation of two or more of the three authentication factors. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 70 of 87

71 8. Overall Phase 2 Implementation Plan As outlined above (see Section 1), a major activity within the Phase 2 Preparation Work Stream, the FInest team developed a phase 2 implementation plan in order to realize, implement and trial the FInest solutions. In this section we describe this implementation plan, which in fact has materialized itself in a successful project proposal for the FI PPP Phase 2 round of use case projects. This project, cspace, in addition to delivering the key software elements of the FInest platform, also introduces additional and complementary application scenarios and thus opportunities for uptake of the FInest platform and solutions. The following summarizes the key technical aspects of the cspace project and how the FInest components and core modules are being taken up, integrated and implemented. We first summarize the overall goal and approach of the cspace project (Section 8.1), then provide an introduction the project s overall work breakdown structure (Section 8.2), key work streams and technical outcomes (Section 8.3). This is followed by an explanation of how the FInest core modules and technical components presented above will be followed-up and realized as part of cspace (Section 8.4). We conclude the phase 2 implementation plan by providing a milestone and release planning (Section 8.5). You may refer to Deliverables D-5.5 to D8.5 wherein the phase 2 implementation plan is refined for the four FInest Core Modules The cspace Project: Overall Aim and Approach As mentioned above, the cspace leverages on the outcomes of two complementary Phase 1 use case projects: FInest & SmartAgriFood. The insights gained in both projects emphasize the need for novel ICT solutions that allow radical improvements for collaboration in business networks, with Agri-Food and Transport and Logistics industries as primary sectors demanding such solutions: several actors (incl. enterprises, authorities, service providers) need to exchange information & communicate across organizational borders to conduct business. The aim of the project is to pioneer towards fundamental changes on how collaborative business networks will work in future. For this, the goal of cspace is to drive development and trials for an integrated and extensible business-to-business collaboration service and associated Apps, thereby establishing the standard for supporting and optimizing inter-organizational business collaboration in the global transport, logistics, and agri-food industry. To achieve this within the 24 month timeframe, the project follows an incremental, iterative development and release approach. This means that cspace results will developed along 8 consecutive 3-month milestones, ultimately delivering the measurable results as laid out in Section 8.5. This iterative approach allows delivering and disseminating results early on, thus fostering adoption both within and outside the consortium. To achieve its objectives, the cspace project will focus on the following four primary work areas, for which we outline the main concepts and approach below: 1. Implement the cspace as an open and extensible Software-as-a-Service solution along with an initial set of cross-domain applications for future B2B collaboration, utilizing the Generic Enablers provided by the FI PPP Core Platform D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 71 of 87

72 2. Establish Experimentation Sites across Europe where pilot applications are tested in early trials from the Agri-Food and the Transport and Logistics domains 3. Provide a working Experimentation Environment that implements the eight use cases defined for cspace and which allows for large trials in phase 3 of the FI PPP, and 4. Prepare for industrial uptake and innovation enablement by pro-active engagement of stakeholders and associations from relevant industry sectors and the IT industry. The key R&D principles underlying the cspace S&T strategy are: Provide early and continuous releases of specifications and technical interfaces of the cspace solution, thereby ensuring that domain Apps will be developed and made available in the cspace app store early on in the project, thus facilitating the involvement of interested domain players outside the consortium. Initiate an open call to obtain development partners (including SMEs) to begin rapid development of domain Apps so that the foundation for a robust ecosystem for the targeted cspace domains (transport, logistics and agri-food) can be established, as well as to build a critical mass for large scale expansion in Phase 3. Leverage and extend the domain-solutions and stakeholder communities established during the Phase 1 use case projects FInest and SmartAgriFood. This extension of capabilities will allow for cross domain usage of the cspace service to address multi-domain business challenges. Follow a continuous, incremental development and validation approach of the cspace solutions, starting with software testing of the cspace components, validation of the cspace services in an experimental environment, up to the in-the-field deployment of cspace software as part of trial and demonstration sites. Balance domain-centric technology pull (making sure the results addressing the needs of key European domain players) with ICT driven technology push (making sure to provide clear market opportunities and competitive advantage for European ICT companies). Ensure structured and effective technical management (including continuous identification and mitigation of risks), while remaining agile to respond to novel findings (e.g., from the trial experiments), emerging requirements (e.g., from the inclusion of open call members), and technology developments (e.g., from new releases of Generic Enablers). Seeking for strong synergies between cspace, the FI PPP program, and EU projects in general, the cspace project will: Strongly integrate and align with the Technology Foundation ( Core Platform ) activities (including FI-WARE and its successor project), specifically for what concerns the use, integration and validation of its generic enablers. Leverage the outcomes and services of the Capacity Building activities, possibly including the provisioning of computing, as well as real-world infrastructures and trial sites (on top of which generic and domain-specific capabilities may be offered). Utilize the cross domain capabilities of cspace (as demonstrated by joint transport &logistics and agri-food use cases) to encourage other FI PPP use case projects to utilize and contribute to cspace. Build on, significantly extend and contribute to existing R&D results of EU and national projects in order to efficiently bootstrap the project and economize and leverage on previous R&D investments. Continuously identify opportunities for exploitation and standardization of cspace solutions in order to ensure wide adoption and sustainability of outcomes. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 72 of 87

73 Pro-actively participate in EU-wide coordination and alignment activities to maintain close interactions with other projects, identify synergies and establish active collaborations cspace Work Breakdown In order to achieve its goals, cspace leverages and capitalizes on the outcomes of two successful Phase 1 use case projects FInest and SmartAgriFood, as well as the Generic Enablers available from the FI PPP Technology Foundation ( Core Platform ) projects (FI-WARE and its successor). Successful achievement cspace s goals will be demonstrated through extensive trial experiments in the domains of agri-food and transport and logistics, which comprise diverse European trial sites, stakeholders and usage scenarios. One ultimate outcome of cspace will be the inclusion of stakeholder groups and providing guidelines, plans and recommendations for the large scale expansion of platform usage in Phase 3. Figure 16 shows an overview of the key activities and work packages (WP) that will jointly allow cspace to achieve the aforementioned goals. Figure 16: Overall project strategy and high-level work breakdown structure D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 73 of 87

74 The work in cspace follows three major work streams: Workstream 1: The major work stream in cspace is devoted to solution development, trial experimentation and use case expansion (depicted from top to bottom of Figure 16). It is subdivided into: cspace Development (WP200), which addresses the iterative design, implementation and testing of the software components implementing the cspace service, while incorporating feedback from users and developers, thereby ultimately enabling the App ecosystem; cspace Hosting & Experimentation (WP300), which is responsible for setting up compute infrastructures, deploying the cspace software components (developed in WP200) and Apps (developed in WP400) including the deployment of the required Core Platform Generic Enablers, as well as for providing experimentation support and enablement to the use case trials (in WP400); Use Case Trials (WP400), which defines cross-domain use cases and defines, sets up, and executes use case trials to demonstrate the cspace capabilities and benefits in the realworld; this WP thus includes the development of Apps and the connection of trial-specific, local infrastructure (e.g., in-the-field systems and devices) to the cspace software components (hosted by WP300). Two types of Apps will be developed: (1) general purpose baseline Apps (i.e., Apps are required by stakeholders across several domains), (2) domain Apps needed for conducting specific use case trial experiments. Open collaboration & Exploitation (WP500), which will foster early uptake of results and drive establishing an eco-system around cspace, including dissemination, exploitation and standardization; this WP will also coordinate and prepare guidelines and plans for large scale expansion of platform usage, involving relevant stakeholder groups. Workstream 2: Complementing workstream1 are activities related to Core Platform integration and validation (depicted from left to right in Figure 16). Specific interactions with the FI PPP Core Platform activities are planned as follows: WP200 will continue the assessment of the Core Platform Generic Enablers (already started in Phase 1) for what concerns their versatility and scope of capabilities when used for developing cspace software components. WP300 will assess the flexibility and scalability of the deployed Core Platform Generic Enablers for hosting the cspace solutions and experimentation environments. WP400 will analyse the openness of the Core Platform to accommodate building novel domain Apps on top of the cspace service. WP500 will jointly with other use case projects and the cspace stakeholder communities contribute to fostering improvements and update of Generic Enablers. Workstream 3: Ensuring project results and work progress are achieved on time, within budget, and in quality, the third work stream is responsible for project coordination (WP100). This general work breakdown of cspace is refined in the following subsections. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 74 of 87

75 8.3. Elaboration of cspace Technical Work Streams cspace Development (WP 200) WP 200 is responsible for specifying, designing, and implementing the software components and modules required for the extendible software as a service solution of the cspace. Overall WP 200 encompasses 5 major clusters of activities as depicted in Figure 17: cspace Core Features (Tasks ): These include software components that support B2B collaboration, realize dynamic front-ends, provide the cspace store and revenue management facilities, as well as implement configurable system and data integration mechanisms. Operating Environment (Task 260): This includes software elements that provide the middleware to compose, execute and orchestrate the cspace components and backend software of the domain Apps. Security, Privacy & Trustworthiness (Task 270): Those capabilities are considered key to allow for using the cspace service in a trusted business setting. Development Environment (Task 280): A dedicated development environment will support App developers in creating and publishing their solutions. WP Coordination (Task 210): This includes the development and release of the public cspace specification. Figure 17: High-level structure of WP200 cspace Development cspace Hosting & Experimentation (WP 300) WP 300 will be responsible for setting up compute infrastructures, hosting the cspace software components (from WP200), deploying the domain Apps (from WP400), and for providing experimentation support for the initial use case trials (defined in WP 400) in order to determine D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 75 of 87

76 whether the underlying technologies (the cspace service, Apps and Generic Enablers) are capable of delivering the expected functionality, performance, security, privacy and reliability, which are ultimately necessary for large scale user trials. Overall, WP 300 consists of three main parts as depicted in Figure 18: Hosting (Tasks 320 and 330): WP 300 will provide access to cloud based infrastructure for hosting the cspace software components (from WP 200). This includes installation and administration of the cspace components, as well as the Core Platform Generic Enablers integrated into cspace. Additionally, this includes support for hosting and operating the Apps developed in Task 450. Experimentation (Tasks 340 and 350): WP 300 will provide an experimentation environment for testing, analysing and assessing cspace and its Apps according to the use case trials and scenarios defined in WP 400. This includes simulation capabilities (based on real-world data recorded in the field), as well as setting up cspace test installations. WP Coordination (Task 310). Figure 18: High-level structure of WP300 cspace Hosting & Experimentation Use Case Trials and Domain Apps (WP 400) WP 400 focuses on leveraging and extending work performed in Phase 1 of the FI PPP program to setup trial sites for real world use cases and to exploit those sites for conducting initial use case experiments (with the support of WP 300) to determine and demonstrate whether the cspace solution and the underlying Generic Enablers being utilized are capable of delivering benefits and utility in the real-world. Based on the needs of the use case trials themselves, baseline and domain Apps will be developed (as part of WP 400) so that the trials can be performed and the ecosystem business model envisioned for the cspace service tested. In addition, where needed, trial-specific, local infrastructure (such as in-the-field sensors and devices) will be set-up and linked to the cspace components hosted by WP300. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 76 of 87

77 Figure 19: High-level structure of WP400 Use case trials and domain Apps Overall, WP 400 is decomposed into 3 primary types of tasks as depicted in Figure 19: Design, setup, and execution of use case trials: This includes defining cross-domain use cases and the set-up and execution of use case trials. Overall eight use case trials are proposed: Farming in the Cloud (Task 420) addresses (1) the intelligent application of pesticides to improve crop protection information sharing, and (2) the improvement of greenhouse operations through the use of IoT devices for monitoring and controlling environmental conditions. Intelligent Perishable Goods Logistics (Task 430) looks at (1) the shipment of fish from Norway to continental Europe and the impact that effective planning and replanning can have on the product, (2) the impact of supply chain deviations on fresh fruit and vegetables, (3) the improvement of the entire supply chain process of flowers to a retailer. Smart Distribution & Consumption (Task 440) is concerned with (1) tracking and tracing of meat from the farm to the consumer, (2) the linked management of inbound materials and outbound finished goods optimized w.r.t. consumer demand, (3) providing consumers with information about the products that they have purchased. Development of general purpose and domain specific applications (Task 450): The requirements for these Apps are defined in Tasks The Apps will demonstrate the extensibility and domain-specific benefits of cspace during the use case trials. This task is specifically concerned with the development of general purpose baseline Apps (i.e., Apps are required by stakeholders across several domains), as well as domain Apps needed for conducting specific use case trial experiments. This task will provide the following major outcomes: Design and implementation of general purpose starter Apps, including contract management, transport planning, predictive monitoring and product information services. Design and implementation of domain Apps to be used during domain-specific trial experiments. Reference implementations of Apps, including the definition of an initial set of Business Collaboration Objects for real-time B2B collaboration. D3.4: Techn. Spec. domain-specific FI Platform for T&L and Phase 2 Implementation Plan Page 77 of 87