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




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

 No. We should not. We have discussed this  many many times before and we concluded
 that we should not have a  special  wsdl for our interactions.

 While the User's WSDL MAY/MUST have the WS-RM Features and Properties,
 I don't see a reason for having a special WSDL or interjecting the User's WSDL
 with our interactions.

 For once, we cannot describe all the interactions statically as some of them are
 dynamic and we should provide the User with the flexibility to switch or use
 multiple Reply Patterns.

 Secondly, things like "retry" cannot be described in WSDL easily.

 I for one doesn't believe in interjecting User's WSDL with RM operations or interactions
 as I believe they are QoS that have to be transparently supported.

 Do we include/describe  tcp linger or keep-alive interactions in WSDL?

 The problem with Response Reply pattern compared to other Reply patterns is that,
 while other Reply pattern interactions are done without interfering with the main
 producer-consumer interaction, Response pattern interjects (piggybacks on the
 Consumer response) with that interaction and hence this conundrum.

 For that we need to go by some restrictions such as a one-way operation (note, I'm
 not saying One-way consumer interface) cannot use a Response reply pattern.

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