As the e-CODEX standard describes some standards that must be used when connecting to other participants in use-cases, the described building blocks are optional as long as those standards are fulfilled and the technical understanding between e-CODEX participants remains stable.
A rough overview on the decentralised e-CODEX network architecture can be seen here:
The Gateway within e-CODEX is the building block that is responsible for the communication between participants of e-CODEX use cases. A gateway used for participating in e-CODEX must have the following standards implemented:
- ebMS 3.0 standard [1]: Gateway interchange messages complying with the ebXML standard. This standard defines the structure one message header must have to be understood among the e-CODEX infrastructure of participants.
- AS-4 messaging profile[2]: This profile is part of the ebMS 3.0 standard and defines the structure one message must have. Additionally, several security rules are specified. Also the technical transportation of messages is described here.
- Non-repudiation: A gateway must ensure that one message must not be delivered twice successfully.
- Reliability: The gateway used implements reliability and “Quality of service” that can be configured since different e-CODEX use cases may have different reliability settings which are defined by the use-case owner.
Whereas it is defined in e-CODEX that any gateway solution fulfilling those requirements mentioned above can be used, e-CODEX implemented its own gateway solution. This gateway is the DOMIBUS[3] gateway which is now under maintenance of the CEF programme of the European Commission.
The DOMIBUS gateway additionally offers features like:
- PMode[4] configuration: the way ebXML messages are sent and processed between two Gateways is defined using PMode files. Those files contain configuration information on how the communication is set up in sense of use-case, involved parties, their technical communication parameters and their roles, security, business processes and reliability. The definition of PModes is also part of the AS-4 profile of the ebMS 3.0 standard.
- Logging: The Logging module enables the administrator to configure log levels and choose the log medium to be used (database or file).
- Plugin interface: The plugin interface allows implementers to develop their own plugin(s) for communicate with the backend(s). Several plugins can be configured in parallel to differentiate use-cases on gateway level and connect different backend solutions. Default plugins are included.
More information regarding the Domibus Gateway, its roadmap, the latest versions and alternative products can be found at CEF's Domibus Website.
The connection of e-CODEX participants on gateway level is also called e-Delivery.
[1] OASIS ebMS 3.0 specification : https://www.oasis-open.org/committees/download.php/24618/ebms_core-3.0-spec-cs-02.pdf
[2] Reference to the official OASIS profile description : http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/AS4-profile-v1.0.html
[3] Official site: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Domibus
[4] Processing Mode
The domibusConnector suite is developed and maintained by the e-CODEX consortium.
The domibusConnector is a linking component to connect national use-case specific applications to the generic messaging standards of the gateway.
According to its particular settings, each e-CODEX participant must perform some adaptations to the messages. The domibusConnector provided by e-CODEX contains a generic set of modules which aims to provide the common functionality which is needed by every participant and every e-CODEX use-case.
The parts specific to each participant will need some specific and dedicated implementation which is to be done on national level. There may be several national backend applications behind the domibusConnector depending on the national structure (different use-cases are handled by different applications).
The domibusConnector implements two workflows, one for sending messages from the national backend system to the Gateway (outgoing workflow) and the other one for receiving messages from the Gateway and forwarding them to the national backend system (incoming workflow).
More details on the features of the domibusConnector and supporting products can be seen here.
Roadmaps
e-CODEX Schemas are developed and maintained by the e-CODEX consortium. They provide a standardised data structure and semantic for several European use cases and ensure the interoperability of the exchanged data.
The CMT is an online tool to manage the collection of participant data and distribution of e-CODEX configuration files.
e-CODEX configuration files are:
- PModes: or Processing Modes. The way ebXML messages are sent and processed between two Gateways is defined using PMode files. Those files contain configuration information on how the communication is set up in sense of use-case, involved parties, their technical communication parameters and their roles, security, business processes and reliability. The definition of PModes is also part of the AS-4 profile of the ebMS 3.0 standard.
- Truststores holding certificates of participants within a business use-case on different level. There are truststores for transportation security, messages security, but also signature validation.
- A security context file defining the level of message security on gateway level.
To be able to generate those configuration files, it is necessary, that each participant uploads its data to the CMT. With an administrative account a participant provides its connection data, uploads the different certificates and may trigger the CfC (Coordinator for Configuration) to generate a new set of configuration files once the data is complete.
In addition to that, the CMT offers features to support participants in maintain their data. Those are for example:
- Recognition e-mail when a new set of configuration files are available.
- E-mail when a new set of configuration reaches production level.
- Trigger when certificates are about to expire.
- Validation of certificates when uploading.
Before going online with your e-CODEX environment, you should perform extensive tests. e-CODEX offers a Central Testing Platform (CTP) to support your testing activities. The e-CODEX CTP provides a full e-CODEX test environment and a Web Interface for sending and receiving test messages.
Read this article to get a basic understanding of the technical concept of the e-CODEX components.
Detailed documentation created during the e-CODEX project (2010-2016):
e-CODEX secures your messages on multiple levels: the transport layer as well as the message layer as well as the document layer provide for the confidentiality, integrity and authenticity of e-CODEX messages. Each layer relys on well-established security standards to meet these goals.