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 envelope of underlyingresponse


 

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]