- From: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
- Date: Fri, 24 Jan 2003 11:33:05 -0800
- 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 UTC