The project is implemented in Java for all process related elements. The Java Aspectj extension is also used to allow us to take advantage of Aspect Oriented design components. Velocity is used to generate the dynamic presentation layer (this is in place of technologies such as JSP).
A key external Interface that is utilized by the system is the Hibernate Session interface. This allows us to persist and retrieve our objects from the relational database. The system contains a wrapper to this interface that allows us to add some functionallity to the Hibernate configuration. The Hibernate utility allows us to dynamically alert Hibernate of objects that it should be able to persist. It also makes it so the system is capable of creating and updating the table schema if it is not present or current with deployed objects. This coupled with some static checks for default data make it so that the application can be deployed against an empty database and it will create the table structure as well as and bootstrap data that it may need.
Another external interface utilized in the system is the Castor marshalling and unmarshalling built into the generated object model. The workflow engine uses this to read in XML documents that specify workflow definitions that are available to the system.
Everything in the core system is stored in the relational database. There is a project module, File Upload, which allows the user to store very large files in relation to a project. These files are stored on the file system. Initially we stored the files in the database but we found that it created more issues than it solved. We encountered database driver issues as well as slow performance. Therefore the only data in the system that is not stored in the database are the files uploaded by this module.
The system uses its own security model. We considered using JBoss''s form based security but decided against it since it would have tied us to one application server. As listed in the future activities section we still need to make sure that a password is submitted via a secure protocol (SHTTP, SSL, etc.). Once the information is on the server we process the password through an MD5 algorithm so that we do not store any clear text. The users and the roles are system defined. A user of the system can also browse the site (making no edits) as a guest which is not logged in at all, this was another reason for not using form based security. The system contains six security roles:
Currently the system is not localized and there is code-level work that needs to be done to support different languages. There are the beginnings of support for this as the user specifies their locale, but we would need to remove some hard-codded english and start using resource bundles for our html templates.
Currently the modules created for the system require some rework, as mentioned in the future activities section, if they are to be re-usable in a different framework. But because this framework is so versatile they are reusable from the perspective of customizing this system for different implementations.
The system has a global error handling mechanism which is implemented through an interceptor (described above). If certain global exceptions are filtered up through the invocation chain we can handle them with a consistent message. Data entry errors are the responsibility of the module writers. The interceptor will handle global catastrophic errors which should never happen (ex. Database is down, webserver has crashed, etc.).
