RE: [business-transaction] Issue - ex-10 - acknowledgements for LRT

Title: Message

I'd 
like to propose a solution based on the earlier messages quoted 
below:

 

Add 
the new parameter values to *_STATUS proposed below.

Add a 
new standard qualifier "expected time till state change" that can be sent on any 
message to give an indication of how long the sender thinks it might be before 
it does something interesting.

 

The 
message and the qualifier are informational - they do not cause state change, 
they do not forbid the sender from changing state much earlier, they do not 
commit the sender to changing state at the time stated, they do not change the 
persistence/recovery requirements implied by BTP.

 

Peter

 

ps 
despite proposing this as a way to tidy things up, I'm not sure I like the 
qualifier very much.

  

  
-----Original Message-----
From: Furniss, Peter 
  
Sent: 23 March 2004 17:58
To: 
  
Subject: RE: 
  [business-transaction] Issue - ex-10 - acknowledgements for 
  LRT

  
I 
  think the additional messages would be:

  
 

  
INFERIOR_STATUS/prepare-received

  
INFERIOR_STATUS/confirm-received

  
INFEIROR_STATUS/cancel-received

  
 

  
and 
  

  
SUPERIOR_STATUS/confirmed-received

  
SUPERIOR_STATUS/cancelled-received

  
 

  
the 
  superior_status messages would only be used when the inferior had made an 
  autonomous decision, and the superior didn't know the proper decision 
  yet.

  
 

  
None 
  of these would cause a state change. There is no need for a 
  "response-requested" version of these - normally the receiver will be in the 
  state corresponding to having just sent the message. In the few cases where it 
  is possible for the receiver to have moved on, the receiver could resend the 
  new message (e.g. after sending CANCEL, receive 
  INFERIOR_STATUS/prepare-received : could resent CANCEL).

  
 

  
Sending the expected time (X) till decision is made would seem to be an 
  item for a qualifier.

  
 

  
Peter

  
    

    
-----Original Message-----
From: Furniss, Peter 
    
Sent: 23 March 2004 15:55
To: 
    
Subject: 
    [business-transaction] Issue - ex-10 - acknowledgements for 
    LRT

    
This issue has been added to the btpex issue list. The issues list is 
    posted as a Technical Committee document to the OASIS 
    BTP TC pages on a regular basis. The current edition, as a TC document, 
    is the most recent document with the title in the "Issues" folder of 
    the BTP 
    TC document list - the next posting will include this issue. The list 
    editor's working copy, which will normally include an issue when it is 
    announced, is available at this 
    constant URL. 
    Issue - ex-10 - acknowledgements for LRTStatus: 
    open
Date added: 23 Mar 2004
Submitter: Alastair Green 
    []
Date submitted: 23 March 
    2004
Description: Ability to support long-running transactions is 
    a design goal of BTP. In practice BTP does not support a useful feature that 
    prevents idle network chatter during long (and expected) pauses in a 
    conversation. This arises from product implementation experience. 
    
Any protocol message that will (in theory, subject to implementation 
    level administrative or deployment overrides) be resent indefinitely until a 
    state-moving message is received “in reply”, should be capable of receiving 
    a receipt-acknowledgement, whose reception can be interpreted to mean: I 
    would prefer you not to resend the message I have just received. I will 
    reply in my own good time, and I estimate that this time will be no less 
    than X seconds away. 
    
Absent such acks, it is very difficult to obtain the appropriate balance 
    between fault-tolerance and good network citizenship. Customers don’t like 
    excess network traffic. 
    
The recoverable nature of all retriable conversations ensures that the 
    use of a receipt-ack will not terminate the conversation prematurely or 
    wrong-headedly. 
    
The SUPERIOR_STATUS/prepared-received message might be used as a model or 
    basis for the syntax of such a message.
Changes: 23 Mar 2004 - new 
    issue

    

    
To comment on this issue, please follow-up to this announcement on the 
     list (replying to this message 
    should automatically send your message to that list), or ensure the subject 
    line as you send it starts "Issue - ex-10 - [anything]" or is a reply 
    to such a message. 
    
To add a new issue, please email to the issues list maintainer 
    (Peter Furniss). 
    
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/business-transaction/members/leave_workgroup.php.