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 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.

The front type and the identifier of the bound collection are published as Resource Properties of the manager, in accordance with OCMA patterns for publication and discovery of service state. A third Resource Property is the name of the bound plugin, i.e. the plugin to which the manager delegates the resolution of its requests.

• 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.

Again, the type, the identifier of the bound collection, and the name of the bound plugin are published as Resource Properties of the manager.

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

The resource is created at the activation of the service instance in the gCube Hosting Node.

During its lifetime, it publishes creation requests as activation records. Conversely, it subscribes for the activation records that are 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 list of summary descriptions of the plugins that are hosted at the service instance.

Service plugins logically extend factory and collection manager resources with corresponding resource delegates. In particular:

• 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 factory 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.

Finally, note that factory and collection managers are persistent resources and may thus be re-activated across restarts of the gCube Hosting Node:

• the factory persists the history of its activations, i.e. the activation records that it published and/or processed.
• the collection managers persist the name and state of their delegates.

Content Model

Architectural considerations aside, the most distinguished element in the design of the Content Manager is its content model. Instead of settling for a fixed set of document structures, the service chooses a single generic structure that can acts as a 'carrier' for an arbitrary number of concrete document models. In particular, the Content Manager model documents as edge-labelled and node-attributed trees, the gDoc trees.

The expectation is that producers (service plugins) and consumers (service clients) will convene on more concrete document models by exchanging gDoc trees with an agreed shape. The agreement may be bilateral or involve any number of parties, and it may apply to the entire document or to distinguished parts of it (e.g. the metadata, the annotations, the representation of raw content, etc). For maximum decoupling between consumers and producers, the agreement may be captured by system-wide conventions and result in canonical tree forms.

gDoc Trees

A gDoc tree has the following properties:

• nodes may have a identifier.

The identifier is text.

• nodes have zero or more attributes.

Attributes are uniquely named and names may be qualified with a namespace. Their values is text.

• nodes have a state.

The state may be either N for 'new', U for 'updated', or D for 'deleted'.

The state marks how the node deviates from its persistent representation in a repository. It is used in the write operations of the service.

• inner nodes have zero or more edges.

Edge are named and names may be qualified with a namespace.

• leaf nodes have a text value.

• the root may be marked with the identifier of the collection that contains the document represented by the tree;

The figure below uses a graphical representation to show an example of a gDoc tree.

The model includes the definition of a serialisation onto XML, from which it inherits constraints on the names of edges and attributes as well as constraints on the textual content of attributes and leaf values. The serialisation of a gDoc tree is (informally) defined by a small set of rules:

• the root node serialises as an arbitrarily named document element;
• all the other nodes serialise as elements named as the incoming edges;
• parent-child relationships between nodes serialise as containment relationships between elements;
• leaf values serialise as element text content;
• attributes serialise as XML attributes;
• identifiers serialise as values of attributes called http://gcube-system.org/namespaces/contentmanagement/gdoc:id
• collection identifiers serialise as values of attributes called http://gcube-system.org/namespaces/contentmanagement/gdoc:collID
• states serialise as values of attributes called http://gcube-system.org/namespaces/contentmanagement/gdoc:state

One serialisation for the gDoc tree above would then be:

<gdoc:gdoc xmlns:gdoc="http://gcube-system.org/namespaces/contentmanagement/gdoc"
	gdoc:id="1" gdoc:state="U" x="..." y="...">
	<a gdoc:id="2" gdoc:state="U">
		<b gdoc:id="$2" gdoc:state="U" />
	</a>
	<a gdoc:id="a1" gdoc:state="U">
		<c gdoc:state="N">
			<d gdoc:state="N">...</d>
			<d gdoc:state="N" w="..">...</d>
		</c>
	</a>
	<b gdoc:id="1:/2" gdoc:state="U" w="..." />
</gdoc:gdoc>

The gDoc API

The XML serialisation of gDoc tree is 'natural', in that it does not employ dedicated element structures for the representations nodes, edges, attributes, etc. This streamlines its manipulation with standard XMl technologies (e.g. XPath, XSLT, XQuery, DOM, SAX, etc.) and enables object binding technologies (e.g. JAXB, XStream, etc).