Shaman is currently made of 3 different subsystems : Spirit, Insight, and Legend.
Here is the big picture :

Spirit provides a customizable Web front-end, for both content access, and workflow features.

Spirit is a Cocoon application. It adds some components, configuration files and scripts to the out-of-the-box Cocoon 2 distribution.
Spirit provides following features :

• Data access (to Insight server) is hidden by an abstraction layer.
• XML processing is defined with pipelines of Transformers, which are XSLs most of time. The invoked pipeline may vary depending of the URI, or other session parameters.
• Any XML content can be converted in any binary format. This currently includes (but is not limited to) HTML, PDF, Word, Excel, JPEG, PNG.
• Binary content may be provided "as it is" from the Insight repository. This is especially useful for images.
• Dynamic XML content may be written easily, with Cocoon eXtensible Server Pages (XSPs). This allows quick development of user forms and navigation structures, while keeping content and logic separated (MVC model).

The Spirit subsystem bundled with Shaman intends to give an example of LCMS application, but users are strongly encouraged to invent their own and give us feedback then.

We intend to delegate User repository feature to a LDAP server (not shown on the diagram).

Insight is a proprietary database, whose role is to:

• "Store" role: handle content files of any size.
• Keep content metadata.
• Give an object-oriented representation of metadata.
• Provide basic workflow features.

We had several good reasons for writing our own server:

• All JDBC-compliant databases don't support BLOBs (e.g. HSQL).
• A XMLDB-like server does not handle very large content files.
• Content may be anything, not just XML.
• We want content to be accessed through java.net.URL objects, allowing a remote content store.
• A home-grown server allows to implement all the hooks we need.
• A home-grown server can return exactly the data structures we need (here we chose an Object-Oriented semantic).
• It provides an indirection layer above storage means.
• Writing one's own content server is not so hard after all ;-)

The OperationService interface shown in the diagram below represents a simple interface which accepts Operation objects. This solves many problems of concurrency and parameter passing.

The Insight server is designed to keep a rigid-but-generic data structure.

Legend is the WebDAV repository, in which Authors store their "work-in-progress". We chose Apache Jakarta-Slide as WebDAV server implementation. There is not much to say about it, except that it never caused problem.

We intend to delegate User repository feature to a LDAP server (not shown on the diagram).