Currently, each las2peer service requires that the following constraints are fulfilled:
- Each service bundles all its functionality in one JAR file
- Each service JAR file defines one main class, in which all publicly accessible service methods are listed (and annotated in case of a RESTful service)
We received criticism that this constraint might lead to badly maintainable monolithic code. This criticism is justified, but solvable with a couple of guidelines, which should be documented. Principally, there are two ways:
- use service main class only for the definition of publicly accessible methods (including annotations) and import other classes within the same JAR, which realize respective functionality, but are not accessible publicly.
- distribute service functionality across multiple JARs, each of them fulfilling the above constraints.
- combinations of both above ways
Given a clear decision for dividing service functionality across multiple JARs, developers should also ask the question, if conceptually their service is a combination of multiple smaller independent services.