Issue 4254: Activity service Issue: Behaviour of get_coordinator() (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: The following section is taken from the Activity srevice specification orbos/2000-06-19. P51: "It is not strictly necessary for an implementation of the Activity Service to create an ActivityCoordinator prior to distributing a context between execution environments in which it was begun. Each Activity may be managed by at most one ActivityCoordinator." The description of Current::get_coordinator() is as follows: "Returns a reference to the current Activity?s ActivityCoordinator. This may be nil if a coordinator has yet to be created." I believe that the act of trying to obtain the ActivityCoordinator should cause it to be created if it doesn't exist already. For example, it should be reasonable (on a server at least) to code: CosActivity::Current_ptr cur; CosActivity::ActivityCooridinator_ptr coord1, coord2; ... curt->begin(); coord1 = cur->get_coordinator(); cur->begin(); coord2 = cur->get_coordinator(); coord2->is_same_activity(coord1); // This better be false! It shouldn't blow up, either. cur->complete(); cur->complete(); Thus, I believe get_coordinator() should never return nil. As a second part of this issue some execution environments, for example a lightweight client, may wish to restrict access to the Activity service through the Current interface only. Further, some environments may wish to limit restrict access to the Activity service to a subset of the Current function, providing little more than the ability to begin and end an Activity context and explicitly preventing the ability to register Actions from the environment. For example, a client environment may not have the capability to service inbound signals for Actions and so may not want to allow local Action implementations to be registered. Another example is a where recoverability of the Activity is required but a particular client environment cannot provide this quality of service. So, I suggest that at least the Current::get_coordinator() and add_action()/add_actions() methods should provide an exception that can be thrown by an implementation in an environment where use of the ActivityCoordinator or Action interfaces is not intended. In no case would it be desirable for these methods simply to return nil. Resolution: see above Revised Text: The Current interface get_coordinator method should only return nil if there is no Activity associated with the current thread. An Activity service implementation may chose to restrict the use of an ActivityCoordinator in certain environments, for example a light-weight client. The following changes to the specification are proposed. 1. Change the description of the Current get_coordinator method to the following: Returns a reference to the current Activity's ActivityCoordinator. Returns nil if no Activity is associated with the current thread. 2. Add the following text to the description of the ActivityCoordinator interface (section 2.2.3): Implementations of the Activity Service may restrict the use of the ActivityCoordinator in certain environment, such as a light-weight client. Actions taken: April 5, 2001: received issue May 2, 2003: closed issue Discussion: Resolution: Modify the text to allow a service implementation to restrict the availability of the coordination in certain execution environments End of Annotations:===== From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id SAA137996; Thu, 5 Apr 2001 18:04:51 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A25.005DD1DC ; Thu, 5 Apr 2001 18:04:45 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org cc: issues@omg.org Message-ID: <80256A25.005D6A03.00@d06mta05.portsmouth.uk.ibm.com> Date: Thu, 5 Apr 2001 17:58:49 +0100 Subject: Activity service Issue: Behaviour of get_coordinator() Mime-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f35H25b02769 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 1H&!!o-bd9=H*!!W5C!! Please open an issue for the following. The following section is taken from the Activity srevice specification orbos/2000-06-19. P51: "It is not strictly necessary for an implementation of the Activity Service to create an ActivityCoordinator prior to distributing a context between execution environments in which it was begun. Each Activity may be managed by at most one ActivityCoordinator." The description of Current::get_coordinator() is as follows: "Returns a reference to the current Activity?s ActivityCoordinator. This may be nil if a coordinator has yet to be created." I believe that the act of trying to obtain the ActivityCoordinator should cause it to be created if it doesn't exist already. For example, it should be reasonable (on a server at least) to code: CosActivity::Current_ptr cur; CosActivity::ActivityCooridinator_ptr coord1, coord2; ... curt->begin(); coord1 = cur->get_coordinator(); cur->begin(); coord2 = cur->get_coordinator(); coord2->is_same_activity(coord1); // This better be false! It shouldn't blow up, either. cur->complete(); cur->complete(); Thus, I believe get_coordinator() should never return nil. As a second part of this issue some execution environments, for example a lightweight client, may wish to restrict access to the Activity service through the Current interface only. Further, some environments may wish to limit restrict access to the Activity service to a subset of the Current function, providing little more than the ability to begin and end an Activity context and explicitly preventing the ability to register Actions from the environment. For example, a client environment may not have the capability to service inbound signals for Actions and so may not want to allow local Action implementations to be registered. Another example is a where recoverability of the Activity is required but a particular client environment cannot provide this quality of service. So, I suggest that at least the Current::get_coordinator() and add_action()/add_actions() methods should provide an exception that can be thrown by an implementation in an environment where use of the ActivityCoordinator or Action interfaces is not intended. In no case would it be desirable for these methods simply to return nil. Regards...Ian 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: , Cc: References: <80256A25.005D6A03.00@d06mta05.portsmouth.uk.ibm.com> Subject: Re: Activity service Issue: Behaviour of get_coordinator() Date: Fri, 6 Apr 2001 10:31:21 +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 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Fp@e9cnPd9o_\d9RZD!! ----- Original Message ----- I believe that the act of trying to obtain the ActivityCoordinator should cause it to be created if it doesn't exist already. For example, it should be reasonable (on a server at least) to code: As a second part of this issue some execution environments, for example a lightweight client, may wish to restrict access to the Activity service through the Current interface only. Further, some environments may wish to limit restrict access to the Activity service to a subset of the Current function, providing little more than the ability to begin and end an Activity context and explicitly preventing the ability to register Actions from the environment. For example, a client environment may not have the capability to service inbound signals for Actions and so may not want to allow local Action implementations to be registered. Another example is a where recoverability of the Activity is required but a particular client environment cannot provide this quality of service. So, I suggest that at least the Current::get_coordinator() and add_action()/add_actions() methods should provide an exception that can be thrown by an implementation in an environment where use of the ActivityCoordinator or Action interfaces is not intended. In no case would it be desirable for these methods simply to return nil. ------------------------------- I agree with both of these issues (in fact the historical records would show that point (i) was originally suggested way back when we started this work, but I can't remember why it was not accepted). As for point (ii), I'd suggest an Unavailable exception, similar to the OTS. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 Importance: Normal Subject: Re Issue 4254: Activity service Issue: Behaviour of get_coordinator() To: "Mark Little" Cc: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Fri, 29 Jun 2001 21:50:54 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 30/06/2001 07:19:34 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: >WMe9@UZ!!M`6!!M*&!! The one case where get_coordinator should return nil is when there is no Activity associated with the thread. 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 "Mark Little" on 06/04/2001 10:31:21 Please respond to "Mark Little" To: Ian Robinson/UK/IBM@IBMGB, ots-structs-ftf@omg.org cc: issues@omg.org Subject: Re: Activity service Issue: Behaviour of get_coordinator() ----- Original Message ----- I believe that the act of trying to obtain the ActivityCoordinator should cause it to be created if it doesn't exist already. For example, it should be reasonable (on a server at least) to code: As a second part of this issue some execution environments, for example a lightweight client, may wish to restrict access to the Activity service through the Current interface only. Further, some environments may wish to limit restrict access to the Activity service to a subset of the Current function, providing little more than the ability to begin and end an Activity context and explicitly preventing the ability to register Actions from the environment. For example, a client environment may not have the capability to service inbound signals for Actions and so may not want to allow local Action implementations to be registered. Another example is a where recoverability of the Activity is required but a particular client environment cannot provide this quality of service. So, I suggest that at least the Current::get_coordinator() and add_action()/add_actions() methods should provide an exception that can be thrown by an implementation in an environment where use of the ActivityCoordinator or Action interfaces is not intended. In no case would it be desirable for these methods simply to return nil. ------------------------------- I agree with both of these issues (in fact the historical records would show that point (i) was originally suggested way back when we started this work, but I can't remember why it was not accepted). As for point (ii), I'd suggest an Unavailable exception, similar to the OTS. Mark. ---------------------------------------------- Dr. Mark Little (mark@arjuna.com) Transactions Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191 2064203 Importance: Normal Subject: Issue 4254: proposal To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Tue, 17 Jul 2001 20:53:53 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 08:14:49 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: A?B!!EZ~!!Cfj!!TELe9 Proposal for resolution of 4254: The Current interface get_coordinator method should only return nil if there is no Activity associated with the current thread. An Activity service implementation may chose to restrict the use of an ActivityCoordinator in certain environments, for example a light-weight client. The following changes to the specification are proposed. 1. Change the description of the Current get_coordinator method to the following: Returns a reference to the current Activity's ActivityCoordinator. Returns nil if no Activity is associated with the current thread. 2. Add the following text to the description of the ActivityCoordinator interface (section 2.2.3): Implementations of the Activity Service may restrict the use of the ActivityCoordinator in certain environment, such as a light-weight client. 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 4254: some ActivityCoordinator operations can throw NO_IMPLEMENT to restrict what operations are available to specific users (e.g., clients). [Ian Robinson to write up.] Can also restrict Currents. [Mark Little to write up, for Vote 2.]