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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
