Content Manager

The Content Manager service provides its clients with uniform access to content hosted or served by a variety of back-ends, both inside and outside the system. It is the central component of the gCube subsystem that deals with organisation of content and related data.

Service Design

The Content Manager is designed as an OCMA service. In OCMA terms, it classifies as a multi-type, 1-N adapter service:

• it is a multi-type service because it supports two front types for, respectively, reading and writing content modelled as labelled trees. Collectively, the front types and the tree content model form the gDoc access type of the service.
• it is an adapter service because it adapts the gDoc access type to multiple back types. For this, the service employes an open architecture of type-specific plugins to which it delegates the creation and operation of its collection managers. Plugins are dynamically deployed within single instances of the services, and different instances may have different plugins.

The figure below overviews the design of the service in the context of one its running instances. The instance exposes three stateful port-types:

• the ReadManager serves as the interface of collection managers that offer read-only operations over the content of the bound collection. The interface defines the gDocRead front type of the service;
• the WriteManager serves as the interface of collection managers that offer write-only operations over the content of the bound collection. The interface defines the gDocWrite front type of the service;
• the Factory serves as the front-end of a single WS Resource that creates ReadManaager and WriteManager resources .

Service plugins extend the resources by providing corresponding resource delegates. The factory delegate extends the Factory resource to handle requests that are specifically addressed to the plugin. It does so by creating read delegates and/or write delegates that handle future requests made to, respectively, ReadManager and WriteManager resources created by the service. They do so by translating the requests against the back-end repository that holds or serves the content of the collection bound to the corresponding managers. Depending on the plugin and/or the particular request, the factory delegate may create zero or more read or write delegates. For example, a plugin may support only read-operations against the back-end repository.