Apogée Architecture

Apogee objects are living inside a tree structure in the same manner as files and folders in a file system but the similitudes ends here. Apogee resources are not folder, neither files. They may point to physical objects (stored somewhere) or they may represents only logical nodes in the resource tree. Example of possible objects are files, folders, user groups, users or any other objects that may be represented in a tree structure.

A flexible mechanism of manipulating resources should be provided. An ECM provider is contributing it's own type of project and may define customized operations on the project resources.

Thus, projects are bound to specific ECM provider implementations. Resources and operations on resources should be flexible enough to be adapted for the needs of every ECM provider .

As the resource model is dynamic and may describe any kind of object Apogee must provide a mean to edit these objects. A dynamic editor model should be defined

In fact the local ECM implementation was initially required in order to use a CPS ECM platform in an off-line mode (without being connected to the CPS server). For doing it, it would have been necessary to synchronize off-line modifications with the remote ECM platform.

Apogee must be able to run as a plug-in inside the eclipse IDE in order to reuse existing editors and other functionalities.

Apogee is coming with it's own resource model but the integration with the Eclipse resource model should be investigated. This may be done using the Eclipse Flexible Workspace feature.

Anyway, in a first phase Apogee should run using it's own resource model.

Apogee resources are handles to logical data objects and are represented in a tree structure. Resources are lightweight objects that contains the minimum of data needed to locate, retrieve and manipulate the underlying objects. Every Apogee resource is uniquely identified by an URI.

Note that resources are handles to objects – this means the existence of a resource object is not presuming the existence of it's underlying object. The resource provides methods to check if the underlying object exists, to create it if not existing or to delete it.

Objects pointed by Resources are described by the “Resource Meta-data”.

Underlying objects may be folder or files in a file system or objects in a tree hierarchy like users / groups. Underlying objects are not even required to exists physically. In this case the meta-data can be viewed as the object itself. The meta-data is providing any information needed to manipulate the resource and the data stored under the resource if any.

Apogee defines three type of resources: Site, Folder and File. Resource types are not herited by undlerlying objects. There isn't any relation between a ressource type and its underlying object. Resources may point to any possible object or data. For example a specific Folder ressource may point to a data file from a file system, and a File ressource may point to a folder in a file system!

Figure 3. : The resource model class hierarchy

3.1.4. The Resource Tree

The ressource tree is rooted in a special container node IresourceTreeRoot. The root node can contains only ISite ressources. Each Isite is bound to an ECM provider through a ISiteController. The Site object is implemented as extending a Folder.

Thus, a Site is in the same time a Folder: the site root folder having the path «/». Each site is the root of it's own tree ressource. The site ressource tree is made by folder and file ressources. File are leaf nodes, while folders are parent nodes. All ressource nodes belonging to the site tree are owned by the same ECM provider that is bound to the site.

Anyway, in future, we plan to implement Virtual Sites that may group ressources from different sites (thus different ECM providers). To implement this we may use a special ISiteController that is delegating every operation to the real site owning the target ressource. This means resources inside a Virtual Site are unaware they are not into their real site since they are preserving the binding to their real site.

Figure 4. : The Site Tree - Sites may be contained by another sites

A Site Controller is associated with an Apogee site to control operations on that site. The association can be made through the API or using the eclipse extension point mechanism.

The Site Controller is handling site resources operations. Each operation is defined as an ISiteOperation object. The operation is dispatched by the controller to the operation handler registered to handle the operation.

This mechanism enables ECM providers to add new operations, undefined for other types of Sites, and also to easy customize existing controllers by changing the way that some operations are handled.

A controller is providing a notification mechanism so that clients may be notified before an operation is performed – so that they may cancel the operation if some prerequisites are not meet - and after the operation was completed.

The Site Controller API is defining some basic operations like tree traversal, create, delete, create etc. that may be implemented by ECM providers, but each ECM provider can define it's own set of operations like publish, submit, etc and performing them using the ISiteController.execute(operation) method.

A site controller is implementing only basic functionalities related to site resources operations. Advanced functionalities such as security checks, undo manager, operation history etc should be implemented as external modules plugged into the resource model using the site operation notification mechanism. See Site Operation Listeners section for more details. Anyway, in future, some important functionalities as the security system may be implemented directly in the site controller.

Figure 5. : Executing a Synchronous Operation

The ISiteController is also providing authentication methods and methods to build and navigate the site tree as getChildren(), and getChild(String name).

Resource Meta-data is used to describe the underlying data if any stored under this resource. There are some predefined meta-data fields like “modification-time”, “content-type”, “version”, “author”, “language” etc. but fields can be added, removed or modified at run-time. This way the meta-data can be customized to describe any type of object used by a given ECM provider.The meta-data must contain only fields that defines the underlying data. You must not store inside annotations or other data attached to a resource. You can write for this specialized services that maps the resource to a property / value pair.

Operations are implemented as ISiteOperation objects. Anyway, for convenience, some basic operations like create, delete, edit etc are directly provided by the ISiteResource API (that is using the operation mechanism internally).

An operation object defines the operation that should be executed by the site controller. Site operations are supporting :

Figure 6. : Creating a Resource - using the ISiteResource API

The Site Controller provides a notification mechanism on the operations it performs. This allows external modules to implement custom handling before and after an operation is executed. Each listener may specify for what kind of operations it must be notified.

The operation may be canceled by handling the “about to perform operation” notification. This feature can be used for example to integrate a security check mechanism before an operation is performed, or to cancel an operation if some prerequisites are not meet. The other type of notification “operation performed” is made after an operation was performed and can be used for reporting or checking operations completion status. This can also be used to implement an undo / redo manager

Figure 7. : Possible Implementation of An Undo Manager

The resource manager is the facade to the Apogee resource model and it's implemented using the singleton pattern.

The resource manager is giving access to the root resource that is containing all Apogee sites, to the site controller registry that is managing bindings between sites and controllers and to other site based services like a property manager etc.

Figure 8. : Getting the Controller Associated to a Site