I’m working on a Java project in which we want to have data collection plugins that collect data to be processed by one or more data aggregation modules. The plugins will all written in-house. Say for example we have data collection plugins A, B and C and data aggegration module X. The modules A, B & C input data into tables that are different but have a few certain fields in common that X cares about. Sometimes the names of the fields are different, but as far as the algorithm is concerned they are “the same”.
What’s the best way to get X to operate on these different data sources while still allowing for a new data collection plugin D to be integrated, as well as the possibility of a new aggregation module Y that operates on some or all of the data sources?
My main concerns are about dependencies – for example, should the data collection plugins know about the aggregation modules, or the other way round? Or neither? Should the collection plugins implement interfaces that the aggregators can then make use of, and if so then where should be interfaces be defined?
Provide a API containing the Interfaces and the JavaDoc that the AggregationModul respects, you can add some tools, you can add some extra custom-annotations like @MustBeThredSave or @DoNotSynchronize or @Obsolete, a few simple Tools like conversation-methods or Helper are ok in the api too. Use @Documented and @Since-Annotations too, use them to let the InputModules know when a Version will support the Modul.
JSF handle this by having a jsf-impl.jar and a jsf-api.jar and it works like a charm.
Also its a good idea to use the SecurityManager in the AggregationModul and the InputModuls A,B,C (http://docs.oracle.com/javase/tutorial/security/userperm/).