High-Level Architecture

The Sentinel Toolbox Development Platform (SNAP) is the underlying platform for the Sentinel-1, -2, and -3 Toolboxes. SNAP is built on ESA BEAM heritage incorporating many years of evolution and improvements with respect to API design, processing framework development, and with respect to a common EO data model. This common data model is called the Product Data Model (PDM) and explained in more detail in Product Data Model.

The SNAP architecture solely comprises modules. A module is both a logical and physical software configuration item that has a unique name, a version and comprises both source code and resources. It may depend on other modules, because it uses their exposed application programming interfaces (API) or reuses provided functions and resources.

SNAP modules may provide well-defined, generic extension points. They also define an API that offers the abstract interfaces that extensions to these extension points must adhere to (the software contract). Extensions are provided by further extension modules which provide services such as specific data readers, data writers or data processors. An extension module may itself again define new extension points and expose higher-level APIs.

Every module is in fact a plug-in. SNAP comprises a dedicated plug-in management which allows for dynamic module loading and unloading at runtime. Users can install new extension modules or update installed ones from either a local module file or the remote Sentinel Toolbox module repository. The Sentinel Toolbox also uses the dynamic module management to update its system framework modules from the remote module repository.

A prominent example in the Sentinel Toolbox and many other extensible software is the definition of an extension point that allows to plug-in new or alternative data readers which generate a common in-memory representation of a given data model. In SNAP, a reader is defined by an abstract interface which allows to create a PDM instance from a given data source locator (universal resource locator, URL). Another module may use data access functions of the PDM but it doesn’t need to care about which reader is used to actually read the data from the data source. The reader interface abstracts from any implementation details and also data source details such as the data location or the data formats used. In the following, we further explain various extension points in SNAP.

Another important advantage of such fine-grained modularisation is that the software can be split into modules that implement a graphical user interface (GUI) and others that provide the actual functionality. Such responsibility separation is important for at least two reasons:

1. The Sentinel Toolbox is used in a “headless” server environment, where a desktop Graphical User Interface is neither required nor available. In this case, GUI modules don’t need to be deployed into the server environment at all.
2. The Sentinel Toolbox can be extended to offer alternative GUIs

Both cases indicate that the data, logic, and presentation modules must never depend on certain GUI-providing modules and thus shall not know anything about a related GUI implementation. In SNAP, the separation between GUI- and non GUI-code is acted out to the point that they are situated in different projects: SNAP Desktop (which contains the GUI code) and SNAP Engine (which contains the functionality). In external projects, which do not make the separation, it has become good practice to create separate modules for ui and non-ui code. Note that the GUI is dependent on the Engine, but not the other way round.

Users of the Sentinel Toolbox can decide if they want to also install the Sentinel-1, -2, or -3 Toolbox or any combination of them, because the individual toolboxes are actually sets of modules which can be dynamically plugged into SNAP.