View Manager

The View Manager service defines, publishes, and maintains selective views over the content of collections exposed by the Content Manager service. It is a key component of the gCube subsystem that deals with the organisation of content and related data.

We overview here the motivations, architecture and interfaces of the service, as well as its client library.

THIS SECTION OF GCUBE DOCUMENTATION IS CURRENTLY UNDER UPDATE.

Motivations

The main purpose of the Content Manager service is to offer read and write access to the content of document collections maintained both within and outside the system. In doing so, it also publishes information about the collections and it maintains this information over time. Often, however, similar 'collection management services' are required for groups of documents, or document parts, which share common properties within a single collection. For example, the system needs information about all the metadata of a certain type and in a certain language which occur across the documents of a single collection. Similarly, the system may need information about all the documents in the collection which have been updated over the last month.

Clients of the Content Manager service may use gDoc predicates to extract such information from the collection at any time. However, a dedicated service is required to publish and maintain these collection views over time and for an arbitrary number of clients.

The View Manager service serves precisely this purpose within the system. It does so in a general fashion, creating, publishing, and maintaining any content view that can be captured by a gDoc predicate. It can also delegate to specialised plugins the maintenance of content views of particular significance and persistence within the system. Metadata and annotation views, for example, are maintained by specialised plugins of the View Manager service.

What the View Manager does not do, however, is to expose the content of the views it maintains. Access remains based instead on the Content Manager service alone, without the costs of mediated access over the wide-area network. In this sense, we say that the View Manager maintains passive views. The expectation here is that access transparencies normally associated with 'active views' may be regained at the client-side, in association with view-specific access libraries that complement corresponding service plugins. Naturally, the gCube Document Library offers such transparencies for the service plugins dedicated to the management of metadata and annotation views.

Architecture

The interface of the View Manager is distributed across two port-types:

• the View port-type serves as the interface of WS-Resources that model and publish the properties that define a content view. Some properties are defined when the view is created and do not change over time (static properties). Others requires explicit maintenance (dynamic properties). We discuss in detail the interface and Resource Properties of View resources below.

• the Factory port-type serves as the interface of a single WS-Resource that publishes information about the plugins hosted by service instance and allows the creation of View resources from definitions provided by clients. We discuss in detail the interface and Resource Properties of the Factory resource below.

View resources may be extended by delegates provided by service plugins. Delegates are first invoked by the Factory when clients mention the name of the corresponding plugin in their requests to create content views. Their task is to validate the definitions provided by clients and to maintain the dynamic properties of the view thereafter.

Interfaces

In this Section, we discuss in more detail the operations of the service port-types and the Resource Properties of the corresponding WS-Resources. For clarity, we show and comment the signatures of operations in terms of the underlying Java implementation, which mirror the WSDL definitions. We point directly to the WSDL for the definition of auxiliary data structures for input and outputs (e.g. values of Resource Properties).

note: the service offers a client-side library that operates at a higher level of abstraction than its public interface. The operations discussed below are of interest to clients that choose to bypass those facilities, typically because they cannot afford a static dependency to them.

Factory

The Factory resource exposes a single operation for clients that wish to create View resources. The operation is not intended for generic use, in that clients are expected to target a specific plugin to which the Factory ought to delegate the creation of a View resources. A default plugin is called upon when another one is not specifically targeted. The operation, its inputs, and its outputs are formally defined in the WSDL of the port-type:

• public ViewReference create(VMSCreateParams params) throws GCUBEFault

the operation creates a View resource and returns a references to it, which includes its endpoint as well as a model of its properties (at least those which were computed at creation time). Requests are paremetrised by:

• the name of the plugin to which the service ought to dispatch the request, the target plugin. If this is omitted, the request is implicitly addressed to the default plugin.
• a model of view that includes all the view properties to be set on the resource, from the identifier of the view to the predicate that defines it, to any other property that may be required by the target plugin.

The Factory resource exposes the following Resource Properties (in addition to standard system properties):

• Plugin: (multi-valued) a set of properties that describe a service plugin hosted by the service instance, including:

• name: the name of the plugin;
• description: a free-form description of the plugin;
• property: (multi-valued) an additional, arbitrary property of the plugin, as standardly defined for service plugins.

Views

View resources do not expose operations other than the standard operations for resource management defined by the GCUBEProvider (lifetime, Resource Property inspection, Resource Property change).

On the other hand, View resources publish the following Resource Properties (in addition to standard system properties):

• View: a set of view properties, including:

• id: the identifier of the view;
• collectionID: the identifier of the content collection bound to the view.
• type: a qualified name that types the view.
• description: a free-form description of the view;
• predicate: the predicate that identifies the elements of the view;
• cardinality: an estimate of the number of elements of the view;
• lastUpdate an estimate of the time in which the view was last updated;
• property: an additional, arbitrary property of the view (multi-valued):

• name: the qualified name of the property;
• description: a free-form description of the property;
• value: the string value of the property.

• Plugin: the name of the plugin bound to the resource.

Plugins

Default Plugin

= Client Library =