G52IWS: Web Services Description Language (WSDL)

1. G52IWS: Web Services Description Language (WSDL) Chris Greenhalgh 2007-10-26

2. Contents • Standards • WSDL and web services • Anatomy of a WSDL definition document • WSDL bindings • WSDL tools See also: “Developing Java Web Services”, ch 5 part (pp 201-222); WSDL 2.0 specification(s)

3. Standards • First released 2000 • Microsoft, IBM, Ariba • Based on prior Network Accessible Services Specification Language & SOAP Contract Language • March 2001 – WSDL 1.1 http://www.w3.org/TR/wsdl • submitted to W3C as a Note • July 2002 – WSDL 1.2 draft • Superceeded by WSDL 2.0 before fully standardised • June 2007 – WSDL 2.0 http://www.w3.org/2002/ws/desc/ • W3C Recommendation (standard) • Significantly redesigned – not directly compatible, but cleaner and more general • See also: JSR 110: Java API for WSDL

4. WSDL and web services • Describes web service interface & semantics – how to invoke or call a web service • Contains: • Interface information – publicly available functions • Data type information for incoming & outgoing messages • Binding information about the protocol to be used • Address information for locating the web service • Described services can be implemented in any language & on any platform

5. WSDL and SOAP • In principal a WSDL-described web service can be communicated with using any agreed protocol/transport, e.g. • SOAP • SMTP/MIME • HTTP (without SOAP) • MOM • … • But it will often be SOAP • Or HTTP in simple cases

6. Usage • May be generated from (describe) a Web service • E.g. as in SampleServer2.jws • Or by hand • May be used to specify and build a web service • E.g. as in SampleWebService.wsdl • Link to WSDL published in a web services registry • Found by potential users • “user” = application or programmer  • Information is used to correctly communicate with the web service • E.g. through creation and use of client-side stub classes • (Or construct an alternative but compatible service)

7. Web-service lifecycle “Developing Java Web Services” figure 5.1

8. Anatomy of a WSDL 1.1 definition document • Key elements: • <definitions> - document root element, specifying service name & namespace(s) • <types> - data types, usually XML Schema • (see XML notes) • <message> - logical definition of a one-way message • <portType> - abstract definition of the supported operations in terms of specific messages • <binding> - specific protocol and data format for portType • <port> - an address for binding to the service • <service> - the whole service: a set of related (supported) ports

9. <wsdl:definitions> element • targetNamespace attribute identifies an XML Schema namespace for the WSDL document • Defines other namespaces • Including standard wsdl namespace WSDL1.1, xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" • WSDL2.0: <description> in namespace xmlns:wsdl="http://www.w3.org/ns/wsdl"

10. http://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdlhttp://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdl

11. <wsdl:types> element • Typically XML Schema type definitions • For use in the messages/operations

12. http://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdlhttp://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdl

13. <wsdl:message> element • Note: merged into operation input/output element(s) in WSDL 2.0 • Abstract definitions of all messages understood by or sent by the web service • Each comprises a list of parts • Each part has • Name • Element qualified name • or type qualified name – not WSDL 2.0 • As specified in types section or imported schema • Typically XML Schema

14. http://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdlhttp://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdl

15. <wsdl:portType> element • <interface> element in WSDL 2.0 • Contains a list of the <operation>s supported • Each may have • An <input> • An <output> • WSDL 1.1 – each identifies a defined message • WSDL 2.0 – each defines a message, e.g. as an XML Schema-defined element or list of elements (parts)

16. portType Extension • WSDL 1.1 • Different portTypes may contain essentially the same operations (same messages, etc.) but are not explicitly related • WSDL 1.2 • One portType may “extend” another, i.e. include all of its operations, plus add others • WSDL 2.0 • Similarly, one interface may “extend” one or more others, i.e. include all of their operations, plus add others

17. http://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdlhttp://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdl

18. WSDL operation types • One-way – input message only • Notification – output message only • Request-response – input then output, plus optional fault message(s) (failure responses, cf. Java exceptions) • <fault> element (WSDL 1.1) • Solicit-response – output then input, plus optional fault message(s) • WSDL 2.0: • Renamed consistently: in and/or out • Extended to consider • Optional responses • “Robust” messages (have a fault response on failure) • Distinguishes incoming & outgoing faults

19. WSDL operation types “Developing Java Web Services”, figure 5.2

20. <binding> element • Defines the message format & protocol details for operations and messages defined in a particular portType • (or WSDL 2.0 interface). • Provides binding information for all operations, messages and faults in the portType • See later note on WSDL bindings

21. http://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdlhttp://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdl

22. <service> element • Specifies the type and location of a particular service • WSDL 1.1 • List of <port>s, each a particular <binding> of a particular <portType> • Each with an address (e.g. URL) • WSDL 2.0 • Implemented overall interface • With a list of <endpoint>s, each with a particular <binding> on a particular address

23. http://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdlhttp://www.cs.nott.ac.uk/~cmg/G52IWS/sample_soap/SampleServer2.wsdl

24. WSDL bindings • Associate protocol and data format information with abstract entities such as message, operation & portType (WSDL2.0 interface) • Extensible, • i.e. new bindings can be specified & identified without changing the WSDL standard • WSDL 1.1 has standard bindings for • SOAP • HTTP GET & POST • MIME (not strictly a complete protocol)

25. Example WSDL 1.1 SOAP 1.1 binding (as in examples) • Binding must: • Identify SOAP 1.1 protocol • Identify data encoding • Specify address for SOAP endpoint • And may • Identify SOAP action HTTP header URI • Define SOAP Envelope header entries

26. <soap:binding> element • Identifies use of SOAP (and version) • Identifies default server style • document – XML document exchange • rpc – remote procedure call with arguments/return values • Identifies transport binding • transport=... • In this case HTTP as per SOAP specification

28. <soap:operation> element • Allows per-operation specification of SOAP style (rpc or document) • Allows SOAP action header to be specified for that wsdl:operation

30. <soap:body> element • Specifies mapping/encoding of message part(s) to SOAP body • Affected by operation style: • rpc • Body contains an element named after the operation • Each part appears within the operation element as a named wrapper element • literal • Body contains parts directly • Affect by message specification • If “type” then type applies to Body or wrapper itself • If “element” then that element is added as child

31. Example document/literal body WSDL: <wsdl:message name="listMatchingResponse">  <wsdl:part name="body" element="types:nameValuePair" /> </wsdl:message> <wsdl:operation name="listMatching"> <wsdl:input message="service:listMatchingRequest" name="listMatchingRequest" /> … </wsdl:operation> SOAP: <soapenv:Body> <nameValuePair xmlns="http://www.cs.nott.ac.uk/~cmg/G52IWS/SampleWebServiceTypes"> <name xmlns="">subject</name> <value xmlns="">Chris</value> </nameValuePair> </soapenv:Body>

32. Example rpc/encoded body WSDL: <wsdl:message name="handleStringRequest"> <wsdl:part name="s" type="xsd:string" /> </wsdl:message> <wsdl:operation name="handleString" parameterOrder="s"> <wsdl:input message="impl:handleStringRequest" name="handleStringRequest" />  … </wsdl:operation> SOAP: <soapenv:Body> <ns1:handleString soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://DefaultNamespace"> <s xsi:type="xsd:string">abc</s> </ns1:handleString> </soapenv:Body>

33. <soap:body> element attributes • parts="(part name list)" – optional, parts to appear in SOAP body (specifically) • use="literal" – part(s) (elements or types) are XML and appear directly • use="encoded" – parts (types only) are abstract types and are encoded into XML • encodingStyle="(encoding URI(s))" identifies encoding used, required for encoded • Typically SOAP encoding • namespace="URI" – for encoded content not explicitly defined by the abstract type(s)

35. <soap:address> element • Specifies service endpoint address • In this case an HTTP URL (HTTP transport)

36. WSDL tools • Possible capabilities • WSDL generation – from an existing service • E.g. as seen with SimpleServer2.jws • Also AXIS java2WSDL • WSDL compilation – generate data structures and skeleton for service implementation • E.g. as seen with SimpleWebService.wsdl server • using AXIS WSDL2Java • WSDL proxy generation – produce client stub for a particular language encapsulating all details for invoking the web service • E.g. as seen with SimpleWebService.wsdl & SimpleClient.java • Also AXIS WSDL2Java • See examples (notes & code)

37. Limitations of WSDL • Unable to describe complex business processes • E.g. multiple web services, sequences of related messages • See WS-CDL, BPEL, ebXML CCP/A, …