Issue 4556: Clarification of set_response behaviour (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Clarification Severity: Summary: The Activity service specification states, in the description of the SignalSet::set_response method: "The SignalSet returns a boolean to indicate whether or not the Action that returned the response should be informed of any further signals from this signal set; if the value is true then the Action continues to receive Signals." This suggests that, if the SignalSet is used to broadcast signals (rather than simply produce completion signals), an Action that indicated it required no further signals during the first broadcast within a particular Activity may well expect to receive signals if the SignalSet was requested to broadcast a second time within the same activity or indeed was subsequently asked to produce completion signals. In a subordinate node, there is no knowledge from one process_signal(Signal) to the next as to which particular broadcast the signal comes from. Therefore, the subordinate has no way of knowing whether a registered Action that indicated no-further-signals on a previous set_response should receive signals on subsequent process_signal calls from the superior. Resolution: see above Revised Text: if the value is true then the Action continues to receive Signals for this SignalSet, otherwise the Action is disassociated from the SignalSet, i.e., this is equivalent to it being removed. Actions taken: September 5, 2001: received issue May 2, 2003: closed issue Discussion: Resolution: It was always the intention that the Action would be removed from the SignalSet. Therefore, update the text to clarify this End of Annotations:===== Importance: Normal Subject: Clarification of set_response behaviour To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Wed, 5 Sep 2001 15:39:58 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.8 |June 18, 2001) at 05/09/2001 15:59:24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: lJ=!!KMB!!('`d9ZBIe9 The Activity service specification states, in the description of the SignalSet::set_response method: "The SignalSet returns a boolean to indicate whether or not the Action that returned the response should be informed of any further signals from this signal set; if the value is true then the Action continues to receive Signals." This suggests that, if the SignalSet is used to broadcast signals (rather than simply produce completion signals), an Action that indicated it required no further signals during the first broadcast within a particular Activity may well expect to receive signals if the SignalSet was requested to broadcast a second time within the same activity or indeed was subsequently asked to produce completion signals. In a subordinate node, there is no knowledge from one process_signal(Signal) to the next as to which particular broadcast the signal comes from. Therefore, the subordinate has no way of knowing whether a registered Action that indicated no-further-signals on a previous set_response should receive signals on subsequent process_signal calls from the superior. I think the easiest way to define interoperable behaviour is to clarify the set_response description to indicate that a return value of false indicates that the Action wishes to receive no further signals from that SignalSet for the duration of the Activity. This would have a similar effect to performing a remove_action. An alternative would be to clarify that the Action *may* not receive any further signals from the SignalSet but must be able to handle any signals that it does get. An Action that wrappered, for example, an OTS Resource would need to be able to consume commit or rollback signals after it had returned a VoteReadOnly outcome. A 3rd option would be to send architected correlation information with each signal to indicate which broadcast it came from. This could be as a parameter on the process_signal method (which a 'business' Action would have to igore), as a new field in the Signal (which an application should ignore). If ActivityContext were flowed on process_signal (currently it is not as of issue 4346) then the correlation id could be added to the ActivityIdentity structure. Any variation of this 3rd option would require a new issue that I suspect we wouldn't be able to cover in this FTF so I'm reluctant to push this one. Ian Robinson, WebSphere Transactions Architecture IBM Hursley Lab Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com From: "Mark Little" To: , "Ian Robinson" References: Subject: Re: Clarification of set_response behaviour Date: Wed, 5 Sep 2001 18:07:31 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Filter-Version: 3.4 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: AYK!!(V6!!(K9e9@+P!! > The Activity service specification states, in the description of > the SignalSet::set_response method: > "The SignalSet returns a boolean to indicate whether or not the > Action that returned the response should be informed of any further > signals from this signal set; if the value is true then the Action > continues to receive Signals." > > This suggests that, if the SignalSet is used to broadcast signals > (rather than simply produce completion signals), an Action that > indicated it required no further signals during the first broadcast > within a particular Activity may well expect to receive signals if > the SignalSet was requested to broadcast a second time within the > same activity or indeed was subsequently asked to produce completion > signals. > > In a subordinate node, there is no knowledge from one > process_signal(Signal) to the next as to which particular broadcast > the signal comes from. Therefore, the subordinate has no way of > knowing whether a registered Action that indicated > no-further-signals > on a previous set_response should receive signals on subsequent > process_signal calls from the superior. > > I think the easiest way to define interoperable behaviour is to > clarify the set_response description to indicate that a return value > of false indicates that the Action wishes to receive no further > signals from that SignalSet for the duration of the Activity. This > would have a similar effect to performing a remove_action. remove_action from that SignalSet was always what I had in mind. Mark. ---------------------------------------------- Dr. Mark Little Transactions Architect, HP Arjuna Labs Email: mark@arjuna.com | mark_little@hp.com Phone: +44 191 2064538 Fax : +44 191 2064203