Ref.

Ares(2019)7374810 - 29/11/2019

D5.2: DESCRIPTION OF PLUGIN

ARCHITECTURE TO BE USED BY
BDSS TOOLS FOR PLUGIN
IMPLEMENTATION

Work Package WP5 (D5.2)

Lead Authors (Org) A. Segatto, M. Milleri and C. Kavka (ESTECO)
Contributing Author(s) (Org) Y. Didri (LIST), T Tamisier (LIST) and S. Belouettar (LIST)
Reviewers (Org) S. Belouettar (LIST), G. Giunta (LIST)
Due Date 31-12-2018
Date
Version V1.3

Dissemination level

PU: Public X
PP: Restricted to other programme participants
RE: Restricted to a group specified by the consortium
CO: Confidential, only for members of the consortium

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 1

implementation
Versioning and contribution history

Version Date Author Notes

A. Segatto (ESTECO), M.
v1.0 06-12-2018 Milleri (ESTECO) and C. Initial draft
Kavka (ESTECO)
A. Segatto (ESTECO), C. Enhanced architecture
V1.1 14-12-2018
Kavka (ESTECO) description
Initial architecture
Y. Didri (LIST) and T
V1.2 20-12-2018 evaluation section and
Tamisier (LIST)
general corrections
S. Belouettar (LIST), G.
V1.3 21-12-2018 Review
Giunta (LIST)

Disclaimer:
This document’s contents are not intended to replace consultation of any applicable legal
sources or the necessary advice of a legal expert, where appropriate. All 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 user, therefore, uses the information at its
sole risk and liability. For the avoidance of all doubts, the European Commission has no
liability in respect of this document, which is merely representing the authors’ view.

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 2

implementation
TABLE OF CONTENTS

Versioning and contribution history .............................................................................................................. 2

Disclaimer: ..................................................................................................................................................... 2
Task and Deliverable descriptions from the project proposal ....................................................................... 5
Compliance with the work-programme NMBP-23-2016 ............................................................................... 5
Executive Summary........................................................................................................................................ 5
Introduction ................................................................................................................................................... 6
Knowledge-based apps requirements ........................................................................................................... 7
The knowledge-based APPS plugin architecture ........................................................................................... 7
The app container services .......................................................................................................................... 10
The authentication and authorization services........................................................................................ 10
The common data adapter services ......................................................................................................... 10
Environment configurations..................................................................................................................... 10
The plugin modules...................................................................................................................................... 10
The view module ...................................................................................................................................... 11
The data adapter module ......................................................................................................................... 11
The actions module .................................................................................................................................. 11
Initial architecture evaluation...................................................................................................................... 11
Conclusions .................................................................................................................................................. 14
References ................................................................................................................................................... 14

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 3

implementation
LIST of Figures

Figure 1: An example of an app component, in this case a parallel coordinates chart .................................... 8
Figure 2: The plugin architecture diagram ........................................................................................................ 9
Figure 3: A data analysis app ........................................................................................................................... 12
Figure 4: A parallel coordinates app ................................................................................................................ 13
Figure 5: An app to study data correlation...................................................................................................... 13
Figure 6: Future enhancements based on table lens or pixel based / heatmap ............................................. 14

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 4

implementation
Task and Deliverable descriptions from the project proposal
WP definition: The goal of WP5 is to define and create Decision Support Tools (Apps), and
implement them into the BDSS platform for being used by various decision-makers within the
product design process for trial in the WP6 End User Application case studies.
Task 3.3: Plugin tool architecture (Leader: ESTECO). Involved partners: GRANTA, LIST; Duration:
M12-M24).
D3.4: This deliverable presents the definition of the architecture for the plugins based on the
requirements previously identified and the business workflow integration constraints. The proposed
architecture supports both human interaction and completely automated jobs, ensures business
process compliance (access control and security standards), and includes definitions for the full
automation of interactions of tools with databases and visualization tools.

Compliance with the work-programme NMBP-23-2016

The definition of the architecture of the plugin interfaces of the BDSS matches the scope and
expected impact as described in the call text of NMBP-23-2016. Indeed, the definition of the plugin
interface, essential for the definition of BDSS apps, is a key step towards the definition and
implementation of the complete BDSS and will ensure that the developed business decision tool is
realistic and useful to end-users. A careful analysis of security aspects also contributes to the
expected integration of humans in new more complex industrial environments, supporting decision
makers to confidentially access the decision-making platform as indicated in the work-programme.

Executive Summary
This deliverable aims at providing a full definition of the plugin interface for BDSS apps, including its
internal architecture and the interfaces with the other BDSS modules.
The plugin architecture has been defined based on the requirements identified in task T5.1, with its
results already presented in Deliverable D5.1, and the requirements for business processes
identified in tasks T3.1 and T3.2, tasks already completed with results presented in deliverables D3.1
and D3.3, respectively. In particular, the application cases proposed by the industrial partners
provided an invaluable source of information for the identification of customer business needs for
the business layer. Both human interaction and completely automated jobs are supported by the
proposed architecture that also ensures business process compliance (access control and security
standards) and includes definitions for the full automation of interactions of tools with databases
and visualization tools.
The results presented in this deliverable provide support for the implementation of the BDSS apps,
activity currently under execution in task T5.3.

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 5

implementation
Introduction
The mission of COMPOSELECTOR is to develop a Business Decision Support System (BDSS), which
integrates materials modelling, business tools and databases into the end-user’s workflow to
support the complex decision process involved in the selection and design of polymer-matrix
composites.
Making the BDSS tool available to and usable by decision makers is one of the most important goals
of COMPOSELECTOR. This objective will be reached by providing a set of tailored knowledge-based
“apps” to support and guide decision makers in their managerial decision situations. In practice,
there will be both technical and business decision makers interacting at different levels, requiring
the BDSS knowledge to be presented in a way that is properly customized to their needs.
Considering current decision makers expectations today, the tools will need to be presented in web
based and mobile environments.
Knowledge-based BDSS apps developed in the BDSS can be implemented to cover a large number
of different applications. For example, apps for data and visual analytics are needed to help
implementing alternative strategies with the user in the loop of a material selection, building upon
a multi-actor framework to cover the entire value-chain, and eventually, bring to implementing a
roadmap to improve composite material selection and design. Other knowledge-based apps can
support the development of KPIs-based business decisions applications, including the interaction
with collaborative decision and support tools, life cycle engineering as well as multi-objective
optimization and multi-criteria decision methods.
The selection of a well-defined software architecture to build apps in the BDSS is essential in order
to guarantee a solid base to support the implementation of a wide range of applications intended
to interact with different types of decision makers at very different levels. In fact, a strong
interaction among all the COMPOSELECTOR partners was required in order to reach the definition
of the general plugin architecture which is presented in this deliverable. It is certainly expected that:
it should cover all defined use cases; contribute to the definition of one of the most distinctive
elements of COMPOSELCTOR; be the tools that the decision makers will use to interact with the
system.
This deliverable presents the general architecture of the plugin architecture for the knowledge-
based BDSS apps. The architecture is defined in terms of the modules the apps are required to
implement and their interactions with other modules as well as the other BDSS layers. Each app
provides a set of “views” that are implemented in terms of “plugins”, a unit that provides a secure
and well-defined environment where user experience and behavior can be fitted and, then plugged
into the app to deliver its services to the final decision maker user.
This document is structured as follows: next section introduces the general knowledge-apps
requirements, followed by a section presenting the general conceptual architecture of the BDSS
apps plugin architecture and the interaction with the other BDSS components, in particular, with
the business level and the interoperability layer. After that, an initial example of a knowledge-based
app is introduced to present the interaction between decision makers and a simple app, when
applied to a typical COMPOSELECTOR scenario. The deliverable is complemented with final
conclusions and a short bibliography at the end.

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 6

implementation
Knowledge-based apps requirements
The requirements for the knowledge-based apps were identified by considering the work performed
in task T5.1, which established the key-performance indicators linking material and process
modelling outcomes to business decisions. Result are presented in the deliverable D5.1. Also, the
work performed in tasks T3.1 and T3.3, whose results are already reported in deliverables D3.1 and
D3.3 respectively, contributed to the identification of requirements for the BDSS apps. As described
in these documents, the requirements were identified in a collaborative activity that involved the
whole consortium, with a particularly important contribution from the industrial partners.
The following requirements were identified:
1. Web technology and mobile features support. Current decision makers are expected to use
modern technology to interact with the BDSS. The apps must provide a web interface usable
from most modern browsers.
2. Visual analytics capabilities. The BDSS apps will need to provide decision makers with
powerful graphic tools to support visual data processing. In fact, visual analytics capabilities
are essential to support KPI-based decision-making activities. Possibility to include visual
components provided by already existing tools (e.g. Granta visualization tools) should be
considered.
3. Ability to interact with the different BDSS layers. Not only the ability to display and handle
data are required by decision makers but also the possibility to handle execution of business
workflows is required. Apps should have the possibility to interact with the business layer to
request execution of a business workflow, query its execution status or stop its execution if
necessary.
4. Secure environment. Decision making activities can be taken at high levels and with a strong
request for confidentiality. A state-of-the-art technology is required to support business user
interaction, guaranteeing a top-level industry-standard authentication service. In particular,
users should use the same credentials across the business layer and COMPOSELECTOR apps,
at least.
5. Well-defined interaction with COMPOSELECTOR business layer and interoperability layer.
Interaction with the business layer and the interoperability layer should take place by using
well-defined APIs, implemented in terms of independent adapters, which can be developed
and maintained independently.

The knowledge-based APPS plugin architecture

As a result of the requirement definition process, and based on interaction with the other partners,
the partners involved in this activity concluded that the requirements are feasible, and the
envisioned implementation is adequate for providing a successful architecture for knowledge-based
apps plugins, which can deliver the required support for the BDSS system.
In the proposed architecture, a BDSS app is built from a set of building blocks called “plugins”, each
one of them providing a specific app functionality. Each plugin is autonomous, meaning that it can
be developed, maintained and tested independently, supporting the distributed development of
complex apps by different software developers. Plugins are software components, which provide
user experience through a graphical user interface, an associated behavior and also a service that
access the required data. An example of a single component (or plugin) is presented in Figure 1. This
component corresponds to a typical parallel coordinates chart used to display KPI data. The plugin
component displays data though a user interface, interacts with the user by providing a certain
D5.2- Description of plugin architecture to be used by BDSS tools for plugin 7
implementation
behavior and can access specific data available in some database.

Figure 1: An example of an app component, in this case a parallel coordinates chart

The top-level knowledge-based BDSS app, simply called app from now on, is a container which
includes a set of internal components (or plugin units) like the parallel chart shown before, which
are put together and benefit from a set of core services provided by the app container. These sets
of core services can be used by the individual components in order to deliver their own services.
The main architecture is presented in Figure 2. The individual plugin components are all completely
autonomous, can be developed and maintained independently. Also, they should all rely on the core
services provided by the app container in order to offer their own functionalities to the final user.
In this way, the app acts as a container, which offers a place for a set of plugin units, each one of
them getting a secure and well-defined environment, where they can be fitted and then plugged
into the top-level container to deliver its services to the final decision-maker.
Each plugin must provide its own visual module, an optional action module and a data adapter. The
visual module corresponds to a presentation layer supporting user interaction (called also user
experience) and the action module to the associated behavior than can provide actions to be
executed by the user. From the software point of view, the component is implemented in terms of
a graphic software module called “view”, the associated behavior is implemented in terms of a
module called “action”, and the required access to data through a “data adapter”, which is the
software module that acts as a bridge to the data source. The “action” module is optional, since in
some plugins there could be no need for a specific behavior as, for example, in a component used
just to display data. An example of plugins integrated into the app container is presented in Figure
1.
Clearly, the terms “app component” and “plugin” can be used interchangeably in this specification.

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 8

implementation
 Business top-level BDSS user

view
view view

actions
…
data adapter data adapter
data adapter

plugin plugin plugin

authentication and environment

common data adapters
authorization services configurations
app

business, interoperability and database layers

Figure 2: The plugin architecture diagram

The top-level app container provides the following services:

1. Authentication and authorization: access to services provided by an app is subject to strict
authorization and authentication control as established by the single sign-on module
implemented in the BDSS.
2. Common data adapters: the app provides adapters that can be used by the single plugin to
access data provided by the other layers of the BDSS.
3. Environment configurations: a set of environment variables that provides configuration
information to the app, which can be useful to the individual plugin to configure itself.
As mentioned before, BDSS plugins are implemented in terms of the following modules:
1. View: the software component that implements the user interface, intended to display
information capable of handling interactive requests.
2. Actions: the software component that implements the behavior related directly or not with
the user interface interaction.
3. Data adapter: the software component that implements a bridge which provides access to
a generic data source, extending the common data adapter functionalities.
More details on the core services provided by the app, which are available for all plugins, and the
modules that are required to implement the individual plugins, are presented in more detail in the
next sections.
Currently, a prototype implementation of a BDSS app server with a number of different decision-
making plugins is available at https://app.composelector.eu, where login credentials for the single

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 9

implementation
sign-on are required.

The app container services

As mentioned before, the top level BDSS app is a container that provides a set of core services that
can be used by the independent plugins in order to deliver their own services. The main services are
described below.

The authentication and authorization services

This module is based on a standard protocol, which provides state-of-the-art single sign-on login to
multiple applications features, guaranteeing that app users cannot access services without getting
their credentials validated before.
The security module is based on the standard protocol OpenID connect (OpenID 2018), in particular,
the current implementation used is based on the Keycloack identity and access management
software library, which is open source and available at https://www.keycloak.org. The same
technology is used for the business layer, meaning that users have a single-entry point for these two
levels of the BDSS. It is possible that other layers can join the single sign on technology in the future.

The common data adapter services

The common data adapter is the software module that acts as a bridge between the plugins and the
data source. By using the common data adapter, plugins are not required to deal with the
complexity of handling all details of the procedure to access the BDSS data services.
In particular, there is an adapter dedicated to the business layer interaction through the business
layer API. It provides services to start and stop business workflows, and provides query about
business workflows executions. There is also a data adapter for interoperability and database layers
integration, which through the database layer API provides services to query for data about
modelling workflows, previous execution results and other information available through the
database layer.
The services provided by the business layer API and the database layer API are implemented
according to the standard REST technology, making them easily accessible by standard REST clients
using HTTPS. Of course, only requests that are authenticated with the single sign on module are
accepted. In fact, to request services from the business layer API, a user needs to get a token from
the single sign on module, which provide the appropriate permissions. This can be done from most
modern web languages like, for instance, JavaScript.
Plugins can define their own data adapters, in such a way that the view and actions modules can get
a simplified access to specific data repositories, without being involved in complex interaction with
them.

Environment configurations
The app container provides configuration for the plugins which are represented as a set of pairs
(variable, value), in a similar way as operating systems implement environment variables. These
variables can be used to provide information to the plugins, which can be used at initialization time
or at run time.

The plugin modules

Each plugin is implemented in terms of a set of modules. These modules are described in detail
D5.2- Description of plugin architecture to be used by BDSS tools for plugin 10
implementation
below.

The view module

The view module implements the user visible interface of the plugin, being its main job to support
the user experience of the app when using the plugin. In the BDSS, it is expected that it will be
implemented as a web page, which should be defined in such a way that can provide an adequate
representation also for a mobile application view.
The module can deliver the user interface in terms of a hierarchy of components, defining arbitrary
areas of the screen that can be used to present different contents.
In order to support a good user experience, it is expected that views provided by plugins from a
single app should maintain a uniform style.

The data adapter module

The plugin data adapter is a module that supports a simplified access to data, by extending the
common data adapter provided by the app container with additional functionalities. These
functionalities can be based on other data sources or simply on transformations and aggregations
of the data provided by the common data adapter.
In other words, the plugin data adapter provides an abstraction, which encapsulates the (possibly)
complex details required to access a particular data source. By using the data adapter, the other
plugin modules can get, then, an optimized way of accessing data without the need to consider
aspects like connection pooling or concurrency for example.

The actions module

This optional module implements the component application logic that might or might not be
directly related to the user interface. By separating the view-related functionality from the logic of
the plugins, the software that implements the components can be cleaner, more efficient and easier
to maintain.
The module is implemented as a set of functions that are made available to the other plugin
components.

Initial architecture evaluation

In order to perform an initial evaluation of the architecture and provide a proof of concept for the
architectural choices, a “walking skeleton” for a base BDSS app with support for authentication,
security and a general-purpose technology stack that follows the proposed architecture has been
developed. The technology stack is composed of Java EE (Enterprise) and JavaScript single page
application.
Based on this very basic container, LIST has plugged-in one app (three Tabs) that are shown in Figure
3, Figure 4 and Figure 5. The plugin in Figure 3 (container tab “Parallel Coordinates”) can be used to
display data. In this case maximal von Mises stress, deflection, principal stress and stiffness coming
from different scenarios when analyzing Dow use case are compared and assessed. Those scenarios
are presented in the data analysis plugin (Figure 3, container tab “Data”) where the figures of the
specified KPI are presented for a quantitative comparison. The third tab, named “Correlation”, is
useful for identifying correlation among data.
The first tab offers a systematic view of the input data, which are analyzed further in the remaining
two tabs (Figure 4 and Figure 5). This example considers data generated form the multiscale
modelling of a composite leaf-spring (use case N°2). This tab represents the combinations obtained
D5.2- Description of plugin architecture to be used by BDSS tools for plugin 11
implementation
from the cardinal product of Epoxy (I, II or III) with either Glass (I, II or III) and Carbon (I, II or III), i.e.
3*3*2 = 18 combinations. Each combination is measured according to we have four performance
attributes: Max Mises Stress, Max Deflection, Max Principal Stress and Stiffness.
The second tab shows on this example how Parallel Coordinates allows an interactive display of
multi-dimensional data. The view is initialized with the entire solution space. For large sets of data,
interactive features will be used for zooming and filtering, and to enable the user to generate a
subset of the solution space by reducing the range of value on selected axes. Results of this
interactive visualization will then be used as inputs for further visual analysis. An alternative of
Parallel Coordinate would be the so-called Radar Chart (see:
http://bl.ocks.org/tpreusse/2bc99d74a461b8c0acb1).

The last tab shows the correlations between any two pairs of variables through a standard matrix
of correlations. For future enhancements, advanced visualization for this tab could be based on
table lens or pixel based / heatmap as shown in Figure 6.
This app is made available in the COMPOSELECTOR BDSS app server as indicated before, accessible
with single sign-on credentials at https://app.composelector.eu.

Figure 3: A data analysis app

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 12

implementation
 Figure 4: A parallel coordinates app

Figure 5: An app to study data correlation

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 13

implementation
 Figure 6: Future enhancements based on table lens or pixel based / heatmap

Conclusions
As a result of the requirement definition process, and based on interaction with the whole
consortium, the partners involved in task T5.2 concluded that the requirements are feasible, and
the envisioned implementation is adequate to provide a plugin architecture for BDSS apps, which
can deliver the required support for the BDSS system.
This deliverable presents the proposed architecture for the app’s plugins, which are currently under
implementation in task T5.3.

References
OpenID (2018), The Open ID connect standard, https://openid.net/connect/

D5.2- Description of plugin architecture to be used by BDSS tools for plugin 14

implementation