Technical Services Interfaces

From WebLab Wiki
Jump to navigationJump to search

This pages lists definitions of technical service interfaces.

Next WebLab Version

TODO: This part has to be completed. Define a service interface relying on Query to process services data.

Uses Cases

TODO: This part has to be completed. Explain use cases of a Query compliant service interface to deal with removal.

It might be a good idea to have an exemple by type of service:

  • indexer/search
  • database
  • knowledge repository


WebLab 1.2.5 /1.2.8

Cleanable

The Cleanable interface defines the operation clean that allows the service consumer to remove existing resource that are stored by the requested service. These resources are designated by their URI and can be related to a particular usage context.

Cleanable2.jpg

Auditable

The Auditable interface defines the operation report that allows the service consumer to get a summary information about the service execution. The generated report is represented by a PoK within a set of RDF properties (to be defined and or customised per project) and it can be related to a particular usage context.

Auditable.jpg

Auditable Properties

There is currently one project that has use this interface. The processing (Analyser) service on that project were quite long since we where dealing with Image processing. This interface was used by the portal to get the status of each processing service. The properties were something like: number of successfully processed document, min/mean/max processing time per document, number of errors, currently processed document.

Source Reader

We decided to remove the Source Reader service interface since as far as we know, no more service is using this interface. For a replacement, see Queue Manager interface. Even the QueueManager interface is not usd any more. We are now mainly relying on the Karaf+Camel to dequeue documents from JMS/ActiveMQ queues and then start the processing. All our data sources are integrated as Karaf/Camel components that enqueue quite empty documents (like they were outputted from

Report Provider

We decided to remove the Report Provider service interface since its use is duplicated with the combination of Auditable and Indexer services interfaces.

Dataoperator

This interface has evolved into two distinct service interfaces:

WebLab 1.2.2

DataOperator

This technical service interface offers 3 methods for

  1. reporting information about data stored ;
  2. dropping all data linked to a context and
  3. deleting a specific resource.

Repositories (ie ResourceContainer) and search engines (ie Indexer) should expose such interface. Generally, all service that may store data should implement it too. This interface provides a common data management board that conforms with legal constraints applied with data storage.