This is an old revision of the document!
(Dropwizard for RPG)
For some time now there is the trend for packaging REST services into a fat executable ready to deploy anywhere without much or any configuration. Dropwizard is such a project. It takes best of breed stuff to create an easy to use platform for developing REST services.
Developing REST services on the IBM i server has been very hard and/or complicated. Creating such a platform would ease the integration of the IBM i platform into the rest of the IT application infrastructure.
Each Dropwizard instance should reside in a separate library. This way we can have duplicate objects on the system but in separate libraries. Each start job should have a configured library list.
A HTTP Server needs to be embedded.
One of these http servers need to be ported to the IBM i platform and compiled to an ILE module.
Nothing to do here because every job on the IBM i has a native database connection.
Configuration should be dead simple.
The user can also enter his custom configuration which he can query with the configuration service program.
Normally a stream file in the IFS would be used for storing the configuration of the server/service. But most IBM i people are not comfortable with using the IFS because they haven't used it on a regular basis (or not at all).
Simple database file with two fields (key, value). The name of the configuration file is the same as the program name. Different configurations are stored in different members in the same configuration file. At the start of the program the configuration file and the member are specified.
Special MiWorkplace Plugin for Dropwizard for editing configuration values. Form Editor.
The configuration for the logging is stored in the configuration database file.
For simple REST services a template engine would easy the development of REST services a lot.
Templating should be optional.
As the compiled program on IBM i is not an archive file it (like a Java program) any additional cannot be just added to the compiled object.
Solution: Through an extra build step any additional asset is put into a source member which is then compiled to a module and added to the bound program object.
At server start a command (and additional parameters) are passed to program. One command would be
server which starts the server with the passed configuration.
server is a standard command provided by the framework.
Additional commands can be added via API calls at runtime. Commands are compiled as modules and bound to the program object.
Each BlueDroplet instance provides an admin web application. It displays various information about the server and its registered resources.
Tasks are actions which can be executed via the admin ui or via a REST call. A task is registered at the application via an API call.