[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] WSDL One-way operation type and Data in Soap envelopeof underlyingresponse
Sunil: Since this provides a way to get the functioanality that Doug was requesting in 2b) we should add a clarification to the section 5.2 to explaing this. In general, we could add a small sub section on how to use wsdl descriptions including our header elements bound to soap header in soap binding. However, it might be worth discussing a "conceptual" transformation from a user level wsdl description to a different wsdl description which adds our header elements as message parts bound to the soap header. Tom Rutt Sunil Kunisetty wrote: > Tom Rutt wrote: > >> If a web service was going to clarify its use of WS-Reliability, it >> might also want to have a second input part on the operation for the >> wsdl:request element. This could be bound to the soap header in the >> soap http binding. > > This case and the case you mentioned in the previous mail (about > adding a output part and bind it > to a wsrm:response soap header) are _perfectly valid_ if an User > desires to do so and neither our spec. > prohibits this case nor it can do it as it is an User's choice. > > We did ponder on this many times before and decided that the spec. > won't mandate it and at the > same time doesn't explicitly prohibit it. If an User wants to do it, > he should be able to do it. > > The case you mentioned in your previous mail, where in, an output > message with one part bound > to a SOAP Header to use the Response RM Reply pattern is also valid > but then again it becomes a > request-response operation w.r.t. WSDL because of the presence of > the output message definition > and hence was able to use the Response pattern. > > I don't know how any one can use the Response RM_Reply pattern for a > one-way WSDL operation > which is what the NO cell represents in the table in section 5.2. I > think this is valid and I don't > think we should change it to Yes. > > >> This detailed use of WSDL shoulld not be disalllowed, and it can get >> thru the BP 1.0 restrictions >> >> Tom Rutt >> >> Tom Rutt wrote: >> >>> Let me clarify: >>> >>> Assume a WSDL description for a port type has an operation >>> definition with an input message with one part, and an output >>> message which has just just one part specified as a wsrm:response >>> element. If the soap /http post binding binds the input message >>> part to the soap body, and the output message part to the soap >>> header, this is no longer a WSDL >>> one way operation. This explicit WSDL defintion would get thru the >>> criterea of the BP 1.0. >>> >>> Tom Rutt >>> >>> >>> >>> Tom Rutt wrote: >>> >>>> I just realized why we have this seeming conendrum. >>>> >>>> If we were really expressing what we are doing with the response >>>> reply pattern, we would >>>> have an extra return message part for our response element, and we >>>> would soap bind it to the soap header. >>>> >>>> Thus, strictly speaking, the way we are using soap for the response >>>> reply pattern, would not be wsdl >>>> one way, even the consumer' view of the wsdl is no return part for >>>> the message. >>>> >>>> JUST THE FACT that the rmp is acting above the soap processor means >>>> we should have special wsdl >>>> for our interactions, which would include the wsrm:response element >>>> as a return message part of the operation, >>>> bound to a soap header in the return. >>>> >>>> Tom Rutt >>>> >>>> Sunil Kunisetty wrote: >>>> >>>>> >>>>> >>>>> Tom Rutt wrote: >>>>> >>>>>> From the minutes of 6/14 meeting, My comments new to this email >>>>>> start >>>>>> with <ter> tag >>>>>> " >>>>>> 2b) The one-way consumer interface and Response RM-Reply >>>>>> pattern is the >>>>>> most direct combination to reliably deliver one-way >>>>>> messages from a >>>>>> producer "hidden" behind a firewall. The matrix in section >>>>>> 5.2 should >>>>>> not disallow this combination. While synchronous >>>>>> polling at least >>>>>> works, it always requires an additional round trip. >>>>>> >>>>>> <ter> one of Sunil's objections to the above proposal is based >>>>>> on the >>>>>> BP 1.0 restriction. >>>>>> >>>>>> I Quote from BP 1.0a of WS-I >>>>>> " >>>>>> >>>>>> 5.6.10 One-Way Operations >>>>>> >>>>>> There are differing interpretations of how HTTP is to be used when >>>>>> performing one-way operations. >>>>>> >>>>>> R2714 For one-way operations, an INSTANCE MUST NOT return a HTTP >>>>>> response that contains a SOAP envelope. Specifically, the HTTP >>>>>> response >>>>>> entity-body must be empty. >>>>>> >>>>>> R2750 A CONSUMER MUST ignore a SOAP response carried in a >>>>>> response from >>>>>> a one-way operation. >>>>>> >>>>>> R2727 For one-way operations, a CONSUMER MUST NOT interpret a >>>>>> successful >>>>>> HTTP response status code (i.e., 2xx) to mean the message is >>>>>> valid or >>>>>> that the receiver would process it. >>>>>> >>>>>> One-way operations do not produce SOAP responses. Therefore, the >>>>>> Profile >>>>>> prohibits sending a SOAP envelope in response to a one-way >>>>>> operation. >>>>>> This means that transmission of one-way operations can not result in >>>>>> processing level responses or errors. For example, a "500 Internal >>>>>> Server Error" HTTP response that includes a SOAP message >>>>>> containing a >>>>>> SOAP Fault element can not be returned. >>>>>> >>>>>> The HTTP response to a one-way operation indicates the success or >>>>>> failure of the transmission of the message. Based on the >>>>>> semantics of >>>>>> the different response status codes supported by the HTTP >>>>>> protocol, the >>>>>> Profile specifies that "200" and "202" are the preferred status >>>>>> codes >>>>>> that the sender should expect, signifying that the one-way >>>>>> message was >>>>>> received. A successful transmission does not indicate that the SOAP >>>>>> processing layer and the application logic has had a chance to >>>>>> validate >>>>>> the message or have committed to processing it. >>>>>> >>>>>> Despite the fact that the HTTP 1.1 assigns different meanings to >>>>>> response status codes "200" and "202", in the context of the Profile >>>>>> they should be considered equivalent by the initiator of the >>>>>> request. >>>>>> The Profile accepts both status codes because some SOAP >>>>>> implementations >>>>>> have little control over the HTTP protocol implementation and cannot >>>>>> control which of these response status codes is sent. >>>>>> >>>>>> " >>>>>> >>>>>> <ter> the requirements seem tied to HTTP transport binding for SOAP, >>>>>> rather than to SOAP in general. However the first two sentences of >>>>>> explanatory text is written regarding Soap in general. >>>>>> >>>>>> " >>>>>> >>>>> The BP requirement may be tied to Http, but as I mentioned >>>>> umpteen no. of times >>>>> on the call and as_ always you keep interrupting me without >>>>> listening completely,_ I was >>>>> saying that the abstract part of the WSDL one-way operation >>>>> prohibits a response. >>>>> >>>>> Infact, let me re-quote a snippet from what you quoted: >>>>> " *One-way operations do not produce SOAP responses. >>>>> *Therefore, the Profile >>>>> prohibits sending a SOAP envelope in response to a one-way >>>>> operation. >>>>> This means that transmission of one-way operations can not >>>>> result in >>>>> processing level responses or errors." >>>>> >>>>> >>>>> Let me also cut-and-paste the snippet from the WSDL 1.1 spec. >>>>> regarding the >>>>> one-way operation: >>>>> /2.4.1 One-way Operation/ >>>>> >>>>> /The grammar for a one-way operation is:/ >>>>> >>>>> /<wsdl:definitions .... > <wsdl:portType .... > */ >>>>> / <wsdl:operation name="nmtoken">/ >>>>> / <wsdl:input name="nmtoken"? message="qname"/>/ >>>>> / </wsdl:operation>/ >>>>> / </wsdl:portType >/ >>>>> /</wsdl:definitions>/ >>>>> >>>>> /The input element specifies the abstract message format for >>>>> the one-way operation./ >>>>> >>>>> >>>>> Note that there is no output or fault definition for a one-way >>>>> message. >>>>> >>>>> What BP did is re-inforcing what is said in WSDL 1.1 spec. and >>>>> clarified what to do in Http case >>>>> as the latter is request-response transport. >>>>> >>>>> What I'm still not clear on Doug's issue 2(b) is how to employ a >>>>> Response RM-Reply pattern >>>>> for a one-way WSDL operation. >>>>> >>>>> I fully understand and agree that usage of word MEP in section >>>>> 5.2 is misleading and corrected. >>>>> >>>>> I also agree that one-way consumer interface MAY be mapped to a >>>>> R-R binding/operation and >>>>> thus CAN be used with a Response RM_Reply pattern. >>>>> >>>>> But, section 5.2 is NOT about Consumer interfaces, rather WSDL >>>>> 1.1 operation types. >>>>> With that context, I don't see anything wrong with that table. >>>>> >>>>> I don't see how the combination of one-way consumer interface >>>>> and Response RM-Reply pattern >>>>> is the most used one. To me this is the least used one as most >>>>> likely a one-way consumer interface >>>>> will be mapped to a one-way WSDL operation and hence a one-way >>>>> binding. I'd assume Callback >>>>> pattern to be the most commonly used pattern in that scenario. >>>>> >>>>> >>>>> -Sunil >>>>> >>>> >>> >> > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]