WebLab 1.2.5/Service Interfaces

The service integrated in the platform need to refer to a common scheme and be as normalised as possible in order to ease the creation and enhancement of processing chains. Using a common data exchange model is a first step but then we need to rationalise the expression of services methods and to group them into functional interfaces.

This page describes the generic interfaces and the following link provide a technical description through a WSDL file.

Motivations

A data exchange model will be useless without the definition of standard service interfaces that exploit it. Sharing the same data model is a first step but to ease creation of complex and flexible processing chains, a standardisation of services definition is a must. If each service defines its own interface based on internal implementation or previous choices, orchestration will be dependent on them which make them only used with a pre-defined set of known services and prevent services implementations to be changed easily. If their signatures are not standard, the transformation may not be so easy – even if they use a common data exchange model. This could become a resource consuming task that reduces scalability of applications.

Thus in WebLab, we defined a set of generic interfaces that are presented hereafter. These interfaces should only be seen from a technical point of view, i.e. it only defines the input and output – in term of WebLab data exchange model objects. These interfaces are then implemented by services described in the services taxonomy described in the section dedicated to services taxonomy and standardised interfaces. The UML design allows a description of generic interfaces with general behaviour, in order to express a dedicated service class. Its purpose is quite technical and makes reference to the data exchange model in XSD and to the WSDL technology set. These interfaces could be implemented in several specific descriptions allowing a diversification between each real service that can be implemented. These implementation may propose different generic interfaces in a coherent set that respects the standardised services interfaces.

An example is the analysing services which could be grouped under a common generic interface: Analyser. Then multiple standardised implementations can be defined in order to discriminate the different cases of analysis depending on their specificity (metadata extraction, speaker identification, face recognition, etc.) and thus leading to multiple standards interfaces.

Generic interfaces

The generic interfaces define the most common methods that may be used in WebLab application. These definitions use the UML formalism but are then translated into WebService interfaces in WSDL which rely on the XSD of the data exchange model. The web service technology allows an easy conversion of these interfaces in Java, C++... or any other language which provide a way to implement SOAP web service. Thus these generic interfaces are rather technical and does not clearly define the functionalities which are expose or provided behind the WSDL actions. These will be clearly defined in the standardised interfaces presented later.

The actual WSDL of the interfaces are available on the SVN repository (just here). Then actual definition of WSDL services are grouped into one unique WSDL: WebLab.wsdl.

Analyser

Interface of a analyser. It only contains a method to enable business analyser to process resources, given a usage context. Most of the time this analysis turn out to be the addition of annotations to the Resource.

Link to Analyser WSDL on the SVN.

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.

Link to Auditable WSDL on the SVN.

Cleanable

The "Cleanable" interface defines the operation "clean" that allows the service consumer to remove dirty resources according to a usage context. A resource can be considered as dirty if it meets the criteria defined by the input query or as consequence of a particular business rule.

Link to CleanableWSDL on the SVN.

Configurable

The configurable interface will be used to define services of which behavior depends on a usage context, this context corresponding to a particular set of parameters. In some services, the configurable interface is optional and won't be inevitably realised in every implementations.

Link to Configurable WSDL on the SVN.

Indexer

The indexer interface will be used to define resources indexing services. This interface will be realised only by services enabling on-line indexing.

Link to Indexer WSDL on the SVN.

Queue Manager

The QueueManager interface will be used to define services able to iterate over a set of resources and return them one by one.

Link to Queue Manager WSDL on the SVN.

Report Provider

The report provider interface was used to define services that can produce reports. These services were, in most of the cases, parametrisable: they were realising configurable interface. This was enabling the reporting to be dependent of the usage context.

Since WebLab 1.2.5 the ReportProvider interface is deprecated. We encourage you to use rather an Indexer and Auditable interface together to get the same functional coverage.

Link to Report Provider WSDL on the SVN.

Resource Container

The resource container interface will be used to define services that can manage the resources persistence.

Link to Resource Container WSDL on the SVN.

Searcher

The searcher interface will be used to define resource searching services.

Link to Searcher WSDL on the SVN.

Source Reader

The source reader interface was used as entry point for any analysis of source content.

Since WebLab 1.2.5 the SourceReader is deprecated. We encourage you to use rather a QueueManager interface to get the same functional coverage. Or to directly rely on Camel queues.

Link to Source Reader WSDL on the SVN.

Trainable

The trainable interface will be used to define services of which behavior change dynamically by machine learning. This interface should enable to provide resources to the services. These resources will be used to learned its behavior model. In some services, this model could be dependent of a usage context. The trainable interface will be realised only by services enabling the machine learning procedure on-line (in some case, this step will be done off-line).

Link to Trainable WSDL on the SVN.