[OpenSPP-project] OpenSPP Project Status

[Dean W. <dea...@so...>]

The OpenSPP team is wrapping up Sprint 2. Some things are going well, and some things are a bit behind schedule.

Early on, the design team elected to apply a fairly elegant architecture. There's a "web service" layer that runs under Tomcat to bring in SOAP requests and return responses. This layer implements the SOAP protocol layer, parses out the data then passes the various SPPP commands on to a "command processor" layer. The command processor implements all the business logic of the protocol, and uses a "data object" layer to persist the data into or retrieve data from a MySQL relational database. Each layer contains independently testable (using JUnit) classes.


The web service layer is fairly straightforward, as is the data object layer. The command processor is fairly gnarly. The design team elected to use a "command factory" pattern that relies on the inheritance model of Java to allow us to build out one set of commands (we started with Destination Group), then replicate and extend function through inheritance for other commands. The basic idea is that while this makes the first command set harder to build, it should make the follow-on work easier to do. The risk is that this sort of elegant software architecture is much easier to maintain for someone who understands it, but possibly more difficulty to maintain in a distributed-and-voolunteer team model than a "brute force" approach might be.

In practice, it's proven harder than we expected to get the first set of commands fully functional. Team members Jeremy and Mickael are today working with a fully integrated but hand-assembled code base to track down exceptions occurring in the Destination Group operations. We had hoped to have this demonstrable at the end of Sprint 1, and are just now getting close to making it happen.

The next step is to polish up the system assembly process so that it doesn't have to be knitted together by hand into a running system but has a mostly automated build process that can spit out the application image (a web-service archive or WAR file for use with Apache Tomcat) and the base configuration files that will need to be customized by the installer. Once automated build/deployments can happen, it should be a lot easier to start snapping in the code for additional SPPP operations.

A related piece of complexity is managing the third-party components that the code is dependent on. The Java tool chain we're using requires lots of Java archives ( JAR files) for things like database connectivity, logging, testing, formatting SOAP messages, and so on. A minimalist approach would provide our users with a manifest of those JAR files and instructions for where to get them and how to install them before building the OpenSPP package itself. ANother possible model is that we include copies of the required JAR files in our own source tree, such that the WAR file produced from our build process includes the needed JAR files. This has pros and cons -- critically, we'd have to verify that we're compliant with the licensing terms of those components in doing so, AND that we're compliant with applicable export law relating to application cryptography. For example, we have developers in Israel, and even if the crypto library is copied by an Israel-located developer onto our US-based server, checking that code back out again is considered an export and there are legal procedures that must be observed.  We're currently engaged in developing a component manifest and in evaluation of the alternatives.

--
Dean