Ace104 Lecture 7 WSDL in depth

Advanced Schema features (required for understanding wsdl)

Can use 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

id = xs:ID maxOccurs = ( xs:nonNegativeInteger | “unbounded” ) : “1” minOccurs = xs:nonNegativeInteger : “1” namespace = ( (“##any” | “##other” ) | list of (xs:anyURI | “##targetNamespace” | “##local”) ) ) : “##any” processContents = (“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 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 <xs:schema xmlns:xs=" xmlns:wthr=" elementFormDefault="qualified" targetNamespace=" <xs:any namespace=" processContents="strict"/>

Cities.xsd <xs:schema xmlns:xs=" targetNamespace=" elementFormDefault="qualified">

Weather.xml <wthr:weatherReport xmlns:wthr=" xmlns:xsi=" xsi:schemaLocation=" file:/Users/siegela/Desktop/xs_any_examples.xsd"> <c:city xmlns:c=" xsi:schemaLocation=" file:/Users/siegela/Desktop/cities.xsd"> Miami FL Most explicit way to tell validator where schema is located is to Use schemaLocation

Class example Step 1 –Create schema named itinerary.xsd Use targetNamespace=omega.travel.com Use ElementFormDefault=qualified Root element is Itinerary –Sequence »dateGenerated, min=1 max=1, type=date »passenger, min=1, max=unbounded, type = passengerType »departing, min=1, max=1, type=airportCode »returning, min=1, max=1, type=airportCode »preferences, min=1, max=1, type=preferenceType –passengerType: complex -> last, first each of type string –airportCode: simple -> enumeration -- ORD, MIA, etc. –preferences: complex -> meal, seating –meal: simple -> enumeration -- vegan, veg, meat-n-fat, lowcal –seating: simple -> enumeration -- aisle, window, center

Class example, cont. Step 2: –Generate sample valid sample xml Step 3: Make.xsd more flexible –Allow unspecified elements to be placed after element in element. –Specify –Revalidate xml –Add minOccurs=0 to line above to not require presence of new elements

Class Example, cont. Create new schema called fbitravel.xsd –Use namespace travel.fbi.gov –Add root element securityCode of type –In sample.xml, add a element in the location and explicitly add xsi:schemaLocation to that element. –Does validation work?

XMLschema-instance The XML schema standard also defines several attributes for direct use in any XML documents. These attributes are in a different namespace – 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

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!

41 41 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 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 The base type accepts book elements with optional titles defined as attributes or elements.

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

Corresponding XML Apology for Raymond de Sabonde Apologie par Raymond de Sabonde … this is required if type is abstract Note: if bookBase is not abstract then a bookBase type will validate also

Another example but using extension rather than restriction

?xml version="1.0" encoding="UTF-8"?> Here student type will be declared as abstract and several subtypes will be defined within the same schema

Student base type

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

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

<class xmlns:xsi=" xsi:noNamespaceSchemaLocation="file:/Users/siegela/Desktop/class.xsd"> title0 lastName0 firstName0 social0 true 3.2 Smith lastName1 firstName1 social1 3.5 Philosophy 2010 "room 201" 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)

<xs:schema xmlns:xs=" xmlns:tns=" targetNamespace=" > <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> SOAP Schema, Envelope element

<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> <xs:anyAttribute namespace="##other" processContents="lax" /> SOAP Schema, Header element

<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded” processContents="lax" /> Prose in the spec does not specify that attributes are allowed on the Body element SOAP Schema, Body element

<!-- Global Attributes. The following attributes are intended to be usable via qualified attribute names on any complex type referencing them. --> 'encodingStyle' indicates any canonicalization conventions followed in the contents of the containing element. For example, the value ' indicates the pattern described in SOAP specification

Fault reporting structure Fault element

<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> <xs:anyAttribute namespace="##any" processContents="lax" /> 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 asdkfj October 2002

Literal The literal way to do this does not include a type in the XML but rather validates against a schema <purchaseOrder xmlns= xmlns:xsi=“ xsi:schemaLocation=“ po.xsd” > 87 kdjfkl udfk

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 as we saw earlier (with lax processing).

Andrew Klein 901 NW 200 st. Miami FL <env:Envelope xmlns:env=“ xmlns:xsd=“ xmlns:xsi=“ xmlns:enc=“ xmlns:ns0=“ env:encodingStyle=“ Andrew Klein 901 NW 200 st. … Names matter but order doesn’t

<env:Envelope xmlns:env=“ xmlns:xsd=“ xmlns:xsi=“ xmlns:enc=“ xmlns:ns0=“ env:encodingStyle=“ 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]”>

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=" xmlns:tns=" xmlns:xsd1=" xmlns:soap=" xmlns=" <schema targetNamespace=" xmlns=" Sample WSDL showing types element

Sample wsdl showing message and portType elements

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport=" <soap:operation soapAction="

My first service <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="

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

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: * The input element specifies the abstract message format for the one-way operation.

Request-response The grammar for a request-response operation is: * * 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: * * 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: * 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: * ? ? * * Specified by

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. *

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. More about binding element

A service groups a set of related ports together: * 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 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)

<wsdl:definitions targetNamespace=" xmlns:http=" xmlns:mime=" xmlns:soap=" xmlns:soapenc=" xmlns:wsdl=" xmlns:xs=" xmlns:xsi=" xmlns:ws=" 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

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

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 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

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)

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 combination can give a lot of portability headaches

Simple Math Operations 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

<soap:operation soapAction=" style="document"/> <soap:body encodingStyle=" use="encoded"/>

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 hello SOAP-enc – hello

Object graphs Literal: SOAP Encoding: 10 20

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(" "GetLastTradePrice", "m"); SOAPBodyElement bodyElement = body.addBodyElement(bodyName);

QName name = new QName("symbol"); SOAPElement symbol = bodyElement.addChildElement(name); symbol.addTextNode("SUNW"); URL endpoint = new URL (" 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(); }