On the 17th of June, work started on creating a new web admin application for the 52° North WPS. The project aimed to achieve the following three goals. The first was to make managing, maintaining, and extending the code easier for project developers. This was achieved by having a layered architecture to deal with separate concerns and responsibilities. The second goal was to provide a way for third party developers to integrate their modules to the application with minimum effort. A configuration API was developed to achieve this. The final goal was to improve the usability of the system by creating a new, modern, and flexible user interface.
I have discussed the goals and initial plan in the first blog: New 52° North WPS Admin Web Application, and reported on the progress half way through in the second blog: 52° North WPS Configuration Management Reloaded. In this final blog, I’ll focus on the end result and what has been achieved.
Please note that many of the following figures are simplified, and for the sake of readability, many details have been omitted.
Web Layer
The web layer is responsible for taking user requests and returning the application responses after these requests have been processed by the services. My aim was to have as close to RESTful API as possible. Therefore, many of the configurations are performed through request URIs using GET and POST HTTP methods. If the request is successful, a successful HTTP status is returned. If not, an appropriate HTTP error status will be returned along with JSON error object.
Services
At the heart of the new admin application is a completely new way to manage and process configurations. Previously, configurations creation and processing was coupled directly with the presentation elements (inside HTML, JSP, and JavaScript).
The new admin application moves the responsibility of managing the configuration to a separate and independent service layer. The service classes will take clients requests (forwarded by the web layer), process them, and connect to lower level DAO classes when needed (e.g. database insertion).
To reduce complexity and coupling between the services and clients, there is a main entry point to all services. This works as a facade to the service layer. Clients need to only depend on the ConfigurationManager, and through it they can access the rest of the services.
Configuration API
One of the main requirements of the new admin application is to allow third party developers to add their own configuration modules with minimum effort. Developers need to be able to specify what configuration values their module needs and have these values passed to them by the application. The application must do the heavy lifting on behalf of the developer, this includes creating the form in the interface, receiving and validating user entries, passing the values to the third party module and finally storing the values.
To achieve this, third party modules need to implement the ConfigurationModule interface, define their configuration parameters using type safe configuration entry classes, and annotate any setter methods with the key of the configuration entry with the value wanted.
Low Level Access
The admin application has varied data persistence requirements. Most data will be saved to a database, but some data will be saved to XML files, such as log configuration and capabilities information. To make the services, and application as a whole, independent of the underlying data store, a DAO layer is created with DAO interfaces that serve different persistence needs. These interfaces are implemented in specific APIs (for example JDBC or JDOM) to support databases or XML data stores.
Functions & Features & UI
Now it is time to show the actual application from the user point of view. In this section, I’ll present a few screenshots and a brief description of each.
Homepage
All of the main functions are reachable with one click to simplify and speed up navigation.
Login
Internal administration pages are protected.
Server Configurations
Configure the server.
Repositories Configurations
All repository modules will be displayed in this page. The admin can activate/deactivate a repository, enter configuration values, and activate/deactivate an algorithm within a repository.
Generators Configurations
Similar to the repositories’ page, except that there is no algorithms table within the modules.
Parsers Configurations
Similar to the generators page.
Log Configurations
The admin can easily and quickly configure the log settings without having to look for and edit the log XML file.
Service Identification Configurations
The admin can edit the service identification information which will appear in the GetCapabilities response.
Service Provider Configurations
Similar to service identification, this information will appear in a GetCapabilities response.
Users Configurations
The application has two access levels – Admin and User. They both have similar privileges, except that an Admin can manage other users in the system (e.g. add new user).
Test Client
The test client enables the admin to quickly perform tests on various scripts and algorithms.
Backup & Restore
To backup configurations, the admin first selects what to backup, then a Zip archive with the date will be generated and the link will be provided for download. To restore, the admin uploads the backup file, and the current configurations will be overwritten.
Upload
Upload processes and RScripts.
Future Work
Of course no work is ever complete. This section discusses possible future work, either by me, or by other developers:
- Access management levels: this perhaps is a little complex, but the application might benefit from a more advanced access management, in which the admin can define new access levels and specific privileges for each level.
- Higher coverage testing: although almost all main classes have been tested using unit tests and the interaction of these classes was tested using integration tests, the application can benefit from wider coverage testing to cover more scenarios.
- Integration with the current system: this is perhaps the hardest part and will require the collaboration of other 52° North developers. The new admin application completely redesigns the way configurations are handled. This means a lot of the current classes and modules need be refactored, and in some cases, re-written completely.
Leave a Reply