W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2003

RE: Support for application protocols

From: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
Date: Fri, 24 Jan 2003 11:33:05 -0800
Message-ID: <2E33960095B58E40A4D3345AB9F65EC109E4BCC6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
To: "Mark Baker" <distobj@acm.org>
Cc: <www-ws-desc@w3.org>

Mark, thanks for the additional explanation. FYI, the WG hasn't really
begun to work on bindings with any significant earnest; when we do, your
post below will undoubtedly be quite helpful. 

--Jeff

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Friday, January 24, 2003 10:46 AM
> To: www-ws-desc@w3.org
> Subject: Support for application protocols
> 
> 
> Greetings,
> 
> I just checked the new bindings draft and noticed that no progress has
> yet been made on section 3, which is unfortunate from my POV, because
> I consider it deficient in a very important way that would ideally be
> dealt with up front, as it would certainly impact other parts of the
> spec.  FWIW, this is why I raised issue 64[1].
> 
> The subject of this message is "Support for application protocols",
> which is what section 3 currently doesn't have; it doesn't distinguish
> between application protocols and transport protocols, thereby
treating
> application protocols *as* transport protocols, which they are not.
> 
> To remedy this problem, I propose the following.
> 
> First, the renaming of the "transport" attribute on the "binding"
> element to "protocol", to reflect that more than just transport
> protocols will be supported.
> 
> Second, an additional parameter on the "binding" element called "type"
> which can have two possible values (for now); "transport" or
> "application".  Alternately, URIs for those values would be fine.  The
> default value would be "transport", since this reflects common
practice
> with the use of application protocols by Web services.
> 
> There are (at least) two ways of doing the core of the change I'm
> presenting here.  One way would be to remove the need for an operation
> element in the case where "type" had value "application", which would
> permit the methods/"verbs" of the application protocol to be exposed
as
> the operation.  The other way would be to define the methods as
> operations in the binding.  Potato, potatoe.  Either way's ok with me,
> as is any other solution that recognizes that "application protocol
> method = WSDL operation"
> 
> And of course, should "type" have the value of "transport", even if
the
> protocol being used is an application protocol, then it's back to the
> same use of WSDL that you're all familiar with.
> 
> BTW, this has the added benefit of providing you a solution for
> supporting the SOAP 1.2 "Web Method" feature, as the "Web method" in
use
> would be exposed as a WSDL operation.
> 
> Thanks!
> 
>  [1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-
> issues.html#x64
> 
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
Received on Friday, 24 January 2003 14:33:41 GMT

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