OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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


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]