document template · d2.2.2 comvantage architecture specification –confidential ... d5.2.3 ui...

284928

Collaborative Manufacturing Network

for Competitive Advantage

D2.3 – ComVantage Architecture Best Practises

(public)

D2.3 – ComVantage Architecture Best Practices

WP2 – Continuous Requirements Analysis and Overall Architecture

© ComVantage Consortium – 2014 2

Grant Agreement No. 284928

Project acronym ComVantage

Project title Collaborative Manufacturing Network for Competitive Advantage

Deliverable number D2.3

Deliverable name ComVantage Architecture Best Practises

Version V 1.0

Work package WP 2 – Continuous Requirements Analysis and Overall Architecture

Lead beneficiary TUD

Authors Markus Graube (TUD), Tobias Münch (SAP), Patricia Ortiz (INNO), Mohamed Hilia (EVIDIAN), Manu Carnarero (NEXTEL), Johannes Pfeffer (TUD), Jan Hladik (SAP), Philipp Herzig (SAP), Robert Buchmann (UNIVIE)

Reviewers Robert Buchmann (UNIVIE), Frank Haferkorn (RST)

Nature R – Report

Dissemination level PU – Public

Delivery date 31/08/2014 (M36)




Executive Summary This deliverable provides a description of the best practices for setting up and running an architecture of an interorganisational collaboration platform.

It is the result of an architectural alignment of the generic concepts developed in the ComVantage project.

It describes an integrated approach of architectural visions among all technical work packages. More detailed outlines to the ComVantage key concepts are described in related deliverables. Please find a list of all related deliverables in section 1.4.




Table of Contents

1 OVERVIEW .......................................................................................................................................... 6

1.1 INTRODUCTION ............................................................................................................................... 6

1.2 SCOPE OF THIS DOCUMENT ............................................................................................................... 6

1.3 TERMS AND DEFINITIONS .................................................................................................................. 6

1.4 RELATED DOCUMENTS...................................................................................................................... 7

2 TECHNOLOGICAL AND CONCEPTUAL ENABLERS ................................................................................. 9

2.1 BUSINESS PROCESS MODELLING ......................................................................................................... 9

2.1.1 Meta Modelling Platform / Compiler .................................................................................. 9

2.1.2 Standard / Legacy Modelling Languages.............................................................................. 9

2.1.3 Open Model Initiative (OMI) ............................................................................................... 9

2.2 BUSINESS PROCESS EXECUTION & MOBILE COLLABORATION ..................................................................... 9

2.2.1 Android .............................................................................................................................. 9

2.2.2 Python (rdflib)....................................................................................................................10

2.3 DATA INTEGRATION ........................................................................................................................10

2.3.1 URI ....................................................................................................................................10

2.3.2 RDF ....................................................................................................................................10

2.3.3 Linked Data ........................................................................................................................12

2.3.4 SPARQL ..............................................................................................................................14

2.4 USER AUTHENTICATION AND AUTHORISATION ......................................................................................15

2.4.1 SAML .................................................................................................................................15

2.4.2 XACML ...............................................................................................................................15

3 COMVANTAGE REFERENCE ARCHITECTURE FOR VIRTUAL ENTERPRISES ...........................................17

3.1 KEY CONCEPTS AND RECOMMENDATIONS ............................................................................................17

3.1.1 Decentralised Approach .....................................................................................................17

3.1.2 Model-driven Operation ....................................................................................................18

3.1.3 Semantic Data Harmonisation............................................................................................23

3.1.4 Integration of Data Sources and Legacy Systems ................................................................24

3.1.5 User Authentication and Authorisation ..............................................................................26

3.1.6 Orchestration of Mobile Workflows ...................................................................................28

3.2 ARCHITECTURE OVERVIEW ...............................................................................................................32

4 CONCLUSION .....................................................................................................................................34

5 REFERENCES .......................................................................................................................................35




List of Figures

Figure 1: D2R architecture (D2R, 2012) .......................................................................................................14

Figure 2 : Architecture XACML ....................................................................................................................16

Figure 3: Exemplary setup of a virtual enterprise with two collaboration partners sharing distributed data sources and business processes along a common end-to-end product value chain .............................18

Figure 4: Data modelling using the ontology extension approach and the proof-of-concept tool OntoSketch...........................................................................................................................................................21

Figure 5: Positioning the modelling method in the ComVantage architecture .............................................22

Figure 6: Silk User Interface ........................................................................................................................24

Figure 7: Example of the Linked Data adapter for databases from the application area Customer-oriented Production (WP7) ...............................................................................................................................25

Figure 8: Transformation from relational data model (top) to graph-based model (bottom) and its serialised representation as RDF (middle) ..........................................................................................................26

Figure 9: ComVantage secure framework ...................................................................................................28

Figure 10: ComVantage modelling patterns ................................................................................................29

Figure 11: The App Orchestration Process of the Industrial App Framework. ..............................................30

Figure 12: Example for two App Ensembles derived from a business process model. ..................................30

Figure 13: Example of Selection Pattern on Android target platform ...........................................................31

Figure 14: Order and alignment of the key concepts with the overall architecture approach of ComVantage and its logical layers ...........................................................................................................................32




1 OVERVIEW

1.1 Introduction

The ComVantage project aims at facilitating the collaboration of partners across organisational boundaries by applying novel collaboration and visualisation concepts for increased trust and latest data federation and security concepts in order to provide an appropriate data source integration as well as access control among different stakeholders. Within two main work streams the fundamental and generic concepts are developed and implemented within well-chosen application areas.

1.2 Scope of this Document

The purpose and scope of this document is the provision of a summary about best practices considering the integrated architecture of an interorganisational collaboration platform as well as the complete and final ComVantage technology framework. It is based on prior work published in several ComVantage deliverables and comprehensive discussion between developers in the project.

First, already existing technologies, standards and tools are described in chapter 2 that serve in terms of identified best-practices as enablers and foundation for the ComVantage architecture and are part of technology framework. This includes the main research areas of ComVantage which are, business process modelling, business process execution and mobile collaboration, user authentication and authorisation as well as data integration.

Second, an overview about the ComVantage architecture is given in chapter 3, specifically highlighting main technical concepts and new developed tools to complete the ComVantage technology framework.

In general, the document serves as overview about technical concepts and tools which are explained in more detail in the respective ComVantage deliverables. The specific deliverables are referenced in the text and are additionally listed in section 1.4.

The document is finalised with a conclusion in chapter 0.

1.3 Terms and Definitions

In the following, the key characterising terms of the ComVantage architecture are briefly explained:

Virtual Enterprise: By definition of (Barnett, et al. 1994), a virtual enterprise is based on a temporary alliance of several businesses. It takes advantage of a market opportunity and dissolves, when it has passed. A virtual enterprise does not have own major resources but it consists of the resources and core competencies of its individual partners.

Data Harmonisation: Concept to create a uniform foundation for data from different data sources. Harmonisation affects the data format (technical structure) as well as the meta model (naming and meaning of entities). Data harmonisation as a concept is key for a uniform consumption of data and further enriching operations (e.g. calculating implicit information, establishing relations between information). Relevant aspects with respect to data harmonisation are described in section 2.3 (Technological and conceptual enablers with respect to data integration), section 3.1.2.2 (Data models), section 3.1.3 (Semantic data harmonisation) and section 3.1.4 (Integration of data sources and legacy systems).

Linked Data: A method for publishing structured information in the web. It is primarily used as design principles for RDF-based data sets and aims at facilitating the interlinking of data across distributed data sources. Linked Data was motivated by HTML and the World Wide Web which represent the web of documents. In difference to those, Linked Data refers to fine grained information based on single statements (data triples) to establish the web of data. Please refer to section 2.3.3 for more details.




1.4 Related Documents

Since the overall ComVantage architecture is based on several technical approaches from the generic concepts work packages, all the related results delivered prior or in parallel to this deliverable have a strong influence. First, the finalising best-practice deliverables in the other work package provide further and more detailed reading:

D3.5.2 Guidelines for the secure collaboration model - public This deliverable provides final guidelines with respect to the ComVantage modelling method and the secure collaboration infrastructure.

D4.5 Linked Data best practices - public This deliverable describes final best practices about the modelling and integration of Linked Data into the overall ComVantage approach.

D5.4.2 UI guidelines for mobile collaboration - public This deliverable describes final guidelines to improve mobile UIs for collaborative scenarios as well as best practices for the enabling foundation and system architecture.

D6.5 Plant Commissioning and Engineering - Final report on best practices - public This deliverable describes best practices of applied generic concepts in the Plant Engineering and Commissioning application area.

D7.5 Customer-oriented Production - Final report on best practices - public This deliverable describes best practices of applied generic concepts in the Customer-oriented Production application area.

D8.5 Mobile Maintenance - Final report on best practices - public This deliverable describes best practices of applied generic concepts in the Mobile Maintenance application area.

D9.6 ComVantage implementation guidelines and plan – public This deliverable discusses the implementation of the ComVantage framework on an organisational level and therefor has a different perspective than the other listed documents, which are more of technical nature.

D11.4 Final report on prototypical implementation of ComVantage - confidential This deliverable reports about the final demo scenarios in each of the application areas and underlying technical set ups.

Furthermore, a couple of other technical deliverables provide more detailed insights into used technologies and concepts:

D2.2.2 ComVantage Architecture specification –confidential This deliverable provides the final ComVantage architecture describing all components and interfaces necessary to set up a collaborative network based on ComVantage.

D3.1.2 Specification of modelling method including conceptualisation outline - public This deliverable describes the ComVantage modelling method for business processes as well as the related tool chain.

D3.2.2 ComVantage secure information model definition - public This deliverable describes the ComVantage tool chain for user authentication and authorisation.

D3.4.2 Prototype of ComVantage modelling method – confidential This deliverable describes the final status of different modelling tools developed in ComVantage.




D4.1.3 Data format specifications - public This deliverable describes the Linked Data approach, the ontology engineering methodology and the ComVantage ontologies in detail.

D4.2.3 Middleware adapter set - confidential This deliverable describes the technical concepts of Linked Data adapters for middleware technologies.

D4.3.3 Business and engineering software adapter - confidential This deliverable describes the technical concepts of Linked Data adapters for business and engineering software.

D4.4.3 Linked Data support toolset – confidential This deliverable describes a set of tools and the necessary processes for creating, linking, mapping, curating and managing multiple datasets.

D5.2.3 UI presentation and workflow models - confidential This deliverable describes UI guidelines for collaborative mobile UI, especially with focus on business processes in the manufacturing domain.

D5.3.3 UI modelling and generation framework - confidential This deliverable documents the development result of the Industrial App Framework which represents an implementation of the novel ComVantage App Orchestration Concept.

All deliverables of the ComVantage project that are declared as public can be accessed on the ComVantage webpage: http://www.comvantage.eu/results-publications/public-deriverables/

http://www.comvantage.eu/results-publications/public-deriverables/




2 TECHNOLOGICAL AND CONCEPTUAL ENABLERS

2.1 Business Process Modelling

2.1.1 Meta Modelling Platform / Compiler

Meta modelling platforms / compiler like ADOxx1, MetaEdit+2and EMF3 can facilitate the implementation and deployment of the conceptual ComVantage modelling method in the form of a modelling tool. The latest version of the conceptual specification has been designed independent of such platforms; however, the modelling prototyping employed ADOxx for proof-of-concept implementation. Details about meta modelling platforms are reported in the deliverables D3.4.2 (Prototype of ComVantage modelling tool, confidential) and D3.5.2 (Guidelines for the secure collaboration model).

2.1.2 Standard / Legacy Modelling Languages

Familiarity with the following modelling languages can facilitate assimilation and quicker understanding of various fragments of the hybrid ComVantage modelling method: BPMS4/UML5 activity diagrams (for business process modelling), ER diagrams6 (for information space modelling), e3 value7 (for business modelling), FODA models8 (for value structure modelling), SCOR diagrams9 (for supply chain modelling).

2.1.3 Open Model Initiative (OMI)

The Open Model Initiative Laboratory (OMILab10) is a physical and virtual environment that enables a) the collaborative and remote use of the OMI modelling prototype through RDP connections and b) the agile evolution of the modelling method in the project afterlife, as new knowledge or requirements emerge from the application domain. For a) it hosts the prototype that is accessible for OMI members through RDP connections; for b) it provides conceptual framework and documentation, as well as auxiliary services (e.g. for model publishing, dissemination through OMTV etc.).

2.2 Business Process Execution & Mobile Collaboration

2.2.1 Android

Android is the market leader in mobile ecosystems. Designing for the platform guarantees a wide outreach and enables early adoption in relevant fields of application (process industries, manufacturing, mobile maintenance). As Android is the leading mobile ecosystem, a multitude of different device types are available. These devices feature hardware configurations that can be used in industrial environments (RFID/NFC sensors, rugged cases, various display sizes, etc…), as well as business environments. Thus, business processes that span vertically across the organisational levels of a company can be executed on the same mobile platform.

1 http://www.adoxx.org/live/home 2 http://www.metacase.com/products.html 3 http://www.eclipse.org/modeling/emf/

4 http://www.adonis-community.com/ 5 http://www.uml.org/

6 doi:10.1145/320434.320440 7 http://e3value.few.vu.nl/ 8 http://www.sei.cmu.edu/reports/90tr021.pdf 9 https://supply-chain.org/ 10 http://omilab.org




2.2.2 Python (rdflib)

Python is an efficient, fast and flexible programming language especially suited for prototype development and adoption of cutting edge technologies. With the library rdflib11 there is an add-on available for python that leverages the power of RDF, Linked Data and SPARQL. It integrates extremely convenient ways of acquiring, storing and interacting with Linked Data programmatically. It is an enabler for rapid prototyping and creative forward programming of innovative tools for manipulating triple based information as embraced by the ComVantage framework.

2.3 Data Integration

2.3.1 URI

Resource identification is a key aspect of the World Wide Web and the related Linked Data paradigm. The common standard for resource identification and addressing in the web is Uniform Resource Identifier (URI). An URI is represented as a string and has certain syntax including a scheme, a hierarchical part and optionally a query part and a fragment part. A best practice within the semantic web is to use HTTP URIs which uses Hypertext transfer Protocol as a scheme. URIs can address abstract or real resources. An abstract resource is used to address things from the real world (a person for instance) whereas a real resource can be a document, a file or an image stored in the web. Within ComVantage both types are used.

A key feature to URIs, especially in the Linked Data context, is the dereferenceability which means that a resource – or its representation – is directly accessible in the web. However, this feature is not always realised since it requests additional effort for publishing data. Therefore, also undereferenceable URIs do exist.

Example: http://dbpedia.org/resource/Lyocell

In ComVantage, URIs are used to define entities within the uniform meta model.

2.3.2 RDF

The Resource Description Framework (RDF) is a standard by the W3C for formal description of logical statements about resources (World Wide Web Consortium, 2004).

The framework contains specifications about

data models (e.g. Triples, Named Graphs),

data formats (e.g. Turtle, JSON) and

vocabularies (rdf and rdf/s).

2.3.2.1 Triple-based Data Model

RDF uses a triple-based data model to express not only key value relations but also the meaning of the relation between key and value. Each triple represents an elementary statement and is represented by the three fields: subject (S), predicate (P) and object (O).

11 https://github.com/RDFLib




Example:

@PREXIX dat: http://www.comvantage.eu/data# .

@PREXIX shop: http://www.comvantage.eu/shop# .

[S] [P] [O]

Data property <dat:Order001> <shop:id> ‘10020120802’

Object property <dat:Order001> <shop:hasItem> <dat:Item001>

The example above describes, that the current instance of an order has the id ‘10020120802’ and has an assigned item Item001. While the subject and the predicate must be always defined by an URI (see section 2.3.1), the object can be an URI or a literal. A URI always refers to another resource (and mostly to further information as well) whereas a literal does not but only represent a simple data type (e.g. string, integer, date). In case the object is represented as a literal, the relation is called a data property. In case the object is represented as an URI, the relation is called an object property and the data triple refers to more information since the URI of the object can be the subject of other data triples again. In order to shorten and simplify notations as well structuring complex data sets, namespaces can be used. They are defined by the @prefix command and can be used for each entity of the triple statement as shown in the example above. Please refer to deliverable D4.1.1 (Data format specification) for more details about RDF.

In ComVantage, the RDF-based meta model and standard vocabulary are enablers for the model serialisation vocabulary employed for exporting diagrammatic models as Linked Data. Furthermore, RDF is the foundational concept for the meta models that enables the data harmonisation across distributed data sources and organisations.

2.3.2.2 Named Graphs

Named Graphs extend the Resource Description Framework by allowing to add a fourth element to every statement. This fourth element is a further URI which is used to collect a set of triples into a so called Named Graph. This Named Graph can be identified via its URI and can also be used in SPARQL queries via the GRAPH keyword. This way it is possible to separate information into different datasets in a triple store by using Named Graphs.

2.3.2.3 Turtle

The Terse RDF Triple Language (Turtle)12 is one serialisation of RDF besides many others. It was mainly provided by David Beckett and Tim Berners-Lee and has the advantage that it is very easy to read for humans but also widely supported by different tools in the Semantic Web environment. Furthermore, it is also a very compact serialisation with supports abbreviations for URIs (via prefixes), abbreviations for groups of triples, common data types and RDF collections. Thus, a Turtle file is much smaller than a RDF/XML file while offering more possibilities as its predecessor N-Triples. The media type of Turtle is text/turtle and the content is always encoded as UTF-8. Thus, it supports internationalised strings as well.

2.3.2.4 JSON

JavaScript Object Notation (JSON) is a subset of the ECMA standard (ECMA, 1999) and is used as data exchange format to serialise text and application data. JSON offers a more efficient data representation than XML because it uses a smaller amount of signs. Furthermore JSON and its objects are closer to the used programming language and offer a good tool support.

12 http://www.w3.org/TeamSubmission/turtle/




Example:

{employees:[

{

name:”John Doe”,

role=”Technician”,

id=”51002”,

phone=”035161124811”

},

{

name:”Max Payne”,

role=”First Level Support”,

id=”48339”,

phone=”035161125113”

}

]}

2.3.2.5 Vocabularies

The term vocabulary is often used in the same context as ontologies. However, while vocabularies represent an agreed and standardised set of terms to describe things in the real world, an ontology is a more complex and formal collection of entities and their interrelation. Vocabularies are important to ensure interoperability of systems operating on machine-understandable data like Linked Data as they base on the same interpretation and semantics. Vocabularies are collections of classes and properties. In Linked Data, they are expressed in RDF using terms from RDFS and OWL (Bizer, Heath, Berners-Lee, 2009) and other ontologies. Classes and properties in vocabularies can be linked to other vocabularies in order to create mappings between related entities. Reusing already modelled knowledge from existing RDF vocabularies like FOAF13, SIOC14, SKOS15, vCard16, Dublin Core17, OAI-ORE18 or Good Relations19 will reduce effort of term definition and increase reusability of ontologies

Please refer to deliverable D4.1.1 (Data format specification) to learn more about ontologies, vocabularies and their application in ComVantage. The deliverable D4.1.3 (Data format specification) provides an overview about all ontologies that are developed in ComVantage.

2.3.3 Linked Data

Linked Data is a set of principles that address how to apply semantic web technologies in a useful way (Berners-Lee, 2006). It utilises the advantages of RDF and represents a de-facto standard of publishing and connecting structured data in the web. The following four principles are defined:

1. Use URIs as identifier for things

2. Use HTTP URIs so that people and user agents can look up those names.

3. When a URI is dereferenced, provide useful information, using the standards (RDF, SPARQL)

13 http://xmlns.com/foaf/spec/ 14

http://rdfs.org/sioc/spec/ 15 http://www.w3.org/2004/02/skos/ 16 http://www.imc.org/pdi/ 17 http://dublincore.org/ 18 http://www.openarchives.org/ore/ 19 http://purl.org/goodrelations/




4. Include links to other URIs so that they can discover related information.

The following example from the ComVantage Mobile Maintenance application area describes interlinking capabilities of RDF and Linked Data. Machine01 has an assigned report ServiceReport01. By moving the object to the subject position, we can make further statements about the ServiceReport01, for instance about the assigned author. The prefix “rppm” (Repair, Preventive and Predictive Maintenance) is referencing the vocabulary, where the used properties are defined. The prefix “mma” (Mobile Maintenance) is referencing the data set of the Individuals (instance data in the context of RDF).

@PREFIX mma: http://www.comvantage.eu/dataset/mma/ .

@PREFIX rppm: http://www.comvantage.eu/ontologies/mma/rppm/ .

[S] [P] [O]

<mma:Machine01> <rppm:hasReport> <mma:ServiceReport01>

<mma:ServiceReport01> <rppm:hasAuthor> <mma:ServiceTechnician01>

Extended capabilities for interlinking data and datasets are provided by modelling languages like OWL and RDFS, which are offered as ontologies to support the creation of Linked Data. These are used especially to describe relations between entities in the Linked Data web. If a new entity A is exactly identical with an already existing one B, this can be expressed with the triple A owl:sameAs B. For other relations, one uses an appropriate predicate: e.g. if A is a special kind of B, one can say: A rdfs:subClassOf B. If there is no appropriate predicate, but one still wishes to include a relation, on can use the rdfs:seeAlso predicate. This makes it possible to interlink data between different data sets of companies or between a company and a public source.

An example from the ComVantage Mobile Maintenance application area is shown below. It uses the syntax of RDFS and OWL vocabulary and entities from custom ComVantage vocabulary “rppm” as well as data sets “mma” and “mop” (Maintenance Operations). The first statement describes that the WaterPump01 from the “mma” data set is the same physical entity as the Machine04 defined in the “mop” data set. The second statement describes that the concept ServiceTechnician is a sub-class of the concept Employee. This means that all Service Technicians are also Employees at the same time. However, not all Employees are also Service Technicans.

@PREFIX owl: http://www.w3.org/2002/07/owl# .

@PREFIX rdfs: http://www.w3.org/2000/01/rdf-schema# .

@PREFIX mma: http://www.comvantage.eu/dataset/mma/ .

@PREFIX mop: http://www.comvantage.eu/dataset/mop/ .

@PREFIX rppm: http://www.comvantage.eu/ontologies/mma/rppm/ .

[S]

[P] [O]

<mma:WaterPump01> <owl:sameAs> <mop:Machine04>

<rppm:ServiceTechnician> <rdfs:subClassOf> <rppm:Employee>

In ComVantage, the Linked Data design principles for RDF are used for the meta model that is the result of the semantic data harmonisation. Furthermore, a couple of existing RDF and Linked Data specific tools and frameworks are used to complete the ComVantage tool chain. Triple stores are used for persisting semantic information whereas D2R is used to transform/enrich relational data (from databases) to semantic data. Both are explained in the following. For connecting machine middleware systems and complex enterprise systems (e.g. ERP), no existing tools or frameworks could be used. They have been created in the ComVantage project (refer to section 3.1.4).




2.3.3.1 Triple Stores / Graph Stores

Triple stores (or graph stores) are an alternative approach to relational databases leveraging a schema-less approach to store data. They are highly adapted to the RDF data model (refer to section 2.3.2) and are designed to store information in the form of data triples. A data triple expresses information as statements (refer to section 2.3.2.1). Most triple stores are able to store data into Named Graphs (refer to section 2.3.2.2) which adds a further dimension to the data model.

In ComVantage, triple stores are used to persist semantic data that is not derived from backend/enterprise systems. Furthermore triple stores capable of handling N-quads can be used for persistent storage of the business process models exported as Linked Data.

2.3.3.2 D2R

D2R (Bizer, Cyganiak, 2006, see Figure 1) allows for publishing content of relational databases on the semantic web by mapping it to RDF and offering a SPARQL endpoint. It uses a declarative mapping that specifies how resources are identified and how property values are generated from database content. Incoming SPARQL requests are rewritten to local SQL commands. The results are lifted to RDF and are mapped to a given domain schema. The mapping is modelled as RDF in the D2RQ mapping language. First of all, absolute URIs are automatically created using a generated vocabulary. This enables the server to answer HTTP request about this URIs as they are dereferenceable. Later on, the mappings to the automatically generated vocabulary can be manually replaced by known vocabularies in order to match a specific domain model.

D2R features an acceptable performance by supporting on-demand querying with reasonable response time. An exemplary implementation of a D2R-based business software adapter is presented in the ComVantage deliverable D4.3.3 (Business and engineering software adapter, confidential).

Figure 1: D2R architecture (D2R, 2012)

2.3.4 SPARQL

SPARQL (SPARQL Protocol And RDF Query Language) is a graph-based query language for data stored in RDF (World Wide Web Consortium, 2008). The usage and syntax is similar to SQL but adapted to specific aspects of semantic data (see also section 2.3.2 about RDF).




Example:

PREFIX shop: <http://www.comvantage.eu/shop#>

PREFIX garment: <http://www.comvantage.eu/garment#>

SELECT ?lorder ?lstate ?ltask

WHERE {

?order a <shop:Order>.

?order <shop:id> ?lorder.

?order <shop:hasCart> ?cart .

?cart <shop:hasItem> ?item .

?item <shop:isInTask> ?task .

?task <garment:description> ?ltask .

?item <shop:hasStatus> ?state .

?state <garment:description> ?lstate .

}

The example above represents a query for all orders in the system, including their current state and current active task. There are many frameworks that already support developers to execute SPARQL queries and offer SPARQL endpoints on top of existing semantic data sources. The most popular ones are Sesame (Sesame, 2012) and Jena (Jena, 2012).

In ComVantage, SPARQL is used to perform all queries and updates of semantic data. Only for time-critical live data access, a direct HTTP REST access is realised (e.g. for live senor values).

Please refer to deliverable D4.1.1 (Data format specification) for more details about the application of SPARQL.

2.4 User Authentication and Authorisation

2.4.1 SAML

The Security Assertion Markup Language (SAML), developed by the Security Services Technical Committee of OASIS, is an XML-based framework for communicating user authentication, entitlement, and attribute information. This OASIS standard defines both an XML schema for security assertions and protocols to exchange these assertions. SAML allows business entities to make assertions regarding the identity, attributes and entitlements of a subject to other entities, such as a partner company or another enterprise application. An assertion contains one or more statements. An attribute statement contains attributes of a user such as roles of this user, in this case, the global role of the user.

2.4.2 XACML

2.4.2.1 XACML-Based Security Component

In ComVantage, the collaborative system partners share data as linked data (vocabularies). This data encode information that should be accessed and manipulated by the participating partners. By consequence, the permitted and denied accesses to this data should be controlled. The ComVantage approach proposes a XACML-based authorisation component to deal with the multi-domain access control issues. This latter, is based on Role-Based Access Control model proposed by NIST (Sandhu et. al 2000), and the XACML standard proposed by OASIS (Lockhart et. al 2011). The developed XACML-component enables the access control policies to resources expressed as URI. Moreover, the management of access control policies is performed by using the proposed Policy Administration Point. These policies are then evaluated




by the PDP (Policy Decision Point) against the XACML request. The Component provides an API to facilitate the access control requests and to hide some XACML complexities.

2.4.2.2 XACML

XACML acronym for (eXtensible Access Control Markup Language) is an access control standard based on XML language proposed by OASIS (Lockhart et. al 2011). XACML aim at representing authorisation policies, authorisation request and response. The standard XACML proposes a list of combining algorithms for evaluation authorisation policies. The XACML architecture depicted on the figure 1 is based on the following component PAP, PDP, PEP and PIP.

Figure 2 : Architecture XACML

The PAP (Policy Administration Point) is the component where the access control policies are defined. The PDP (Policy Decision Point) is the component that evaluates the access requests against the XACML policies. A PEP (Policy Enforcement Point) submits access requests to the PDP, and applies the decision (PERMIT/DENY). In some cases a policy refers to an attribute whose value is not included in the request sent by the PEP. The PIP (Policy Information Point) provides some of the missing attributes. For deep information about XACML, please refer to (Lockhart et. al 2011)




3 COMVANTAGE REFERENCE ARCHITECTURE FOR VIRTUAL ENTERPRISES

3.1 Key Concepts and Recommendations

3.1.1 Decentralised Approach

By definition of (Barnett, et al. 1994), a virtual enterprise is based on a temporary alliance of several businesses. It takes advantage of a market opportunity and dissolves, when it has passed. A virtual enterprise does not have own major resources but it consists of the resources and core competencies of its individual partners. Due to the distributed and decentralised characteristic of a virtual enterprise, there would be no chance to organise the management of central components neither from a legal nor from an organisational point of view (e.g common meta models or application servers). According to this, centralised components need to be avoided in the architecture. A main reason for this requirement is the fact that even in a heterogeneous and distributed collaboration environment, companies want to continue running their legacy systems and want to keep full control of their valuable enterprise data. The fully decentralised approach proposed by ComVantage is totally in line with these business-critical requirements. It proposes a separation into Domains where a domain can be operated by an individual partner or can be shared among a couple of partners (e.g. by a Joint Venture). This characteristic provides full scalability and satisfies the different needs of large and micro enterprises. Referring to the setup outlined in Figure 3, a customer factory (partner A) and a service company (partner B) of the collaboration network are running their dedicated IT-infrastructure (domain A and B). However, micro companies will not be able to run their own IT-infrastructure regarding their limited financial and personnel resources. The scalability of the approach allows micro companies to participate in a shared infrastructure that is offered by a 3rd party provider. This 3rd party provider can either be a major partner of the network with a special interest to involve micro companies or a commercial hosting offer. Running a shared infrastructure requires micro companies to agree on meta model definitions and to share the administration of access control policies. Due to the limited complexity of micro businesses, this is manageable with acceptable effort. As a result, micro companies can reduce efforts and costs related with running and maintaining their own IT-infrastructure.

The decentralised characteristic of the approach is complemented with a single point of access paradigm for each domain. It offers a uniform interface with respect to data format, meta model and communication protocol for heterogeneous data sources connected in the particular domain. The interface can be consumed in an uniform way and therefore reduces complexity of front end development for each collaboration partner (e.g. facilitates reuse of applications). In ComVantage we decided to use a semantic approach leveraging the advantages of RDF, Linked Data, ontologies and SPARQL. RDF (refer to section 2.3.2) is used as uniform data format based on the Linked Data design principles (refer to section 2.3.3). Ontologies are used as meta models and SPARQL represents the uniform interface protocol. The single point of access is provided for each domain as part of the Domain Access Server (refer to Figure 3). Furthermore, the interface is accompanied with access control mechanisms which are described in section 0. The Domain Access Server takes care of distributing all requests to the connected data sources within this particular domain. Moreover it merges all results to a combined result set and eliminates duplicates for instance.

Additionally, the interface offers a non-SPARQL channel for middleware commands. These commands are time-critical (especially in the case of live data access to sensors) and the SPARQL overhead is omitted on the request side. However, results are as well provided as Linked Data.




Figure 3: Exemplary setup of a virtual enterprise with two collaboration partners sharing distributed data sources and business processes along a common end-to-end product value chain

The presented decentralised approach is furthermore characterised by the execution of interlinked business processes to realise an end-to-end cross-domain product value chain. Especially in the manufacturing industry, product value chains are very complex. On the other side, the personnel on the shop floor needs intuitive and usable mobile IT support. ComVantage has developed the Industrial App Framework that leverages intuitive single purpose apps. A pool of Generic Apps with verified usability can be used to accelerate the user interface development. These Generic Apps can be adapted to specific use cases and can be orchestrated to App Ensembles based on a business process model. Furthermore, the App Ensembles are interlinked across domains via the Domain Access Server of each collaboration partner.

3.1.2 Model-driven Operation

In order to achieve a high flexibility and maintainability of all components from the ComVantage approach, the consortium focused on model-driven development and an appropriate design-time tool chain in many areas:

Access control models (role models, access control policies, SPARUL template definitions)

Data models (Ontologies and vocabularies as meta models)

Business Process Models




3.1.2.1 Access Control Models

With respect to user authentication and user authorisation, a couple of design-time specifications need to be provided. First, a role model needs to be defined which defines all user roles for all stakeholders and collaboration partners that are part of the virtual enterprise. The role model is deployed into a LDAP user repository and is queried by an Identity Provider (IdP) to check and obtain users credentials (roles). A user could have more than one role and only the ComVantage roles are going to be retrieved, but it is possible to retrieve any other user attribute required.

Second, policies for user authorisation need to be created. These policies are used to create data views for logical separation of data for different roles. The creation of the data views is supported by the use of named graphs and the assignment of access rights over them. These named graphs could be created specifically for this purpose, or it is also possible to reuse existing named graphs. Regarding the access rights, they could be defined using two different predicates, canSee or canUse, depending if the role needs to see (obtain) the information or if the role only needs to use the information in a constraint of the SPARQL statement to match or limit the results. The policies definition should be done after a deep analysis of which information needs to be seen or used by each of the roles, or just analysing each of the SPARQL statements to be launched against the original data.

For example, analysing the query above, it is possible to write a single SPARUL statement to define the required policy, as it is shown in the next code sample.

PREFIX ns: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX tee: <http://www.comvantage.eu/ontologies/mma/tee/>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?uri ?title

WHERE {

?uri ns:type tee:ReportTemplate .

?uri rdfs:label ?title .

?uri tee:hasFunctionType (x) .

}

# (x) is a parameter filled by the application that launch the query




This policy stores all possible triples that could be required by the SPARQL statement in a named graph called acd:cv_role_engineer_canSee and give canSee rights over it for the role acd:cv_role_engineer.

Third, SPARUL templates need to be defined. They are used as prepared statements for securing data update operations. They also could have one or more actions associated with each template if it is required to update any AC view. These actions are SPARQL/SPARUL statements. The templates and the actions could have gaps to be filled identified by a name and a type; the available types are IRI and LITERAL.

The previous code sample is a template example with four parameters (templateId, reported, deviceId and deviceUri), where two of them are typed as IRIs and the other two as LITERALs. This template should have at least one associated action which will insert the same triples into the required access control views.




PREFIX ac: <http://www.comvantage.eu/ontologies/ac-schema/>

PREFIX acd: <http://www.comvantage.eu/instances/>

INSERT {

GRAPH acd:cv_role_engineer_canSee {



?uri tee:hasFunctionType ?x

}

GRAPH acd:cv_permissions {

ac:cv_role_engineer ac:canSee acd:cv_role_engineer_canSee

}

}

WHERE {



?uri tee:hasFunctionType ?x

}




PREFIX report: <http://eu/comvantage/kua/dhm/kua001/testreport/>

INSERT {

report:id ns:type tee:Report .

report:id tee:hasTemplate $(templateId,iri) .

report:id tee:ReportId $(reportId,literal) .

report:id tee:hasDevice $(deviceId,literal) .

$(deviceId,literal) tee:hasUri $(deviceUri,iri).

}




3.1.2.2 Data Models

The collaboration approach of ComVantage requires for data harmonisation. The core of the semantic data harmonisation approach used in ComVantage are RDF-based meta models. These meta models are following the Linked Data design principles and are developed as OWL ontologies. These ontologies are used to extract and harmonise data from heterogeneous and distributed data sources from all collaboration partners. A specification of the used methodology and the developed meta models can be found in the deliverable D4.1.3 (Data format specification). Unfortunately, ontology engineering is not easily applicable to micro companies. We envision a process that explicitly omits the complexity of developing ontologies from scratch for each partner. Micro companies should be able to join a collaboration network by simply adapting existing ontologies. ComVantage participated in the prototypical development of a proof of concept named OntoSketch that facilitates ontology engineering by offering support for ontology extension based on existing ontologies from collaboration partners and public communities (refer to Figure 4). It allows the user to import existing ontologies, browse and filter their contents, and extend them with new concepts. The UI provides assistance to make ontology engineering also applicable to non-expert users. A detailed description of the tool is documented in deliverable D4.1.3 (Data Format Specification) and D4.4.2 (Linked Data support tool set) whereas deliverable D4.5 (Linked Data best practises) contains the best practises of OntoSketch.

Figure 4: Data modelling using the ontology extension approach and the proof-of-concept tool OntoSketch

3.1.2.3 Business Process Models

The business process modelling method designed in ComVantage is a multi-layered hybrid modelling method having business processes in the center, semantically enriched with additional facets such as process motivators (abstract values, KPIs) and requirements for support assets (apps, information assets, sensors, robots) or liable participants (roles, business or individual entities). A model serialisation bridge enables the export of information captured in models to the Linked Data cloud, so that process-aware




components can further make use of this information to change or control their behavior. The Industrial App Framework (and its resulting App Ensembles) is a proof-of-concept for such process-awareness; however, other components or even run-time apps could be developed in a way that benefits from reading model information.

Thus, the conceptual layers of the modelling workbench stack are here split in two categories (Figure 5):

The low levels focus on process execution requirements for the technological specificity of ComVantage (mobile apps). The model types pertaining to these levels (e.g. diagrammatic orchestration models, business process models, organisational models) are direct input for app development and the IAF component, hence they provide the direct bridge to the run-time architecture.

The high levels focus on a multi-layered decomposition of the business view (starting from the business model and domain specific resources types) down to the level of process execution requirements addressed by the low levels. The model types pertaining to these levels are focused on design-time business analysis and on identifying requirements gaps, thus they are of secondary relevance to the run-time components;

The high levels are connected to the low levels through semantic links that are navigable and query-able, thus making app requirements traceable across the multiple layers (e.g. to identify what motivates the presence of a requirement for a specific app component). To enable this, all levels should be model-able in the same tool.

Figure 5: Positioning the modelling method in the ComVantage architecture

The multiple layers of the modelling stack are organised around a framework established in the modelling method specification deliverable (D3.1.2), and its core layers are displayed in Table 1. Additional layers (high levels) have been described (in deliverable D6.2.2, D7.2.2, D8.2.2) in order to cover domain specificities of the ComVantage application areas.




Aspect Scope

Behavioural Structural Procedural Collaborative Motivator focus Participant focus

Business (high level)

Value exchange flow

Business model

Value structure

Market and Business structure

Enterprise (high level)

Business process Participant

collaboration Enterprise structure

Evaluation (high level)

Evaluation process Participant

collaboration KPI structure

Enterprise structure and

Information space

Requirements (low level)

Requirements process

Participant collaboration

Asset structure

App development (low level)

Interaction flow Navigation model Mobile support

structure

App execution set-up

(low level) Orchestration

Notification exchange

Mobile support structure

Table 1: Conceptual levels (scopes) and facets (aspects) of the modelling method

3.1.3 Semantic Data Harmonisation

In ComVantage semantic data harmonisation is used to leverage relations between data of distributed sources. Data harmonisation is realised by transforming information to a uniform data format and meta model without affecting the original data sources. The transformation need to be specified for each data source individually by software components. They are described in more detail in section 3.1.4.

ComVantage leverages RDF and the Linked Data design principles as uniform data format and ontologies as meta models. A major prerequisite for semantic data harmonisation is the availability of meta model definitions. Due to the necessity of a fully decentralised architecture (refer to section 3.1.1), the definition of a central meta model that is commonly used by all collaboration partners is no option. In fact, all collaboration partners should have the possibility to define their own meta models. Hu et al. outline that enterprise data is barely using semantic technologies (Hu, Svensson, 2010) and that only a few application domains are well covered with existing ontologies. Our meta models build upon existing ontologies (and including vocabularies) to the maximal extend and define new terms that are nowhere modelled yet. Details about the ComVantage ontologies are reported in deliverable D4.1.3 (Data Format Specification)

In order to allow cross-domain collaboration, a mapping between meta models of different domains (of different collaboration stakeholders) is necessary. These mappings need to be derived at design-time. Finding different ontology entities that refer to the same real-world object or finding relations between ontology entities is an important task for which (semi-) automation is important. The Silk tool20 was developed for this purpose. In ComVantage, we employ this tool in a use case from the Customer-oriented Production application area, where the goal is to find possible replacements for shirt parts, in particular zippers (see D7.3.2 for details).

The Silk syntax for defining rules is powerful: there is a large arsenal of conversion functions for numbers (e.g. arithmetic functions, removal of non-numeric characters) and strings (conversion to lower case, substrings, removal of prefixes) as well as comparison functions (Levenshtein distance, Jaro-Winkler, temporal or geographical distance). In order to aggregate the results of several comparisons into a single

20 http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/




numerical score, there are aggregate functions like maximum or weighted average. This makes the tool usable for a wide range of application scenarios.

These features can be accessed via a GUI that allows for dragging and dropping the different functions (see Figure 6), which makes it very easy to develop, verify and modify rules.

Figure 6: Silk User Interface

The single point of access that is provided for each domain (for each collaboration partner) uses a uniform interface technology to facilitate cross-domain interaction of client applications. The interface implements the SPARQL 1.1 standard (World Wide Web Consortium, 2008) and allows for reading and updating data.

3.1.4 Integration of Data Sources and Legacy Systems

Integration of heterogeneous data sources is crucial to data harmonisation. The ComVantage approach realises data integration based on Linked Data Adapters. These adapters are provided for several technologies that are most common in manufacturing environments and perform the mapping of syntactic information from the data sources to Linked Data based on meta models provided as ontology.

The following Linked Data adapters are part of the ComVantage framework:

D2R: integration of relational databases XLWrap: integration of spreadsheets DHM: integration of machine data based on GAMMA and OPC-UA middleware systems OData-LD: integration of enterprise systems that offer an OData interface.




The basic principle of transforming data to Linked Data will be explained on the example of D2R in the following:

The Linked Data adapter for databases is based on the open source project D2RQ (refer to 2.3.3.2). The adapter translates SPARQL queries to SQL and returns results based on a domain-specific mapping. While the mapping is defined at design-time, the content is lifted to RDF on demand at run-time which avoids the problem of keeping redundant data in sync. Since the database doesn’t contain the semantic information that is required for this transformation, it is provided in a mapping file. This allows the user to define for specific database tables how to derive a URI for an RDF individual from a specific entry, which classes this individual is an instance of, and which other individuals it is related to. In detail, the adapter works as the following: First, database entities are mapped to OWL individuals which represent semantic instance data. Second, the individuals are assigned to appropriate classes (from a specific semantic vocabulary). Third, the foreign key relations of each row are mapped to RDF object properties. Finally, all the other values are mapped to RDF data properties. Figure 7 shows an example from the application area Customer-oriented Production. The used MySQL database contains data about customers and orders from a webshop. The entity of the highlighted customer is mapped to an OWL individual and is now represented by an URI (“http://....customer/21”). Moreover, this entity is assigned to a specific class (rdf:type = cvshop:Customer). The foreign key relation of the customers address is mapped to an object property and refers to another URI (is cvshop:addressOf <http://....shipping/21>). Finally, all other values like name are mapped to literals (strings and integers) without any further relations. As already mentioned beforehand, the RDF representation of the data is nonpermanent whereas the database contents are permanent.

Figure 7: Example of the Linked Data adapter for databases from the application area Customer-oriented Production (WP7)

Based on the example from Figure 7, Figure 8 visualises the transformation from a relational data model (as used in a relational database) to a graph-based data model as used from Linked Data. While the relational data model uses rich entity representations and value-based foreign key relations, the graph model is based on atomic entity representations (nodes) and semantic relations in between (edges).




Figure 8: Transformation from relational data model (top) to graph-based model (bottom) and its serialised representation as RDF (middle)

The Linked Data adapters are provided as generic components which are configured with the meta models of the particular domain in order to connect to a specific data source (e.g. a customer database of a collaboration partner). Using adapters offers the advantage of integrating legacy systems without modifications. Hence, the ComVantage approach can be used on top of an existing IT infrastructure and in parallel to already existing business applications.

A complete overview of developed adapters is documented in the deliverables D4.2.3 (Middleware adapter set) and D4.3.3 (Business and engineering software adapter). Furthermore, an additional adapter for complex enterprise systems (e.g. ERP) was developed. It leverages the standardised OData21 interface to avoid customisation for specific proprietary interfaces. The OData – LD adapter is documented in deliverable D4.5 (Linked Data best practices).

3.1.5 User Authentication and Authorisation

Collaboration between different organisations can only be successful if partners can trust each other. Thus, ensuring that Linked Data information from heterogeneous nature (structured, non-structured, real-time, non real-time) remains secure and only accessible to authorised members is a crucial issue. However, within a collaboration environment decision-making is profoundly different from centrally coordinated collaboration. Relying on forming a single domain of trust is no real guarantee that other partners will have as agreed in the future. In this decentralised context a sophisticated dynamic access control model needs to

21 http://www.odata.org/




be defined, which enables policy negotiation, establishment, management, monitoring and enforcement for a multi-domain access to Linked Data sources. Additionally, the mechanism should be also simple enough, so that information security enforcement does not refrain SMEs to engage in collaboration and trust is not conditioned by the nature of the enterprises comprising the collaboration network.

ComVantage security model needs to define controls for:

(1) Linked Data Units (LDU, single RDF triples), which are built assigning control policies to data objects,

(2) Linked Data Sets (LDS), which aggregate LDU within a domain and specific access control policies and

(3) Linked Data Networks (LDN), which are created across domains based on agreements among companies to collaborate in the execution of a particular project.

For that purpose, an authentication process based on SAML (Online community for the Security Assertion Markup Language, 2013) identity federation and security credentials interchange is performed in the first place. The ComVantage cross-domain authentication framework developed consists of the following components: (1) Identity Provider (IdP): the element including a LDAP repository where users’ credentials/attributes are stored. It also works as a STS (Security Token Service), responsible for issuing security tokens, (2) Service Provider (SP): the element responsible for protecting the resource/application. It takes the authorisation decisions and acts as the Policy Enforcement Point (PEP), (3) Mobile/Application Client: the element that requires access to the information of the resource stored in SP, on behalf of the User-Client.

Afterwards, a multi-tiered authorisation process takes place to provide multi-domain access control for Linked Data at two levels:

(1) The Domain Access Server is in charge of rewriting the SPARQL query received by adding control checks so that the resulting query will just work with the information related with the roles that the requester belongs to.

(2) Execution of queries on data sources in a controlled manner. This part of the security approach is based on an intelligent structuring of information in access control graphs (also called views) for each domain, which enables the implementation of delegated access controls based on ad-hoc yet traceable information sharing.

The query rewriting process works as follows: During runtime, the SPARQL queries are rewritten so as to retrieve just the information associated with the views the requester have access to. This access depends on its role, which will be determined by a prior authentication mechanism as described previously in this section. During the query resolution process, the access will be limited just to the information that has been collected in any view related with the role of the requester. The rewritten query will be executed on the endpoint where the views had been published out of band. Just the information related to the views that the requester is able to see or use will be returned.

Furthermore, data updates are controlled by the approach. The SPARUL Composer implements a concept based on prepared statements to avoid security leaks. Application developers can create such predefined SPARUL statements and store them in the DAS. The application sends an update request by providing the relevant SPARUL statement id and the parameters to be inserted. Furthermore, additional actions are assigned to each SPARUL statement to keep the derived views in sync.

Additionally, to the Linked Data and RDF-oriented authorisation components, an XACML-based authorisation was developed and deployed on the DAS server. This component ensures the authorisation to Linked Data by means of the ComVantage defined roles. Concretely, the authorisations are role-based statements that express which role is denied or permitted to perform which action on which resource. These authorisation concepts are expressed as URIs. As a consequence, this component represents a powerful tool for securing the access to Linked Data in multi-domain environment such as ComVantage.

Figure 9 shows in green the different security components within the global ComVantage architecture:




Figure 9: ComVantage secure framework

More detailed information about the security concept is documented in the deliverable D3.2.2 (ComVantage secure information model definition).

3.1.6 Orchestration of Mobile Workflows

The target of the process interoperability dimension is the support of executing complex workflows across organisational boundaries. In ComVantage we have decided in favour of a model driven development approach for applications. Relevant model types and modelling tools are developed within the project (refer to section 3.1.2 for details).

ComVantage provide a workflow modelling workbench oriented towards business stakeholders within the design-time dimension of the architecture. A hybrid modelling method has been designed under the framework presented in (Karagiannis et. al, 2002) to capture collaboration and mobile app requirements on multiple levels of abstraction (a specification is available in deliverable D3.1.2, Specification of modelling method including conceptualisation outline). The modelling procedure recommends that each business process is first designed in a business view (with a “one responsible/activity” granularity), then extended to a technical view (with a “one required app/activity” granularity, to support the orchestration detailed in the next section). Figure 10 introduces some modelling patterns from the ComVantage modelling method.

Pattern1: Delegation or transfer of control. BPMN relies on explicit “throw and catch” messaging events between two activities. Our approach implies it with “subsequent” arrows shifting control between different roles (swim lanes). By convention, any activity initiating a cross-swim lane arrow can be considered a “notifying activity”.

Pattern2: Waiting to get results after delegation/transfer. BPMN relies on a sequence of activities on the same swim lane that is interrupted by throwing and catching messages. Our approach implies this with a lack of subsequent arrows continuing on the same swim lane.

Pattern3: Delegation/transfer followed by parallel work. BPMN relies again on messaging to initiate a parallel flow in the partner company and to resynchronise with its results after the parallel work is finished. Our approach uses a parallelism split to distribute work between the two swim lanes, and a corresponding join to indicate where work must be synched back together.




Figure 10: ComVantage modelling patterns

Additional semantics are given by links to related models (of other types), and can be explicitly serialised through an export mechanism as N-quads (Bizer et. al, 2013) to enable querying outside the modelling tool. For purposes of mobile app development, the most relevant links are the ones from activities (in business process models) to roles and app features (in a resource pool model), for example (prefixes omitted for brevity):

:A1 a :Activity;

:lane :Company1;

:mobilesupport :Notifying_feature.

:Arrow1 :from :A1; :to :A2.

The first part of the statement above assures that the assignment between activities and swim lanes is not only a visual indication, but also an RDF relation that can be queried in order to detect the discussed patterns for further processing (for example, to assign mobile app skeletons based on them). The second part captures a link between the activity and an app feature required to support it, while the last part captures the process flow. In ComVantage, such serialisations of collaborative business process models are input for an App Orchestration Process (Ziegler et. al, 2012) that outputs an orchestrated ensemble of apps that are executed as dictated by the business flow.

An Industrial App Framework (IAF) is being developed as an implementation of the App Orchestration Concept (refer to deliverable D5.3.3, UI modelling and generation framework). Its goal is to simplify the usage of apps for mobile support of workflows in virtual enterprises.

Figure 11 outlines the App Orchestration Process as it is implemented in the Industrial App Framework. The three main steps (Select, Adapt, Manage) rely on various models as input. An App-Pool contains Generic Apps and formal descriptions that allow automatic selection. Existing models, such as business process models, are used to select the most appropriate Generic App from the pool, adapt them to the context of use, connect to data sources and create a navigation design that resembles the modelled business process (Ziegler et al., 2012). The effort for supporting a workflow on mobile devices is much lower than with state of the art technology. Existing apps with proven usability and consistency can be reused and adapted to context (refer to deliverable D5.3.3, UI modelling and generation framework; as well as to Pfeffer et al., 2012; Urbas et al., 2011) missing apps are created using app templates and style guides (refer to deliverable D5.2.3, UI presentation and workflow models), and existing navigation models can be used to drive the orchestration process. The result is an App Ensemble of Adapted Apps that can be deployed on mobile devices and supports a specific workflow within the virtual enterprise.




Figure 11: The App Orchestration Process of the Industrial App Framework.

Figure 12 shows an exemplary transformation from a business process model to two App Ensembles that can be achieved using the developed IAF (example from the Mobile Maintenance application area). Agile re-orchestration of an App Ensemble becomes possible with minimal reimplementation effort, if the business process and its app feature requirements are adjusted accordingly.

Figure 12: Example for two App Ensembles derived from a business process model.




The App Ensembles as result of the App Orchestration Process are finally being deployed to the mobile devices of the users. The scope of an App Ensemble contains the workflow steps that are being managed from one role/one user for one specific business process (e.g. on-site machine defect localisation of a Service Technician). However, complex workflows require multiple involvements across users, roles and organisations. The Service Technician for instance is involved twice, one time at the beginning for the defect localisation and one time at the end for the result reporting (Figure 12). In between, other roles are involved, for instance to manage the assignment of remote experts to the maintenance operation.

The Industrial App Framework as run-time environment of the App Ensemble supports multiple mechanisms to exchange data between workflow steps or to trigger them. First, an Intent-based approach is used to exchange data between apps of an App Ensemble or to trigger the next app in the same App Ensemble. Second, data is exchanged via the Linked Data cloud between App Ensembles of different users or roles. The Service Technician for instances creates a maintenance request as soon as he spotted a machine defect. This request is added to a list of pending maintenance requests and triggers a workflow for a maintenance coordinator at the service company.

The Generic App Pool (Figure 11) is major component of the App Orchestration Process. It consists of Generic Apps that are created for specific domain and industries. Since these Apps are automatically orchestrated, it has to be ensured that all of them are aligned with regards to visual appearance and behaviour. Otherwise supported business tasks may behave completely different with respect to their look&feel and, thus, has to be avoided. Therefore, these apps are following detailed design guidelines for collaborative mobile UIs. Exemplary guidelines for the manufacturing domain, which is the main target of the ComVantage project, have been presented in deliverable D5.2.3 (UI presentation and workflow models). The presented guidelines are intended to be used by application developers who are contributing to ComVantage’s Generic App Pool to ensure consistent design and behaviour across all Apps within the Generic App Pool. Figure 13 shows example realisation for the so-called Selection Pattern which is a commonly occurring pattern to support business processes. In this case, multiple interaction schemes (single selection, multi-selection, read-only list) are shown and its realisation. It is important to note that the realisation on other target platforms (e.g., iOS) may differ although the concept supporting the respective business process is equal.

Figure 13: Example of Selection Pattern on Android target platform

In D5.2.3, we provide concrete patterns for the Android and iOS platforms based on our conceptual and theoretical patterns from prior work (e.g., D5.2.2). It is argued further that the provided patterns for the considered target platforms are consistent with the technical requirements described above. In this context, the provided concrete patterns may help application developers who are contributing to ComVantage’s central pool of mobile applications to develop more effectively. Moreover, it helps developers to be consistent with the style guides and design guidelines proposed by the target platforms on the one hand and ComVantage’s functional and non-functional requirements on the other hand.




3.2 Architecture Overview

In the following, the explained concepts from the previous section are mapped to the ComVantage architecture and its individual layers are described more detailed.

Figure 14 shows a scenario of multiple mobile applications accessing information of data sources across different partners within a collaboration network. The architecture defines a physical separation between individual partners, called domains. A domain is defined as a self-contained area of responsibility. Each domain contains a set of data sources which are exclusively assigned to it and a set of local access control policies that are defined and managed by the domain owner. All domains within one application scenario build the collaboration network. In the following, a layer concept of the ComVantage architecture is introduced. These layers are replicated within each domain.

Each mobile app has a single purpose (e.g. reporting a maintenance request) and knows the interfaces of all relevant domains (e.g. domains of the customer, the maintenance service provider and machine manufacturer). The workflow logic for cross-domain collaboration is modelled at design-time and is contained in the mobile application (refer to section 3.1.6). Furthermore the app orchestration logic must be contained on the mobile device (as part of the Industrial App Framework) in order to allow interplay of several single purpose apps. Within the ComVantage architecture all applications are grouped in the Application Layer.

Figure 14: Order and alignment of the key concepts with the overall architecture approach of ComVantage and its logical layers

In order to simplify the access to various data sources within one domain and to avoid repetition of necessary domain services like access control, each domain offers a single point of access to all mobile applications. The so called Domain Access Servers have the same structure and functionalities among each

Workflow

App App App

Data Source

Data Source

Data Source

Domain Access Server

Domain Access Server

Domain of Partner A Domain of Partner B

Collaboration Network

Application Layer

Business Process Modelling

Application Orchestration

Domain Source Layer

Integration of Data Sources and Legacy Systems

Data Modelling

Web Layer

Single Point of Access

User Authentication

Data Integration Layer

Semantic Data Harmonisation

User Authorization

Do

main

Co

nfigu

ration

Layer




domain but provide the possibility for a domain-specific configuration within the Domain Configuration Layer (e.g. with respect to registered data sources, prepared statements for SPARUL updates or general operational parameters). The uniform interface for a single point of access within each domain is exposed in the Web Layer of the Domain Access Server (refer to section 3.1.1). Furthermore, this layer is in charge of authenticating the user (refer to section 3.1.5). Requests are forwarded to the Data Integration Layer for direct on demand access to all domain sources. The Data Integration Layer is responsible for request distribution to all relevant data sources that are connected to the host domain. Moreover it enforces the compliance of local access control policies for queries (refer to SPARQL Rewriting, section 3.1.5) and data updates (refer to SPARUL Composer).

The Domain Source Layer represents a RDF-based abstraction layer and contains all domain-specific data sources. Domain sources can be either private or public. Private sources in the ComVantage context are usually enterprise sources while public sources are maintained by open communities (e.g. DBPedia). For enterprise sources, arbitrary technologies and different meta models are supported, which have to be mapped to an ontology of the domain (Domain Data Model). Mappings are defined manually at design-time and are executed by technology-specific Linked Data adapters which are located in the Domain Source Layer as well. For public sources, no mapping is offered. Therefore, only public Linked Data sources are supported. Data sources from a public domain are directly accessed by the mobile applications because no role-specific access control is necessary.




4 CONCLUSION

The integrated architecture presented in this document is a consolidated result of architecture visions from individual generic concept work streams in the ComVantage project, including Secure Information Model (WP3), Business Process Modelling (WP3), Linked Data Integration (WP4) and Trustful Mobile Collaboration (WP5). Whereas the previous documents released in this work package (WP2 – Continuous Requirements Analysis and Overall Architecture) have been detailed explanations of the architecture and the interfaces, this document focusses on explaining key technical concepts that are the results from learning during the 3 years of continuous development.




5 REFERENCES Auer, S., Dietzold, S., Lehmann, J., Hellmann, S., Aumueller, D. (2009) ‘Triplify – Light-Weight Linked Data

Publication from Relational Databases’, WWW 2009 Madrid Barnett, W., Presley, A., Johnson, M. & Liles, D. (1994). An Architecture for the Virtual Enterprise. In the

proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, San Antonio.

Berners-Lee, T. (2006) ‘Linked Data’, http://www.w3.org/DesignIssues/LinkedData.html Bizer, C., Cyganiak, R. (2006) ‘D2R Server – Publishing Relational Databases on the Semantic

Web’, ISWC 2006

Bizer, C., Cyganiak, R., (2013).The TriG syntax, retrieved from http://wifo5-03.informatik.uni-mannheim.de/bizer/trig/

Bizer, C., Heath, T. and Berners-Lee, T. (2009) 'Linked Data - The Story So Far', International Journal

on Semantic Web and Information Systems (IJSWIS), vol. 5, no. 3, pp. 1-22. D2R (2012) http://d2rq.org/ ECMA (1999) ‘Standard ECMA-262’, 3rd Edition Fielding et. al (2012) ‘HTTP Status Code Definitions’, W3C

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Lockhart, H., Parducci, B., Levinson, R. (2011) ‘OASIS eXtensible Access Control Markup Language (XACML)’, OASIS, https://www.oasis-open.org/committees/xacml/ Hu, B., Svensson, G. (2010) ‘A Case Study of Linked Enterprise Data’, The Semantic Web – ISWC 2010 Jena (2012) http://jena.apache.org/ Karagiannis, D., Kühn, Bauknecht, K., Min Tjoa, A., Quirchmayer, G. (2002). Metamodelling platforms. In:

Proceedings of the Third International Conference EC-Web 2002 – DEXA 2002, LNCS 2455, pp. 451-464. Springer, Berlin/Heidelberg

Kirk, T., Levy, A. Y., Sagiv, Y., Srivastava, D. (1995) ‘The Information Manifold’, in Proceedings of the AAAI

1995 Spring Symp, on Information Gathering from Heterogeneous, Distributed Environments, p. 85—91

Online community for the Security Assertion Markup Language (SAML) OASIS Standard (2013). Retreived

from http://saml.xml.org/ Pfeffer, J., Graube, M., Urbas, L. (2012). Browsing Reversible Neighborhood Relations in Linked Data on

Mobile Devices. In: C. Benavente-Peces, F. Ali, J. Filipe (Eds.), Proceedings of the 2nd International Conference on Pervasive Embedded Computing and Communication Systems (PECCS 2012), S. 150-155. SciTePress.

Rodriguez, A. (2008). ‘RESTful Web services: The basics‘,

https://www.ibm.com/developerworks/webservices/library/ws-restful/

http://www.springerlink.com/content/978-3-642-17748-4/




Mell, P., Grance, T. (2009). ‘The NIST Definition of Cloud Computing’, National Institute of Standards and

Technology, Information Technology Laboratory Sandhu, R., Ferraiolo, D.F., Kuhn, D.R. (2000), ‘The NIST Model for Role Based Access Control: Toward a

Unified Standard’ Postscript PDF Proceedings, 5th ACM Workshop on Role Based Access Control, July 26-27, 2000, Berlin, pp.47-63

Schenk, S., Saathoof, C., Baumesberger, A., Jochum, F., Kleinen, A., Staab, S., Scherp, A. (2008)

‘SemaPlorer – Interactive Semantic Exploration of Data and Media based on a Federated Cloud Infrastructure’, Semantic Web Challenge, International Semantic Web Conference

Sesame (2012) http://www.openrdf.org/ Urbas, L., Pfeffer, J., & Ziegler, J. (2011). iLD-Apps: Usable Mobile Access to Linked Data Clouds at the Shop

Floor. In: Proceeedings of Workshop on Visual Interfaces to the Social and Semantic Web (VISSW 2011). 13. Februar 2011, Palo Alto, California, US. CEUR-WS.org proceedings Vol-694.

World Wide Web Consortium (2004). Resource Description Framework (RDF). Retrieved from

http://www.w3.org/RDF/ World Wide Web Consortium. (2008). SPARQL Query Language for RDF. Retrieved from

http://www.w3.org/TR/rdf-sparql-query/ Ziegler, J., Graube, M., Pfeffer, J., Urbas, L. (2012). Beyond App-Chaining - Mobile App Orchestration for

Efficient Model Driven Software Generation, Proceedings of the 17th IEEE International Conference on Emerging Technologies and Factory Automation ETFA in print

http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf

http://www.openrdf.org/




DISCLAIMER

The information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law.

Copyright 2014 by SAP SE, Asociación de Empresas Tecnológicas Innovalia, Ben-Gurion University of the Negev, BOC Business Objectives Consulting S.L.U, Comau S.p.A., Technische Universität Dresden, Dresscode 21 GmbH, Evidian S.A., ISN Innovation Service Network d.o.o., Kölsch & Altmann GmbH, Nextel S.A., RST Industrie Automation GmbH, University of Vienna.