-
Notifications
You must be signed in to change notification settings - Fork 2
Development Roadmap
Currently the configuration of Gravity is performed through REST calls rather than user friendly configuration screens. The point of having a REST API was that a user interface could be built that would allow managers to maintain their own processes to a large extent, and for there to be as little involvement from developers as possible.
The development of these screens stalled because the core operational screens that allowed day to day operation had been completed, and the processes required completed. Once a process has bedded down there is often not much need to use administration screens on a day to day basis. However, they will be critical to eliminate the need for developers involvement.
Currently tasks are not able to be assigned to individuals or teams and there is no concept of a 'to do list' for specific users. Instead users are given certain aspects to monitor in a process. Much of the process is automated, and so task allocation is not a huge concern.
However, there is a good case for proper assignment of tasks and strategies around assignment. Ideally we need to introduce the ability to assign a user to a task, and for users to be able to see a list of the tasks assigned to them.
The assignment of tasks should be handled by various strategies which can be employed, such as random, round robin or user with least work. Each approach has its advantages and disadvantages, so managers will be given the choice of assignment strategy when setting up task assignment rules.
Currently we have been using the JackRabbit 2.X series of JCR implementation. This requires that the data actually be stored in a relational SQL database such as MySQL in order to have clustering of the JCR. The database is still a central point of failure however, and so we have had in mind from the very early stages of the design of Gravity that we needed to eventually move to a distributed NoSQL data store.
This has been delivered by JackRabbit Oak, a implementation of the JCR which uses MongoDB NoSQL distributed database for storage. We have not however had the opportunity to validate JackRabbit Oak as a working alternative to the 2.X series. We need to look at Oak and see if it is viable.
There are two concerns with Oak:
- That it requires specific action to index fields. Currently everything is indexed by default.
- That it does not have the facility to count the number of child nodes of a node.
[NOTE: The main codebase has moved to Jackrabbit Oak]
Currently Gravity is deployed as a single monolithic WAR file into Tomcat. This approach means that all the services code needs to be included in the WAR itself. OSGi gives us an alternative, as it means we could have a Application Server were we could install or upgrade services at runtime. Services would no longer need to be built into the Gravity binary, rather they could be deployed as separate independent services.
This means a number of fundamental changes. First we would need to migrate from Tomcat to something like WildFly (JBoss) which gives us a OSGi container. We would then need to modify the Gravity binary to run as a OSGi Bundle. We would then need to modify the execution plugin to resolve services using OSGi. We would not retain the old mechanism of instantiation of services inside Spring.
An alternative to the OSGi approach would be a Microservices approach, where new services are deployed as web services and their interfaces registered with Gravity to make them available. In this architecture new services would not be deployed into the same JVM at all, rather they would run in their own JVM, or perhaps even in their own container.
One 'lightweight' container approach is Docker. This allows a image to be easily configured and deployed into a virtual environment. The upside compared to OSGI is that it maintains a level of operating system isolation so that one service cannot impact other services. The downside is that if there are many individual services resources cannot be shared. OSGi provides the ability to share common resources efficiently while maintaining logical isolation and strict access via contract/interface.
There are other open source applications which have suites of useful endpoints and services that could be used by Gravity. Rather than reinventing the wheel it should be possible to write adapter plugins which make it possible to call classes written for Spring Integration, JBoss ESB, or Mule. This will enable us to leverage existing code bases without taking on the responsibility of maintaining them.