CSPP51038 WSDL in depth. Advanced Schema features (required for understanding wsdl)

transcript

CSPP51038

WSDL in depth

Advanced Schema features(required for understanding wsdl)

<xs:any>

• Can use <xs:any namespace=“…”> in schema to specify extensibility elements– “any element can go here from the specific

namespaces”– Common technique to allow flexibility in instance

documents without forcing change to schema– We will see the wsdl files rely heavily on this– Strong implications for validation

##any: any element from any namespace##other: any element from any namespace other than the target##targetNamespace: any element from the target

skip: do not attempt validation of these elements (by looking for schema)lax : attempt validation but don’t complain if you can’t find schemastrict: attempt validation and error if you can’t find schema

Validation

• How is validation done for these <xs:any> elements?

• Very important: up to processing tool to try to find schema– You can use xsi:schemaLocation within specific

element– You can leave it up to the tool to figure out. Most

will• Look up URI and see if anything is there• Have copy of standard schema (soap-enc, etc.)• Look it up in a registry

WeatherReport.xsd

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wthr="http://www.ccis.com/ace104/weather" elementFormDefault="qualified" targetNamespace="http://www.cccis.com/ace104/weather"> <xs:element name="weatherReport"> <xs:complexType> <xs:sequence> <xs:element name="temperature" type="xs:float"/> <xs:element name="windSpeed" type="xs:integer"/> <xs:element name="humidity" type="xs:float"/> <xs:any namespace="http://www.cccis.com/ace104/weather/cities" processContents="strict"/> </xs:sequence> </xs:complexType> </xs:element></xs:schema>

Cities.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.cccis.com/ace104/weather/cities" elementFormDefault="qualified"> <xs:element name="city"> <xs:complexType> <xs:sequence> <xs:element name="name" type="xs:string"/> <xs:element name="state"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="FL"/> <xs:enumeration value="AL"/> <xs:enumeration value="MD"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="zipcode" type="xs:string”/> </xs:sequence> </xs:complexType> </xs:element></xs:schema>

Weather.xml

<?xml version="1.0" encoding="UTF-8"?><wthr:weatherReport xmlns:wthr="http://www.cccis.com/ace104/weather" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.cccis.com/ace104/weather file:/Users/siegela/Desktop/xs_any_examples.xsd"> <wthr:temperature>32</wthr:temperature> <wthr:windSpeed>23</wthr:windSpeed> <wthr:humidity>100</wthr:humidity> <c:city xmlns:c="http://www.cccis.com/ace104/weather/cities" xsi:schemaLocation="http://www.cccis.com/ace104/weather/cities file:/Users/siegela/Desktop/cities.xsd"> <c:name>Miami</c:name> <c:state>FL</c:state> <c:zipcode>33169</c:zipcode> </c:city></wthr:weatherReport>

Most explicit way to tell validatorwhere schema is located is to Use schemaLocation

XMLschema-instance

• The XML schema standard also defines several attributes for direct use in any XML documents.

• These attributes are in a different namespace– http://www.w3.org/2001/XMLSchema-instance

• We have used one of these extensively already -- xsi:schemaLocation

• Note that the standard prefix is xsi: but in practice, any prefix can be used. All schema processors have appropriate attribute declarations for these attributes built in

xsi:schemaLocation

• Recall that the xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes can be used in a document to provide hints as to the physical location of schema documents which may be used for assessment

• Processing tool may choose to override these suggestions to avoid breaking instance documents if a resource moves

<xsi:type> attribute

• The simple or complex type definition used in validation of an element is usually determined by reference to the appropriate schema components.

• An element information item in an instance may, however, explicitly assert its type using the attribute xsi:type.

• The value of this attribute is a Qname

• As we will see this is used in SOAP documents

Why xsi:type?

• Why would we want the instance document to specify the type?

• Not really necessary simply for validation, since we could use xs:union to allow an element definition to hold several types simultaneously

• Becomes important when we need the tool that reads the instance-document to know what type occurred in the instance doc!

</methodName>

<param>

</value>

</param>

</params>

</methodCall>

Example rpc-type mechanism showing flexibility of definingtype withing xml instance

What about schema

• There are a few types of relationships that can exist between schema type definition and the xsi:type – Corresponding schema contains different type

definition and xsi:type=“..” overrides it– Corresponding schema has general type and

xsi:type=“..” restricts it– For complext types, corresponding schema has

base or abstract type and xsi:type=“..” subclasses it (see next slide)

Abstract types and xsi:type

• As mentioned, another use of xsi:type is to specify a concrete instance of an abstract complex type within an instance document

• It can also be used to specify a concrete subclass of a non-abstract type, though this is often not as useful since it does not prohibit the base type from appearing in the instance document

bookBase<xs:complexType name="bookbase" abstract="true"> <xs:sequence> <xs:element ref="isbn"/> <xs:element ref="title" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="author" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="character" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute ref="id"/> <xs:attribute ref="title"/> <xs:attribute ref="available"/> </xs:complexType>

This derived type accepts only title attributes (note that elementis implied eliminated by not appearing in the sequence, whereasattribute is implied to still exist).

bookTitleAttribute<xs:complexType name="bookTitleAttribute"> <xs:complexContent> <xs:restriction base="bookbase"> <xs:sequence> <xs:element ref="isbn"/> <xs:element ref="author" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="character" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType>

The base type accepts book elements with optional titles definedas attributes or elements.

bookTitleElements

<xs:complexType name="bookTitleElements"> <xs:complexContent> <xs:restriction base="bookbase"> <xs:sequence> <xs:element ref="isbn"/> <xs:element ref="title" minOccurs="1" maxOccurs="unbounded"/> <xs:element ref="author" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute ref="title" use="prohibited"/> </xs:restriction> </xs:complexContent> </xs:complexType>

This type does not allow titles as attributes but onlyas one or more elements

Corresponding XML

<book id=“12345” available=“true” xsi:type=“bookTitleElements”> <isbn> 9294854839 </isbn> <title lang=“en”> Apology for Raymond de Sabonde </title> <title lang=“fr”> Apologie par Raymond de Sabonde </title> …</book>

this is required if type is abstract

Note: if bookBase is not abstract then a bookBasetype will validate also

Another example but using extension rather than

restriction

?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="class"> <xs:complexType> <xs:sequence> <xs:element name="title"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="courseID" type="xs:string"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="students" type="student" minOccurs="2" maxOccurs="200"/> <xs:element name="location" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element>

Here student type will be declared as abstract and severalsubtypes will be defined within the same schema

Student base type

<xs:complexType name="student" abstract="true"> <xs:sequence> <xs:element name="lastName" type="xs:string"/> <xs:element name="firstName" type="xs:string"/> <xs:element name="social" type="xs:NMTOKEN"/> </xs:sequence> </xs:complexType>

<xs:complexType name="gradStudent"> <xs:complexContent> <xs:extension base="student"> <xs:sequence> <xs:element name="funded" type="xs:boolean"/> <xs:element name="gpa" type="xs:float"/> <xs:element name="advisor" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Says that gradStudent is a sequence that has everythingin student sequence plus three additional elements funded,gpa, and advisor

<xs:complexType name="undergradStudent"> <xs:complexContent> <xs:extension base="student"> <xs:sequence> <xs:element name="gpa" type="xs:float"/> <xs:element name="major" type="xs:string"/> <xs:element name="class" type="xs:int"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Says that undergradStudent is a sequence that has everythingin student sequence plus three additional elements gpa,major, and class

<?xml version="1.0" encoding="UTF-8"?><class xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:/Users/siegela/Desktop/class.xsd"> <title>title0</title> <students xsi:type="gradStudent"> <lastName>lastName0</lastName> <firstName>firstName0</firstName> <social>social0</social> <funded>true</funded> <gpa>3.2</gpa> <advisor>Smith</advisor> </students> <students xsi:type="undergradStudent"> <lastName>lastName1</lastName> <firstName>firstName1</firstName> <social>social1</social> <gpa>3.5</gpa> <major>Philosophy</major> <class>2010</class> </students> <location>"room 201"</location></class>

Sample XML instance document showing how required xsi:typeattribute selects subclass

A little more SOAP

SOAP Reminder

• Recall that there are three parts to SOAP– A generic message envelope

• This is generally considered a nice thing

– A suggested set of encoding rules (known as “Section 5” or “SOAP encoding”)

• This is more frequently discredited these days

– A standard for represent remote procedure calls• This is somewhat discredited (at best it is harmless)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/" targetNamespace="http://schemas.xmlsoap.org/soap/envelope/" >

<xs:element name="Envelope" type="tns:Envelope" /> <xs:complexType name="Envelope" > <xs:sequence> <xs:element ref="tns:Header" minOccurs="0" /> <xs:element ref="tns:Body" minOccurs="1" /> <xs:any namespace="##other" minOccurs="0"

maxOccurs="unbounded" processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax" /> </xs:complexType>

</xs:schema>

SOAP Schema, Envelope element

<xs:element name="Header" type="tns:Header" /><xs:complexType name="Header" > <xs:sequence> <xs:any namespace="##other" minOccurs="0"

maxOccurs="unbounded" processContents="lax" />

</xs:sequence> <xs:anyAttribute namespace="##other"

processContents="lax" /></xs:complexType>

SOAP Schema, Header element

<xs:element name="Body" type="tns:Body" /> <xs:complexType name="Body" > <xs:sequence> <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded”

processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax" >

<xs:annotation> <xs:documentation>

Prose in the spec does not specify that attributes are allowed on the Body element

</xs:documentation> </xs:annotation></xs:anyAttribute>

</xs:complexType>

SOAP Schema, Body element

<xs:attribute name="mustUnderstand" > <xs:simpleType> <xs:restriction base='xs:boolean'>

<xs:pattern value='0|1' /> </xs:restriction>

</xs:simpleType> </xs:attribute> <xs:attribute name="actor" type="xs:anyURI" />

<xs:simpleType name="encodingStyle" > <xs:annotation>

<xs:documentation> 'encodingStyle' indicates any canonicalization conventions followed in the contents of the containing element.

For example, the value 'http://schemas.xmlsoap.org/soap/encoding/’ indicates the pattern described in SOAP specification </xs:documentation></xs:annotation>

<xs:list itemType="xs:anyURI" /> </xs:simpleType>

<xs:attribute name="encodingStyle" type="tns:encodingStyle" /> <xs:attributeGroup name="encodingStyle" > <xs:attribute ref="tns:encodingStyle" /> </xs:attributeGroup>

<xs:element name="Fault" type="tns:Fault" /> <xs:complexType name="Fault" final="extension" > <xs:annotation>

<xs:documentation> Fault reporting structure </xs:documentation></xs:annotation>

<xs:sequence> <xs:element name="faultcode" type="xs:QName" /> <xs:element name="faultstring" type="xs:string" /> <xs:element name="faultactor" type="xs:anyURI" minOccurs="0" /> <xs:element name="detail" type="tns:detail" minOccurs="0" /> </xs:sequence> </xs:complexType>

Fault element

<xs:complexType name="detail"> <xs:sequence> <xs:any namespace="##any" minOccurs="0"

maxOccurs="unbounded" processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##any"

processContents="lax" /> </xs:complexType>

SOAP Schema, detail type

SOAP Encoding

• Recall that in general a SOAP message needs to be able to describe the data that it is carrying to the receiver

• Two ways to do this– Refer to a schema from within the SOAP message and use

regular xs types (“literal”)– Using soap encoding (or some other encoding standard)

directly within the XML (“encoded”)• Soap-enc relies on xsi:type embedded in XML, as we just saw!

• Additional rules for arrays, object graphs, etc.

Soap-enc with simple types

• Simple types are represented using standards xs types as

<env: Envelope …>

<env:Body>

asdkfj3 339039393

</identifier>

<date xsi:type=“xsd:date” >29 October 2002</date>

Literal

• The literal way to do this does not include a type in the XML but rather validates against a schema

<purchaseOrder xmlns=http://www.cccis.com/po/schema xmlns:xsi=“http://www.w3.org.2001/XMLSchema-instance xsi:schemaLocation=“http://www.cccis.com/po/schema po.xsd”> <identifier>87 kdjfkl2393894udfk </identifier></purchaseOrder>

Compound Types• Soap-enc defines struct and array types that

are used in SOAP documents– Struct is used for aggregate types whose

components have (possibly) different names. It does not carry any special syntax (as we’ll see)

– array is used when all components have the same name

– The soap-enc schema is not intended to be used by itself, but rather embedded within the SOAP schema using the <any namespace=…> as we saw earlier (with lax processing).

<billingAddress> <name>Andrew Klein</name> <street> 901 NW 200 st.</street> <city>Miami</city> <state>FL</state> <zip>33169</zip></billingAddress>

<env:Envelope xmlns:env=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance xmlns:enc=“http://schemas.xmlsoap.org/soap/encoding/ xmlns:ns0=“http://www.cccis.com/xml env:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/> <env:Body> <ns0:billingAdress> <name xsi:type=“xsd:string”>Andrew Klein</name> <street xsi:type=“xsd:string”>901 NW 200 st.</street> … <city xsi:type=“xsd:string>33169</zip> </ns0:billingAddress>

Names matter but order doesn’t

<emailAddresses> <email>siegela@uchicago.edu</email> <email> rbaker@cccis.com</email></emailAddresses>

<env:Envelope xmlns:env=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance xmlns:enc=“http://schemas.xmlsoap.org/soap/encoding/ xmlns:ns0=“http://www.cccis.com/xml env:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/> <env:Body> <ns0:emailAddresses xsi:type=“enc:Array” ecn:arrayType=“xsd:String[2]”> <email xsi:type=“xsd:string”>siegela@uchicago.edu</email> <email xsi:type=“xsd:string”>rbaker@cccis.com</email> </ns0:emailAddresses> If all types are the

same these are optional

2d arrays, etc.

• Soap encoding also allows multidimensional arrays using references, etc.

<ns0:ArrayOfPaymentDetail id=“ID1 xsi:type=“enc:Array”

enc:arrayType=“ns0:Paymentdetail[2]”>

</ns0:ArrayOfPaymentDetail>

Web Services

• Here is a simple starting definition– “A Web Service is a software component

that is described via WSDL and is capable of being accessed via standard network protocols such as but not limited to SOAP over HTTP” - Oasis Consortium

• WSDL (Web Services Definitons Language) is the Interface Definition Language (IDL) of web services.

• To truly understand web services it is necessary to have a very deep understanding of the WSDL standard (and its associated problems)

• Relying on high level tools for rpc is not adequate!

WSDL• WSDL is an XML format for describing network services as a

set of endpoints operating on messages containing either document-oriented or procedure-oriented information.

• The operations and messages are described abstractly, and then bound to a concrete network protocol and message formats to define an endpoint.

• Related concrete endpoints are combined into abstract endpoints (services).

• WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in the SOAP standard describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

WSDL Components

• a WSDL document uses the following elements in the definition of network services:

– Types • a container for data type definitions using some type system (such as XSD).

– Message • an abstract, typed definition of the data being communicated.

– Operation • an abstract description of an action supported by the service.

– Port Type • an abstract set of operations supported by one or more endpoints.

– Binding • a concrete 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.

?xml version="1.0"?><definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">

Sample WSDL showing types element

Sample wsdl showing message and portType elements

<service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service>

</definitions>

Port types

A port type is a named set of abstract operations and the abstract messages involved.

<wsdl:definitions .... > <wsdl:portType name="nmtoken"> <wsdl:operation name="nmtoken" .... /> * </wsdl:portType></wsdl:definitions>

Messaging Modes

WSDL has four transmission primitives that an endpoint can support:

･ One-way. The endpoint receives a message.

･ Request-response. The endpoint receives a message, and sends a correlated message.

･ Solicit-response. The endpoint sends a message, and receives a correlated message.

･ Notification. The endpoint sends a message.

One-way operations

The grammar for a one-way operation is:<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:portType ></wsdl:definitions>

The input element specifies the abstract message format for the one-way operation.

Request-responseThe grammar for a request-response operation is:

<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType ></wsdl:definitions>

Note that a request-response operation is an abstract notion; aparticular binding must be consulted to determine how the messages areactually sent: within a single communication (such as a HTTPrequest/response), or as two independent communications (such as twoHTTP requests).

Solicit-response

The grammar for a solicit-response operation is:

<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType ></wsdl:definitions>

The output and input elements specify the abstract message format forthe solicited request and response, respectively. The optional faultelements specify the abstract message format for any error messagesthat may be output as the result of the operation (beyond thosespecific to the protocol).

Notification

The grammar for a notification operation is:

<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:portType ></wsdl:definitions>

The output element specifies the abstract message format for thenotification operation.

• A binding defines message format and protocol details for operationsand messages defined by a particular portType. • There may be any number of bindings for a given portType. • The grammar for a binding is as follows:

<wsdl:definitions .... > <wsdl:binding name="nmtoken" type="qname"> * <-- extensibility element (1) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element (2) --> * <wsdl:input name="nmtoken"? > ? <-- extensibility element (3) --> </wsdl:input> <wsdl:output name="nmtoken"? > ? <-- extensibility element (4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element (5) --> * </wsdl:fault> </wsdl:operation> </wsdl:binding></wsdl:definitions>

Specified by <xs:any namespace=“##other”/>

• The name attribute provides a unique name among all bindings definedwithin in the enclosing WSDL document.

• A binding references the portType that it binds using the typeattribute. This QName value follows the linking rules defined by WSDL

• Binding extensibility elements are used to specify the concretegrammar for the input (3), output (4), and fault messages(5). Per-operation binding information (2) as well as per-bindinginformation (1) may also be specified.

• An operation element within a binding specifies binding informationfor the operation with the same name within the binding'sportType. Since operation names are not required to be unique (forexample, in the case of overloading of method names), the nameattribute in the operation binding element might not be enough touniquely identify an operation. In that case, the correct operationshould be identified by providing the name attributes of thecorresponding wsdl:input and wsdl:output elements.

• A binding MUST specify exactly one protocol.

• A binding MUST NOT specify address information.

A port defines an individual endpoint by specifying a singleaddress for a binding.

<wsdl:definitions .... > <wsdl:service .... > * <wsdl:port name="nmtoken" binding="qname"> * <-- extensibility element (1) --> </wsdl:port> </wsdl:service></wsdl:definitions>

The name attribute provides a unique name among all ports definedwithin in the enclosing WSDL document.

The binding attribute (of type QName) refers to the binding using thelinking rules defined by WSDL (see Section 2.1.2).

Binding extensibility elements (1) are used to specify the addressinformation for the port.

A port MUST NOT specify more than one address.

A port MUST NOT specify any binding information other than addressinformation.

More about binding element

A service groups a set of related ports together:

<wsdl:definitions .... > <wsdl:service name="nmtoken"> * <wsdl:port .... />* </wsdl:service></wsdl:definitions>

The name attribute provides a unique name among all services defined within in the enclosing WSDL document.

Service element

Ports within a service have the following relationship:

• None of the ports communicate with each other (e.g. the output of oneport is not the input of another). If a service has several portsthat share a port type, but employ different bindings or addresses,the ports are alternatives. Each port provides semantically equivalentbehavior (within the transport and message format limitations imposedby each binding). This allows a consumer of a WSDL document to chooseparticular port(s) to communicate with based on some criteria(protocol, distance, etc.).

• By examining its ports, we can determine a service's port types. This allows a consumer of a WSDL document todetermine if it wishes to communicate to a particular service basedwhether or not it supports several port types. This is useful if thereis some implied relationship between the operations of the port types,and that the entire set of port types must be present in order toaccomplish a particular task.

Next Steps

• We now need to study in detail the binding element

• Before we do this we will solidify what we’ve learned by doing several group exercises based on what we know so far

Abstract service description

• SimpleMathService– Operation add

• Input: list of numbers• Output: single number (sum)

– Operation extrema• Input: list of numbers• Output: two numbers (min and max)

<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="http://www.example.com/webservice" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ws="http://www.example.com/webservice">

• wsdl root is the definitions element• targetNamespace attribute is namesapce that global elements of this wsdl are placed. This is important for qname references• every other namespace is used to refer to elements from corresponding schema within certain extensibility locations of wsdl file

<wsdl:types> <xs:schema targetNamespace="http://www.example.com/webservice"> <xs:complexType name="numberListType"> <xs:sequence> <xs:element name="number" type="xs:float"/> </xs:sequence> </xs:complexType> </xs:schema> </wsdl:types>

Types element is used to define any non-basic types that areused for the messages defined subsequently.

Recall that it is also ok to import a schema file rather thaninline one

Here I only need one derived type -- to represent a list of numbers both for extrema and add services

<wsdl:message name="mathOpsInput"> <wsdl:part name="numberList" type="ws:numberListType"/> </wsdl:message>

<wsdl:message name="addOpOutput"> <wsdl:part name="number" type="xs:float"/> </wsdl:message>

<wsdl:message name="extremaOutput"> <wsdl:part name="min" type="xs:float"/> <wsdl:part name="max" type="xs:float"/> </wsdl:message>

• each message represents what can be thought of as input and output data for a particular operation(s)

• each data element is specified as a <wsdl part> and has either a simple or derived datatype

• parts can be thought of as parameters if we think of rpc -- but we can think more loosely of message-oriented

<wsdl:portType name="simpleMath"> <wsdl:operation name="add"> <wsdl:input message="ws:mathOpsInput"/> <wsdl:output message="ws:addOpOutput"/> </wsdl:operation>

<wsdl:operation name="extrema"> <wsdl:input message="ws:mathOpsInput"/> <wsdl:output message="ws:extremaOutput"/> </wsdl:operation> </wsdl:portType>

• portType is a collection of functions. In this case we only have two and one portType is adequate. In general we can make more detailed groupings.

• for two-way request-response messages, each portType has an input and an output message. These messages are referred to using the message attribute. They must refer to message elements defined in the same wsdl (qnames)

<wsdl:binding name="simpleMathSoapBinding" type="ws:simpleMath"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="add"> <soap:operation soapAction="http://people.cs.uchicago.edu/ace104/math"/> <wsdl:input> <soap:body use="encoded"/> </wsdl:input> <wsdl:output> <soap:body use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding>

• the binding element makes the abstract portType definitions concrete. Here we bind the message to SOAP over http

• other details are very important• use=“encoded | literal” : to use soap encoding vs datatypes associated with schema• style=“rpc | document” : represent as method name, params vs. use XML instance directly as body.

This combinationcan give a lot ofportability headaches

<wsdl:service name="simpleMathService"> <wsdl:documentation>Simple Math Operations</wsdl:documentation> <wsdl:port name="simpleMath" binding="ws:simpleMathSoapBinding"> <soap:address location="http://people.cs.uchicago.edu/…"/> </wsdl:port> </wsdl:service>

• Service is a collection of ports with their associated bindings

• It is common to have multiple bindings for the same port• for example both SOAP (over http) and direct http• mime, SMTP are other common bindings• you can also create your own without changing the wsdl• however, it probably won’t be too useful for others

WSDL SOAP Analyzer

• Good idea to use a tool to validate your WSDL and check for adherence to WS-I interoperability standards.

• Also, good idea to see sample auto-generated SOAP messages for the various combinations of settings.

• These can be quite a mess. document/literal seems to be the best bet for portability

A one-way example

• Access a Date Service that returns the Date and GMT

• Input: none

• Output: date and time

• Allow multiple bindings to single port

<wsdl:message name="dateTimeOutput"> <wsdl:part name="dateTime" type="xs:date"/> </wsdl:message>

<wsdl:portType name="Date"> <wsdl:operation name="getDateTime"> <wsdl:output message="ws:dateTimeOutput"/> </wsdl:operation> </wsdl:portType>

<wsdl:binding name="DateSoapBinding" type="ws:Date"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="getDateTime"> <soap:operation soapAction="http://www.example.com/webservice" style="document"/> <wsdl:output> <soap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="encoded"/>

</wsdl:output> </wsdl:operation> </wsdl:binding>

<wsdl:binding name="DateHttpGet" type="ws:Date"> <http:binding verb="GET"/> <wsdl:operation name="getDateTime"> <http:operation location="/GetBriefings"/> <wsdl:output> <mime:mimeXml part="Body"/> </wsdl:output> </wsdl:operation> </wsdl:binding>

Problems with WSDL

• WSDL not well defined/described– The original spec uses definition by example

• Early WSDL tools highly incompatible– Different interpretations – e.g. when to use xsd:import; when to use

wsdl:import

• Not so bad today (if using the major toolkits)

More on binding elementrpc vs. document debate

• One way to think of this is as follows– rpc versus document

• RPC Style:String foo(String s, Integer i)

• Document StyleClass foo {

String s;Integer I;

}String foobar(foo);

SOAP-enc versus Literal styles

• Literal – just as plain XML<stuff>hello</stuff><numbers">

</numbers>

• SOAP-enc – <stuff xsi:type=“xsd:string”>hello</stuff>

</numbers>

Object graphsLiteral:<Distance> <p1> <x>10</x> <y>20</y> </p1> <p2> <x>10</x> <y>20</y> </p2> <Distance>

SOAP Encoding:<Distance> <p1 HREF="#id1"/> <p2 HREF="#id1"/> </Distance> <Point id="id1"> <x>10</x> <y>20</y> </Point>

XML Schema

• Officially any XML Schema construct is valid in WSDL

• In practice…– e.g. for a long time Java tools were defined by

JAX-RPC which defined a subset of valid XML Schema

– e.g. in early stages of SRU the following caused headaches:

• xsd:positiveInteger, xsd:nonNegativeInteger etc.

Enter WS-I

• Web Service Interoperability profile– Key components: SOAP, WSDL, UDDI

• Defines a set of rules for interoperable WebServices– e.g. use SOAP document/literal style– Rules for wsdl:import versus xsd:import– Still defines any XML Schema as valid etc.

• Compliant toolsets much better at interoperating today

import javax.xml.soap.*;import javax.xml.namespace.QName;import java.util.Iterator;import java.net.URL;

public class Request { public static void main(String[] args) { try { SOAPConnectionFactory soapConnectionFactory = SOAPConnectionFactory.newInstance(); SOAPConnection connection = soapConnectionFactory.createConnection();

MessageFactory factory = MessageFactory.newInstance(); SOAPMessage message = factory.createMessage();

SOAPHeader header = message.getSOAPHeader(); SOAPBody body = message.getSOAPBody(); header.detachNode();

QName bodyName = new QName("http://wombat.ztrade.com", "GetLastTradePrice", "m"); SOAPBodyElement bodyElement = body.addBodyElement(bodyName);

QName name = new QName("symbol"); SOAPElement symbol = bodyElement.addChildElement(name); symbol.addTextNode("SUNW");

URL endpoint = new URL ("http://wombat.ztrade.com/quotes"); SOAPMessage response = connection.call(message, endpoint);

connection.close();

SOAPBody soapBody = response.getSOAPBody();

Iterator iterator = soapBody.getChildElements(bodyName); bodyElement = (SOAPBodyElement)iterator.next(); String lastPrice = bodyElement.getValue();

System.out.print("The last price for SUNW is "); System.out.println(lastPrice);

} catch (Exception ex) { ex.printStackTrace(); } }}

CSPP51038 WSDL in depth. Advanced Schema features (required for understanding wsdl)

Documents