[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
Tom Rutt wrote: > 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. I for one doesn't prefer it as I don't think we should talk about binding stuff in out document. Makes it much complex to read. Also, while it is doable, I wouldn't prefer to design that way as it freezes my runtime options. For ex., in the case you mentioned to bind a output part to wsrm:response. the User is forced to use Response RM-Reply pattern. Again, it doesn't mean that there aren't use cases that require such enforcement. Having said that, I'm not vehemently opposed to it if the final wordings are simple and crisp. What I'm opposed it to change the only No cell to Yes. > > 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. > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]