Lookup Pattern
Lookup Pattern D2.1:
The lookup pattern is considered for a specific purpose; Its main characteristic is online and near real-time (NRT) use of information. The information is simple, attributes based. This is only applicable in cases where the exchange has a legal basis and can be executed without explicit User consent.
When the required information is not available right away, the process requiring the information stops and needs to be executed again from the start (as soon as the required information is available again).
This pattern requires synchronous communication, i.e. it must be “light weight”. This pattern ties DP and DC closely together: the DC cannot provide its service in case the DP is not available means that DC and DP usually know each other up front and the communication relationship is set up to cover a large number of repetitive interactions over time.
Important document
ISA2 Action ‘Innovative Public Services’: Piloting a REST API extension of CEF eDelivery, 30/10/2020 v1.1
API project in ISA2 Action INNOVATIVE PUBLIC SERVICE
| Source | European Commission |
| Action Owner | CONNECT (DIGIT, JRC). |
| Objectives &
scope |
Develop relevant legal, organizational and technical artefacts trialled through a combination of the CEF eDelivery building block with blockchain-based transactions’ log and a REST-based profile (a.k.a. APIs approach), that support new patterns of data access by request and data sharing. The initiative will facilitate design choices on the legal, organizational, semantic and technical level necessary for setting up APIs. |
The REST-based profile is relevant for DE4A Lookup pattern; however the scope of the API project is wider. The envisaged implementation is an extension of the eDelivery BB. How will this work with already existing APIs in the MSs?
Piloting a REST API extension of CEF eDelivery [1] contains a lot of useful information. What follows is an extract.
Business need
A BB with a profile to cater for the REST API architectural style primarily addressing different architectures and communication patterns than those already supported by the eDelivery AS4 profile. The data exchange would operate in a light context.
The term “light context” refers to a set of constraints and circumstances applying to organisations or environments that do not run (in) an enterprise IT data centre (non-limitative):
- Organisational constraints
- Hardware and IT infrastructure constraints
- “Low throughput” scenarios
- Limitations introduced by sandbox environments
Requirements envisaged specification:
- Simple or automatic installation of the software
- Minimal or zero configuration that assumes no advanced knowledge of the used technology
- Minimal operation and maintenance
- Ease of use with immediate start and no complicated enrolment
- Reduced requirements on the hardware resource
- Reduced access privileges on the host
Legal basis: carried out under the ISA² action on Innovative Public Services, legal artefacts are also envisaged.
Things to consider:
- Number of corners, 2 or more (even >4)
- Communication patterns (7+), but I suppose we could simplify to Synchronous business response (C1 à C2 via http and C1 expects a business response from C2)
- Identity (6 candidates)
- Transport protocols
- Integrity & confidentiality (TLS + message signing option)
- (Q)ERDS
- Custom metadata/semantic mapping
Used by the following use cases
Application collaborations
TBD