1. Web Services - Concepts, Architecture and Applications Part 6: Service Description (WSDL) Gustavo Alonso and Cesare Pautasso Computer Science Department ETH Zürich alonso@inf.ethz.ch http://www.inf.ethz.ch/~alonso Some slides were modified or added by: Nilufer Onder Computer Science Department Michigan Technological University http://www.cs.mtu.edu/~nilufer

2. ©ETH ZürichPart 6: WSDL 2 What is WSDL? o Web Services Description Language (WSDL) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented communication. (www.w3.org/TR/wsdl)www.w3.org/TR/wsdl o The original document was prepared by Ariba, IBM, and Microsoft. o The Web Services Description Language specification is in working draft 2.0 (November 2003, June 2007) o WSDL discusses how to describe the different parts that comprise a Web service. o A WSDL document defines services as collections of network endpoints, or ports. o The general framework is to store WSDL descriptions where potential clients can find the services they need

3. ©ETH ZürichPart 6: WSDL 3 WSDL definitions o In WSDL, abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings o Abstract definition ÞTypes: a container for data type definitions (e.g., using XSD) ÞMessage: a typed definition of the data being communicated ÞOperation: description of an action supported by the service ÞPort type: set of operations supported by one or more endpoints o Concrete description ÞBinding: protocol and data format specification for a particular port type ÞPort: a single endpoint defined as a combination of a binding and a network address ÞService: a collection of related endpoints

4. ©ETH ZürichPart 6: WSDL 4 Elements of WSDL WSDL document Types (type information for the document, e.g., XML Schema) Message 1Message 4Message 3Message 2 Operation 1Operation 3Operation 2 Message 6Message 5 Interface (abstract service) binding 1 endpoint 1 binding 2 endpoint 2 binding 3 endpoint 3 binding 4 endpoint 4 Service (the interface in all its available implementations) Abstract description of the service Concrete description of the service

5. ©ETH ZürichPart 6: WSDL 5 WSDL Example From: Web Services Description Language (WSDL)1.1. © W3C Note 15 March 2001 <definitions name=“StockQuote” Targetnamespace=“http://example.com/stockquote.wsdl”http://example.com/stockquote.wsdl Xmlns:tns=“http://example.com/stockquote.wsdl”http://example.com/stockquote.wsdl Xmlns:xsdl=“http://example.com/stockquote.xsd”http://example.com/stockquote.xsd Xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/”http://schemas.xmlsoap.org/wsdl/soap/ Xmlns=“http://schemas.xmlsoap.org/wsdl”/>http://schemas.xmlsoap.org/wsdl”/

6. ©ETH ZürichPart 6: WSDL 6 WSDL Example - Types From: Web Services Description Language (WSDL)1.1. © W3C Note 15 March 2001 <schema targetNamespace=http://example.com/stockquote.xsdhttp://example.com/stockquote.xsd xmlns=http://www.w3.org/2000/10/XMLSchema>http://www.w3.org/2000/10/XMLSchema

7. ©ETH ZürichPart 6: WSDL 7 Types in WSDL o The types in WSDL are used to specify the contents of the messages (normal messages and fault messages) that will be exchanged as part of the interactions with the Web service o The type system is typically based on XML Schema (structures and data types) - support is mandatory for all WSDL processors o An extensibility element can be used to define a schema definition language other than XML Schema

8. ©ETH ZürichPart 6: WSDL 8 WSDL Example - Messages From: Web Services Description Language (WSDL)1.1. © W3C Note 15 March 2001

9. ©ETH ZürichPart 6: WSDL 9 Messages and Faults o Called “message reference component”, it contains three elements: Þmessage reference: indicating the message pattern used for this message Þdirection: whether it is an inbound or outbound message Þmessage: the actual contents of the message expressed in terms of the types previously defined o Messages are divided into parts, each of them being a data structure represented in XML. Each part must have a type (basic or complex types, previously declared in the WSDL document). o If a SOAP binding is used, a WSDL message element is meant to match the contents of the body of a SOAP message. By looking at the types and looking at the message, it is possible to build a SOAP message that matches the WSDL description (and this can be done automatically since the description is XML based and the types also supported by SOAP) o Called the “fault reference component”, it contains: Þa name Þmessage reference: the message to which the fault refers to Þdirection: whether the fault is inbound or outbound Þmessage: the actual contents

10. ©ETH ZürichPart 6: WSDL 10 WSDL Example – Operation and Port From: Web Services Description Language (WSDL)1.1. © W3C Note 15 March 2001

11. ©ETH ZürichPart 6: WSDL 11 Operations o An operation is a set of messages and faults. The sequencing and number of messages in the operation is determined by the message exchange pattern (would add a line containing <fault message=… to the operation) o An operation has: Þname Þmessage exchange pattern Þmessage references: the messages involved (input, output) Þfault references: the faults involved (infault, outfault) Þstyle (optional): RPC, set- attribute or get-attribute Þfeatures and properties o Style: ÞRPC = implies interactions mirroring the behavior of RPC Þset- and get- attribute = implies interactions of the type commonly found in object oriented languages o Features and properties: used to specified characteristics of the message exchange implied by an operation. Examples include reliability, security, routing, etc

12. ©ETH ZürichPart 6: WSDL 12 WSDL Example – Binding From: Web Services Description Language (WSDL)1.1. © W3C Note 15 March 2001 http://schemas/xmlsoap.org/soap/http http://example.com/GetLastTradePrice

13. ©ETH ZürichPart 6: WSDL 13 Bindings and ports o A binding defines message formats and protocol details for the operations and messages of a given Port Type o A binding corresponds to a single Port Type (obvious since it needs to refer to the operations and messages of the Port Type) o A Port Type can have several bindings (thereby providing several access channels to the same abstract service) o The binding is extensible with elements that allow to specify mappings of the messages and operations to any format or transport protocol. In this way WSDL is not protocol specific. o A port specifies the address of a binding, i.e., how to access the service using a particular protocol and format o Ports can only specify one address and they should not contain any binding information o The port is often specified as part of a service rather than on its own

14. ©ETH ZürichPart 6: WSDL 14 WSDL Example – Service From: Web Services Description Language (WSDL)1.1. © W3C Note 15 March 2001 My first service http://example.com/stockquote

15. ©ETH ZürichPart 6: WSDL 15 Bindings, endpoints, and services o A binding describes a concrete message format and transmission protocol for a given endpoint o A binding can be generic or refer to a concrete interface o A binding can be defined for an entire interface or on an operation basis o A binding has: Þname Þinterface: the interface to which this binding applies Þoperations: a set of binding operation components Þfeatures and properties o A binding operation component specifies the binding for a given operation: Þname: the operation for which the binding applies Þmessage references Þfault references o The binding operation component contains message and fault bindings for all messages and faults of an operation o An endpoint associates an address to a given binding o A service groups together all the endpoints for a given interface o The specification includes bindings for HHTP, SOAP and MIME (the latter may eventually be dropped)

16. ©ETH ZürichPart 6: WSDL 16 Message exchange patterns o IN-ONLY Þa single incoming message (A) with no faults o ROBUST IN-ONLY Þan inbound message (A) that might trigger a fault message o IN-OUT ÞAn incoming message (A) received from node N ÞAn outgoing message (B) sent to node N ÞFaults, if any, replace message B o IN-MULTI-OUT ÞLike IN-OUT but with zero or more outbound messages and “fault replaces message” behavior o OUT-ONLY ÞAn outbound message (A) that expects no faults o ROBUST OUT-ONLY ÞAn outbound message (A) that might trigger a fault o OUT-IN ÞAn outbound message (A) to node N ÞAn inbound message (B) from node N ÞFaults, if any, replace message B o ASYNCHRONOUS OUT-IN ÞLike OUT-IN but with trigger behavior for messages o OUT-MULTI-IN Þreverse of IN-MULTI-OUT

17. ©ETH ZürichPart 6: WSDL 17 Interfaces in WSDL 2.0 o An interface defines the messages a service sends or receives by grouping the messages into operations o An interface can extend the operations of other interfaces (inheritance) o An interface has: Þname Þextended interfaces: other interfaces that this one extends Þstyle default: default style for operations Þoperations Þfeatures and properties o An interface corresponds to the abstract description of the Web service, it does not contain any information about where the service resides or what protocols are used to invoke the Web service

18. ©ETH ZürichPart 6: WSDL 18 WSDL 1.1 vs WSDL 2.0 WSDL 2.0 o Endpoints o Interfaces o Support for Interface inheritance o Removed operation overloading o Messages defined through Types o Operations nested inside Interfaces o Endpoints nested inside Bindings o 9 Message Exchange Patterns o New: Features and Properties WSDL 1.1 o Ports o PortTypes o Supported operation overloading o Messages composed of Parts o 6 Top level elements: Messages, Operations, PortTypes, Bindings, Ports and Services. o 4 Transmission Primitives (One-way, Request-Response, Solicit-Response, Notification)

19. ©ETH ZürichPart 6: WSDL 19 On the use of WSDL

20. ©ETH ZürichPart 6: WSDL 20 Potential Uses of WSDL o Traditional service description language: a contract that a Web service implements o Input to stub compilers: will generate required stubs and additional information for developing both the service and the clients o (allow designers to reason about the semantics of a Web service. However, semantics is outside the scope of current WSDL specifications.)

21. ©ETH ZürichPart 6: WSDL 21 Conversations o WSDL is in its current version an extension of the IDL model to support interaction through the Internet: ÞXML as syntax and type system Þpossibility of grouping operations into a service Þdifferent options for accessing the service (addresses and protocols) o This is its great advantage … Þit is straightforward to adapt existing middleware platforms to use or support WSDL Þautomatic translation from existing IDLs to WSDL is trivial o … but also the disadvantage Þelectronic commerce and B2B interactions are not single service calls ÞWSDL does not reflect the structure of the procedures to follow to correctly interact with a service (conversations) business protocol = set of valid conversations o Without a business protocol, most of the development work is still manual

22. ©ETH ZürichPart 6: WSDL 22 Using Workflows with ebXML ©BEA CONVERSATIONS

23. ©ETH ZürichPart 6: WSDL 23 Conversations (example) “The xCBL 3.5 ChangeOrder document is a buyer-initiated document that can be used to change an existing Order already received and responded to by a seller. The document can be used to make changes to header level information, change line items, cancel line items, add line items, etc. Note that if an OrderResponse has not been received for a given Order, a ChangeOrder is not necessary (an Order with a purpose of “Replace” should be used). Similarly, if an entire order is to be cancelled (regardless of whether a response has been received or not) an Order with a purpose of “Cancellation” should be used.” xCBL 3.5 Order Management Recommended Use, Version 1.0 November 19, 2001

24. ©ETH ZürichPart 6: WSDL 24 Other standards o ebXML shows here again what could be a possible evolution path for WSDL (or the type of technology that is being built on top of WSDL) o ebXML does not consider a client/ server model but an interaction between partners (peer-to-peer) o Consequently, the service description model for ebXML is the description of how two business processes interact with each other: Þpartners publish their processes (an external view over them) Þa collaboration agreement is drawn based on those processes Þthe collaboration agreement describes the business protocol between those partners o Multiple standards will continue to coexist VIEW OF BUSINESS PROCESS PARTNER 1 VIEW OF BUSINESS PROCESS PARTNER 2 COLLABORATION AGREEMENT service

25. ©ETH ZürichPart 6: WSDL 25 Automatic development o The ultimate goal of WSDL is to provide support for automating as much as possible for the development process for Web services: Þgiven the WSDL description, a WSDL compiler generates the stubs or skeletons necessary to develop clients that can interact with the service Þfor that purpose, WSDL must rely on a standard protocol so that generic stubs can be created, this is where SOAP comes into the picture ÞWSDL is meant as a bridge between internal services and external (Web) services o Similarly, the ultimate goal in ebXML is to automate the process of developing a collaboration agreement, deploying it and enforcing its rules: Þgiven a collaboration agreement (possibly a standard one), one should be able to automatically generate a stub or skeleton for the individual business processes at the ends of the agreement Þpartners need only to extend the stub process with their own internal logic Þthis is why ebXML needs more than SOAP as the agreement is used to control and direct the flow of messages between partners at the platform level

26. ©ETH ZürichPart 6: WSDL 26 WSDL Summary o The goal of WSDL is to describe Web services, in particular describe service interfaces. o The WSDL data structure has interesting implications on how services are described and how they interact ÞServices can initiate operations like a client (blurred notion of client and service provider) ÞWSDL does not presume a particular form of communication (first defines the abstract interface, then the location and protocol) ÞAbstract interfaces are reusable: different services could combine different interfaces using different bindings, and could make them available at different addresses ÞWSDL documents can import other WSDL documents ÞThe WSDL description is correlated with SOAP. If the messages defined in WSDL are exchanged using SOAP, then the InterfaceBindings contain all the information needed to infer or automatically construct SOAP messages (interaction style, XML encoding, transport bindings)