Solution design checklist

Designing the eDelivery message exchange infrastructure to be used in your domain includes the design of a message exchange model, a discovery model and a security model.

Even if eDelivery adopts a specific configuration, you are free to set-up your infrastructure as it best fits your needs.

Design message exchange model

In the design of the message exchange model, you will select the most fitting solution in terms of topologies, protocols and integration approach.

Topologies

Topologies define how the different components in the message exchange model interface with each other:

• 2 corner model (or fully connected network). Actors in the exchange network communicate by directly connecting their backend systems.
• 3 corner model (or star network). Actors communicate by linking their backend systems to the same central hub. 
• 4 corner model (or mesh network). Actors communicate with each other through access points. Each backend connects to one access point that conforms to the same technical specifications of all other access points.

eDelivery implements a 4 corner model topology.

Protocols

Among the different protocols, eDelivery adopts the ebMS3 / AS4 profile developed by OASIS. It is based on SOAP web services.

Design discovery model

Next, you will design the discovery model of your infrastructure. This determines how the actors in the network discover the IP addresses and the related attributes of the other participants.

Static model

In a Static model the IP address and related attributes are static. The IP address of all the Access Points in the network are stored on a central location for the other Access Points to reference. To send a message, the sending Access Point looks at the static list of IP addresses on the networks’ Domain Name System (DNS) to locate the Access Point of the receiver.

Dynamic model

Dynamic Service Location enables the sending access point to dynamically discover the IP address and capabilities of the receiver. The sender consults a Service Metadata Publisher (SMP) where information about every participant in the data exchange network is kept up to date. As at any point in time there can be several SMPs, every participant must be given a unique ID that must be published by the Service Metadata Locator (SML) on the network’s Domain Name System (DNS). By knowing this URL, the sender is able to dynamically locate the right SMP and therefore the right receiver.

eDelivery relies on a dynamic discovery model.

Design security model

The security model is based on PKIs (Public Key Infrastructure) and descries the kind of security controls you will implement between corners.

Trust Circles

• Dedicated PKI. A dedicated PKI per policy domain that enables the eDelivery components to trust each other by sharing a common root Certification Authority (CA) certificate as a trust anchor.
• Mutual Exchange of certificates. Each component maintains its own repository of PKI certificates it trusts.
• Domain trusted lists. Service providers use certificates issued by multiple CAs without the need to build complex cross-certification paths.

Through DIGIT (Directorate General of Informatics), eDelivery supports a dedicated PKI infrastructure by establishing a so-called eDelivery CA.

Security controls

In its 4 corner model sample implementation, eDelivery deploys a set of security requirements that map the guidelines of the eIDAS regulation.

Design Integration approach

To determine how backends are integrated with the Access Points, connectors may be built, bought or reused.

Some Access Point products offer advanced integration possibilities whereas others are purely for messaging purposes.

Services Providers may provide integration added-value services and at the same time operate the Access Point.

Write the Service Delivery Document

With all the above clear, you will participate in the creation of the Service Delivery Document (SDD).

The SDD is a document that defines how you reuse eDelivery in your architecture. It provides a useful overview of the solution design, that will be used to coordinate the following phases (set-up and operation) but, most importantly, will help participants become a node in the infrastructure you will set-up.

Develop a proof of concept (optional)

As a final step before setting-up your services, you may develop a proof of concept.

You can leverage on the documentation and support material (e.g. eLearning) produced by the eDelivery technical team to set-up a small scale message exchange network.

This will allow to validate your design and proceed with the next step, the set-up of the solution on full scale.