Within the CLARIN infrastructure a growing number of web services is becoming available. To answer linguistic research questions advanced workflows of these services will be created. Various national CLARIN initiatives are using or building workflow engines to specify and execute these workflows. In general these workflow engines execute web services based on metadata stored in an engine specific repository. This core CMD model for CLARIN web service descriptions is based on the overlap between the metadata schemes of these repositories.
Based on this UML model a CMD profile has been created. However, notice as CMD doesn't support object oriented features like abstract classes and inheritance this profile isn't a one-to-one transformation.
( View the CMD profile in the registry or download the profile as XML or XSD )
In an instance of the UML model Parameter and ParameterGroup instances would me able to mix in the Input, Output and Parameters lists, but in the CMD model ParameterGroup instances have to precede Parameter instances
In the CMD model ServiceDescriptionLocation is a component instead of an element to enable the use of a CMD ResourceProxy to point to the WSDL or WADL file
However, since version 1.0.2 also an, optional, Location element is provided, which can be used instead of the ResourceProxy. Please use only one of these options to prevent inconsistencies.
A web service repository shouldn't directly offer its services in instances of the core model. Instead a repository specific profile should be created. This repository specific profile can extend the core model, e.g., it can add additional CMD elements and components. This can be done by editing copies of the components of the core model. The current versions of the core components are in the CLARIN core WS descr - version 1.0.2 group in the public space in the ComponentRegistry.
The following public CMD profiles are valid extensions to the core model and are or will be used by CLARIN web service registries, workflow and/or chaining engines:
ToolService - CLARIN-NL Tool/Service descr - version 1.0
CMD profile in use within CLARIN-NL/VL and to be used within the TTNWW project.
ToolService - CLARIN-NL Tool/Service descr - DANS - version 1.0
From version 2.0 on CLARIN-D's WebLicht supports the CMD core model for CLARIN Web Services. A dedicated online editor has been created and is available to CLARIN-D developers (look in the archive or ask on the CLARIN-D developers mailinglist if you don't know the credentials).
Notice that the profile name can be different from the core profile, e.g., ToolService, as the associated element name will be skipped during validation.
When an instance of the repository specific profile is stripped of all the extensions it should still be a valid instance of the core model. This validation can be done by uploading the instance using the form below.
This example shows how the CLARIN-NL repository specific ToolService profile has been created. This profile mainly adds the TechnicalMetadata component to the Parameter component of the core model.
Add the TechnicalMetadata component to the core Parameter component:
The links in the example above are based on version 1.0.1 of the core model and version 1.0.0 of the ToolService profile.
Frequently Asked Questions
Why do we need a technical service description, e.g., a WADL or WSDL file, next to the CMD metadata to fully document a web service?
The CMD metadata for web services focusses on the semantic description of a service, i.e., what goes in and what comes out, but it doesn't specifiy how to technically invoke the web service. Should you, for example, pass on the parameters into the query string and use the GET HTTP verb to invoke the service and receive the result? Or should one do a multi-part POST? Or should one wrap the input in a SOAP envelope and POST it to the web service? One could extend the core model to make this explicit, but there are already many of these proposals, e.g., WSDL and WADL, which can be reused. To invoke aribtrary web services a workflow or chaining engine needs to know this. For a more in-depth discussion see the Metadata2012 paper on the core model.
The core model doesn't prescribe a technical service description language or Interface Definition Language (IDL), why not?
For SOAP web services there is a standard, i.e., WSDL (2), but for REST-based web services there isn't. Sun submitted WADL some years ago, but it never made it to a recommendation. So currently there are several competing proposals: