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.
Contents
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 thegDocRead
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 thegDocWrite
front type of the service; - the
Factory
serves as the front-end of a single WS Resource that createsReadManaager
andWriteManager
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.