Difference between revisions of "DBA 2nd iteration Solution Architecture"
Line 317: | Line 317: | ||
==== Component description ==== | ==== Component description ==== | ||
+ | example | ||
+ | {| class="wikitable" | ||
+ | |Component | ||
+ | |Short description of its use | ||
+ | |- | ||
+ | |Evidence service locator (ESL) configuration file | ||
+ | |As the DBA pilot’s MVP uses just one type of evidence, with just one data provider per Member state (on NUTS0 level), there is no need for dynamic discovery of the data provider and its data services. For the DBA pilot it is sufficient to use a simple configuration file with the required elements (member state and participant id). | ||
+ | |- | ||
+ | |SMP | ||
+ | |For each evidence request and response, information on the receivers Access Point (URL) and its certificates are needed. Each member state hosts an SMP for this purpose. Before sending a request or response, the sending party queries the SMP of the receiver to get this info. | ||
+ | |- | ||
+ | |DNS & SML | ||
+ | |As there are multiple SMP’s, the sending party needs to know where to find the SMP of the receiver to get the actual metadata. This location can be found in the centrally CEF-hosted DNS, that will be queried by the access point of the sending member state. | ||
+ | |||
+ | DNS entries will be created from the registration of SMP’s: the SML, which is also centrally hosted by CEF. | ||
+ | |- | ||
+ | |eDelivery AS4 gateway | ||
+ | |This component – also referred to as eDelivery access point – handles the secure transfer of the data, including encryption and decryption as well as signing/sealing and validating signatures/seals. | ||
+ | |- | ||
+ | |DE4A Connector | ||
+ | |The DE4A connector is the reference software that data requestors and data transferors can use to connect to the OOP TS. This eases the work by abstracting the communication with the components. | ||
+ | |} | ||
==== Requirements ==== | ==== Requirements ==== | ||
Line 323: | Line 345: | ||
==== Expected logical interfaces ==== | ==== Expected logical interfaces ==== | ||
+ | example | ||
+ | {| class="wikitable" | ||
+ | |Component | ||
+ | |Expected interface | ||
+ | |- | ||
+ | |Evidence service locator (ESL) configuration file | ||
+ | |IN (from DE4A connector to ESL configuration file): | ||
+ | |||
+ | - Member state | ||
+ | |||
+ | - Canonical evidence type | ||
+ | |||
+ | OUT from ESL configuration file to DE4A connector): | ||
+ | |||
+ | - participant ID | ||
+ | |- | ||
+ | |SMP | ||
+ | |IN (from DE4A connector to SMP): | ||
+ | |||
+ | - Participant ID | ||
+ | |||
+ | OUT (from SMP to DE4A connector): | ||
+ | |||
+ | - Service URL | ||
+ | |||
+ | - Certificate to use | ||
+ | |- | ||
+ | |DNS & SML | ||
+ | |IN (from DE4A connector to DNS): | ||
+ | |||
+ | - Member state | ||
+ | |||
+ | - Participant ID | ||
+ | |||
+ | OUT (from DNS to DE4A connector): | ||
+ | |||
+ | - SMP location | ||
+ | |- | ||
+ | |eDelivery AS4 gateway | ||
+ | |IN (from DE4A connector to eDelivery AS4 gateway): | ||
+ | |||
+ | - evidence request | ||
+ | |||
+ | OUT (from eDelivery AS4 gateway to DE4A connector): | ||
+ | |||
+ | - Evidence response | ||
+ | |- | ||
+ | |DE4A Connector | ||
+ | |IN (from data evaluator to DE4A connector): | ||
+ | |||
+ | - Data evaluator | ||
+ | |||
+ | - Data evaluating Member state | ||
+ | |||
+ | - Requested evidence type | ||
+ | |||
+ | - Company identification (eIDASLegalPersonID, eIDASLegalName) | ||
+ | |||
+ | - Data providing Member state | ||
+ | |||
+ | |||
+ | OUT (from DE4A connector to data evaluator): | ||
+ | |||
+ | - Data providing member state | ||
+ | |||
+ | - Data provider | ||
+ | |||
+ | - Evidence type | ||
+ | |||
+ | - Company identification (eIDASLegalPersonID, eIDASLegalName) | ||
+ | |||
+ | - Evidence (XML) | ||
+ | |} | ||
=== DC-specific solution === | === DC-specific solution === |
Revision as of 12:15, 27 July 2021
Introduction
Approach: we follow the SA as was done for Intermediation (1st iteration)
Scope and focus
- Within scope
- Modify DO/DE Mocks for S&N en Lookup patterns
- Common component voor Cross-border subscriptions (optional for MS to use, i.e. not mandatory)
- Event Notification + Evidence Lookup flavour, in line with PSA 2nd iteration
- Outside scope
- Resend a subscription request in case of an error (instead the possibility to inspect the logs and manually resend a request is deemed sufficient (MVP))
- Include the Evidence in the notification (instead pure notification + lookup)
- Attribute Lookup
DE4A preconditions
Design choices
Describe what WON'T be implemented for the pilot as well as design choices (see also scope section)
eIDAS and OOP TS
DBA eIDAS solution
Process realisation
Mapping processes/activities to application services and components (PSA --> tables).
Component description
Classify components: DE/DO/Common component.
Requirements
Describe the requirements for application services.
Component Implementation
Describe the implementation of the components.
Expected logical interfaces
Describe the (logical) interfaces between the components.
DC specific solution
Process realisation
Component description
Requirements
Component implementation
Expected logical interfaces
DP specific solution
Process realisation
Component description
Requirements
Component implementation
Expected logical interfaces
DBA OOP TS solution
Maybe this is the place to insert explanation of the subscription application collaboration (and notification?), i.e. front-end/back-end w.r.t. notifications.
The shared solution for the OOP TS consists of all common functionality of the OOP technical system. Most of the common OOP TS components need to be implemented by the data requestor and data transferor, although the OOP TS uses central components as well.
Image might need an update, i.e. depict S&N and LKP shared stuff
The OOP TS domain (WP5) provide the data requestor and data transferor with the components needed for
- cross-border subscription and notification messages
- performing the lookup of an evidence
In the MVP the DBA pilot uses one type of subscription message and one type on notification message that all DC’s and DP’s involved will use. The subscription message is for subscribing to cross-border events generated at the DP. The notification message is for notifying the DC of such events. If the DC desires the Evidence can be retrieved using the Lookup. This implies an update of the IEM (WP3). There will be just one data provider per Member state: the business register, where the subscription will be recored and where the cross border events are generated, i.e.is the authentic source of company information. The DC will subscribe in one Member State at a time. The DP will notify one Member State at the time. The explicit request and the preview functions won't be needed, in both interaction patterns there is no user involvement.
Process realisation
work in progress...
Subscription
Based on definition on MVP some rows might disappear, i.e. for now the tables are complete w.r.t. PSA
Process | Application Service | Components |
Initiate subscription (DC) | Subscription Initiation | |
Change subscription (DC) | Subscription Initiation | |
Lookup event provider routing information (DC) | Inquire Routing Information | |
Send subscription request (DC) |
|
|
Validate subscription request (DP) |
|
|
Evaluate subscription request (DP) | Subscription Evaluation | |
Exception: Prepare subscription error message (DP) | Subscription Error Handling | |
Exception Send subscription error message (DP) |
|
|
Exception: Forward subscription error (DC) | n/a | |
Exception: Investigate reason for subscription error (DC) | n/a | |
Register subscription (DP) | Subscription Creation and Update | |
Confirm subscription (DP) | Subscription Confirmation | |
Send subscription confirmation (DP) |
|
|
Forward confirmation (DC) | n/a | |
Log subscription information (DC) | n/a |
Notification
Process | Application Service | Components |
Identify event (DP) | Cross-border Event Filter | |
Check subscriptions (DP) | Subscription Lookup | |
Prepare notification message and subscriber list (DP) | Notification Message and Subscriber List Preparation | |
Exception: Resend past events (DP) | Manual Event Dispatch | |
Resolve service metadata (DP) | Inquire Routing Information | |
Exception: Resolve subscriber participant ID and inform National Contact Point (DP) | Subscription Mismatch Log | |
Send event notification (DP) |
|
|
Validate event notification (DC) |
|
|
Determine event response (DC) | Event Evaluation | |
Request change of subscription (DC) |
|
|
Dismiss event (DC) | Update Notification Response Log | |
Trigger evidence lookup (DC) | Update Notification Response Log | |
Notify Responsible Organization (DC) | Update Notification Response Log |
Lookup
Note: compared with Intermediation the user is absent.
Process | Application Service | Component |
Determine required cross-border evidence (DC) | Cross-border Evidence Matching | |
Lookup routing information (DC) | Inquire Routing Information | |
Request evidence (DC) |
|
|
Evaluate evidence request (DP) |
|
|
Establish subject identity (DP) | Identity/Record Matching | |
Communicate non-availability of OOP |
|
|
Extract evidence (DP) | Evidence Lookup | |
Communicate non-availability or Delay of evidence (DP) |
|
|
Establish non-availability of OOP (DC) | Evidence Request Tracker | |
Compose evidence response (DP) | Domestic to Cannonical Evidence Transformation | |
Transfer evidence (DP) |
|
|
Forward evidence (DC) |
|
|
Evaluate evidence (DC) | Requirements/Evidence Matching |
Component description
example
Component | Short description of its use |
Evidence service locator (ESL) configuration file | As the DBA pilot’s MVP uses just one type of evidence, with just one data provider per Member state (on NUTS0 level), there is no need for dynamic discovery of the data provider and its data services. For the DBA pilot it is sufficient to use a simple configuration file with the required elements (member state and participant id). |
SMP | For each evidence request and response, information on the receivers Access Point (URL) and its certificates are needed. Each member state hosts an SMP for this purpose. Before sending a request or response, the sending party queries the SMP of the receiver to get this info. |
DNS & SML | As there are multiple SMP’s, the sending party needs to know where to find the SMP of the receiver to get the actual metadata. This location can be found in the centrally CEF-hosted DNS, that will be queried by the access point of the sending member state.
DNS entries will be created from the registration of SMP’s: the SML, which is also centrally hosted by CEF. |
eDelivery AS4 gateway | This component – also referred to as eDelivery access point – handles the secure transfer of the data, including encryption and decryption as well as signing/sealing and validating signatures/seals. |
DE4A Connector | The DE4A connector is the reference software that data requestors and data transferors can use to connect to the OOP TS. This eases the work by abstracting the communication with the components. |
Requirements
Component implementation
Expected logical interfaces
example
Component | Expected interface |
Evidence service locator (ESL) configuration file | IN (from DE4A connector to ESL configuration file):
- Member state - Canonical evidence type OUT from ESL configuration file to DE4A connector): - participant ID |
SMP | IN (from DE4A connector to SMP):
- Participant ID OUT (from SMP to DE4A connector): - Service URL - Certificate to use |
DNS & SML | IN (from DE4A connector to DNS):
- Member state - Participant ID OUT (from DNS to DE4A connector): - SMP location |
eDelivery AS4 gateway | IN (from DE4A connector to eDelivery AS4 gateway):
- evidence request OUT (from eDelivery AS4 gateway to DE4A connector): - Evidence response |
DE4A Connector | IN (from data evaluator to DE4A connector):
- Data evaluator - Data evaluating Member state - Requested evidence type - Company identification (eIDASLegalPersonID, eIDASLegalName) - Data providing Member state
- Data providing member state - Data provider - Evidence type - Company identification (eIDASLegalPersonID, eIDASLegalName) - Evidence (XML) |
DC-specific solution
Probably makes sense to split (two images) in notification and subscription