Architecture

The overall architecture was just as simple, as a three tier web application can get. Data backend, application server, web front-end. There were only a few twists to it that made the project special.

Most of the data model had to be implemented using Alfresco’s content metamodel. As the Alfresco content metamodel allows great flexibility in terms of inheritance and meta data customization, it was surprisingly easy to create the entire structure. The financial data was stored in the metadata on the milestone nodes, that contained the documentation related to the given milestone, as well as the rest of the milestones. Since projects are pretty easily represented in such a tree structure, this was even easier to create and manage, than to design the corresponding database and create all the traversing algorithms.

Using “traditional” document archive solutions, such as DB2 Content Manager, ECM Documentum, Saperion, that use a more rigid content model, like table per document type, this would have not worked. Those beasts are great for storing vast amounts of documents of a limited type, but Alfresco was good to store virtually any type of document albeit not as effectively.

As the milestones and the documents themselves had associated actions, such as deadlines to produce some document, or review something, we had to dig in and provide ad-hoc task assignment features. Since the users of the application were in the project monitoring office, but the executors of these tasks were “only” people with access to the Alfresco Web interface, we had to come up with something that uses Alfresco but not directly our application. Alfresco had jBPM version 3 built in those times.

I never was satisfied with jBPM, to me it was not much more than a hack in itself, that ignored the trends and standards for so many years. Alfresco has decided not to go with jBPM, and upgrade to the already available version 5, despite, that it already supported BPMN 2.0. They have developed Activiti that’s way easier and better integrated.

Even though Alfresco provided API’s to most of it’s internal components, it was not true for the task management. We had to create an add-on to the Alfresco to expose the jBPM services. Since our goal was to create a reusable framework, that can be deployed on a out-of-the-box Alfresco installation, it had to be created as a standard package. This was when the open source world has shown it’s backside. Neither Alfresco package structure, nor the jBPM API, nor the way it was integrated in Alfresco was well documented. We had to do lots of digging around in the source code to make up for the non-existent documentation.

The actual application was based on standard EJB 3.0 that managed the connection to the Alfresco web services. We used the mandated Glassfish AS, which was great at that time, and we separated it from the Alfresco instance, just in case. The front-end was implemented in JSF 2.0 using Primefaces. We had to match the University design handbook on the UI, and since we had no designer at this time, I was the one re-skinning the components using CSS. This presented some problems, as the version of Primefaces that contained the features we needed, was still in development. Fortunately that was not a “big-league” type open-source library, the developer offered us help, it was well documented, and worked almost out of the box. We even went to production with a pre-release SNAPSHOT, because we couldn’t wait another month for the actual release.

The most challenging, and interesting part of the entire interface was the collapsible project tree display. This was implemented in PrimeFaces’ tree control, since it is a really flexible implementation, even the data aggregation was done pretty easily. The only custom code we had to do, was the Export to excel feature, that dumped the entire project’s financial data to a spreadsheet, for further analysis. Once we got that right, the rest of the application was just a standard JEE development task.

Reporting was implemented in Jasper Reports. Fortunately this reporting engine already had the ability to use the Java beans that we used in the application to map our data model to the front-end components. It just clicked in it’s place waiting for someone to define and implement reports in it.