W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

169 Syntax for webMethod - property or attribute?

From: David Orchard <dorchard@bea.com>
Date: Tue, 6 Jul 2004 16:26:30 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08BE6567@ussjex01.amer.bea.com>
To: <www-ws-desc@w3.org>

I wanted to use the Atom WSDL 2.0 example (at http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20) to motivate the allowing of wsdl:method on the interface operation.   I rewrite my proposed Atom Interface operation using the proposed solution:

<interface name="atomHTTPPOST">
    <operation name="PostEntry" method="POST">
      <input element="atomtypes:entry"/>
      <output element="atomtypes:entry">
        <property uri="http://www.w3.org/@@@@/@@/features/AD/data">
          <constraint>atomtypes:Location</constraint>
        </property>
      </output>
    </operation>
</interface>
<interface name="atomHTTPEdit">
    <operation name="DeleteEntry" method="DELETE">
    </operation>
    <operation name="GetEntry" method="GET">
      <output element="atomtypes:entry"/>
    </operation>
    <operation name="PutEntry" method="PUT">
      <input element="atomtypes:entry"/>
      <output element="atomtypes:entry"/>
    </operation>
</interface>
<interface name="atomHTTPFeed"
    <operation name="GetFeed" method="GET">
      <output element="atomtypes:feed">
        <property uri="http://www.w3.org/@@@@/@@/features/AD/data">
          <constraint>atomtypes:Location</constraint>
        </property>
      </output>
    </operation>
  </interface>

then the binding can be simplied.  Instead of:

  <binding name="atomHTTPPOSTURI" interface="atomapi:atomHTTPPost">
    <operation ref="PostEntry" http:method="POST"/>
  </binding>
  <binding name="atomHTTPEntryURI" interface="atomapi:atomHTTPEdit">
    <operation ref="DeleteEntry" http:method="DELETE"/>
    <operation ref="GetEntry" http:method="GET"/>
    <operation ref="PutEntry" http:method="PUT"/>
  </binding>
  <binding name="atomHTTPFeedURI" interface="atomapi:atomHTTPFeed">
    <operation ref="GetFeed" http:method="GET"/>
  </binding>

The following can be done:

  <binding name="atomHTTPPOSTURI" interface="atomapi:atomHTTPPOST"/>
  <binding name="atomHTTPEntryURI" interface="atomapi:atomHTTPEdit"/>
  <binding name="atomHTTPFeedURI" interface="atomapi:atomHTTPFeed"/>

This compares favourably with the sweetness of the SOAP binding:

  <binding name="atomSOAP" interface="atomapi:atomSOAP" wsoap:protocol="http://schemas.xmlsoap.org/soap/http">
    <!-- Use of the AD feature/module for ws-security is very very dubious, but included here for completeness given the WSDL 1.1 for Atom -->
    <wsoap:module uri="http://www.w3.org/@@@@/@@/modules/AD"/>
    <operation ref="POST" wsoap:action="http://purl.org/atom/ns/http/POST"/>
    <operation ref="DELETE" wsoap:action="http://purl.org/atom/ns/http/DELETE"/>
    <operation ref="GET" wsoap:action="http://purl.org/atom/ns/http/GET"/>
    <operation ref="PUT" wsoap:action="http://purl.org/atom/ns/http/PUT"/>
  </binding>

One is immediately struck by the difference between the SOAP and HTTP bindings.  In SOAP, the operation is optionally defined in the message and then the action is set in the binding.  There are perhaps many operations at a given address, so we'd like to optimize for multiple operations in a given binding.

In the HTTP as transfer protocol scenario, there are as many interface operations, but probably more interfaces, bindings, and endpoints.  The use of HTTP will then tend to have many separate bindings rather than be clustered in a given binding.  This is to enable a given endpoint to say which subset of the HTTP operations is supports, which can only be accomplished by more bindings as each binding maps to an interface.  

To net it: use of HTTP will result in more interfaces, more bindings, and more endpoints when compared to SOAP over HTTP.  This proposal significantly helps reduce the complexity of the bindings, though it does nothing to optimize the number of interfaces, bindings and endpoints.  

Cheers,
Dave
Received on Tuesday, 6 July 2004 19:26:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT