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] Summary of WS-Reliability 1.01* issues discussed over past week


Title: RE: [wsrm] Summary of WS-Reliability 1.01* issues discussed over past week

Solution proposed for (2a) below:

(removing the sentence  "However,  an RMP  is  not required  to distinguish  WSDL
operation types.")

We can remove this sentence if:

(1) we tighten the RMP definition (terminology):
Keep defining RMP as a "SOAP Node" (as defined in SOAP 1.2) as we did, but
remove the unnecessary and possibly misinterpreted "or a subset or superset thereof".
The RMP is the entity that has all functions needed to transmit reliable SOAP messages,
from the Submit/Deliver/Respond/Notify operations layer down to the wire.
(I think Doug made a similar point)

(2) we replace this sentence with a statement independent from WSDL, and getting
at the core of why the sentence above needed be removed:
"When invoking Deliver operation on a payload, an RMP is required to know whether
a related Respond invocation is expected or not."
(I would not mind narrowing further this statement to make it conditional to the binding
of Deliver/Respond to an underlying request-response MEP)

Jacques

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Sunday, June 13, 2004 3:13 PM
To: wsrm@lists.oasis-open.org
Subject: [wsrm] Summary of WS-Reliability 1.01* issues discussed over
past week


The following is intended to help get everyone caught up.

Most  of  this  derives  from  the abstract  model  in  our  specification,
resulting in  a number  of contradictions  between it and  the rest  of the
document, underscoring  a few over-general restrictions  or indicating some
under-specified  concerns.   While  some  of  the  issues  below  could  be
considered editorial, the bulk are at least minor technical concerns.

When  reading  the  following,  it   is  very  important  to  remember  the
distinction between  the capabilities the  WS-Reliability protocol provides
to  the producer  and consumer  and how  that protocol  maps to  use  of an
underlying  protocol.    Producer  /  consumer   interactions  occur  using
WS-Reliability  and  WS-Reliability  uses  SOAP messaging  (our  underlying
protocol).  The RMP  always has complete control over the  bits on the wire
though  the producer  and  consumer may  provide  the bulk  of the  message
content in a "pass through" fashion.

The example  "solutions" are provided  primarily to make the  issues clear.
While some  of these approaches may resolve  the issues, we must  come to a
common understanding of the problems before working on solving them.

1) The  existing descriptions of  the callback  and poll  RM-Reply patterns
    assume   the   underlying   protocol  supports   request-response   SOAP
    interactions but do  not explain what goes into  the underlying response
    of  the  separate  message  exchanges.   In  detail,  the  response  and
    synchronous  RM-Reply  patterns may  be  used  only  with an  underlying
    protocol that supports request-response (a less general restriction than
    currently specified).   For the callback and  asynchronous poll RM-Reply
    patterns,  we are using  only one-way  messaging; though  the underlying
    protocol  might support  request-response, we  should rely  on  the SOAP
    binding to describe  or profile how the underlying  response is used (or
    ignored).  For  example, we might  clarify that these  RM-Reply patterns
    involve two  separate one-way  SOAP message exchanges  (callback), three
    separate  one-way message  exchanges  (asynchronous poll)  or a  one-way
    followed  by a  request-response  exchange (synchronous  poll).  Such  a
    clarification might also address part of (2) below -- though at the cost
    of some generality.

1a) The  "non-essential assumption"  that the underlying  protocol supports
     request-response SOAP  interactions, stated  in section 2.1,  should be
     removed.  This is no longer a general assumption but something specific
     to two of our four RM-Reply pattern options.

1b)  The  HTTP Binding  should  be an  instance  of  the general  semantics
     described in  the main body of  the specification and  not extend those
     semantics.   The current  section  provides examples  of semantics  not
     described elsewhere.  After resolving the areas left under-specified or
     over-generalized in the rest of the document, we must recheck section 6
     for conflicts with these semantics.  In addition, any transfer protocol
     responses that may  be unclear because we are  using a request-response
     underlying  protocol  in  a  one-way  fashion should  be  described  by
     reference to the appropriate SOAP over HTTP binding.

2) Section  5.2 is completely  about the  producer /  consumer interactions
    though some of its text has been applied to the RMP use of an underlying
    protocol.  The matrix  in section 5.2 states that  all RM-Reply patterns
    may be used with  consumer-generated payload(s) or application responses
    on  the receiving  RMP side.   However, the  callback and  poll RM-Reply
    patterns  provide multiple opportunities  to return  payload information
    (as they are  currently described, see (1) above)  and the specification
    does  not  describe  which  option  is  recommended.   Our  new  Respond
    operation  (possibly restricted  to specific  RM-Reply  pattern choices)
    must be mapped  to the underlying protocol at least as  far as timing is
    concerned.  We may also decide to further restrict when the consumer may
    invoke the Respond operation.

2a)  The sentence  "However,  an RMP  is  not requried  to disinguish  WSDL
     operation types."  [please note  new spelling errors] was introduced in
     a recent edit to section 5.2,  enshrining an assumption a few of the TC
     had previously made.  This  assumption contradicts the complete control
     an RMP  has over the  bits on  the wire.  The  consumer may or  may not
     provide payload  information (the  consumer interface may  be described
     using either a request-response or  a one-way operation type).  Even if
     the receiving RMP  is only passing the information  through, it must be
     aware of when to wait for the consumer to invoke the Respond operation.
     This sentence should be removed.

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.

2c) The matrix in section 5.2 also was the first to introduce the idea that
     the consumer  could provide information intended for  the producer.  We
     needed to extend the abstract model to introduce this earlier and avoid
     a contradiction between the matrix and the model.  I believe this issue
     has become editorial as we discuss the details of the edits necessary.

2d)  When using  the Response  RM-Reply pattern,  the  immediate underlying
     response  may be  lost  and the  sending  RMP may  query  using a  Poll
     request.   Should the response  to such  a "spontaneous"  Poll indicate
     which  referenced messages  included consumer  payloads in  the earlier
     response?  The sending RMP might  "just know" a consumer payload may be
     available from  information the consumer  provides (WSDL, say)  or some
     other means; an  indication of a consumer payload  in the Poll response
     informs the sending  RMP directly.  The sending RMP  can already decide
     when a resend might be  necessary and any indications the receiving RMP
     provides would be a new extension to the WS-Reliability protocol.  Such
     an  extension would,  primarily, reduce  the size  of the  known subset
     requiring resends  since any a  priori information would  indicate only
     that a consumer payload had been possible.

3) The  description of  duplicate  elimination in  section  3.2.2 does  not
    describe  the  content  of  either  the  immediate  underlying  protocol
    response nor an RM-Reply that may be sent later (in the callback or poll
    RM-Reply cases).   In particular, whether or not  consumer payloads from
    the response sent the first time  (in the case when the earlier response
    had  been  lost)   may  be  returned  during  this   iteration  is  left
    unspecified.  As Sunil has  stated, some have implementation issues with
    caching  payloads  in  the  receiving   RMP  though  this  is  the  most
    appropriate way to handle the  duplicate message.  We might thus avoid a
    new requirement but concentrate on ensuring caching is allowed.

3a) Sunil mentioned  in a private email that no RM-Reply  pattern at all is
     used unless an acknowledgement was  requested.  I have not searched but
     am  pretty sure  we have  not described  RM fault  semantics, duplicate
     elimination nor consumer payloads in this situation.  For example, will
     the  callback be  invoked or  the  poll include  any information  about
     successfully delivered messages when AckRequested did not appear in the
     original message?  I suspect we moved the ReplyPattern element out from
     under the AckRequested  to allow more generality here  but the existing
     text implies an RM-Reply is always publicized.

4) The  RM  Fault processing  model  described  in  section 4.5  previously
    attempted to cover responses to duplicate messages though the reader was
    not directed here from 3.2.2 "Duplicate Elimination".  I believe we have
    agreed  not to  lump  faulting  and responding  to  a duplicate  message
    together  in the  document and  have addressed  the editorial  issues in
    section 4.5.

4a)  Sunil has  outlined a  few  issues with  including a  SOAP fault  when
     returning an  RM fault.  If  I remember correctly, the  original reason
     for this addition was avoiding an  empty SOAP Body when the sending RMP
     expected a consumer payload.  If  we accept all of the restrictions and
     clarifications mentioned above (in (1) especially), the problem will be
     limited  to  use of  the  Response  RM-Reply pattern  (request-response
     underlying  protocol utilization)  with a  consumer  response expected.
     The SOAP  Fault would cause  the underlying protocol response  to match
     the  signature expected  in that  case but  may  cause interoperability
     problems  in other  cases.   Sunil  would like  to  avoid the  inherent
     redundancy of  a message containing both  SOAP and RM  faults.  He also
     points out that "send a SOAP fault" is not specific enough.

5) The   specification   is   generally   vague  about   the   meaning   of
    "application-level"  and talks  about WSDL  primarily as  describing the
    producer /  consumer interaction without making  this distinction clear.
    In some  cases, WSDL operation or  MEP types are applied  at all levels.
    As a  relatively editorial matter, we must  clarify distinctions between
    exchanges  controlled by  the RMP  processing ("underlying  protocol" or
    SOAP  message exchanges)  and how  the  RM-Reply patterns  map to  those
    exchanges  and the  producer /  consumer interface  (sometimes described
    using consumer-provided WSDL).  In effect, the producer and consumer sit
    on top  of an RMP that  is (abstractly) implemented  using an underlying
    SOAP   processor.   That   SOAP  processor   provides  the   one-way  or
    request-response message deliveries used for the RM-Reply patterns.  The
    RMPs  effectively  provide  another,  higher quality  of  service,  WSDL
    binding that the producer and  consumer use to interact.  We probably do
    not need to include the SOAP processor explicitly in our model but we do
    need  to  be clear  throughout  or  document  what level  is  discussed.
    Primarily, section  5.2 will be the  main place in which  the producer /
    consumer interface  come to the fore.  And,  no, this is not  as large a
    change as it seems.


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.



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