Web services. Introduction to WSDL. February 23, 2006.

Today. ● Introduction to WSDL. ● Soap revisited and exercises. ● Midterm.

Calling a web service. Service requester will need a service description. Three options: ● a textual description of the service, ● include sample message formats in the documentation, or ● a formal service description, in order to send a SOAP request message.

What to specify. ● Ordinary middleware: service operations, (service name, service signature). ● Web services: service access mechanisms (transport protocol, service location) Summary: ● service interface, ● protocol binding, ● endpoint address information.

Web service specification structure. WSDL (XML document). Abstract part Concrete part Protocol bindings, endpoints / ports.. Interface of supported operations: service name, service signature (in-out parameters).

Abstract (interface) WSDL part TYPES MESSAGES OPERATIONS PORT TYPES

The abstract WSDL part. ● Types. Data structures for the units (parts) which are exchanged. ● Messages. Consists of parts. ● Operations. Define the transmission primitives/ interactions. ● Port types. Assembles operations in related groups.

Example: Price check service. Purpose: extending the “inventoryCheck” web service to include price informatin, and availability. Wrapped in an operation: Request message: “product SKU number” Response message: “price” and “available units”

Concrete WSDL part BINDINGS. SERVICES AND PORTS.

The Concrete WSDL part ● Interface bindings. Specifies message encoding (SOAP encoded or literal), interaction style (RPC or document), and protocol binding per port type. ● Ports. Locations. Specifies EndPoint or network address where the implementation of the port type can be accessed. ● Services. Logical groupings of ports.

EBNF-style WSDL specification. {.. } [.. ] {.. }

The XML Schema for WSDL Any WSDL document must conform to the XML Schema at Try to download it!

The element <definitions name="PriceCheck" targetNameSpace= " xmlns:pc=" xmlns:avail=" xmlns:wsi=" xmlns:xsd=" xmlns:soap=" xmlns=" >

The element. Describes the interface to a web service as a “collection of operations” There may be 0 or more... Best practice: 1 portType definition per WSDL document.

Example Naming convention: nameOfWebServicePortType Must be unique within the WSDL document!

The elements Equivalent to a method signature in Java, defines a “method” on the web service: ● name of the method, (name attribute) ● input parameters (input message) ● output/return type (output and fault messages) Naming rule: all operation names are different!

The element. Abstract form of an input, output, or fault message. Defined by a collection of parts. There may be 0 or more... Naming rule: each message name is unique!

Example

The element Are the components/units of messages. Has two characterizing properties: ● a name (name attribute -- unique!) ● a kind (type attribute or element attribute) where type -- XSD schema type system and element -- element in the XML schema.

Example defined in the priceCheck WSDL document (listing 4.1).

The element attribute. Specifies the payload of the message on the wire. Must be the XML element which conforms to the XML schema defined in the types section. See Listing 4.1.

Example: PriceCheckRequest message. <env:Envelope xmlns:env=" xmlns:xsd=" xmlns:xsi=" 133

The part element attribute Its value must refer to : ● global XML element, declared in an XML schema in the types section of the WSDL. ● same, but imported in the types section.

Example: PriceCheckResponse message <env:Envelope xmlns:env=" xmlns:xsd=" xmlns:xsi="

Alternative priseCheckRequest

PriceCheckerRequest message <env:Envelope xmlns:env=" xmlns:xsd=" xmlns:xsi=" <ns1:checkPrice env:encodingStyle=" xmlns:ns1=" > 133

The element The place for the WSDL document to define user- defined XML types and elements. At most (1) types element!

Example of imported types. namespace=" schemalocation=" namespace=" schemalocation=" No target namespace because all types are imported!

The element ● defines the web service (ws) operations abstractly: possibly the ws-name, the input types and output types. ● Yet to specifiy the binding to SOAP, the “implementation” requirements. ● How to format messages in a protocol specific manner.

<binding elements... A can have many s. A describes how to invoke using a specific message/transport protocol: ● SOAP/HTTP ● SOAP/SMTP ● other..

Example <soap:binding style="document" transport=" /> <soap:operation soapAction= "

element name Convention: portTypeName ++ protolname (++ binding) where the protocol name is where to the binding maps. portType name must be unique!

The element Specifies the endpoint hosting the web service. Naming rule: unique among all ports in the same WSDL document.

PriceCheckSoapBinding <port name="PriceCheck" binding="pc:PriceCheckSOAPBinding"> Attribute "location" gives the URL where messages are send to.

The element Purpose: contain a set of related ports! Conventionally: ● one service per WSDL document! ● Different addresses for each port in a service!

Exercises today: 1. Repeat the soap-encoding and validation exercise from last time for (a) the simple graph of Figure 3.6 p.141, and (b) an array structure of sibling names, ordered after their age. (Get validation.zip with ftp://evarose.net) 2. Write some possible SOAP requests in RPC interaction style for the method headers:

Exercise today 2. (cont) public double sum(double a1, double a2) public String getName(int ssn); 3. investigate the web service WSDLs on

See you next week. The midterm exam is given next time (March 2). We'll continue with WSDL (Chap 4) and on calling a web service.