Author: gnaylor
Date: Tue Jul 12 21:44:19 2016
New Revision: 1752350
URL: http://svn.apache.org/viewvc?rev=1752350&view=rev
Log:
Edit content and fix IBM "which WSDL" link
Modified:
incubator/taverna/site/trunk/content/documentation/web-service-developers/index.md
Modified:
incubator/taverna/site/trunk/content/documentation/web-service-developers/index.md
URL:
http://svn.apache.org/viewvc/incubator/taverna/site/trunk/content/documentation/web-service-developers/index.md?rev=1752350&r1=1752349&r2=1752350&view=diff
==============================================================================
---
incubator/taverna/site/trunk/content/documentation/web-service-developers/index.md
(original)
+++
incubator/taverna/site/trunk/content/documentation/web-service-developers/index.md
Tue Jul 12 21:44:19 2016
@@ -23,72 +23,76 @@ However, it should be possible to create
##WSDL (Web Service Description Language) style Web services
-[WSDL](/documentation/glossary#wsdl) binding describes how the Web service is
bound to a messaging protocol;
+[WSDL](/documentation/glossary#wsdl) binding describes how the Web service is
bound to a messaging protocol,
particularly the SOAP messaging protocol.
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 you four style/use models:
+A SOAP binding can also have an **encoded** use or a **literal** use.
Combining these
+options would yield 4 binding styles, except that the document/encoded
combination
+is not WS-I compliant and is [not
used](https://www.ibm.com/developerworks/library/ws-whichwsdl/).
+However, there is an additional binding style that is commonly referred to as
the
+document/literal wrapped style.
+
+Thus, developers have four binding styles to choose from when creating a WSDL
file.
1. RPC/encoded
2. RPC/literal
- 3. Document/encoded
- 4. 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.
+ 3. Document/literal
+ 4. Document/literal wrapped
-A good description of the differences between these styles can be found
-
[here](http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/).
+IBM developerWorks has a good description of the [differences between these
styles](https://www.ibm.com/developerworks/library/ws-whichwsdl/).
-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.
+Although Taverna supports to a fair extent bindings that are **RPC/encoded**
and **RPC/literal**,
+ the preferred binding style is **document/literal wrapped**.
+ Specifically, the WSDL should have âstyleâ attributes that are set to
âdocument,â "useâ attributes set to âliteral,â
+ and the parameters should be inside a wrapper.
+This is particularly important when dealing with complex types; for primitive
types, no problems are anticipated.
-###Currently un-tested
+###Currently untested features
-The following are untested, and although not proven to fail the behaviour is
currently undefined.
-For this reason it is advised that these features are avoided.
+The following are untested and, although not proven to fail, the behaviour is
currently undefined.
+For this reason, it is advised to avoid these features.
- - Multiple WSDL imports.
- Taverna has only been tested on services that contain either no, or only
one import of an additional wsdl file.
+ - **Multiple WSDL imports.**
+ Taverna has only been tested on services that contain no more than one
import of an additional WSDL file.
For WSDLs that import more than one additional WSDL, particularly if that
WSDL has a different service endpoint to the others,
the behaviour of Taverna is currently unclear.
Its expected that it will fail when invoking the Web service.
- This does not affect imports of schemas.
- This has been thoroughly tested and works as expected.
- - 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.
+ *This does not affect imports of schemas, which has been thoroughly tested
and works as expected.*
+
+ - **Multiple service endpoints.** For a given WSDL, Taverna currently only
references the first service endpoint.
+ If more than one exists, operations belonging to the second endpoint are
expected to fail.
+
+ - **Ambiguous type names.**
In the unusual case that an operation requires inputs that contain
identically named types
- that belong to different namespaces it is expected that Taverna should
not have any problems.
+ 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 known to fail
+###Situations currently known to fail
The following are situations that are known to fail in Taverna.
- - 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.
+ - **Cyclic references.**
+ When processing the result of an invoked operation, Taverna resolves the
XML into a single document.
+ If the response contains cyclic references, this is detected and an error
occurs. (This prevents 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. Within the UI,
- Taverna only distinguishes between operations, for a given service, by
name.
- The operation signature is not used to distinguish between operations of
the same name.
+
+ - **Overloaded operations.** Within the UI,
+ Taverna only distinguishes by name between operations for a given
service.
+ *The operation signature is not used to distinguish between operations of
the same name.*
For this simple reason, Taverna does not support overloaded operations.
- - anyType.
- Although Taverna can invoke a service that deals with the anyType type,
+
+ - **anyType.**
+ Although Taverna can invoke a service that uses the anyType type,
the XML splitting mechanism 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.
-##Advertise your services with BioCatalogue
+##Advertise your Life Sciences services with BioCatalogue
-If your services are in the Life Sciences domain,
- one of the best ways to make people aware of your services and make them
easily discoverable from Taverna and
- the Web is to register and describe them in
[BioCatalogue](http://www.biocatalogue.org/)
- Life Sciences Web Services registry.</p>
+Registering your service in the [BioCatalogue](http://www.biocatalogue.org/)
+ Life Sciences Web Services registry is one of the best ways to make
people aware of your services
+ and to make them easily discoverable from Taverna and the Web.
With BioCatalogue, service providers can easily register, describe, advertise
and monitor their Web services.
Users can easily find the right Web service using BioCatalogue's powerful
search and filtering.
