WebLab 1.2/Service Interfaces
The service integrated in the platform need to refer to a common scheme and be as normalized 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 rationalize 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.
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 chain, a standardisation of services definition is a must. If each service defines its own interface absed on internal implemenation or previous choice, 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. But 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 will reduce scalability of applications.
Thus in WebLab, we defined a set of generic interfaces that will be 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 standardized interfaces. The UML design will allow a description of generic interfaces with general behaviour, in order to express a dedicated service class. Its purpose is quite technical and will make reference to the data exchange model in XSD and to the WSDL technology set. These interfaces could then be implemented in several specific descriptions allowing a diversification between each real service that will be implemented. These implementation may propose different generic interfaces in a coherent set that will respect the standardized services interfaces.
An example will be the analysing services which could be grouped under a common generic interface: Analyser. Then multiple standardized implementations will 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.
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 will then allow 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.
Interface of an 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.
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.
The indexer interface will be used to define resources indexing services. This interface will be realised only by services enabling on-line indexing.
The QueueManager interface will be used to define services able to iterate over a set of resources and return them one by one.
The report provider interface will be used to define services that can produce reports. These services will be, in most of the cases, parametrisable: they will realised configurable interface. This will enable the reporting to be dependent of the usage context.
The resource container interface will be used to define services that can manage the resources persistence.
The searcher interface will be used to define resource searching services.
The sourceReader interface will be used as entry point for any analysis of source content.
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).