In the SNAP architecture 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.
The data, logic, presentation, and control subsystems are logical boundaries which can comprise any number of related modules.
A subsystem may contain one or more platform modules which provide well-defined, generic extension points. The platform modules 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.
SNAP Module-based Architecture
The SNAP architecture solely comprises modules. Modules are the building blocks of the software and every module is in fact a plug-in. SNAP comprises a dedicated module 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.
The major advantage of such a loosely-coupled architecture is that extensions may come and go and that the Sentinel toolbox itself is not dependent on particular service implementations. This makes the system fully scalable in terms of functionality and offered services and allows for further extension without adding any complexity to the system therefore ensuring optimal software maintainability and sustainability.
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 the Sentinel Toolbox, a reader is defined by an abstract interface which allows to instantiate a CDM from a given data source locator (universal resource locator, URL). Another module may use data access functions of the CDM 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 sections, we further explain the various extension points in the Sentinel Toolbox.
Another important advantage of such fine-grained modularisation is that the software can be split into modules that implement a graphical user interface (as part of the control subsystem) and others that provide the actual functionality. Such responsibility separation is important for at least two reasons:
- The Sentinel Toolbox is used in a “headless” server environment, where a desktop Graphical User Interface (GUI) is neither required nor available. In this case, GUI modules don’t need to be deployed into the server environment at all.
- The Sentinel Toolbox can be extended to offer alternative GUIs
Both use 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.
SNAP Engine and SNAP Desktop
The figure above shows in horizontal direction the main platform modules and single examples for implementation/extension modules. In vertical direction it shows the Engine modules which can be used in headless environments and the GUI that is dependent on the Engine, but not the other way round.
The Sentinel Toolbox Development Platform (SNAP) is the underlying platform for the Sentinel-1, -2, and -3 Toolboxes currently being developed by ESA. 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.
The version 2 of the Sentinel Toolboxes has been released in November 2015 and includes SNAP version 2, which uses the dynamic, module-based architecture described so far in this section. Users 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. Together with a variety on data readers for a wide range of instruments and data formats, as well as data writers and processors (from BEAM and NEST) heritage, a high level of synergistic data use is provided.
SNAP software stack and architecture
SNAP allows for a highly synergistic use of EO data in a single application.