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


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
>>
>

-- 
----------------------------------------------------
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]