How Web Services are introduced in a Workflow

Download Report

Transcript How Web Services are introduced in a Workflow

How Web Services are introduced
in a CLARIN Workflow
WSDL and WADL files for Web
Service description.
What is needed basically?

In order to include a web service in
a general workflow the following
data is needed:




Protocol used for communication
Location of web service
List of operations offered by this web
service
Description of the data types used in
those operations
Web Service data files

WSDL (Web service description Language) is a W3C
standard

version 1.1




version 2.0




Used to describe SOAP web services. Based on XML.
(Microsoft and IBM)
http://www.w3.org/TR/wsdl
Used to describe SOAP and REST web services. Based on XML.
(Sun, Canon, IBM, WSO2)
http://www.w3.org/TR/wsdl20/
WADL (Web Application Description Language)



Used to describe REST web services. Based on XML.
(Sun Microsystems)
https://wadl.dev.java.net
SOAP cannot use WADL



REST Web Services can pack all
description data in a WADL file or in a
WSDL 2.0 file.
WADL and WSDL languages are
essentially the same but WADL is more
specific to REST. It is also easier to use.
WADL is not standard (neither is REST)
but since WADL is easier to use (like
REST) probably will be widely accepted
(like REST).
Summing up



WSDL or WADL Description files
permit to describe web services
This description is used by client
applications to connect to the web
services.
For most generic workflows such
description files are enough, but for
CLARIN....
SOAP Web service example for a
CLARIN scenario



The following web service queries a CQP indexed
corpus.
WSDL file url:
http://igraine.upf.es:9100/cqp/service.wsdl
Information included in that WSDL file:



It uses SOAP
It can be accessed at
http://igraine.upf.es:9100/cqp/api
It has 3 operations available




CqpQueryResults GetPendingResults(int ticket_no)
bool ResultsAvailable(int ticket_no)
int QueryCqpExpression(string cqp_expression, string
domain)
It uses a custom data type CqpQueryResults which is
also defined in the WSDL file.
Using the web service: Binding process example
with WSDL.
Step 1: Get WS Location

Look for the ‘Service’ Tag
<service name="CQPService">
<port name="CQPCqpPort" binding="typens:CQPCqpBinding">
<soap:address location="http://igraine.upf.es:9100/cqp/api"/>
</port>
</service>
Binding process example with WSDL.
Step 2: Get WS protocol

Look for the ‘Binding’ Tag
<binding name="CQPCqpBinding" type="typens:CQPCqpPort">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="rpc"/>
…
Binding process example with WSDL.
Step 3: Get Operations available

Operations are Contained in the ‘operation’ tag.
<operation name="GetPendingResults">
<soap:operation soapAction="/cqp/api/GetPendingResults"/>
<input>
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:ActionWebService" use="encoded"/>
</input>
<output>
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:ActionWebService" use="encoded"/>
</output>
</operation>
Binding process example.
Step 4: Get operation parameters

Each ‘operation’ tag is related to the parameters
description (‘message’ tag).
<operation name="GetPendingResults">
….
<message name="GetPendingResults">
<part name="ticket_no" type="xsd:int"/>
</message>
<message name="GetPendingResultsResponse">
<part name="return" type="typens:CqpQueryResults"/>
</message>
Binding process example with WSDL.
Step 5: Get custom types definition

Operation parameters may have custom data types. Those
are described in the ‘ComplexType’ tag and can be nested.
<operation name="GetPendingResults">
….
<message name="GetPendingResultsResponse">
<part name="return" type="typens:CqpQueryResults"/>
</message>
…
<xsd:complexType name="CqpQueryResults">
<xsd:all>
<xsd:element name="error_msg" type="xsd:string"/>
<xsd:element name="result" type="typens:CqpResultLineArray"/>
<xsd:element name="error" type="xsd:boolean"/>
</xsd:all>
</xsd:complexType>
CLARIN Workflows


For general workflows, WSDL or WADL files
contain enough information for including the Web
Service and use it in any workflow.
Workflows in CLARIN can have more
requirements than general workflows that cannot
be inside WSDL or WADL files, for instance ...



Alternative web services / mirrors. Required when
errors occur.
Information about cost of execution.
WSDL/WADL files use traditional URIs for
referencing resources, while CLARIN will use PID’s
Extra information for CLARIN
Workflows

Some of this extra information could be
contained in the Registry



Alternative / mirror web services.
Cost of execution
Registry should also have a reversal PID
resolution. Get PID using URI. Getting
PID using URIs declared in WSDL/WADL
files would be easy.
Conclusions




WSDL/WADL files describe web services interface.
Any software can be a web service client if the
web service’s WSDL/WADL is available. And it is
sufficient to be included in a workflow without
human interaction.
CLARIN workflows will have some extra
information requirements. With this extra
information, user will be able to include web
services to CLARIN workflows.
Should the required extra information be in the
CLARIN registry?