Webservices (WS) and WSDL (1.1) Sources: Chitnis, M., Tiwari, P., Ananthamurthy, L.: Introduction to Web Services: Architecture, http://www.developer.com/services/article.php/1495021 Cerami, E.: Web Services Essentials, Chapter 6: WSDL Essentials, O'Reilly & Associates, (2002) Dumke, R., Lother, M., Wille, C., Zbrog, F.: Web Engineering, Person Studium, (2003) WSDL Tutorial, http://www.w3schools.com/wsdl/default.asp Christensen, E., Curbera, F., Meredith, G., Weerawarana, S.: Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl Slide Author: Jürgen Mangler (juergen.mangler@univie.ac.at) Renate Motschnig (renate.motschnig@univie.ac.at) Further Topics: XML XML Schema

Goals of This Chapter Provide an overview on most recent technologies Illustrate the importance of XML Allow students to understand the interconnections of the technologies Allow students to see interconnections with web-based architectures Allow students to estimate future development

What Is an XML Web Service? XML Web services are the fundamental building blocks in the move to distributed computing on the Internet. Open standards and the focus on communication and collaboration among people and applications have created an environment where XML Web services are becoming the platform for application integration. Applications are constructed using multiple XML Web services from various sources that work together regardless of where they reside or how they were implemented. Examples: Transaction handling, calendar service, …

Architecture of Web Services Client/server applications in use in the 80s and early 90s were primarily data-centric focus on retrieval and display of data rather than on the business rules Web applications are based on a distributed architecture they have moved away from the data-centric nature of client/server applications service-oriented architecture Remote Procedure Calls (RPC), Remote Method Invocation (RMI), to Common Object Request Broker Architecture (CORBA) are inherently service-oriented.

Web Services Introduction (http://e-serv.ebizq.net/wbs/thomas_1.html) Web services have become influential since about 2002 Strong impetus for development of both major enterprise platforms: .NET (Microsoft) J2EE (Sun Microsystems) Users, e.g.: U.K. government: Employs web services in creating an Internet-based infractructure for all government services by 2005. Software vendors such as Sun, Oracle Corp., are including web services protocols in their platform and development tools. Microsoft is planning to offer public web services, notably .NET Passport that lets you use your email address and a single password for secure sign-on to any participating web site.

Web Services - Trends Three waves of web service deployment: Partner: support complex supply chains Private: Web service protocols used to extend internal EAI (Enterprise Application Integration) efforts. Dominant mode of deployment will be mixed J2EE and .NET, hence interoperability is essential Public: full-blown adoption of services; will be delayed until standards are finalized. Web services offer a fine-grained approach to EAI and thus provide attractive means for companies who want to outsource just few particular functions.

Definition of Web Services (one of several) XML Web Services expose useful functionality to Web users through a standard Web protocol. In most cases, the protocol used is SOAP. XML Web services provide a way to describe their interfaces in enough detail to allow a user to build a client application to talk to them. This description is usually provided in an XML document called a Web Services Description Language (WSDL) document. XML Web services are registered so that potential users can find them easily. This is done with Universal Description Discovery and Integration (UDDI).

What can one do with web services? Exposing existing applications as XML Web services will allow users to build new, more powerful applications that use XML Web services as building blocks. For example, a user might develop a purchasing application to automatically obtain price information from a variety of vendors, allow the user to select a vendor, submit the order and then track the shipment until it is received. The vendor application, in addition to exposing its services on the Web, might in turn use XML Web services to check the customer's credit, charge the customer's account and set up the shipment with a shipping company.

Architecture of Web Services The application providing a service and the client application using the service talk to each other in a common language: XML A service providing application and a client application using the service need some way to locate each other before they start talking with each other: UDDI So, a basic service-oriented architecture for Web Services has: a standard way for communication a uniform data representation and exchange mechanism a standard meta language to describe the services offered a mechanism to register and locate Web Services-based applications

Architecture of Web Services Service Discovery and Publication Service Description XML based messaging Data level description Transport UDDI WSDL SOAP XML, XSchema, Encoding TCP/IP, HTTP, FTP, ... Register a WS Locate a WS Directory Services Standard comm. channel Uniform data representation and exchange WS provider WS requestor

WS Technologies - XML Uniform data representation and exchange Extended Markup Language (XML) is a meta language that has a well-defined syntax and semantics. The syntax and semantics "self describing" features of XML make it a simple, yet powerful, mechanism for capturing and exchanging data between different applications.

WS Technologies - SOAP Standard communication channel The Simple Object Access Protocol (SOAP) is the channel used for communication between a Web Services provider application and a client application. The simplicity of SOAP is that it does not define any new transport protocol; instead, it re-uses the Hyper Text Transfer Protocol (HTTP) for transporting data as messages. This use of HTTP as the underlying protocol ensures that Web Services provider applications and client applications can communicate using the Internet as the backbone.

WS Technologies - SOAP (1) SOAP is the communications protocol for XML Web services. SOAP is a specification that defines the XML format for messages. SOAP message: a well-formed XML fragment enclosed in a couple of SOAP elements. The Current SOAP standard assumes security is a transport issue and is silent on security issues.

WS Technologies - SOAP (2) Optional parts of the SOAP specification describe how to represent program data as XML and how to use SOAP to do Remote Procedure Calls. They are used to implement RPC-style applications where a SOAP message containing a callable function, and the parameters to pass to the function, is sent from the client. The server returns a message with the results of the executed function. Most current implementations of SOAP support RPC applications.

WS Technologies - SOAP (3) SOAP also supports document style applications where the SOAP message is just a wrapper around an XML document. Document-style SOAP applications provide flexibility for many new XML Web services. The last optional part of the SOAP specification defines the format of an HTTP message that contains a SOAP message. The HTTP binding is optional, but almost all SOAP implementations support it because it's the only standardized protocol for SOAP.

WS Technologies - WSDL Standard meta language to describe offered services Web Services provider applications advertise the different services they provide using a standard meta language called the Web Services Description Language (WSDL). WSDL is based on XML and uses a special set of tags to describe a Web service, services provided, where to locate them, etc. Client applications obtain information about a Web service prior to accessing and using a Web service of a Web Service provider.

WS Technologies - UDDI Registering and locating Web Services The "yellow pages" of Web Services is the Universal Description Discovery and Integration (UDDI). Web Services application providers are listed in a registry of service providers using UDDI. Similarly, client applications locate Web Services application providers using UDDI. Like in the case of WSDL, UDDI also is based on XML.

WSDL Introduction WSDL is a specification defining how to describe web services in a common XML grammar. WSDL describes four critical pieces of data: Interface information describing all publicly available functions Data type information for all message requests and message responses Binding information about the transport protocol to be used Address information for locating the specified service

refactored response (e.g. reformated) Sequence Diagram – WS's Customer UDDI Webserver (WS requestor) Webserver (WS provider) search service service found Service Description service shown service solicited request response refactored response (e.g. reformated)

WSDL Introduction WSDL represents a contract between the service requestor (client) service provider (server) like a class represents a contract between client code and the actual object. The crucial difference is that WSDL is platform- and language-independent and is used primarily (although not exclusively) to describe SOAP services. Using WSDL, a client can locate a web service and invoke any of its publicly available functions.

WSDL – Basic Design <definitions>: Root WSDL Element <types>: The data types that are involved in a transmission. <message>: What messages can be submitted? What parameters do they have? <portType>: How do the messages relate to form a method? <binding>: How will the messages be transmitted on the wire? What SOAP-specific details are there? <service>: Where ist the service located?

WSDL – <definitions> The definitions element must be the root element of all WSDL documents. It defines the name of the web service, declares multiple namespaces used throughout the remainder of the document, and contains all the service elements described here.

WSDL – <types> The types element describes all the data types used between the client and server. WSDL is not tied exclusively to a specific typing system, but it uses the W3C XML Schema specification as its default choice. If the service uses only XML Schema built-in simple types, such as strings and integers, the types element is not required. A full discussion of the types element and XML Schema is deferred to the end of the chapter.

WSDL – <message> The message element describes a one-way message, whether it is a single message request or a single message response. It defines the name of the message and contains zero or more message part elements, which can refer to message parameters or message return values.

WSDL – <portType> The portType element combines multiple message elements to form a complete one-way or round-trip operation. For example, a portType can combine one request and one response message into a single request/response operation, most commonly used in SOAP services. Note that a portType can (and frequently does) define multiple operations.

WSDL – <binding>, <service> The binding element describes the concrete specifics of how the service will be implemented on the wire. WSDL includes built-in extensions for defining SOAP services, and SOAP-specific information therefore goes here. The service element defines the address for invoking the specified service. Most commonly, this includes a URL for invoking the SOAP service.

WSDL – <documentation>, <import> In addition to the six major elements, the WSDL specification also defines the following utility elements: The documentation element is used to provide human-readable documentation and can be included inside any other WSDL element. The import element is used to import other WSDL documents or XML Schemas. This enables more modular WSDL documents. For example, two WSDL documents can import the same basic elements and yet include their own service elements to make the same service available at two physical addresses. Not all WSDL tools support the import functionality as of yet.

WSDL – Patterns of Operation One-way The service receives a message. The operation therefore has a single input element. Request-response The service receives a message and sends a response. The operation therefore has one input element, followed by one output element. To encapsulate errors, an optional fault element can also be specified. Solicit-response The service sends a message and receives a response. The operation therefore has one output element, followed by one input element. To encapsulate errors, an optional fault element can also be specified. Notification The service sends a message. The operation therefore has a single output element.

WSDL – Patterns of Operation Server Client One-way <input> Server Client Request-response 1 2 <input> <output> Server Client Solicit-response 1 2 <output> <input> Server Client Notification <output>

helloService <definitions> <types>: None <message>: sayHelloToRequest: name parameter sayHelloToResponse: greeting return value <portType>: sayHelloTo operation that consists of a request an a response message <binding>: Request-Response. <service>: Service available at http://almigthy.pri.univie.ac.at/~mangler/helloService.php

helloService - <definitions> The definitions element specifies that this document is the helloService Service. It also specifies numerous namespaces that will be used throughout the remainder of the document: <definitions name="helloService" targetNamespace="urn:helloService" xmlns:typens="urn:helloService" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/">

helloService - <types> Inside types you can declare complex data types and arrays. The targetNamespace has to point to the same urn as xmlns:typens in the <definition>. In our case this section is not needed and is therefore emtpy. <types> <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:helloService"/> </types>

helloService - <message> Two message elements are defined. The first represents a request message, sayHelloToRequest, and the second represents a response message, sayHelloToResponse: <message name="sayHelloToRequest"> <part name="name" type="xsd:string"/> </message> <message name="sayHelloToResponse"> <part name="greeting" type="xsd:string"/> Each of these messages contains a single part element. For the request, the part specifies the function parameters; in this case, we specify a single name parameter. For the response, the part specifies the function return values; in this case, we specify a single greeting return value.

helloService - <message> The part element's type attribute specifies an XML Schema data type. The value of the type attribute must be specified as an XML Schema QName--this means that the value of the attribute must be namespace-qualified. For example, the name type attribute is set to xsd:string; the xsd prefix references the namespace for XML Schema, defined earlier within the definitions element. If the function expects multiple arguments or returns multiple values, you can specify multiple part elements.

helloService - <portType> The portType element defines a single operation, called sayHelloTo. The operation itself consists of a single input message (sayHelloToRequest) and a single output message (sayHelloToResponse): <portType name="helloServicePort"> <operation name="sayHelloTo"> <input message="typens:sayHelloToRequest"/> <output message="typens:sayHelloToResponse"/> </operation> </portType>

helloService - <portType> Much like the type attribute defined earlier, the message attribute must be specified as an XML Schema QName. This means that the value of the attribute must be namespace-qualified. For example, the input element specifies a message attribute of typens:sayHelloToRequest; the typens prefix references the targetNamespace defined earlier within the definitions element.

helloService - <binding> The binding element provides specific details on how a portType operation will actually be transmitted over the wire. Bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or SOAP. In fact, you can specify multiple bindings for a single portType: <binding name="helloServiceBinding" type="typens:helloServicePort"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHelloTo"> <soap:operation soapAction="urn:sayHelloServiceAction/sayHelloTo"/> <input> <soap:body use="encoded" namespace="urn:sayHelloService" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> </output> </operation> </binding>

helloService - <binding> The type attribute references the portType defined earlier in the document. In our case, the binding element therefore references typens:helloServicePort, defined earlier in the document. The binding element is therefore saying, "I will provide specific details on how the sayHelloTo operation will be transported over the Internet."

helloService - <binding> WSDL 1.1 includes built-in extensions for SOAP 1.1. This enables you to specify SOAP-specific details, including SOAP headers, SOAP encoding styles, and the SOAPAction HTTP header. The SOAP extension elements include: soap:binding This element indicates that the binding will be made available via SOAP. style attribute: indicates the overall style of the SOAP message format. rpc: specifies an RPC format. The body of the SOAP request/response will include a wrapper XML element indicating the function name / mirroring the function request (return parameters embedded inside wraper element). document: specifies an XML document call format. Request and response messages consist simply of XML documents. It is flatter than the rpc style and does not require the use of wrapper elements.

helloService - <binding> transport attribute: indicates the transport of the SOAP messages. The value http://schemas.xmlsoap.org/soap/http indicates the SOAP HTTP transport, whereas http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport. soap:operation Indicates the binding of a specific operation to a specific SOAP implementation. The soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the service. soap:body Enables you to specify the details of the input and output messages. In the case of helloService, the body element specifies the SOAP encoding style and the namespace URN associated with the specified service.

helloService - <service> The service element specifies the location of the service. Because this is a SOAP service, we use the soap:address element: <service name="helloServiceService"> <port name="helloServicePort" binding="typens:helloServiceBinding"> <soap:address location="http://almighty.pri.univie.ac.at/~mangler/helloService.php"/> </port> </service> The included URL is also called endpoint URL. The service element includes a documentation element to provide human-readable documentation.

helloService – complexTypes, arrays <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:helloService"> <xsd:complexType name="gPRsArray"> <xsd:complexContent> <xsd:restriction base="soapenc:Array"> <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="typens:gPRsElement[]"/> </xsd:restriction> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="gPRsElement"> <xsd:all> <xsd:element name="name" type="xsd:string"/> <xsd:element name="age" type="xsd:positiveInteger"/> </xsd:all> </xsd:schema> </types>

helloService – complexTypes, arrays <message name="getPersonsRequest"> <part name="group" type="xsd:positiveInteger"/> <part name="team" type="xsd:positiveInteger"/> </message> <message name="getPersonsResponse"> <part name="greeting" type="typens:gPRsArray"/> <message name="throwFault"> <part name="anErrorOccured" type="xsd:string"/> <portType name="helloServicePort"> ... <operation name="getPersons"> <input message="typens:getPersonsRequest"/> <output message="typens:getPersonsResponse"/> <fault message="typens:throwFault"/> </operation> </portType>