Contents

1 Introduction

As explained in Chapter 1, section 6.6, the OOTS architecture uses a hybrid deployment model for the Common Services. This section provides more information on distribution of these services, their configuration, discovery, and use of proxy servers.

2. Common Services Configuration

The data provided by Evidence Broker and Data Service Directory services is logically partitioned in subsets corresponding to the participating Member States. Each of the defined lookup functions includes a parameter to indicate the Member State to which the lookup applies. The OOTS architecture also allows the partition to be reflected in a distribution of the data across multiple component instances. The architecture uses a hybrid deployment model in which:

  • The European Commission will provide an instance into which Member States may upload their data. 
  • Member States may also provide their own instance of the service.

These options are exclusive, meaning that data for a given Member State can, depending on configuration based on the Member State decision, be looked up either in the Commission instance or in an instance provided by the Member State. 

The OOTS has the Member State level as its fixed granularity level, meaning that a Member State has either no instance of the Common Service (if it uses the Commission provided instance) or one (if it provides its own instance), but never more than one. It is therefore not possible to, for example, have multiple Data Service Directories for different regions of a Member State.

Note that, over time, a Member State may decide to move the management of its Common Services data from the Commission provided instance to an instance it provides itself, or vice versa. Also, a Member State may also decide to provide one service itself but not the other. For example, a Member State could provide its own Data Service Directory but use the Commission instance of the Evidence Broker.

In addition to being partitioned geographically, common service data and instances are further partitioned according to other criteria. This version of the OOTS supports two such other criteria: production use versus test use and the technical interface version. The latter is intended to support potential migration to future incompatible versions. 

3. Discovery of Common Services

Depending on the option selected by the Member State, lookups must be directed to either the instance provided by the Commission or by the instance provided by the Member State, and similar routing decisions apply for the production/test environment or interface version use. A clear, unambiguous and up to date overview of all instances of the Common Services, for all Member States, for all environments and for technical interface versions is needed and will be provided using the following two mechanisms:

  1. Overview tables on a restricted area (to be created) of the OOTS Collaborative Space.  
  2. An online DNS-based discovery service. 

The DNS-based discovery service is similar to and inspired by the OASIS BDXL specification which is used in combination with eDelivery. It uses the mechanism of URI-enabled Naming Authority Pointer (NAPTR) DNS resource records as defined in IETF RFC 4848. For use in OOTS, the Commission shall provide a DNS name template. The template shall include placeholders that are to be substituted for the following parameters:

  • The type of common service.  Values are “eb” for Evidence Broker service) or “dsd” for Data Service Directory service.
  • The geography area. Values are ISO 3166 ALPHA-2 country codes for EU Member States.
  • The major version number of the interface of the service instance preceded by the letter “v”. The initial major version number shall be indicated using the string “1”.
  • The environment that the instance supports. The string value “prod” shall be used for the production use.

Available service instances shall be mapped to DNS names that instantiate the template with appropriate substitutions for the four above-mentioned parameters. The Commission will communicate the exact format of the template as part of the rollout of the OOTS common services.  

For the created names, the Commission will provide NAPTR resource records as follows:

  • Record type: “NAPTR”
  • Flag: “u”
  • Service parameter: “”
  • Value: the HTTPS URI of the service encoded using the restricted regular expression syntax defined in section 2.2 of RFC 4848.

The registered HTTPS URI shall be the base server URL of the common service as defined in section12.2 of OASIS ebRS, i.e. the HTTPS URI including the domain root name, without the “/rest/search?q..” part.

The following example is hypothetical record content that could be associated with DNS query strings for all the Member States that use the instance provided by the European Commission. 


IN NAPTR 100 10 "U" "" "!.*!https://dsd.prod.v1.oots.ec.europa.eu!" .  

The following equally hypothetical example shows a sample record for the situation in which Germany would operate its own test DSD. 


IN NAPTR 100 10 "U" "" "!.*!https://test.dsd.once-only.bund.de!" .  


When requesting data, Common Service clients shall substitute the placeholders in the template by the requested values prior to making DNS requests. They shall then extract the service root (i.e. for the example "https://dsd.prod.v1.oots.ec.europa.eu") and append the predefined path components (i.e.  "/rest/search?q.. ") to construct the HTTP client request.

3. Proxy Caching

Data served by the OOTS common services is expected to be highly static and very suited to use in combination with caching proxy servers.

Member States are strongly recommended to route requests to the OOTS Common Services via caching proxy servers in order to:

  • Reduce the load on common services.
  • Reduce the latency on OOTS client applications.
  • Add fault tolerance in case the origin server is not accessible.

Server implementation of common services shall be configured to set the caching related HTTP headers as described in RFC 7234 to enable caching and to ensure that responses retain their considered freshness sufficiently. 

To enable caching, the proxy should terminate TLS connections from its clients and establish its own TLS connections to the origin servers. This is not problematic as the data is not sensitive and its integrity is protected using the response signatures, which the clients shall validate.

4. References

OASIS Business Document Metadata Service Location Version 1.0. http://docs.oasis-open.org/bdxr/BDX-Location/v1.0/os/BDX-Location-v1.0-os.pdf

OASIS ebXML RegRep Version 4.0 Part 2: Services and Protocols (ebRS).  https://docs.oasis-open.org/regrep/regrep-core/v4.0/os/

RFC 4848.  Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) https://datatracker.ietf.org/doc/html/rfc4848

RFC 7234.  Hypertext Transfer Protocol (HTTP/1.1): Caching.  https://datatracker.ietf.org/doc/html/rfc7234. 


  • No labels