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, where each back type corresponds to the access type of a whole class of remote repositories.

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 host different plugins. In addition, some plugins may support both service front types, i.e. grant both read and write access to the corresponding repository; others may instead support read-only access or, less commonly, write-only access.

The figure below overviews the design and use 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, which is published along the with the identifier of the bound collection as a Resource Property of the manager, in accordance with OCMA patterns for publication and discovery of service state;

• 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, which is published along the with the identifier of the bound collection as a Resource Property of the manager, in accordance with OCMA patterns for publication and discovery of service state;

• the Factory serves as the front-end of a single WS Resource that creates ReadManager and WriteManager resources .

Created at the activation of the instance in the gCube Hosting Node, the resource publishes creation requests as activation records and, conversely, subscribes for activation records published by other instances of the service, in line with OCMA patterns for replication of service state.

The resource also publishes as a Resource Property the summary descriptions of the plugins hosted at the service instance.

Service plugins extend factory and collection manager resources with corresponding resource delegates. The factory delegate extends the Factory resource at plugin deployment time in order to handle requests that are specifically addressed to the plugin. At each such request, the delegate processes plugin-specific parameters to create one ore more read delegates and/or write delegates, which the service instance uses to create and extend corresponding collection managers. Future requests to the managers are then handled by their delegates, which translate the requests against the back-end repository that exposes the collection bound to the managers.