Graffito Architecture

Architecture Neutral

Thanks to the Spring framework, Graffito can be used in different kind of architectures, for examples :

  1. Portal server : Graffito is the default Jetspeed CMS engine.
  2. Any other web applications can used Graffito.
  3. EJB components.
  4. Web services.

Virtual Content Tree and Graffito Master Store

Graffito groups together different stores into the same virtual content tree. By this way, your application can access to heterogeneous content servers. The principal store required by the Graffito engine is the Graffito Master Store. It contains all store references and knows how to mount those stores into the virtual content tree.Graffito Master Store can also contain some CMS objects, permissions setting, scheduler info, ... .

The Graffito Engine

The Graffito engine is a container based on 2 distinct layers : The "Graffito services" layer and the "Persistence service" Layer.

The first one, the "Graffito Services" deals with an high level of abstraction. It is composed of different Spring components which are providing a generic API. This API is independent of any CMS content store. Each components solves one of the CMS aspect. For example, the model service manages the CMS objects life cycle (instantiate, create, update, remove) and the search service gives a way to search content across the complete content tree, ... . In order to have more abstraction on the content location, the "Graffito Services" layer dispatchs all requests to the "Persistence Service" layer.

The core Graffito services are :

  1. The Model Service.
  2. The Version Service.
  3. The Security Service.
  4. The Search Service.
  5. The Index Service.
  6. The Workflow Service.
  7. The Event handler Service.
Thanks to the Spring assembling script, it is possible to add new Graffito services.

The "Persistence Service" layer is the key component for building the virtual content tree. After reading all store references from the Graffito Master Store, it can mount each of them into the content tree. Mounting a store is based on an URI mapping. All servers are associated to an URI prefix. So, a CMS object is stored into the store which has the same URI prefix. In the current version it is possible to mount a server only on the root level. Later, we plan to mount a server anywhere in the content tree. The "Persistence Service" is based on a plugin design. By this way, it is possible to have different kind of stores (JCR, Webdav, Graffito DB/OJB Store or proprietary store). The "Persistence Service" knows which plugin to use with which server. The plugin goals is to convert a Graffito request (eg. create a document) into a specific CMS API.

The Graffito Store plugin

Graffito Store plugin can be used to access to a predefined DB schema provided with the Graffito distribution. This plugin implementation is based on OJB.

The JCR plugin

[TO BE COMPLETED]

The Webdav plugin

[TO BE COMPLETED]