Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current ·  View Page History

There are two main types of web-services: REST (REpresentational State Transfer) and WSDL (Web Services Description Language) /SOAP.

REST services

REST services use the HTTP protocol. As described on wikipedia, a common mapping of services is:

Resource

GET

PUT

POST

DELETE

Collection URI, such as http://example.com/resources/

List the URIs and perhaps other details of the collection's members.

Replace the entire collection with another collection.

Create a new entry in the collection. The new entry's URL is assigned automatically and is usually returned by the operation.

Delete the entire collection.

Element URI, such as http://example.com/resources/item17

Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.

Replace the addressed member of the collection, or if it doesn't exist, create it.

Treat the addressed member as a collection in its own right and create a new entry in it.

Delete the addressed member of the collection.

Tools to build REST services

The Java API for XML Web Services (JAX-WS) provides full support for building and deploying REST Web services. It is tightly integrated with the Java Architecture for XML Binding (JAXB) for binding XML to Java data and is included in Java 6.

Some guidelines on building REST Web services can be found online.

WSDL/SOAP Web services

Web Service Description Language (WSDL) Web services operate by exchanging Simple Object Access Protocol (SOAP) messages with clients over HTTP.

WSDL Web services are defined by their WSDL document, an XML format that represents an interface to a Web service. WSDL is machine-readable description of the operations (functions) and parameters offered by the service, i.e. XML message types that the service receives and produces and that get wrapped in SOAP messages exchanged between the client and the service.

WSDL binding describes how a particular Web service is bound to the underlying SOAP messaging protocol (or any other protocol used as a carrier). A WSDL-SOAP binding can be either a Remote Procedure Call (RPC)-style binding or a document-style binding. A SOAP binding can also have an encoded use or a literal use. This gives four style/use models:

  • RPC/encoded
  • RPC/literal
  • Document/encoded
  • Document/literal

There is also a fifth binding style that is commonly referred to as the document/literal wrapped. Thus, developers have five binding styles to choose from when creating a WSDL file. A good description of the differences between these styles can be found online.

Taverna aims to support Web services that are compliant with Web Services Interoperability (WS-I) standard. This is a long-term goal and currently there are a few nuances. However, it is possible to create WSDL Web services that are compatible with Taverna if you follow certain guidelines.

Although Taverna supports bindings that are RPC/encoded and RPC/literal to a fair extent, the preferred binding style is document/literal wrapped, i.e. the WSDL should have “style” attributes that are set to “document” and “use” attributes set to “literal”. This is particularly the case when dealing with complex types; for primitive types no problems are anticipated.

Currently not tested

The following are not tested, and although not proven to fail, the behaviour is currently undefined. For this reason it is advised that the use of the following features is avoided.

  • Multiple WSDL imports. Taverna has only been tested on services that contain either no, or only one import of an additional WSDL file. For WSDLs that import more than one additional WSDL document, particularly if that WSDL has a different service endpoint to the others, the behaviour of Taverna is currently unclear. It is expected that it will fail when invoking the Web service. This does not affect imports of XML schema - this has been thoroughly tested and works as expected as long as schemas are publicly available.
  • Multiple service endpoints. For a given WSDL Taverna currently only references the first service endpoint. If more than one exists then operations belonging to the second endpoint are expected to fail.
  • Ambiguous type names. In the unusual case when an operation requires inputs that contain identically named types that belong to different namespaces it is expected that Taverna should not have any problems. However, because of the unusual nature of this it is untested and therefore not recommended.

Currently not working

The following are known to fail in Taverna and should be avoided.

  • Cyclic references. When processing the result of invoking an operation, Taverna resolves the XML into a single document. If the response contains cyclic references, this is detected and an error occurs (to prevent an infinitely long document). For this reason cyclic references should be avoided. (Taverna will, however, work with such an operation as long as the cyclic reference is not contained within the response data structure).
  • Overloaded operations. For a given service, Taverna distinguishes between its operations only by name. The operation signature is not used to distinguish between operations of the same name. For this simple reason, Taverna does not support overloaded operations.
  • xsd:anyType. xsd:anyType type can be used to represent a parameter that can be of any type. Although Taverna can invoke a service that deals with the anyType type, the XML splitting mechanism for the message to be sent/received cannot work since there is no information about the data structure required or received. Such services can only be used by providing and/or manipulating the XML directly inside the workflow.
  • Sending SOAP messages with attachments. This refers to the method of using Web Services to send and receive files as SOAP message attachments. Since the fact that a service can accept an attachment is not described in a WSDL document – Taverna cannot know this and therefore does not support it. However, if a service returns attachments (there can be more than one) – Taverna can extract them and returns them on a special service output port called attachmentList.

Since the use of the use of SOAP attachments to pass data is not supported in Taverna and SOAP attachments are not practical for passing large files anyway, it is advised to pass files per references only and then upload the file inside the service. 

Labels
  • None