Difference between revisions of "Usage of third party specifications and components"
(→RegRep) |
|||
Line 58: | Line 58: | ||
An ebXML Registry is capable of storing any type of electronic content such as XML documents, text documents, images, sound and video. Instances of such content are referred to as a RepositorytItems. RepositorytItems are stored in a content repository provided by the ebXML Registry. | An ebXML Registry is capable of storing any type of electronic content such as XML documents, text documents, images, sound and video. Instances of such content are referred to as a RepositorytItems. RepositorytItems are stored in a content repository provided by the ebXML Registry. | ||
− | RegRep usage at DE4A project has been limitated to a minimal approach due to the low benefits against the "plain" message, also, until the moment, it there was not definition about the RegRep usage. Nevertheless, the eDelivery implementation at the Connector includes the | + | RegRep usage at DE4A project has been limitated to a minimal approach due to the low benefits against the "plain" message, also, until the moment, it there was not definition about the RegRep usage. Nevertheless, the eDelivery implementation at the Connector includes the the message wrapping into a RegRep specification with basic slots organization and the message obtained is sended via AS4 as a payload. |
==Kafka== | ==Kafka== |
Revision as of 08:21, 1 October 2021
Overview
DE4A project is based on some specifications and components that allows to build new software with some inherited capabilities as security, reliability, integrity and scalability.
At this point some of the main technologies involved will be described.
eDelivery
The CEF eDelivery Building Block helps users to exchange electronic data and documents with one another in a reliable and trusted way.
The CEF eDelivery 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 CEF eDelivery can easily and safely exchange data even if their IT systems were developed independently from each other.
SML
The Service Metadata Locator (SML) is a singleton instance in the DE4A network. It is operated by CEF, a key facility of the European Commission, and provided to the DE4A project at no cost. DE4A is currently operating on the test instance of the SML, called "SMK", and was assigned the DNS zone de4a.acc.edelivery.tech.ec.europa.eu. for the project.
Additionally, CEF provided the project 10 test SMP X.509 certificates based on the "DE4A_TEST_SMP_CA" which is based on CEFs "Connectivity Test Component CA". Only certificates issued by the "DE4A_TEST_SMP_CA" are allowed to register in the DE4A SML DNS zone.
Every SMP (see below) that wants to join the DE4A network needs to register once at the SML using the specific DNS zone and a certificate based on the "DE4A_TEST_SMP_CA".
SMP
The task of a Service Metadata Publisher (SMP) is to create the link between the technical identifiers and the effective endpoint URL to exchange messages with. Additionally, it provides X.509 certificates that will be used to encrypt messages for a specific recipient. Each participant has a list of so called “Endpoints” that are uniquely identified by a combination of a document type identifier, a process identifier and a transport profile. An SMP makes it possible for two parties in the domain to exchange documents with dynamic discovery and utilizing the 4 Corner Model used for eDelivery within the DE4A project.
The information has been structured as follows, based on the SMP schemas outlines:
SMP filed name | DE4A parameter | Description | Example |
---|---|---|---|
ParticipantIdentifier | Participant ID | Unique identifier assigned to each entity involved (DE's/DO's) | Scheme: iso6523-actorid-upis - Value: 9999:egov |
DocumentIdentifier | Canonical Evidence Type | Type of canonical evidence | Scheme: urn:de4a-eu:CanonicalEvidenceType - Value: CompanyRegistration |
ProcessIdentifier | Message Type | Action type (request/response) for a message | Scheme: urn:de4a-eu:MessageType - Value: request |
EndpointURI | AS4 endpoint | Endpoint where the AS4 message will be sent for a certain participant | https://de4a-dev-connector.egovlab.eu/phase4 |
Certificate | AS4 public key certificate | Base64 X.509 certificate for the AS4 gateway | MIIFfzCCA2egAwIBAgICEAkwDQYJKoZIhvcNAQELBQAwajELMAk...(more) |
RegRep
ebXML RegRep is a standard defining the service interfaces, protocols and information model for an integrated registry and repository. The repository stores digital content while the registry stores metadata that describes the content in the repository. An ebXML Registry is capable of storing any type of electronic content such as XML documents, text documents, images, sound and video. Instances of such content are referred to as a RepositorytItems. RepositorytItems are stored in a content repository provided by the ebXML Registry.
RegRep usage at DE4A project has been limitated to a minimal approach due to the low benefits against the "plain" message, also, until the moment, it there was not definition about the RegRep usage. Nevertheless, the eDelivery implementation at the Connector includes the the message wrapping into a RegRep specification with basic slots organization and the message obtained is sended via AS4 as a payload.
Kafka
The Apache Kafka instance running at the DE4A facilities is an open source distributed event streaming platform. In the DE4A project it is used to receive messages from the different services used in the project. The received messages can be viewed online as they are received in the Package Tracker made available for everyone. This is mainly for the purpose of quickly seeing if there are any problems between services and what type of problem i.e. connection problems to help finding issues for pilot partners and developers. The main use case for this is thus distributed event logging and not digital traffic reporting where entire logs are sent and stored off site. The reasoning for this is that the Kafka instance at eGovlab servers is fully open, meaning anyone can read and write messages to that service. To reduce the security risks the Kafka instance on eGovlab premises does not store the sent messages for any longer periods, i.e. the messages are essentially ephemeral.
For the DE4A project the particular setup uses ZooKeeper as the coordinator, Kafka as the broker of messages and the Package Tracker as a web service configured to consume and display any messages received by the Kafka broker. The Package Tracker can only display “live” i.e. any messages received in the past will never be displayed.