Transcript xs:any> - Computer Science

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
<xs:any>
<xs:any>
id
maxOccurs
minOccurs
namespace
processContents
=
=
=
=
xs:ID
( xs:nonNegativeInteger | “unbounded” ) : “1”
xs:nonNegativeInteger : “1”
( (“##any” | “##other” ) | list of (xs:anyURI |
“##targetNamespace” | “##local”) ) ) : “##any”
= (“skip” | “lax” | “strict”) : “strict”
##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 schema
strict: 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>
Most explicit way to tell validator
<c:zipcode>33169</c:zipcode>
where schema is located is to
</c:city>
Use schemaLocation
</wthr:weatherReport>
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!
<methodCall>
<methodName>
<getStateName>
</methodName>
<params>
<param>
<value>
<i4>
41
</i4>
</value>
</param>
</params>
</methodCall>
<methodCall>
<methodName>
<getStateName>
</methodName>
<params>
<param>
<value xsi:type=“xs:int”>
41
</value>
</param>
</params>
</methodCall>
Example rpc-type mechanism showing flexibility of defining
type 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 element
is implied eliminated by not appearing in the sequence, whereas
attribute 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 defined
as 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 only
as one or more elements
Corresponding XML
<book id=“12345” available=“true” xsi:type=“bookTitleElements”>
<isbn>
9294854839
</isbn>
this is required if type is abstract
<title lang=“en”>
Apology for Raymond de Sabonde
</title>
<title lang=“fr”>
Apologie par Raymond de Sabonde
</title>
…
Note: if bookBase is not abstract then a bookBase
</book>
type 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 several
subtypes 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 everything
in 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 everything
in 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:type
attribute 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)
SOAP Schema, Envelope element
<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/" >
<!-- Envelope, header and body -->
<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, Header 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, Body 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>
<!-- Global Attributes. The following attributes are intended to be usable
via qualified attribute names on any complex type referencing them. -->
<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>
Fault element
<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>
SOAP Schema, detail type
<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 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>
<identifier xsi:type=“xsd:string” >
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>
Names matter but order doesn’t
<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>
<emailAddresses>
<email>[email protected]</email>
<email> [email protected]</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”>[email protected]</email>
<email xsi:type=“xsd:string”>[email protected]</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]”>
<item href=“#ID2”/>
<item href=“#ID3/>
</ns0:ArrayOfPaymentDetail>
Web Services
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
• 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/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
Sample WSDL
showing types element
Sample wsdl showing message and portType elements
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation
soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<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-response
The 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; a
particular binding must be consulted to determine how the messages are
actually sent: within a single communication (such as a HTTP
request/response), or as two independent communications (such as two
HTTP 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 for
the solicited request and response, respectively. The optional fault
elements specify the abstract message format for any error messages
that may be output as the result of the operation (beyond those
specific 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 the
notification operation.
• A binding defines message format and protocol details for operations
and 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 defined
within in the enclosing WSDL document.
• A binding references the portType that it binds using the type
attribute. This QName value follows the linking rules defined by WSDL
• Binding extensibility elements are used to specify the concrete
grammar for the input (3), output (4), and fault messages
(5). Per-operation binding information (2) as well as per-binding
information (1) may also be specified.
• An operation element within a binding specifies binding information
for the operation with the same name within the binding's
portType. Since operation names are not required to be unique (for
example, in the case of overloading of method names), the name
attribute in the operation binding element might not be enough to
uniquely identify an operation. In that case, the correct operation
should be identified by providing the name attributes of the
corresponding 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 single
address for a binding.
<wsdl:definitions .... >
<wsdl:service .... > *
<wsdl:port name="nmtoken" binding="qname"> *
<-- extensibility element (1) -->
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
More about binding element
The name attribute provides a unique name among all ports defined
within in the enclosing WSDL document.
The binding attribute (of type QName) refers to the binding using the
linking rules defined by WSDL (see Section 2.1.2).
Binding extensibility elements (1) are used to specify the address
information for the port.
A port MUST NOT specify more than one address.
A port MUST NOT specify any binding information other than address
information.
Service 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.
Ports within a service have the following relationship:
• None of the ports communicate with each other (e.g. the output of one
port is not the input of another). If a service has several ports
that share a port type, but employ different bindings or addresses,
the ports are alternatives. Each port provides semantically equivalent
behavior (within the transport and message format limitations imposed
by each binding). This allows a consumer of a WSDL document to choose
particular 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 to
determine if it wishes to communicate to a particular service based
whether or not it supports several port types. This is useful if there
is some implied relationship between the operations of the port types,
and that the entire set of port types must be present in order to
accomplish 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 are
used for the messages defined subsequently.
Recall that it is also ok to import a schema file rather than
inline 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>
This combination
<soap:body use="encoded"/>
can give a lot of
</wsdl:input>
portability headaches
<wsdl:output>
<soap:body use="encoded"/>
</wsdl:output>
</wsdl:operation>
<!-- similar for extrema 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.
<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 autogenerated 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 element
rpc vs. document debate
• One way to think of this is as follows
– rpc versus document
• RPC Style:
String foo(String s, Integer i)
• Document Style
Class foo {
String s;
Integer I;
}
String foobar(foo);
SOAP-enc versus Literal styles
• Literal – just as plain XML
<stuff>hello</stuff>
<numbers">
<item>10</item>
<item>20</item>
<item>30</item>
<item>40</item>
<item>50</item>
</numbers>
• SOAP-enc –
<stuff xsi:type=“xsd:string”>hello</stuff>
<numbers xsi:type="SOAP-ENC:Array" SOAPENC:arrayType="xsd:integer[5]">
<item>10</item>
<item>20</item>
<item>30</item>
<item>40</item>
<item>50</item>
</numbers>
Object graphs
Literal:
<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();
}
}
}