- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Thu, 12 May 2005 02:50:25 +0200
- To: "Arthur Ryman" <ryman@ca.ibm.com>
- Cc: <www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D6416505EECD@uspale20.pal.sap.corp>
Obviously, I know the meaning Arthur. ;-). I just want to show that how your example makes the use of request-response like an outbound MEP. I am just asking the question whether other folks in the wg anticipated the utility of the marker, or empty messages, by passing the actual semantics for an MEP. For example, the example begs the question why can't we use an Outbound MEP for the same purpose instead of #none? There is a SOAP response MEP that we could use in the binding that we could refer to. Why this formulation instead? Further, if we want to illustrate the use of #none, then probably burying the concept in this large example is not a good idea. It appears part of the use case for Service References for the first time. It should be tackled separately. --umit _____ From: Arthur Ryman [mailto:ryman@ca.ibm.com] Sent: Wednesday, May 11, 2005 2:37 PM To: Yalcinalp, Umit Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org Subject: Re: What is the purpose of #none? Umit, #none means the message is empty. Arthur Ryman, Rational Desktop Tools Development phone: +1-905-413-3077, TL 969-3077 assistant: +1-905-413-2411, TL 969-2411 fax: +1-905-413-4920, TL 969-4920 mobile: +1-416-939-5063, text: 4169395063@fido.ca intranet: http://labweb.torolab.ibm.com/DRY6/ "Yalcinalp, Umit" <umit.yalcinalp@sap.com> Sent by: www-ws-desc-request@w3.org 05/10/2005 09:45 PM To <www-ws-desc@w3.org> cc Subject What is the purpose of #none? While I was reading the primer on service references, I came across an interesting example in our primer. Apart from the fact that primer talks about both Service and Endpoint references in Section 7.9 and the reader is baffled about the differences here (endpoint references are not introduced anywhere before) which is not the purpose of this email, example 7.14 is particularly interesting: <interface name="reservationDetailsInterface"> <operation name="retrieve" pattern=" <http://www.w3.org/2005/05/wsdl/in-out> http://www.w3.org/2005/05/wsdl/in-out"> <input messageLabel="In" element="#none" /> <output messageLabel="Out" element="wdetails:reservationDetails" /> </operation> ... Check out the binding: <binding name="reservationDetailsSOAPBinding" interface="tns:reservationDetailsInterface" type=" <http://www.w3.org/2005/05/wsdl/soap> http://www.w3.org/2005/05/wsdl/soap" wsoap:protocol=" <http://www.w3.org/2003/05/soap/bindings/HTTP> http://www.w3.org/2003/05/soap/bindings/HTTP"> <operation ref="tns:retrieve" wsoap:mep=" <http://www.w3.org/2003/05/soap/mep/request-response> http://www.w3.org/2003/05/soap/mep/request-response" /> <operation ref="tns:update" wsoap:mep=" <http://www.w3.org/2003/05/soap/mep/request-response> http://www.w3.org/2003/05/soap/mep/request-response" /> </binding> The intent here appears to be that a "retrieve" action will cause reservation details to be sent to the caller when an empty message is received. According to our spec, this is perfectly legitimate, because we allow empty messages, hence empty SOAP bodies to act as a trigger for the response message. This pattern here seems like a poor man's SOAP response MEP, which is modeled on top of SOAP request-response MEP by passing the request message using WSDL request-response MEP. Aren't we confused yet ? ;-) I am wondering why we wanted to allow #none. It seems the whole purpose is to paypass a designed MEP to masquarade as another. Can someone refresh my memory why we wanted to allow element content to be empty again? (As a side comment, can anyone truly believe that this kind of a WSDL definition will be usable by a service provider without a mandatory SOAP Action header if many pseudo-output MEPs similar to the one quoted above were to be assigned to the same endpoint? ) Do we really want to promote this usecase in the Primer? End-Of-Rant, --umit
Received on Thursday, 12 May 2005 00:52:42 UTC