First Look at WSDL 2.0

SAP Developer Network

Summary

This article describes the status of WSDL (Web Services Description Language) 2.0 and compares it to its predecessor, WSDL 1.1.

By Canyang Kevin Liu

06 Jan 2005

 

Overview

Web Services Description Language (WSDL) is an XML format for describing web services. Using WSDL, a service provider can describe the expectations and functionality of a single web service in a platform-independent way, so that potential requestors can understand how to correctly interact with the service. In the world of loosely-coupled web services, WSDL plays a central role for interoperability among services implemented in different platforms.

The WSDL language was initially developed by Microsoft and IBM. WSDL 1.1 was co-submitted to W3C by Microsoft, IBM, SAP, and others in 2001. The language has been under standardization process in W3C since early 2002. The expected deliverable from W3C is WSDL 2.0.

Even though WSDL does not have the final stamp of approval from any standard organization yet, it has already been broadly adopted as the de facto web services description language by many web services platforms. For example, the Web Services Interoperability Organization was founded to facilitate efficient adoption of web services. WSDL 1.1 is one of the key specifications endorsed by WS-I Basic Profile 1.0 and 1.1.

The Java Community Process has actually created a few WSDL-related Java Specification Requirements, including JSR110 Java API for WSDL and JSR101 JAX-RPC, which define how to map WSDL 1.1 definitions to Java implementations. All the existing web services platforms from key vendors support WSDL. To mention a few: Microsoft .Net, IBM Websphere, BEA Web Logic, SAP NetWeaver™, and many others.

This paper gives an update on the status of WSDL 2.0, and explains how it differs from WSDL 1.1. It is assumed that the reader is familiar with WSDL 1.1.

Status of W3C Work

Where Do We Stand?

W3C issued a "last-call" draft for WSDL 2.0 on August 3, 2004. In the W3C process, a last-call announcement signals that the working group in charge believes that it has satisfied the requisite technical requirements (e.g. requirements found in the charter or a separate requirements document) in the Working Draft, and they are looking for public comments to advance the draft to its next level of maturity.

In the last-call draft, the WSDL 2.0 specification is broken into three parts:

  • Part 1: Core language

  • Part 2: Predefined extensions (including MEPs, features, and operation styles)

  • Part 3: Bindings

The drafts for all the three parts are available for public review on the Web Services Description Working Group page.

What's Next?

W3C is working on the comments issued in the WSDL 2.0 last call review period. The original timeline for advancing WSDL to the more advanced maturity levels is below, although the working group is running late.

In conjunction with WSDL 2.0 specifications, the working group has also prepared a note, "Assigning Media Types to Binary Data in XML." It defines a few XML Schema constructs that can be used to designate media types of binary data with XML Schema. The media types note is on a separate schedule.

  • Candidate Recommendation: October 2004

  • Proposed Recommendation : January 2005 - March 2005

  • Recommendation: March 2005 - June 2005

  • Errata: October 2005 - January 2006

Inheriting from WSDL 1.1

WSDL 2.0 inherited most of the WSDL 1.1 architectural principles, including three layers of description, flexible authoring style or modularization capability, and extensibility.

Three Levels of Description

WSDL 2.0 still has the three layers of description from WSDL 1.1.

  • Abstract Interface: An abstract interface defines what a service is. More precisely, it defines the messages to be exchanged with a service - in other words, the kind of functionality it provides, the expected input, and what the service will provide given such input.

  • Protocol Binding: A binding defines how to access a service with a concrete protocol. For example, When SOAP messages are exchanged over HTTP, the binding defines which parts of the input message go into the SOAP header and which parts go into the SOAP body. Another binding can be defined for the same message to be exchanged as a MIME package over HTTP. The MIME binding defines which parts of the message will be sent as the root part of the MIME package, and which parts will be sent as attachments.

  • Service Endpoints: The endpoint describes where to access a service and depends largely on the binding in use; for example, the endpoint may be a URL in an HTTP scheme, or an email address in an SMTP scheme. The endpoint tells the exact address where a service can be activated.

When a service is defined, the abstract interface is usually designed at design time; binding definition is typically defined at configuration time; and endpoint information is available at run time. As more and more information is available for the service, the definition gets more concrete as shown in diagram 1.

Diagram 1

Flexible Authoring Styles

Corresponding to the three abstraction layers, WSDL descriptions are typically spread out in different documents. For example, the abstract interface may be defined by an industry vertical standard organization, while the bindings may be defined by various vendor consortia, and a particular vendor may define the concrete endpoints and an aggregate WSDL definition of a service instance that it provides.

This principle of separation is inherited by WSDL 2.0 with several enhancements. WSDL 1.1 allows flexible authoring styles via a single <wsdl:import> construct, which enables importing WSDL definitions defined in separate files with the same or different namespaces. WSDL2.0 works differently. Following the XML schema model, in particular its visibility rules for <xsd:import> and <xs:include>, WSDL 2.0 defines two constructs: <wsdl:import>, for WSDL definitions with a different namespace, and <wsdl:include>, for WSDL definitions with the same namespace.

Extensibility

WSDL allows extensions so that features that are not yet natively covered by WSDL language can still be described. WSDL 1.1 has an open content model for binding and endpoint constructs, but is fairly restrictive when it comes to extending abstract interface. WSDL 2.0 goes a few steps further:

  • WSDL 2.0 has an open content model.

    • All WSDL 2.0 constructs are extensible through both element and attributes (from other namespaces). In other words, one can add attributes and/or children elements to any WSDL elements.

    • Extension elements can be marked as mandatory by using the wsdl:required global attribute.

  • WSDL 2.0 provides a set of predefined extensions:

    • 8 Message Exchange Patterns (MEPs),

    • A set of operation styles that defines how messages should be designed for particular use, such as for RPC, and

    • 1 predefined feature for application data definition (see "Under Dispute" section below for use of features and properties).

    • A set of bindings for SOAP 1.1, SOAP 1.2, and HTTP.

      In addition to these predefined extensions, WSDL 2.0 allows users or third parties to define their own MEPs, operation styles, features and properties, and bindings to other protocols when they see particular needs for such extensions.

  • As in WSDL 1.1, WSDL 2.0 requires support for the XML schema, and it allows use of other message definition languages.

What's New in WSDL 2.0

WSDL 2.0 Component Model

The specification of WSDL 2.0 defines an abstract component model that allows WSDL 2.0 definitions to be independent of any particular serialization, including XML. For easy use with XML, WSDL 2.0 also defines an XML Infoset representation for each component, and provides mapping rules from the XML representation to the component.

The following diagram summarizes the XML representation of the WSDL 2.0 component model. One can easily identify the similarities with WSDL 1.1. An <interface> still contains <operations> which still have <input> and/or <output>. <binding> still provides mirroring constructs for <interface>. <service> still provides the concrete address.

Just at the first glance of diagram 2, however, careful eyes may notice a few differences from WSDL 1.1, such as the fact that the <message> construct is removed, <definitions> is renamed to <descriptions>, <portType> is renamed to <interface>, a new construct <include> is added, etc. In this section, I will list the major changes for interface, binding, and service, and in the next section, I will provide a complete example of how a complete WSDL 1.1 description can be rewritten in WSDL 2.0.

Diagram 2(Simplified) XML Representation of WSDL 2.0 Component Model

Namespace Changes

The target namespace of the WSDL 1.1 schema is http://schemas.xmlsoap.org/wsdl/; WSDL 2.0 has a W3C namespace http://www.w3.org/2004/08/wsdl. In addition, WSDL 2.0 defines a few new namespaces.

Namespace

URL

Description

WSDLi (WSDL-instance)

http://www.w3.org/2004/08/wsdl-simple-types

This namespace defines a global attribute "wsdlLocation," which can be used in WSDL 2.0 documents to indicate the location of the WSDL file.

WSDLs (WSDL-simple-types)

http://www.w3.org/2004/08/wsdl-simple-types

A few simple types defined by WSDL 2.0, such as string, token, anyURI, Boolean, etc. In order to avoid introducing a dependency on any particular serialization of the component model, WSDL 2.0 provides its own definition of those types, patterned after XML Schema: Datatypes, but independent of it. This allows processors to accept descriptions serialized using a mechanism that is not compatible with XML Schema: Datatypes, such as XML 1.1 [XML 1.1].

WRPC

http://www.w3.org/2004/08/wsdl/rpc

This is the URI for RPC style. It defines a set of rules for messages intended for use with RPC. It also defines a global attribute "signature," which can be used in schema to describe a RPC signature.

Message Exchange Patterns

WSDL 1.1 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.

WSDL 2.0 generalizes the “transmission primitives” concepts to Message Exchange Patterns (MEPs). An MEP defines the sequences and cardinality of abstract messages listed in a wsdl:operation. WSDL2.0 defines 8 MEPs, and allows more MEPs to be defined by third parties. Depending on how the first message in the MEP is initiated, the 8 WSDL 2.0 MEPs can be grouped into in-bound MEPs - in which case the service receives the first message in the exchange, and out-bound MEPs - in which case the service sends out the first message in the exchange.

WSDL 2.0 defines four in-bound MEPS:

  1. In-Only

    This patten consists of exactly one message received by a service from some other node. No fault may be generated.

  2. Robust In-Only

    This pattern can be considered as a variation of In-Only. It also consists of exactly one message received by a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model.

  3. In-Out

    This patten consists of exactly two messages: a message received by a service from some other node, followed by a message sent to the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model.

  4. In-Optional-Out

    This patten consists of one or two messages: a message received by a service from some other node, optionally followed by a message sent to the other node from the service. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model.

WSDL 2.0 also defines four out-bound MEPs that sort of mirror the in-bound MEPs with reserved direction:

  1. Out-Only

    This patten consists of exactly one message sent to some other node from a service. No fault may be generated.

  2. Robust Out-Only

    This pattern can be considered as a variation of Out-Only. It aslo consists of exactly one message sent to some other node from a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model.

  3. Out-In

    This patten consists of exactly two messages: a message sent to some other node from a service, followed by a message received by the service from the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model.

  4. Out-Optional-In

    This patten consists of one or two messages: a message sent to some other node from a service, optionally followed by a message received by the service from the other node. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model.

While the utility of in-bound MEPs is easy to see, there have been questions concerning the usefulness of out-bound MEPs, especially how a service can specify the endpoint information for the target node of the initial out-bound message. The lack of binding extensions for these MEPs in WSDL 2.0 makes them even harder to understand.

The list of MEPs defined in WSDL 2.0 is not meant to be exhaustive, and they are not meant to be supported by all web services. Out-bound MEPs are useful in the abstract level for fully specifying the functionality of a service, including its requirements for its potential customers, so application integrators can gain a better understanding of how multiple services may be used together. In the typical use cases for out-bound MEPs, binding and endpoint information may be provided by integration infrastructure in deployment and runtime.

Redesigned Message Definition Mechanism

In WSDL 1.1, a message definition consists of dispersed pieces, some in XML schema, and some in WSDL. As the result, the content of a message may have to be defined across multiple abstraction layers. For example, a complete description of an attachment consists of a dummy XML schema, an abstract WSDL message part, and a WSDL MIME binding. The under-specification nature of WSDL 1.1 about how to aggregate these pieces to get a complete description of the message and how to map the aggregated description to a run time message has created numerous interoperability problems.

WS-I Basic Profile and Attachment Profile have provided many clarifications with respect to the interoperability issues of WSDL 1.1, but some issues, when further complicated with binding definition, are hardly fixable. For example, the BP has to tolerate abstraction leakage by requiring messages with multiple parts to be only useable by RPC style SOAP bindings.

With WSDL 2.0, W3C has taken a more dramatic approach to fix the root of the problem.

  • wsdl11:message and wsdl11:part constructs have been completely removed. o All messages are defined directly using a type language. WSDL 2.0 requires support for XML Schema. Other type languages may be supported via its extension mechanism. o Message definitions such as global element declarations in XML schema are referenced by operation input/output constructs directly. o RPC style becomes a set of rules for abstract message definition. For easy mapping to a RPC signature, messages intended to be used with RPC must be designed based on these rules.

  • All messages are defined directly using a type language. WSDL 2.0 requires support for XML Schema.

  • Message definitions such as global element declarations in XML schema are referenced by operation input/output constructs directly.

  • RPC style becomes a set of rules for abstract message definition. For easy mapping to a RPC signature, messages intended to be used with RPC must be designed based on these rules.

As a result of the new design, in WSDL 2.0 the content of a message is completely defined by a type language. When XML schema is used as the type language, the entire content of a message is completely defined by a global element declaration.

When SOAP binding is concerned, the WSDL 2.0 notion is similar to the document-literal style in WSDL 1.1, but it is more powerful as it fully takes advantage of the expression power of XML schema for message definition and enables more clearly distinguishable abstraction layers. Now a complete compound data set, including a main XML document and related binary data can be defined in XML schema in the abstract interface level. The binary content of the compound data set may be transmitted as attachments, but that’s a binding decision which is clearly separated from the interface definition.

Changes to the Interface Definition

In WSDL 2.0, like WSDL 1.1, an interface still consists of a set of operations, and each operation still has input and output messages. However, the following changes have been incorporated:

  1. The abstract interface construct has been renamed from wsdl11:portType to wsdl20:interface.

  2. Redesigned message definition mechanism.

    In WSDL 1.1, a message definition consists of dispersed pieces - some in the XML schema, some in WSDL. The under-specification of how to aggregate these pieces to get a complete description of the message and how to map the aggregated description to a run time message has created a host of interoperability problems. WS-I Basic Profile has provided some clarification in trying to resolve the interoperability issues with WSDL 1.1, but some issues - when further complicated by binding definition - are hardly fixable. For example, the BP has to tolerate abstraction leakage by requiring messages with multiple parts to be only useable by RPC style SOAP bindings. W3C has taken a more dramatic approach to fix the root of the problem:

    • wsdl11:message and wsdl11:part constructs are completely removed.

    • All messages are defined directly using a type language, such as XML Schema.

    • Message definitions are referenced by operation input/output constructs directly.

    • RPC style becomes a set of rules for abstract message definition. For easy mapping to a RPC signature, messages intended for use with RPC must be designed based on these rules.

  3. Added interface inheritance support.

    • One interface can be derived from another interface.

  4. Faults are hoisted to be child of interface and made reusable by multiple operations.

    • Fault message reference is made consistent with input/output message reference. It has two constructs for fault reference: “infault” and “outfault.”

  5. More flexible and extensible MEP support.

  6. Operation style.

    • May define certain rules that message definitions associated with an operation must conform to.

    • WSDL 2.0 contains a predefined style for RPC that specifies the rules of how messages should be defined when they are intended for use with RPC-style operations.

  7. Safeness.

    • Indicating whether the operation is asserted to be safe (as defined in Section 3.5 of Web Architecture, http://www.w3.org/TR/2003/WD-webarch-20031209/) for users of the described service to invoke.

    • If this property is false, then no assertion has been made about the safety of the operation, thus the operation may or may not be safe.

    • However, an operation should be marked safe if it meets the criteria for a safe interaction.

  8. Features and properties can be defined for an interface, an operation, a message, or a fault (see the "Under Dispute" section).

Simple Binding Definition

WSDL 2.0 has made the binding constructs more reusable:

  • A binding is not necessarily tied to one particular interface.

    • When a binding extension is not operation-specific, it can be associated with multiple interfaces.

  • More reusable attributes/defaults are hoisted to wsdl:binding level.

  • Fault is raised to be a child of wsdl:binding.

WSDL 2.0 provides several normative binding extensions:

  • SOAP binding

    WSDL 2.0 SOAP binding provides full support for binding an abstract WSDL interface to SOAP over HTTP. It supports both SOAP 1.1 and SOAP 1.2.

    SOAP 1.2 binding is pretty much a redesign from WSDL 1.1.

    • It has removed the confusing choice of Literal vs. Encoded and RPC vs. Document. Everything is document/literal in WSDL 2.0.

      Please note that RPC community is not left alone. WSDL2.0 defines a set of rules for designing messages suitable for RPC calls. In addition, it provides a facility in the interface level to indicate that RPC-friendly message is in use by an operation.

    • Please note that RPC community is not left alone. WSDL2.0 defines a set of rules for designing messages suitable for RPC calls. In addition, it provides a facility in the interface level to indicate that RPC-friendly message is in use by an operation.

    Support for SOAP 1.1 is still under construction as this paper is written.

  • HTTP binding

    WSDL 2.0 HTTP binding supports any HTTP version and all HTTP methods. (Note that WSDL 1.1 only support HTTP 1.1 GET and POST.)

WSDL 2.0 binding extensions for both SOAP and HTTP are designed with the objective of minimizing what needs to be explicitly declared for common cases. This minimization is achieved by defining a set of default rules which apply for all operations of the bound interface, unless specifically overidden on a per operation basis. For example, if the bound interface defines three operations A, B, and C, and the binding only provides specific info about A, and does not refer B and C at all, then all the default rules apply for operations B and C.

The WSDL 1.1 MIME binding is deprecated. WSDL 2.0 supports attachments based on XOP and MTOM (see attachments section).

A Service Can Implement Only One Interface

One major change for the service construct is that in WSDL 2.0 a wsdl20:service must be and can only be associated with one wsdl2.0:interface, whereas in WSDL 1.1 a wsdl11:service can contain endpoints of any wsdl11:portType. In other words, while in WSDL 1.1 the service construct is a pure syntactic wrapper of potentially un-related endpoints, the WSDL 2.0 service construct groups a set of endpoints at which a particular deployed implementation of a certain wsdl:interface is provided.

In addition, wsdl11:port is renamed to wsdl12:endpoint. The address of an endpoint now is an attribute, instead of a child element.

Web Services Attachments Support

For many web services applications, it is a common requirement to handle binary data associated with a primary XML document. For example, a car insurance claim application may involve processing the pictures of the accident scene and the damaged car in addition to the main insurance claim document, which alone is in the XML format.

How to deal with binary data in the web services context has been a long-standing challenge to the web services community. Several solutions have been proposed. The issue has at least two aspects: 1) how to transfer a SOAP envelope with binary data; 2) how to describe binary data in a web service interface. Explaining the differences between these solutions requires another paper. Here we just focus on how WSDL 1.1 and WSDL 2.0 differ in supporting attachments descriptions.

WSDL 1.1 support for attachments description is based on SOAP with Attachment (SwA). SwA specifies rules for transferring SOAP envelope along with binary attachments in a MIME package. WSDL 1.1 defines a binding extension for MIME. Using the MIME binding extension, one can specify which message part should be sent as a MIME part and what its media type is.

WSDL 2.0 support for attachment description is based on MTOM, which is a SOAP 1.2-based solution provided by the W3C. MTOM relies on the infoset of a message to decide if optimization is necessary for transferring the message across the wire. If optimization is needed, the message will be sent as a MIME package, if not, a SOAP envelope. WSDL 2.0 relies on XML Schema to describe the infoset of a message. It endorses a few new schema types for providing media type information in message definitions.

For more information, see the article, "The Evolution of Web Services Attachments Technologies."

Under Dispute: WSDL 2.0 Feature and Properties

Two constructs, wsdl20:feature and wsdl20:property were introduced into WSDL 2.0 without full consensus of the W3C WSD working group. Minority objections are under file against their inclusion in WSDL 2.0 and must be resolved before WSDL2.0 can be made a recommendation from W3C.

The terminology of feature and property are originated from SOAP 1.2. WSDL 2.0 introduced the corresponding constructs to provide support for SOAP1.2, but generalized the concept to be appliable not only to all bindings but also abstract interfaces. As a result of the generalization, a WSDL feature and related properties now become predefined extensions which describe an abstract piece of functionality of a web services, such as reliability, security, correlation and routing. The two constructs can appear anywhere in the interface level, the binding level and under an endpoint description, but unfortunately the working group is not able to provide full specification on how different features and properties can be composed to provided an integrated view of the functionality a web service provide.

While all participants of the WSD working group agree that support for feature and property description is important, there are disagreements about how to approach such support. On the one hand, some members, especially those who have co-authored the WS-Policy specification believe that SOAP 1.2 feature and property and WS-Policy have a lot in common and convergence is desireable. Policies/Features/Properties and their description in WSDL deserve a separate specification which is composeable with WSDL. Providing a half baked solution in WSDL 2.0 will only make WSDL unnecessarily complicated. On the other hand, some other companies argue that WS-Policy is not in any standard process, and WSDL 2.0 should not imply dependance on a non-standard specification and should provide feature and properties support now.

W3C is working on an intitiative to standardize a mechanism for describing Web services constraints and capabilities. WS-Policy is provided as an potential input for such mechanism. Progress of related activities in W3C may play an important role in settling down the dust around this issue.

Rewriting a WSDL 1.1 Example in WSDL 2.0

The following examples, the first in WSDL 1.1 and second in WSDL 2.0, show the WSDL definition of a same web service providing stock quotes. The service supports a single operation called GetLastTradePrice, which is deployed using the SOAP 1.1 protocol over HTTP. The request takes a ticker symbol of type string, and returns the price as a float.

Example 1 is copied from WSD L1.1 specification, section 1.2. The parts that have been changed in WSDL 2.0 are marked in italic bold.

Example 1 - WSDL 1.1 Definition for the Stockquote Service

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

To rewrite the above example in WSDL 2.0, a few changes are necessary:

  • Use the wsdl2.0 and soap1.2 namespace

  • The message schema remains the same, but how they are used in an operation is different now. Note that the stockQuote interface now directly references the global element definitions

  • Binding to SOAP 1.2 is simplified via using defaults.

  • It uses more attribute extension to the WSDL 2.0 binding construct.

  • Service now is tied to a single interface.

  • Address is now an attribute of an endpoint.

Example 2 is the WSDL 2.0 version of the same services described in example 1. Changed parts are marked bold.

Example 2 - Rewrite Example 1 in WSDL 2.0

<?xml version="1.0"?>
<description  targetNamespace="http://example.com/stockquote.wsdl"
          xmlns:tns="http://example.com/stockquote.wsdl"
          xmlns:xsd1="http://example.com/stockquote.xsd"

          xmlns:wsoap=" http://www.w3.org/2004/08/wsdl/soap12"

          xmlns=" http://www.w3.org/2004/08/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>
				

    <interface name="StockQuote">
<operation name="GetLastTradePrice"

        pattern="http://www.w3.org/2004/03/wsdl/in-out">
           <input messageLable = “In

               element="xsd1:TradePriceRequest"/>
           <output messageLable = “Out

               element="xsd1:TradePrice"/>
        </operation>

    </interface>
				
    <binding name="StockQuoteSoapBinding" 
interface="tns:StockQuote"
type =”http://www.w3.org/2004/08/wsdl/soap12” 
        wsoap:protocol=“http://www.w3.org/2003/05/soap/bindings/HTTP”

            wsoap:mepDefault="http://www.w3.org/2003/05/soap/mep/request-response">
        <operation ref="tns:GetLastTradePrice">
wsoap:action="http://example.com/GetLastTradePrice"/>
        </operation>
    </binding>
				
    <service name="StockQuoteService" interface=”tns:StockQuote”>
        <documentation>My first service</documentation>
        <endpoint name="StockQuotePort" 
                 binding="tns:StockQuoteBinding"
address ="http://example.com/stockquote"/>
        </endpoint>
    </service>
				
</description>
				
				

References

Table of Contents



Related Content:



Content Options

Copyright © 2005 SAP AG, Inc. All Rights Reserved. SAP, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product, service names, trademarks and registered trademarks mentioned are the trademarks of their respective owners.

SAP Developer Network