1 G52IWS: Web Services Description Language (WSDL) Chris Greenhalgh

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 ); 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 –submitted to W3C as a Note July 2002 – WSDL 1.2 draft –Superceeded by WSDL 2.0 before fully standardised June 2007 – WSDL –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: – - document root element, specifying service name & namespace(s) – - data types, usually XML Schema (see XML notes) – - logical definition of a one-way message – - abstract definition of the supported operations in terms of specific messages – - specific protocol and data format for portType – - an address for binding to the service – - the whole service: a set of related (supported) ports

9 element targetNamespace attribute identifies an XML Schema namespace for the WSDL document Defines other namespaces –Including standard wsdl namespace WSDL1.1, xmlns:wsdl=" –WSDL2.0: in namespace xmlns:wsdl="

10

11 element Typically XML Schema type definitions For use in the messages/operations

12

13 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 part s 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

15 element element in WSDL 2.0 Contains a list of the s supported Each may have –An 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 portType s 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

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) – 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 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

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

23

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 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

27

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

29

30 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:input message="service:listMatchingRequest" name="listMatchingRequest" /> … SOAP: <nameValuePair xmlns=" subject Chris

32 Example rpc/encoded body WSDL: <wsdl:input message="impl:handleStringRequest" name="handleStringRequest" /> … SOAP: <ns1:handleString soapenv:encodingStyle=" xmlns:ns1=" abc

33 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)

34

35 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, …