Distributed Systems SOAP, WSDL
Dr. Cesare Pautasso Computer Science Department Swiss Federal Institute of Technology (ETHZ) [email protected] http://www.inf.ethz.ch/~pautasso
Standard Layers Discovery
Messaging Description UDDI User Interface SOAPSOAP WSDL HTML XML HTTP TCP/IP
©IKS, ETH Zürich. 2 The Web services stack WSDL-based Semantic Web ebXML Messaging SOAP ebXML MSS Description WSDL RDF ebXML CPP Nonfunctional description WSEL Conversations WSCL ebXML WSCI WS- DAML-S BPSS Choreography Coordination BPEL4WS Business BPML BPML processes WSFL/XLANG Contracts ebXML CPA ebXML Discovery UDDI registries WS- Transactions Transactions BTP BTP SAML Security WS-Security S/MIME ©IKS, ETH Zürich. 3
HTTP, HTML and XML WWW basics The earliest implementations BROWSER were very simple and built directly upon the existing systems URL (client/server based on RPC, TP- INTERNET Monitors, or any other form of response middleware which allowed page interaction through a programmable client) the CGI script (or program) acted WEB SERVER as client in the traditional sense map URL to CGI script (for instance using RPC) execute CGI script The user clicked in a given URL get results back (stdout of CGI script) and the server invoked the script prepare response page corresponding to that URL send page to browser the script executed, produced the results and passed them back to the server (usually as the address Implemented of a web page) as a normal client CGI the server retrieved the page and script send it to the browser
Existing Middleware Infrastructure
©IKS, ETH Zürich. WWW 5
HTTP as a communication protocol HTTP was designed for exchanging documents. It is almost like e-mail File being requested (in fact, it uses RFC 822 compliant (docu2.html) and mail headers and MIME types): version of the protocol Example of a simplified request (from browser to Web server): List of MIME types GET /docu2.html HTTP/1.0 accepted by the browser Accept: www/source Accept: text/html Accept: image/gif Information about the User-Agent: Lynx/2.2 libwww/2.14 * a blank line * environment where the browser is running If the “GET” looks familiar, it is not a coincidence. The document transfer protocol used is very End of request similar to ftp
©IKS, ETH Zürich. WWW 6 HTTP server side response Example of a response from the server (to the request by Protocol version, code indicating the browser): request status (200=ok)
HTTP/1.0 200 OK Date: Wednesday, 02-Feb-94 Date, server identification (type) 23:04:12 GMT and format used in the request Server: NCSA/1.1 MIME-version: 1.0 Last-modified: Monday, 15- Nov-93 23:33:16 GMT Content-type: text/html MIME type of the document Content-length: 2345 being sent * a blank line *
Parameter passing
The introduction of forms for POST request indicating the allowing users to provide information CGI script to execute (post-query) to a web server required to modify HTML (and HTTP) but it provided a GET can be used but requires the more advanced interface than just parameters to be sent as part of the retrieving files: URL: POST /cgi-bin/post-query HTTP/1.0 /cgi-bin/post-query?name=…&email=... Accept: www/source Accept: text/html Accept: video/mpeg As before Accept: image/jpeg ... Accept: application/postscript User-Agent: Lynx/2.2 libwww/2.14 Content-type: application/x-www- form-urlencoded Content-length: 150 * a blank line * &name = Cesare+Pautasso Data provided through the form &email= [email protected] and sent back to the server ... ©IKS, ETH Zürich. WWW 8 Contents and presentation HTML is a markup language HTML is based on SGML, that is, designed to describe how a the tags and the grammar used document should be displayed in HTML documents have been (the visual format of the defined using SGML. document). HTML is one of the many markup
Table of contents
languages that exist, some of- 1 A Gentle Introduction them having being in use before to SGML HTML even existed
- 2 What's Special about SGML? Markup languages have been
- 2.1 Descriptive developed and are used in many Markup industries (aircraft
- 2.2 Types of manufacturing, semiconductors, Document
- 2.3 Data computer manuals). Markup Independence languages provide a standardized
- 3 Textual grammar defining the meaning Structure of tags and their use
- 4 SGML Structures Markup languages use SGML, an
- 4.1 international text processing Elements standard from the 80’s, to define
- 4.2 Content tag sets and grammars Models: An Example
©IKS, ETH Zürich. WWW 9
HTML and XML HTML only provides primitives B2B applications require documents for formatting a document with that are much more structured so a human user in mind that they can be easily parsed and the information they contain Using HTML there is no way to indicate what are the contents extracted of a document (its semantics) To cope with this requirement, the XML standard was proposed For instance, a query to Amazon.com returns a book and Important aspects of XML: its price as an HTML document XML is not an extension to HTML XML is a simplified version of SGML a human has no problem that can be implemented in a Web interpreting this browser information once the XML is not a language but a “meta- browser displays it language” used to define markup to parse the document to languages automatically identify the XML tags have no standard price of the book is much meaning that can be interpreted by the browser. The meaning must be more complicated and an supplied as an addition in the form ad-hoc procedure (different of a style sheet or program for every bookstore)
©IKS, ETH Zürich. WWW 10 Data structures in XML
('Mouse':0.792449,
DTDs and documents The goal of XML is to provide a Using XML is possible to standardized way to specify data exchange data through HTTP and structures so that when data is Web servers and process the data exchanged, it is possible to automatically understand what has been sent Note that the use of XML reduces The Document Type Definition the universality of the browser (DTD) specifies how the data since now a browser needs structure is described: processing additional programs to deal with instructions, declarations, specific markup languages comments, and elements developed using XML (somewhat Using the DTD, the XML similar to plug-ins but more document can be correctly encompassing in terms of interpreted by a program by functionality) simply parsing the document However, this is not much of a using the grammar provided by problem since the browser is for the DTD humans while XML is for The idea is similar to IDL except automated processing that instead of defining XML can be used as the parameters as combinations of intermediate language for standard types, a DTD describes marshalling/serializing arbitrary documents as semi- arguments when invoking structured data services across the Internet
©IKS, ETH Zürich. WWW 12 XML Schema A different problem related to What is different between XML accessing EAI systems through a Schema and DTDs?. XML web interface is the Schema: representation of relational data. uses the same syntax as If HTML is used, the data is XML (DTDs have a different formatted for presentation, not syntax) for processing provides a wider set of types If XML and DTDs are used, then (similar to those in SQL) the structured is better suited for processing but the processing is allows to define complex ad-hoc (one can define any DTD types from the basic types one wants) supports key and referential XML Schema has been proposed integrity constraints to allow database like query can be used by query processing over XML documents. languages (XQuery, for XML Schema is a data definition instance) to parse XML language for XML documents documents and treat them that allows to treat them as as relational data relational data in a standardized Can be used to specify the manner data model used by a Web service interface
©IKS, ETH Zürich. WWW 13
RPC across the Web Web Services and Client/Server | The Web service architecture proposed by IBM is based on two key concepts: UDDI architecture of existing synchronous middleware platforms current specifications of SOAP, UDDI and WSDL | The architecture has a remarkable client/server flavor | It reflects only what can be SOAP done with SOAP (Simple Object Access Protocol) UDDI (Universal Description and Discovery Protocol) WSDL (Web Services WSDL Description Language) ©IKS, ETH Zürich. 15
Remote calls in RPC/DCE
©IKS, ETH Zürich. 16 Remote calls in CORBA
Service Client Identifying and locating (sever) services
Client stub Interface Implementation Skeleton CORBA repository repository Object runtime adapter
ORB ORB MIDDLEWARE Marshalling MIDDLEWARE and serializing arguments TCP/IP TCP/IP socket socket
Local Area Network
©IKS, ETH Zürich. 17
Remote calls in DCOM
Service Client Identifying and locating (sever) services
Client proxy Server stub COM Registry Registry COM runtime runtime
SCM SCM MIDDLEWARE Marshalling MIDDLEWARE and serializing arguments DCE DCE RPC RPC
SCM = Service Control Manager Local Area Network
©IKS, ETH Zürich. 18 Simple Object Access Protocol (SOAP)
SOAP as RPC mechanism
CLIENT stubs, SOAP system Wrap doc HTTP runtime in HTTP support call service Serialized POST (web location XML doc request client)
This could be RPC, CORBA, DCOM, using SOAP as protocol INTERNET
SERVER SOAP system stubs, Retrieve HTTP runtime doc from support service Serialized HTTP adapters (web XML doc response server)
©IKS, ETH Zürich. 20 Wire-protocols, XML and SOAP
| RPC, CORBA, DCOM, even Java, | To address this problem, XML was use different mechanisms and used to define SOAP (Simple Object protocols for communicating. All Access Protocol) of them map to TCP or UDP one | SOAP is conceptually quite simple: way or another but use different RPC using HTTP syntax for marshalling, serializing and packaging messages (at the client) turn an RPC call into an XML document | The problem is that these mechanisms are a legacy from (at the server) turn the XML the time when communications document into a procedure call were mostly within LANs and (at the server) turn the within homogeneous systems procedure’s response into an | Building a B2B environment XML document combining the systems of (at the client) turn the XML different companies becomes document into the response to difficult because the protocols the RPC available in RPC, CORBA, or DCOM use XML to serialize the are too low level and certainly not arguments following the SOAP compatible among each other specification (gateways are needed, etc.) ©IKS, ETH Zürich. 21
SOAP as an RPC wrapper
| SOAP has been conceived as a way of SOAP Envelope wrapping different protocols into an SOAP header XML document sent using HTTP (or other mechanisms) | Header Block The structure of a SOAP message is very simple: it contains headers and body. The header and the body can be divided SOAP Body into blocks so that the information sent in them can be structured. Body Block | SOAP as a communication protocol is also extremely simple: it only has two types of interaction (request response or notification). It also allows for client initiated or server initiated exchanges (mechanism is identical, the only difference is who starts)
©IKS, ETH Zürich. 22 What is SOAP? The W3C started working on A set of rules that must be followed SOAP in 1999. The current W3C when processing a SOAP message recommendation is Version 1.2 and a simple classification of the SOAP covers the following four entities involved in processing a main areas: SOAP message. It also specifies what A message format for one-way parts of the messages should be read communication describing how a by whom and how to react in case message can be packed into an the content is not understood XML document A set of conventions on how to turn A description of how a SOAP an RPC call into a SOAP message and message (or the XML document back as well as how to implement that makes up a SOAP message) the RPC style of interaction (how the should be transported using client makes an RPC call, this is HTTP (for Web based interaction) translated into a SOAP message, or SMTP(for e-mail based interaction) forwarded, turned into an RPC call at the server, the reply of the server converted into a SOAP message, sent to the client, and passed on to the client as the return of the RPC call)
©IKS, ETH Zürich. 23
The background for SOAP SOAP was originally conceived as the minimal possible infrastructure necessary to perform RPC through the Internet: use of XML as intermediate representation between systems very simple message structure mapping to HTTP for tunneling through firewalls and using the Web infrastructure The idea was to avoid the problems associated with CORBA’s IIOP/GIOP (which fulfilled a similar role but using a non-standard intermediate representation and had to be tunneled through HTTP anyway) The goal was to have an extension that could be easily plugged on top of existing middleware platforms to allow them to interact through the Internet rather than through a LAN as in the original case. Hence the emphasis on RPC from the very beginning (essentially all forms of middleware use RPC at one level or another) Eventually SOAP started to be presented as a generic vehicle for computer driven message exchanges through the Internet and then it was open to support interactions other than RPC and protocols other then HTTP. This process, however, is only in its very early stages.
©IKS, ETH Zürich. 24 Structure of a SOAP Message
SOAP Messages SOAP is based on message exchanges SOAP Envelope Messages are structured with an SOAP header envelope where the application encloses the data to be sent A message has two main parts: Header Block header: which can be divided into blocks SOAP Body body: which can also be divided into blocks SOAP does not say what to do Body Block with the header and the body, it only states that the header is optional and the body is mandatory Use of header and body, however, is implicit. The body is for application level data. The header is for infrastructure level data
©IKS, ETH Zürich. 26 For the XML fans (SOAP, body only)
XML name space identifier for SOAP serialization XML name space identifier for SOAP envelope
From the: Simple Object Access Protocol (SOAP) 1.1. ©W3C Note 08 May 2000
©IKS, ETH Zürich. 27
SOAP example, header and body
0
0 0 2 y xmlns:SOAP-ENV= a M "http://schemas.xmlsoap.org/soap/envelope/" 8 0 SOAP-ENV:encodingStyle= e t o "http://schemas.xmlsoap.org/soap/encoding/"/> N C 3 W © . 1 . xmlns:t="some-URI" 1 ) P SOAP-ENV:mustUnderstand="1"> A O S 5 ( l o c o t o r P s s e c c A t c e j b O e l p m i S : e h t m o r ©IKS,F ETH Zürich. 28 The SOAP header The header is intended as a generic place holder for information that is not necessarily application dependent (the application may not even be aware that a header was attached to the message). Typical uses of the header are: coordination information, identifiers (e.g., for transactions), security information (e.g., certificates) SOAP provides mechanisms to specify who should deal with headers and what to do with them. For this purpose it includes: SOAP actor attribute: who should process that particular header entry (or header block). The actor can be either: none, next, ultimateReceiver. None is used to propagate information that does not need to be processed. Next indicates that a node receiving the message can process that block. ultimateReceiver indicates the header is intended for the final recipient of the message mustUnderstand attribute: with values 1 or 0, indicating whether it is mandatory to process the header. If a node can process the message (as indicated by the actor attribute), the mustUnderstand attribute determines whether it is mandatory to do so. SOAP 1.2 adds a relay attribute (forward header if not processed) ©IKS, ETH Zürich. 29 The SOAP body The body is intended for the application specific data contained in the message A body entry (or a body block) is syntactically equivalent to a header entry with attributes actor= ultimateReceiver and mustUnderstand = 1 Unlike for headers, SOAP does specify the contents of some body entries: mapping of RPC to a collection of SOAP body entries the Fault entry (for reporting errors in processing a SOAP message) The fault entry has four elements (in 1.1): fault code: indicating the class of error (version, mustUnderstand, client, server) fault string: human readable explanation of the fault (not intended for automated processing) fault actor: who originated the fault detail: application specific information about the nature of the fault ©IKS, ETH Zürich. 30 SOAP Fault element (v 1.2) In version 1.2, the fault element is specified in more detail. It must contain two mandatory sub-elements: Code: containing a value (the code for the fault) and possibly a subcode (for application specific information) Reason: same as fault string in 1.1 and may contain a few additional elements: detail: as in 1.1 node: the identification of the node producing the fault (if absent, it defaults to the intended recipient of the message) role: the role played by the node that generated the fault Errors in understanding a mandatory header are responded using a fault element but also include a special header indicating which one o f the original headers was not understood. ©IKS, ETH Zürich. 31 Message processing SOAP specifies in detail how messages must be processed (in particular, how header entries must be processed) Each SOAP node along the message path looks at the role associated with each part of the message There are three standard roles: none, next, or ultimateReceiver Applications can define their own roles and use them in the message The role determines who is responsible for each part of a message If a block does not have a role associated to it, it defaults to ultimateReceiver If a mustUnderstand flag is included, a node that matches the role specified must process that part of the message, otherwise it must generate a fault and do not forward the message any further SOAP 1.2 includes a relay attribute. If present, a node that does not process that part of the message must forward it (i.e., it cannot remove the part) The use of the relay attribute, combined with the role next, is useful for establishing persistence information along the message path (like session information) ©IKS, ETH Zürich. 32 From TRPC to SOAP messages RPC Request SOAP Envelope SOAP header RPC Response (one of the two) Transactional SOAP Envelope SOAP Envelope context SOAP header SOAP header Transactional Transactional SOAP Body context context Name of Procedure Input param 1 SOAP Body SOAP Body Return parameter Fault entry Input param 2 ©IKS, ETH Zürich. 33 Mapping SOAP to a transport protocol SOAP and HTTP A binding of SOAP to a transport protocol is a description of how a SOAP message is to be sent using HTTP POST that transport protocol SOAPSOAP EnvelopeEnvelope The typical binding for SOAP is HTTP SOAP header Transactional SOAP can use GET or POST. With context GET, the request is not a SOAP SOAP Body message but the response is a SOAP Name of Procedure message, with POST both request and response are SOAP messages Input parameter 1 (in version 1.2, version 1.1 mainly Input parameter 2 considers the use of POST). SOAP uses the same error and status codes as those used in HTTP so that HTTP responses can be directly interpreted by a SOAP module ©IKS, ETH Zürich. 35 In XML (a request) POST /StockQuote HTTP/1.1 0 0 Host: www.stockquoteserver.com 0 2 y a Content-Type: text/xml; charset="utf-8" M 8 0 Content-Length: nnnn e t o SOAPAction: "GetLastTradePrice" N C 3 W © . 1 . 1 ) P A xmlns:SOAP-ENV= O S ( l "http://schemas.xmlsoap.org/soap/envelope/" o c o t SOAP-ENV:encodingStyle= o r P s s "http://schemas.xmlsoap.org/soap/encoding/"> e c c A t c e j b O e l p m i S : e h t m o r F ©IKS, ETH Zürich. 36 In XML (the response) 0 0 0 HTTP/1.1 200 OK 2 y a Content-Type: text/xml; charset="utf-8" M 8 0 Content-Length: nnnn e t o N C 3 W © . 1 . xmlns:SOAP-ENV= 1 ) P A "http://schemas.xmlsoap.org/soap/envelope/" O S ( l SOAP-ENV:encodingStyle= o c o t o "http://schemas.xmlsoap.org/soap/encoding/"/> r P s s e c c A t c e j b O e l p m i S : e h t m o r F ©IKS, ETH Zürich. 37 HTTP POST All together SOAPSOAP EnvelopeEnvelope SOAP header Transactional context SOAP Body Name of Procedure Input parameter 1 SERVICE REQUESTER SERVICE PROVIDER Input parameter 2 RPC call Procedure SOAP SOAP engine engine HTTP Acknowledgement HTTP engine HTTP HTTP engine HTTP SOAPSOAP EnvelopeEnvelope SOAP header Transactional context SOAP Body Return parameter ©IKS, ETH Zürich. 38 SOAP Summary SOAP, in its current form, provides SOAP takes advantage of the a basic mechanism for: standardization of XML to encapsulating messages into resolve problems of data an XML document representation and serialization (it uses XML Schema to mapping the XML document represent data and data with the SOAP message into structures, and it also relies on an HTTP request XML for serializing the data for transforming RPC calls into transmission). As XML becomes SOAP messages more powerful and additional simple rules on how to standards around XML appear, process a SOAP message SOAP can take advantage of (rules became more precise them by simply indicating what and comprehensive in v1.2 of schema and encoding is used as the specification) part of the SOAP message. SOAP is a very simple protocol Current schema and encoding intended for transferring data are generic but soon there will from one middleware platform to be vertical standards another. In spite of its claims to implementing schemas and be open (which are true), current encoding tailored to a particular specifications and are very tied to application area (e.g., the efforts RPC and HTTP. around EDI) ©IKS, ETH Zürich. 39 Web Services Description Language (WSDL) What is WSDL? The Web Services Description Language specification is in version 1.1 (March 2001) and currently under revision (v2.0 is in the working draft stage, August 2004) WSDL 1.1 discusses how to describe the different parts that comprise a Web service interface the type system used to describe the service data model (XML Schema) the messages involved in the interaction with the service the individual operations composed of 4 possible message exchange patterns the sets of operations that constitute a service the mapping to a transport protocol for the messages the location where the service provider resides groups of locations that can be used to access the same service It also includes specification indicating how to bind WSDL to the SOAP, HTTP (POST/GET) and MIME protocols ©IKS, ETH Zürich. 41 WSDL as an IDL WSDL can be best understood when we approach it as an XML version of an IDL that also covers the aspects related to integration through the Internet and the added complexity of Web services An IDL in conventional middleware and enterprise application integration platforms has several purposes: description of the interfaces of the services provided (e.g., RPC) serve as an intermediate representation for bridging heterogeneity by providing a mapping of the native data types to the intermediate representation associated to the IDL in question serve as the basis for development through an IDL compiler that produces stubs and libraries that can be use to develop the application A conventional IDL does not include information such as: location of the service (implicit in the platform and found through static or dynamic binding) different bindings (typically an IDL is bound to a transport protocol) sets of operations (since an interface defines a single access point and there is no such a thing as a sequence of operations involved in the same service) ©IKS, ETH Zürich. 42 IDL (Interface Definition Language) All RPC systems have a language Given an IDL specification, the that allows to describe services in interface compiler performs a variety an abstract manner (independent of tasks: of the programming language generates the client stub procedure used). This language has the for each procedure signature in the generic name of IDL (e.g., the IDL of interface. The stub will be then SUN RPC is called XDR) compiled and linked with the client The IDL allows to define each code service in terms of their names, and Generates a server stub. It can also input and output parameters (plus create a server main, with the stub maybe other relevant aspects). and the dispatcher compiled and An interface compiler is then used linked into it. This code can then be to generate the stubs for clients extended by the designer by writing and servers (rpcgen in SUN RPC). It the implementation of the might also generate procedure procedures headings that the programmer can It might generate a *.h file for then used to fill out the details of importing the interface and all the the implementation. necessary constants and types ©IKS, ETH Zürich. 43 Elements of WSDL 1.1 WSDL document Types (type information for the document, e.g., XML Schema) Message 1 Message 2 Message 3 Message 4 Message 5 Message 6 Operation 1 Operation 2 Operation 3 Port Type (abstract service) Abstract description of the service binding 1 binding 2 binding 3 binding 4 port 1 port 2 port 3 port 4 Service (the interface in all of the service its available implementations) Concrete description ©IKS, ETH Zürich. 44 Elements of WSDL 2.0 WSDL document Types (type information for the document, e.g., XML Schema) Message 1 Message 2 Message 3 Message 4 Message 5 Message 6 Operation 1 Operation 2 Operation 3 Interface (abstract service) Abstract description of the service binding 1 binding 2 binding 3 binding 4 endpoint 1 endpoint 2 endpoint 3 endpoint 4 Service (the interface in all of the service its available implementations) Concrete description ©IKS, ETH Zürich. 45 Types in WSDL 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 The type system is typically based on XML Schema (structures and data types) - support is mandatory for all WSDL processors An extensibility element can be used to define a schema other than XML Schema ©IKS, ETH Zürich. 46 Types in WSDL (Example) Messages and Faults Messages have a name that identifies In WSDL 1.0, the structure of a them throughout the XML document. “message” is explicitly defined, listing Messages are divided into parts, each all of its parts. of them being a data structure represented in XML. Each part must In WSDL 2.0, a “message reference have a type (basic or complex types, component” is defined as part of an previously declared in the WSDL operation and contains three document). elements : A WSDL message element matches Message label (indicating the the contents of the body of a SOAP message pattern used for the message. By looking at the types and message) looking at the message, it is possible Direction (whether it is an to build a SOAP message that inbound or outbound message) matches the WSDL description (and Message element (the actual this can be done automatically since contents of the message the description is XML based and the expressed in terms of the types types also supported by SOAP) previously defined) A message does not define any form Faults are a special kind of message of interaction, it is just a message used to report errors Operations provide the first level of In WSDL 2.0, an operation is a set of context for the messages. In WSDL messages and faults. The 1.0, there are four types of sequencing and number of operations: messages in the operation is one-way: the client send a determined by the message message to the server exchange pattern request-response: the client The style of an operation sends a request, the server distinguishes between RPC-like behavior, document oriented replies with a response message exchange or (in 2.0) set- Solicit-response: the server and get- of attributes sends a message and the Operations can be annotated with client replies features and properties (e.g., Notification: the server reliability, security, routing) sends a message ONE-WAY: REQUEST-RESPONSE: Port Types A Port Type corresponds to the abstract definition of a ©IKS, ETH Zürich. 50 Bindings and ports A binding defines message formats A port specifies the address of a and protocol details for the binding, i.e., how to access the operations and messages of a given service using a particular protocol Port Type and format A binding corresponds to a single Ports can only specify one address Port Type (obvious since it needs to and they should not contain any refer to the operations and binding information messages of the Port Type) The port is often specified as part of A Port Type can have several a service rather than on its own bindings (thereby providing several access channels to the same abstract service) 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. ©IKS, ETH Zürich. 51 Bindings and Ports (example) ©IKS, ETH Zürich. 53 Elements of WSDL WSDL document Types (type information for the document, e.g., XML Schema) Message 1 Message 2 Message 3 Message 4 Message 5 Message 6 Operation 1 Operation 2 Operation 3 Port Type (abstract service) Abstract description of the service Interface Interface Interface Interface binding 1 binding 2 binding 3 binding 4 port 1 port 2 port 3 port 4 Service (the actual service in all of the service its available implementations) Concrete description ©IKS, ETH Zürich. 54 WSDL example (1) ©IKS, ETH Zürich. 55 WSDL example (2)