Issue 5432: asynchronous responses (ots-structs-ftf) Source: Red Hat (Dr. Mark Little, mlittle(at)redhat.com) Nature: Uncategorized Issue Severity: Summary: Currently the core of the Additional Structuring Mechanisms for the OTS (aka Activity Service) assumes synchronous responses from participants (Actions) at the instigation of the coordinator messages (generated by the SignalSet). As we have found in several recent studies and other work on extended transactions (e.g., the OASIS BTP) there are good reasons why participants may want to asynchronously send "responses" to messages the coordinator hasn't yet generated. For example, in a two-phase protocol, a participant may be able to spontaneously prepare and send the coordinator the relevant Outcome. In the current spec. this isn't possible directly. Obviously there are tricks that could be played with another-level-of-indirection (e.g., enlist a "cacheing" participant with the coordinator that the real Action enlists with and this receives [and stores] any spontaneous responses). However, even this doesn't really address the entire problem since the response the Action sent (the Outcome) is made with respect to a presumed specific Signal that the coordinator sent. So, what if the coordinator doesn't send that Signal? Having this as part of the core will help us to continue to support a wide range of coordination/extended transaction protocols. Resolution: Revised Text: Actions taken: June 20, 2002: closed issue, duplicate Discussion: End of Annotations:===== From: "Mark Little" To: "XOTS FTF" Cc: Subject: asynchronous responses Date: Mon, 17 Jun 2002 09:52:31 +0100 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Currently the core of the Additional Structuring Mechanisms for the OTS (aka Activity Service) assumes synchronous responses from participants (Actions) at the instigation of the coordinator messages (generated by the SignalSet). As we have found in several recent studies and other work on extended transactions (e.g., the OASIS BTP) there are good reasons why participants may want to asynchronously send "responses" to messages the coordinator hasn't yet generated. For example, in a two-phase protocol, a participant may be able to spontaneously prepare and send the coordinator the relevant Outcome. In the current spec. this isn't possible directly. Obviously there are tricks that could be played with another-level-of-indirection (e.g., enlist a "cacheing" participant with the coordinator that the real Action enlists with and this receives [and stores] any spontaneous responses). However, even this doesn't really address the entire problem since the response the Action sent (the Outcome) is made with respect to a presumed specific Signal that the coordinator sent. So, what if the coordinator doesn't send that Signal? Having this as part of the core will help us to continue to support a wide range of coordination/extended transaction protocols. Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 260625