>Date: Mon, 15 May 2000 23:12:12 +1000 (EST) From: Michi Henning To: butek@us.ibm.com cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <852568E0.00462C85.00@d54mta08.raleigh.ibm.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: =0gd9_f7!!~1Z!!PTl!! On Mon, 15 May 2000 butek@us.ibm.com wrote: > > > The following are the remaining issues that the Interceptors FTF > must > resolve. Please lend a hand and volunteer a resolution for your > favorite. > The details can be found at > http://www.omg.org/issues/interceptors-ftf.html. > > Issue 3322: Portable Interceptors: object_to_string, > string_to_object (goes > away if 3403 is addressed) > Issue 3403: PI needs the ORB to be available in IDL > Issue 3429: ORBInitInfo needs the ORB > Issue 3435: Interceptors and finalization > Issue 3545: org.omg.PortableInterceptor.ORBInitializerClass.XXX on > command > line? > Issue 3598: Java mapping of register_orb_initializer > Issue 3599: Detail lacking in when request interceptors are called Russell, I didn't open a separate issue for it, because I wanted opinions first. However, the answers are still outstanding, so I think we have an issue: it appears to be impossible to portably attach OTS policies to POAs with the machinery that is currently in place. We need a fix for that, otherwise OTS ends up getting hamstrung... Cheers, Michi. Date: Mon, 15 May 2000 11:09:16 -0230 From: Matthew Newhook To: Michi Henning Cc: butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Message-ID: <20000515110916.A25925@ooc.com> References: <852568E0.00462C85.00@d54mta08.raleigh.ibm.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: 8fG!!Kn~!!*gK!!F4b!! Hi Michi, On Mon, May 15, 2000 at 11:12:12PM +1000, Michi Henning wrote: > Russell, I didn't open a separate issue for it, because I wanted opinions > first. However, the answers are still outstanding, so I think we have > an issue: it appears to be impossible to portably attach OTS policies > to POAs with the machinery that is currently in place. We need a fix for > that, otherwise OTS ends up getting hamstrung... Can you elaborate? You can create new policies, and these can be placed on atribrary POAs in POA::create_POA. These policies can them influence various things, including the components that are placed in IORs, and requests made on objects within that POA. What is needed that isn't in place? > Cheers, > > Michi. 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: Mon, 15 May 2000 10:39:24 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Michi Henning , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <20000515110916.A25925@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9aD!!%iEe9dj;!!";O!! On Mon, 15 May 2000, Matthew Newhook wrote: > Hi Michi, > > On Mon, May 15, 2000 at 11:12:12PM +1000, Michi Henning wrote: > > Russell, I didn't open a separate issue for it, because I wanted > opinions > > first. However, the answers are still outstanding, so I think we > have > > an issue: it appears to be impossible to portably attach OTS > policies > > to POAs with the machinery that is currently in place. We need a > fix for > > that, otherwise OTS ends up getting hamstrung... > > Can you elaborate? You can create new policies, and these can be > placed > on atribrary POAs in POA::create_POA. These policies can them > influence > various things, including the components that are placed in IORs, > and > requests made on objects within that POA. What is needed that isn't > in place? One thing that may be of issue, is that is it portably impossible to locate a POA and a Servant from the information given in the adapter_id, and object_id. Cheers, -Polar > > > Cheers, > > > > Michi. > > 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 Sender: jon@corvette.floorboard.com Message-ID: <39201057.CECD49A1@floorboard.com> Date: Mon, 15 May 2000 07:57:27 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Michi Henning , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <852568E0.00462C85.00@d54mta08.raleigh.ibm.com> <20000515110916.A25925@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &VG!!#iQ!!Jc>e9J56!! Matthew Newhook wrote: > > Hi Michi, > > On Mon, May 15, 2000 at 11:12:12PM +1000, Michi Henning wrote: > > Russell, I didn't open a separate issue for it, because I wanted opinions > > first. However, the answers are still outstanding, so I think we have > > an issue: it appears to be impossible to portably attach OTS policies > > to POAs with the machinery that is currently in place. We need a fix for > > that, otherwise OTS ends up getting hamstrung... > > Can you elaborate? You can create new policies, and these can be placed > on atribrary POAs in POA::create_POA. These policies can them influence > various things, including the components that are placed in IORs, and > requests made on objects within that POA. What is needed that isn't > in place? IIRC, there's nowhere in the spec that actually describes the source of the policies that can be retrieved via the IORInfo interface. Michi and I assume that the source is the POA that the IOR is being created for, but the document doesn't say that. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 15 May 2000 13:24:50 -0230 From: Matthew Newhook To: Jonathan Biggar Cc: Michi Henning , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Message-ID: <20000515132450.A27201@ooc.com> References: <852568E0.00462C85.00@d54mta08.raleigh.ibm.com> <20000515110916.A25925@ooc.com> <39201057.CECD49A1@floorboard.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39201057.CECD49A1@floorboard.com> Content-Type: text/plain; charset=us-ascii X-UIDL: K0%!!5O'e9+Wl!!^$+e9 Hi, On Mon, May 15, 2000 at 07:57:27AM -0700, Jonathan Biggar wrote: > > Can you elaborate? You can create new policies, and these can be placed > > on atribrary POAs in POA::create_POA. These policies can them influence > > various things, including the components that are placed in IORs, and > > requests made on objects within that POA. What is needed that isn't > > in place? > > IIRC, there's nowhere in the spec that actually describes the source of > the policies that can be retrieved via the IORInfo interface. Michi and > I assume that the source is the POA that the IOR is being created for, > but the document doesn't say that. That's the source. The specification deliberately doesn't mention anything about any specific object adapter. However, since an object adapter is needed to create an IOR I don't see where else the policies would come from but a POA in a POA based ORB. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org 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: Mon, 15 May 2000 13:26:07 -0230 From: Matthew Newhook To: Polar Humenn Cc: Michi Henning , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Message-ID: <20000515132607.B27201@ooc.com> References: <20000515110916.A25925@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: Qded9!Hm!!-!kd9"jp!! Hi, On Mon, May 15, 2000 at 10:39:24AM -0400, Polar Humenn wrote: > > Can you elaborate? You can create new policies, and these can be placed > > on atribrary POAs in POA::create_POA. These policies can them influence > > various things, including the components that are placed in IORs, and > > requests made on objects within that POA. What is needed that isn't > > in place? > > One thing that may be of issue, is that is it portably impossible to > locate a POA and a Servant from the information given in the adapter_id, > and object_id. Can you explain? When the servant is connected to a POA you know both the object-id and the adapter-id. So why is it impossible? > 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 -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Sender: jbiggar@corvette.floorboard.com Message-ID: <3920242B.A2C9C720@floorboard.com> Date: Mon, 15 May 2000 09:22:03 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Polar Humenn , Michi Henning , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <20000515110916.A25925@ooc.com> <20000515132607.B27201@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: O1>!!F3"!!Jg > Hi, > > On Mon, May 15, 2000 at 10:39:24AM -0400, Polar Humenn wrote: > > > Can you elaborate? You can create new policies, and these can be placed > > > on atribrary POAs in POA::create_POA. These policies can them influence > > > various things, including the components that are placed in IORs, and > > > requests made on objects within that POA. What is needed that isn't > > > in place? > > > > One thing that may be of issue, is that is it portably impossible to > > locate a POA and a Servant from the information given in the adapter_id, > > and object_id. > > Can you explain? When the servant is connected to a POA you know both > the object-id and the adapter-id. So why is it impossible? I think it is possible now, with the new attribute added to the POA which returns the adapter_id. The application code can cooperate in building a global map from adapter_id to POA references when the POAs are constructed. That map can also contain information to find a Servant from an object_id, assuming that the POA isn't using RETAIN. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 15 May 2000 12:23:53 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Michi Henning , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <20000515132607.B27201@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: _FA!!IR,e9JFbd9/[Be9 On Mon, 15 May 2000, Matthew Newhook wrote: > Hi, > > On Mon, May 15, 2000 at 10:39:24AM -0400, Polar Humenn wrote: > > > Can you elaborate? You can create new policies, and these can be > placed > > > on atribrary POAs in POA::create_POA. These policies can them > influence > > > various things, including the components that are placed in > IORs, and > > > requests made on objects within that POA. What is needed that > isn't > > > in place? > > > > One thing that may be of issue, is that is it portably impossible > to > > locate a POA and a Servant from the information given in the > adapter_id, > > and object_id. > > Can you explain? When the servant is connected to a POA you know > both > the object-id and the adapter-id. So why is it impossible? I don't think there is a way to locate the POA from the adapter-id, portably. There is nothing said about it. I'm not sure this matters. I think what we are looking for is something to hang a policy on a POA when it is created and use that policy at a later time to discover information about the object, such as some security properties. For example, in a certain interceptor point where the servant has been located and is able to be called upon for infomation, we may want certain information from the interceptor. Plese forgive me if I don't have the types correct, I don't have the spec in front of me. local DomainNamePolicy { DomainName get_domain_name( AdapterId adapter_id, ObjectId object_id, PortableServer::Servant servant); }; I think there are two problems. I've been told that even if I have the handle to the servant, it doesn't necessarily represent a single object, so therefore I need the object id to figure that out. Okay, so the object_id goes in as a parameter. Also, people have also told me that that information is not enough, as it is certainly possible for a servant to handle multiple POAs (although its definately stipulated as a bad idea). Now, given that, I really need the adapter_id, to really figure out which object I'm really intercepting. Okay, so what? When I'm setting up this policy, I must know the way by which I'm allocating object_ids within the POA. Fine, not a problem. I'm creating the POA, I should use/create a policy that understands the object ids I create with it. However, at that point, i.e. creation of the POA, I do not know the adapter_id that will be spit out in the interceptor. Cheers, -Polar > > > 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 > > -- > 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 From: Paul Kyzivat To: interceptors-ftf@omg.org, OTS RTF Subject: RE: Interceptors FTF remaining issues Date: Mon, 15 May 2000 19:13:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: FXW!!R)@e9g\1e9d_k!! > > > One thing that may be of issue, is that is it portably > impossible to > > > locate a POA and a Servant from the information given in > the adapter_id, > > > and object_id. > > > > Can you explain? When the servant is connected to a POA > you know both > > the object-id and the adapter-id. So why is it impossible? > > I think it is possible now, with the new attribute added to the POA > which returns the adapter_id. The application code can cooperate in > building a global map from adapter_id to POA references when the POAs > are constructed. That map can also contain information to find a > Servant from an object_id, assuming that the POA isn't using RETAIN. Cooperation to this extent by the application should not be required. There should be some builtin way to go from adapter id to adapter. (Resolve_initial_references is one possibility that comes to mind.) Personally, I think forcing indirection through this kind of handle is simply obfuscation that adds more unnecessary expense to interceptors that are already too expensive. It would be much better to provide the POA directly, or if we must support other (unstandardized) kinds of adapters, then perhaps we should return a reference to the adapter typed as Object. Then all it would take is a narrow to get the real thing. Paul Date: Tue, 16 May 2000 09:25:08 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org, OTS RTF Subject: RE: Interceptors FTF remaining issues In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BE91@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: DB=!!c/hd9kA-!!BW%!! On Mon, 15 May 2000, Paul Kyzivat wrote: > > I think it is possible now, with the new attribute added to the POA > > which returns the adapter_id. The application code can cooperate in > > building a global map from adapter_id to POA references when the POAs > > are constructed. That map can also contain information to find a > > Servant from an object_id, assuming that the POA isn't using RETAIN. > > Cooperation to this extent by the application should not be required. > There should be some builtin way to go from adapter id to adapter. > (Resolve_initial_references is one possibility that comes to mind.) I agree. If the application has to build a map for the interceptors to use, things are no longer transparent (or easy). > Personally, I think forcing indirection through this kind of handle is > simply obfuscation that adds more unnecessary expense to interceptors that > are already too expensive. It would be much better to provide the POA > directly, or if we must support other (unstandardized) kinds of adapters, > then perhaps we should return a reference to the adapter typed as Object. > Then all it would take is a narrow to get the real thing. I agree. Realistically, we have to be able to get at the adapter from inside an interceptor. Cheers, Michi. Date: Tue, 16 May 2000 09:33:14 +1000 (EST) From: Michi Henning To: Matthew Newhook cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <20000515110916.A25925@ooc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: =d?e9be+!!LLK!!Wl3!! [ Note: I've CC'd the issues list on this because I think that's a real interceptor issue that we should track separately. ] Subject heading for the issue should be "Overriding POA policies". On Mon, 15 May 2000, Matthew Newhook wrote: > Hi Michi, > > On Mon, May 15, 2000 at 11:12:12PM +1000, Michi Henning wrote: > > Russell, I didn't open a separate issue for it, because I wanted > opinions > > first. However, the answers are still outstanding, so I think we > have > > an issue: it appears to be impossible to portably attach OTS > policies > > to POAs with the machinery that is currently in place. We need a > fix for > > that, otherwise OTS ends up getting hamstrung... > > Can you elaborate? You can create new policies, and these can be > placed > on atribrary POAs in POA::create_POA. These policies can them > influence > various things, including the components that are placed in IORs, > and > requests made on objects within that POA. What is needed that isn't > in place? OK. Below is my original e-mail and Jon's reply to it. I can't see how I would get, for example, an OTS policy of REQUIRES_EITHER onto a POA. -- Michi's original message -- OK. We could make a NON_TRANSACTIONAL POA policy value that becomes the default if I don't do anything special. Some questions that have to do with implementing this: Suppose I call create_POA with an empty policy list, on an ORB with which OTS was registered. During create_POA, the ORB core calls into the OTS via establish_components(). The OTS calls back into the ORB via the passed IORInfo interface passed to that operation. At that point, it can call add_ior_component() or add_ior_component_to_profile() to let the POA know that the default policy value should be NON_TRANSACTIONAL. Now replay this scenario, but the client calls create_policy() to establish REQUIRES_EITHER and passes that policy in the policy list given to create_POA. As before, the ORB will call establish_components(), which can call add_ior_component() to return the default policy of NON_TRANSACTIONAL. How, having called add_ior_component, does the ORB override the default policy value with REQUIRES_EITHER? Does it call add_ior_component a second time? But how? It doesn't know which component is involved, or what profile it might apply to. On the other hand, the OTS cannot override the policy value because it won't get called a second time. The way I see it, the current portable interceptor spec makes it impossible to override a POA policy with a value other than the default value. [ Portable interceptor people can stop reading at this point. What follows is OTS-RTF specific. Do we need to do something about the add_ior_component() problem? Can someone explain to me the sequence of events that would take place from program start-up until a call to create_POA completes, and what happens if a client passes a non-default OTS policy value to create_POA()? ] -- End of Michi's original message -- -- Jon's reply -- > OK, so I'll have to eat my words... I got confused by these words in the PI > spec: > > Request Interceptors are registered on a per-ORB basis. > > To achieve virtual per-object Interceptors, query the policies on > the target from within the interception points to determine whether > they should do any work. To achieve virtual per-POA Interceptors, > instantiate each POA with a different ORB. > > This seems in conflict with what is said in the OTS spec in section > 10.3.11 about creating transactional references. Do we need to do anything > about this? No, I don't think so. First off, I think that statement from the PI spec is obsolete. IIRC, earlier editions of the PI spec didn't have the new opaque adapter id that can be retrieved from both the POA and the ServerRequestInfo. It's pretty trivial to use the adapter id to get per-POA behavior in server side request interceptors. Second, the PI spec updated the POA to require it to retain policies it doesn't understand but have a factory registered via the PI interfaces. This is obviously intended to allow new services to detect new policy types that are associated with a POA and have the interceptors do the right thing, whatever that may be. As an aside, the PI spec appears to entirely gloss over how "server side policies" are determined, in particular for calls to IORInfo::get_effective_policy. I should raise an issue about this. > Some questions that have to do with implementing this: > > Suppose I call create_POA with an empty policy list, on an > ORB > with which OTS was registered. During create_POA, the ORB > core > calls into the OTS via establish_components(). The OTS calls > back into the ORB via the passed IORInfo interface passed to > that > operation. At that point, it can call add_ior_component() or > add_ior_component_to_profile() to let the POA know that the > default > policy value should be NON_TRANSACTIONAL. > > Now replay this scenario, but the client calls > create_policy() > establish REQUIRES_EITHER and passes that policy in the > policy > list given to create_POA. As before, the ORB will call > establish_components(), which can call add_ior_component() > to > return the default policy of NON_TRANSACTIONAL. How, having > called add_ior_component, does the ORB override the default > policy value with REQUIRES_EITHER? Does it call > add_ior_component > a second time? But how? It doesn't know which component is > involved, > or what profile it might apply to. On the other hand, the > OTS > cannot override the policy value because it won't get called > a second time. > > The way I see it, the current portable interceptor spec > makes > it impossible to override a POA policy with a value other > than > the default value. I think that is what IORInfo::get_effective_policy is supposed to provide, but the documentation in the PI spec is too sparse for me to be sure. :-( X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 15 May 2000 20:56:02 -0400 (EDT) From: Polar Humenn To: Michi Henning cc: Paul Kyzivat , interceptors-ftf@omg.org, OTS RTF Subject: RE: Interceptors FTF remaining issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: eT~e9BlF!!dXRd9~LAe9 On Tue, 16 May 2000, Michi Henning wrote: > On Mon, 15 May 2000, Paul Kyzivat wrote: > > > > I think it is possible now, with the new attribute added to the > POA > > > which returns the adapter_id. The application code can > cooperate in > > > building a global map from adapter_id to POA references when the > POAs > > > are constructed. That map can also contain information to find > a > > > Servant from an object_id, assuming that the POA isn't using > RETAIN. > > > > Cooperation to this extent by the application should not be > required. > > There should be some builtin way to go from adapter id to adapter. > > (Resolve_initial_references is one possibility that comes to > mind.) > > I agree. If the application has to build a map for the interceptors > to use, > things are no longer transparent (or easy). > > > Personally, I think forcing indirection through this kind of > handle is > > simply obfuscation that adds more unnecessary expense to > interceptors that > > are already too expensive. It would be much better to provide the > POA > > directly, or if we must support other (unstandardized) kinds of > adapters, > > then perhaps we should return a reference to the adapter typed as > Object. > > Then all it would take is a narrow to get the real thing. > > I agree. Realistically, we have to be able to get at the adapter > from inside > an interceptor. I agree. Right now, we have to wait until we create a POA and wait for an invocation on an object in that POA to find out what the full adapter id the ORB created for it. Even that doesn't work. Because if we have more than one POA, we have to guess which one the adapter_id represents. In fact, the only assurance we have at that point, is if we didn't create any POAs in the server, and therefore we could surmise that the adapter_id presented in the interceptor represents the RootPOA. If we have the POA available, we can construct a usable adapter id (by successive calls to poa.the_name() and poa.the_parent()) in a predictable fashion. This allows us to write security policy based on adapter ids before the adapter is even created. It might be a pain in the arse to do this, but the functionality is there if needed. 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 Date: Tue, 16 May 2000 09:39:54 +1000 (EST) From: Michi Henning Reply-To: interceptors-ftf@omg.org, OTS RTF To: issues@omg.org Subject: Overriding POA policies Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: O8Xd9MP4e9I%#!!T@0e9 ---------- Forwarded message ---------- From: Michi Henning Organization: Object Oriented Concepts To: Matthew Newhook Cc: interceptors-ftf@omg.org, OTS RTF Date: Tue, 16 May 2000 09:33:14 +1000 (EST) Subject: Re: Interceptors FTF remaining issues [ Note: I've CC'd the issues list on this because I think that's a real interceptor issue that we should track separately. ] Subject heading for the issue should be "Overriding POA policies". On Mon, 15 May 2000, Matthew Newhook wrote: > Hi Michi, > > On Mon, May 15, 2000 at 11:12:12PM +1000, Michi Henning wrote: > > Russell, I didn't open a separate issue for it, because I wanted > opinions > > first. However, the answers are still outstanding, so I think we > have > > an issue: it appears to be impossible to portably attach OTS > policies > > to POAs with the machinery that is currently in place. We need a > fix for > > that, otherwise OTS ends up getting hamstrung... > > Can you elaborate? You can create new policies, and these can be > placed > on atribrary POAs in POA::create_POA. These policies can them > influence > various things, including the components that are placed in IORs, > and > requests made on objects within that POA. What is needed that isn't > in place? OK. Below is my original e-mail and Jon's reply to it. I can't see how I would get, for example, an OTS policy of REQUIRES_EITHER onto a POA. -- Michi's original message -- OK. We could make a NON_TRANSACTIONAL POA policy value that becomes the default if I don't do anything special. Some questions that have to do with implementing this: Suppose I call create_POA with an empty policy list, on an ORB with which OTS was registered. During create_POA, the ORB core calls into the OTS via establish_components(). The OTS calls back into the ORB via the passed IORInfo interface passed to that operation. At that point, it can call add_ior_component() or add_ior_component_to_profile() to let the POA know that the default policy value should be NON_TRANSACTIONAL. Now replay this scenario, but the client calls create_policy() to establish REQUIRES_EITHER and passes that policy in the policy list given to create_POA. As before, the ORB will call establish_components(), which can call add_ior_component() to return the default policy of NON_TRANSACTIONAL. How, having called add_ior_component, does the ORB override the default policy value with REQUIRES_EITHER? Does it call add_ior_component a second time? But how? It doesn't know which component is involved, or what profile it might apply to. On the other hand, the OTS cannot override the policy value because it won't get called a second time. The way I see it, the current portable interceptor spec makes it impossible to override a POA policy with a value other than the default value. [ Portable interceptor people can stop reading at this point. What follows is OTS-RTF specific. Do we need to do something about the add_ior_component() problem? Can someone explain to me the sequence of events that would take place from program start-up until a call to create_POA completes, and what happens if a client passes a non-default OTS policy value to create_POA()? ] -- End of Michi's original message -- -- Jon's reply -- > OK, so I'll have to eat my words... I got confused by these words in the PI > spec: > > Request Interceptors are registered on a per-ORB basis. > > To achieve virtual per-object Interceptors, query the policies on > the target from within the interception points to determine whether > they should do any work. To achieve virtual per-POA Interceptors, > instantiate each POA with a different ORB. > > This seems in conflict with what is said in the OTS spec in section > 10.3.11 about creating transactional references. Do we need to do anything > about this? No, I don't think so. First off, I think that statement from the PI spec is obsolete. IIRC, earlier editions of the PI spec didn't have the new opaque adapter id that can be retrieved from both the POA and the ServerRequestInfo. It's pretty trivial to use the adapter id to get per-POA behavior in server side request interceptors. Second, the PI spec updated the POA to require it to retain policies it doesn't understand but have a factory registered via the PI interfaces. This is obviously intended to allow new services to detect new policy types that are associated with a POA and have the interceptors do the right thing, whatever that may be. As an aside, the PI spec appears to entirely gloss over how "server side policies" are determined, in particular for calls to IORInfo::get_effective_policy. I should raise an issue about this. > Some questions that have to do with implementing this: > > Suppose I call create_POA with an empty policy list, on an > ORB > with which OTS was registered. During create_POA, the ORB > core > calls into the OTS via establish_components(). The OTS calls > back into the ORB via the passed IORInfo interface passed to > that > operation. At that point, it can call add_ior_component() or > add_ior_component_to_profile() to let the POA know that the > default > policy value should be NON_TRANSACTIONAL. > > Now replay this scenario, but the client calls > create_policy() > establish REQUIRES_EITHER and passes that policy in the > policy > list given to create_POA. As before, the ORB will call > establish_components(), which can call add_ior_component() > to > return the default policy of NON_TRANSACTIONAL. How, having > called add_ior_component, does the ORB override the default > policy value with REQUIRES_EITHER? Does it call > add_ior_component > a second time? But how? It doesn't know which component is > involved, > or what profile it might apply to. On the other hand, the > OTS > cannot override the policy value because it won't get called > a second time. > > The way I see it, the current portable interceptor spec > makes > it impossible to override a POA policy with a value other > than > the default value. I think that is what IORInfo::get_effective_policy is supposed to provide, but the documentation in the PI spec is too sparse for me to be sure. :-( From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA31676; Wed, 17 May 2000 05:48:35 -0500 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id GAA45882; Wed, 17 May 2000 06:01:00 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E2.00370548 ; Wed, 17 May 2000 06:00:58 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, OTS RTF Message-ID: <852568E0.005532EB.00@d54mta08.raleigh.ibm.com> Date: Mon, 15 May 2000 10:20:20 -0500 Subject: Re: Interceptors FTF remaining issues Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 7,l!!;*Td9S0U!!;96!! Here's a quote from the interceptor spec about IORInfo.get_effective_policy: "21.5.3.1 get_effective_policy An ORB service implementation may determine what server side policy of a particular type is in effect for an IOR being constructed by calling the get_effective_policy operation. The returned CORBA::Policy object shall only be a policy whose type was registered via ORBInitInfo::register_policy_factory (see section 21.7.2.12, register_policy_factory on page 21-43)." Russell Butek butek@us.ibm.com Jonathan Biggar @corvette.floorboard.com on 05/15/2000 09:57:27 AM Sent by: jon@corvette.floorboard.com To: Matthew Newhook cc: Michi Henning , Russell Butek/Austin/IBM@IBMUS, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Matthew Newhook wrote: > > Hi Michi, > > On Mon, May 15, 2000 at 11:12:12PM +1000, Michi Henning wrote: > > Russell, I didn't open a separate issue for it, because I wanted opinions > > first. However, the answers are still outstanding, so I think we have > > an issue: it appears to be impossible to portably attach OTS policies > > to POAs with the machinery that is currently in place. We need a fix for > > that, otherwise OTS ends up getting hamstrung... > > Can you elaborate? You can create new policies, and these can be placed > on atribrary POAs in POA::create_POA. These policies can them influence > various things, including the components that are placed in IORs, and > requests made on objects within that POA. What is needed that isn't > in place? IIRC, there's nowhere in the spec that actually describes the source of the policies that can be retrieved via the IORInfo interface. Michi and I assume that the source is the POA that the IOR is being created for, but the document doesn't say that. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 17 May 2000 09:22:39 -0400 (EDT) From: Polar Humenn To: butek@us.ibm.com cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <852568E0.005532EB.00@d54mta08.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: eA9e9\OU!!AMLe9\]Y!! Can I ask a naive question? What to registering policy factories have to do with effective policies on objects? Say I create an object that implements some extention of the CORBA::Policy interface in whatever language I happen to be working in. I don't have a bonefied CORBA policy factory for it, so I can't register it. Who cares? I create a POA with that policy. During an interception point why ServerRequestInfo::get_server_policy(), or IORInfo::get_effective_policy(), I believe the text below states that I cannot retrieve that policy. Hmmmm. Why not? Cheers, -Polar On Mon, 15 May 2000 butek@us.ibm.com wrote: > > > Here's a quote from the interceptor spec about > IORInfo.get_effective_policy: > > "21.5.3.1 get_effective_policy > > An ORB service implementation may determine what server side policy > of a > particular > type is in effect for an IOR being constructed by calling the > get_effective_policy > operation. The returned CORBA::Policy object shall only be a policy > whose > type was > registered via ORBInitInfo::register_policy_factory (see section > 21.7.2.12, > register_policy_factory on page 21-43)." > > Russell Butek > butek@us.ibm.com > > > Jonathan Biggar @corvette.floorboard.com on > 05/15/2000 > 09:57:27 AM > > Sent by: jon@corvette.floorboard.com > > > To: Matthew Newhook > cc: Michi Henning , Russell > Butek/Austin/IBM@IBMUS, > interceptors-ftf@omg.org, OTS RTF > Subject: Re: Interceptors FTF remaining issues > > > > Matthew Newhook wrote: > > > > Hi Michi, > > > > On Mon, May 15, 2000 at 11:12:12PM +1000, Michi Henning wrote: > > > Russell, I didn't open a separate issue for it, because I wanted > opinions > > > first. However, the answers are still outstanding, so I think we > have > > > an issue: it appears to be impossible to portably attach OTS > policies > > > to POAs with the machinery that is currently in place. We need a > fix > for > > > that, otherwise OTS ends up getting hamstrung... > > > > Can you elaborate? You can create new policies, and these can be > placed > > on atribrary POAs in POA::create_POA. These policies can them > influence > > various things, including the components that are placed in IORs, > and > > requests made on objects within that POA. What is needed that > isn't > > in place? > > IIRC, there's nowhere in the spec that actually describes the source > of > the policies that can be retrieved via the IORInfo interface. Michi > and > I assume that the source is the POA that the IOR is being created > for, > but the document doesn't say that. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > > > ------------------------------------------------------------------- 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 Sender: jbiggar@corvette.floorboard.com Message-ID: <3922DA2D.3513779F@floorboard.com> Date: Wed, 17 May 2000 10:43:09 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com CC: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <852568E0.005532EB.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @(+e9; > Here's a quote from the interceptor spec about > IORInfo.get_effective_policy: > > "21.5.3.1 get_effective_policy > > An ORB service implementation may determine what server side policy of a > particular > type is in effect for an IOR being constructed by calling the > get_effective_policy > operation. The returned CORBA::Policy object shall only be a policy whose > type was > registered via ORBInitInfo::register_policy_factory (see section 21.7.2.12, > register_policy_factory on page 21-43)." I see that quote, it doesn't say that the source of "server side policies" is from the POA that the object reference is being created for, and that the policies come from the policy list provided when the POA is created. Smart people who have worked with the specs for a long time can figure this out, but I think most people will be left clueless. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <3922DB0B.AFF3BE7C@floorboard.com> Date: Wed, 17 May 2000 10:46:51 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &g>!!B#_d9;iM!!V)1e9 Polar Humenn wrote: > > Can I ask a naive question? What to registering policy factories have to > do with effective policies on objects? > > Say I create an object that implements some extention of the CORBA::Policy > interface in whatever language I happen to be working in. I don't have a > bonefied CORBA policy factory for it, so I can't register it. Who cares? > > I create a POA with that policy. > > During an interception point why ServerRequestInfo::get_server_policy(), > or IORInfo::get_effective_policy(), I believe the text below states that I > cannot retrieve that policy. I've wondered that myself. Given that all policy objects have the copy() operation and policies that aren't explicitly known by the POA are just going to be copied and/or remembered, it seems the restriction to policies that have registered factories is unnecessary. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 17 May 2000 14:08:41 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Polar Humenn , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <3922DB0B.AFF3BE7C@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: i1@!!Im;!!U-J!!JOXd9 Jonathan Biggar wrote: > > Polar Humenn wrote: > > > > Can I ask a naive question? What to registering policy factories have to > > do with effective policies on objects? > > > > Say I create an object that implements some extention of the CORBA::Policy > > interface in whatever language I happen to be working in. I don't have a > > bonefied CORBA policy factory for it, so I can't register it. Who cares? > > > > I create a POA with that policy. > > > > During an interception point why ServerRequestInfo::get_server_policy(), > > or IORInfo::get_effective_policy(), I believe the text below states that I > > cannot retrieve that policy. > > I've wondered that myself. Given that all policy objects have the > copy() operation and policies that aren't explicitly known by the POA > are just going to be copied and/or remembered, it seems the restriction > to policies that have registered factories is unnecessary. I agree that this restriction is unnecessary, and strongly encourage its removal. The Portable Interceptors specification should not assume that the Portable Interceptor APIs are the only mechanism by which ORB services and their associated Policy objects might be implemented. -Bob > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org From: butek@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA18974; Wed, 17 May 2000 15:14:00 -0500 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAB34094; Wed, 17 May 2000 15:26:26 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E2.006AC677 ; Wed, 17 May 2000 15:26:16 -0400 X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org, OTS RTF Message-ID: <852568E2.006AC2BC.00@d54mta04.raleigh.ibm.com> Date: Wed, 17 May 2000 15:26:03 -0400 Subject: Re: Interceptors FTF remaining issues Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 9(Zd9plgd9&Uh!!RVM!! Bob Kukura on 05/17/2000 01:08:41 PM > > Jonathan Biggar wrote: > > > > Polar Humenn wrote: > > > > > > Can I ask a naive question? What to registering policy factories have to > > > do with effective policies on objects? > > > > > > Say I create an object that implements some extention of the CORBA::Policy > > > interface in whatever language I happen to be working in. I don't have a > > > bonefied CORBA policy factory for it, so I can't register it. Who cares? > > > > > > I create a POA with that policy. > > > > > > During an interception point why ServerRequestInfo::get_server_policy(), > > > or IORInfo::get_effective_policy(), I believe the text below states that I > > > cannot retrieve that policy. > > > > I've wondered that myself. Given that all policy objects have the > > copy() operation and policies that aren't explicitly known by the POA > > are just going to be copied and/or remembered, it seems the restriction > > to policies that have registered factories is unnecessary. > > I agree that this restriction is unnecessary, and strongly encourage its > removal. The Portable Interceptors specification should not assume that > the Portable Interceptor APIs are the only mechanism by which ORB > services and their associated Policy objects might be implemented. > This restriction wasn't originally in the interceptor proposal. I recall a rather involved discussion in Cambridge that resulted in this restriction. I must have been zoning out during that conversation, I remember it took place, but I can't remember any details. Does anyone have a better memory than mine? Russell Butek butek@us.ibm.com Date: Wed, 17 May 2000 17:11:15 -0230 From: Matthew Newhook To: butek@us.ibm.com Cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Message-ID: <20000517171115.A13817@ooc.com> References: <852568E2.006AC2BC.00@d54mta04.raleigh.ibm.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <852568E2.006AC2BC.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii X-UIDL: p>#"!pA=e9dBFe9\?e!! Hi, On Wed, May 17, 2000 at 03:26:03PM -0400, butek@us.ibm.com wrote: > This restriction wasn't originally in the interceptor proposal. I recall a > rather involved discussion in Cambridge that resulted in this restriction. > I must have been zoning out during that conversation, I remember it took > place, but I can't remember any details. Does anyone have a better memory > than mine? I think it was a potential security concern. Also, we didn't want the POA policies to show up in the list. > Russell Butek > butek@us.ibm.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: Wed, 17 May 2000 15:46:13 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <852568E2.006AC2BC.00@d54mta04.raleigh.ibm.com> <20000517171115.A13817@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: bgD!!W+K!!jUOd9'"8e9 Matthew Newhook wrote: > > Hi, > > On Wed, May 17, 2000 at 03:26:03PM -0400, butek@us.ibm.com wrote: > > This restriction wasn't originally in the interceptor proposal. I recall a > > rather involved discussion in Cambridge that resulted in this restriction. > > I must have been zoning out during that conversation, I remember it took > > place, but I can't remember any details. Does anyone have a better memory > > than mine? > > I think it was a potential security concern. Also, we didn't want the > POA policies to show up in the list. I don't remember this conversation either, but may not have been present. From our perspective, we do want the POA policies to show up. Filtering them out would take extra work, with no added benefit. I have no idea what the security concern may have been. > > > Russell Butek > > butek@us.ibm.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 Sender: jbiggar@corvette.floorboard.com Message-ID: <3922FDB1.AFCD5942@floorboard.com> Date: Wed, 17 May 2000 13:14:41 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <852568E2.006AC2BC.00@d54mta04.raleigh.ibm.com> <20000517171115.A13817@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -Kkd9~N9!!hef!!%3b!! Matthew Newhook wrote: > > Hi, > > On Wed, May 17, 2000 at 03:26:03PM -0400, butek@us.ibm.com wrote: > > This restriction wasn't originally in the interceptor proposal. I recall a > > rather involved discussion in Cambridge that resulted in this restriction. > > I must have been zoning out during that conversation, I remember it took > > place, but I can't remember any details. Does anyone have a better memory > > than mine? > > I think it was a potential security concern. Also, we didn't want the > POA policies to show up in the list. I can see that security might possibly be a concern, but since an interceptor has plenty of other opportunity for mischief, I'm not sure what extra security might be gained from denying access to the POA's policy list. Also, why shouldn't the interceptor see the POA's policy list? There may very well be useful behavior that an interceptor could exhibit by, for example, knowing whether the object reference is persistent or transient. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 17 May 2000 16:29:10 -0400 (EDT) From: Polar Humenn To: Bob Kukura cc: Matthew Newhook , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <3922F705.B48C6C51@iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: W\Oe9J75e9=Q)!!ORid9 On Wed, 17 May 2000, Bob Kukura wrote: > > > Matthew Newhook wrote: > > > > Hi, > > > > On Wed, May 17, 2000 at 03:26:03PM -0400, butek@us.ibm.com wrote: > > > This restriction wasn't originally in the interceptor proposal. > I recall a > > > rather involved discussion in Cambridge that resulted in this > restriction. > > > I must have been zoning out during that conversation, I remember > it took > > > place, but I can't remember any details. Does anyone have a > better memory > > > than mine? > > > > I think it was a potential security concern. Also, we didn't want > the > > POA policies to show up in the list. > > I don't remember this conversation either, but may not have been > present. From our perspective, we do want the POA policies to show > up. > Filtering them out would take extra work, with no added benefit. I > have > no idea what the security concern may have been. I'll agree with Bob. I don't see a security concern. In fact, we need the POA policies to show up! 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 Date: Wed, 17 May 2000 18:26:37 -0230 From: Matthew Newhook To: Bob Kukura Cc: butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Message-ID: <20000517182637.B14256@ooc.com> References: <852568E2.006AC2BC.00@d54mta04.raleigh.ibm.com> <20000517171115.A13817@ooc.com> <3922F705.B48C6C51@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3922F705.B48C6C51@iona.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 8dJ!!IYRd95%6!!=(;e9 Hi Bob, On Wed, May 17, 2000 at 03:46:13PM -0400, Bob Kukura wrote: > > I think it was a potential security concern. Also, we didn't want the > > POA policies to show up in the list. > > I don't remember this conversation either, but may not have been > present. From our perspective, we do want the POA policies to show up. > Filtering them out would take extra work, with no added benefit. I have > no idea what the security concern may have been. I don't think you were present. From memory the meeting was attended by Jishnu, Jeff, Ioana, Vijay, Russell, Harold, Michi & myself. I can't remember the specifics of the conversation. However, I think we might have discussed the following: How does the POA know when to allow a policy, and when to reject it? I believe we changed the text of POA::create_POA to say something like the policies are either built in (ie: existing POA policies) or are registered with a policy factory. This allows the POA to determine whether the policies are at least recognized by the ORB. If this restriction is removed, how is this recognition carried out? 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 Sender: jbiggar@corvette.floorboard.com Message-ID: <39230E92.DEB9894E@floorboard.com> Date: Wed, 17 May 2000 14:26:42 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <852568E2.006AC2BC.00@d54mta04.raleigh.ibm.com> <20000517171115.A13817@ooc.com> <3922F705.B48C6C51@iona.com> <20000517182637.B14256@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ZXfd9%VVd9MaE!!?O)e9 Matthew Newhook wrote: > > Hi Bob, > > On Wed, May 17, 2000 at 03:46:13PM -0400, Bob Kukura wrote: > > > I think it was a potential security concern. Also, we didn't want the > > > POA policies to show up in the list. > > > > I don't remember this conversation either, but may not have been > > present. From our perspective, we do want the POA policies to show up. > > Filtering them out would take extra work, with no added benefit. I have > > no idea what the security concern may have been. > > I don't think you were present. From memory the meeting was attended by > Jishnu, Jeff, Ioana, Vijay, Russell, Harold, Michi & myself. > > I can't remember the specifics of the conversation. However, I think we > might have discussed the following: > > How does the POA know when to allow a policy, and when to reject it? I > believe we changed the text of POA::create_POA to say something like > the policies are either built in (ie: existing POA policies) or are > registered with a policy factory. This allows the POA to determine whether > the policies are at least recognized by the ORB. If this restriction is > removed, how is this recognition carried out? Why does it need any extra mechanism to recognize policies? It can query the policy type, and if it is one that the POA knows, it can use it. Otherwise, it just stores it for the interceptors' benefit. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 17 May 2000 17:36:09 -0400 (EDT) From: Polar Humenn To: Matthew Newhook cc: Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <20000517182637.B14256@ooc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: (&/!!-K!e9(b+!!Tj9!! On Wed, 17 May 2000, Matthew Newhook wrote: > Hi Bob, > > On Wed, May 17, 2000 at 03:46:13PM -0400, Bob Kukura wrote: > > > I think it was a potential security concern. Also, we didn't > want the > > > POA policies to show up in the list. > > > > I don't remember this conversation either, but may not have been > > present. From our perspective, we do want the POA policies to > show up. > > Filtering them out would take extra work, with no added benefit. > I have > > no idea what the security concern may have been. > > I don't think you were present. From memory the meeting was attended > by > Jishnu, Jeff, Ioana, Vijay, Russell, Harold, Michi & myself. > > I can't remember the specifics of the conversation. However, I think > we > might have discussed the following: > > How does the POA know when to allow a policy, and when to reject it? > I > believe we changed the text of POA::create_POA to say something like > the policies are either built in (ie: existing POA policies) or are > registered with a policy factory. This allows the POA to determine > whether > the policies are at least recognized by the ORB. If this restriction > is > removed, how is this recognition carried out? What does it mean for a POA to "reject" a policy? There are some policies that directly pertain to a POA, such as Retain, Default servant, etc. The other policies are just supposed to be remembered, correct? Why should it reject them? -Polar > > 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, 18 May 2000 07:36:51 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Matthew Newhook , Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <39230E92.DEB9894E@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: gLQe9_5Xd9YQ%!!:OP!! On Wed, 17 May 2000, Jonathan Biggar wrote: > > I don't think you were present. From memory the meeting was attended by > > Jishnu, Jeff, Ioana, Vijay, Russell, Harold, Michi & myself. > > > > I can't remember the specifics of the conversation. However, I think we > > might have discussed the following: > > > > How does the POA know when to allow a policy, and when to reject it? I > > believe we changed the text of POA::create_POA to say something like > > the policies are either built in (ie: existing POA policies) or are > > registered with a policy factory. This allows the POA to determine whether > > the policies are at least recognized by the ORB. If this restriction is > > removed, how is this recognition carried out? > > Why does it need any extra mechanism to recognize policies? It can > query the policy type, and if it is one that the POA knows, it can use > it. Otherwise, it just stores it for the interceptors' benefit. I can't recall any discussion of security issues with regard to this. But I think this discussion is getting off-track. What I'm really concerned about is how the policy gets into the IOR. Here is the challenge: Write portable code that results in the OTS REQUIRES_SHARED policy to be embedded into every IOR created on a particular POA. I cannot see how this can be implemented right now. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 18 May 2000 07:55:23 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Matthew Newhook , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <3922FDB1.AFCD5942@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: PFLe9gbad9@P3e9dp5e9 On Wed, 17 May 2000, Jonathan Biggar wrote: > I can see that security might possibly be a concern, but since an > interceptor has plenty of other opportunity for mischief, I'm not > sure > what extra security might be gained from denying access to the POA's > policy list. > > Also, why shouldn't the interceptor see the POA's policy list? > There > may very well be useful behavior that an interceptor could exhibit > by, > for example, knowing whether the object reference is persistent or > transient. Also, for OTS, the policies must be visible because the interceptors has to verify that the transaction semantics of client and server match. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: interceptors-ftf@omg.org, OTS RTF Subject: RE: Interceptors FTF remaining issues Date: Wed, 17 May 2000 19:08:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: [eUd9`$dd9!aM!!j"?!! I am pretty sure sometime, someplace, there was a discussion about this, regarding the right of the POA to capture the content of the policies that affect it in some convenient form, and that it could be at least inconvenient to keep them around in original form to show to interceptors. I am relatively open minded on this - looking for pros & cons. Paul > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Wednesday, May 17, 2000 4:29 PM > To: Bob Kukura > Cc: Matthew Newhook; butek@us.ibm.com; > interceptors-ftf@omg.org; OTS RTF > Subject: Re: Interceptors FTF remaining issues > > > On Wed, 17 May 2000, Bob Kukura wrote: > > > > > > > Matthew Newhook wrote: > > > > > > Hi, > > > > > > On Wed, May 17, 2000 at 03:26:03PM -0400, butek@us.ibm.com wrote: > > > > This restriction wasn't originally in the interceptor > proposal. I recall a > > > > rather involved discussion in Cambridge that resulted > in this restriction. > > > > I must have been zoning out during that conversation, I > remember it took > > > > place, but I can't remember any details. Does anyone > have a better memory > > > > than mine? > > > > > > I think it was a potential security concern. Also, we > didn't want the > > > POA policies to show up in the list. > > > > I don't remember this conversation either, but may not have been > > present. From our perspective, we do want the POA policies > to show up. > > Filtering them out would take extra work, with no added > benefit. I have > > no idea what the security concern may have been. > > I'll agree with Bob. I don't see a security concern. In fact, > we need the > POA policies to show up! > > 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 > Date: Wed, 17 May 2000 22:04:10 -0230 From: Matthew Newhook To: Michi Henning Cc: Jonathan Biggar , Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Message-ID: <20000517220410.C16610@ooc.com> References: <39230E92.DEB9894E@floorboard.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: 0``d9pe?!!-ZA!!O-Zd9 Hi Michi, On Thu, May 18, 2000 at 07:36:51AM +1000, Michi Henning wrote: > But I think this discussion is getting off-track. What I'm really concerned > about is how the policy gets into the IOR. Here is the challenge: > > Write portable code that results in the OTS REQUIRES_SHARED > policy to be embedded into every IOR created on a particular POA. ^^^^^^ Do you mean component and not policy? Assuming that, and assuming that the user has set the appropriate policy on the POA itself, why can't the IORInterceptor do that? > I cannot see how this can be implemented right now. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html 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, 18 May 2000 10:45:28 +1000 (EST) From: Michi Henning To: Matthew Newhook cc: Jonathan Biggar , Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <20000517220410.C16610@ooc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?OQe91Mh!!k$`d9UQD!! On Wed, 17 May 2000, Matthew Newhook wrote: > Hi Michi, > > On Thu, May 18, 2000 at 07:36:51AM +1000, Michi Henning wrote: > > But I think this discussion is getting off-track. What I'm really > concerned > > about is how the policy gets into the IOR. Here is the challenge: > > > > Write portable code that results in the OTS REQUIRES_SHARED > > policy to be embedded into every IOR created on a particular > POA. > ^^^^^^ > Do you mean component and not policy? Assuming that, and assuming > that > the user has set the appropriate policy on the POA itself, why can't > the > IORInterceptor do that? How? I can't find the API calls that would permit me to do that. How does REQUIRES_SHARED get into each IOR created on that POA? Who puts the policy in there, and at what time? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 17 May 2000 22:44:31 -0230 From: Matthew Newhook To: Michi Henning Cc: Jonathan Biggar , Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues Message-ID: <20000517224431.A20422@ooc.com> References: <20000517220410.C16610@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: D/@!!Tij!!8P>!!Jiad9 Hi, On Thu, May 18, 2000 at 10:45:28AM +1000, Michi Henning wrote: > > Do you mean component and not policy? Assuming that, and assuming that > > the user has set the appropriate policy on the POA itself, why can't the > > IORInterceptor do that? > > How? I can't find the API calls that would permit me to do that. How > does REQUIRES_SHARED get into each IOR created on that POA? Who puts > the policy in there, and at what time? A policy is created which is handed in the PolicyList to create_POA. When the IORInterceptor is called get_server_policy (or whatever the API call is) retrieves the policy, if present, and establish_component is called with the REQUIRES_SHARED component. > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html 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, 18 May 2000 11:27:14 +1000 (EST) From: Michi Henning To: Matthew Newhook cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <20000517224431.A20422@ooc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,W$"!&)?!!00I!!8(?e9 On Wed, 17 May 2000, Matthew Newhook wrote: > A policy is created which is handed in the PolicyList to create_POA. When > the IORInterceptor is called get_server_policy (or whatever the API call > is) retrieves the policy, if present, and establish_component is called > with the REQUIRES_SHARED component. OK, I can see that now, thanks. So what does get_effective_policy() return if I ask for the OTS policy, but the client didn't pass an OTS policy to create_POA()? In that case I have to use whatever is the default and call add_ior_component() with that default. I think we have a hole there. get_effective_policy() shold probably return nil() in that case? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <392348F1.2BC9D2D3@floorboard.com> Date: Wed, 17 May 2000 18:35:45 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Matthew Newhook , Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: k6Be9B@3e9=/ad9O&9!! Michi Henning wrote: > > On Wed, 17 May 2000, Matthew Newhook wrote: > > > Hi Michi, > > > > On Thu, May 18, 2000 at 07:36:51AM +1000, Michi Henning wrote: > > > But I think this discussion is getting off-track. What I'm really concerned > > > about is how the policy gets into the IOR. Here is the challenge: > > > > > > Write portable code that results in the OTS REQUIRES_SHARED > > > policy to be embedded into every IOR created on a particular POA. > > ^^^^^^ > > Do you mean component and not policy? Assuming that, and assuming that > > the user has set the appropriate policy on the POA itself, why can't the > > IORInterceptor do that? > > How? I can't find the API calls that would permit me to do that. How > does REQUIRES_SHARED get into each IOR created on that POA? Who puts > the policy in there, and at what time? Michi, I think the way you are supposed to do it is like this: 1. The application code, which knows it wants to use the OTS does whatever magic is necessary to link in the OTS and have the OTS register itself with the ORB via the ORBInitializer interface. 2. The application calls ORB_init. 2. The OTS ORBInitializer registers lots of interceptor junk, including the factories for the OTS policies and an IOR Interceptor. 3. The application constructs a TransactionPolicy for REQUIRES_SHARED by calling ORB::create_policy(). 4. The application creates a POA, placing that policy object in the list of policies in the create_POA() call. 5. The application creates a reference by calling POA::create_reference(). 6. The POA calls the OTS IORInterceptor::establish_components(). 7. The OTS IORInterceptor uses IORInfo::get_effective_policy() to retrieve the TransactionPolicy of the POA, examines it, finds REQUIRES_SHARED, and encodes a TAG_POLICIES TaggedComponent that contains the correct policy information for REQUIRES_SHARED. Now, there is a problem here, since each IORInterceptor is going to create its own TAG_POLICIES component on the IOR. This is legal, as far as I can tell, but not very efficient. We could mandate that the POA must collapse multiple TAG_POLICIES components into one for each IOR profile, but I think it would be better to add another couple of operations to the PI IORInfo interface: local interface IORInfo { void add_policy(in Messaging::PolicyValue pv); void add_policy_to_profile(in Messaging::PolicyValue pv); }; Now that I've climbed out on the limb, I'll let the other Interceptor folks shoot me down if this isn't right. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 18 May 2000 12:28:46 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <392348F1.2BC9D2D3@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: AVMe9ibLd9(2He9aX[!! On Wed, 17 May 2000, Jonathan Biggar wrote: > 7. The OTS IORInterceptor uses IORInfo::get_effective_policy() to > retrieve the TransactionPolicy of the POA, examines it, finds > REQUIRES_SHARED, and encodes a TAG_POLICIES TaggedComponent that > contains the correct policy information for REQUIRES_SHARED. Yep, that seems to work, thanks. The only thing missing appears to be that the return value of get_effective_policy() isn't specified if the policy type that is being asked for is known, but the client didn't pass such a policy to create_POA(). In that case, the IORInterceptor has to establish the default. Looks like requiring get_effective_policy() to return a nil reference would be the right thing to do in this case. > Now, there is a problem here, since each IORInterceptor is going to > create its own TAG_POLICIES component on the IOR. This is legal, as > far > as I can tell, but not very efficient. > > We could mandate that the POA must collapse multiple TAG_POLICIES > components into one for each IOR profile, but I think it would be > better > to add another couple of operations to the PI IORInfo interface: > > local interface IORInfo { > void add_policy(in Messaging::PolicyValue pv); > void add_policy_to_profile(in Messaging::PolicyValue pv); > }; I don't think that all policies will end up under TAG_POLICIES. For example, OTS current specifies const IOP::ComponentId TAG_TRANSACTION_POLICY = 26; Also, I can see lots of other policies crop up over time. Do we really want to add operations to IORInfo that are specific to particular services, such as messaging? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <392364F2.5EAF3AF9@floorboard.com> Date: Wed, 17 May 2000 20:35:14 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -]Ge9X#Ie9S__d9H,3e9 Michi Henning wrote: > > On Wed, 17 May 2000, Jonathan Biggar wrote: > > > 7. The OTS IORInterceptor uses IORInfo::get_effective_policy() to > > retrieve the TransactionPolicy of the POA, examines it, finds > > REQUIRES_SHARED, and encodes a TAG_POLICIES TaggedComponent that > > contains the correct policy information for REQUIRES_SHARED. > > Yep, that seems to work, thanks. The only thing missing appears to be > that the return value of get_effective_policy() isn't specified if > the policy type that is being asked for is known, but the client didn't > pass such a policy to create_POA(). In that case, the IORInterceptor has > to establish the default. Looks like requiring get_effective_policy() to > return a nil reference would be the right thing to do in this case. > > > Now, there is a problem here, since each IORInterceptor is going to > > create its own TAG_POLICIES component on the IOR. This is legal, as far > > as I can tell, but not very efficient. > > > > We could mandate that the POA must collapse multiple TAG_POLICIES > > components into one for each IOR profile, but I think it would be better > > to add another couple of operations to the PI IORInfo interface: > > > > local interface IORInfo { > > void add_policy(in Messaging::PolicyValue pv); > > void add_policy_to_profile(in Messaging::PolicyValue pv); > > }; > > I don't think that all policies will end up under TAG_POLICIES. For example, > OTS current specifies > > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26; > > Also, I can see lots of other policies crop up over time. Do we really > want to add operations to IORInfo that are specific to particular services, > such as messaging? I thought that the Messaging stuff was for generic transport of policy data. I can see that for the OTS we should keep using the component that was defined for it, but for new policies, shouldn't they just all just ride in the generic policy tagged component? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 18 May 2000 14:04:03 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <392364F2.5EAF3AF9@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2m=!!8~od9XVPe9jTn!! On Wed, 17 May 2000, Jonathan Biggar wrote: > I thought that the Messaging stuff was for generic transport of policy > data. I can see that for the OTS we should keep using the component > that was defined for it, but for new policies, shouldn't they just all > just ride in the generic policy tagged component? But why would we then put operations into an interceptor that are specific to messaging? void add_policy(in Messaging::PolicyValue pv); ^^^^^^^^^ void add_policy_to_profile(in Messaging::PolicyValue pv); ^^^^^^^^^ Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <39238A2A.D3C77800@floorboard.com> Date: Wed, 17 May 2000 23:14:02 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]h=!!@IE!!42kd9+'@e9 Michi Henning wrote: > > On Wed, 17 May 2000, Jonathan Biggar wrote: > > > I thought that the Messaging stuff was for generic transport of policy > > data. I can see that for the OTS we should keep using the component > > that was defined for it, but for new policies, shouldn't they just all > > just ride in the generic policy tagged component? > > But why would we then put operations into an interceptor that are specific > to messaging? > > void add_policy(in Messaging::PolicyValue pv); > ^^^^^^^^^ > void add_policy_to_profile(in Messaging::PolicyValue pv); > ^^^^^^^^^ Well, I suppose if we want to decouple PI from Messaging we could use another type with the same data. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 18 May 2000 16:28:15 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <39238A2A.D3C77800@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: icc!!mVhd9=1d!!je!!! On Wed, 17 May 2000, Jonathan Biggar wrote: > > On Wed, 17 May 2000, Jonathan Biggar wrote: > > > > > I thought that the Messaging stuff was for generic transport of > > policy > > > data. I can see that for the OTS we should keep using the > > component > > > that was defined for it, but for new policies, shouldn't they > > just all > > > just ride in the generic policy tagged component? > > > > But why would we then put operations into an interceptor that are > > specific > > to messaging? > > > > void add_policy(in Messaging::PolicyValue pv); > > ^^^^^^^^^ > > void add_policy_to_profile(in Messaging::PolicyValue pv); > > ^^^^^^^^^ > > Well, I suppose if we want to decouple PI from Messaging we could > > use > another type with the same data. Hmmm... What about security? It uses a whole slew of separate tags. (I have no idea what the types of these are in each case). Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <39238CD2.F97184B2@floorboard.com> Date: Wed, 17 May 2000 23:25:22 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: lP`d9C\I!!%ZJe9mZk!! Michi Henning wrote: > > On Wed, 17 May 2000, Jonathan Biggar wrote: > > > > On Wed, 17 May 2000, Jonathan Biggar wrote: > > > > > > > I thought that the Messaging stuff was for generic transport of policy > > > > data. I can see that for the OTS we should keep using the component > > > > that was defined for it, but for new policies, shouldn't they just all > > > > just ride in the generic policy tagged component? > > > > > > But why would we then put operations into an interceptor that are specific > > > to messaging? > > > > > > void add_policy(in Messaging::PolicyValue pv); > > > ^^^^^^^^^ > > > void add_policy_to_profile(in Messaging::PolicyValue pv); > > > ^^^^^^^^^ > > > > Well, I suppose if we want to decouple PI from Messaging we could use > > another type with the same data. > > Hmmm... What about security? It uses a whole slew of separate tags. > (I have no idea what the types of these are in each case). I am proposing that we grandfather all existing tagged components that are essentially an encoded policy and strongly suggest that all other policies all be carried in a single TAG_POLICIES component for efficiency. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 18 May 2000 16:37:20 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues In-Reply-To: <39238CD2.F97184B2@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: HYpd9p%$!!m8pd9HN>!! On Wed, 17 May 2000, Jonathan Biggar wrote: > > Hmmm... What about security? It uses a whole slew of separate tags. > > (I have no idea what the types of these are in each case). > > I am proposing that we grandfather all existing tagged components that > are essentially an encoded policy and strongly suggest that all other > policies all be carried in a single TAG_POLICIES component for > efficiency. Not a bad idea. It certainly would help to have a single sequence with policy values instead of lots of single-element sequences... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Reply-To: From: "Nick Sharman" To: , "OTS RTF" Subject: RE: Interceptors FTF remaining issues Date: Thu, 18 May 2000 12:13:38 +0100 Message-ID: <005501bfc0ba$1dbb08b0$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: o&5e9e5!"!AFn!!7/7e9 Hi, We all seem to be happy that an IORInterceptor can pick up (at least some) of the Policies passed in on POA::create_POA and turn them into IOR components via IORInterceptorInfo::add_ior_to_component*. That seems to be fine for OTS & Security Policies, which appear as single top-level components. What happens if a Policy has to be placed inside a TAG_POLICIES component? At the moment, the interceptor has to: 1. For each Policy of interest: a. create an instance of the IDL struct (or whatever) that describes the on-the-wire form of the Policy; b. turn the struct from (a) into an octet sequence via a Codec; c. create an instance of Messaging::PolicyValue containing the right PolicyType and the octet; 2. create an instance of Messaging::PolicyValueSeq to contain the results of each pass through (1); 3. turn the sequence from (2) into an octet sequence via a Codec; 4. insert into the IOR via IORInterceptorInfo::add_ior_to_component*. Observations: 1. This is rather complex when the interceptor only expects to plant a single Policy in the IOR (two uses of Codec instead of one); 2. Potentially, we could have several TAG_POLICIES, each from a different service and perhaps also from the ORB itself. 3. It seems like a bad idea for IORInterceptorInfo::add_ior_to_component*. to spot incoming TAG_POLICIES in the hope of merging them into any existing TAG_POLICIES. It would seem neater to define new operations on IORInterceptorInfo: void add_ior_policy_value (in Messaging::PolicyValue policy_value); (and similarly for modifying a specific profile). Apart from this, is it really the case that Messaging::PolicyValue is intended to hold Policies defined outside Messaging? In any case, these operations introduce a dependency on the Messaging IDL that is otherwise unnecessary: it would perhaps be better to move PolicyValue and 'ownership' of TAG_POLICIES into module IOP or IOR. Similarly, we could add to ClientRequestInfo: Messaging::PolicyValue get_effective_policy (in CORBA::PolicyType ptype); (and similarly for ..._policies). These would only get the Policy from the TAG_POLICIES components; interceptors would also need to look for components that encode 'their' Policies directly. Regards Nick > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Thursday, May 18, 2000 7:37 AM > To: Jonathan Biggar > Cc: interceptors-ftf@omg.org; OTS RTF > Subject: Re: Interceptors FTF remaining issues > > > On Wed, 17 May 2000, Jonathan Biggar wrote: > > > > Hmmm... What about security? It uses a whole slew of separate tags. > > > (I have no idea what the types of these are in each case). > > > > I am proposing that we grandfather all existing tagged components that > > are essentially an encoded policy and strongly suggest that all other > > policies all be carried in a single TAG_POLICIES component for > > efficiency. > > Not a bad idea. It certainly would help to have a single sequence with > policy values instead of lots of single-element sequences... > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 May 2000 10:31:17 -0400 (EDT) From: Polar Humenn To: Nick Sharman cc: interceptors-ftf@omg.org, OTS RTF Subject: RE: Interceptors FTF remaining issues In-Reply-To: <005501bfc0ba$1dbb08b0$5610a8c0@thumper.uk.peerlogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: PA0!!l6He9pi(!!i)?!! Hi, looks like a lot on this thread over the evening, I'd thought I read through it all before replying. So, I get to this explaination of what is needed for these policy things. I'm not sure what this TAG_POLICIES component is. Uggg. I guess I have to research the messaging spec? But as Nick points out. It certainly looks complex. For security, Aside from the series of components that are in the Security Interoperability specification now, CSIv2 will end up just putting one component which will contain an ordered sequence of components. I wouldn't expect more than one interceptor to do this, but who knows what crazy ideas people begin to have. :) The IOR interceptor will be able to retrieve a policy off the POA stating the list of credentials and security mechanisms that are associated with objects in the POA and convert it to list of components and turn that list into a single IOR component. If this is bad idea, please let me know now. Cheers, -Polar On Thu, 18 May 2000, Nick Sharman wrote: > Hi, > > We all seem to be happy that an IORInterceptor can pick up (at least > some) > of the Policies passed in on POA::create_POA and turn them into IOR > components via IORInterceptorInfo::add_ior_to_component*. > > That seems to be fine for OTS & Security Policies, which appear as > single > top-level components. > > What happens if a Policy has to be placed inside a TAG_POLICIES > component? > At the moment, the interceptor has to: > > 1. For each Policy of interest: > a. create an instance of the IDL struct (or whatever) that > describes > the on-the-wire form of the Policy; > b. turn the struct from (a) into an octet sequence via a Codec; > c. create an instance of Messaging::PolicyValue containing the > right > PolicyType and the octet; > 2. create an instance of Messaging::PolicyValueSeq to contain the > results > of each pass through (1); > 3. turn the sequence from (2) into an octet sequence via a Codec; > 4. insert into the IOR via > IORInterceptorInfo::add_ior_to_component*. > > Observations: > > 1. This is rather complex when the interceptor only expects to plant > a > single Policy in the IOR (two uses of Codec instead of one); > 2. Potentially, we could have several TAG_POLICIES, each from a > different > service and perhaps also from the ORB itself. > 3. It seems like a bad idea for > IORInterceptorInfo::add_ior_to_component*. > to spot incoming TAG_POLICIES in the hope of merging them into > any > existing TAG_POLICIES. > > It would seem neater to define new operations on IORInterceptorInfo: > > void add_ior_policy_value (in Messaging::PolicyValue > policy_value); > > (and similarly for modifying a specific profile). > > Apart from this, is it really the case that Messaging::PolicyValue > is > intended to hold Policies defined outside Messaging? In any case, > these > operations introduce a dependency on the Messaging IDL that is > otherwise > unnecessary: it would perhaps be better to move PolicyValue and > 'ownership' > of TAG_POLICIES into module IOP or IOR. > > Similarly, we could add to ClientRequestInfo: > > Messaging::PolicyValue get_effective_policy (in CORBA::PolicyType > ptype); > > (and similarly for ..._policies). These would only get the Policy > from the > TAG_POLICIES components; interceptors would also need to look for > components > that encode 'their' Policies directly. > > Regards > Nick > > > > -----Original Message----- > > From: Michi Henning [mailto:michi@ooc.com.au] > > Sent: Thursday, May 18, 2000 7:37 AM > > To: Jonathan Biggar > > Cc: interceptors-ftf@omg.org; OTS RTF > > Subject: Re: Interceptors FTF remaining issues > > > > > > On Wed, 17 May 2000, Jonathan Biggar wrote: > > > > > > Hmmm... What about security? It uses a whole slew of separate > tags. > > > > (I have no idea what the types of these are in each case). > > > > > > I am proposing that we grandfather all existing tagged > components that > > > are essentially an encoded policy and strongly suggest that all > other > > > policies all be carried in a single TAG_POLICIES component for > > > efficiency. > > > > Not a bad idea. It certainly would help to have a single sequence > with > > policy values instead of lots of single-element sequences... > > > > Cheers, > > > > Michi. > > -- > > Michi Henning +61 7 3891 5744 > > Object Oriented Concepts +61 4 1118 2700 (mobile) > > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > > East Brisbane 4169 michi@ooc.com.au > > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > > > > ------------------------------------------------------------------- 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, 18 May 2000 11:42:01 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Michi Henning , Matthew Newhook , Bob Kukura , butek@us.ibm.com, interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <392348F1.2BC9D2D3@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0X""!M)N!!YRh!!hR Michi, I think the way you are supposed to do it is like this: > > 1. The application code, which knows it wants to use the OTS does > whatever magic is necessary to link in the OTS and have the OTS > register > itself with the ORB via the ORBInitializer interface. > > 2. The application calls ORB_init. > > 2. The OTS ORBInitializer registers lots of interceptor junk, > including > the factories for the OTS policies and an IOR Interceptor. > > 3. The application constructs a TransactionPolicy for > REQUIRES_SHARED > by calling ORB::create_policy(). > > 4. The application creates a POA, placing that policy object in the > list of policies in the create_POA() call. > > 5. The application creates a reference by calling > POA::create_reference(). > > 6. The POA calls the OTS IORInterceptor::establish_components(). > > 7. The OTS IORInterceptor uses IORInfo::get_effective_policy() to > retrieve the TransactionPolicy of the POA, examines it, finds > REQUIRES_SHARED, and encodes a TAG_POLICIES TaggedComponent that > contains the correct policy information for REQUIRES_SHARED. > > Now, there is a problem here, since each IORInterceptor is going to > create its own TAG_POLICIES component on the IOR. This is legal, as > far > as I can tell, but not very efficient. > > We could mandate that the POA must collapse multiple TAG_POLICIES > components into one for each IOR profile, but I think it would be > better > to add another couple of operations to the PI IORInfo interface: > > local interface IORInfo { > void add_policy(in Messaging::PolicyValue pv); > void add_policy_to_profile(in Messaging::PolicyValue pv); > }; > > Now that I've climbed out on the limb, I'll let the other > Interceptor > folks shoot me down if this isn't right. :-) > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Date: Thu, 18 May 2000 11:48:49 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: nick.sharman@peerlogic.com CC: interceptors-ftf@omg.org, OTS RTF Subject: Re: Interceptors FTF remaining issues References: <005501bfc0ba$1dbb08b0$5610a8c0@thumper.uk.peerlogic.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &(]d9j2md9JG%!!7pCe9 I just wanted to note that we, Sun, definitely agree that all policies given to create_POA should be available in the IORInterceptor (regardless of their origin). We need this to build an ORBD - we need to see the persistent lifespan policy. Cheers, Harold Date: Tue, 12 Nov 2002 17:59:52 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issue 3609 proposed resolution The following resolution will appear in a vote in the near future unless there is serious technical objection to it. Jishnu _________________________________________________________________________ Issue 3609: Overriding POA policies (interceptors-rtf) Click http://cgi.omg.org/issues/issue3609.txt for this issue's archive. Source: IONA (Mr. Michi Henning, michi@triodia.com michi.henning@iona.com) Nature: Uncategorized Issue Severity: Summary: It appears to be impossible to portably attach OTS policies to POAs with the machinery that is currently in place. We need a fix for that, otherwise OTS ends up getting hamstrung... Here is the challenge: Write portable code that results in the OTS REQUIRES_SHARED policy to be embedded into every IOR created on a particular POA. I cannot see how this can be implemented right now. Resolution: No problem in doing that. A policy is created which is handed in the PolicyList tocreate_POA. When the IORInterceptor is called get_server_policy (or whatever the API call is) retrieves the policy, if present, and establish_component is called with the REQUIRES_SHARED component. Now, a couple of anciliary things need to be fixed: 1. Remove the requirement for the registration of policy factory in section 21.5.5.1 "get_effective_policy". 2. Clarify in an appropriate place that the source of server side policies that get placed in a IOR is the POA that the IOR is created from. Both of these have already been taken care of by resolution of other issues and the current text in section 21.5.5.1 already fixes these concerns. So close this issue no change. Revised Text: Actions taken: Close no change May 15, 2000: received issue