sws-questionnaires

We discuss here key aspects of the architecture of sws-questionnaires.

Dependencies

A key architectural issue for sws-questionnaires is its remote interface towards the input-system. This splits in two main parts:

• reference: the interface to collect dataset metadata and reference data.

• statistics: the interface to extract and ingest statistical data and metadata.

All interfaces will be accessed behind local interfaces, effectively in an anti-corruption layer that isolates the dependency from the rest of the application's code, first and foremost the integration tests.

Data access patterns vary significantly across interfaces:

• access to reference data is read-only, high-frequency, repeatable, largely anonymous, and mostly interactive (specifications management).

• access to statistical data is instead unidirectional, punctual, varied, secure, and mostly batch (campaign population and questionnaire ingestion).

Relying on a remote interface for reference data might then prove too 'chatty' to grant responsiveness in all cases, and it would reduce the operational autonomy of the application. The repeatibility of requests would imply unnecessary load on both sws-questionnaires and input-system. While client-side caching may alleviate some of the responsiveness issues, server-side caching is a strong architectural requirement.

Caching works well with the assumption of anonymity, because reference data can be accessed on behalf of the application and the cache be shared by users. The cache itself will remain largely hidden to users, though invalidation mechanisms will be made available to administrators.

Ultimately, the cache may be promoted to a knowledge base and make explicit via a dedicated admin console. This is not a requirement at the outset however.

The reasoning is almost inverted when it comes to statistics. A cache here is not necessary and, given the sensitivity of data, it is not desirable either. Here the application will act on behalf of the user based on identity propagation mechanisms.

Stack

The stack of sws-questionnaires follows the blueprint that we've adopted for all the new applications of the Statistical Working Platform.

It is hardly revolutionary, so as to preserve the value of past investments. Like the input-system, sws-questionnaires will:

• runs in Java EE application servers (Wildfly). In particular, it relies heavily on EJB, JAX-RS, and CDI specifications.

• uses relational storage for the persistence of its domain model (Postgres).

It will differ otherwise because:

• the data access API will be provided by JOOQ rather than Spring.

• it will shun the use of JMS messaging for asynchronous behavior, unless it becomes a clear requirement for scale.

• it will shun the use of file-based configuration, so as to encourage a stateless deployment infrastructure.