We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Data.ElectronicMessageExchange R5 - FIWARE Forge Wiki

FIWARE.OpenSpecification.Data.ElectronicMessageExchange R5

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Data.ElectronicMessageExchange
Chapter Data/Context Management,
Catalogue-Link to Implementation Domibus
Owner European Commission, CEF-EDELIVERY-SUPPORT@ec.europa.eu)

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.

Contents

Copyright

  • Copyright © 2012-2016 by the European Commission

Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (implicit patents license) to understand the rights to use these specifications.

Please check the European Union Public Licence (EUPL) to understand the rights to use the sample software implementing these specifications.

Overview

The Electronic Data Exchange GE implements a standardised message exchange protocol (based on an e-SENS AS4 profile) that ensures interoperable, secure and reliable data exchange of single or groups of payloads in any structured or unstructured format through Access Points.

The solution is based on a distributed model called the “4-corner model”. In this model, the back-end systems of the users don’t exchange data directly with each other but do this through Access Points. These Access Points are conformant to the same technical specifications and therefore capable of communicating with each other. As a result of this, users adopting the Electronic Message Exchange GE can easily and safely exchange data even if their IT systems were developed independently from each other.

Basic Concepts

The 4 corner model

In order to understand how the Electronic Data Exchange GE works, it is important to understand the 'four-corner' message exchange model as presented in figure 1. In this message exchange model a message passes through four “corners” on its way from the Original Sender to the Final Recipient:

Corner 1 (C1) - the sending backend system of Original Sender

Corner 2 (C2) - the sending Access Point

Corner 3 (C3) - the receiving Access Point

Corner 4 (C4) - the backend system of the Final Recipient


Figure 1: Four Corner Model

Domibus

Domibus is a sample implementation of a AS4 conformant Access Point based on the e-SENS AS4 profile. The Domibus core is maintained and supported by the European Commission. However, the users of the sample implementation remain fully responsible for the integration with backend systems, deployment and operation. While users are free to create their own fork from the Domibus core, if they do so they will have to maintain and support it themselves. The Domibus core exposes an internal API which allows the creation of one or more customised plugins for Domibus . CEF eDelivery is responsible for the default plugins, not the customised ones. However, CEF eDelivery offers a service to validate the customised plugins. To facilitate the creation of a custom plugin CEF eDelivery provides an internal API that is fully documented.


Figure 2: Domibus Components

Generic Architecture

Figure 3 shows a logical architecture of the Electronic Data Exchange GE providing a high-level view of the main packages composing the system. The Database persistence and file system persistence are logical packages representing the physical data storages used by the platform. The others represent different application layers and give an overview of the organisation of the platform's code.

Figure 3: Domibus logical view

Back office system (Corner 1/4)

The whole purpose of Domibus is to connect different back office systems via structured, secure message exchange. While, regarding a single message exchange, corner 1 and 4 are usually different applications running in different environments, within a single deployment the role of corner 1 and corner 4 (for different message exchanges) is usually occupied by the same application. Therefore, from a logical point of view, corner 1 and 4 are the same package.

Domibus plugin implementation

This module is responsible for the communication between the back office system and Domibus and for the mapping from the back office internal data format to Domibus internal data format. The communication and the mapping of the data can be done in both directions. Integration into existing security architecture can also be implemented here. As there can be made few assumptions about the back office system, this module is commonly implemented by the Domibus user. Details on this process can be found inside the Domibus plugin cookbook.

Domibus default plugins

Domibus provides two default plugins, a Web Service plugin and JMS plugin, which serve for testing purposes and as examples for custom implementations. They were initially developed to accommodate the needs of the e-CODEX project and thus will not be suitable for every use case.

Domibus plugin API

This package contains all necessary interfaces and classes required to implement a Domibus plugin

Domibus MSH (Corner 2/3)

The Domibus MSH (Message Service Handler) is the main module, representing corner 2 and/or 3 in a 4-corner message exchange. All the implementation relevant to the e-SENS AS4 profile is done inside this package. It is deployable on any Container supporting the Java Servlet Specification v 3.0. To support the required AS4 retry mechanisms a spring configured cronjob regularly checks for messages that need to be resent. The cronjob is configured using spring (domibus-configuration.xml) on property: “domibus.msh.retry.cron”. This does not configure the retry interval for messages (which is done via PModes).

Administrative GUI

This package contains of a Spring MVC web application providing basic monitoring and configuration options.

PMode generator

The PMode generator is an external tool which is able to create a set of XML PMode configuration files (one for each Domibus MSH in the network) using a proprietary domain specific language (pconf). This generator is implemented with Xtext.

PMode command line tool

The PMode command line tool is a maven project which is able to generate XML PMode configuration files from a pconf file via command line

PMode Eclipse plugin

The PMode Eclipse plugin is an extension to the open source Eclipse development environment. It provides editing capabilities for pconf files including code completion and syntax highlighting.

Main Interactions

The use cases used to describe the interactions between Domibus and the backend systems (C1 and C4) in the next subsections only cover the use of the default WS plugin. The default JMS plugin offers additional ways to interact with Domibus, but is not further detailed in the subsections below.

Backend C1 interactions (for the default WS plugin)

Figure 4: Backend C1 use cases diagram for the default WS plugin


ID

Use Case

Short Description

Operation

UC01

Send Message

Submit any type of document from an Backend C1 to a Backend C4

sendMessage

UC03

Get Status of the Message

Get the status of the Message

getMessageStatus


Backend C4 interactions (for the default WS plugin)

Figure 5: Backend C4 use cases diagram for the default WS plugin


ID

Use Case

Short Description

Operation

UC02

Download Message

Download the message from the Receiving AP C3

downloadMessage

UC03

Get Status of the Message

Get the status of the Message

getMessageStatus

UC04

ListPending Messages

Check the pending messages to be downloaded by the Backend C4 from C3

listPendingMessages

Basic Design Principles

Size

Size restrictions applied on the data that is exchanged by the back office systems, but not on the application or its components themselves, have an impact on the architecture and on the configuration of the system. Additionally payloads can be stored on the file system instead of the database to avoid the processing of huge blobs. As the e-SENS AS4 profile provides no provisions for ebMS large file handling (split/join) the transfer of data is limited by bandwidth and memory constraints. Extra restrictions can be implemented via the business process PModes. These restrictions concern the maximum size of a payload and the maximum number of payloads in a message.

Performance

An important architectural decision that benefits the performance of Domibus includes the decoupling of the solution into corner 1/4 representing the back office systems and corner 2/3 representing the Domibus MSH. The back office systems (corner1/4) interact with the Domibus MSH (corner 2/3) via the interfaces (web services, JMS, REST, etc) exposed by the plugins deployed on the Domibus MSH side. Domibus MSH is using internally JMS queues to perform the processing of the messages coming from the back office systems via the plugins or from other access points. All this architectural decisions lead to an improved throughput and load distribution of the messages.

Extensibility

Domibus is designed in a layered fashion and consists of multiple interconnected modules. This modular design facilitates the upgrades by replacing existing modules and extensions by adding additional modules.

Reliability

The reliability of Domibus is enhanced through the decoupling of each architectural layer by JMS queues. A store and forward mechanism and automatic retry policy ensures that parts of the system can continue functioning without losing data when an issue occurs in a specific component.

Portability

Currently the application can be deployed on Tomcat 8, WebLogic 12.1.x and WildFly 9.0.2 and can connect to Oracle and MySQL databases. With minor changes, it might be deployed on any Java Servlet 3.0-compliant server and it might connect to any RDBMS (Relational Database Management System). Besides being extensible, Domibus is carefully designed in such a way that it is independent of the specific external system that communicates with. The use of a generic plugin API leaves the different layers unaffected when an additional external systems need to be supported by Domibus. The usage of JPA to access the database makes it easy for implementers to change the relational database used to store the platform data.

Security

The Domibus middleware provides built-in security in accordance to the implemented specification and industry best practices. It can also be easily integrated into existing security domains.

On top of the security that Domibus provides, the user shall take additional security measures according to best practices and regulations. This includes, but is not limited to, using firewalls, IP whitelists and file system/database encryption. DIGIT shall not be held responsible for any security breach that might occur due to User not respecting this recommendation.

Corner 1 - Corner 2 Communication

As no assumptions can be made about the security architecture of corner 1/4 (back office), the integration into the existing architecture has to be provided by the Domibus plugins. The default WS plugin provide basic and certficates authentication and can be easily extended to accommodate most of the security requirements.

Corner 2 – Corner 3 Communication

The communication between corner 2 and corner 3 is able to fulfil all the security requirements specified in the e-SENS AS4 profile. The configuration is handled via WS-Policy files and PMode configuration. All webservice security is enforced by the Apache CXF framework.

  • Certificate Configuration: The location and credentials of private and public certificates used by CXF are configured in the “domibus-security.xml” spring configuration file.
  • Client Certificate: The client certificate for use with client authentication (two-way SSL) is configured in the “clientauthentication.xml” spring configuration file. Incoming TLS secured connections terminate at the proxy server (e.g. Apache httpd) and must be configured according to the employed proxy servers documentation.

Corner 3 – Corner 4 Communication

The security between corner 3 and corner 4 is handled via the same mechanisms used in the communication corner 1 – corner 2.

Administrative Sites

Access to the domibus administration page is secured with username/password. The credentials are managed by a Spring authentication manager and multiple authentication providers can be plugged into it By default, the credentials are stored in the Domibus-security.xml file and they are managed by an authentication provider that uses a Bcrypt strong hashing function for encoding them. Integration into an existing authentication scheme (i.e. LDAP) can be performed via Spring configuration.

References

[1]

Domibus Software Architecture Document

[2]

Domibus Interface Control Document for the Default WS Plugin

[3]

Domibus Interface Control Document for the Default JMS Plugin

Detailed Specifications

Re-utilised Technologies/Specifications

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Data refers to information that is produced, generated, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. Data in FIWARE has associated a data type and avalue. FIWARE will support a set of built-in basic data types similar to those existing in most programming languages. Values linked to basic data types supported in FIWARE are referred as basic data values. As an example, basic data values like ‘2’, ‘7’ or ‘365’ belong to the integer basic data type.
  • A data element refers to data whose value is defined as consisting of a sequence of one or more <name, type, value> triplets referred as data element attributes, where the type and value of each attribute is either mapped to a basic data type and a basic data value or mapped to the data type and value of another data element.
  • Context in FIWARE is represented through context elements. A context element extends the concept of data element by associating an EntityId and EntityType to it, uniquely identifying the entity (which in turn may map to a group of entities) in the FIWARE system to which the context element information refers. In addition, there may be some attributes as well as meta-data associated to attributes that we may define as mandatory for context elements as compared to data elements. Context elements are typically created containing the value of attributes characterizing a given entity at a given moment. As an example, a context element may contain values of some of the attributes “last measured temperature”, “square meters” and “wall color” associated to a room in a building. Note that there might be many different context elements referring to the same entity in a system, each containing the value of a different set of attributes. This allows that different applications handle different context elements for the same entity, each containing only those attributes of that entity relevant to the corresponding application. It will also allow representing updates on set of attributes linked to a given entity: each of these updates can actually take the form of a context element and contain only the value of those attributes that have changed.
  • An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. Events typically lead to creation of some data or context element describing or representing the events, thus allowing them to processed. As an example, a sensor device may be measuring the temperature and pressure of a given boiler, sending a context element every five minutes associated to that entity (the boiler) that includes the value of these to attributes (temperature and pressure). The creation and sending of the context element is an event, i.e., what has occurred. Since the data/context elements that are generated linked to an event are the way events get visible in a computing system, it is common to refer to these data/context elements simply as "events".
  • A data event refers to an event leading to creation of a data element.
  • A context event refers to an event leading to creation of a context element.
  • An event object is used to mean a programming entity that represents an event in a computing system [EPIA] like event-aware GEs. Event objects allow to perform operations on event, also known as event processing. Event objects are defined as a data element (or a context element) representing an event to which a number of standard event object properties (similar to a header) are associated internally. These standard event object properties support certain event processing functions.


CEF eDelivery specific terms and definitions can be found on the CEF Definitions page.

Personal tools
Create a book