De4a-commons library

The de4a-commons project is located on GitHub at https://github.com/de4a-eu/de4a-commons and contains reusable DE4A components that are unrelated to the Connector itself.

The library requires Java 1.8 as the minimum version and builds with Apache Maven 3.

The released versions of the library are both available on GitHub releases as well as on Maven Central with the group ID “eu.de4a”.

The three submodules of de4a-commons are:

• de4a-kafka-client
• de4a-core-schemas
• de4a-canonical-evidences

All the submodules are described below in subchapters.

This library was redesigned between Iteration 1 and Iteration 2, so that the core schemas and the canonical evidence types are clearly separated from each other

de4a-kafka-client

This is a Java API to easily post a message to the DE4A Kafka Server, so that it appears on the shared tracker. This server is mainly a debugging support functionality based on the Apache Kafka technology. The server logs events to simplify the cross-border debugging of evidence exchanges in the absence of a standardised administration GUI.

By default, to access a Kafka Service a TCP connection is required, as this is the most efficient way of communicating. As direct TCP connections are usually prohibited from governmental applications, an additional module was installed on the Kafka server, that allows to send HTTP requests to it. That additional layer reduced the maximum throughput of client and server, but that was irrelevant for us.

The main part of this submodule is configuration code as well as the differentiation between TCP sending and HTTP sending.

de4a-core-schemas

This submodule defines a Java API with the marshallers for reading and writing DE4A Core XML Schemas in an easy way. All the Core XML Schemas are converted into Java domain objects using the JAXB technology. With an additional abstraction layer the reading and writing of XML objects ensuring consistency to the XML Schema is achieved. The XML objects in this submodule can work with any canonical evidence types as long as they are XML based. This includes canonical evidence types that are currently non-existing.

The idea of separating the Core XML Schemas from the Canonical Evidence Types was, on the one hand, to guarantee a clear separation of concerns and, from a practical point of view, also to ensure a clean management of dependencies between these components.

de4a-canonical-evidences

This submodule contains a Java API for all the XML schemas and their corresponding Java domain objects. The domain objects were again created using JAXB and can be used very similarly to the de4a-core-schemas submodule. All the existing canonical evidence types and events are grouped by project pilot area so that the assignment is clear. The underlying concept can also be applied for other types of canonical evidence that are unknown at the time of creation of the library.