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: Prelim wed f2f minutes

the prelim wed f2f minutes are attached

Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Wednesday




8:30 Coffee


6         Review of Homework Assignments and Continued Issue Resolution

6.1      Updated Messaging model

Iwasa presented his updated messaging model,  http://www.oasis-open.org/archives/wsrm/200310/msg00093.html .


The group participated in edits to the diagrams, to use terms RM Request and RM Reply..


Agreed that requirements 3.2 section should be used as basis for what is explained in section 2. 


Agreed to have three pictures in section 2, using arrows for Underlying transport request and Underlying transport response.

Add text from 3.2. of requirements to section 2 of spec.


Leave figures for section 5 as amended by Iwasa email..


6.2      Polling Mechanism homework – Rel94


Sunil presented his homework on the Polling model and schema.


FINAL REL 94 Proposal.


 The group agreed to accept the proposal with one change:

        - Move the "request for poll" into a new Header rather than

          overloading "AckRequested".


 Here is a final proposal for REL-94 with the required changes.




  So the initial msg. with the intent for Poll ReplyPattern Binding will


  ReplyPattern set to Poll and it will have AckRequested sub-element













 The poll request will have a new Header called PollRequest.

 An example is as follows:



         <GroupId value="a.b.c.com/xyz/001" >

            <SequenceNumberRange From="1" To="10" />


        <GroupId value="a.b.c.com/xyz/002" />





   * Intent for Poll pattern is done using ReplyPattern set to Poll and

     existence of the AckRequested sub-element in Request Header.

   * Actual Poll request will be sent in a  separate Header called


   * PollRequest Header could be the one of  following:

        o If it has one or more GroupId sub-elements, then it is a

          indication that  sender wants to Poll previously sent message(s).

        o There can be one or more GroupId sub-elements.

             + Values can be same or different.

        o There can be zero or more SequenceNumberRange sub-elements under a


        o If there is no SequenceNumberRange sub-element, Response should

          include all received messages in that Group.

   * For Poll Request, it should only have MessageHeader and PollRequest

     Header. It shouldn't have the Request Header. So essentially one can't

     Ack a Poll request. No useful use case to support it.

   * For simplicity sake, we should mandate that all the messages in a group

     should use the same ReplyPattern.

   * The Response for a Poll request will have a MessageHeader and the

     ReplyPattern sub-element will be set to Poll.

   * The group agreed to generalize the rule  for all patterns.

     [AI: Add this as a new issue and close it as Resolved.]



 So possible requests are (assume ReplyPattern is Poll for all the below):

 1)  <PollRequest>

        <GroupId value="a.b.c.com/xyz/001" >

            <SequenceNumberRange From="1" To="12" />




 2) <PollRequest>

        <GroupId value="a.b.c.com/xyz/001" >

            <SequenceNumberRange From="1" To="5" />

            <SequenceNumberRange From="7" To="7" />

             <SequenceNumberRange From="10" To="12" />




 3) <PollRequest>

        <GroupId value="a.b.c.com/xyz/001" >

            <SequenceNumberRange From="1" To="5" />


        <GroupId value="a.b.c.com/xyz/001" >

            <SequenceNumberRange From="6" To="12" />




 While all the 3 cases are valid, (1) will be the most efficient and should

be recommended.


 And the receiver is REQUIRED to send back requested Acks for message(s)

that were

 received already.


 Note that the Response will include all received messages in the range

mentioned in

 the  Request, not just previously un-acked messages.



     <RefToGroupId value="a.b.c.com/xyz/001">

         <RefToSequenceNumberRange From="1" To="5" />

         <RefToSequenceNumberRange From="7" To="7" />

        <RefToSequenceNumberRange From="10" To="12 />


   <RefToGroupId value="a.b.c.com/xyz/002">

         <RefToSequenceNumberRange From="1" To="8" />




 It was also decided to use the same syntax for bataching acks in

 all the patterns. [REL 75]

 [Open Issue: Whether we need to restrict the semantics for Response

              Reply pattern has to be decided.]





  1.This request will be sent to the same endpoint as the original

message(s) are sent..

  2.Poll request for a message sent to another endpoint MAY result in

InvalidGroupId fault.

  3.Since it is defined as a Header, it could be defined in the SOAP Binding

part if it is desired.


 Possible failure faultcodes are:


  1.InvalidGroupId:  Even if one of the GroupIds are wrong or invalid, this

fault will be sent.

  2.InvalidSequenceNumber: Even if one of the SequenceNumbers is wrong or


     this fault will be generated and sent.



 Essentially, all or none approach wrt to Faults. We should be able to share

the above

 Status values with Fault  Codes. Note both  are QNAME types and hence



 Piggybacking of a Poll request could either be disallowed or should be

tackled along

 with the general piggybacking problem.




This proposal was agreed by the meeting.


7         France Telecom Executive Briefing

Jean-Jacques Damlamian: (Senior Vice President of Corporate Technology and Innovation at France Telecom, in charge of the Group R&D activities, the Directorate of Innovation and the Directorate of the Intellectual Property and Licensing) gave a short presentation on the importance of the group finishing its work in a pragmatic and timely manner.


He addressed concerns about competing efforts, but told us to focus on producing an easily implementable standard in minimal time.

7.1      Interop demo status


Bob Freund gave a presentation of the Demo Subgroup status


The presentation was uploaded to give url


December 9 early evening is the demo time at xml show.




New troublemaker distributed (Fujitsu)                     Oct 6, 2003
Financial services app distributed (Oracle/Fujitsu)     Oct 22, 2003
Distribution of binary rmp for test                             Nov 3, 2003
First draft presentation and handouts                       Nov 18, 2003
Pre-test at Fujitsu San Jose CA                              Nov 18-20, 2003
Final-test at Oracle, Morristown NJ                          Dec 8-9, 2003
Demonstration at XML 2003                                    Dec 9, 2003


Sunil asked which spec version will be used.


Bob F , now using .52 reference plus errata.  


If we get stable, can go for the newest version. 


Bof F: this is a Public demo, no egg on face allowed.  The subgroup will consider the output of the meeting.


8         Continue resolution of WS-Reliability Specification Issues

8.1      Timing parameters

Bob F suggested the following:

  • The first message in a non-singleton group with  (i.e., a message with the statusAttribute of the sequenceNo element =start) must have the ack requested element present.  It can have an empty body, or may have data in the body
  • The ExpiryTime of the first message serves to idendify the expiry time for the group.
  • All messages in the group must have an expiryTime which is less than or equal to the ExpiryTime for the group.


With the above there is no need for the removeAfter attribute.


Bob F stated this ensures the delivery of the establishment of a group


Jacques asked, is it required that an ordered group requires the messageOrder element to be present?


Need to add clarification in spec that:

  • All messages in an ordered group MUST have the MessageOrder element present in the RequestHeader.
  • All messages in an un-ordered group MUST NOT have the MessageOrder element present in the RequestHeader.


A message in a non-ordered group can either contain the duplicateElimination or not.


All messages in an ordered group MUST have the duplicateElimination element present.


The Expiry time for each message in a group MUST be less than or equal to the GroupExpiryTime (currently called RemoveAfter).


Bob’s proposal trades off bandwidth and an an extra check that the removeAfter has not changed, with the requirement that the first message in a non singleton group always be acknowledged.


Sunil pointed out that the status attribute is defaulted to continue. 


Iwasa stated that one interpretation is the status attribute must be present if the message is not of status continue.


This would imply that the first message in the group MUST have the status=start.


The group does not exist unless a message is received with status=start.


Sunil stated that putting ackRequested on the first message does not guarantee that the first message will ever be received.


Jacques stated that the removeAfter attribute could always be required for orderedGroups.


Sunil suggested that if we always required the removeAfter attribute, and have the effective removeAfter for the group always be set at the receiver to the value of the removeAfter attribute of the highest sequenceNO receiver.


Iwasa scenario: 

  • first message has removeAfter of Oct29. 
  • Later message has removeAfter of Dec1. 
  • The later message reaches the receiver on Oct30. 


Iwasa stated the group will be removed before the later message arrives.


The latter will be taken as establishing a new group. 


The Iwasa scenario is a problem if the removeAfter is allowed to change.


Tom suggested alternative:  The sender sends each message in group with ack requested and removeAfter present, until it gets is first ack message.  After that it does not need to send removeAfter.  In all cased removeAfter value is always the same for every message in the group (if present).


Jacques states this forces use of of guaranteed delivery even if they do not want it.  He expressed opposition to this proposal.



  • RemoveAfter MUST be present for non-singleton groups
  • RemoveAfter MUST always have the same value for all messages in non-singleton group.
  • If receiver detects different value in sequence, it MUST return a specified RM fault (InvalidRemoveAfter)
  • RemoveAfter MUST not be present for a singleton group.  If received, the sender MUST return the (invalidRemoveAfter) rm fault.


This has the advantage that any single message in the group will serve to establish the group.


An ordered sequence will not deliver messages if the first message in the sequence is not received.  Nothing can fix this, it is a property of guaranteed order.


Change the name of removeAfter attribute to GroupExpiryTime Attribute.


Enforce rule that expiry time for every message in group MUST be less than or equal to GroupExpiryTime.


Bob F asked if we could have two alternatives for groups:

  • Finite Group Expiry time
  • Specific maximum IdleTime for group.


This would result in a choice element called “RemoveAfter” with two possible arms in the choice:

  • GroupExpiryTime
  • GroupMaxIdleTime. (seconds).


This will not work for attributes since they cannot be complex types.


Sunil asked why we could not have both allowed, with the first one firing taking precedence?


If we made them both allowed, then non-presence of GroupExpiryTime would indicate arbitray length group


Question:  if GroupExpiryTime not present, does maxIdleTime have to be present.  Answer is yes


This would simplify the protocol.


New proposal:

·        Two optional attributes, GroupExpiryTime and GroupMaxIdleDuration,

·        Neither allowed to be present in singleton groups

·        For non singleton groups, at least one must be present

·        Non presense of GroupExpiryTime indicates arbitrary length group.

·        The presence and values of both attributes must be identical for every message in the group.

·        If both are present, the first criteria that fires terminates the group.

·        Presence of status=end always takes precedence to terminate the group.

·        If groupExpiryTime is present, its value must be greater than or equal to the message expiry time for each message in the group.

·        When a group is terminated for any reason above, all messages and group state information are removed from receiving rmp persistence.

·        Processing order constraints must be clarified.


The first message received in group is the one whose parameters are used.  If values are are not same a fault could be sent.


Doug B suggested we simplify the protocol by not requiring constraint checking at the recipient side.


Sunil stated we could senf fault on message, but continue the group processing.


Timestamp:  must the resend have the same timestamp value as the original.



What does receiver do if message in group has different GroupExpiry or GroupMax Idle -  InvalidGroupTerminationCritera


What does receiver do if a message in group has expiry time later than the group expiry Time – InvalidExpiryTime


Assume that protocol has validity restrictions on the three parameters, expiryTime, GroupExpiryTime, and GroupMaxIdleDuration.


Strongest possible enforcement – receiver must check the validity of timing parameters on every message received, and if it detects an invalid paramer, it must send a fault and MUST not process message further


Jacques – this is a tradeoff of verbosity with complexity.  


Weaker alternative:  If receiver checks and detects invalid parameter condition, is must send fault and not process message further.  However, checking is not required.


Straw poll:

Strongest alternative: 7

Weaker alternative: 2


Jeff Moved to accept strongest alternative, Dock seconded.


Doug B opposed 1

In Favor 9

2 obstain.


Motion passes.


Sunil stated that with this proposal, we would not need knowledge of additional config parametes for global limits and defaults.


We need to go thru each of the issues in the block to see if the proposal closes them.


Marc: we need an exception if the value of the groupExpiryTime is greater than what the receiver is willing to accept.


Timing issue checks:


8.2      REL-38: Timestamp


Bob F – the protocol does not use timestamp anywhere.  Thus there is no need for this parameter,  If the application needs a timestamp, it should be put in the payload.


We used to have timeToLive which was added to the timestamp.


Leave issue open, try to resolve on Thurs meeting.


Jacques – the decision to keep it or not may be impacted on whether the next version needs it or not.


6.1      REL-45: Handling message delivery failure cases


Leave open as low priority issue


6.2      REL-50: Semantics of message ExpiryTime

Jacques stated this is not yet resolved, and that the new timing parameter proposal above, needs to be further clarified.


Potential refinement of Processing order constraints:

  • Receiver RMP must check for message expiration
  • if expired , receiver sends a fault with refToGroupID present, and does not process message further
  • If not expired,
    • If duplicateElimination or messageOrder is present in message, persist state information for group, and then return ack
    • Receiver RMP executes duplicate ID check if duplicateElimination element is present.
      • If duplicate detected discard duplicate message
      • If duplicate not detected
        • If ordered delivery not in use, make available to receiver app
        • If ordered delivery is in use, retain for proper order of making available to user.
  • For a singleton message with duplicate elimination present, when expiry time is reached, all information about that singleton group is removed from receiver rmp state
  • For non singleton groups,
    • when the group terminates due to groupExpiryTime criteria, all  information about that group is removed from receiver rmp persistence, including the stored messages in the orderedDelivery case
    • When the group terminates due to status=end condition, stop adding new message sequence numbers larger than the sequeneNumber of the end message into the receiver rmp persistence for that group (and return fault), but keep all existing persistence information for that terminated group
    • When the group terminates due to GroupMaxIdleDuration condition, stop adding new messages with sequence numbers larger than the highest sequenceNumber received into the receiver rmp persistence for that group (and return fault), but keep all existing persistence information for that terminated group
    • any information persisted in receiver RMP for a message in the group is removed from persistent store when the message expires.
    • When last message in terminated group expires, all state information about that group is removed from receiver rmp persistent store.


Tom: Alternative way to state the last major bullet:

  • For non singleton group termination (for any of the three reasons) stops a group from accepting messages with higher sequence numbers than the largest sequene number received before termination of that group.  For all non accepted messages a “TerminatedGroup” fault is returned. However, the persistence for a particular message already accepted into that group at the receiver rmp is saved until that message is expired.


Sunil alternative:

  • when group expires, receiver rmp eliminate all state information, which means ordered delivery and duplicate elimination stops working for that group.


Bob alternative:


  • For a non-singleton group, when a group terminates, a largest sequenceNo received mark is placed in the group state information, such that when the message with that sequence number is delivered to the user and all the messages received for that group expire, the group state is removed.


Jacques:  If we change the scope of the duplicateID check to be tied to the groupExpiry rather than the message expiry, it simplifies the processing.


Bob:  If we go back to requiring a group expiry time it simplifies.  If you get a status=End before the group expiry time, the sequence number of that end message terminates the ordered Delivery processing when that message is delivered to the application.


Bob F – it would be very good to have the same behaviour for each way to terminate a group.


Doug: if sender does not tell receiver to stop with explicit status=end, how does receiver let the sender know that the group is terminated.


Sunil it is simplified if we only start an ordered group after the start message is received.


Other issues left to resolve on this topic.

  REL-52: New rules for persistence

  REL-57: Ordering and Missing Message Behavior

  REL-97: GroupID lifetime (RemoveAfter)



7         Assess impact of Request/Response on Basic WS-R Schema elements

Jacques sent the following summary on 9/30:

General recommendation on what WS-R should cover regarding Guaranteed delivery (GD)

of messages involved in a WSDL request-response :


1- Only the following GD cases should be supported by this version of WS-R:

- GD of request + GD of response (Variant 1)

- GD of request + no GD of response (Variant 2)

The following case should be excluded (not covered by this specification) (see Option 3.1.1):

- no GD of request + GD of response (Variant 3)


2- The recommendation for GD of request-response, is that its use of Ack and resend procedures

will differ from one-way ops in the following way:

- request-response is treated as a single transaction (will be entirely replayed, if either leg failed)

- in case of Variant 1, in case the response is not acknowledged, the request-response should not be replayed.

Instead, the Ack should be resent (see Proposal 1.2) (depending on firewall restrictions on either side,

either using RMP-level polling to get the Ack, or a resending mechanism for Acks.)(to resolve!)


3- Given the impact of supporting GD request-response on SOAP implementations (seee Appendix A),

recommendation is that it should belong to a higher conformance profile for WS-R.

i.e. some implementations that cover only the reliability of one-way operations

should still be considered as conforming at some level to WS-R.


More detail for variant 1:

Proposal 1:

We address here the case where the response message (1.b) failed. The solution is to resend the response over an HTTP response, itself part of a new HTTP transaction that involves resending the request. In other words, we consider that the entire HTTP transaction (1) has failed, and redo it. A successful recovery will look like this:


(1.a) Aà requestà B

(1.b)      response + Ack1 ß B     need to distinguish this from a normal piggyback of new rmRequest

(2.a) Aà requestà B                   cannot avoid invoking operation twice without dupElim

(2.b) A ß response of 1.a + Ack1 ß B     will send previous response

(3.a) A à Ack2 à B


We could call this “transactional reliability”, as it involves replaying the entire transaction. The transaction (2) is carried over an HTTP request –response. Note that this is a pattern different from the usual resending pattern as currently specified in WS-R.


Sub-Issue 1.1 to proposal 1:  Note that the repeated request in (2.a) will not be passed to the application in case duplicate elimination is required, but otherwise will be. In case it is, which response should be sent back (response to 1.a or to 2.a), as App(B) will have answered twice?


In the above case the receiver rmp must know that reliable requestResponse is in use (to be able to resend buffered response for 2.b above).  (another alternative would be for the second response to be sent if dup elim is not in use)


When receiver rmp receives request and gets response from app, how does it distinguish this from another oneway rm Request?


The most difficult scenario for variant 1 is:


(1.a) Aà requestà B

(1.b)  A ß response + ack ß B

 (2.a) A à Ack (lost)                          (like a callback)

 (3.b) A ß (Nack-Ack error)  ß B      (like a poll)

(4.a) A à Ack à B


3b could be accomplished with the existing poll message, but perhaps we could also have a specific header for the nack-ack error.


At lease one rmp needs to be aware that erliable request-response wsdl operation is being supported.


Variant 2 is simpler, and introduces no new problems.


Jacques expressed an opinion that to make the above scenarios work, we would have to extend the existing schema.  (add new header elements, or change existing header elements). 


How does rmp know whether variant 1 or variant 2 is in use?


Could have an additional element in existing request header (or a new header for this purpose) to indicate that reliable request/reply is desired.


A new set of headers for the additional info would be preferable for extending the existing protocol.


Possibly put the request response wsdl operation type in an informative annex.



Meeting resessed at 5:15 PM.

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