WPS Admin Web Application
: Khalid Alqinyah
: Benjamin Pross (firstname.lastname@example.org
), Matthes Rieke (email@example.com
This project aims to develop a new admin web application for 52° North Web Processing Service (WPS). The new application will improve the backend code through a new implementation, and the front end through a new and modern interface.
More description about the project can be found on the following blog post: New 52° North WPS Admin Web Application
My name is Khalid Alqinyah. I’m a third year computer science student. Follow me and the development progress on: https://github.com/khalidq
Features & Functionality (work in progress)
- Configure process repositories.
- Configure generators.
- Configure parsers.
- Upload processes.
- Import/export configurations.
- Configure service provider information.
- Configure service identification information.
- Configure log setting
- View log entries.
- User access management.
- Test client.
- Build and integrate configuration modules through a configuration API.
- Control the location and order of the configuration module in the user interface.
The development will be divided into four major phases.
Phase 1: Configuration Management
The first phase consists of creating a flexible configuration manager and API that makes it easy to add new configuration modules to the application.
Phase 2: Configuration Modules
After creating the configuration API, the next phase is to create the configuration modules for the application (e.g. repository configuration module, service identification settings module).
Phase 3: Controllers & RESTful methods
The next step is to expose these configurations modules through a web layer and controller classes. These classes will enable the configuration of modules through RESTful methods.
Phase 4: User Interface
Finally, the user interface will implemented.
The development code can be found at: https://github.com/khalidq/WPS
- As a backend developer I want full control over the configuration parameters for my backend so that I can add new settings and change stuff without waiting for a new release of other modules.
- As a backend developer I want one simple configuration API so that I do not have to read any documentation and so that I do not have to worry how my configuration is stored and where to get the correct values.
- As an administrator I want to enable and disable process repositories in a backend
- As an administrator I want to store all the settings from my WPS in a file so that I can backup them and re-use them after a new installation or if something broke.
- As an administrator I want to interactively edit the static parts of the capabilities description in a nice HTML form so that I don't have to edit XML files by hand on the server.
- As a system administrator I want to interactively edit the log configuration (level and file) so that my machine does not get filled with DEBUG logs.
- As an algorithm developer I want to upload new versions of my algorithm in a web interface so that I can do that myself (without a system administrator)
- As an algorithm developer I want to enable and disable algorithms.
- As an administrator I want to upload new algorithms and repositories in a browser so that I don't have to connect to the server the WPS is running on (which I am not allowed to because I am not a system adminstrator)
- As a user I want my password to be transferred and stored securely so that I don't have to worry about being hacked.
- As an administrator I want to be able to reset my passwort (using a simple server-side mechanism, no emails or so...) so that I don't have to re-install when I forget it.
- As a backend developer I want to access logs of my backend processor for debugging.
- As an administrator I want to protect my WPS configuration with a password so that nobody else can change settings.
- As an administrator I ...
- As a user I ...
- As a backend developer I ...
High-level Configuration Architecture
The following diagram provides a high-level view on the required components for the configuration of repositories through the user interface.
- The GrassRepository provides all Configuration definitions (parameter names and corresponding datatypes) through an interface
- Example: GrassRepository provides [Definition: name=python-executable, datatype=file], [Definition: ...]
- the central Configuration Manager components can request these definitions for each available repository (e.g. repository.getConfigurationDefinitions())
- The RepositoryUI can retrieve all desired Configuration definitions for a specific repository
- Example: UI creates an input to specify the [Definition: name=python-executable, datatype=file]
- The RepositoryUI provides the Definition values to the central Configuration Manager (e.g. through a "Save" button)
- Example: User defines the path to python: [Definition: name=python-executable, value="/usr/bin/python"). The Configuration Manager (or the UI?) could be responsible for converting to the correct datatypes (here: File)
- The central Configuration Manager component stores the definitions (after the "Save" button click) and is now able to provide these (to GrassRepository and UI for later editing)
- Finally, the GrassRepository can request all desired Configuration Definitions from the manager and can start working
The Configuration Manager has to cover two functionalities:
- "dispatching" the Configuration Definitions and their values
- make the Configuration Definitions persistent (through SQLite, XML file, ...) and loadable
Original Project Idea
: The current admin interface for the 52°North WPS implementation is heavily coupled with the underlying functionality and modules. This makes it hard to extend the functionality and to package smaller functional packages of the service since the admin interface directly requires many modules. Therefore the admin interface must be transferred from the current HTML/JSP approach to a modern and flexible web application framework. The admin interface should be visually appealing and technologically flexible, e.g. use RESTful interface to configure the server instead of submitting plain old HTML forms.
A potential student must be familiar with Java and web client development, preferably with a framework such as Spring, and be able to work in a larger development team. Experience with agile software development and the ability to produce intuitive and attractive user interfaces would be a great plus. This is a challenging project which will catch a lot of interest from the user community. Expected results
: Modular web client interface that supports the current use cases (managing algorithm repositories, uploading R scripts, uploading moving code packages). The module specific function, such as R script management, must be moved out of the webapp module to the R extension module.
Community and Code License: Geoprocessing, GPL 2.0