Issue 3663: IORInterceptor invoked on each Object Adapter Creation (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: There is no way to determine a unique policy set. Invoking IORInterceptors on each adapter creation is therefore implicit in the current specification. However, to ensure portability, the specification should explicitly say that IORInterceptors are invoked on every adapter creation (regardless of the policy set). A Server Activation Framework needs this guarantee so that each persistent POA (re)created may exchange information with an activation daemon. Resolution: Close issue. No change Revised Text: Actions taken: May 30, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Tue, 30 May 2000 07:37:42 -0700 (PDT) Message-Id: <200005301437.HAA14156@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org, issues@omg.org Subject: IORInterceptor invoked on each Object Adapter Creation Content-Type: text X-UIDL: /4cd9S4J!!4I:e9b From: Harold Carr To: interceptors-ftf@omg.org, issues@omg.org Subject: Portable Activation Framework using Portable Interceptors Content-Type: text X-UIDL: BMhd9FO!e9BIBe9&$>e9 Jurgen, this is a discussion of issues I raised earlier, please do not make this an issue. All, OK, as promised, here are how the issues I raised relate to building a portable activation service. Please keep in mind, *THIS IS A USE-CASE*. We are *NOT* trying to standardize location/activation services. We are proposing changes/extensions to portable interceptors based on our prototype of an activation service built using portable interceptors. I've identified the portions of the service which require changes/extensions to the existing PI spec by preceding them with "PI FTF". ORBD Startup - PI FTF - ORBD is started on same port -ORBPersistentServerPort. - ORBD specifies its ORBInitializer class. - ORBDInitializer creates and registers activator reference in initial references. - ORBDInitializer creates and registers a ServerRequestInterceptor. Server Startup - PI FTF - started with PersistentServerId (passed by activator). - Activator passes appropriate ORBInitializer class. - ORBInitializer pre_init creates and registers IORInterceptor. - ORBInitializer post_init uses - ORBInitInfo::resolve_initial_references to obtain a reference to the Activator which it gives to - IORInterceptor for use during POA creation. Server POA Creation In IORInterceptor: - PI FTF - everything happens in new point: components_available. - PI FTF - need access to POA LifeSpanPolicy (to determine if - PERSISTENT). - If persistent then do the following steps. - PI FTF - get the IORTemplate associated with this POA. - Register that template with the activator. - Get the activator's template. - PI FTF - set the adapter's template to the activator's template. - Now, any references created by this POA will "point" to the activator (and contain components appropriate for the activator). - PI FTF - the IORInterceptor must be called each time a POA is (re)created to enable it to exchange information with the - activator. ORBD Server Request Interceptor - Get the adapter_id from ServerRequestInfo. - Lookup the template associated with this id. - If it doesn't exist then request is for the ORBD. - Otherwise - Get the object_id from ServerRequestInfo. - PI FTF - Use the object id to create a new reference from the - server's template. - Raise ForwardRequest. Misc - PI FTF - not explicit is the fact that Java ORBs need an ORB ID for persistent references to be unique: serverId | orbId | poa path/name. - PI FTF - when an object adapter is destroyed it notifies the activator of this fact so that the activator may reclaim resources. Cheers, Harold Date: Wed, 28 Jun 2000 12:48:28 -0700 (PDT) Message-Id: <200006281948.MAA26342@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Content-Type: text X-UIDL: jp"!!;AR!!3)e!!B A Server Activation Framework needs this guarantee so that each persistent POA (re)created may exchange information with an activation daemon.

In general, someone may create several POAs with identical policies but different servant managers. The servant managers can make POA behave completely different even though they have the same set of policies. Therefore it would make sense to invoke the IORInterceptor for each adapter creation. This also brings up the question, if POAs have the same policy set but different values for those policies, are they considered equivalent with respect to invoking IORInterceptor. I do not think this question needs to be answered if we just say that IORInterceptor is invoked on each adapter creation regardless of the policy set. I would like to include this issue in the vote 4 cycle coming soon. Cheers, Harold Date: Wed, 28 Jun 2000 16:36:32 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <200006281948.MAA26342@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]S[d9VhMe9>'0!!oC`d9 Harold Carr wrote: > > There is no way to determine a unique policy set. Invoking > IORInterceptors on each adapter creation is therefore implicit in the Our ORB does determine unique policy sets, but I refuse to get into how or why. I disagree that invocing the IORInterceptors on each adapter creation is implicit. > current specification. However, to ensure portability, the > specification should explicitly say that IORInterceptors are invoked > on every adapter creation (regardless of the policy set).

The submitters discussed the requirements on when IORInterceptors are invoked at great length and agreed to the current requirements. This was not an error or omission. I don't think it is in scope for FTF to revisit this decision without some evidence that the current specification is unworkable. > > A Server Activation Framework needs this guarantee so that each > persistent POA (re)created may exchange information with an > activation > daemon.

Supporting server activation frameworks was explicitly not considered a requirement in the adopted specification. We believe it is out of scope for the FTF to be adding this requirement at this point in time. I don't think you are considering all the implications of this "feature" anyway - like how would you portably disable whatever interactions the ORB normal performs with its own activation/location daemon(s)? IONA is opposed to adding this requirement to the portable interceptors specification, or making changes that are only justified by this requirement. > > In general, someone may create several POAs with identical policies > but different servant managers. The servant managers can make POA > behave completely different even though they have the same set of > policies. Therefore it would make sense to invoke the > IORInterceptor > for each adapter creation. The servant managers are not visible to the IORInterceptor, which cannot even assume that a POA is involved (the application may be using a BOA or proprietary OA or even a future OMG standard special purpose OA). The model supported by the Portable Interceptor specification is that the IORInterceptor uses the policy information to determine what components to add to the IOR. Whether the POA is the object adapter, and if so, what kind of servant managers it has, are not relevant. > > This also brings up the question, if POAs have the same policy set > but > different values for those policies, are they considered equivalent > with respect to invoking IORInterceptor. I do not think this > question > needs to be answered if we just say that IORInterceptor is invoked > on > each adapter creation regardless of the policy set. I can't see what someone would say that the POAs have the "same policy set" if the values were different. But maybe this does need to be clarified in the current specification. I would define "same policy set" as something like "identical values for all effective policies". > > I would like to include this issue in the vote 4 cycle coming soon. I think some discussion might be in order first. I don't sense we've achieved consensus. > > Cheers, > Harold -Bob Date: Wed, 28 Jun 2000 14:06:57 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <200006281948.MAA26342@shorter.eng.sun.com> <395A61D0.34A5E55D@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7N3!!S!,!!"?H!!iLa!! Bob Kukura wrote: > > Harold Carr wrote: > > > > There is no way to determine a unique policy set. Invoking > > IORInterceptors on each adapter creation is therefore implicit in the > > Our ORB does determine unique policy sets, but I refuse to get into how > or why. I disagree that invocing the IORInterceptors on each adapter > creation is implicit. If there is no portable way to determine unique policy sets then IORInterceptors will be invoked differently on different ORBs. Not good. Other submitters have made this implicit argument statement many times. No one has disagreed until now. > > > current specification. However, to ensure portability, the > > specification should explicitly say that IORInterceptors are invoked > > on every adapter creation (regardless of the policy set).

> > The submitters discussed the requirements on when IORInterceptors are > invoked at great length and agreed to the current requirements. This was > not an error or omission. I don't think it is in scope for FTF to > revisit this decision without some evidence that the current > specification is unworkable. Yes, I was there. I recall not being very happy with it but agreed to move on to other topics. The use case below shows how it is not workable. > > > > > A Server Activation Framework needs this guarantee so that each > > persistent POA (re)created may exchange information with an activation > > daemon.

> > Supporting server activation frameworks was explicitly not considered a > requirement in the adopted specification. We believe it is out of scope > for the FTF to be adding this requirement at this point in time. I don't > think you are considering all the implications of this "feature" anyway > - like how would you portably disable whatever interactions the ORB > normal performs with its own activation/location daemon(s)? IONA is > opposed to adding this requirement to the portable interceptors > specification, or making changes that are only justified by this > requirement. I brought up the SAF as a use-case, not a requirement. So let's not beat on that now. > > > > > In general, someone may create several POAs with identical policies > > but different servant managers. The servant managers can make POA > > behave completely different even though they have the same set of > > policies. Therefore it would make sense to invoke the IORInterceptor > > for each adapter creation. > > The servant managers are not visible to the IORInterceptor, which cannot > even assume that a POA is involved (the application may be using a BOA > or proprietary OA or even a future OMG standard special purpose OA). The > model supported by the Portable Interceptor specification is that the > IORInterceptor uses the policy information to determine what components > to add to the IOR. Whether the POA is the object adapter, and if so, > what kind of servant managers it has, are not relevant. If one wanted to have N POAs with identical policies but different servant managers AND they wanted to put different info in the tagged components depending on the servant manager they would then have to create their own policy (and register a factory) and add this policy to the list of policies given to the create_poa operation. Suppose 3 POAs are created with policy X used to indicate something about the servant manager. Suppose the values of policy X are: POA1 X1 - A POA2 X2 - B POA3 X3 - A An IORInterceptor writer would reasonably expect to see IORInterceptor::establish_components to be invoked when POA1 and POA2 are created since the policy set (which includes their values) are different. However, the spec seems to indicate the one could not necessarily expect the point to be called when POA3 is created since it has a set which was previously seen. So, the IOR created by POA3 will not necessarily contain the tagged components the user would like included in the IOR since the interceptor may or may not be invoked. Or maybe they could expect to see whatever was established when creating POA1 to also happen for POA3 since the policy set is identical. Both of these situations seem unnecessary and overly subtle. What exactly is the problem with just calling IORInterceptor points on each adapter creation? It seems simple to understand and reasonable to implement. > > > > > This also brings up the question, if POAs have the same policy set but > > different values for those policies, are they considered equivalent > > with respect to invoking IORInterceptor. I do not think this question > > needs to be answered if we just say that IORInterceptor is invoked on > > each adapter creation regardless of the policy set. > > I can't see what someone would say that the POAs have the "same policy > set" if the values were different. But maybe this does need to be > clarified in the current specification. I would define "same policy set" > as something like "identical values for all effective policies". Yes, clarification would be necessary - although I think we should just say they are called on each creation - end of story. > > > > > I would like to include this issue in the vote 4 cycle coming soon. > > I think some discussion might be in order first. I don't sense we've > achieved consensus. Agreed, thus my original mail... > > > > > Cheers, > > Harold > > -Bob Harold Date: Wed, 28 Jun 2000 20:55:25 -0230 From: Matthew Newhook To: Harold Carr Cc: Bob Kukura , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000628205525.A5152@ooc.com> References: <200006281948.MAA26342@shorter.eng.sun.com> <395A61D0.34A5E55D@iona.com> <395A68F1.1F6D793C@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <395A68F1.1F6D793C@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: Y'kd9@2f!!DJTd9k!$e9 Hi, On Wed, Jun 28, 2000 at 02:06:57PM -0700, Harold Carr wrote: >[...] > > Supporting server activation frameworks was explicitly not considered a > > requirement in the adopted specification. We believe it is out of scope > > for the FTF to be adding this requirement at this point in time. I don't > > think you are considering all the implications of this "feature" anyway > > - like how would you portably disable whatever interactions the ORB > > normal performs with its own activation/location daemon(s)? IONA is > > opposed to adding this requirement to the portable interceptors > > specification, or making changes that are only justified by this > > requirement. > > I brought up the SAF as a use-case, not a requirement. So let's not > beat on that now. Please illuminate the group on some other use-cases the "require" this behaviour. I am still *firmly* of the opinion that this server activation framework should be handled as a seperate RFP. I have definitely not heard *any* convincing argument to the contrary. >[...] > Harold Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 28 Jun 2000 16:39:27 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Bob Kukura , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <200006281948.MAA26342@shorter.eng.sun.com> <395A61D0.34A5E55D@iona.com> <395A68F1.1F6D793C@sun.com> <20000628205525.A5152@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Sd6!!,YP!!n*]d9\-*e9 As I said in the message, let's not beat on SAF regarding this issue. Also, please refer to the example I gave which illustrates the general problem. H Matthew Newhook wrote: > > Hi, > > On Wed, Jun 28, 2000 at 02:06:57PM -0700, Harold Carr wrote: > >[...] > > > Supporting server activation frameworks was explicitly not considered a > > > requirement in the adopted specification. We believe it is out of scope > > > for the FTF to be adding this requirement at this point in time. I don't > > > think you are considering all the implications of this "feature" anyway > > > - like how would you portably disable whatever interactions the ORB > > > normal performs with its own activation/location daemon(s)? IONA is > > > opposed to adding this requirement to the portable interceptors > > > specification, or making changes that are only justified by this > > > requirement. > > > > I brought up the SAF as a use-case, not a requirement. So let's not > > beat on that now. > > Please illuminate the group on some other use-cases the "require" > this behaviour. > > I am still *firmly* of the opinion that this server activation framework > should be handled as a seperate RFP. I have definitely not heard *any* > convincing argument to the contrary. > > >[...] > > Harold > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 28 Jun 2000 21:19:44 -0230 From: Matthew Newhook To: Harold Carr Cc: Bob Kukura , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000628211944.A5286@ooc.com> References: <200006281948.MAA26342@shorter.eng.sun.com> <395A61D0.34A5E55D@iona.com> <395A68F1.1F6D793C@sun.com> <20000628205525.A5152@ooc.com> <395A8CAF.A81201B@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <395A8CAF.A81201B@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ;[ld9#E$!!#nG!!NBg!! Hi, On Wed, Jun 28, 2000 at 04:39:27PM -0700, Harold Carr wrote: > As I said in the message, let's not beat on SAF regarding this issue. > Also, please refer to the example I gave which illustrates the general > problem. I read the example prior to replying and I don't see a general problem. How could the fact that there are servant managers (which the interceptor cannot determine anyway) influence the set of components that are placed in IORs for that POA? The selection of IOR components should be based on the policy set for the POA. I don't think that the spec should make any statement on this matter. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 29 Jun 2000 11:25:57 -0700 (PDT) Message-Id: <200006291825.LAA25914@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Content-Type: text X-UIDL: IcZ!!b#Je95MNe96BLe9 21.5.2.1 establish_components states: "A server side ORB calls the establish_components operation on all registered IORInterceptor instances when it is assembling the list of components that will be included in the profile or profiles of an object reference. This operation is not necessarily called for each individual object reference. For example, the POA specifies policies at POA granularity and therefore, this operation might be called once per POA rather than once per object. In any case, establish_components is guaranteed to be called at least once for each distinct set of server policies." This is ambiguous, particularly the last sentence. Consider: Four (and only four) POAs, A, B, C, D, are created somewhere within the scope of a particular rootPOA in a particular ORB instance. The following policies are given to create_poa when the POAs are created in the listed order: A - X/1 - means policy X with a value of 1. B - X/2 C - Y/3 D - X/1 IORInterceptor::establish_components (called II::ec for the rest of the discussion) is called when A is created. We assume it will be called since this is the first POA created under this particular rootPOA. This points out an ambiguity - what is the scope of "each distinct set of server policies"? II::ec called during the creation of A uses X/1 to determine to "establish" a tagged component, let's call it TC_X. B is then created. We assume II::ec will be called since the value of the X policy is different from the previous "set." Another ambiguity: does "distinct set" include values or just it just mean types? C is then created and would definitely be invoked since it has a policy of a new type and value which hasn't been seen before. Finally D is created. Since X/1 has been seen before does this mean that II::ec is not called in this case? That means that references created by POA D will not contain TC_X although that is what the interceptor writer/POA creator intended when they passed the X/1 policy to create_poa when creating D. Since II::ec is not called because it has the same distinct set of policies that were given during the creation of A does this mean that the ORB will automatically establish TC_X for references created by POA D? Further, would the ORB have to remember if the invocation of II::ec during the creation of A used add_ior_component or add_ior_component_to_profile? One approach to solving the ambiguity would be to add verbage to clarify the above (and probably other combinations I haven't thought of at the moment). However, that would result in a subtle, complex, hard-to-use specification. To me the correct solution is to say that II::ec is called on each adapter creation. This is simple and intuitive for the user to understand. I can see no technical reason for not taking this approach. During the discussion and straw-poll taken on this issue in Oslo nobody dissented with the "call on each adapter" solution. Cheers, Harold Date: Thu, 29 Jun 2000 15:07:25 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <200006291825.LAA25914@shorter.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: dO+e9Ydgd9`ee!!52hd9 Harold Carr wrote: > > 21.5.2.1 establish_components states: > > "A server side ORB calls the establish_components operation on all > registered IORInterceptor instances when it is assembling the list of > components that will be included in the profile or profiles of an > object reference. This operation is not necessarily called for each > individual object reference. For example, the POA specifies policies > at POA granularity and therefore, this operation might be called once > per POA rather than once per object. In any case, establish_components > is guaranteed to be called at least once for each distinct set of > server policies." > > This is ambiguous, particularly the last sentence. I don't think it is ambiguous. Its just, as intended, giving the ORB vendor some flexibility. All its trying to say is that the portable interceptor implementation cannot depend on a distinct establish_components call for each distinct POA (or other construct in a diffrent OA). > > Consider: > > Four (and only four) POAs, A, B, C, D, are created somewhere within > the scope of a particular rootPOA in a particular ORB instance. > > The following policies are given to create_poa when the POAs are > created in the listed order: > > A - X/1 - means policy X with a value of 1. > B - X/2 > C - Y/3 > D - X/1 > > IORInterceptor::establish_components (called II::ec for the rest of > the discussion) is called when A is created. We assume it will be > called since this is the first POA created under this particular > rootPOA. This points out an ambiguity - what is the scope of "each > distinct set of server policies"? II::ec called during the creation > of A uses X/1 to determine to "establish" a tagged component, let's > call it TC_X. I think the scope here was intended to be bounded by the ORB lifetime. It is possible that some other non-POA object adapter happens to use the exact same effective components, and that the ORB doesn't even need to call II::ec when POA A is created. > > B is then created. We assume II::ec will be called since the value > of > the X policy is different from the previous "set." Another > ambiguity: > does "distinct set" include values or just it just mean types? I've always intended it to include values. It wouldn't be very useful for it to just mean types, as portable interceptor implementations could not count on the chance to create the appropriate components for each distinct set of policy values. This may need clarification. > > C is then created and would definitely be invoked since it has a > policy of a new type and value which hasn't been seen before. > > Finally D is created. Since X/1 has been seen before does this mean > that II::ec is not called in this case? That means that references > created by POA D will not contain TC_X although that is what the > interceptor writer/POA creator intended when they passed the X/1 > policy to create_poa when creating D. It is up to the ORB vendor to decide whether II::ec will be called in this case. Portable interceptor implemenations cannot assume that it will or will not. This is important because it implies that a portable interceptor can only base its decision of what components to include on the policies. But what I think you are missing, and may need clarification, is that, if the ORB does not call II::ec in this case, it still must include TC_X in the references created with POA D. > > Since II::ec is not called because it has the same distinct set of > policies that were given during the creation of A does this mean > that > the ORB will automatically establish TC_X for references created by > POA D? Further, would the ORB have to remember if the invocation of > II::ec during the creation of A used add_ior_component or > add_ior_component_to_profile? I've never really undestood add_ior_component_to_profile, so I can't comment on that. Our ORB has pluggable transports that may use different profiles, and generally there is no need for ORB services to be aware of which transport(s) are in use, so we discourage use of add_ior_component_to_profile. But, to answer your question, the ORB does have to do everything as if II::ec were called for POA D, whether or not it actually does call it for POA D. Correct portable interceptor implementations must do the same thing for the same set of policies, no matter how many times II::ec is called for that set of policies. Note that this would be required even if the ORB could be guaranteed to call II::ec for each POA, since the object references need to be equivalent for each activation of the "same" POA. > > One approach to solving the ambiguity would be to add verbage to > clarify the above (and probably other combinations I haven't thought > of at the moment). However, that would result in a subtle, complex, > hard-to-use specification. I really don't see the problem. > > To me the correct solution is to say that II::ec is called on each > adapter creation. This is simple and intuitive for the user to > understand. I can see no technical reason for not taking this > approach. During the discussion and straw-poll taken on this issue > in > Oslo nobody dissented with the "call on each adapter" solution. Unfortunately, I could not be there. The danger of this approach is that it will lead interceptor implementors into thinking they have the freedom to base the components they add in II::ec on things other than the set of effective policies. But doing that would potentially lead to subtle bugs and degradations due to slightly different sets of components being generated each time the "same" POA is activated. It would also potentially lead to the slippery slope of making the POACurrent available during this interceptor point, and things like that, which I think we must stay completely clear of. > > Cheers, > Harold -Bob From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: Issue 3663: IORInterceptor invoked on each Object Adapter Cre ation Date: Thu, 29 Jun 2000 18:03:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: [cZ!!X&K!!md3!!Om`!! I think I pretty much agree with Bob, conceptually. But it seems to me that there is a problem deciding what constitutes a unique set of policies. This must mean policy values, not just policy types. And it would be no problem if we restricted ourselves to the well defined set of POA Policies - they all have simple value semantics and are immutable. But we have now permitted any old policy to be attached to a POA. These could be remote objects and/or they might have mutable state. The usual bugaboo about object identity then makes it impossible in general to tell whether one set of policies is equal to another set of policies. I suppose this still permits Bob to make his optimization when only certain kinds of policies, known to have proper behavior, are present. But as soon as Polar adds an exotic security policy to the poa all bets are off. Paul > -----Original Message----- > From: Bob Kukura [mailto:kukura@iona.com] > Sent: Thursday, June 29, 2000 3:07 PM > To: Harold Carr > Cc: interceptors-ftf@omg.org > Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter > Creation > > > > > Harold Carr wrote: > > > > 21.5.2.1 establish_components states: > > > > "A server side ORB calls the establish_components operation on all > > registered IORInterceptor instances when it is assembling > the list of > > components that will be included in the profile or profiles of an > > object reference. This operation is not necessarily called for each > > individual object reference. For example, the POA specifies policies > > at POA granularity and therefore, this operation might be > called once > > per POA rather than once per object. In any case, > establish_components > > is guaranteed to be called at least once for each distinct set of > > server policies." > > > > This is ambiguous, particularly the last sentence. > > I don't think it is ambiguous. Its just, as intended, giving the ORB > vendor some flexibility. All its trying to say is that the portable > interceptor implementation cannot depend on a distinct > establish_components call for each distinct POA (or other > construct in a > diffrent OA). > > > > > Consider: > > > > Four (and only four) POAs, A, B, C, D, are created somewhere within > > the scope of a particular rootPOA in a particular ORB instance. > > > > The following policies are given to create_poa when the POAs are > > created in the listed order: > > > > A - X/1 - means policy X with a value of 1. > > B - X/2 > > C - Y/3 > > D - X/1 > > > > IORInterceptor::establish_components (called II::ec for the rest of > > the discussion) is called when A is created. We assume it will be > > called since this is the first POA created under this particular > > rootPOA. This points out an ambiguity - what is the scope of "each > > distinct set of server policies"? II::ec called during the creation > > of A uses X/1 to determine to "establish" a tagged component, let's > > call it TC_X. > > I think the scope here was intended to be bounded by the ORB lifetime. > It is possible that some other non-POA object adapter happens > to use the > exact same effective components, and that the ORB doesn't even need to > call II::ec when POA A is created. > > > > > B is then created. We assume II::ec will be called since > the value of > > the X policy is different from the previous "set." Another > ambiguity: > > does "distinct set" include values or just it just mean types? > > I've always intended it to include values. It wouldn't be very useful > for it to just mean types, as portable interceptor > implementations could > not count on the chance to create the appropriate components for each > distinct set of policy values. This may need clarification. > > > > > C is then created and would definitely be invoked since it has a > > policy of a new type and value which hasn't been seen before. > > > > Finally D is created. Since X/1 has been seen before does this mean > > that II::ec is not called in this case? That means that references > > created by POA D will not contain TC_X although that is what the > > interceptor writer/POA creator intended when they passed the X/1 > > policy to create_poa when creating D. > > It is up to the ORB vendor to decide whether II::ec will be called in > this case. Portable interceptor implemenations cannot assume that it > will or will not. This is important because it implies that a portable > interceptor can only base its decision of what components to > include on > the policies. > > But what I think you are missing, and may need clarification, is that, > if the ORB does not call II::ec in this case, it still must > include TC_X > in the references created with POA D. > > > > > Since II::ec is not called because it has the same distinct set of > > policies that were given during the creation of A does this > mean that > > the ORB will automatically establish TC_X for references created by > > POA D? Further, would the ORB have to remember if the invocation of > > II::ec during the creation of A used add_ior_component or > > add_ior_component_to_profile? > > I've never really undestood add_ior_component_to_profile, so I can't > comment on that. Our ORB has pluggable transports that may > use different > profiles, and generally there is no need for ORB services to > be aware of > which transport(s) are in use, so we discourage use of > add_ior_component_to_profile. But, to answer your question, > the ORB does > have to do everything as if II::ec were called for POA D, > whether or not > it actually does call it for POA D. > > Correct portable interceptor implementations must do the same > thing for > the same set of policies, no matter how many times II::ec is > called for > that set of policies. Note that this would be required even > if the ORB > could be guaranteed to call II::ec for each POA, since the object > references need to be equivalent for each activation of the > "same" POA. > > > > > One approach to solving the ambiguity would be to add verbage to > > clarify the above (and probably other combinations I haven't thought > > of at the moment). However, that would result in a subtle, complex, > > hard-to-use specification. > > I really don't see the problem. > > > > > To me the correct solution is to say that II::ec is called on each > > adapter creation. This is simple and intuitive for the user to > > understand. I can see no technical reason for not taking this > > approach. During the discussion and straw-poll taken on > this issue in > > Oslo nobody dissented with the "call on each adapter" solution. > > Unfortunately, I could not be there. The danger of this > approach is that > it will lead interceptor implementors into thinking they have the > freedom to base the components they add in II::ec on things other than > the set of effective policies. But doing that would > potentially lead to > subtle bugs and degradations due to slightly different sets of > components being generated each time the "same" POA is activated. It > would also potentially lead to the slippery slope of making the > POACurrent available during this interceptor point, and things like > that, which I think we must stay completely clear of. > > > > > Cheers, > > Harold > > -Bob > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 29 Jun 2000 19:00:49 -0400 (EDT) From: Polar Humenn To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: Issue 3663: IORInterceptor invoked on each Object Adapter Cre ation In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BF14@bos1.noblenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: L7V!!G0Qe99-^d9IBZ!! On Thu, 29 Jun 2000, Paul Kyzivat wrote: > I think I pretty much agree with Bob, conceptually. > But it seems to me that there is a problem deciding what constitutes > a > unique set of policies. > > This must mean policy values, not just policy types. And it would be > no > problem if we restricted ourselves to the well defined set of POA > Policies - > they all have simple value semantics and are immutable. > > But we have now permitted any old policy to be attached to a > POA. These > could be remote objects and/or they might have mutable state. The > usual > bugaboo about object identity then makes it impossible in general to > tell > whether one set of policies is equal to another set of policies. > > I suppose this still permits Bob to make his optimization when only > certain > kinds of policies, known to have proper behavior, are present. But > as soon > as Polar adds an exotic security policy to the poa all bets are off. I know, everybody blames me! :) I'm used to it. Seriously the only hook we have is the policy framework. However, when a POA is created and the IORInterceptor::establish_components is created, we only expect to use certain policies out of an Portable Object Adapter. One of these policies may contain a reference to a set of Credentials objects that will be used to prime the IOR. I think we have stated that we will resign ourselves to a particular POA as the granlarity for credentials assoicated with the object references created by that POA, because that is the only hook we have. However, on at least one BOA ORB that we use, we don't have that luxury, because we only have one BOA per ORB, so establish_compoents would have be called on each object reference created. In either case, I think it's clear that if you have a BOA and portable inteceptors you know when establish components has to be called, with a POA it can be called once. So, I think, I agree with Bob. However, I agree with Harold that I don't understand this sentence: "In any case, establish_components is guaranteed to be called at least once for each distinct set of server policies." What does distinct set of server policies really mean? CORBA Policy doesn't have an "boolean equals(CORBA::Policy the_policy)" operation, right? And doing those comparisons to figure that sentence out would *really* be inefficient. I would say that establish_components is guaranteed to be called at least once for each Object Adapter created to guarantee coverage, if not for each object reference created. I'm not sure how it can be any other way? I realize this might be inefficient if you are cranking out POAs ad nauseum with the same policies, but the call can return relatively quickly if you cache the components. I think. I could just be foaming at the mouth, which most people think I'm doing these days. :) Cheers, -Polar > Paul > > > -----Original Message----- > > From: Bob Kukura [mailto:kukura@iona.com] > > Sent: Thursday, June 29, 2000 3:07 PM > > To: Harold Carr > > Cc: interceptors-ftf@omg.org > > Subject: Re: Issue 3663: IORInterceptor invoked on each Object >Adapter > > Creation > > > > > > > > > > Harold Carr wrote: > > > > > > 21.5.2.1 establish_components states: > > > > > > "A server side ORB calls the establish_components operation on >all > > > registered IORInterceptor instances when it is assembling > > the list of > > > components that will be included in the profile or profiles of >an > > > object reference. This operation is not necessarily called for >each > > > individual object reference. For example, the POA specifies >policies > > > at POA granularity and therefore, this operation might be > > called once > > > per POA rather than once per object. In any case, > > establish_components > > > is guaranteed to be called at least once for each distinct set >of > > > server policies." > > > > > > This is ambiguous, particularly the last sentence. > > > > I don't think it is ambiguous. Its just, as intended, giving the >ORB > > vendor some flexibility. All its trying to say is that the >portable > > interceptor implementation cannot depend on a distinct > > establish_components call for each distinct POA (or other > > construct in a > > diffrent OA). > > > > > > > > Consider: > > > > > > Four (and only four) POAs, A, B, C, D, are created somewhere >within > > > the scope of a particular rootPOA in a particular ORB instance. > > > > > > The following policies are given to create_poa when the POAs are > > > created in the listed order: > > > > > > A - X/1 - means policy X with a value of 1. > > > B - X/2 > > > C - Y/3 > > > D - X/1 > > > > > > IORInterceptor::establish_components (called II::ec for the rest >of > > > the discussion) is called when A is created. We assume it will >be > > > called since this is the first POA created under this particular > > > rootPOA. This points out an ambiguity - what is the scope of >"each > > > distinct set of server policies"? II::ec called during the >creation > > > of A uses X/1 to determine to "establish" a tagged component, >let's > > > call it TC_X. > > > > I think the scope here was intended to be bounded by the ORB >lifetime. > > It is possible that some other non-POA object adapter happens > > to use the > > exact same effective components, and that the ORB doesn't even >need to > > call II::ec when POA A is created. > > > > > > > > B is then created. We assume II::ec will be called since > > the value of > > > the X policy is different from the previous "set." Another > > ambiguity: > > > does "distinct set" include values or just it just mean types? > > > > I've always intended it to include values. It wouldn't be very >useful > > for it to just mean types, as portable interceptor > > implementations could > > not count on the chance to create the appropriate components for >each > > distinct set of policy values. This may need clarification. > > > > > > > > C is then created and would definitely be invoked since it has a > > > policy of a new type and value which hasn't been seen before. > > > > > > Finally D is created. Since X/1 has been seen before does this >mean > > > that II::ec is not called in this case? That means that >references > > > created by POA D will not contain TC_X although that is what the > > > interceptor writer/POA creator intended when they passed the X/1 > > > policy to create_poa when creating D. > > > > It is up to the ORB vendor to decide whether II::ec will be called >in > > this case. Portable interceptor implemenations cannot assume that >it > > will or will not. This is important because it implies that a >portable > > interceptor can only base its decision of what components to > > include on > > the policies. > > > > But what I think you are missing, and may need clarification, is >that, > > if the ORB does not call II::ec in this case, it still must > > include TC_X > > in the references created with POA D. > > > > > > > > Since II::ec is not called because it has the same distinct set >of > > > policies that were given during the creation of A does this > > mean that > > > the ORB will automatically establish TC_X for references created >by > > > POA D? Further, would the ORB have to remember if the >invocation of > > > II::ec during the creation of A used add_ior_component or > > > add_ior_component_to_profile? > > > > I've never really undestood add_ior_component_to_profile, so I >can't > > comment on that. Our ORB has pluggable transports that may > > use different > > profiles, and generally there is no need for ORB services to > > be aware of > > which transport(s) are in use, so we discourage use of > > add_ior_component_to_profile. But, to answer your question, > > the ORB does > > have to do everything as if II::ec were called for POA D, > > whether or not > > it actually does call it for POA D. > > > > Correct portable interceptor implementations must do the same > > thing for > > the same set of policies, no matter how many times II::ec is > > called for > > that set of policies. Note that this would be required even > > if the ORB > > could be guaranteed to call II::ec for each POA, since the object > > references need to be equivalent for each activation of the > > "same" POA. > > > > > > > > One approach to solving the ambiguity would be to add verbage to > > > clarify the above (and probably other combinations I haven't >thought > > > of at the moment). However, that would result in a subtle, >complex, > > > hard-to-use specification. > > > > I really don't see the problem. > > > > > > > > To me the correct solution is to say that II::ec is called on >each > > > adapter creation. This is simple and intuitive for the user to > > > understand. I can see no technical reason for not taking this > > > approach. During the discussion and straw-poll taken on > > this issue in > > > Oslo nobody dissented with the "call on each adapter" solution. > > > > Unfortunately, I could not be there. The danger of this > > approach is that > > it will lead interceptor implementors into thinking they have the > > freedom to base the components they add in II::ec on things other >than > > the set of effective policies. But doing that would > > potentially lead to > > subtle bugs and degradations due to slightly different sets of > > components being generated each time the "same" POA is >activated. It > > would also potentially lead to the slippery slope of making the > > POACurrent available during this interceptor point, and things >like > > that, which I think we must stay completely clear of. > > > > > > > > Cheers, > > > Harold > > > > -Bob > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 5 Jul 2000 15:20:08 -0700 (PDT) Message-Id: <200007052220.PAA05724@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Content-Type: text X-UIDL: pKW!!2(Ke9Ue3e9~bOe9 I maintain that 21.5.2.1 is ambiguous, impossible to implement, and precludes graceful evolution. It basically says that establish_components is guaranteed to be called at least once for each distinct set of server policies. Ambiguousities (is that a word ;-): A1. What is the scope of this distinct set? (We are converging on ORB scope.) A2. Does distinct set include values? (We are converging on looking at both types and values.) A3. If a second object adapter is created with a set of policies which has already been seen, what happens. Bob has said it is up to the ORB vendor to decide whether to call II::ec - that an IORInterceptor writer cannot assume it will be called. If it isn't called then what is the point of putting in some policies which tell the interceptor to add some components? This leads to the next point. A4. If II:ec is not called explicity for case 3 then Bob says that the ORB will still include TC_X in references created for the "second" adapter. Does the ORB make this inclusion with add_ior_component_to_profile or add_ior_component_to_profiles? Impossibilities: I1. Policies attached to object adapters may be remote objects. It is impossible to determine (remote) object identity so there is no way to determine a distinct set. Evolution: E1. If other objects are exposed in IORInfo (such as an object which can be cast to an object adapter - this is just an example - I am not advocating this - but I have heard people ask for this - please do not flame the example, stick to the general idea) then other operations may be done inside establish_components using the exposed objects. In other words the interceptor would do other work besides add_ior_component_to_profile(s). This type of work cannot be done if the call to II::ec cannot be predicated. There are probably other problems I haven't flushed out. If you know of any, please add to the set. All of these problems are solved if we simply say something like: "establish_components is guaranteed to be called at least once for each Object Adapter created." If you do not agree I think the proper response to this mail is to provide precise wording for section 21.5.2.1 which resolves *ALL* of the above issues. Cheers, Harold Date: Wed, 5 Jul 2000 15:20:42 -0700 (PDT) Message-Id: <200007052220.PAA05794@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Content-Type: text X-UIDL: HF*!!84:!!o39e9hO)!! I maintain that 21.5.2.1 is ambiguous, impossible to implement, and precludes graceful evolution. It basically says that establish_components is guaranteed to be called at least once for each distinct set of server policies. Ambiguousities (is that a word ;-): A1. What is the scope of this distinct set? (We are converging on ORB scope.) A2. Does distinct set include values? (We are converging on looking at both types and values.) A3. If a second object adapter is created with a set of policies which has already been seen, what happens. Bob has said it is up to the ORB vendor to decide whether to call II::ec - that an IORInterceptor writer cannot assume it will be called. If it isn't called then what is the point of putting in some policies which tell the interceptor to add some components? This leads to the next point. A4. If II:ec is not called explicity for case 3 then Bob says that the ORB will still include TC_X in references created for the "second" adapter. Does the ORB make this inclusion with add_ior_component_to_profile or add_ior_component_to_profiles? Impossibilities: I1. Policies attached to object adapters may be remote objects. It is impossible to determine (remote) object identity so there is no way to determine a distinct set. Evolution: E1. If other objects are exposed in IORInfo (such as an object which can be cast to an object adapter - this is just an example - I am not advocating this - but I have heard people ask for this - please do not flame the example, stick to the general idea) then other operations may be done inside establish_components using the exposed objects. In other words the interceptor would do other work besides add_ior_component_to_profile(s). This type of work cannot be done if the call to II::ec cannot be predicated. There are probably other problems I haven't flushed out. If you know of any, please add to the set. All of these problems are solved if we simply say something like: "establish_components is guaranteed to be called at least once for each Object Adapter created." If you do not agree I think the proper response to this mail is to provide precise wording for section 21.5.2.1 which resolves *ALL* of the above issues. Cheers, Harold Date: Wed, 5 Jul 2000 22:22:39 -0230 From: Matthew Newhook To: Harold Carr Cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000705222238.A8829@ooc.com> References: <200007052220.PAA05724@shorter.eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200007052220.PAA05724@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: NJK!!/Qad9S?Ne94XR!! Hi Harold, On Wed, Jul 05, 2000 at 03:20:08PM -0700, Harold Carr wrote: > > I maintain that 21.5.2.1 is ambiguous, impossible to implement, and > precludes graceful evolution. It basically says that > establish_components is guaranteed to be called at least once for each > distinct set of server policies. > > Ambiguousities (is that a word ;-): > > A1. What is the scope of this distinct set? > (We are converging on ORB scope.) I would think the ORB would be the scope, yes. Why is that a problem? > A2. Does distinct set include values? > (We are converging on looking at both types and values.) Yes. > A3. If a second object adapter is created with a set of policies which > has already been seen, what happens. Bob has said it is up to the > ORB vendor to decide whether to call II::ec - that an > IORInterceptor writer cannot assume it will be called. > If it isn't called then what is the point of putting in some > policies which tell the interceptor to add some components? > This leads to the next point. I'm not sure I understand what the problem is. If the II:ec is not called then the components that were established for the previous call are used. > A4. If II:ec is not called explicity for case 3 then Bob says that > the ORB will still include TC_X in references created for the > "second" adapter. Does the ORB make this inclusion with > add_ior_component_to_profile or add_ior_component_to_profiles? Mmm... I don't understand the question. Please give a concrete example ;) > Impossibilities: > > I1. Policies attached to object adapters may be remote objects. > It is impossible to determine (remote) object identity so there > is no way to determine a distinct set. No, that's not the case. Policies are local objects therefore they cannot be remote. > Evolution: > > E1. If other objects are exposed in IORInfo (such as an object which > can be cast to an object adapter - this is just an example - I > am > not advocating this - but I have heard people ask for this - > please do not flame the example, stick to the general idea) then > other operations may be done inside establish_components using > the > exposed objects. In other words the interceptor would do other > work besides add_ior_component_to_profile(s). > > This type of work cannot be done if the call to II::ec cannot > be predicated. Well, if they are then we'll have to rexamine this -- but personally I cannot see whatelse the set of components would be based on other than policies. > There are probably other problems I haven't flushed out. > If you know of any, please add to the set. > > All of these problems are solved if we simply say something like: > "establish_components is guaranteed to be called at least once for > each Object Adapter created." Why provide this guarantee? I _still_ don't see the point... IOR components are based unique policy sets. I simply don't see why we should make any guarantee other than the IORInterceptor is called at least once for all unique policy sets. > If you do not agree I think the proper response to this mail is to > provide precise wording for section 21.5.2.1 which resolves *ALL* of > the above issues. Sorry, but I don't see any issues... > Cheers, > Harold Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 Jul 2000 12:33:37 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation In-Reply-To: <20000705222238.A8829@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -lW!!2/`!!'^Td9KOhd9 Comments interspersed below. -Polar On Wed, 5 Jul 2000, Matthew Newhook wrote: > Hi Harold, > > On Wed, Jul 05, 2000 at 03:20:08PM -0700, Harold Carr wrote: > > > > I maintain that 21.5.2.1 is ambiguous, impossible to implement, > and > > precludes graceful evolution. It basically says that > > establish_components is guaranteed to be called at least once for > each > > distinct set of server policies. > > > > Ambiguousities (is that a word ;-): > > > > A1. What is the scope of this distinct set? > > (We are converging on ORB scope.) > > I would think the ORB would be the scope, yes. Why is that a > problem? I think the problem Harold has with this spec is what does "server policies" mean? The ones applied to the adapter, the ORB, the thread? If you say ORB, then than procludes the ones used on a POA. Anyway, I think the idea is to get rid of the last setence depending on "distinct set of server policies", so let's not dwell on its pendantic nature. > > A2. Does distinct set include values? > > (We are converging on looking at both types and values.) > > Yes. This is a huge problem in complexity that will is inefficient in calculation. First, as I said before, there is no "boolean equals(in CORBA::Policy the_policy)" operation on CORBA::Policy. "is_eqivalent" doesn't have the right semantics. In any case, figuring out whether a list of policies is equal to another is computationally rediculous. > > A3. If a second object adapter is created with a set of policies which > > has already been seen, what happens. Bob has said it is up to the > > ORB vendor to decide whether to call II::ec - that an > > IORInterceptor writer cannot assume it will be called. > > If it isn't called then what is the point of putting in some > > policies which tell the interceptor to add some components? > > This leads to the next point. > > I'm not sure I understand what the problem is. If the II:ec is not > called then the components that were established for the previous call are > used. The problem is not when II:ec is not called, the problem is when should it be called. > > A4. If II:ec is not called explicity for case 3 then Bob says that > > the ORB will still include TC_X in references created for the > > "second" adapter. Does the ORB make this inclusion with > > add_ior_component_to_profile or add_ior_component_to_profiles? > > Mmm... I don't understand the question. Please give a concrete > > example > ;) > > > Impossibilities: > > > > I1. Policies attached to object adapters may be remote objects. > > It is impossible to determine (remote) object identity so > > there > > is no way to determine a distinct set. > > No, that's not the case. Policies are local objects therefore they > cannot be remote. No, that is not the case. CORBA::Policy is not required to be a local object. We have them in Security and they are locality constrained objects and remote objects. > > Evolution: > > > > E1. If other objects are exposed in IORInfo (such as an object > > which > > can be cast to an object adapter - this is just an example - I > > am > > not advocating this - but I have heard people ask for this - > > please do not flame the example, stick to the general idea) > > then > > other operations may be done inside establish_components using > > the > > exposed objects. In other words the interceptor would do > > other > > work besides add_ior_component_to_profile(s). > > > > This type of work cannot be done if the call to II::ec cannot > > be predicated. > > Well, if they are then we'll have to rexamine this -- but personally > I cannot see whatelse the set of components would be based on other > than policies. > > > There are probably other problems I haven't flushed out. > > If you know of any, please add to the set. > > > > All of these problems are solved if we simply say something like: > > "establish_components is guaranteed to be called at least once for > > each Object Adapter created." > > Why provide this guarantee? I _still_ don't see the point... IOR > components are based unique policy sets. I simply don't see why we > > should > make any guarantee other than the IORInterceptor is called at least > > once > for all unique policy sets. Components are based on unique policy sets, provide that the policies contain static values. Not all policies do. However, for security, we said that we would, for the POA only, restrict policies used for security (such as a set of credentials to be associated with object references) to a single POA. This seems to work for us in the POA model. BTW, as far as finding out the complexity of determining distinct policy sets by their values, there is no "equals" operation on Credentials. Credentials are the "value" of that policy, so how do you determine if two credentials policies are equal or distinct? I think Bob wants the possibility for other adapters other than the POA. There is the BOA, like it or not. Some ORBs, the BOA is created once and only once, no matter how many object references are created from it. So II:ec would have to be called there for every object reference, since each object may have different policies associated with its connection to the BOA. Saying that "II:ec will be called at least once per adapter creation" is not violated by that approach. The bottom line is that it needs to be called. And it is better that the interceptor do the determination of what needs to be called. To solve this problem, we can put an attribute on the interceptor stating when it should be called, adapter creation, every object reference creation, at most once, etc. > > If you do not agree I think the proper response to this mail is to > > provide precise wording for section 21.5.2.1 which resolves *ALL* > > of > > the above issues. > > Sorry, but I don't see any issues... > > > Cheers, > > Harold > > Regards, Matthew > -- > Matthew Newhook E-Mail: > > mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 6 Jul 2000 14:12:47 -0230 From: Matthew Newhook To: Polar Humenn Cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000706141247.A14754@ooc.com> References: <20000705222238.A8829@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: 7V0!!-kR!!cbn!!K=]d9 Hi, On Thu, Jul 06, 2000 at 12:33:37PM -0400, Polar Humenn wrote: >[...] > > I would think the ORB would be the scope, yes. Why is that a problem? > > I think the problem Harold has with this spec is what does "server > policies" mean? The ones applied to the adapter, the ORB, the thread? IMO, the object-adapter. >[...] > > I'm not sure I understand what the problem is. If the II:ec is not > > called then the components that were established for the previous call are > > used. > > The problem is not when II:ec is not called, the problem is when should it > be called. I still don't understand -- it's called on the first set of unique policies. >[...] > > > Impossibilities: > > > > > > I1. Policies attached to object adapters may be remote objects. > > > It is impossible to determine (remote) object identity so there > > > is no way to determine a distinct set. > > > > No, that's not the case. Policies are local objects therefore they > > cannot be remote. > > No, that is not the case. CORBA::Policy is not required to be a local > object. We have them in Security and they are locality constrained objects > and remote objects. I stand corrected -- the components spec says "... * All the interfaces in the Messaging module that inherit CORBA::Policy", not CORBA::Policy itself. >[...] > > components are based unique policy sets. I simply don't see why we should > > make any guarantee other than the IORInterceptor is called at least once > > for all unique policy sets. > > Components are based on unique policy sets, provide that the policies > contain static values. Not all policies do. Ummm... really? I've always considered policies to be immutable -- they generally carry readonly values. If policies are not immutable doesn't this present a serious problem? Namely that the set of components for an IOR would vary over time -- and would not be fixed for a particular POA. Perhaps I misunderstand you? > [...] > To solve this problem, we can put an attribute on the interceptor > stating > when it should be called, adapter creation, every object reference > creation, at most once, etc. I don't like that. Anything that requires calling the interceptor for every object reference is terrible terrible terrible (yes, saying it three times makes it more correct! ;) >[...] > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 Jul 2000 14:32:20 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation In-Reply-To: <20000706141247.A14754@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: d*gd9IU2e9oWUd9o$fd9 On Thu, 6 Jul 2000, Matthew Newhook wrote: > Hi, > > On Thu, Jul 06, 2000 at 12:33:37PM -0400, Polar Humenn wrote: > >[...] > > > I would think the ORB would be the scope, yes. Why is that a > problem? > > > > I think the problem Harold has with this spec is what does "server > > policies" mean? The ones applied to the adapter, the ORB, the > thread? > > IMO, the object-adapter. Okay. > >[...] > > > I'm not sure I understand what the problem is. If the II:ec is not > > > called then the components that were established for the previous call are > > > used. > > > > The problem is not when II:ec is not called, the problem is when should it > > be called. > > I still don't understand -- it's called on the first set of unique > policies. How do you determine the "uniqueness"? > >[...] > > > components are based unique policy sets. I simply don't see why we should > > > make any guarantee other than the IORInterceptor is called at least once > > > for all unique policy sets. > > > > Components are based on unique policy sets, provide that the policies > > contain static values. Not all policies do. > > Ummm... really? I've always considered policies to be immutable -- they > generally carry readonly values. If policies are not immutable doesn't > this present a serious problem? Namely that the set of components for > an IOR would vary over time -- and would not be fixed for a particular > POA. Perhaps I misunderstand you? Well, those policies that have "attributes", I would probably agree. However, since all policies are allowed, then some policies may have parameterized values, i.e. operations. How would you tell if their operations were equal? (in general, of course, is proven to be impossible! :) > > [...] > > To solve this problem, we can put an attribute on the interceptor > > stating > > when it should be called, adapter creation, every object reference > > creation, at most once, etc. > > I don't like that. Anything that requires calling the interceptor > > for > every object reference is terrible terrible terrible (yes, saying it > three times makes it more correct! ;) But if the interceptor specifies that it should be called per object creation, what's the problem? If it is a necessity for the interceptor, then at least it has control over its own call semantics, instead of GUESSING what the ORB is going to do. I think a call semantic controlled by the interceptor at the time of interceptor installation might be a big boon to solving issue 1. At Most Once 2. At Object Adapter Creation 3. At Object Reference Creation Then the interceptor controls when the call will happened and there are no more questions. Just my 2 cents. -Polar > >[...] > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > Regards, Matthew > -- > Matthew Newhook E-Mail: > >mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 6 Jul 2000 16:03:45 -0230 From: Matthew Newhook To: Polar Humenn Cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000706160345.A15720@ooc.com> References: <20000706141247.A14754@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: ]9od9L;Wd9Bfj!!2Y2e9 Hi Polar, On Thu, Jul 06, 2000 at 02:32:20PM -0400, Polar Humenn wrote: >[...] > > I still don't understand -- it's called on the first set of unique > > policies. > > How do you determine the "uniqueness"? If all of the policies that were created were under the ORB control then the ORB can determine that. >[..] > Well, those policies that have "attributes", I would probably agree. > However, since all policies are allowed, then some policies may have > parameterized values, i.e. operations. How would you tell if their > operations were equal? (in general, of course, is proven to be >impossible! > :) Personally, I'm of the view that this is a corruption of the Policy idea. Object references are immutable. Object references have a fixed set of policies, which also should be immutable. If a fixed policy can change over time then I think that many assumptions that most ORBs make are invalid. >[...] > > I don't like that. Anything that requires calling the interceptor for > > every object reference is terrible terrible terrible (yes, saying it > > three times makes it more correct! ;) > > But if the interceptor specifies that it should be called per object > creation, what's the problem? If it is a necessity for the interceptor, > then at least it has control over its own call semantics, instead of > GUESSING what the ORB is going to do. > > I think a call semantic controlled by the interceptor at the time of > interceptor installation might be a big boon to solving issue > > 1. At Most Once > 2. At Object Adapter Creation > 3. At Object Reference Creation > > Then the interceptor controls when the call will happened and there are no > more questions. You assume that it's easy to hook interceptors into object-reference creation. What if the ORB itself doesn't actually create object-references (perhaps something else, like an IMR does this). By this you have architecturally bound every ORB to satisify some dubious requirement. I don't like that. > Just my 2 cents. > -Polar > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 Jul 2000 14:57:30 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation In-Reply-To: <20000706160345.A15720@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: CPJe9po""!]=6e9~S\d9 On Thu, 6 Jul 2000, Matthew Newhook wrote: > Hi Polar, > > On Thu, Jul 06, 2000 at 02:32:20PM -0400, Polar Humenn wrote: > >[...] > > > I still don't understand -- it's called on the first set of > unique > > > policies. > > > > How do you determine the "uniqueness"? > > If all of the policies that were created were under the ORB control > then > the ORB can determine that. > > >[..] > > Well, those policies that have "attributes", I would probably > agree. > > However, since all policies are allowed, then some policies may > have > > parameterized values, i.e. operations. How would you tell if their > > operations were equal? (in general, of course, is proven to be > impossible! > > :) > > Personally, I'm of the view that this is a corruption of the Policy > idea. Object references are immutable. Object references have a > fixed > set of policies, which also should be immutable. If a fixed policy > can > change over time then I think that many assumptions that most ORBs > make > are invalid. I'm not saying that they vary over time, but some policies have operations that take parameters, of which given the same inputs, output the same answers, for all time. However, figuring out whether those two policies of that nature are equal by evaluation is impossible, in general. Therefore, you cannot determine whether two list of policies are actually not distinct, in general. > >[...] > > > I don't like that. Anything that requires calling the interceptor for > > > every object reference is terrible terrible terrible (yes, saying it > > > three times makes it more correct! ;) > > > > But if the interceptor specifies that it should be called per object > > creation, what's the problem? If it is a necessity for the interceptor, > > then at least it has control over its own call semantics, instead of > > GUESSING what the ORB is going to do. > > > > I think a call semantic controlled by the interceptor at the time of > > interceptor installation might be a big boon to solving issue > > > > 1. At Most Once > > 2. At Object Adapter Creation > > 3. At Object Reference Creation > > > > Then the interceptor controls when the call will happened and there are no > > more questions. > > You assume that it's easy to hook interceptors into object-reference > creation. What if the ORB itself doesn't actually create object-references > (perhaps something else, like an IMR does this). If the object reference isn't created by the adapter, then we aren't worried about it, right? We are only worried about intercepting the object references created by the adapter. > By this you have architecturally bound every ORB to satisify some dubious > requirement. I don't like that. Maybe so in that case. So, what would be an alternative? For the ORB to list its capabilities and have the interceptor choose which model it can deal with? If the ORB doesn't have the capability to call on the II:ec for every object reference, and the inteceptor asks for it, can't this be some sort of initialziation exception? > > Just my 2 cents. > > -Polar > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 6 Jul 2000 16:32:51 -0230 From: Matthew Newhook To: Polar Humenn Cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000706163251.A16112@ooc.com> References: <20000706160345.A15720@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: dp5e98C8e9JcM!!g3e!! Hi Polar, On Thu, Jul 06, 2000 at 02:57:30PM -0400, Polar Humenn wrote: > > [...] > > Personally, I'm of the view that this is a corruption of the Policy > > idea. Object references are immutable. Object references have a fixed > > set of policies, which also should be immutable. If a fixed policy can > > change over time then I think that many assumptions that most ORBs make > > are invalid. > > I'm not saying that they vary over time, but some policies have operations > that take parameters, of which given the same inputs, output the same > answers, for all time. However, figuring out whether those two policies of > that nature are equal by evaluation is impossible, in general. Therefore, > you cannot determine whether two list of policies are actually not > distinct, in general. Ok, for that particular type of Policy, yes you are correct. However, the point still remains: For policies that are created strictly by the ORB uniqueness can be determined fairly easily. >[...] > > You assume that it's easy to hook interceptors into object-reference > > creation. What if the ORB itself doesn't actually create object-references > > (perhaps something else, like an IMR does this). > > If the object reference isn't created by the adapter, then we aren't > worried about it, right? I don't think that's right. > We are only worried about intercepting the object references created by > the adapter. The references are created on behalf of the adapter -- however, the entity that actually creates them may not be the adapter itself. > > By this you have architecturally bound every ORB to satisify some dubious > > requirement. I don't like that. > > Maybe so in that case. So, what would be an alternative? For the ORB to > list its capabilities and have the interceptor choose which model it can > deal with? > > If the ORB doesn't have the capability to call on the II:ec for every > object reference, and the inteceptor asks for it, can't this be some sort > of initialziation exception? I don't think that's such a good idea. Personally, I don't see why we need interception on reference creation. The spec as it is right now said that the IORInterceptors can affect the set of components that go into an IOR based on some unique set of object-adapter policies. Therefore we are basically scoped at the object-adapter? What is wrong with that? > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 6 Jul 2000 16:51:33 -0230 From: Matthew Newhook To: Polar Humenn Cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000706165132.A16277@ooc.com> References: <20000706163251.A16112@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: Me,!!AYNd9)NQe9d$(!! Hi, On Thu, Jul 06, 2000 at 03:24:00PM -0400, Polar Humenn wrote: >[...] > > Ok, for that particular type of Policy, yes you are correct. However, > > the point still remains: For policies that are created strictly by the > > ORB uniqueness can be determined fairly easily. > > I still don't see that. You can ask the ORB to create the same policy > twice. For the ORB to determine whether the two policies are the same by > value. That would mean that the ORB has to keep a history of every policy > it has been told to create. Why is that? Given that I know the policy type I can do anything I like -- such as implement a proprietary equals type method. >[...] > -Polar > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 Jul 2000 15:24:00 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation In-Reply-To: <20000706163251.A16112@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: h1Oe9oDGe9Wn'!!0X*!! On Thu, 6 Jul 2000, Matthew Newhook wrote: > Hi Polar, > > On Thu, Jul 06, 2000 at 02:57:30PM -0400, Polar Humenn wrote: > > > [...] > > > Personally, I'm of the view that this is a corruption of the > Policy > > > idea. Object references are immutable. Object references have a > fixed > > > set of policies, which also should be immutable. If a fixed > policy can > > > change over time then I think that many assumptions that most > ORBs make > > > are invalid. > > > > I'm not saying that they vary over time, but some policies have > operations > > that take parameters, of which given the same inputs, output the > same > > answers, for all time. However, figuring out whether those two > policies of > > that nature are equal by evaluation is impossible, in > general. Therefore, > > you cannot determine whether two list of policies are actually not > > distinct, in general. > > Ok, for that particular type of Policy, yes you are > correct. However, > the point still remains: For policies that are created strictly by > the > ORB uniqueness can be determined fairly easily. I still don't see that. You can ask the ORB to create the same policy twice. For the ORB to determine whether the two policies are the same by value. That would mean that the ORB has to keep a history of every policy it has been told to create. > >[...] > > > You assume that it's easy to hook interceptors into object-reference > > > creation. What if the ORB itself doesn't actually create object-references > > > (perhaps something else, like an IMR does this). > > > > If the object reference isn't created by the adapter, then we aren't > > worried about it, right? > > I don't think that's right. > > > We are only worried about intercepting the object references created by > > the adapter. > > The references are created on behalf of the adapter -- however, the > entity that actually creates them may not be the adapter itself. Okay. But are we really concerned about that? If they are created on behalf of the adapter, logically, the adapter is untimately responsible for them, correct? You would think that the adapter asks this other entity to create an object with such values, of which it gets by calling II:ec before asking the entity to create one. > > > By this you have architecturally bound every ORB to satisify some dubious > > > requirement. I don't like that. > > > > Maybe so in that case. So, what would be an alternative? For the ORB to > > list its capabilities and have the interceptor choose which model it can > > deal with? > > > > If the ORB doesn't have the capability to call on the II:ec for every > > object reference, and the inteceptor asks for it, can't this be some sort > > of initialziation exception? > > I don't think that's such a good idea. Personally, I don't see why we > need interception on reference creation. Like I said, if you have a BOA and you connect different objects to the BOA to create object references. Anyway, it's only a point of discussion about how it may operate. I think that saying that it is called "at least once" upon object adapter creation would be more than sufficient. If an ORB vendor wants to call it on every object reference creation, then so be it. > The spec as it is right now said > that the IORInterceptors can affect the set of components that go > into > an IOR based on some unique set of object-adapter > policies. Therefore > we are basically scoped at the object-adapter? What is wrong with > that? Yes, scoped at the object-adapter where possible. There is no such case with a BOA. No big deal. The Unique set property seems problematic to me, especially if it is unique by value of the policies. -Polar > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 Jul 2000 15:28:33 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation In-Reply-To: <20000706165132.A16277@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2oOd9,?J!!eL\d958F!! On Thu, 6 Jul 2000, Matthew Newhook wrote: > Hi, > > On Thu, Jul 06, 2000 at 03:24:00PM -0400, Polar Humenn wrote: > >[...] > > > Ok, for that particular type of Policy, yes you are > correct. However, > > > the point still remains: For policies that are created strictly > by the > > > ORB uniqueness can be determined fairly easily. > > > > I still don't see that. You can ask the ORB to create the same > policy > > twice. For the ORB to determine whether the two policies are the > same by > > value. That would mean that the ORB has to keep a history of every > policy > > it has been told to create. > > Why is that? Given that I know the policy type I can do anything I > like -- ^^^^^^^^^^^^^^^^^^^^^^ > such as implement a proprietary equals type method. And when you *DONT KNOW* the policy type? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 6 Jul 2000 18:00:04 -0230 From: Matthew Newhook To: Polar Humenn Cc: interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000706180004.A16554@ooc.com> References: <20000706165132.A16277@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: G*Je9&P^d93:~e9Y?ed9 Hi, On Thu, Jul 06, 2000 at 03:28:33PM -0400, Polar Humenn wrote: > On Thu, 6 Jul 2000, Matthew Newhook wrote: > > > Hi, > > > > On Thu, Jul 06, 2000 at 03:24:00PM -0400, Polar Humenn wrote: > > >[...] > > > > Ok, for that particular type of Policy, yes you are correct. However, > > > > the point still remains: For policies that are created strictly by the > > > > ORB uniqueness can be determined fairly easily. > > > > > > I still don't see that. You can ask the ORB to create the same policy > > > twice. For the ORB to determine whether the two policies are the same by > > > value. That would mean that the ORB has to keep a history of every policy > > > it has been told to create. > > > > Why is that? Given that I know the policy type I can do anything I like -- > ^^^^^^^^^^^^^^^^^^^^^^ > > such as implement a proprietary equals type method. > > And when you *DONT KNOW* the policy type? Like I said in my previous mail -- obviously this only applies when the ORB creates the policy directly. > -Polar > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 06 Jul 2000 14:02:43 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: k-M!!bV8!! I've read all the exchanges regarding this. The show stopper is still: in general, there is no portable way to determine a unique policy set. Therefore, the wording: "establish_components is guaranteed to be called at least once for each Object Adapter created." is still a simple solution that solves the problem. It is also easier for the end user to reason about. Could someone tell say if there is a technical problem is with calling EC on each adapter creation? Thanks, Harold Date: Thu, 06 Jul 2000 14:15:14 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <200007052220.PAA05724@shorter.eng.sun.com> <20000705222238.A8829@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3Oad9Em5e9@T#e9#fjd9 Matthew Newhook wrote: > > A4. If II:ec is not called explicity for case 3 then Bob says that > > the ORB will still include TC_X in references created for the > > "second" adapter. Does the ORB make this inclusion with > > add_ior_component_to_profile or add_ior_component_to_profiles? > > Mmm... I don't understand the question. Please give a concrete > > example > ;) OK. This is from the mail I sent last week. Consider: Four (and only four) POAs, A, B, C, D, are created somewhere within the scope of a particular rootPOA in a particular ORB instance. The following policies are given to create_poa when the POAs are created in the listed order: A - X/1 - means policy X with a value of 1. B - X/2 C - Y/3 D - X/1 IORInterceptor::establish_components (called II::ec for the rest of the discussion) is called when A is created. We assume it will be called since this is the first POA created under this particular rootPOA. II::ec called during the creation of A uses X/1 to determine to "establish" a tagged component, let's call it TC_X. B is then created. We assume II::ec will be called since the value of the X policy is different from the previous "set." C is then created and would definitely be invoked since it has a policy of a new type and value which hasn't been seen before. Finally D is created. Since X/1 has been seen before does this mean that II::ec is not called in this case? That means that references created by POA D will not contain TC_X although that is what the interceptor writer/POA creator intended when they passed the X/1 policy to create_poa when creating D. Since II::ec is not called because it has the same distinct set of policies that were given during the creation of A does this mean that the ORB will automatically establish TC_X for references created by POA D? Further, would the ORB have to remember if the invocation of II::ec during the creation of A used add_ior_component or add_ior_component_to_profile? Cheers, Harold ps: I still feel that it would be useful if response could either agree that calling on adapter creation works OR start sending wording to be added to the spec to clarify the issues. Date: Thu, 6 Jul 2000 18:50:55 -0230 From: Matthew Newhook To: Harold Carr Cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000706185055.B16847@ooc.com> References: <200007052220.PAA05724@shorter.eng.sun.com> <20000705222238.A8829@ooc.com> <3964F6E2.E55D6567@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3964F6E2.E55D6567@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: (jHe9WBX!!p@U!!Bj2!! Hi, On Thu, Jul 06, 2000 at 02:15:14PM -0700, Harold Carr wrote: >[...] > > Mmm... I don't understand the question. Please give a concrete example > > ;) > > OK. This is from the mail I sent last week. > > Consider: > > Four (and only four) POAs, A, B, C, D, are created somewhere within > the scope of a particular rootPOA in a particular ORB instance. > > The following policies are given to create_poa when the POAs are > created in the listed order: > > A - X/1 - means policy X with a value of 1. > B - X/2 > C - Y/3 > D - X/1 > > IORInterceptor::establish_components (called II::ec for the rest of > the discussion) is called when A is created. We assume it will be > called since this is the first POA created under this particular > rootPOA. II::ec called during the creation > of A uses X/1 to determine to "establish" a tagged component, let's > call it TC_X. > > B is then created. We assume II::ec will be called since the value of > the X policy is different from the previous "set." > > C is then created and would definitely be invoked since it has a > policy of a new type and value which hasn't been seen before. > > Finally D is created. Since X/1 has been seen before does this mean > that II::ec is not called in this case? That means that references > created by POA D will not contain TC_X although that is what the It doesn't mean that -- the ORB has to use the components that were established in the previous call. > interceptor writer/POA creator intended when they passed the X/1 > policy to create_poa when creating D. > > Since II::ec is not called because it has the same distinct set of > policies that were given during the creation of A does this mean > that > the ORB will automatically establish TC_X for references created by > POA D? Yes. > Further, would the ORB have to remember if the invocation of > II::ec during the creation of A used add_ior_component or > add_ior_component_to_profile? What difference does that make? The IOR "template" that the IOR interceptor created for POA A must be used to create IORs for POA D. > > Cheers, > Harold > > ps: I still feel that it would be useful if response could either > agree > that calling on adapter creation works OR start sending wording to > be > added to the spec to clarify the issues. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 06 Jul 2000 14:32:29 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <200007052220.PAA05724@shorter.eng.sun.com> <20000705222238.A8829@ooc.com> <3964F6E2.E55D6567@sun.com> <20000706185055.B16847@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $16!!>4W!!=Eld9I+5!! If there were some way to portably determine a unique policy set then the specification would need to be augmented to specify the points raised in the discussion below. But first "uniqueness" needs to be solved. CHeers, H Matthew Newhook wrote: > > Hi, > > On Thu, Jul 06, 2000 at 02:15:14PM -0700, Harold Carr wrote: > >[...] > > > Mmm... I don't understand the question. Please give a concrete example > > > ;) > > > > OK. This is from the mail I sent last week. > > > > Consider: > > > > Four (and only four) POAs, A, B, C, D, are created somewhere within > > the scope of a particular rootPOA in a particular ORB instance. > > > > The following policies are given to create_poa when the POAs are > > created in the listed order: > > > > A - X/1 - means policy X with a value of 1. > > B - X/2 > > C - Y/3 > > D - X/1 > > > > IORInterceptor::establish_components (called II::ec for the rest of > > the discussion) is called when A is created. We assume it will be > > called since this is the first POA created under this particular > > rootPOA. II::ec called during the creation > > of A uses X/1 to determine to "establish" a tagged component, let's > > call it TC_X. > > > > B is then created. We assume II::ec will be called since the value of > > the X policy is different from the previous "set." > > > > C is then created and would definitely be invoked since it has a > > policy of a new type and value which hasn't been seen before. > > > > Finally D is created. Since X/1 has been seen before does this mean > > that II::ec is not called in this case? That means that references > > created by POA D will not contain TC_X although that is what the > > It doesn't mean that -- the ORB has to use the components that were > established in the previous call. > > > interceptor writer/POA creator intended when they passed the X/1 > > policy to create_poa when creating D. > > > > Since II::ec is not called because it has the same distinct set of > > policies that were given during the creation of A does this mean that > > the ORB will automatically establish TC_X for references created by > > POA D? > > Yes. > > > Further, would the ORB have to remember if the invocation of > > II::ec during the creation of A used add_ior_component or > > add_ior_component_to_profile? > > What difference does that make? The IOR "template" that the IOR > interceptor created for POA A must be used to create IORs for POA D. > > > > > Cheers, > > Harold > > > > ps: I still feel that it would be useful if response could either agree > > that calling on adapter creation works OR start sending wording to be > > added to the spec to clarify the issues. > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 6 Jul 2000 19:18:42 -0230 From: Matthew Newhook To: Harold Carr Cc: Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation Message-ID: <20000706191841.A17360@ooc.com> References: <200007052220.PAA05724@shorter.eng.sun.com> <20000705222238.A8829@ooc.com> <3964F6E2.E55D6567@sun.com> <20000706185055.B16847@ooc.com> <3964FAED.6907F6A6@sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3964FAED.6907F6A6@sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: D>/e9dfLe9>cRd99:=!! Hi, On Thu, Jul 06, 2000 at 02:32:29PM -0700, Harold Carr wrote: > If there were some way to portably determine a unique policy set then > the specification would need to be augmented to specify the points > raised in the discussion below. But first "uniqueness" needs to be > solved. I'm not entirely sure why that needs to be solved. Why is that important? This seems to be going round in circles. All that should be important to the interceptor writer is that the interceptors are called for each unique policy set. > CHeers, > H Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 06 Jul 2000 17:58:01 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr CC: Polar Humenn , Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <3964F3F3.6832650F@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: fY9!!O:L!!CGi!!M/(e9 Harold Carr wrote: > > I've read all the exchanges regarding this. The show stopper is still: > in general, there is no portable way to determine a unique policy set. This is not a show stopper because there is no requirement for any portable code to determine a unique policy set. The submission was worded as it was here to allow ORB vendors the freedom to optimize for performance and scalability. > Therefore, the wording: > > "establish_components is guaranteed to be called at least once for > each Object Adapter created." > > is still a simple solution that solves the problem. It is also > easier > for the end user to reason about. The Portable Interceptor user has no business knowing when an object adapter is created. That user should not even assume the object adapter is an implementation of the POA. > > Could someone tell say if there is a technical problem is with > calling > EC on each adapter creation? ORBs are free to call establish_components for each POA creation. But I see no compelling reason to require them to do this. My biggest problem with your proposed change is that it would encourage Portable Interceptor users to implement establish_components operations that base the components on something other than just the effective server side policies. This is problematic in that "different" IORs would be created by different activations of the "same" POA. We need to encourage (or even require) implementors to make the selection of components generated by establish_components purely a function of the effective server side policies. If they do so, then different activations of the "same" POA will have the same IORs. If they follow this rule, it won't matter whether the ORB calls establish_components for each POA creation/activation, or optimizes this in some way, or even uses some non-POA OA. > > Thanks, > Harold -Bob Date: Thu, 06 Jul 2000 15:01:47 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kukura CC: Polar Humenn , Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation References: <3964F3F3.6832650F@sun.com> <396500E9.D07C541F@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: P'e!!\ee!!l>$e9F*L!! Well, then, as I said in mail yesterday which summarized problems, please respond with specific text to be added/deleted/changed in the current specification to clarify the issues. H Bob Kukura wrote: > > Harold Carr wrote: > > > > I've read all the exchanges regarding this. The show stopper is still: > > in general, there is no portable way to determine a unique policy set. > > This is not a show stopper because there is no requirement for any > portable code to determine a unique policy set. The submission was > worded as it was here to allow ORB vendors the freedom to optimize for > performance and scalability. > > > Therefore, the wording: > > > > "establish_components is guaranteed to be called at least once for > > each Object Adapter created." > > > > is still a simple solution that solves the problem. It is also easier > > for the end user to reason about. > > The Portable Interceptor user has no business knowing when an object > adapter is created. That user should not even assume the object adapter > is an implementation of the POA. > > > > > Could someone tell say if there is a technical problem is with calling > > EC on each adapter creation? > > ORBs are free to call establish_components for each POA creation. But I > see no compelling reason to require them to do this. > > My biggest problem with your proposed change is that it would encourage > Portable Interceptor users to implement establish_components operations > that base the components on something other than just the effective > server side policies. This is problematic in that "different" IORs would > be created by different activations of the "same" POA. > > We need to encourage (or even require) implementors to make the > selection of components generated by establish_components purely a > function of the effective server side policies. If they do so, then > different activations of the "same" POA will have the same IORs. If they > follow this rule, it won't matter whether the ORB calls > establish_components for each POA creation/activation, or optimizes this > in some way, or even uses some non-POA OA. > > > > > Thanks, > > Harold > > -Bob X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 Jul 2000 18:13:02 -0400 (EDT) From: Polar Humenn To: Bob Kukura cc: Harold Carr , Matthew Newhook , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation In-Reply-To: <396500E9.D07C541F@iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: g<[d9WlDe9b*-!!m_7e9 On Thu, 6 Jul 2000, Bob Kukura wrote: > We need to encourage (or even require) implementors to make the > selection of components generated by establish_components purely a > function of the effective server side policies. Fine. But what do you mean by "effective server side policies"? And how in general does the ORB know, in general, when the effective server side policies are not distinct? > different activations of the "same" POA will have the same IORs. If > they follow this rule, it won't matter whether the ORB calls > establish_components for each POA creation/activation, or optimizes > this in some way, or even uses some non-POA OA. It would be nice to follow the rule, if we know the following criteria: What exactly constitutes/specifies a distinct set of server side policies? Cheers, -Polar > > > > > Thanks, > > Harold > > -Bob > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 Jul 2000 18:35:10 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Harold Carr , Harold Carr , interceptors-ftf@omg.org Subject: Re: Issue 3663: IORInterceptor invoked on each Object Adapter Creation In-Reply-To: <20000706191841.A17360@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K&"!!(> Hi, > > On Thu, Jul 06, 2000 at 02:32:29PM -0700, Harold Carr wrote: > > If there were some way to portably determine a unique policy set > then > > the specification would need to be augmented to specify the points > > raised in the discussion below. But first "uniqueness" needs to > be > > solved. > > I'm not entirely sure why that needs to be solved. Why is that > important? This seems to be going round in circles. All that should > be > important to the interceptor writer is that the interceptors are > called > for each unique policy set. Okay, let me take a slightly different tact on this. Uniqueness doesn't have to be "solved". It simply has to be DEFINED. So, define a "unique server side policy set". Lay it all down, so I know EMPHATICALLY when I write an interceptor I know when it's going to get called. I, as an interceptor writer, want to follow a specification, and know actally how I must code things. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Issue 3633: Request clarification for use of alias typecodes in typedef helper classes ------------------------------------------------------------------------------------------- Summary: I've noticed that there appears to be a lack of consistency between ORB vendors when it comes to the use of alias typecodes in Java helper classes generated for IDL typedefs. Specifically, both Visibroker 4 and Orbix 2000 return an appropriate alias typecode from the helper class's type () method. However, the Visibroker 4 generated helper class does not use it in either the insert or extract methods, whilst the Orbix 2000 helper class uses it to set the typecode of the Any passed to the insert method and to check that the Any passed to the extract method is of the correct type. Would it be possible to clarify which of these approaches is correct? From the specification of the IDL to Java mapping, it appears that typdef types are intended to be 'unwound' to the first non-typedef type, which would suggest that the first approach is OK. However, if this is the case, for what purpose is the alias typecode produced, if not for the setting/checking of typecodes of Anys containing instances of the associated type? Discussion: Either approach appears to be valid, especially since the typecode equality semantics simply unwind tk_alias typecodes until they reach a non-tk_alias typecode. I think no change is needed here. Proposed Resolution: Close no change.