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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Title: Message

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: business-transaction@lists.oasis-open.org
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 LRT

Status: open
Date added: 23 Mar 2004
Submitter: Alastair Green [alastair.green@choreology.com]
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 business-transaction@lists.oasis-open.org 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.