Issue 4348: Interoperability of childLifetime (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: When a child Activity completes, its parent's ActivityCoordinator must drive the childComplete/childLifetime SignalSet to produce the childComplete signal for distribution to any Actions with an interest in this signal. This Signal contains an ActivityInformation structure that indicates the GlobalId and final CompletionStatus of the completing Activity. (A separate issues proposes that the final Outcome of the child Activity also be included in the ActivityInformation). The specification leaves it to an Activity service implementation to determine how a parent Activity is notified of its child's completion and how the ActivityInformation is obtained by the parent's childComplete/childLifetime SignalSet. A practical approach is for the child ActivityCoordinator to call its parent ActivityCoordinator's process_signal_set("org.omg.childComplete") method. If the child Activity is active on the thread when childCompletion processing occurs, then the SignalSet in the parent can determine the child's GlobalId and CompletionStatus via the Current interface. (Note: the completionStatus of the child may be modified by the completion SignalSet during completion processing; it is the *final* completionStatus that should be reported during childComplete processing). An interoperation issue arises if a child Activity is rooted on a node that is downstream from the parent's root. In this case, childComplete signals need to originate from the parent's root ActivityCoordinator/SignalSet. Mechanically, the completing child should inform its (local) parent ActivityCoordinator by whichever implementation-specific means it uses and then the local (subordinate) parent ActivityCoordinator has to push this back up to its ultimate superior for distribution throughout the tree. The means by which this happens need to be defined to ensure interoperation across different vendors' implementations. One approach would be for the subordinate ActivityCoordinator to drive its superior's process_signal_set() method, ensuring that the ActivityContext is propagated on this flow (in order that the superior can obtain the child's GlobalId). A similar consideration holds for childBegin. There are issues with this approach; one is that any child Activity, begun at any node downstream to its parent, will always have its context imported (as a subordinate) to all upstream nodes on which its parent is active. A different solution to the problem might be to introduce a new method on the ActivityCoordinator interface that can be used during child-completion to pass the ActivityInformation object. This would mean that no service context would need to flowed and all the information required to deliver the childComplete signal would be available to the parent. This could be something like: void ActivityCoordinator::set_child_completed(in ActivityInformation ai) It would still be implementation-specific how that ActivityInformation got added to the signal, but that is not an interoperation issue. Resolution: see above Revised Text: If the parent of a sub-Activity is not a root Activity (ie it is a subordinate) then the distribution of the ChildLifetime signals is delegated upstream to the superior ActivityCoordinator. Actions taken: May 2, 2003: closed issue Discussion: Resolution: This issue is mostly closed by 4303. Only a minor clarification remains. The description of the ChildLifetime SignalSet in section 2.2.1 needs the following additional statement. End of Annotations:===== From: ian_robinson@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta09_cs0 [9.180.35.6]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5FGneB195526; Fri, 15 Jun 2001 17:49:40 +0100 Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.005C684D ; Fri, 15 Jun 2001 17:49:20 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org cc: issues@omg.org Message-ID: <80256A6C.005C669E.00@d06mta10.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 17:48:37 +0100 Subject: New Issue: Interoperability of childLifetime Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: AK6e9VXMe90YW!!RfS!! When a child Activity completes, its parent's ActivityCoordinator must drive the childComplete/childLifetime SignalSet to produce the childComplete signal for distribution to any Actions with an interest in this signal. This Signal contains an ActivityInformation structure that indicates the GlobalId and final CompletionStatus of the completing Activity. (A separate issues proposes that the final Outcome of the child Activity also be included in the ActivityInformation). The specification leaves it to an Activity service implementation to determine how a parent Activity is notified of its child's completion and how the ActivityInformation is obtained by the parent's childComplete/childLifetime SignalSet. A practical approach is for the child ActivityCoordinator to call its parent ActivityCoordinator's process_signal_set("org.omg.childComplete") method. If the child Activity is active on the thread when childCompletion processing occurs, then the SignalSet in the parent can determine the child's GlobalId and CompletionStatus via the Current interface. (Note: the completionStatus of the child may be modified by the completion SignalSet during completion processing; it is the *final* completionStatus that should be reported during childComplete processing). An interoperation issue arises if a child Activity is rooted on a node that is downstream from the parent's root. In this case, childComplete signals need to originate from the parent's root ActivityCoordinator/SignalSet. Mechanically, the completing child should inform its (local) parent ActivityCoordinator by whichever implementation-specific means it uses and then the local (subordinate) parent ActivityCoordinator has to push this back up to its ultimate superior for distribution throughout the tree. The means by which this happens need to be defined to ensure interoperation across different vendors' implementations. One approach would be for the subordinate ActivityCoordinator to drive its superior's process_signal_set() method, ensuring that the ActivityContext is propagated on this flow (in order that the superior can obtain the child's GlobalId). A similar consideration holds for childBegin. There are issues with this approach; one is that any child Activity, begun at any node downstream to its parent, will always have its context imported (as a subordinate) to all upstream nodes on which its parent is active. A different solution to the problem might be to introduce a new method on the ActivityCoordinator interface that can be used during child-completion to pass the ActivityInformation object. This would mean that no service context would need to flowed and all the information required to deliver the childComplete signal would be available to the parent. This could be something like: void ActivityCoordinator::set_child_completed(in ActivityInformation ai) It would still be implementation-specific how that ActivityInformation got added to the signal, but that is not an interoperation issue. Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com Importance: Normal Subject: Issue 4348: proposal To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Thu, 19 Jul 2001 22:54:27 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 08:24:59 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: hY,!!@1Ld9UO;e9aWP!! Proposal for resolution of 4348: This issue is mostly closed by 4303. Only a minor clarification remains. The description of the ChildLifetime SignalSet in section 2.2.1 needs the following additional statement. If the parent of a sub-Activity is not a root Activity (ie it is a subordinate) then the distribution of the ChildLifetime signals is delegated upstream to the superior ActivityCoordinator. Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com From: "Mark Little" To: "XOTS" Subject: FTF meeting summary Date: Wed, 18 Jul 2001 10:05:44 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Filter-Version: 2.1 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *%D!!CL[d9H0jd9D]:!! Just a quick note to report on the meeting we had at Danvers. We managed to work through all of the issues that were reported prior to Danvers, though some have come up since. A brief summary of the issues we discussed, and the resolutions follows (the individuals who will write up the final proposed resolutions are also indicated). Proposal for 4348: closed due to 4303. [Ian Robinson to write up.]