From Filtered Push Wiki
- Client helper should be part of the FP-Node project and should be a maven client side artifact. Client helper currently contains the helper code in addition to tests suitable only for a deployed network (belong in a separate project) and testing utilities (belong in FP-Tools?)
- Create a top level code examples project for FP-Hello among other examples of deployment/implementation of filteredpush (example configs, example ears, etc)
- Create a top level configurations project that contains deployable filtered push configurations (oa, order-coffee). Consists of the rules, rulesets, annotation generator, model descriptors, database schema?, setup scripts?. Maven project for each configuration builds a tar file, depends on the ear/ears and is what we would distribute on sourceforge?
- The maven parent project and pom.xml in the root of the trunk/branches/tags directories can be used to package what we would distribute on sourceforge in the files section (a tar containing EAR(s) + configuration(s) and readme document describing different deployment scenarios?)
- Extract out other classes from api libary and put those in projects that create client side artifacts as well.
- Should the different implementations of the services be in separate projects or in the same project? Benefits of having them in the same project/ejb-jar:
- A single ejb-jar for each service interface (Knowledge, Analysis, Messaging) containing multiple implementations allows us to release and deploy a single jar. Changing implementations or using multiple implementations side by side is a matter of configuration in this case and would not require any development/build.
- Some of the beans are shared between implementations (for example both, the sparqlpush messaging and kvp messaging use the same set of register interest entity beans since in both systems the fp message uuid of the interest and the fp messages pertaining to that interest are currently being persisted to the same database. How the interests are notified and from what data the fp messages are produced is what differs across the two implementations.
- A single top level configuration as well as a single set of local and remote interfaces shared by all of the ejbs allows us to easily define or redefine the apis for all of the implementations at once and ensure that even if something is changed, all the implementations that implement the interfaces still support the change.
- Easier to write tests that can be configured to test all or only one particular implementation.
- FP-Configuration - Contains the rules and ruleset configs for the AnnotationParser, the corresponding xml model descriptors for the AnnotationGenerator, and work flow xml files for Kepler. This is distinct from the network deployment configurations which can be found in FP-Applications.
- FP-Drivers - Driver implementations for use by the AnnotationProcessor
- FP-Examples - Contains example source code (i.e. FP-HelloEJB)
- FP-IPT - FilteredPush IPT
- FP-GG - FilteredPush Golden Gate
- FP-HTTP - Contains all deployable support projects that are not service oriented but can be wrapped by the SOA modules.
- FP-JavaSOA - Contains FilteredPush SOA Applications and modules that are supported using one or many of the following frameworks/libraries: JavaEE/EJB, Spring, JAX-WS (SOAP), JAX-RS (REST).
- FP-Applications - Contains applications of the SOA Modules in the form of EAR projects.
- FP-Modules - Contains FilteredPush service modules (FP-Knowledge, FP-Analysis, FP-Messaging) and presentation layer components (FP-Web). Can be deployed as part of an application EAR or individually. Spring/EJB support and configuration for Tomcat or JavaEE server deployment.
- FP-SemanticWeb - Semantic web related libraries for parsing/generating annotation rdf/xml.
- FP-Testing - Contains any tests and testing utilities that aren't dedicated to unit testing specific components but are test clients designed to invoke the network in a deployment environment (i.e. testing the AccessPoint).
- FP-Tools - ClientHelper tools.