How does the AIM work?

DEMETER aims to facilitate the creation of apps from existing data, components, and systems, with new ones developed as needed. In order for all these to communicate and interoperate, it is necessary to use a common data model for all data exchanged. Otherwise, it is impossible to use them together. The AIM model provides this common data format (and language) for all data exchanged. Furthermore, as we desire interoperability with the best known and most used ontologies, models and vocabularies that are already used, we have in fact developed AIM by taking concepts and vocabulary from all these existing models and fused them together, thus ensuring a backward interoperability with all these models. In general, any component (e.g., device) that want to be offered through the DEMETER Hub needs to be AIM compliant and this is achieved by creating the appropriate data wrapper that translates the data used by said component to the AIM model and vice versa.

Now to achieve all these, AIM is structured in a modular way: it includes a core vocabulary of concepts that are common and general to all domains, and more specialized models for each possible agri-domain (e.g., farms, or animals etc.) and even more specialized models for specific applications, together with a meta-model and meta-data that tie all these together.

What does the AIM do?

AIM provides the common data model (language) that allows different, existing (or new) systems and devices to talk to each other and interoperate as part of a complete app. This provides a number of business opportunities to create new apps from existing data, components, and devices (or even existing systems), thus allowing the monetization and reuse of the data and devices.

Who are the end-users/stakeholders targeted by AIM?

Software Suppliers	Hardware Suppliers
IT Services	Advisory Services

What are the benefits of the AIM for the end-users?

As outlined above, AIM provides the common data model that allows different, existing (or new) systems and devices to talk to each other and interoperate as part of a complete app. Advisors and experts working with farmers will be able to create new apps from existing components based on the needs of the farmers and using the unique co-creation process offered by DEMETER.

Where can I find examples of AIM in operation?

Various DEMETER pilots already have integrated AIM (or the integration is ongoing). For example, the pilot in Cluster 4 which addresses animal welfare and milk quality has already fully integrated AIM in its deployment.

The latest implementations of the AIM pilot-specific extensions are always up to date in GitLab. For each extension the ontology module and the corresponding JSON-LD context is available here.

Technical Overview of DEMETER AIM

To facilitate the creation of apps from existing data, components and systems, and to allow all these to communicate and interoperate, it is necessary to use a common data model for all data exchanged. The AIM model provides this common data format (and language) for all data exchanged. AIM is not developed ab initio but takes concepts and vocabulary from all these existing models and fuses them together, thus ensuring semantic interoperability with several well-known and used ontologies, models and vocabularies.

In order for the enablers that are offered through the DEMETER Enabler Hub to be able to communicate with each other, they need to be AIM compliant. Given this requirement, the various enablers can interoperate, and new apps can be created by combining and using the appropriate enablers together and taking data from various existing sources.

The DEMETER AIM follows a modular approach in a layered architecture, with the following subcomponents:

1. The AIM core metamodel, which defines the building blocks and rules of AIM enabling the back-and-forth conversion between property-graph datasets and linked data. It follows the NGSI-LD meta-modelling approach.
2. The AIM cross-domain ontology, i.e., the set of generic models which provide common definitions relevant for the entire agrifood domain and thus avoids conflicting or redundant definitions of the same classes at the domain-specific layer.
3. The AIM domain-specific ontologies, which model agri-specific concepts such as crops, animals, agricultural products as well as farms and farmers, etc. which are typically fused from existing well-known ontologies widely in use.
4. The AIM pilot-specific ontologies layer: this comprises of tailor-made ontologies to our pilots which extend ontologies from the domain-specific layer and mostly define new concepts that exist in no other known agriculture ontology.
5. The AIM metadata schema, which expresses semantics, related to meta-information about the datasets, based on the cross-domain and domain specific ontologies.

DEMETER Agricultural Information Model (AIM)

AIM reuses and integrates a number of cross domain standard ontologies, such as the OGC and W3C standard SOSA/SSN, GEO/EO standards from OGC and ISO/TC211 and INSPIRE, Time standards from W3C and the QUDT quantity ontology.   The Agri domain specific concepts are based on, and align, domain specific ontologies and models including SAREF4Agri, FIWARE and INSPIRE/FOODIE and establishes mappings with other relevant ones including AGROVOC, ADAPT and others. Metadata for available data sets and services are  described through the W3C DCAT Data Catalog Vocabulary.  The data exchange mechanisms are being harmonised with the IDS – International Data Spaces Information model and the emerging GAIA-X federated Data infrastructure.

Due to its modular approach, it can also be extended easily either by new modules (e.g., adding new domain specific ontologies), or by changing specific modules in order to add new concepts.

What is the relationship between AIM and other DEMETER components?

AIM influences and interacts with several other DEMETER components:

• The DEH (DEMETER Enabler Hub) offers AIM-compliant enablers and/or data wrappers for other enablers, as being AIM compliant (and using this common data model) is a prerequisite for interoperability and the formation of complete apps from these components.
• Similarly, the BSE (Brokerage Service Environment) facilitates the deployment of the needed data wrappers and the AIM complaint components in general.

The dashboards allow the creation of apps and the offering of the needed enablers which should follow the AIM data model.

Where can I find more technical information about AIM?

More information about AIM can be browsed at the following (external) link: http://agroportal.lirmm.fr/ontologies/DEMETER-AIM

IPR over AIM is governed by the creative commons license clauses. License: CC BY 4.0 https://creativecommons.org/licenses/by/4.0/

How does the DEH work?

The DEH is the DEMETER resource catalogue dedicated to DEMETER end-users where they are able to create and register their own resources. Users will have two roles to act as DEMETER Provider and/or DEMETER Consumer. A DEMETER Provider is able to offer his/her resources, while DEMETER Consumers will be able to browse the catalogue and find suitable resources matching their requirements. The resources hosted in the registry can be discovered and made accessible via the web interface, but also via APIs.

The DEH can be accessed at  https://deh.h2020-demeter-cloud.eu/.

What does the DEH do?

The DEH provides the registration of resources, their maintenance and discovery. It provides the harmonised descriptions that enable each component to be used in the co-creation mechanism, which will be made available through the SOCS. Furthermore, it allows DEMETER Providers to promote their resources making them reusable by different DEH users.

Who are the end-users/stakeholders targeted by DEH?

Farmers	Software Suppliers	Hardware Suppliers
Agri Suppliers	IT Services	Advisory Services	Public Authorities

What are the benefits of the DEH for the end-users?

End-users as DEMETER Providers, through the DEH, can promote their resources that thus can be validated by different DEMETER Consumers; on the other side, DEMETER Consumers are able to browse the collection of registered digital tools and services, and find suitable resources matching their requirements.

Where can I find examples of the DEH in operation?

Components such as Estimate Animal Welfare DSS and Milk Quality DSS were registered in the DEH with the aim to improve the DSS solution and make its output more accurate. Indeed, to better exploit project results, all the pilot solutions (based on machine learning algorithm) will be adopted and validated in the field, so it is important to make them available and reusable through the DEH.

The DEMETER Enabler Hub (DEH) building blocks are composed of the following modules:

Access Control System (ACS): providing DEH user access, profiling and access policy to the resources stored in the DEH.

Resource Registry Management (RRM): providing the REST APIs framework for the resource management process (e.g., creating, editing, discovery, deleting) and interfacing with other modules such as ACS, DYMER and DEH Dashboard. The module is developed using Spring Boot which is an industry-standard Java-based Framework, with Maven as a build automation tool. For the purpose of storing the data related to resources it adopts MongoDB, which is a NoSQL document-oriented database. As additional modules that are used within Spring ecosystem, it also integrates Spring Data MongoDB which is used to make it easier to manage data in MongoDB. Lombok is used to reduce the boilerplate code related to Entities, while Swagger is used for the purpose of documenting and testing REST APIs.

DYMER: is a framework for dynamic information modelling and resource catalog visualization. It consists of two main components: Dymer-Core and Dymer-Viewer. Dymer-Core is based on a micro-service architecture approach, providing capabilities to develop a single application as an orchestration of small services, each running in its own process, and communicating with lightweight mechanisms using HTTP/REST protocols alongside JSON. Each micro-service is designed and implemented with a specific role and among the main ones we can identify the following three:

• Service-Model allows dynamic modelling of data and metadata inherent to the products and services offered.
• Service-Template allows the generation of graphic templates that can be used in the display of products and services using logic-less templates.
• Service-Entities manages the storage and use of the product and services.

These micro-services are developed using the Express.js web application framework (for Node.js), released as free and open-source software under the MIT License. It is designed for building web applications and APIs.

The information is stored in NoSQL Database (MongoDB, Elasticsearch) that provides high performance, high availability, and automatic scaling. Service-Entities use Elasticsearch that is a distributed, Open-Source search and analytics engine for all types of data (including textual, numerical, geospatial, structured, and unstructured) that are stored in JSON format.

DYMER makes use of two JavaScript libraries, dymer.viewer.js and dymer.map.js, in order to visualise resources in list, map and data table mode.

The JavaScript libraries are capable of communicating with DYMER API enabling CRUD (create, read, update and delete) operations on the entities not only in DYMER but also in every external web portal.

DYMER is able to import data from external sources (from JSON files, Excel files and/or API services displaying data) and it can serve as a bridge to visualise external data thanks to DYMER RESTful APIs.

Interaction with the Dymer-Core takes place through the Dymer-Viewer, which is a fast, small and feature-rich JavaScript library. Thanks to this library it is possible to interact with the platform facilitating the use of data by offering a single search point and displaying the results in special graphic templates.

Together with the DYMER viewer it is possible to use two components: the search algorithm and the filter function. The first one is designed to look for an element or to retrieve an element from any data structure stored in DYMER, whereas the second one helps the user to sort through a wide range of items and search for a specific value of one or more field/s within the data structure.

DEH Dashboard: representing the DEH front-end application, which will be used by end-users or DEMETER Stakeholders for resource creation or discovery. DEH Dashboard has two parts, the Front-End part developed in AngularJS which is SPA (Single Page Application) framework and the back-end part (DYMER) developed in Node.js, which is JavaScript runtime environment that executes JavaScript code outside a web browser, where Express.js is used for routing. For the purpose of storing templates, services and forms MongoDB which is a NoSQL document-oriented database is used. Elasticsearch is used for the purpose of storing entities, their indexing, and fast searching.

What is the relationship between DEH and other DEMETER components?

The DEH links with several other DEMETER components:

• Access Control System (ACS): The ACS provides authentication and authorization functionality.
• Brokerage Service Environment (BSE): The “DEH resource id” is one of the metadata fields created by the DEH and used during a DEE registration in the BSE.
• SOCS: The DEH will provide the SOCS with the registered resources  that SOCS users will be able to use in order to elaborate the optimal solution as result of a co-creation process.

Where can I find more technical information about the DEH?

For more information on DEH, please contact Maria Francesca Cantore (MariaFrancesca.Cantore@eng.it) or Antonio Caruso (Antonio.Caruso@eng.it)

DEH is released under aAGPLv3.

How does the SOCS work?

The SOCS is an online platform dedicated to all stakeholders (farmers, advisors, and suppliers) where providers and consumers of digital technologies are not just matching assets and needs, but they can collaborate together towards joint innovations.

Indeed, the SOCS aims to reverse the relationship with suppliers, through an innovative model in which suppliers are responsible for ensuring that a final solution is optimal to the farmer’s existing context and expressed needs. SOCS also provides a response to farmers who need to be supported when they have to choose between different solutions.

The available services through the SOCS may be categorized under three pillars:

• Collaboration Space: concerned with a set of tools useful to share, validate ideas and co-design new solutions.
• Catalogues: concerned with a common repository for human profiles and competencies, enabling search and discovery of who is part of the network.
• Knowledge Management: concerned with providing online access to information and materials.

One of the main functionalities offered by the SOCS is, undoubtedly, gathering and addressing farmers’ needs according to a co-creation process. Through this process, farmers’ needs can be better elicited, through the collaboration tools and thanks to the help of other users (i.e., advisors). The need expressed by a farmer is analysed and can evolve into a challenge which represents the area of interest that requires new solutions or approaches. The creation of a challenge aims to involve stakeholders in the creation of solutions (ideas) that represent their contributions to the requests expressed through the challenge. The final result of the challenge is the selection of the idea that best matches with the challenge and the elaboration of the optimal solution, relying on the resources present in the DEMETER Enabler Hub (DEH). The DEH centralises the full description of all the components, devices, services, data sources, platforms etc. that are accessible for deployment.

What does the SOCS do?

The SOCS makes available social networking and co-creation features which can allow:

• Users, who want to implement a new solution, to discover companies core activities and select partners by skills, and potentially start a collaboration on common interests.
• Users to analyse existing experiments and success stories and get inspiration for ideas or about how certain problems were faced.
• Developers to co-create and share guidelines to be used by new IT providers interested in the integration with the DEMETER ecosystem.
• Farmers to express their needs and IT providers to gather and address these needs according to a co-creation process which evolves in the implementation of a new application.

Who are the end-users/stakeholders targeted by SOCS?

Farmers	Software Suppliers	Hardware Suppliers
Agri Suppliers	IT Services	Advisory Services	Public Authorities

What are the benefits of SOCS for the end user?

The SOCS aims to reverse the relationship with suppliers; indeed, IT suppliers are responsible for ensuring that a final solution is optimal to the farmer’s existing context and expressed needs. SOCS also provides a response to farmers who need to be supported when they have to choose between different solutions.

The SOCS is based on the DIHIWARE Platform, a solution developed by the MIDIH H2020 EU project (http://midih.eu) and currently in use in many ecosystems in Europe. The DIHIWARE Platform offers a complete collaboration environment inspired by Enterprise Social Software.

The DIHIWARE Platform is the core building block on top of which specific DEMETER customisations (environment customisation, catalogue designing and dedicated user journeys) and new developments are being drawn up, with the help of the consortium, carrying out an in-depth study of the objectives that can be achieved through the use of the Platform and the DEMETER ecosystem offer.

The DIHIWARE Platform is an integrated system leveraging on knowledge-driven services that, next to a Catalogues Management System, and harmonised with the collaborative side of the Platform are able to create an environment where providers and consumers of digital technologies related to AI development and adoption cannot just matching assets and needs, but they can collaborate to boost innovation.

The Platform is based on different Open-Source components, integrated and distributed as Docker images, using a winning modular approach able to simply the deployment procedure and guarantee the possibility to have custom-tailored solutions suitable for the variegated environments.

The DIHIWARE customisation capabilities, next to a concrete adoption plan of the Platform, enables the delivery of specific tailored environments, based on selected DIHIWARE modules and in line with the stakeholders needs and requirements. The resulting platform is an integrated environment made of the following main systems: Collaboration Portal (CP) and Catalogues Management System (CMS). Each system provides a specific function and complements the functionality of the other.

The Collaboration Portal is grounded on Liferay the has been selected since it is a widely used Open-Source and state-of-the-art Content Management System. Liferay Portal is a free and Open-Source enterprise portal software product written in Java. Liferay includes a built-in web content management system allowing users to build websites and portals as an assembly of themes, pages, modules/widgets, and a common navigation.

The Catalogue Management System relies on DYMER (DYnamic Information ModElling & Rendering) which is a WCM (Web Content Management) completely developed by ENGINEERING within the MIDIH Project. Further information on DYMER is available in the DEH section.

What is the relationship between the SOCS and other DEMETER components?

The SOCS, and in particular the co-creation application, has synergies with the DEH, indeed through the latter, developers can select registered resources and use them to elaborate the optimal solution which is the result of a co-creation process.

SOCS is released under aAGPLv3, Co-creation application: joint exploitation.

Where can I find more information about the SOCS?

For more information on SOCS, please contact Maria Francesca Cantore (MariaFrancesca.Cantore@eng.it) or Antonio Caruso (Antonio.Caruso@eng.it)

How does the ACS work?

ACS consists of three relatively independent modules: Authentication, Authorization and Traceability.

These functionalities have been implemented in six main security components: Identity Manager, XACML PDP, Capability Manager, PEP Proxy, Traceability Agent and Traceability blockchain repository.

The Authentication component consists of an IdM (Identity Manager), called Keyrock. This IdM will provide the Keyrock’s REST API for authentication based on the OAuth 2.0 protocol.

The Authorization component is divided in XACML PDP, Capability Manager and PEP Proxy.

• The XACML PDP manages the access control policies and decides who can access to a resource and what actions can perform over that resource.
• The Capability Manager is the component for generating capability tokens for the user in case of receiving affirmative authorization decisions from the XACML PDP of a request about an action or about the access to a resource.
• PEP-Proxy acts as an intermediate between a user, service, device, etc. and the Information Repository (Broker) and also as a component of validation of the capability token.

The Traceability component consists of the Traceability Agent and the Traceability DLT (Blockchain repository). Permissioned blockchains register the transactions across the nodes of the network. The DEMETER Traceability Component will register authentication and authorization events as transaction of the blockchain.

What does the ACS do?

ACS has the aim to have a distributed access control platform for the DEMETER project. Thus, ACS allows the management of identities within DEMETER (authentication) and manage permissions, access and roles for resources and applications (authorization).

Who are the end-users/stakeholders targeted by the ACS?

Software Suppliers	Hardware Suppliers
IT Services	Advisory Services

What are the benefits of the ACS for the end users?

ACS component enables OAuth2-based authentication and authorization security to be added to DEMETER’s services and applications. Oauth2.0 is a very flexible protocol that relies on SSL (Secure Sockets Layer) to ensure data between the web server and browsers remain private. OAuth2.0 can share data for users without having to release personal information.

Where can I see examples of the ACS in use?

In addition to providing support to core components of DEMETER (BSE and DEH), ACS provides identity management services to other DEMETER partners that provide applications, as, for example:

• Poultry Wellbeing API
• WaisenseFields: One of the winners of the Open Call #1 tackling the challenge of Soil Workability and Humidity Monitoring
• DEMETER Benchmarking in Agricolus

• The OAuth 2.0 protocol supports several grants (“methods”) types for a client application to acquire an access token (which represents a user´s permission for the client to access their data) which can be used to authenticate a request to the Keyrock API endpoint. The following methods for authentication are provided:
  • Authorization Code: defined for apps running on a web server, where the user will be redirected to the Keyrock server.
  • Username and Password: for logging in with a username and password directly in the web server.
  • Client credential: suitable for machine-to-machine authentication where specific user´s permission to access data is not required
  • Refresh token: to refresh the authentication token before its expiration time.

  The Authorization component is divided in XACML PDP, Capability Manager and PEP Proxy.

  XACML PDP. The PDP (Policy Decision Point) evaluates XACML (eXtensible Access Control Markup Language) policies in XML representation. With the specified policies, a request from the Capability Manager made to the PDP, that has the location of the policies, is evaluated to decide if the access or action in the request can be performed or not sending back a response. This communication is sent encoded in JSON, which provides a less verbose representation of the information and improves the request processing as well.

  The PDP is deployed as a Web Service to be accessed by the authorization entity acting as Policy Enforcement Point (PEP) through the exchange of HTTP messages with JSON payloads containing the XACML requests or responses. The PDP is based on Web technologies to be a scalable and lightweight solution so it can be applied to any large-scale deployment that requires XACML as policy language. XACML PDP achieves clear performance improvements over other existing solutions in terms of scalability and efficiency.

  Capability Manager. The Capability Manager signs the generated capability token that includes the client’s public key and time restrictions associated with the specific policy delimiting the validity period for this credential.

  The figure above shows a flow chart with a Capability Manager in an authorization process example:

  1. When an authenticated user wants to get access to a resource or to perform an action an authorization request is sent to the Capability Manager (fig. step 1).
  2. When this request, that includes the user’s authentication (AuthN) token, is received by the Capability Manager it validates the token on the IdM getting back the user’s identity attributes (fig. steps 2, 3) and then validates them (fig. step 4).
  3. Once validated and with these attributes, the Capability Manager asks the XACML PDP sending an authorisation (AuthZ) request to determine whether the requested credential must be generated or not (fig. step 5).
  4. The XACML PDP evaluates the AuthZ request using the defined policies and sends back its verdict to the Capability Manager (fig. steps 6, 7).
  5. The Capability Manager generates then the Cap.Token and send it back to the user in a response (fig. steps 8, 9).

ACS Capability Manager

PEP Proxy. The PEP Proxy verifies that the public key contained in the received capability token is the same key that was used in the authentication process and verifies the token’s signature by making use of the Capability Manager’s public key. This component simplifies the access control mechanism to the resources, and it is a relevant feature on IoT scenarios since complex access control policies are not required to be deployed on end devices.

PEP Proxy

In the figure above, a user that has already received the capability token from the Capability Manager attempts to access a resource. For this purpose, the user generates a request in which the Cap. Token is attached and that is handled by the PEP Proxy (fig. step 1) which validates the token (fig. step 2). After a positive validation, the PEP Proxy forwards the query to the system (Context Broker) (fig. step 3) as well as it forwards the response (fig. step 4) to the user (fig. step 5).

Traceability Agent. The authentication and authorization traceability component will log the access to DEMETER resources by logging the issue and use of authentication and authorization tokens. These tokens contain the information about the user who is logged to the system and the resources the user is intended to access.

The traceability agent will expose a REST API to register authentication and authorisation events (POST) and retrieve their details (GET). The REST API has been designed flexible enough to be able to use different traceability blockchain repositories (i.e., Quorum).

The events logged will contain information about the receiver of the token, the sender of the token, the timestamp, the token details, and an optional data field to extend the information of the event.

Traceability Agent

Traceability Blockchain Repository. A permissioned version of a blockchain repository has been chosen to provide the characteristics of immutability, privacy and compatibility required by the DEMETER Traceability Component. It supports both public and private transactions and smart contracts, and their states derived from a single, common, complete blockchain for transactions validated by every node in the network.

What is the relationship between the ACS and the other DEMETER components?

BSE: The BSE component uses the ACS component, specifically the PEP Proxy and the Capability Manager to get the Capability Token. So, before to getting the Capability Token, it is necessary to get the authentication token, so the BSE makes use of the Authentication module.

DEH: ACS provides secured communication among all components, more specifically by the Identity Manager.

ACS Link to other DEMETER components

Where can I find more technical information about the ACS?

The DEMETER ACS framework domain: https://acs.bse.h2020-DEMETER-cloud.eu:5443

Fiware Keyrock Tutorial: https://fiware-tutorials.readthedocs.io/en/latest/identity-management/index.html

The OAuth 2.0 Authorization Framework: https://datatracker.ietf.org/doc/html/rfc6749

How does the BSE work?

In the framework of DEMETER, a resource coupled with the necessary enablers (core and advanced) is called “DEMETER enhanced entity” (DEE). A DEE once authenticated and authorized by the BSE can register as a service with the BSE specific registry. Subsequently, it becomes discoverable by all the other registered DEEs. Finally, based on the suitable core and advanced enablers that each DEE implement and after resource provisioning information from the BSE, DEEs should be able to communicate directly with each other. Each DEMETER-enabled application should utilize at least one BSE.

What does the BSE do?

BSE coordinates the registration, discovery, and execution of running DEEs. It also offers compatibility (with the BSE metadata model) checking functionality during registration.

Who are the end-users/stakeholders targeted by BSE?

Software Suppliers	Hardware Suppliers

What are the benefits of the BSE for the end-user?

The BSE offers several advantages:

• Allows the discovery and use of available DEEs locally, remotely, or on a cloud.
• Implemented as a self-contained application, it enables an external party to deploy it anywhere as a complete brokerage service solution.
• Based on distributed, high-availability, commercially proven solution.
• Embeds compatibility check functionality.
• Accompanied by high-performance publish-subscribe communication mechanism

Where can I see examples of the BSE in use?

All pilots/DEEs are using a BSE instance (either the one deployed on DEMETER cloud or one deployed on-premise).  Information on the pilots is available here.

BSE is a core module of DEMETER architecture, which facilitates the registration, discovery and ultimately communication process for the DEMETER-enabled resources in a secure and privacy preserving manner.

BSE Components

The building blocks of the BSE are as follows:

• Access Control System: Access Control System and its sub-components are described in the ACS section. BSE is utilizing the functionality provided by this component
• Service Registry: In the context of Brokerage Service Environment (BSE), the Service Registry implements a RESTful interface through which it communicates on one hand with Access Control Server (ACS) and on the other with Brokerage Server (BS). Service Registry is used to store user and service-related meta data in a persistent manner. More specifically, it holds, user authentication credential information (where necessary) and access tokens that are generated by the ACS and are used from third party services to access and interoperate with BSE endpoints. Furthermore, it stores service-related meta-data that is required or generated by the Brokerage Server (BS) .
• Brokerage Server: In the context of Brokerage Service Environment (BSE), the Brokerage Server (BS) purpose is to facilitate the registration, discovery, and provisioning service. It is built on top of Consul (https://www.consul.io/) which is a service mesh solution providing a full featured control plane with service discovery, configuration, and segmentation functionality. Through Brokerage Server (BS) and the RESTful interface that it implements, a third-party service can get registered, discovered, and queried through the BSE. The BS, interfaces with Service Registry where it stores services’ meta-data in a persistent manner. In addition, where it is necessary from a security or administrative point of view, the BS incorporates Access Control Lists through tokens that can be used to confine each service discovery environment.

DEMETER Brokerage Service Environment

What is the relationship between the BSE and the other DEMETER components?

Access Control System (ACS): provides authentication and authorization functionality.

DEMETER Enabler Hub: DEH id generated in DEH is one of the metadata fields used during a DEE registration in BSE.

Functional Interoperability enabler: offers the compatibility check functionality and is embedded in the registration functionality.

Where can I find more technical information about BSE ?

For more information on BSE, please contact Yannis Oikonomidis (Yannis.OIKONOMIDIS@intrasoft-intl.com).