Usage of third party specifications and components

From DE4A
Revision as of 08:24, 26 August 2021 by Antonio.osuna (talk | contribs)
Jump to navigation Jump to search

Overview

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.

In addition to the RepositoryItems, an ebXML Registry is also capable of storing standardized metadata that MUST be used to further describe RepositoryItems. Instances of such metadata are referred to as a RegistryObjects (or one of its sub-types, as described later in this document). RegistryObjects are stored in the registry provided by the ebXML Registry.

To illustrate these concepts we use the library analogy as follows:

  • An ebXML Registry is like your local library.
  • The repository is like the bookshelves in the library.
  • The repository items in the repository are like book on the bookshelves. The repository items can contain any type of electronic content just like the books in the bookshelves can contain any type of information.
  • The registry is like the card catalog. It is organized for finding things quickly.
  • A RegistryObject is like a card in the card catalog. All RegistryObjects conform to a standard just like the cards in the card catalog conform to a standard.
  • Every repository item MUST have a RegistryObject that describes it, just like every book must have a card in the card catalog.

To summarize, ebXML Registry stores any type of content as RepositoryItems in a repository and stores standardized metadata describing the content as RegistryObjects in a registry.

Kafka

References

‎<references />