Issue 4257: PropertyGroup propagation strategy on intermediate servers with no Property (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: PropertyGroup propagation strategy on intermediate servers with no PropertyGroupManger. The following section is taken from the Activity srevice specification orbos/2000-06-19. P58 "A PropertyGroupManager must be registered with each client and server that wishes to use the type of PropertyGroup it represents." Consider a configuration where objectA on serverA creates an Activity and sets PropertyGroup data for PropertyGroup1 and then calls objectB on serverB which calls objectC on serverC. The Activity service is configured on all 3 servers. ObjectB and objectC can both access the PropertyGroup data so long as a PropertyGroupManager for PropertyGroup1 is registered with the Activity services on serverB and serverC. This is necessary because a PropertyGroupManager is required to unmarshal the PropertyGroup context received with the request arriving at each server. What the specification does not define is whether or not all received PropertyGroup contexts at serverB are propagated on downstream to serverC if, for example, the PropertyGroupManager for PropertyGroup1 is not registered with the Activity service on serverB. If the PropertyGroup1 context is never to be used on serverB then it would simplify deployment if it were not necessary to configure a PropertyGroup1 PropertyGroupManager on that server just to ensure that the PropertyGroupIdentity part of the received context PGContext is propagated on downstream. It would also improve performance as the PropertyGroup context would not need to be unmarshalled, so long as the Activity service copied the marshalled PGContext from the inbound request to the outbound downstream request. This issue proposes that, in the case where an intermediate server has the Activity service configured but not a particular PropertyGroupManager, all PropertyGroupIdentities received with an inbound ActivityContext are propagated on downstream in any outbound ActivityContexts. Resolution: It was agreed that this should be allowed, and text modifications proposed Revised Text: Section 2.2.6 of the specification states: A PropertyGroupManager must be registered with each client and server that wishes to use the type of PropertyGroup it represents. I propose that this issue be resolved by changing that statement to: A PropertyGroupManager must be registered with the Activity service, in each domain, for each type of PropertyGroup that is accessed via the get_property_group method of the Current interface. Actions taken: April 5, 2001: received issue April 5, 2001: received issue May 2, 2003: closed issue Discussion: End of Annotations:===== From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id IAA23640; Fri, 6 Apr 2001 08:40:25 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A26.002A2391 ; Fri, 6 Apr 2001 08:40:16 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org cc: issues@omg.org Message-ID: <80256A26.002A112D.00@d06mta05.portsmouth.uk.ibm.com> Date: Thu, 5 Apr 2001 21:05:44 +0100 Subject: Activity service Issue: PropertyGroup propagation strategy on intermediate servers with no PropertyGroupManger. Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 6c\d9U(2e9Iind97X,e9 Juergen, please open an issue for the following: PropertyGroup propagation strategy on intermediate servers with no PropertyGroupManger. The following section is taken from the Activity srevice specification orbos/2000-06-19. P58 "A PropertyGroupManager must be registered with each client and server that wishes to use the type of PropertyGroup it represents." Consider a configuration where objectA on serverA creates an Activity and sets PropertyGroup data for PropertyGroup1 and then calls objectB on serverB which calls objectC on serverC. The Activity service is configured on all 3 servers. ObjectB and objectC can both access the PropertyGroup data so long as a PropertyGroupManager for PropertyGroup1 is registered with the Activity services on serverB and serverC. This is necessary because a PropertyGroupManager is required to unmarshal the PropertyGroup context received with the request arriving at each server. What the specification does not define is whether or not all received PropertyGroup contexts at serverB are propagated on downstream to serverC if, for example, the PropertyGroupManager for PropertyGroup1 is not registered with the Activity service on serverB. If the PropertyGroup1 context is never to be used on serverB then it would simplify deployment if it were not necessary to configure a PropertyGroup1 PropertyGroupManager on that server just to ensure that the PropertyGroupIdentity part of the received context PGContext is propagated on downstream. It would also improve performance as the PropertyGroup context would not need to be unmarshalled, so long as the Activity service copied the marshalled PGContext from the inbound request to the outbound downstream request. This issue proposes that, in the case where an intermediate server has the Activity service configured but not a particular PropertyGroupManager, all PropertyGroupIdentities received with an inbound ActivityContext are propagated on downstream in any outbound ActivityContexts. 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 Importance: Normal Subject: Issue 4257: proposal To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Wed, 18 Jul 2001 17:20:54 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 17:22:18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 8T 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 4257: clarification to allow a manager not to be present on a downstream node just for a node to act as a router. [Ian Robinson to write up.]