Issue 4345: ActivityPolicyValues and how they relate to Activity service object (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: The current specification defines ActivityPolicyValues that were based on the OTSPolicyValues at a time of flux for the OTS specification. These are currently: const ActivityPolicyValue IGNORES = 0; // This is the default const ActivityPolicyValue SUPPORTS = 1; const ActivityPolicyValue REQUIRES = 2; const ActivityPolicyValue REQUIRES_NONE = 3; Since OTS 1.2 is now finalised, I believe we should follow the pattern established by that specification and replace these policies with the following: const ActivityPolicyValue REQUIRES = 1; const ActivityPolicyValue FORBIDS = 2; const ActivityPolicyValue ADAPTS = 3; I'm not sure which policy should be used as a default in the absence of an explicit ActivityPolicy; I propose ADAPTS since FORBIDS seems a little harsh. The definitions for these policies should follow the equivalent OTSPolicy definitions. I don't believe we need any equivalent of the NonTxTargetPolicyValue (required only for interoperation with OTS 1.1). We need to define the policy that the Activity service objects themselves should use to determine whether or not context is expected to flow on operations on these objects. I believe this should be ADAPTS for all Activity service objects. Resolution: Update the specification in line with the OTS Revised Text: 2.3.1 Activity Service POA Attributes In order to control the flow of Activity context information, the following POA policy attributes are required that will be added to an object' IOR profile by the server for the benefit of the client/server interceptor: typedef unsigned short ActivityPolicyValue; const ActivityPolicyValue REQUIRES = 1; const ActivityPolicyValue FORBIDS = 2; const ActivityPolicyValue ADAPTS = 3; const ActivityPolicyValue INTERNAL = 4; const CORBA::PolicyType ActivityPolicyType = ??; // To be allocated interface ActivityPolicy : CORBA::Policy { readonly attribute ActivityPolicyValue apv; } The semantics of these policies will now be described (in the following section the term apv is the ActivityPolicyValue in the Activity component of the target object IOR). Note that an apv of ADAPTS should always be treated by a client in the same way as an IOR with no Activity component, in order to work with non-activity aware environments. Client-side =========== If apv is REQUIRES, then a method request must be sent with an Activity context. If there is no Activity context, then the client-side Activity service interceptor must raise the ACTIVITY_REQUIRED system exception and must not send the request. If apv is FORBIDS, then no Activity context is allowed to be sent. If there is an Activity context active on the thread, then the client-side Activity service interceptor must raise the INVALID_ACTIVITY system exception and must not send the request. If apv is ADAPTS, or if there is no ActivityPolicy, then an Activity context must be sent if and only if an Activity context is associated with the thread of the caller. This would include any requests to objects on a non-Activity aware ORB. If apv is INTERNAL then a method request must be sent without an Activity context regardless of whether it is made within the scope of an Activity or not. Activity service implementation objects use this policy. Server-side =========== The server-side Activity service interceptor should behave as follows when processing inbound requests: If apv is REQUIRES, then any received Activity context must be associated with the thread of execution. If no Activity context is received, the server-side Activity service interceptor must throw the ACTIVITY_REQUIRED system exception, thereby preventing the request from being dispatched. If apv is FORBIDS, then the server-side Activity service interceptor is required to check that no Activity context has been flowed with the request and to throw the INVALID_ACTIVITY system exception if it has, thereby preventing the request from being dispatched. If apv is ADAPTS, or if there is no ActivityPolicy, , then any received Activity context must be associated with the thread of execution. If apv is INTERNAL, any Activity context must be ignored. The client-side behavior above means that the server should never have to deal with this situation. Given that this situation constitutes a client-side error, an implementation may throw a system exception if this happens. <end of replaced text> The section entitled "Combinations of TransactionPolicyValues and ActivityPolicyValues" is unnecessary and should be removed. The following IDL should be added to the IDL in section B.1 within the CosActivity module typedef unsigned short ActivityPolicyValue; const ActivityPolicyValue REQUIRES = 1; const ActivityPolicyValue FORBIDS = 2; const ActivityPolicyValue ADAPTS = 3; const ActivityPolicyValue INTERNAL = 4; const CORBA::PolicyType ActivityPolicyType = ??; // To be allocated interface ActivityPolicy : CORBA::Policy { readonly attribute ActivityPolicyValue apv; } Actions taken: June 15, 2001: received issue May 2, 2003: closed issue Discussion: 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 f5FGmbB70720; Fri, 15 Jun 2001 17:48:37 +0100 Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A6C.005C4C26 ; Fri, 15 Jun 2001 17:48:08 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org cc: issues@omg.org Message-ID: <80256A6C.005C48E8.00@d06mta10.portsmouth.uk.ibm.com> Date: Fri, 15 Jun 2001 17:43:02 +0100 Subject: New issue: ActivityPolicyValues and how they relate to Activity service objects Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: h'*e9/]O!!Z#/!!dk#e9 The current specification defines ActivityPolicyValues that were based on the OTSPolicyValues at a time of flux for the OTS specification. These are currently: const ActivityPolicyValue IGNORES = 0; // This is the default const ActivityPolicyValue SUPPORTS = 1; const ActivityPolicyValue REQUIRES = 2; const ActivityPolicyValue REQUIRES_NONE = 3; Since OTS 1.2 is now finalised, I believe we should follow the pattern established by that specification and replace these policies with the following: const ActivityPolicyValue REQUIRES = 1; const ActivityPolicyValue FORBIDS = 2; const ActivityPolicyValue ADAPTS = 3; I'm not sure which policy should be used as a default in the absence of an explicit ActivityPolicy; I propose ADAPTS since FORBIDS seems a little harsh. The definitions for these policies should follow the equivalent OTSPolicy definitions. I don't believe we need any equivalent of the NonTxTargetPolicyValue (required only for interoperation with OTS 1.1). We need to define the policy that the Activity service objects themselves should use to determine whether or not context is expected to flow on operations on these objects. I believe this should be ADAPTS for all Activity service objects. 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: Re: issue 4345 - ActivityPolicyValues To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Thu, 5 Jul 2001 11:26:09 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 05/07/2001 11:28:31 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ~%Y!!!`9!!@-nd9jk(!! The ActivityPolicy interface and related definitions needs to be added to the CosActivity IDL. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) Importance: Normal Subject: Issue 4345: 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 21:30:41 +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: 9fOd9"Ugd9LSpd9ogT!! The Activity service specification currently defines the following ActivityPolicyValues: const ActivityPolicyValue IGNORES = 0; // This is the default const ActivityPolicyValue SUPPORTS = 1; const ActivityPolicyValue REQUIRES = 2; const ActivityPolicyValue REQUIRES_NONE = 3; These should be renamed and redefined to be consistent with the policy values decided upon for OTS1.2. The OTS 1.2 specification has no equivalent of IGNORES but an OTS Issue (4030) is considering a policy value of INTERNAL for OTS objects. I propose an equivalent value for Activity service objects. I also propose that, with the removal of the IGNORES policy, ADAPTS is used as the default in the absence of any Activity policy. Section 2.3.1 of the specification should be replaced with the text below. 2.3.1 Activity Service POA Attributes In order to control the flow of Activity context information, the following POA policy attributes are required that will be added to an object' IOR profile by the server for the benefit of the client/server interceptor: typedef unsigned short ActivityPolicyValue; const ActivityPolicyValue REQUIRES = 1; const ActivityPolicyValue FORBIDS = 2; const ActivityPolicyValue ADAPTS = 3; const ActivityPolicyValue INTERNAL = 4; const CORBA::PolicyType ActivityPolicyType = ??; // To be allocated interface ActivityPolicy : CORBA::Policy { readonly attribute ActivityPolicyValue apv; } The semantics of these policies will now be described (in the following section the term apv is the ActivityPolicyValue in the Activity component of the target object IOR). Note that an apv of ADAPTS should always be treated by a client in the same way as an IOR with no Activity component, in order to work with non-activity aware environments. Client-side =========== If apv is REQUIRES, then a method request must be sent with an Activity context. If there is no Activity context, then the client-side Activity service interceptor must raise the ACTIVITY_REQUIRED system exception and must not send the request. If apv is FORBIDS, then no Activity context is allowed to be sent. If there is an Activity context active on the thread, then the client-side Activity service interceptor must raise the INVALID_ACTIVITY system exception and must not send the request. If apv is ADAPTS, or if there is no ActivityPolicy, then an Activity context must be sent if and only if an Activity context is associated with the thread of the caller. This would include any requests to objects on a non-Activity aware ORB. If apv is INTERNAL then a method request must be sent without an Activity context regardless of whether it is made within the scope of an Activity or not. Activity service implementation objects use this policy. Server-side =========== The server-side Activity service interceptor should behave as follows when processing inbound requests: If apv is REQUIRES, then any received Activity context must be associated with the thread of execution. If no Activity context is received, the server-side Activity service interceptor must throw the ACTIVITY_REQUIRED system exception, thereby preventing the request from being dispatched. If apv is FORBIDS, then the server-side Activity service interceptor is required to check that no Activity context has been flowed with the request and to throw the INVALID_ACTIVITY system exception if it has, thereby preventing the request from being dispatched. If apv is ADAPTS, or if there is no ActivityPolicy, , then any received Activity context must be associated with the thread of execution. If apv is INTERNAL, any Activity context must be ignored. The client-side behavior above means that the server should never have to deal with this situation. Given that this situation constitutes a client-side error, an implementation may throw a system exception if this happens. The section entitled "Combinations of TransactionPolicyValues and ActivityPolicyValues" is unnecessary and should be removed. The following IDL should be added to the IDL in section B.1 within the CosActivity module typedef unsigned short ActivityPolicyValue; const ActivityPolicyValue REQUIRES = 1; const ActivityPolicyValue FORBIDS = 2; const ActivityPolicyValue ADAPTS = 3; const ActivityPolicyValue INTERNAL = 4; const CORBA::PolicyType ActivityPolicyType = ??; // To be allocated interface ActivityPolicy : CORBA::Policy { readonly attribute ActivityPolicyValue apv; } 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 4345: editorial updates. [Ian Robinson to write up.]