Pages

Showing posts with label Webservice. Show all posts
Showing posts with label Webservice. Show all posts

1/16/2008

MIME Binding

MIME Binding

WSDL includes a way to bind abstract types to concrete messages in some MIME format. Bindings for the following MIME types are defined:

  • multipart/related
  • text/xml
  • application/x-www-form-urlencoded (the format used to submit a form in HTML)
  • Others (by specifying the MIME type string)

The set of defined MIME types is both large and evolving, so it is not a goal for WSDL to exhaustively define XML grammar for each MIME type. Nothing precludes additional grammar to be added to define additional MIME types as necessary. If a MIME type string is sufficient to describe the content, the mime element defined below can be used.

5.11 MIME Binding example

Example 7. Using multipart/related with SOAP

This example describes that a GetCompanyInfo SOAP 1.1 request may be sent to a StockQuote service via the SOAP 1.1 HTTP binding. The request takes a ticker symbol of type string. The response contains multiple parts encoded in the MIME format multipart/related: a SOAP Envelope containing the current stock price as a float, zero or more marketing literature documents in HTML format, and an optional company logo in either GIF or JPEG format.

<definitions .... >

<types>

<schema .... >

<element name="GetCompanyInfo">

<complexType>

<all>

<element name="tickerSymbol " type="string"/>

</all>

</complexType>

</element>

<element name="GetCompanyInfoResult">

<complexType>

<all>

<element name="result" type="float"/>

</all>

</complexType>

</element>

<complexType name="ArrayOfBinary">

<complexContent>

<restriction base="soapenc:Array">

<attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:binary[]"/>

</restriction>

<complexContent>

</complexType>

</schema>

</types>

<message name="m1">

<part name="body" element="tns:GetCompanyInfo"/>

</message>

<message name="m2">

<part name="body" element="tns:GetCompanyInfoResult"/>

<part name="docs" type="xsd:string"/>

<part name="logo" type="tns:ArrayOfBinary"/>

</message>

<portType name="pt1">

<operation name="GetCompanyInfo">

<input message="m1"/>

<output message="m2"/>

</operation>

</portType>

<binding name="b1" type="tns:pt1">

<operation name="GetCompanyInfo">

<soap:operation soapAction="http://example.com/GetCompanyInfo"/>

<input>

<soap:body use="literal"/>

</input>

<output>

<mime:multipartRelated>

<mime:part>

<soap:body parts="body" use="literal"/>

</mime:part>

<mime:part>

<mime:content part="docs" type="text/html"/>

</mime:part>

<mime:part>

<mime:content part="logo" type="image/gif"/>

<mime:content part="logo" type="image/jpeg"/>

</mime:part>

</mime:multipartRelated>

</output>

</operation>

</binding>

<service name="CompanyInfoService">

<port name="CompanyInfoPort"binding="tns:b1">

<soap:address location="http://example.com/companyinfo"/>

</port>

</service>

</definitions>

5.2 How the MIME Binding extends WSDL

The MIME Binding extends WSDL with the following extension elements:

<mime:content part="nmtoken"? type="string"?/>

<mime:multipartRelated>

<mime:part> *

<-- mime element -->

</mime:part>

</mime:multipartRelated>

<mime:mimeXml part="nmtoken"?/>

They are used at the following locations in WSDL:

<definitions .... >

<binding .... >

<operation .... >

<input .... >

<-- mime elements -->

</input>

<output .... >

<-- mime elements -->

</output>

</operation>

</binding>

</definitions>

MIME elements appear under input and output to specify the MIME format. If multiple appear, they are considered to be alternatives.

5.3 mime:content

To avoid having to define a new element for every MIME format, the mime:content element may be used if there is no additional information to convey about the format other than its MIME type string.

<mime:content part="nmtoken"? type="string"?/>

The part attribute is used to specify the name of the message part. If the message has a single part, then the part attribute is optional. The type attribute contains the MIME type string. A type value has two portions, separated by a slash (/), either of which may be a wildcard (*). Not specifying the type attribute indicates that all MIME types are acceptable.

If the return format is XML, but the schema is not known ahead of time, the generic mime element can be used indicating text/xml:

<mime:content type="text/xml"/>

A wildcard (*) can be used to specify a family of mime types, for example all text types.

<mime:content type="text/*"/>

The following two examples both specify all mime types:

<mime:content type="*/*"/>

<mime:content/>

5.4 mime:multipartRelated

The multipart/related MIME type aggregates an arbitrary set of MIME formatted parts into one message using the MIME type "multipart/related". The mime:multipartRelated element describes the concrete format of such a message:

<mime:multipartRelated>

<mime:part> *

<-- mime element -->

</mime:part>

</mime:multipartRelated>

The mime:part element describes each part of a multipart/related message. MIME elements appear within mime:part to specify the concrete MIME type for the part. If more than one MIME element appears inside a mime:part, they are alternatives.

5.5 soap:body

When using the MIME binding with SOAP requests, it is legal to use the soap:body element as a MIME element. It indicates the content type is "text/xml", and there is an enclosing SOAP Envelope.

5.6 mime:mimeXml

To specify XML payloads that are not SOAP compliant (do not have a SOAP Envelope), but do have a particular schema, the mime:mimeXml element may be used to specify that concrete schema. The part attribute refers to a message part defining the concrete schema of the root XML element. The part attribute MAY be omitted if the message has only a single part. The part references a concrete schema using the element attribute for simple parts or type attribute for composite parts (see section 2.3.1).

<mime:mimeXml part="nmtoken"?/>

HTTP GET & POST Binding

HTTP GET & POST Binding

WSDL includes a binding for HTTP 1.1's GET and POST verbs in order to describe the interaction between a Web Browser and a web site. This allows applications other than Web Browsers to interact with the site. The following protocol specific information may be specified:

  • An indication that a binding uses HTTP GET or POST
  • An address for the port
  • A relative address for each operation (relative to the base address defined by the port)

4.1 HTTP GET/POST Examples

The following example shows three ports that are bound differently for a given port type.

If the values being passed are part1=1, part2=2, part3=3, the request format would be as follows for each port:

port1: GET, URL="http://example.com/o1/A1B2/3"

port2: GET, URL="http://example.com/o1?p1=1&p2=2&p3=3

port3: POST, URL="http://example.com/o1", PAYLOAD="p1=1&p2=2&p3=3"

For each port, the response is either a GIF or a JPEG image.

Example 6. GET and FORM POST returning GIF or JPG

<definitions .... >

<message name="m1">

<part name="part1" type="xsd:string"/>

<part name="part2" type="xsd:int"/>

<part name="part3" type="xsd:string"/>

</message>

<message name="m2">

<part name="image" type="xsd:binary"/>

</message>

<portType name="pt1">

<operation name="o1">

<input message="tns:m1"/>

<output message="tns:m2"/>

</operation>

</portType>

<service name="service1">

<port name="port1" binding="tns:b1">

<http:address location="http://example.com/"/>

</port>

<port name="port2" binding="tns:b2">

<http:address location="http://example.com/"/>

</port>

<port name="port3" binding="tns:b3">

<http:address location="http://example.com/"/>

</port>

</service>

<binding name="b1" type="pt1">

<http:binding verb="GET"/>

<operation name="o1">

<http:operation location="o1/A(part1)B(part2)/(part3)"/>

<input>

<http:urlReplacement/>

</input>

<output>

<mime:content type="image/gif"/>

<mime:content type="image/jpeg"/>

</output>

</operation>

</binding>

<binding name="b2" type="pt1">

<http:binding verb="GET"/>

<operation name="o1">

<http:operation location="o1"/>

<input>

<http:urlEncoded/>

</input>

<output>

<mime:content type="image/gif"/>

<mime:content type="image/jpeg"/>

</output>

</operation>

</binding>

<binding name="b3" type="pt1">

<http:binding verb="POST"/>

<operation name="o1">

<http:operation location="o1"/>

<input>

<mime:content type="application/x-www-form-urlencoded"/>

</input>

<output>

<mime:content type="image/gif"/>

<mime:content type="image/jpeg"/>

</output>

</operation>

</binding>

</definitions>

4.2 How the HTTP GET/POST Binding Extends WSDL

The HTTP GET/POST Binding extends WSDL with the following extension elements:

<definitions .... >

<binding .... >

<http:binding verb="nmtoken"/>

<operation .... >

<http:operation location="uri"/>

<input .... >

<-- mime elements -->

</input>

<output .... >

<-- mime elements -->

</output>

</operation>

</binding>

<port .... >

<http:address location="uri"/>

</port>

</definitions>

These elements are covered in the subsequent sections.

4.3 http:address

The location attribute specifies the base URI for the port. The value of the attribute is combined with the values of the location attribute of the http:operation binding element. See section 4.5 for more details.

4.4 http:binding

The http:binding element indicates that this binding uses the HTTP protocol.

<definitions .... >

<binding .... >

<http:binding verb="nmtoken"/>

</binding>

</definitions>

The value of the required verb attribute indicates the HTTP verb. Common values are GET or POST, but others may be used. Note that HTTP verbs are case sensitive.

4.5 http:operation

The location attribute specifies a relative URI for the operation. This URI is combined with the URI specified in the http:address element to form the full URI for the HTTP request. The URI value MUST be a relative URI.

<definitions .... >

<binding .... >

<operation .... >

<http:operation location="uri"/>

</operation>

</binding>

</definitions>

4.6 http:urlEncoded

The urlEncoded element indicates that all the message parts are encoded into the HTTP request URI using the standard URI-encoding rules (name1=value&name2=value…). The names of the parameters correspond to the names of the message parts. Each value contributed by the part is encoded using a name=value pair. This may be used with GET to specify URL encoding, or with POST to specify a FORM-POST. For GET, the "?" character is automatically appended as necessary.

<http:urlEncoded/>

For more information on the rules for URI-encoding parameters, see [5], [6], and [7].

4.7 http:urlReplacement

The http:urlReplacement element indicates that all the message parts are encoded into the HTTP request URI using a replacement algorithm:

  • The relative URI value of http:operation is searched for a set of search patterns.
  • The search occurs before the value of the http:operation is combined with the value of the location attribute from http:address.
  • There is one search pattern for each message part. The search pattern string is the name of the message part surrounded with parenthesis "(" and ")".
  • For each match, the value of the corresponding message part is substituted for the match at the location of the match.
  • Matches are performed before any values are replaced (replaced values do not trigger additional matches).

Message parts MUST NOT have repeating values.

<http:urlReplacement/>

How the SOAP Binding Extends WSDL

How the SOAP Binding Extends WSDL

The SOAP Binding extends WSDL with the following extension elements:

<definitions .... >

<binding .... >

<soap:binding style="rpc|document" transport="uri">

<operation .... >

<soap:operation soapAction="uri"? style="rpc|document"?>?

<input>

<soap:body parts="nmtokens"? use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>

<soap:header message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>*

<soap:headerfault message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?/>*

<soap:header>

</input>

<output>

<soap:body parts="nmtokens"? use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>

<soap:header message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>*

<soap:headerfault message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?/>*

<soap:header>

</output>

<fault>*

<soap:fault name="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>

</fault>

</operation>

</binding>

<port .... >

<soap:address location="uri"/>

</port>

</definitions>

Each extension element of the SOAP binding is covered in subsequent sections.

3.3 soap:binding

The purpose of the SOAP binding element is to signify that the binding is bound to the SOAP protocol format: Envelope, Header and Body. This element makes no claims as to the encoding or format of the message (e.g. that it necessarily follows section 5 of the SOAP 1.1 specification).

The soap:binding element MUST be present when using the SOAP binding.

<definitions .... >

<binding .... >

<soap:binding transport="uri"? style="rpc|document"?>

</binding>

</definitions>

The value of the style attribute is the default for the style attribute for each contained operation. If the style attribute is omitted, it is assumed to be "document". See section 3.4 for more information on the semantics of style.

The value of the required transport attribute indicates which transport of SOAP this binding corresponds to. The URI value http://schemas.xmlsoap.org/soap/http corresponds to the HTTP binding in the SOAP specification. Other URIs may be used here to indicate other transports (such as SMTP, FTP, etc.).

3.4 soap:operation

The soap:operation element provides information for the operation as a whole.

<definitions .... >

<binding .... >

<operation .... >

<soap:operation soapAction="uri"? style="rpc|document"?>?

</operation>

</binding>

</definitions>

The style attribute indicates whether the operation is RPC-oriented (messages containing parameters and return values) or document-oriented (message containing document(s)). This information may be used to select an appropriate programming model. The value of this attribute also affects the way in which the Body of the SOAP message is constructed, as explained in Section 3.5 below. If the attribute is not specified, it defaults to the value specified in the soap:binding element. If the soap:binding element does not specify a style, it is assumed to be "document".

The soapAction attribute specifies the value of the SOAPAction header for this operation. This URI value should be used directly as the value for the SOAPAction header; no attempt should be made to make a relative URI value absolute when making the request. For the HTTP protocol binding of SOAP, this is value required (it has no default value). For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted.

3.5 soap:body

The soap:body element specifies how the message parts appear inside the SOAP Body element.

The parts of a message may either be abstract type definitions, or concrete schema definitions. If abstract definitions, the types are serialized according to some set of rules defined by an encoding style. Each encoding style is identified using a list of URIs, as in the SOAP specification. Since some encoding styles such as the SOAP Encoding (http://schemas.xmlsoap.org/soap/encoding/) allow variation in the message format for a given set of abstract types, it is up to the reader of the message to understand all the format variations: "reader makes right". To avoid having to support all variations, a message may be defined concretely and then indicate it’s original encoding style (if any) as a hint. In this case, the writer of the message must conform exactly to the specified schema: "writer makes right".

The soap:body binding element provides information on how to assemble the different message parts inside the Body element of the SOAP message. The soap:body element is used in both RPC-oriented and document-oriented messages, but the style of the enclosing operation has important effects on how the Body section is structured:

  • If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.
  • If the operation style is document there are no additional wrappers, and the message parts appear directly under the SOAP Body element.

The same mechanisms are used to define the content of the Body and parameter accessor elements.

<definitions .... >

<binding .... >

<operation .... >

<input>

<soap:body parts="nmtokens"? use="literal|encoded"?

encodingStyle="uri-list"? namespace="uri"?>

</input>

<output>

<soap:body parts="nmtokens"? use="literal|encoded"?

encodingStyle="uri-list"? namespace="uri"?>

</output>

</operation>

</binding>

</definitions>

The optional parts attribute of type nmtokens indicates which parts appear somewhere within the SOAP Body portion of the message (other parts of a message may appear in other portions of the message such as when SOAP is used in conjunction with the multipart/related MIME binding). If the parts attribute is omitted, then all parts defined by the message are assumed to be included in the SOAP Body portion.

The required use attribute indicates whether the message parts are encoded using some encoding rules, or whether the parts define the concrete schema of the message.

If use is encoded, then each message part references an abstract type using the type attribute. These abstract types are used to produce a concrete message by applying an encoding specified by the encodingStyle attribute. The part names, types and value of the namespace attribute are all inputs to the encoding, although the namespace attribute only applies to content not explicitly defined by the abstract types. If the referenced encoding style allows variations in it’s format (such as the SOAP encoding does), then all variations MUST be supported ("reader makes right").

If use is literal, then each part references a concrete schema definition using either the element or type attribute. In the first case, the element referenced by the part will appear directly under the Body element (for document style bindings) or under an accessor element named after the message part (in rpc style). In the second, the type referenced by the part becomes the schema type of the enclosing element (Body for document style or part accessor element for rpc style). For an example that illustrates defining the contents of a composite Body using a type, see section 2.3.1. The value of the encodingStyle attribute MAY be used when the use is literal to indicate that the concrete format was derived using a particular encoding (such as the SOAP encoding), but that only the specified variation is supported ("writer makes right").

The value of the encodingStyle attribute is a list of URIs, each separated by a single space. The URI's represent encodings used within the message, in order from most restrictive to least restrictive (exactly like the encodingStyle attribute defined in the SOAP specification).

3.6 soap:fault

The soap:fault element specifies the contents of the contents of the SOAP Fault Details element. It is patterned after the soap:body element (see section 3.5).

<definitions .... >

<binding .... >

<operation .... >

<fault>*

<soap:fault name="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>

</fault>

</operation>

</binding>

</definitions>

The name attribute relates the soap:fault to the wsdl:fault defined for the operation.

The fault message MUST have a single part. The use, encodingStyle and namespace attributes are all used in the same way as with soap:body (see section 3.5), only style="document" is assumed since faults do not contain parameters.

3.7 soap:header and soap:headerfault

The soap:header and soap:headerfault elements allows header to be defined that are transmitted inside the Header element of the SOAP Envelope. It is patterned after the soap:body element (see section 3.5).

It is not necessary to exhaustively list all headers that appear in the SOAP Envelope using soap:header. For example, extensions (see section 2.1.3) to WSDL may imply specific headers should be added to the actual payload and it is not required to list those headers here.

<definitions .... >

<binding .... >

<operation .... >

<input>

<soap:header message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>*

<soap:headerfault message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?/>*

<soap:header>

</input>

<output>

<soap:header message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?>*

<soap:headerfault message="qname" part="nmtoken" use="literal|encoded"

encodingStyle="uri-list"? namespace="uri"?/>*

<soap:header>

</output>

</operation>

</binding>

</definitions>

The use, encodingStyle and namespace attributes are all used in the same way as with soap:body (see section 3.5), only style="document" is assumed since headers do not contain parameters.

Together, the message attribute (of type QName) and the part attribute (of type nmtoken) reference the message part that defines the header type. The schema referenced by the part MAY include definitions for the soap:actor and soap:mustUnderstand attributes if use="literal", but MUST NOT if use="encoded". The referenced message need not be the same as the message that defines the SOAP Body.

The optional headerfault elements which appear inside soap:header and have the same syntax as soap:header) allows specification of the header type(s) that are used to transmit error information pertaining to the header defined by the soap:header. The SOAP specification states that errors pertaining to headers must be returned in headers, and this mechanism allows specification of the format of such headers.

3.8 soap:address

The SOAP address binding is used to give a port an address (a URI). A port using the SOAP binding MUST specify exactly one address. The URI scheme specified for the address must correspond to the transport specified by the soap:binding.

<definitions .... >

<port .... >

<binding .... >

<soap:address location="uri"/>

</binding>

</port>

</definitions>

SOAP

SOAP Binding

WSDL includes a binding for SOAP 1.1 endpoints, which supports the specification of the following protocol specific information:

  • An indication that a binding is bound to the SOAP 1.1 protocol
  • A way of specifying an address for a SOAP endpoint.
  • The URI for the SOAPAction HTTP header for the HTTP binding of SOAP
  • A list of definitions for Headers that are transmitted as part of the SOAP Envelope

This binding grammar it is not an exhaustive specification since the set of SOAP bindings is evolving. Nothing precludes additional SOAP bindings to be derived from portions of this grammar. For example:

  • SOAP bindings that do not employ a URI addressing scheme may substitute another addressing scheme by replacing the soap:address element defined in section 3.8.
  • SOAP bindings that do not require a SOAPAction omit the soapAction attribute defined in section 3.4.

3.1 SOAP Examples

In the following example, a SubscribeToQuotes SOAP 1.1 one-way message is sent to a StockQuote service via a SMTP binding. The request takes a ticker symbol of type string, and includes a header defining the subscription URI.

Example 3. SOAP binding of one-way operation over SMTP using a SOAP Header

<?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/">

<message name="SubscribeToQuotes">

<part name="body" element="xsd1:SubscribeToQuotes"/>

<part name="subscribeheader" element="xsd1:SubscriptionHeader"/>

</message>

<portType name="StockQuotePortType">

<operation name="SubscribeToQuotes">

<input message="tns:SubscribeToQuotes"/>

</operation>

</portType>

<binding name="StockQuoteSoap" type="tns:StockQuotePortType">

<soap:binding style="document" transport="http://example.com/smtp"/>

<operation name="SubscribeToQuotes">

<input message="tns:SubscribeToQuotes">

<soap:body parts="body" use="literal"/>

<soap:header message="tns:SubscribeToQuotes" part="subscribeheader" use="literal"/>

</input>

</operation>

</binding>

<service name="StockQuoteService">

<port name="StockQuotePort" binding="tns:StockQuoteSoap">

<soap:address location="mailto:subscribe@example.com"/>

</port>

</service>

<types>

<schema targetNamespace="http://example.com/stockquote.xsd"

xmlns="http://www.w3.org/2000/10/XMLSchema">

<element name="SubscribeToQuotes">

<complexType>

<all>

<element name="tickerSymbol" type="string"/>

</all>

</complexType>

</element>

<element name="SubscriptionHeader" type="uriReference"/>

</schema>

</types>

</definitions>

This example describes that a GetTradePrice SOAP 1.1 request may be sent to a StockQuote service via the SOAP 1.1 HTTP binding. The request takes a ticker symbol of type string, a time of type timeInstant, and returns the price as a float in the SOAP response.

Example 4. SOAP binding of request-response RPC operation over HTTP

<?xml version="1.0"?>

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"

xmlns:tns="http://example.com/stockquote.wsdl"

xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"

xmlns:xsd1="http://example.com/stockquote.xsd"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="GetTradePriceInput">

<part name="tickerSymbol" element="xsd:string"/>

<part name="time" element="xsd:timeInstant"/>

</message>

<message name="GetTradePriceOutput">

<part name="result" type="xsd:float"/>

</message>

<portType name="StockQuotePortType">

<operation name="GetTradePrice">

<input message="tns:GetTradePriceInput"/>

<output message="tns:GetTradePriceOutput"/>

</operation>

</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="GetTradePrice">

<soap:operation soapAction="http://example.com/GetTradePrice"/>

<input>

<soap:body use="encoded" namespace="http://example.com/stockquote"

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

</input>

<output>

<soap:body use="encoded" namespace="http://example.com/stockquote"

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

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

This example describes that a GetTradePrices SOAP 1.1 request may be sent to a StockQuote service via the SOAP 1.1 HTTP binding. The request takes a stock quote symbol string, an application defined TimePeriod structure containing a start and end time and returns an array of stock prices recorded by the service within that period of time, as well as the frequency at which they were recorded as the SOAP response. The RPC signature that corresponds to this service has in parameters tickerSymbol and timePeriod followed by the output parameter frequency, and returns an array of floats.

Example 5. SOAP binding of request-response RPC operation over HTTP

<?xml version="1.0"?>

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"

xmlns:tns="http://example.com/stockquote.wsdl"

xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"

xmlns:xsd1="http://example.com/stockquote/schema"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>

<schema targetNamespace="http://example.com/stockquote/schema"

xmlns="http://www.w3.org/2000/10/XMLSchema">

<complexType name="TimePeriod">

<all>

<element name="startTime" type="xsd:timeInstant"/>

<element name="endTime" type="xsd:timeInstant"/>

</all>

</complexType>

<complexType name="ArrayOfFloat">

<complexContent>

<restriction base="soapenc:Array">

<attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:float[]"/>

</restriction>

</complexContent>

</complexType>

</schema>

</types>

<message name="GetTradePricesInput">

<part name="tickerSymbol" element="xsd:string"/>

<part name="timePeriod" element="xsd1:TimePeriod"/>

</message>

<message name="GetTradePricesOutput">

<part name="result" type="xsd1:ArrayOfFloat"/>

<part name="frequency" type="xsd:float"/>

</message>

<portType name="StockQuotePortType">

<operation name="GetLastTradePrice" parameterOrder="tickerSymbol timePeriod frequency">

<input message="tns:GetTradePricesInput"/>

<output message="tns:GetTradePricesOutput"/>

</operation>

</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="GetTradePrices">

<soap:operation soapAction="http://example.com/GetTradePrices"/>

<input>

<soap:body use="encoded" namespace="http://example.com/stockquote"

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

</input>

<output>

<soap:body use="encoded" namespace="http://example.com/stockquote"

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

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