Building a digital society and digitizing public services both nationally and across borders are hot topics in Europe right now. Standardised and secure data exchange is one of the key enablers that is required to be in place for succeeding in the task. The good news is that there are already solutions and building blocks available that can be used for the job. Instead of reinventing the wheel and building everything from scratch it is possible to use off-the-shelf, battle-proven solutions that have already been successfully used in multiple implementations.
It goes without saying that X-Road is one of the available solutions. Another solution that is often mentioned in the same context is eDelivery – a building block of the Connecting Europe Facility (CEF). X-Road and eDelivery are both data exchange solutions that have been successfully used in multiple implementations in several countries and / or projects. Technically, they are both based on distributed architecture and they are enablers of decentralized data management. At first glance they may seem very similar, even competitors to each other. But is that really the case? Let’s find out.
Architecture
On architectural level eDelivery and X-Road have many characteristics in common as they are both based on four-corner model. The basic idea of the model is that information systems do not exchange data directly with each other. Instead, information systems are connected through additional access points that implement the same technical specifications and therefore are able to communicate with each other. In addition, access points usually provide common features required in data exchange, e.g. message routing, security, logging, authentication etc. Both X-Road and eDelivery also have an address registry and tools for capability lookups that are used in message routing and service discovery.
Image 1. Four-corner model explained through X-Road architecture.
The similarities do not finish there. In both X-Road and eDelivery the trust model is based on digital certificates, and they both guarantee non-repudiation of messages and identities of message exchange parties using digital signatures. In addition, in both cases the message transport protocol used between the access points is based on MIME/multipart messages even if the structure of the messages is not the same. X-Road and eDelivery can be used to exchange both data and documents. In addition, they are both payload agnostic which means that they can be used for transferring any kind of data (structured, non-structured and/or binary), e.g. purchase order, invoice, JSON, XML, PDF etc.
Cross-Border and Cross-Sector Data Exchange
Technically eDelivery supports both cross-border and cross-sector data exchange. However, eDelivery is typically implemented within a policy domain and different policy domains have their own implementations with domain specific operations and management models. In practice, each policy domain creates its own eDelivery subdomain, and all the eDelivery components that belong to the same subdomain trust each other. Usually, a component / participant from one subdomain, e.g. eHealth, is not considered trusted in another subdomain, e.g. eJustice. This means that there are multiple eDelivery subdomains and it might not be possible to exchange data between them.
X-Road's main idea is that it enables data exchange between organisations from different sectors (public, private, non-profit etc.) and different policy domains. X-Road is typically deployed on a national level so that it provides a nationwide data exchange layer for all kinds of organisations across sector and policy domain boundaries. Two X-Road environments can be joined together, federated, which enables cross-border data exchange between the member organisations of the two ecosystems. Federation means that members of two different X-Road ecosystems can exchange data as if they were members of the same ecosystem.
Trust Models
Both X-Road’s and eDelivery’s trust models are based on digital certificates. X-Road and eDelivery both use certificates to secure the communication between access points (TLS encryption), and sign the data and documents that are transferred. In addition, eDelivery also supports encrypting and decrypting the data and documents. In addition, how certificates are managed, configured and distributed differs between the systems.
eDelivery supports multiple trust models and the model that is used can vary between different eDelivery subdomains. Depending on the selected trust model the distribution of the digital certificates may be manual, automatic or something in between.
X-Road supports the use of multiple trust service providers within an ecosystem and the distribution of certificates is always handled automatically by X-Road. Two organisations may use certificates issued by different trust service providers, but this is fully transparent to the user organisations as the exchange and verification of certificates is automated. In X-Road's context, organisations and access points of the same ecosystem always trust each other. The trust can be expanded to cover other ecosystems using federation.
Messaging Models
One of the main technical differences between eDelivery and X-Road is related to supported messaging models. X-Road is based on synchronous communication that is well suited for real time data and document exchange. Instead, eDelivery is based on asynchronous communication that is well suited for reliable, non-time-critical document and data exchange. eDelivery also supports duplicate message detection and message retry / resending scenarios.
The difference between synchronous and asynchronous communication is that in synchronous communication a service consumer sends a request and stays on waiting for a response, but in asynchronous communication a service consumer sends a request and continues processing with other tasks. In synchronous communication the service consumer’s control flow is disrupted until the service provider has processed the service consumer’s request. Instead, in asynchronous communication the service provider sends a response later once it has processed the request.
Connecting Information Systems
Connecting an information system to eDelivery means that the information system must implement the eDelivery AS4 Profile so that communication between an eDelivery access point and an information system is technically possible. This means that an additional adapter or connector is usually required between an access point and an information system. The adapter/connector acts as a converter between the eDelivery AS4 Profile and the information system’s native format. Exchanging all kind of data is supported, but the data must always be wrapped inside a message that conforms the eDelivery AS4 Profile.
X-Road supports two alternative messaging protocols that can be used in the data exchange – a message protocol for SOAP and a message protocol for REST. When the SOAP protocol is used, an additional adapter or connector is usually required, because the data to be transferred must be wrapped inside a message that conforms the X-Road message protocol for SOAP. Instead, when the REST protocol is used, no additional adapter or converter component is required as existing REST services can be published and consumed as-is.
Operations and Management Model
eDelivery prescribes technical specifications that can be used to enable secure and reliable exchange of documents and data, and the specifications are based on standards. There are multiple software, both commercial and open source, available that implement the eDelivery specifications. Organisations are free to choose which software they use when exchanging data using eDelivery. eDelivery is managed through the specifications – once they change, vendors of the implementations update their products accordingly. Operations and management model is policy domain specific – each domain defines its own model and models between different domains may vary.
X-Road is a technical and organizational framework that provides secure and standardised way to exchange data between data providers and consumers over the Internet. Multiple standards are used in X-Road's implementation, but no X-Road specific parts have been standardised. However, X-Road’s source code and all X-Road protocols are open, and documentation is publicly available so anyone is free to create an implementation of X-Road protocol stack. Organisations that want to exchange data over X-Road must install X-Road software's Security Server component. X-Road and its protocol stack are managed as a software product – the protocol stack is managed and developed as a part of the X-Road software product. In addition, X-Road defines an organizational framework that describes the roles and responsibilities of different actors of an X-Road ecosystem.
Conclusions
On high level it may seem that eDelivery and X-Road are very similar, but more detailed review reveals that there are many significant differences between them. Even if they provide many same features and they have many common components on logical level, the implementation details vary greatly.
One of the key differences between eDelivery and X-Road is that eDelivery is a set of technical specifications with multiple implementations, and X-Road is a technical and organizational framework. In other words, eDelivery and X-Road are conceptually two different things. eDelivery is also missing a detailed organizational framework that defines the roles and responsibilities regarding the operations and management of an eDelivery policy domain.
Another important difference is related to the supported messaging models – asynchronous and synchronous communication. Both messaging models have their pros and cons, and it depends on the use case which one is a better a fit. Choosing a wrong messaging model may result in additional complexity which requires more implementation and maintenance effort.
All in all, eDelivery and X-Road are not identical twins and they should not be considered competitors either. X-Road is well suited for synchronous real-time data and document exchange, whereas eDelivery is a good fit for reliable, non-time-critical document and data exchange. Therefore, eDelivery and X-Road are not mutually exclusive, and they can be used side by side to fulfill different kind of data exchange needs. In the future it might be even possible to exchange data between eDelivery and X-Road. NIIS is currently studying alternatives for implementing a gateway between eDelivery and X-Road that would enable data exchange between eDelivery and X-Road ecosystems. A technical proof-of-concept level implementation has already been completed, but there are legal and administrative questions yet to be resolved. However, that’s another story.