From OpenBlueLab

Home

Official WebSite

Download

Forum

Components

History

Before getting the final component diagram you may see at the beginning of this page, we had the following.

It was with Cocoon 21, which didn't use Spring and didn't enforce block isolation. Moreover, Spring don't support circular dependencies, because they are bad practices and must be avoided. So, I reorganized OpenBlueLab Architecture with the following steps :

Components list :

• 3rd-party : manages all external resources OBL can't (because of licensing issues) or don't want (for strategical, time, skills issues) to manage
• action-master : manages access control list and actions
• common : manages common resources like main stylesheets
• conf : contains project resources. Common resources are provided too. The final provided resource is based on fallback mechanism that will look for specific data first, then common. In this schema, it is of course possible to add a new step to look for data in template application, default, ...
• cms : manages portal
• crud-engine : manages forms and crud operations
• db-tamer : manages db access to permit use of different storage system like xmldb, ldap, jdbc, ... For the moment, only xmldb is implemented. Jdbc through Hibernate is currently on the road and should be released by the end of august 2007.
• guardian : manages authentication with REST services, xml file, xmldb, ldap, sql (through jdbc)
• locator : locates and provides data through a fallback mechanism. This component is a facade for conf components.
• navigation : computes dynamic menus from database, manages navigation in categories, rpc browsing in ajax trees
• profiles : manages roles and portal profile lookup after authentication
• data-tamer : provides various ways to display block of data (menus, tables, lists, news, ...)
• reporter : provides ways to group block of data to create more complex documents like books
• skinning : manages skins, themes, js for each project
• repository : provides access to content repository, permits use of selected programs like imagemagick to convert images, create thumbnails, ... or pdf tools to convert documents, or any other program installed on the server

Components reorganization

Common is used by all components but acts as a repository only. Common component has no dependency. It is removed from the diagram, but not from the model. It is just to make component diagram more readable.

It appears locator acts as a facade for conf, himself acting like a facade for projects contained in conf component. In this schema, elements in conf can't use locator component because of the circular dependency created. It should impy too the system knows about the facade which is external to the system. In our case, locator doesn't provide more services than the facade already present in conf. Locator is then merged in conf component.

We now have the following components diagram :

A few circular dependencies are present :

• crud-engine and action-master
• crud-engine and db-tamer
• crud-engine and navigation
• crud-engine and reporter

We can notice crud-engine is always present. Does the error come from crud-engine or the others components ? After analysis, it seems normal crud-engine uses others components, but reverse use is not.

We finally get this architecture

A last circular dependency is present :

• reporter and data-tamer, which work together. The data-tamer subsystem knows about the reporter facade, which is a bad practice.