Technical architecture

This chapter provides a high-level view of the nevisMeta architecture, including a coarse-grained view of component internals as well as a detailed description of the implemented concepts.

Software architecture

The figure below provides an overview of the nevisMeta components. This overview illustrates how nevisMeta is structured and the generic components contained in nevisMeta into which the module-specific components are "injected".

The generic components only make use of the interfaces defined in the common layer while the modules implement these interfaces into concrete types.

The persistence layer defines abstract stores and provides the two implementations mentioned in the chapter Persistence. It serializes and de-serializes documents in those stores. The business logic layer handles modules and provides logical operations on entities such as creation, versioning, importing/exporting, etc. The web console provides a user interface to the general configuration of nevisMeta and shows the defined setups and entities; displaying of specific module content is provided by the particular module. It also provides visual components that can be used by modules to display protocol-specific views in a consistent way. The REST API translates incoming REST requests into operations on the business layer and serializes description objects returned by the protocol modules into JSON documents (depending on the requested format) using JAX-B. Finally, the OAuth 2.0 Module, exemplary for any protocol module, implements concrete classes of Module, Setup, Entities and their States. It also provides JSF facelets that display the entities in read-only or writable modes, and it defines description classes for the REST API. For a further discussion of the most important concepts and interfaces, see the following chapters.

Modules

Each module, at minimum, takes care of the following:

• Implementing the interfaces from common layer: Module, Setup, Entity and State. It also declares/describes those classes such that the web layer knows how to display instances of those classes.
• Providing JSF facelets (located in /META-INF/resources in the module JAR file) that display the entities (both facelets for normal view and edit view) as well as any required models, controllers and converters.
• Serving as the starting point for some complex operations on entities.

In addition to the above, a module may also provide the following:

• It may define persisted data that is not within the defined hierarchy of module > setup > entity > state and is thus displayed in a special way by the module's screen or is not displayed at all.
• It may define additional REST services that are accessed directly instead of via the pre-defined nevisMeta REST services.

Modules know about the business layer but the business layer doesn't know anything about individual modules. In its interaction with a module, the business layer is restricted to the interfaces defined in the common layer.

Setups

A setup is a container for any number of protocol participants (and relevant entities) that need to interact in some way. In nevisMeta, setups define units of configuration where settings may be defined that apply to subsets of entities, namely the ones within the setup. Note that since a setup is also an entity in its own right, all the features mentioned in the chapter below also apply.

Entities and states

Entities are the basic building blocks of a configuration in nevisMeta. An entity has the following features:

• It has a human-readable name that identifies the entity. The name may be changed at any time and no uniqueness checks are made on it (however, nevisMeta internally uses a unique ID). Consequently, it should never be used as a direct reference to an entity.
• It has an owner, which is the only user besides the administrators that is allowed to manipulate the entity.
• An entity has a type that defines how the entity is persisted and loaded.
• An entity may be a VersionedEntity, in which case it has one or more states representing versions of the entity at a different point in time.
• Each state has a validFrom date from which on it gets active (until superseded by another state). In this way, a sequence of states of the entity is formed over time. Each modification of the entity (except for owner and name) requires a validFrom date in the future. If the changes are sufficiently far off in the future (i.e., after the defined time period to refresh the caches of the consumers), then nevisMeta will instruct all consumers of the entity metadata to re-fetch that metadata at precisely the right time.
• A state can be persisted and loaded by the persistence layer.
• A state describes how it is displayed in the web console and how it is serialized and de-serialized in the REST interface.
• States may also be marked as deleted. This means that when a metadata consumer requests an entity when a deleted state is active then the consumer will not see the entity or any of its metadata. This is different from complete deletion (physical deletion) in that the entity is still visible and manageable in nevisMeta and in that it can be restored by adding a state that is not marked as deleted.

Persistence layer

nevisMeta implements persistence on top of MariaDB and PostgreSQL. The persistence layer is typically set up in a fault-tolerant manner. You can use it to provide high-availability persistence for multiple nevisMeta instances. These instances are thus synchronized to offer high-availability themselves.

The storage backend is configured in the main configuration file. See Persistence backend for details on how to configure the storage backend.