In the SNAP architecture a module is 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.
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 SNAP modules may provide well-defined, generic extension points. The platform modules also 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.
SNAP Module-based Architecture
The SNAP architecture solely comprises modules. Modules are the building blocks of the software and every Every module is in fact a plug-in. SNAP comprises a dedicated module 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.
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 ToolboxSNAP, a reader is defined by an abstract interface which allows to instantiate create a CDM from PDM instance from a given data source locator (universal resource locator, URL). Another module may use data access functions of the CDM 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 sections, we further explain the various extension points in the Sentinel ToolboxSNAP.
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 subsystemGUI) 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 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.
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 
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. 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.