Difference between revisions of "Technical Services Interfaces"

From WebLab Wiki
Jump to navigationJump to search
(Add some comment wrt to 1.2.8 version and auditable existing implementation)
 
Line 13: Line 13:
  
  
=WebLab 1.2.5=
+
=WebLab 1.2.5 /1.2.8=
 
==Cleanable==
 
==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.
 
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.
Line 22: Line 22:
  
 
==Auditable==
 
==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 (TBD) and it can be related to a particular usage context.
+
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.
  
 
<div class="inimg" style="width:265px">
 
<div class="inimg" style="width:265px">
Line 29: Line 29:
  
 
===Auditable Properties===
 
===Auditable Properties===
{{TODO | Properties defining how to report information about a service using Auditable interface.}}
+
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.
  
 
==<div style="text-decoration: line-through;">Source Reader</div>==
 
==<div style="text-decoration: line-through;">Source Reader</div>==
 
We decided to remove the [[WebLab_services_interfaces#Source_Reader|Source Reader]] service interface since as far as we know, no more service is using this interface. For a replacement, see [[WebLab_services_interfaces#Queue_Manager|Queue Manager]] interface.
 
We decided to remove the [[WebLab_services_interfaces#Source_Reader|Source Reader]] service interface since as far as we know, no more service is using this interface. For a replacement, see [[WebLab_services_interfaces#Queue_Manager|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
  
 
==<div style="text-decoration: line-through;">Report Provider</div>==
 
==<div style="text-decoration: line-through;">Report Provider</div>==
Line 38: Line 42:
  
 
==<div style="text-decoration: line-through;">Dataoperator</div>==
 
==<div style="text-decoration: line-through;">Dataoperator</div>==
This interface has evolved into twho service interfaces:
+
This interface has evolved into two distinct service interfaces:
 
* [[Technical_Services_Interfaces#Cleanable|Cleanable]]
 
* [[Technical_Services_Interfaces#Cleanable|Cleanable]]
 
* [[Technical_Services_Interfaces#Auditable|Auditable]]
 
* [[Technical_Services_Interfaces#Auditable|Auditable]]

Latest revision as of 05:24, 16 June 2017

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.