SNAP comprises the underlying API and framework modules of at least the data, logic, presentation and control subsystems. It defines the core CDM, and includes a number of common utility components that support plugin development.For For SNAP we reuse and extend the same extensibility design concept that has been used for BEAM and NEST and that is a commonly accepted object-oriented design pattern for enterprise applications. It works as follows:
A module provides the code for one or more plugins. As described in the section on the High-Level Architecture, modules can be dynamically installed and updated. If a module is installed or updated, new plugins are registered in the system or existing ones are replaced by new versions. If a module is uninstalled, its plugins are removed from the platform. Plugin management takes place as part of a module’s life cycle which is controlled by the platform and which is transparent to the module developer. When a plugin is declared in a module, the platform can recognize it. For the GUI we reuse use the very well documented, elaborated, and powerful NetBeans Platform extension concept (see The NetBeans Platform [https://netbeans.org/features/platform/]). For SNAP Engine modules we only use the basic, widely known JAR SPI concept (see Creating Extensible Applications, [https://docs.oracle.com/javase/tutorial/ext/basics/spi.html]), as we do not want any dependencies from the SNAP Engine to SNAP desktop.
A plugin is a software component that adheres to the contract of a service provider interface (SPI). The abstract SPIs are part of the APIs exposed by SNAP, namely the APIs of the data, logic, presentation and control subsystems. Very importantly, the . The following abstract SPIs are part of the platform APIs SNAP Engine API and defined for the following plugins:
- Data Reader plugins used to read/ingest data from external sources into an in-memory CDM PDM instance which then continues to use the reader to load data when requested (data subsystem)
- Data Processor plugins that transform a source CDM PDM instance into a new target CDM PDM instance or modify the source CDM (logic subsystem)
- Data Writer plugins that transform a CDM PDM instance into any external data types and formats which . This is useful for saving or exporting or otherwise representing entire CDM instances or parts of it (presentation subsystem)whole or partial PDM instances.
- Actions (appearing in menus and toolbars), diagram or 2D/3D-image views, tool windows (dockable editor windows for selected CDM PDM nodes or views), preferences pages plugins, etc. that provide extensions to the GUI or command-line option plugins that provide extensions to the CLI (both control subsystem).
As the name indicates, a concrete SPI is a factory and sometimes a proxy for the actual service to be used in the software. For example, the data reader SPI defines at least two abstract method that a concrete SPI implementation must provide. One method checks if a given input object (file pointer, stream, URL) can be opened and interpreted by this type of data reader and the . The second , - the factory method , - instantiates the actual reader service for the given input object, including optional parameterisation, which is finally used to read from the input object.
To further explain the generic SPI concept, the SPI for GUI actions might just provide the menu text and icon and the actual action’s Java class name, the actual action (service) is only instantiated and invoked once the user clicks the corresponding GUI component generated for the SPI by the platform. Action SPIs are configured in an XML file as part of the GUI extension module. In the NetBeans RCP, this XML file is called layer.xml and is stored as a resource in the module’s Java archive file.
Available plugins are detected on start-up time of the Sentinel Toolbox and automatically made available to other application modules by dedicated plugin registries, which are again made available through each subsystem’s APIs. The application can then populate, e.g., a processor library tool window or the data import/export menus. During application runtime plugin-providing modules can be updated, added or removed from the application using the plugin manager of the Sentinel Toolbox.
In addition to extending SNAP via plugins, it is also possible using the Toolbox’ SNAP libraries for use in other applications. E.g. a user For instance, a developer might want to write software that makes direct use of SNAP functions via the platform APIs. Both use cases, namely Toolbox reuse and toolbox extension are shown in the following figure:
SNAP API Use Cases
Use case #2 indicates that the toolbox allows extensions to use both native Python and Java plugins. "Native" means that programmers can use a dedicated API based on a CDM using maximum runtime performance and data transfer rate. It also allows to invoke any other external executable, e.g. as a node in a processing graph or invoked from the Toolbox ' GUI. Use case #1 is the use of existing platform libraries (including extensions) via Python and Java in client software.
...
SNAP provides a native Python bridge, which makes it possible to (a) use the SNAP libraries and its Java plugins from Python and (b) to implement SNAP processor extensions in Python. The SNAP Python Bridge also allows for the use of R (via the Python rpy2 module). As processor plugins can be written in Python, it is straight forward to implement a Python processor that makes use of R code.
For all of the subsystem APIs, we developed user-friendly wrapper APIs Wrapper APIs for Python and R allowing enable developers to access the Sentinel Toolbox capabilities and services programmatically from their own code and analysis workflows. For example, the data access functions of the CDM will for Python return Python-specific data arrays and will internally make use of for Python while internally they use the modules implemented in Java.
...
The Sentinel Toolbox can and will not solve all user needs. Users will still wish to utilize other tools that are external to the Toolbox and that either provide functionality not provided by the Toolbox or that implement a desired functionality in a different way. In many cases, it is more comfortable and more effective if users can stay in one environment. SNAP lets users (a) integrate their desired external tools into the Toolbox, and (b) add external tools to the Toolbox' standard configuration. This is useful for tools that have already been developed and which would be difficult or impossible to be reengineered as Sentinel Toolbox plugins.
...