Issue 4476: There is no way to modify a POA's ORT and append to it (ort-ftf) Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, Vijaykumar.Natarajan@borland.com) Nature: Uncategorized Issue Severity: Summary: If I wish to register an ORF (ObjectReferenceFactory) as the current factory, there is no way for it to append to the current template. In other words, an updated factory can only replace the original but not say add another profile to the one the given POA would generate w/ the adapter template. As an inverse, there is no way for a POA to require or even request an ORF to include profiles that it deems fit. Proposal: Add a parameter to make_object Object make_object( in string repositoryId, in ObjectId id, ObjectReferenceTemplate template); Add the following methods to ObjectReferenceTemplate abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory { readonly attribute ServerId server_id ; readonly attribute ORBId orb_id ; readonly attribute AdapterName adapter_name; ProfileSeq getProfiles(in string repositoryId, in ObjectId id); ComponentSeq getComponents(in IOP::ProfileId profile_id); }; where ProfileSeq is defined as module IOP { typedef sequence <TaggedProfile> ProfileSeq; typedef sequence <TaggedComponent> ComponentSeq; } Add the following sections: 21.5.3.8 getProfiles This returns the set of profiles that the POA would have generated using its default template. This can optionally be included in the generated IOR. [ED: This is independent of make_object, because make_object returns an object reference from which profiles would have to be extracted for inclusion] 21.5.3.9 getComponents This returns set of components that would have been include in the profile with the id profile_id and allows the factory to choose to include those in the profiles that it generates. Resolution: see above Revised Text: Raise an interop issue to update the appropriate version of the core spec Chapter 13 as follows: In the IDL for module IOP in section 13.6.2, add typedef sequence <TaggedProfile> TaggedProfileSeq ; and replace the anonymous sequence <TaggedProfile> with TaggedProfileSeq Update the ORT specification (ptc/01-04-03) as follows: Change the IDL for ObjectReferenceFactory in section 21.5.3.1 and in section 21.10 as follows: abstract valuetype ObjectReferenceFactory { boolean equals( in ObjectReferenceFactory other ) ; Object make_object( in string repository_id, in ObjectId id ) ; IOP::TaggedProfileSeq make_profiles( in string repository_id, in ObjectId id ) ; } ; Change section 21.5.3.3 to read (that is, delete the last two sentences in the section): make_object creates an Object Reference from this factory using the given repository ID and object ID. Add new sections: 21.5.3.4 make_profiles make_profiles returns the sequence of tagged profiles for the IOR that corresponds to the object reference that would be created by a call to make_object with the same arguments. 21.5.3.5 equals equals satisfies the usual reflexive, symmetric, and transitive properties that equality normally respects. That is, for any ObjectReferenceFactories X, Y, and Z: X.equals( X ) = true X.equals( Y ) = Y.equals( X ) if X.equals( Y ) = true and Y.equals( Z ) = true, then X.equals( Z ) = true If X and Y are different object adapters, and Xinfo and Yinfo are the IORInfo objects passed to the IORInterceptor, then Xinfo.adapter_template().equals( Yinfo.adapter_template() ) = false An equals method on a user defined ObjectReferenceFactory must return false when passed the value of an IORInfo.adapter_template attribute, unless the user defined make_profiles method returns the same ProfileSeq as the adapter_template make_profiles method when invoked with the same arguments, in which case the user defined ObjectReferenceFactory equals method may return true. renumber current sections 21.5.3.4-21.5.3.7 to 21.5.3.6-21.5.3.9 Actions taken: August 12, 2001: received issue Discussion: After a long discussion, we agreed on the following summary of this issue: Users of ORT may wish to accommodate the following two scenarios: The birth address optimization: when a persistent objref is created, include the profile(s) for the transient address of the server as well as the profile(s) that contain the permanent IOR address. In a complex system with multiple authentication servers, the IMR and other CORBA servers may not all support the same authentication policies. This leads to a need for the IMR to construct a transient objref that points to the current incarnation of a persistent server and has security information in the IOR that is appropriate for that particular server. These scenarios are somewhat awkward to address with the current ORT definition for several reasons. The issue here focuses on the following problems: A user defined IORInterceptor may need to determine whether the current_factory and adapter_template are actually the same valuetype or not. Getting access to the profiles in an object reference is quite cumbersome, and possibly not portable. Resolution: Add operations on the ObjectReferenceFactory to test for equality and generate a sequence of tagged profiles End of Annotations:===== Date: Sun, 12 Aug 2001 21:27:16 -0700 From: Vijaykumar Natarajan Subject: Re: Finishing the FTF To: Ken Cavanaugh Cc: ort-ftf@omg.org, issues@omg.org, Kay Kit Chan Message-id: <3B775724.26D3ED14@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200107301933.MAA04805@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_eQzEgTN620ST0nm9dsxQwg)" X-UIDL: 9QJe9M%Oe9-eYd9L*7e9 All, One other issue. This one a little more serious. There is no way to modify a POA's ORT and append to it (not insert components, but append profiles). If I wish to register an ORF (ObjectReferenceFactory) as the current factory, there is no way for it to append to the current template. In other words, an updated factory can only replace the original but not say add another profile to the one the given POA would generate w/ the adapter template. As an inverse, there is no way for a POA to require or even request an ORF to include profiles that it deems fit. Proposal: Add a parameter to make_object Object make_object( in string repositoryId, in ObjectId id, ObjectReferenceTemplate template); Add the following methods to ObjectReferenceTemplate abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory { readonly attribute ServerId server_id ; readonly attribute ORBId orb_id ; readonly attribute AdapterName adapter_name; ProfileSeq getProfiles(in string repositoryId, in ObjectId id); ComponentSeq getComponents(in IOP::ProfileId profile_id); }; where ProfileSeq is defined as module IOP { typedef sequence ProfileSeq; typedef sequence ComponentSeq; } Add the following sections: 21.5.3.8 getProfiles This returns the set of profiles that the POA would have generated using its default template. This can optionally be included in the generated IOR. [ED: This is independent of make_object, because make_object returns an object reference from which profiles would have to be extracted for inclusion] 21.5.3.9 getComponents This returns set of components that would have been include in the profile with the id profile_id and allows the factory to choose to include those in the profiles that it generates. --- end proposal. The use case for the getProfiles is that I want to allow my server (that is currently running and generating these references to also have its direct profiles in the list for clients to access it directly). Since ORFs are not obligated to do so, this provides either option (to include the profiles or not to). The use case for the second, I am thinking would be for, bridge implementations requiring the target codeset components or CSIV2 components or Messaging Policy components etc to be embedded in their profiles as well. Again, this is optional and is used only an as needed basis. Thanks, Vijay Ken Cavanaugh wrote: > > This is just a reminder to the members of the ORT FTF that > we need to raise any issues and resolve them so that I can > prepare the FTF report. > > Here are the dates: > > Comment deadline: August 3 > Report due: September 17 > > The Toronto meeting is September 10-14. 3 weeks before September 10 > is August 20, when we need to have the completed ORT FTF report and > specification. In order to finish on time, I need to have all of the > issues resolved by about August 13 to give time for the final editing. > > Please send any ORT issues that you have ASAP. I have one issue that > I will raise shortly. We have time for about 2 votes if necessary. > > Thanks, > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Mon, 13 Aug 2001 00:53:37 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: ort-ftf@omg.org, issues@omg.org, kkchan@borland.com MIME-Version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: MULTIPART/mixed; BOUNDARY=Rafter_of_Turkeys_714_000 X-UIDL: From: Vijaykumar Natarajan >Subject: Re: Finishing the FTF >To: Ken Cavanaugh >Cc: ort-ftf@omg.org, issues@omg.org, Kay Kit Chan > >MIME-version: 1.0 >X-Accept-Language: en > >All, > >One other issue. This one a little more serious. This is an interesting issue, but what is the use case? You need to demonstrate why this is required to satisfy the needs of the RFP (or something very closely aligned, since we already have discussed activation and load balancing, as well as fault tolerance, and I am aware of some potential uses in constructing bridges. But the only use case required in the RFP is activation). Natthew and I discussed a version of this back in January. I had a proposal that looked like (see the attachment for the entire discussion): abstract valuetype ObjectFactory { Object make_object( in String repositoryId, in Object Id ) ; void add_factory( in ObjectFactory factory ) ; } add_factory allows us to add any ObjectFactory (obviously including ObjectReferenceTemplate) to an ObjectFactory. abstract valuetype ObjectReferenceTemplate : ObjectFactory { readonly attribute ServerID server_id ; readonly attribute ORBID orb_id ; readonly attribute AdapterId adapter_id ; readonly attribute AdapterName adapter_name ; } The ObjectReferenceTemplate then simply adds the adapter-related identity information to the basic ObjectFactory. This split avoids the loss of identity problem when we try to add a template to an existing template. local interface IORInfo { ... readonly attribute ObjectReferenceTemplate primary_template ; attribute ObjectFactory factory ; } The changes since this version are: 1. I removed add_factory due to lack of a use case, and lack of input from Matthew on the object factory in general. We could certainly add it back in with an appropriate use case. One possibility is in FT, such as constructing a scalable IOGR (one that allows creation of families of object references tied together with adapters, rather than just the current object-at-a-time abstract factory). 2. ObjectFactory is now called ObjectReferenceFactory. 3. I removed ObjectReferenceTemplate::AdapterId due to lack of need for it. Let's examine this proposal in more detail. add_factory is the key here. Some other part of the system (e.g. a different server) produces an ORF that can then be combined here. However, this is probably not the correct place to put add_factory. Instead, we could place add_factory in the IORInfo interface. This is of course order sensitive, but no worse than now, since setting the current_factory attribute could take place multiple times in different IORInterceptors. The add_factory method would only be valid when setting current_factory is valid, i.e. during the IORInterceptor::components_established call. Also, this makes setting current_factory less useful, so the correct API would look like: interface IORInfo { ... readonly attribute ObjectReferenceTemplate adapter_template ; readonly attribute ObjectReferenceFactory current_factory ; void add_factory( in ObjectReferenceFactory factory ) ; } Then this could work somewhat like the original proposal (secondary template set): The current_factory is established as follows during the components_established phase: 1. If add_factory is called 0 times, the current_factory is the adapter_template. 2. If add_factory is called 1 or more times, the composition of the list of factories added is the current_factory. It is clear how to implement this: at the end of the components_established phase, we have a list of factories to use for make_object calls. Conceptually, we just take the resulting IORs corresponding to each individual make_object call, extract their profiles, and combine the profiles into the result. Details such a setting the appropriate delegate are up to the ORB implementation. > >There is no way to modify a POA's ORT and append to it (not insert >components, but append profiles). Adding a profile to an ObjectReferenceTemplate is the wrong level of abstraction. > >If I wish to register an ORF (ObjectReferenceFactory) as the current >factory, there is no way for it to append to the current template. In >other words, an updated factory can only replace the original but not >say add another profile to the one the given POA would generate w/ >the >adapter template. > >As an inverse, there is no way for a POA to require or even request >an >ORF to include profiles that it deems fit. That is not a problem here: the POA creates the ObjectReferenceFactory that is exposed to the IOR interceptor. The POA can place any/all profiles in the factory that it chooses. It's just that the user cannot currently change profiles. > >Proposal: > >Add a parameter to make_object > >Object make_object( in string repositoryId, in ObjectId id, >ObjectReferenceTemplate template); This doesn't work: where does POA::create_reference(_with_id) get the extra template from? It seems that the template could never be supplied. Also, this is contrary to what we have been doing all along: after OA creation is complete, the template is complete, and only the repoid and oid are needed. If we really want to put this back into the spec (it was there at one point), it needs to go onto ObjectReferenceTemplate. > >Add the following methods to ObjectReferenceTemplate > >abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory { > readonly attribute ServerId server_id ; > readonly attribute ORBId orb_id ; > readonly attribute AdapterName adapter_name; > ProfileSeq getProfiles(in string repositoryId, in ObjectId id); > ComponentSeq getComponents(in IOP::ProfileId profile_id); Given that there may be multiple profiles with the same id, this call would mix components from different profiles in that case, possibly losing important information. Also, nothing in the ORT spec is currently aware of IORs and their structure. This is not something that we should change, especially this late in the cycle. Of course, a template really stands for some part of one or more profiles, in cases where GIOP is the underlying transport. The Sun implementation has an explicit IIOPProfileTemplate class that takes an ObjectId to produce a complete IIOPProfile. >}; > >where ProfileSeq is defined as > >module IOP { > typedef sequence ProfileSeq; > typedef sequence ComponentSeq; >} > >Add the following sections: > >21.5.3.8 getProfiles > >This returns the set of profiles that the POA would have generated >using >its default template. This can optionally be included in the >generated >IOR. >[ED: This is independent of make_object, because make_object returns >an >object reference from which profiles would have to be extracted for >inclusion] > >21.5.3.9 getComponents >This returns set of components that would have been include in the >profile with the id profile_id and allows the factory to choose to >include those in the profiles that it generates. > >--- end proposal. > >The use case for the getProfiles is that I want to allow my server >(that >is currently running and generating these references to also have its >direct profiles in the list for clients to access it directly). Since >ORFs are not obligated to do so, this provides either option (to >include >the profiles or not to). > If this is your main use case, then it is better served by my proposal above: simply make an add_factory call with the adapter_template, and another add_factory call with whatever else you need (e.g. the factory that was received from the IMR after the OA registration). >The use case for the second, I am thinking would be for, bridge >implementations requiring the target codeset components or CSIV2 >components or Messaging Policy components etc to be embedded in their >profiles as well. Again, this is optional and is used only an as >needed >basis. > I don't see a need for ORT here. This is just the standard IOR interceptor establish_components. A bridge would need to create a new POA every time it needs to forward requests for new policy combinations. ORT cannot and should not be used here. Thanks, Ken. >From Ken.Cavanaugh@eng.sun.com Fri Jan 5 16:45:45 2001 X-Unix-From: Ken.Cavanaugh@eng.sun.com Fri Jan 5 16:45:45 2001 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA10821 for ; Fri, 5 Jan 2001 16:45:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA27547 for ; Fri, 5 Jan 2001 16:45:42 -0800 (PST) Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18399 for ; Fri, 5 Jan 2001 16:45:41 -0800 (PST) Received: from emerald.omg.org (emerald.omg.org [192.67.184.65]) by mail.acm.org (8.9.3/8.9.3) with ESMTP id TAA129128 for ; Fri, 5 Jan 2001 19:45:38 -0500 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by emerald.omg.org (8.11.0/8.9.2) with ESMTP id f060gBa03086 for ; Fri, 5 Jan 2001 19:42:11 -0500 (EST) Received: from taller.eng.sun.com ([129.144.124.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18359; Fri, 5 Jan 2001 16:45:33 -0800 (PST) Received: from montara (montara [129.144.251.170]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id QAA10802; Fri, 5 Jan 2001 16:45:31 -0800 (PST) Message-Id: <200101060045.QAA10802@taller.eng.sun.com> Date: Fri, 5 Jan 2001 16:45:20 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: object reference template To: matthew@ooc.com Cc: ort-submitters@omg.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aTzUdfyK4GFTEBgrBk6pmg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc >From: Matthew Newhook >To: Ken Cavanaugh >Cc: ort-submitters@omg.org >Subject: Re: object reference template >Mime-Version: 1.0 >Content-Disposition: inline >User-Agent: Mutt/1.2.5i > >Hi Ken, > >On Thu, Jan 04, 2001 at 04:41:01PM -0800, Ken Cavanaugh wrote: >> ... >> I was thinking of an attribute for a sequence of secondary >templates >> after the earlier discussion about load balancing. > >The problem that I see is that there is no identity information on a >template. Every template has server ID, ORB ID, and adapter ID. A primary template can only be created in the POA through create_POA, which means that a unique identity for a POA is a unique identity for a template. How unique this is depends on the scope of the server ID, but the framework can make the server ID as unique as is required. >If it there turns out to be more than one template I don't >know how I could find the one that I want to replace (consider the >load balancing case that I outlined below). OTOH, perhaps this isn't >a >problem... Perhaps the right thing to do in this case is to take the >entire sequence of templates and exchange all of them with the load >balancing daemon and replace the contents of the sequence with the >load >balancers template... This requires more thinking :) I agree that exchanging the whole sequence is probably the right thing to do. However, it is difficult to view a sequence of templates as a template, since any template must have server ID/ORB ID/adapter ID. > >From your other mail: > >> I think it would be helpful if you explained in more detail some of >> your models for load balancing and how this could be done using >> ORT. I have been thinking about this a bit, but there are a lot >> of possibilities. > >Basically one of the models of the load balancing stuff we are doing >involves a central daemon that acts much like an IMR. This daemon is >responsible for location forwarding clients to the location of the least >loaded server (according to whatever load balancing algorithm is being >used). If an IMR is involved in the works then the load balancer should >loc-forward to the IMR and not the server -- in this case the >templates need to be exchanged as I previously explained. The nice thing >is that neither the load balancer nor the IMR are aware of this -- it's >all driven by the server. The trick is, of course, to ensure that the >IOR interceptors run in the correct order - so the exchange is done >in the correct order. > I think I see what you mean. The server does a template exchange first with the IMR, then with the LB agent. At that point, the IMR points at the server, the server at the LBA, and the LBA at the IMR. An object creation in the server results in an object pointing to the LBA. An invocation goes first to the LBA, the LBA choose a server, and forwards the request to the IMR, which forwards the request to the server. This seems to me to be an excellent use case for ORT. It is perhaps outside of the scope of the RFP, but I still think we should support this. The question is, exactly how? The reason that I created the secondary template set in the first place was to avoid discussions about ordering. The easiest solution to your scenario is I think the following: local interface IORInfo { ... readonly attribute ObjectReferenceTemplate primary_template ; attribute ObjectReferenceTemplate secondary_template ; } which you have already alluded to. The primary use case of the RFP is then handled by a single IORInterceptor that sets the secondary template. The more sophisticated LB case requires consideration of ordering of the IOR interceptors. As usual, we could simply state that this is handled administratively, leaving this issue undefined. By the way, in our ORB, we do care about ordering in some cases. We handle this by checking to see whether the Java interceptor classes implement Comparable. For any interceptors of the same type that implement Comparable, we sort these, and place them in the interceptor list of that type before the unsorted ones. This makes it easy to deal with whatever kind of ordering is required. Of course, this is a somewhat Java-centric solution to the ordering problem. The remaining question I have is whether the capability of having a sequence of templates (typically each template corresponds to a GIOP tagged profile) is useful for this submission. I have briefly thought about using it for creating IOGRs. Looking at the CORBA FT replication manager, it seems that the API is so far away from ORB APIs like the POA that little can be said about implementing it. I'm not sure what approach might be best for implementing it, but the spec seems to be looking at the problem as replicating a single object rather than a group of related objects. Here is one way we could define the API to handle sequences of templates: abstract valuetype ObjectFactory { Object make_object( in String repositoryId, in Object Id ) ; void add_factory( in ObjectFactory factory ) ; } add_factory allows us to add any ObjectFactory (obviously including ObjectReferenceTemplate) to an ObjectFactory. abstract valuetype ObjectReferenceTemplate : ObjectFactory { readonly attribute ServerID server_id ; readonly attribute ORBID orb_id ; readonly attribute AdapterId adapter_id ; readonly attribute AdapterName adapter_name ; } The ObjectReferenceTemplate then simply adds the adapter-related identity information to the basic ObjectFactory. This split avoids the loss of identity problem when we try to add a template to an existing template. local interface IORInfo { ... readonly attribute ObjectReferenceTemplate primary_template ; attribute ObjectFactory factory ; } The factory can be access, updated, and replaced through this API. Ordering considerations now matter a lot, but the spec can sidestep this issue as administrative, and implementations can choose interesting ways to resolve this as I mentioned above. Like so many CORBA specs, CORBA FT is incomplete in considering how to map the implementation onto the ORB. I would like to see any new mechanisms like CORBA FT, LB, CSIv2, etc. designed so that they can be build outside of the ORB using only standard CORBA APIs. This is not possible today for any of these. Finally, I would like to point out that the most important use case for ORT is the server activation framework. I'm happy to support load balancing as well. I am less certain about keeping the ability to merge templates in some form, but I do want to continue exploring the capability before we decide to remove it completely. Thanks, Ken. Date: Mon, 13 Aug 2001 02:31:07 -0700 From: Vijaykumar Natarajan Subject: Re: Finishing the FTF To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com Message-id: <3B779E5B.25F10D55@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108130753.AAA08130@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_Hut3sCmjpyI4egtoO/AQRQ)" X-UIDL: LB-e9;ffd9jHRd9]R=e9 Hi Ken, Ken Cavanaugh wrote: > > >From: Vijaykumar Natarajan > >Subject: Re: Finishing the FTF > >To: Ken Cavanaugh > >Cc: ort-ftf@omg.org, issues@omg.org, Kay Kit Chan > >MIME-version: 1.0 > >X-Accept-Language: en > > > >All, > > > >One other issue. This one a little more serious. > > This is an interesting issue, but what is the use case? You need > to demonstrate why this is required to satisfy the needs of the RFP > (or something very closely aligned, since we already have discussed > activation and load balancing, as well as fault tolerance, and I am > aware of some potential uses in constructing bridges. But the only > use case required in the RFP is activation). As I pointed out, the simplest use case is that of me wanting to have my clients contact me directly, w/o going through the impl rep, since the server is already running and fail over to the impl rep when the server goes away. > > Natthew and I discussed a version of this back in January. I had a > proposal > that looked like (see the attachment for the entire discussion): > > abstract valuetype ObjectFactory { > Object make_object( in String repositoryId, in > Object Id ) ; > void add_factory( in ObjectFactory factory ) ; > } > > add_factory allows us to add any ObjectFactory (obviously > including > ObjectReferenceTemplate) to an ObjectFactory. > > abstract valuetype ObjectReferenceTemplate : ObjectFactory { > readonly attribute ServerID server_id ; > readonly attribute ORBID orb_id ; > readonly attribute AdapterId adapter_id ; > readonly attribute AdapterName adapter_name ; > } > > The ObjectReferenceTemplate then simply adds the > adapter-related > identity information to the basic ObjectFactory. This split > avoids the > loss of identity problem when we try to add a template to an > existing > template. > > local interface IORInfo { > ... > readonly attribute ObjectReferenceTemplate > primary_template ; > attribute ObjectFactory factory ; > } > > The changes since this version are: > > 1. I removed add_factory due to lack of a use case, and lack of > input from > Matthew on the object factory in general. We could certainly add > it > back in with an appropriate use case. One possibility is in FT, > such > as constructing a scalable IOGR (one that allows creation of > families > of object references tied together with adapters, rather than > just > the current object-at-a-time abstract factory). > > 2. ObjectFactory is now called ObjectReferenceFactory. > > 3. I removed ObjectReferenceTemplate::AdapterId due to lack of need > for it. > > Let's examine this proposal in more detail. > add_factory is the key here. Some other part of the system (e.g. a > different > server) produces an ORF that can then be combined here. However, > this is > probably not the correct place to put add_factory. Instead, we > could place > add_factory in the IORInfo interface. This is of course order > sensitive, but > no worse than now, since setting the current_factory attribute could > take place multiple times in different IORInterceptors. The > add_factory > method would only be valid when setting current_factory is valid, > i.e. > during the IORInterceptor::components_established call. Also, this > makes > setting current_factory less useful, so the correct API would look > like: > > interface IORInfo { > ... > readonly attribute ObjectReferenceTemplate adapter_template ; > readonly attribute ObjectReferenceFactory current_factory ; > void add_factory( in ObjectReferenceFactory factory ) ; > } > > Then this could work somewhat like the original proposal (secondary > template > set): > > The current_factory is established as follows during the > components_established > phase: > > 1. If add_factory is called 0 times, the current_factory is the > adapter_template. > > 2. If add_factory is called 1 or more times, the composition of the > list of factories added is the current_factory. > > It is clear how to implement this: at the end of the > components_established > phase, we have a list of factories to use for make_object calls. > Conceptually, > we just take the resulting IORs corresponding to each individual > make_object > call, extract their profiles, and combine the profiles into the > result. The reason I think exposing profiles is better than not, is that the standard way of extracting profiles out of an Object reference is quite painful. Think about all the steps to do that, with just standard interfaces. > Details such a setting the appropriate delegate are up to the ORB > implementation. > > > > >There is no way to modify a POA's ORT and append to it (not insert > >components, but append profiles). > > Adding a profile to an ObjectReferenceTemplate is the wrong level > of abstraction. Why is that so? An object reference template is just that. A template for object references and an object reference contains profiles. > > > > >If I wish to register an ORF (ObjectReferenceFactory) as the current > >factory, there is no way for it to append to the current template. In > >other words, an updated factory can only replace the original but not > >say add another profile to the one the given POA would generate w/ the > >adapter template. > > > >As an inverse, there is no way for a POA to require or even request an > >ORF to include profiles that it deems fit. > > That is not a problem here: the POA creates the ObjectReferenceFactory that > is exposed to the IOR interceptor. The POA can place any/all profiles > in the factory that it chooses. It's just that the user cannot currently > change profiles. The problem is this. If an IORIntercetpor sets the current_factory, the POA has no control over what that current_factory (which is user code), but must use the reference generated from it. > > > > >Proposal: > > > >Add a parameter to make_object > > > >Object make_object( in string repositoryId, in ObjectId id, > >ObjectReferenceTemplate template); > > This doesn't work: where does POA::create_reference(_with_id) get the > extra template from? It seems that the template could never be supplied. Notice that there is a default template that is set up for the POA to construct object references in the absence of a current_factory override. That's the template I am talking about. (Ie. if nobody IORInterceptor called current_factory and set the factory there would be the default that hte POA would use to create object references. that's the one that is passed). > > Also, this is contrary to what we have been doing all along: after > OA creation > is complete, the template is complete, and only the repoid and oid > are needed. If we really want to put this back into the spec (it > was > there at one point), it needs to go onto ObjectReferenceTemplate. The template is certainly complete. The interaction I was thinking of is as follows: establish_components is being called to modify the template. If no current_factory is installed, then this is the template that would be used to manufacture object references. Now components_established is called. Here, if there is a current_factory override, then those profiles that the template would have created should go into the IOR generated by current_factory. So, when current_factory is called to make_object, the adapter template that was constructed at establish_components time, is passed. The implementation of current_factory calls getProfiles and adds them to the IOR it is creating. In addition, it may call getComponents(profileID) for all profiles that it is going to add and potentially copies some components. > > > > >Add the following methods to ObjectReferenceTemplate > > > >abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory { > > readonly attribute ServerId server_id ; > > readonly attribute ORBId orb_id ; > > readonly attribute AdapterName adapter_name; > > ProfileSeq getProfiles(in string repositoryId, in ObjectId id); > > ComponentSeq getComponents(in IOP::ProfileId profile_id); > > Given that there may be multiple profiles with the same id, this call would > mix components from different profiles in that case, possibly losing > important information. Also, nothing in the ORT spec is currently aware > of IORs and their structure. This is not something that we should change, > especially this late in the cycle. First, the mixing components is not an issue, as IORinfo interface to add components also does the same thing (in the presence of multiple profiles w/ the same ID, I presume this component is added to all) and so this should have hte same semantics. Second, I don't see how there is no knowledge of IOR structure. The sole goal of the ORT is to create object references by manipulating IORs. secondly IORInfo does have Profiles and Components referenced. > > Of course, a template really stands for some part of one or more > profiles, > in cases where GIOP is the underlying transport. The Sun > implementation > has an explicit IIOPProfileTemplate class that takes an ObjectId to > produce > a complete IIOPProfile. > > >}; > > > >where ProfileSeq is defined as > > > >module IOP { > > typedef sequence ProfileSeq; > > typedef sequence ComponentSeq; > >} > > > >Add the following sections: > > > >21.5.3.8 getProfiles > > > >This returns the set of profiles that the POA would have generated using > >its default template. This can optionally be included in the generated > >IOR. > >[ED: This is independent of make_object, because make_object returns an > >object reference from which profiles would have to be extracted for > >inclusion] > > > >21.5.3.9 getComponents > >This returns set of components that would have been include in the > >profile with the id profile_id and allows the factory to choose to > >include those in the profiles that it generates. > > > >--- end proposal. > > > >The use case for the getProfiles is that I want to allow my server (that > >is currently running and generating these references to also have its > >direct profiles in the list for clients to access it directly). Since > >ORFs are not obligated to do so, this provides either option (to include > >the profiles or not to). > > > > If this is your main use case, then it is better served by my proposal > above: simply make an add_factory call with the adapter_template, and > another add_factory call with whatever else you need (e.g. the > factory that was received from the IMR after the OA registration). That as I mentioned is quite painful to do, but I have to pull apart each object reference only to recreate a single object reference. > > >The use case for the second, I am thinking would be for, bridge > >implementations requiring the target codeset components or CSIV2 > >components or Messaging Policy components etc to be embedded in their > >profiles as well. Again, this is optional and is used only an as needed > >basis. > > > > I don't see a need for ORT here. This is just the standard IOR interceptor > establish_components. A bridge would need to create a new POA every time it > needs to forward requests for new policy combinations. ORT cannot and > should not be used here. I am afraid you got me wrong here. This requirement is not to implement a bridge. This is on the server side. let's take an activation example: My servers support a subset of available authorization servers. My impl rep supports all. I wish that my impl rep authorize the user before forwarding the user to the server. The info about authorization servers is in the server's IIOP profile's components, based on say some POA policies. To support this, the object reference factory that is registered by my impl rep, on the server (which will dish out references pointing to my impl rep) must extract the specific component out of the real IOR and add it to the IOR that it generates. Make sense? Finally. I realized this is not only useful, but certainly needed. When I call create_reference_with_id on a POA (or using any other method that returns a reference), the resultant IOR must come from the current_factory.make_object(). If I make a colocated call on that object reference, I now have to go to my ImplRep before I get to the object that is colocated. Very bad. Vijay > > Thanks, > > Ken. > > ------------------------------------------------------------------------ > > Subject: Re: object reference template > Date: Fri, 05 Jan 2001 16:45:20 -0800 (PST) > From: Ken Cavanaugh > To: matthew@ooc.com > CC: ort-submitters@omg.org > > >From: Matthew Newhook > >To: Ken Cavanaugh > >Cc: ort-submitters@omg.org > >Subject: Re: object reference template > >Mime-Version: 1.0 > >Content-Disposition: inline > >User-Agent: Mutt/1.2.5i > > > >Hi Ken, > > > >On Thu, Jan 04, 2001 at 04:41:01PM -0800, Ken Cavanaugh wrote: > >> ... > >> I was thinking of an attribute for a sequence of secondary > templates > >> after the earlier discussion about load balancing. > > > >The problem that I see is that there is no identity information on > a > >template. > > Every template has server ID, ORB ID, and adapter ID. A primary > template > can only be created in the POA through create_POA, which means that > a > unique identity for a POA is a unique identity for a template. How > unique > this is depends on the scope of the server ID, but the framework can > make the server ID as unique as is required. > > >If it there turns out to be more than one template I don't > >know how I could find the one that I want to replace (consider the > >load balancing case that I outlined below). OTOH, perhaps this > isn't a > >problem... Perhaps the right thing to do in this case is to take > the > >entire sequence of templates and exchange all of them with the load > >balancing daemon and replace the contents of the sequence with the > load > >balancers template... This requires more thinking :) > > I agree that exchanging the whole sequence is probably the right > thing to > do. However, it is difficult to view a sequence of templates as a > template, since any template must have server ID/ORB ID/adapter ID. > > > >From your other mail: > > > >> I think it would be helpful if you explained in more detail some > of > >> your models for load balancing and how this could be done using > >> ORT. I have been thinking about this a bit, but there are a lot > >> of possibilities. > > > >Basically one of the models of the load balancing stuff we are > doing > >involves a central daemon that acts much like an IMR. This daemon > is > >responsible for location forwarding clients to the location of the > least > >loaded server (according to whatever load balancing algorithm is > being > >used). If an IMR is involved in the works then the load balancer > should > >loc-forward to the IMR and not the server -- in this case the > >templates need to be exchanged as I previously explained. The nice > thing > >is that neither the load balancer nor the IMR are aware of this -- > it's > >all driven by the server. The trick is, of course, to ensure that > the > >IOR interceptors run in the correct order - so the exchange is done > >in the correct order. > > > > I think I see what you mean. The server does a template exchange > first > with the IMR, then with the LB agent. At that point, the IMR points > at > the server, the server at the LBA, and the LBA at the IMR. An > object > creation in the server results in an object pointing to the LBA. An > invocation goes first to the LBA, the LBA choose a server, and > forwards > the request to the IMR, which forwards the request to the server. > > This seems to me to be an excellent use case for ORT. It is perhaps > outside of the scope of the RFP, but I still think we should support > this. The question is, exactly how? > > The reason that I created the secondary template set in the first > place > was to avoid discussions about ordering. The easiest solution to > your scenario is I think the following: > > local interface IORInfo { > ... > readonly attribute ObjectReferenceTemplate primary_template > ; > attribute ObjectReferenceTemplate secondary_template ; > } > > which you have already alluded to. The primary use case of the RFP > is then handled by a single IORInterceptor that sets the secondary > template. > > The more sophisticated LB case requires consideration of ordering of > the IOR interceptors. As usual, we could simply state that this is > handled administratively, leaving this issue undefined. > > By the way, in our ORB, we do care about ordering in some cases. > We handle this by checking to see whether the Java interceptor > classes > implement Comparable. For any interceptors of the same type that > implement Comparable, we sort these, and place them in the > interceptor > list of that type before the unsorted ones. This makes it easy to > deal with whatever kind of ordering is required. Of course, this is > a > somewhat Java-centric solution to the ordering problem. > > The remaining question I have is whether the capability of having a > sequence of templates (typically each template corresponds to a GIOP > tagged profile) is useful for this submission. I have briefly > thought > about using it for creating IOGRs. Looking at the CORBA FT > replication > manager, it seems that the API is so far away from ORB APIs like the > POA > that little can be said about implementing it. I'm not sure what > approach might be best for implementing it, but the spec seems to be > looking at the problem as replicating a single object rather than a > group of related objects. > > Here is one way we could define the API to handle sequences of > templates: > > abstract valuetype ObjectFactory { > Object make_object( in String repositoryId, in Object Id ) ; > void add_factory( in ObjectFactory factory ) ; > } > > add_factory allows us to add any ObjectFactory (obviously including > ObjectReferenceTemplate) to an ObjectFactory. > > abstract valuetype ObjectReferenceTemplate : ObjectFactory { > readonly attribute ServerID server_id ; > readonly attribute ORBID orb_id ; > readonly attribute AdapterId adapter_id ; > readonly attribute AdapterName adapter_name ; > } > > The ObjectReferenceTemplate then simply adds the adapter-related > identity information to the basic ObjectFactory. This split avoids > the > loss of identity problem when we try to add a template to an > existing > template. > > local interface IORInfo { > ... > readonly attribute ObjectReferenceTemplate primary_template > ; > attribute ObjectFactory factory ; > } > > The factory can be access, updated, and replaced through this API. > Ordering considerations now matter a lot, but the spec can sidestep > this issue as administrative, and implementations can choose > interesting > ways to resolve this as I mentioned above. > > Like so many CORBA specs, CORBA FT is > incomplete in considering how to map the implementation onto the > ORB. > I would like to see any new mechanisms like CORBA FT, LB, CSIv2, > etc. > designed so that they can be build outside of the ORB using only > standard CORBA APIs. This is not possible today for any of these. > > Finally, I would like to point out that the most important use case > for ORT is the server activation framework. I'm happy to support > load balancing as well. I am less certain about keeping the ability > to merge templates in some form, but I do want to continue exploring > the capability before we decide to remove it completely. > > Thanks, > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Mon, 13 Aug 2001 11:56:52 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com MIME-Version: 1.0 Content-MD5: kOH3s3R6qG7hTzGoRwXDXw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: cV$!!-G#!!+0P!!m\&!! Ok, the use cases you have in mind are coming into focus better now. You have: 1. The birth address optimization: when a persistent objref is created, include the profile(s) for the transient address of the server as well as the profile(s) that contain the permanent IOR address. Discussion: this is both useful and common, but of course non-portable. How do you intend to inform the client about which address or profile is preferred? Would you like to use an ALTERNATE_IIOP_ADDRESS component instead in some cases? How would you arrange that if you wanted to? 2. In a complex system with multiple authentication servers, the IMR and other CORBA servers may not all support the same authentication policies (this one is familiar; we looked at it in the NEO days at Sun around 1995-96. We also gave it some consideration during the ORT design, although the discussion does not show in the archives). Discussion: perhaps not common except in very complex systems, but vital to support. So, on to interfaces: First, the general create an objref/fiddle with its IOR representation/ convert to objref again scenario is ugly and cumbersome. Just for reference, let's list the whole thing: 1. Somehow I have objref x. 2. Create an output stream os from a handy ORB (possibly from X, but it doesn't really matter) 3. os.write_object( x ) 4. is = os.create_input_stream() 5. IOR ior = new IOR() 6. IORHelper.read( is ) So now ior contains the profiles in the standard IIOP encoding. If we need to split things apart further, we use codecs to open up the CDR encapsulations. The first thing you are trying to avoid is steps 1-6 above to get to the profiles. The correct place to do this is on the ObjectReferenceFactory, since it is exactly equivalent to make_object. I need to emphasize that your getProfiles operation is not merely looking up profiles (as I think you realize); it is doing exactly the same thing as make_object, only returning the results as a sequence of profiles. It could either return an IOP::IOR or just a sequence of profiles, as you define. In general, I'm not sure that you need the repoid, since you are not constructing an entire IOR. For components, you are assuming that all tagged component are independent of the object id (is that always true? What about DCE?). Under these two assumptions, I would prefer to see abstract valuetype ObjectReferenceFactory { boolean equals( in ObjectReferenceFactory other ) ; Object make_object( in String repositoryid, in ObjectId id, in ObjectReferenceTemplate adapter_template ) ; ProfileSeq make_profiles( in ObjectId id ) ; ComponentSeq get_components( in IOP::ProfileId profile_id ) ; } and then ObjectReferenceTemplate is unchanged. Now, the rest of this issue really centers on how to create objrefs that contain some of the information in the original template. This amounts to saying that the ORB registers another IOR inteceptor that always runs last as follows: 1. The ORB/POA arranges for an IOR Interceptor to be created that always runs last (as usual, the orderining is proprietary) 2. This IORInterceptor compares the adapter_template and current_factory. Equality can either be at the mapping level, or else a small change can be added to introduce equality to the ObjectReferenceFactory (I would rather add the equals method, I think). 3. If the adapter_template and the current_factory are different, the IORInterceptor writes to current_factory with another factory that delegates to the previous current_factory. In other words: class LastInterceptor : IORInterceptor { void components_established( IORInfo info ) { ObjectReferenceFactory old = info.current_factory() ; ObjectReferenceFactory orig = info.adapter_template() ; if (!orig.equals( old )) { ObjectReferenceFactory newfactory = new MyFactory( old ) ; info.current_factory( newfactory ) ; } } ... } Then MyFactory.make_object looks something like: Object make_object( String repoid, byte[] oid, ObjectReferenceTemplate temp ) { Profile[] psold = old.make_profiles( oid ) ; ProfileS[] pstemp = temp.make_profiles( oid ) ; IOR result = new IOR() ; result.type_id = repoid ; Profile[] resultProfiles = new Profile()[ psold.length + pstemp.length]; // copy psold and pstemp to resultProfiles, or whatever part of // psold is needed in this case. result.profile_data = resultProfiles ; // ulgy conversion to objectref: we should think about // creating utilities for IOR<->objref conversion } and actually the above is the implementation of make_profiles. Note that make_profiles applies to the object on which it is invoked; I don't think your proposal to make it operate on the original (POA created) template instead is necessary. Ken. Date: Mon, 13 Aug 2001 12:58:30 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: HSLSf09FoSEZCoeWZWfNfw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: /1F!!>HD!!FP,e9bdMe9 Some additional thoughts (I thought about it some more during my 50 minute commute to Cupertino): >From: Ken Cavanaugh >Subject: Re: Finishing the FTF >To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com >Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, >kkchan@borland.com >MIME-Version: 1.0 >Content-MD5: kOH3s3R6qG7hTzGoRwXDXw== > >First, the general create an objref/fiddle with its IOR representation/ >convert to objref again scenario is ugly and cumbersome. Just for >reference, let's list the whole thing: > >1. Somehow I have objref x. >2. Create an output stream os from a handy ORB (possibly from X, but it > doesn't really matter) >3. os.write_object( x ) >4. is = os.create_input_stream() >5. IOR ior = new IOR() >6. IORHelper.read( is ) > >So now ior contains the profiles in the standard IIOP encoding. If we need >to split things apart further, we use codecs to open up the CDR encapsulations. > >The first thing you are trying to avoid is steps 1-6 above to get to the >profiles. The correct place to do this is on the ObjectReferenceFactory, >since it is exactly equivalent to make_object. I need to emphasize that >your getProfiles operation is not merely looking up profiles (as I think you >realize); it is doing exactly the same thing as make_object, only returning >the results as a sequence of profiles. It could either return an IOP::IOR >or just a sequence of profiles, as you define. In general, I'm not sure that >you need the repoid, since you are not constructing an entire IOR. For >components, you are assuming that all tagged component are independent of the >object id (is that always true? What about DCE?). Under these two assumptions, >I would prefer to see > >abstract valuetype ObjectReferenceFactory { > boolean equals( in ObjectReferenceFactory other ) ; > Object make_object( in String repositoryid, in ObjectId id, > in ObjectReferenceTemplate adapter_template ) ; > ProfileSeq make_profiles( in ObjectId id ) ; > ComponentSeq get_components( in IOP::ProfileId profile_id ) ; >} > actually we don't need to pass the adapter_template to make_object, as we see below. >and then ObjectReferenceTemplate is unchanged. > >Now, the rest of this issue really centers on how to create objrefs >that contain >some of the information in the original template. This amounts to >saying >that the ORB registers another IOR inteceptor that always runs last >as follows: > >1. The ORB/POA arranges for an IOR Interceptor to be created that >always > runs last (as usual, the orderining is proprietary) > >2. This IORInterceptor compares the adapter_template and >current_factory. > Equality can either be at the mapping level, or else a small >change can > be added to introduce equality to the ObjectReferenceFactory (I >would > rather add the equals method, I think). > >3. If the adapter_template and the current_factory are different, the > IORInterceptor writes to current_factory with another factory that > delegates to the previous current_factory. > >In other words: > >class LastInterceptor : IORInterceptor { > > void components_established( IORInfo info ) > { > ObjectReferenceFactory old = info.current_factory() ; > ObjectReferenceFactory orig = >info.adapter_template() ; > if (!orig.equals( old )) { > ObjectReferenceFactory newfactory = > new MyFactory( old ) ; > info.current_factory( newfactory ) ; > } > } > > ... >} > >Then MyFactory.make_object looks something like: > >Object make_object( String repoid, byte[] oid, >ObjectReferenceTemplate temp ) >{ > Profile[] psold = old.make_profiles( oid ) ; > > ProfileS[] pstemp = temp.make_profiles( oid ) ; > > IOR result = new IOR() ; > > result.type_id = repoid ; > > Profile[] resultProfiles = new Profile()[ psold.length + >pstemp.length]; > > // copy psold and pstemp to resultProfiles, or whatever part >of > // psold is needed in this case. > > result.profile_data = resultProfiles ; > > // ulgy conversion to objectref: we should think about > // creating utilities for IOR<->objref conversion >} > >and actually the above is the implementation of make_profiles. >Note that make_profiles applies to the object on which it is invoked; >I don't think your proposal to make it operate on the >original (POA created) template instead is necessary. > Thinking about this some more, what we really need is: 1. Convient conversion operations (probably on the ORB) to go between objrefs and IORs (I am not sure that the procedure outlined above is strictly portable, although it seems likely to work on most ORBs). 2. Equality checking on ObjectReferenceFactories, or an attribute to indicate that the current_factory has been modified. 3. Adminstrative ordering of IORInterceptors (nothing new here. There are lots of cases where this is needed in general). I think the only part that affects ORT is 2. Also, the getComponents method is not necessary, as this is exactly what codecs are defined for. If a convenience method is really necessary, I would see it as a PI issue, rather than ORT. Thanks, Ken. Date: Mon, 13 Aug 2001 14:19:41 -0700 From: Vijaykumar Natarajan Subject: Re: Finishing the FTF To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com Message-id: <3B78446D.D4819D64@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108131958.MAA21044@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_hQma9KR7yLsNzHdDL1XPBw)" X-UIDL: )e@e9?Ukd97F^d9Ck'!! Ken, Ken Cavanaugh wrote: > > Some additional thoughts (I thought about it some more during my 50 minute > commute to Cupertino): > > >From: Ken Cavanaugh > >Subject: Re: Finishing the FTF > >To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com > >Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com > >MIME-Version: 1.0 > >Content-MD5: kOH3s3R6qG7hTzGoRwXDXw== > > > > >First, the general create an objref/fiddle with its IOR representation/ > >convert to objref again scenario is ugly and cumbersome. Just for > >reference, let's list the whole thing: > > > >1. Somehow I have objref x. > >2. Create an output stream os from a handy ORB (possibly from X, but it > > doesn't really matter) > >3. os.write_object( x ) > >4. is = os.create_input_stream() > >5. IOR ior = new IOR() > >6. IORHelper.read( is ) > > > >So now ior contains the profiles in the standard IIOP encoding. If we need > >to split things apart further, we use codecs to open up the CDR encapsulations. > > > >The first thing you are trying to avoid is steps 1-6 above to get to the > >profiles. The correct place to do this is on the ObjectReferenceFactory, > >since it is exactly equivalent to make_object. I need to emphasize that > >your getProfiles operation is not merely looking up profiles (as I think you > >realize); it is doing exactly the same thing as make_object, only returning > >the results as a sequence of profiles. It could either return an IOP::IOR > >or just a sequence of profiles, as you define. In general, I'm not sure that > >you need the repoid, since you are not constructing an entire IOR. For > >components, you are assuming that all tagged component are independent of the > >object id (is that always true? What about DCE?). Under these two > assumptions, > >I would prefer to see > > > >abstract valuetype ObjectReferenceFactory { > > boolean equals( in ObjectReferenceFactory other ) ; > > Object make_object( in String repositoryid, in ObjectId id, > > in ObjectReferenceTemplate adapter_template ) ; > > ProfileSeq make_profiles( in ObjectId id ) ; > > ComponentSeq get_components( in IOP::ProfileId profile_id ) ; > >} > > > > actually we don't need to pass the adapter_template to make_object, as we > see below. I don't get it. MyFactory.make_object takes and uses an ORT (It could be an ORF, now that you've moved the methods to the ORF). > > >and then ObjectReferenceTemplate is unchanged. > > > >Now, the rest of this issue really centers on how to create objrefs that > contain > >some of the information in the original template. This amounts to saying > >that the ORB registers another IOR inteceptor that always runs last > >as follows: > > > >1. The ORB/POA arranges for an IOR Interceptor to be created that always > > runs last (as usual, the orderining is proprietary) > > > >2. This IORInterceptor compares the adapter_template and current_factory. > > Equality can either be at the mapping level, or else a small change can > > be added to introduce equality to the ObjectReferenceFactory (I would > > rather add the equals method, I think). > > > >3. If the adapter_template and the current_factory are different, the > > IORInterceptor writes to current_factory with another factory that > > delegates to the previous current_factory. > > > >In other words: > > > >class LastInterceptor : IORInterceptor { > > > > void components_established( IORInfo info ) > > { > > ObjectReferenceFactory old = info.current_factory() ; > > ObjectReferenceFactory orig = info.adapter_template() ; > > if (!orig.equals( old )) { > > ObjectReferenceFactory newfactory = > > new MyFactory( old ) ; > > info.current_factory( newfactory ) ; > > } > > } > > > > ... > >} > > > >Then MyFactory.make_object looks something like: > > > >Object make_object( String repoid, byte[] oid, ObjectReferenceTemplate temp ) > >{ > > Profile[] psold = old.make_profiles( oid ) ; > > > > ProfileS[] pstemp = temp.make_profiles( oid ) ; > > > > IOR result = new IOR() ; > > > > result.type_id = repoid ; > > > > Profile[] resultProfiles = new Profile()[ psold.length + pstemp.length]; > > > > // copy psold and pstemp to resultProfiles, or whatever part of > > // psold is needed in this case. > > > > result.profile_data = resultProfiles ; > > > > // ulgy conversion to objectref: we should think about > > // creating utilities for IOR<->objref conversion > >} > > > >and actually the above is the implementation of make_profiles. > >Note that make_profiles applies to the object on which it is invoked; > >I don't think your proposal to make it operate on the > >original (POA created) template instead is necessary. > > > > Thinking about this some more, what we really need is: > > 1. Convient conversion operations (probably on the ORB) to go between > objrefs and IORs (I am not sure that the procedure outlined above > is strictly portable, although it seems likely to work on most ORBs). I agree, in fact I just posted that issue before reading this mail ;-) > > 2. Equality checking on ObjectReferenceFactories, or an attribute to indicate > that the current_factory has been modified. Agreed. > > 3. Adminstrative ordering of IORInterceptors (nothing new here. There are > lots of cases where this is needed in general). Can we do something as simple as raise an error if a _set_current_factory is called more than once? Because either way, only one factory can be registered and it would be nice to not fail silently. > > I think the only part that affects ORT is 2. Also, the > getComponents method > is not necessary, as this is exactly what codecs are defined for. > If a > convenience method is really necessary, I would see it as a PI > issue, rather > than ORT. This is a convenience method for the ORT. It allows my factory (which creates IOR) collect and evaluate the components that have been added as part of establish_components. Since this is a part of the factory's operation, I would see it as totally applicable here. If I used codecs, here's what I would have to do. I would have to get profiles. look for the id I'm interested in. Unmarshal the profile, get to the components, look at the component ids and include them as needed in my profile. vs. Get the components for the profile I'm interested in, look at teh component ids and include them as needed in my profile. Vijay > > Thanks, > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Mon, 13 Aug 2001 14:21:28 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, kkchan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: 6O0LI/9dtH09dyBUAN+stA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: 1l0!!k%k!!&Z@e9a!Ie9 Vijay, > >> >> So, on to interfaces: >> >> First, the general create an objref/fiddle with its IOR representation/ >> convert to objref again scenario is ugly and cumbersome. Just for >> reference, let's list the whole thing: >> >> 1. Somehow I have objref x. >> 2. Create an output stream os from a handy ORB (possibly from X, but it >> doesn't really matter) >> 3. os.write_object( x ) >> 4. is = os.create_input_stream() >> 5. IOR ior = new IOR() >> 6. IORHelper.read( is ) >> >> So now ior contains the profiles in the standard IIOP encoding. If we need >> to split things apart further, we use codecs to open up the CDR encapsulations. >> >> The first thing you are trying to avoid is steps 1-6 above to get to the >> profiles. The correct place to do this is on the ObjectReferenceFactory, >> since it is exactly equivalent to make_object. I need to emphasize that >> your getProfiles operation is not merely looking up profiles (as I think you >> realize); it is doing exactly the same thing as make_object, only returning >> the results as a sequence of profiles. > >Oh yes, exactly. It is doing almost the same thing as make_object, >albeit only a part of it. > >> It could either return an IOP::IOR >> or just a sequence of profiles, as you define. In general, I'm not sure that >> you need the repoid, since you are not constructing an entire IOR. > >Since it is doing the part make object, I would rather have the entire >information available. It is upto the system to use it or not. For >example, in some cases, our object key changes based on Repository Id. > Ok, so we need the repoid. I think make_object stays the same, and we look at the IOR conversion interface issue. >> For >> components, you are assuming that all tagged component are >> independent of the >> object id (is that always true? What about DCE?). Under these two >> assumptions, >> I would prefer to see > >Yes, that is correct. Since the object key is in the profile and the >components are part of it. This object key remains independent of hte >components. Ok with me. > >> >> abstract valuetype ObjectReferenceFactory { >> boolean equals( in ObjectReferenceFactory other ) ; >> Object make_object( in String repositoryid, in ObjectId id, >> in ObjectReferenceTemplate adapter_template ) ; >> ProfileSeq make_profiles( in ObjectId id ) ; >> ComponentSeq get_components( in IOP::ProfileId profile_id ) ; >> } > >That's fine. Actually, I think this will change, but we'll get to that in my reply to your reply to my second email of today :-). Ken. Date: Mon, 13 Aug 2001 17:07:00 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: irINdLA0T5kpsq3jAl+tlA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: DpSd99g$!!(oU!!O6nd9 Sorry, I missed replying to this message earlier. Comments inline. >> >I would prefer to see >> > >> >abstract valuetype ObjectReferenceFactory { >> > boolean equals( in ObjectReferenceFactory other ) ; >> > Object make_object( in String repositoryid, in ObjectId id, >> > in ObjectReferenceTemplate adapter_template ) ; >> > ProfileSeq make_profiles( in ObjectId id ) ; >> > ComponentSeq get_components( in IOP::ProfileId profile_id ) ; >> >} >> > >> >> actually we don't need to pass the adapter_template to make_object, >> >as we >> see below. > >I don't get it. MyFactory.make_object takes and uses an ORT (It could >> >be >an ORF, now that you've moved the methods to the ORF). I forgot to mention below that MyFactory.make_object never uses the ObjectReferenceFactory at all: instead, it uses the ObjectReferenceFactory that was passed into the constructor of MyFactory. >> >In other words: >> > >> >class LastInterceptor : IORInterceptor { >> > >> > void components_established( IORInfo info ) >> > { >> > ObjectReferenceFactory old = info.current_factory() >> >; >> > ObjectReferenceFactory orig = >> >info.adapter_template() ; >> > if (!orig.equals( old )) { >> > ObjectReferenceFactory newfactory = >> > new MyFactory( old ) ; >> > info.current_factory( newfactory ) ; >> > } >> > } >> > >> > ... >> >} >> > >> >Then MyFactory.make_object looks something like: >> > >> >Object make_object( String repoid, byte[] oid, >> >ObjectReferenceTemplate temp ) I should have removed temp from this. >> >{ >> > Profile[] psold = old.make_profiles( oid ) ; old was passed in the constructor above. It provides the adapter_template from the OA. >> > >> > ProfileS[] pstemp = temp.make_profiles( oid ) ; >> > >> > IOR result = new IOR() ; >> > >> > result.type_id = repoid ; >> > >> > Profile[] resultProfiles = new Profile()[ psold.length + >> >pstemp.length]; >> > >> > // copy psold and pstemp to resultProfiles, or whatever >> >part of >> > // psold is needed in this case. >> > >> > result.profile_data = resultProfiles ; >> > >> > // ulgy conversion to objectref: we should think about >> > // creating utilities for IOR<->objref conversion >> >} >> > >> >and actually the above is the implementation of make_profiles. >> >Note that make_profiles applies to the object on which it is >> >invoked; >> >I don't think your proposal to make it operate on the >> >original (POA created) template instead is necessary. >> > >> >> Thinking about this some more, what we really need is: >> >> 1. Convient conversion operations (probably on the ORB) to go >> >between >> objrefs and IORs (I am not sure that the procedure outlined >> >above >> is strictly portable, although it seems likely to work on most >> >ORBs). > >I agree, in fact I just posted that issue before reading this mail >> >;-) > >> >> 2. Equality checking on ObjectReferenceFactories, or an attribute >> >to indicate >> that the current_factory has been modified. > >Agreed. > >> >> 3. Adminstrative ordering of IORInterceptors (nothing new here. >> >There are >> lots of cases where this is needed in general). > >Can we do something as simple as raise an error if a >_set_current_factory is called more than once? Because either way, >> >only >one factory can be registered and it would be nice to not fail >> >silently. Matthew's load balancing facility (which I believe they have implemented and possibly shipped) requires reading/writing current_factory multiple times (once each for the load balancing agent and the IMR). This is nice in that the IORInterceptors for the LBA and IMR are independent: they just need to run in the correct order. > >> >> I think the only part that affects ORT is 2. Also, the getComponents method >> is not necessary, as this is exactly what codecs are defined for. If a >> convenience method is really necessary, I would see it as a PI issue, rather >> than ORT. > >This is a convenience method for the ORT. It allows my factory (which >creates IOR) collect and evaluate the components that have been added as >part of establish_components. Since this is a part of the factory's >operation, I would see it as totally applicable here. > >If I used codecs, here's what I would have to do. I would have to get >profiles. look for the id I'm interested in. Unmarshal the profile, get >to the components, look at the component ids and include them as needed >in my profile. > >vs. > >Get the components for the profile I'm interested in, look at teh >component ids and include them as needed in my profile. > Ok, let's try abstract valuetype ObjectReferenceFactory { boolean equals( in ObjectReferenceFactory other ) ; // new Object make_object( in String repositoryid, in ObjectId id ) ; // unchanged ComponentSeq get_components( in IOP::ProfileId profile_id ) ; // new } and leave the IOR <-> objref converison as a separate issue as we have already started the discussion on that. If we can agree on this, we need to do a detailed write-up and get a vote out tommorrow. Ken. Ken. Date: Mon, 13 Aug 2001 17:59:13 -0700 From: Vijaykumar Natarajan Subject: Re: Finishing the FTF To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com Message-id: <3B7877E1.1E4CC03B@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108140007.RAA17941@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_yhT0RzHY63kBjHuI5SEsaQ)" X-UIDL: p0K!!fl:!!bVbd9\n9e9 Hi Ken, Ken Cavanaugh wrote: > > Sorry, I missed replying to this message earlier. Comments inline. > > >> >I would prefer to see > >> > > >> >abstract valuetype ObjectReferenceFactory { > >> > boolean equals( in ObjectReferenceFactory other ) ; > >> > Object make_object( in String repositoryid, in ObjectId id, > >> > in ObjectReferenceTemplate adapter_template ) ; > >> > ProfileSeq make_profiles( in ObjectId id ) ; > >> > ComponentSeq get_components( in IOP::ProfileId profile_id ) ; > >> >} > >> > > >> > >> actually we don't need to pass the adapter_template to make_object, as we > >> see below. > > > >I don't get it. MyFactory.make_object takes and uses an ORT (It could be > >an ORF, now that you've moved the methods to the ORF). > > I forgot to mention below that MyFactory.make_object never uses the > ObjectReferenceFactory at all: instead, it uses the ObjectReferenceFactory > that was passed into the constructor of MyFactory. That's not true. Look for the ^^^^^^^^^. > > >> >In other words: > >> > > >> >class LastInterceptor : IORInterceptor { > >> > > >> > void components_established( IORInfo info ) > >> > { > >> > ObjectReferenceFactory old = info.current_factory() ; > >> > ObjectReferenceFactory orig = info.adapter_template() ; > >> > if (!orig.equals( old )) { > >> > ObjectReferenceFactory newfactory = > >> > new MyFactory( old ) ; > >> > info.current_factory( newfactory ) ; > >> > } > >> > } > >> > > >> > ... > >> >} > >> > > >> >Then MyFactory.make_object looks something like: > >> > > >> >Object make_object( String repoid, byte[] oid, ObjectReferenceTemplate temp ) > > I should have removed temp from this. > > >> >{ > >> > Profile[] psold = old.make_profiles( oid ) ; > > old was passed in the constructor above. It provides the adapter_template from the > OA. > > >> > > >> > ProfileS[] pstemp = temp.make_profiles( oid ) ; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Remember old is the user's old factory. temp is the ORB's template. > >> > > >> > IOR result = new IOR() ; > >> > > >> > result.type_id = repoid ; > >> > > >> > Profile[] resultProfiles = new Profile()[ psold.length + > >> >pstemp.length]; > >> > > >> > // copy psold and pstemp to resultProfiles, or whatever > >> >part of > >> > // psold is needed in this case. > >> > > >> > result.profile_data = resultProfiles ; > >> > > >> > // ulgy conversion to objectref: we should think about > >> > // creating utilities for IOR<->objref conversion > >> >} > >> > > >> >and actually the above is the implementation of make_profiles. > >> >Note that make_profiles applies to the object on which it is > >> >invoked; > >> >I don't think your proposal to make it operate on the > >> >original (POA created) template instead is necessary. > >> > > >> > >> Thinking about this some more, what we really need is: > >> > >> 1. Convient conversion operations (probably on the ORB) to go > >> >between > >> objrefs and IORs (I am not sure that the procedure outlined > >> >above > >> is strictly portable, although it seems likely to work on most > >> >ORBs). > > > >I agree, in fact I just posted that issue before reading this mail > >> >;-) > > > >> > >> 2. Equality checking on ObjectReferenceFactories, or an attribute > >> >to indicate > >> that the current_factory has been modified. > > > >Agreed. > > > >> > >> 3. Adminstrative ordering of IORInterceptors (nothing new here. > >> >There are > >> lots of cases where this is needed in general). > > > >Can we do something as simple as raise an error if a > >_set_current_factory is called more than once? Because either way, > >> >only > >one factory can be registered and it would be nice to not fail > >> >silently. > > Matthew's load balancing facility (which I believe they have > >> >implemented and > possibly shipped) requires reading/writing current_factory multiple > >> >times (once > each for the load balancing agent and the IMR). This is nice in > >> >that the IORInterceptors > for the LBA and IMR are independent: they just need to run in the > >> >correct order. > > > > >> > >> I think the only part that affects ORT is 2. Also, the > >> >getComponents method > >> is not necessary, as this is exactly what codecs are defined > >> >for. If a > >> convenience method is really necessary, I would see it as a PI > >> >issue, rather > >> than ORT. > > > >This is a convenience method for the ORT. It allows my factory > >> >(which > >creates IOR) collect and evaluate the components that have been > >> >added as > >part of establish_components. Since this is a part of the factory's > >operation, I would see it as totally applicable here. > > > >If I used codecs, here's what I would have to do. I would have to > >> >get > >profiles. look for the id I'm interested in. Unmarshal the profile, > >> >get > >to the components, look at the component ids and include them as > >> >needed > >in my profile. > > > >vs. > > > >Get the components for the profile I'm interested in, look at teh > >component ids and include them as needed in my profile. > > > > Ok, let's try > > abstract valuetype ObjectReferenceFactory { > boolean equals( in ObjectReferenceFactory other ) ; // new > > Object make_object( in String repositoryid, in ObjectId id ) ; > >> >// unchanged > > ComponentSeq get_components( in IOP::ProfileId profile_id ) ; > >> >// new > } > > and leave the IOR <-> objref converison as a separate issue as we > >> >have already started > the discussion on that. If we can agree on this, we need to do a > >> >detailed write-up > and get a vote out tommorrow. As I point out, the template is still needed for make_object. However, I concede that it doesn't have to be a template, just an ORF. Second, the get_profiles is now missing. That needs to remain on ORF to get at from the make_object(). Vijay -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Mon, 13 Aug 2001 23:39:31 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: DzHZgekic6+0CO+hSx1B+w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: c74e9L9j!!m*f!!P`8!! As you correctly point out, I screwed up the example. Let me try it again: class LastInterceptor extends IORInterceptor { void components_established( IORInfo info ) { ObjectReferenceFactory current = info.current_factory() ; ObjectReferenceFactory orig = info.adapter_template() ; if (!orig.equals( current )) { ObjectReferenceFactory newfactory = new MyFactory( orig, current ) ; info.current_factory( newfactory ) ; } } ... } So MyFactory has orig and current in its instance variables. There are only two possible ObjectReferenceFactories in this example, and both are available in IORInfo. Then MyFactory.make_object looks something like: Object make_object( String repoid, byte[] oid) { Profile[] origProfiles = orig.make_profiles( oid ) ; Profile[] currentProfiles = current.make_profiles( oid ) ; IOR result = new IOR() ; result.type_id = repoid ; int newLength = XXX ; // this is whatever is needed from both sets // of profiles. Profile[] resultProfiles = new Profile()[ newLength ]; // copy parts of origProfiles and currentProfiles to resultProfiles result.profile_data = resultProfiles ; // ulgy conversion to objectref: we should think about // creating utilities for IOR<->objref conversion } With the above, and in response to your other comments, I think we have: abstract valuetype ObjectReferenceFactory { boolean equals( in ObjectReferenceFactory other ) ; // new Object make_object( in String repositoryid, in ObjectId id ) ; // unchanged ProfileSeq make_profiles( in String repositoryid, in ObjectId id ) ; // really almost the same as make_object ComponentSeq get_components( in IOP::ProfileId profile_id ) ; // new } However, I really don't like putting make_profiles here, assuming that we have a good solution for IOR <-> objref somewhere else. The alternative make_object from above would look like (for example) interface object_reference_converter { IOP::IOR reference_to_IOR( in Object reference ) ; Object IOR_to_reference( in IOP::IOR ior ) ; } and assume that the converted can be obtained, say from resolve_initial_reference( "ObjectReferenceConverter" ) or something similar. Then we just get ahold of the converter in the MyFactory constructor, and assume that object_reference_converter converter ; is available in the instance data of MyFactory. Then make_object looks like: Object make_object( String repoid, byte[] oid) { Object origObject = orig.make_object( repoid, oid ) ; IOR origIOR = converter.reference_to_IOR( origObject ) ; Object currentObject = current.make_object( repoid, oid ) ; IOR currentProfiles = converter.reference_to_IOR( currentObject ) ; IOR result = new IOR() ; result.type_id = repoid ; int newLength = XXX ; // this is whatever is needed from both sets // of profiles. Profile[] resultProfiles = new Profile[ newLength ]; // copy parts of origIOR.profiles and currentIOR.profiles to // resultProfiles result.profile_data = resultProfiles ; return converter.IOR_to_reference( result ) ; } I don't believe that it is worth adding make_profiles if we have an easy to use converter, which we need anyway. This version only requires: abstract valuetype ObjectReferenceFactory { boolean equals( in ObjectReferenceFactory other ) ; // new Object make_object( in String repositoryid, in ObjectId id ) ; // unchanged ComponentSeq get_components( in IOP::ProfileId profile_id ) ; // new } where get_components is provided as a convenience, to avoid extracting components from a profile. However, I don't like the fact that the only ProfileIds that I am guaranteed to understand are TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS. If an ORB supports other proprietary profiles, how does a user-defined implementation of ObjectReferenceFactory implement get_components using portable APIs? The implementation would need to understand the ORBs proprietary profiles. I also disagree about the mixing of tagged components from different profiles. The case in PI that does something similar is add_ior_component_to_profile, which adds the same component to all profiles. However, the profiles could themselves contain information that needs to be interpreted in the context of the profile itself. As an example, consider the TAG_PRIMARY component defined by CORBA_FT. This is supposed to indicate the profile to be used as the preferred profile to reach the server. Calling get_components( TAG_INTERNET_IOP ) would return a list of TAG_PRIMARY, TAG_GROUP, and possibly TAG_ALTERNATE_ADDRESS components all mixed together, making it impossible to determine which TAG_ALTERNATE_ADDRESS components were in the same profile as the TAG_PRIMARY component. However, the behavior of add_ior_component_to_profiles is still perfectly reasonable in the IOGR case. Ken. Date: Tue, 14 Aug 2001 00:03:51 -0700 From: Vijaykumar Natarajan Subject: Re: Finishing the FTF To: Ken Cavanaugh Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com Message-id: <3B78CD57.3DCA8271@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108140639.XAA10040@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_wO6Ojd/4pbDC1Sg9v0sGqQ)" X-UIDL: kfkd9>7M!!b%Zd9ocD!! Hi Ken, Ken Cavanaugh wrote: > > As you correctly point out, I screwed up the example. Let me try it again: > > class LastInterceptor extends IORInterceptor { > > void components_established( IORInfo info ) > { > ObjectReferenceFactory current = info.current_factory() ; > ObjectReferenceFactory orig = info.adapter_template() ; > if (!orig.equals( current )) { > ObjectReferenceFactory newfactory = > new MyFactory( orig, current ) ; > info.current_factory( newfactory ) ; > } > } > > ... > } > > So MyFactory has orig and current in its instance variables. There are > only two possible ObjectReferenceFactories in this example, and both > are available in IORInfo. > > Then MyFactory.make_object looks something like: > > Object make_object( String repoid, byte[] oid) > { > Profile[] origProfiles = orig.make_profiles( oid ) ; > > Profile[] currentProfiles = current.make_profiles( oid ) ; > > IOR result = new IOR() ; > > result.type_id = repoid ; > > int newLength = XXX ; // this is whatever is needed from both sets > // of profiles. > > Profile[] resultProfiles = new Profile()[ newLength ]; > > // copy parts of origProfiles and currentProfiles to resultProfiles > > result.profile_data = resultProfiles ; > > // ulgy conversion to objectref: we should think about > // creating utilities for IOR<->objref conversion > } > > With the above, and in response to your other comments, I think we have: > > abstract valuetype ObjectReferenceFactory { > boolean equals( in ObjectReferenceFactory other ) ; // new > > Object make_object( in String repositoryid, in ObjectId id ) ; // unchanged > > ProfileSeq make_profiles( in String repositoryid, > in ObjectId id ) ; // really almost the same as make_object > > ComponentSeq get_components( in IOP::ProfileId profile_id ) ; // new > } You are right. That looks good. > > However, I really don't like putting make_profiles here, assuming > that we > have a good solution for IOR <-> objref somewhere else. The > alternative > make_object from above would look like (for example) I still believe that's useful and more efficient. Your approach below would require the orig.make_object to create the profiles, then the IOR and then a delegate and an objectimpl, only for all of it to be thrown away and a new set created. considering that this is being done every single time an object is created, I would expect some optimization. > > interface object_reference_converter { > IOP::IOR reference_to_IOR( in Object reference ) ; > Object IOR_to_reference( in IOP::IOR ior ) ; > } > > and assume that the converted can be obtained, say from > resolve_initial_reference( "ObjectReferenceConverter" ) or something > similar. > Then we just get ahold of the converter in the MyFactory > constructor, and > assume that > > object_reference_converter converter ; > > is available in the instance data of MyFactory. Then make_object > looks like: > > Object make_object( String repoid, byte[] oid) > { > Object origObject = orig.make_object( repoid, oid ) ; > IOR origIOR = converter.reference_to_IOR( origObject ) ; > > Object currentObject = current.make_object( repoid, oid ) ; > IOR currentProfiles = converter.reference_to_IOR( > currentObject ) ; > > IOR result = new IOR() ; > > result.type_id = repoid ; > > int newLength = XXX ; // this is whatever is needed from > both sets > // of profiles. > > Profile[] resultProfiles = new Profile[ newLength ]; > > // copy parts of origIOR.profiles and currentIOR.profiles to > // resultProfiles > > result.profile_data = resultProfiles ; > > return converter.IOR_to_reference( result ) ; > } > > I don't believe that it is worth adding make_profiles if we have an > easy to use converter, which we need anyway. This version only > requires: For efficiency reasons. You appear quite uncomfortable with this and yet I don't see any harm in doing this. Is there any specific reason why you are opposed to this? > > abstract valuetype ObjectReferenceFactory { > boolean equals( in ObjectReferenceFactory other ) ; // new > > Object make_object( in String repositoryid, in ObjectId id ) ; > // unchanged > > ComponentSeq get_components( in IOP::ProfileId profile_id ) ; > // new > } > > where get_components is provided as a convenience, to avoid > extracting > components from a profile. However, I don't like the fact that the > only > ProfileIds that I am guaranteed to understand are TAG_INTERNET_IOP > and > TAG_MULTIPLE_COMPONENTS. If an ORB supports other proprietary > profiles, > how does a user-defined implementation of ObjectReferenceFactory > implement > get_components using portable APIs? The implementation would need > to understand the ORBs proprietary profiles. > > I also disagree about the mixing of tagged components from different > profiles. > The case in PI that does something similar is > add_ior_component_to_profile, > which adds the same component to all profiles. However, the > profiles > could themselves contain information that needs to be interpreted in > the > context of the profile itself. > > As an example, consider the TAG_PRIMARY component defined by > CORBA_FT. > This is supposed to indicate the profile to be used as the preferred > profile to reach the server. Calling get_components( > TAG_INTERNET_IOP ) > would return a list of TAG_PRIMARY, TAG_GROUP, and possibly > TAG_ALTERNATE_ADDRESS components all mixed together, making it > impossible > to determine which TAG_ALTERNATE_ADDRESS components were in the same > profile as the TAG_PRIMARY component. However, the behavior of > add_ior_component_to_profiles is still perfectly reasonable in the > IOGR case. You are right. this isn't very clean. As a compromise, how about replacing the get_components w/ the get_profiles. That way the factory has a way to look for the components it needs as well as the profiles it must add to its IOR. Vijay [] vnatarajan5.vcf Date: Tue, 14 Aug 2001 00:23:14 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: GKqH+1LpncXqUc2P8AE8RA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: o9dd9?mg!!bjW!!pC6!! >From: Vijaykumar Natarajan >Subject: Re: Finishing the FTF >To: Ken Cavanaugh >Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com >MIME-version: 1.0 >X-Accept-Language: en > >Hi Ken, > >Ken Cavanaugh wrote: >> >> As you correctly point out, I screwed up the example. Let me try >it again: >> >> class LastInterceptor extends IORInterceptor { >> >> void components_established( IORInfo info ) >> { >> ObjectReferenceFactory current = >info.current_factory() ; >> ObjectReferenceFactory orig = >info.adapter_template() ; >> if (!orig.equals( current )) { >> ObjectReferenceFactory newfactory = >> new MyFactory( orig, current ) ; >> info.current_factory( newfactory ) ; >> } >> } >> >> ... >> } >> >> So MyFactory has orig and current in its instance variables. There >are >> only two possible ObjectReferenceFactories in this example, and >both >> are available in IORInfo. >> >> Then MyFactory.make_object looks something like: >> >> Object make_object( String repoid, byte[] oid) >> { >> Profile[] origProfiles = orig.make_profiles( oid ) ; >> >> Profile[] currentProfiles = current.make_profiles( oid ) ; >> >> IOR result = new IOR() ; >> >> result.type_id = repoid ; >> >> int newLength = XXX ; // this is whatever is needed from >both sets >> // of profiles. >> >> Profile[] resultProfiles = new Profile()[ newLength ]; >> >> // copy parts of origProfiles and currentProfiles to >resultProfiles >> >> result.profile_data = resultProfiles ; >> >> // ugly conversion to objectref: we should think about >> // creating utilities for IOR<->objref conversion >> } >> >> With the above, and in response to your other comments, I think we >have: >> >> abstract valuetype ObjectReferenceFactory { >> boolean equals( in ObjectReferenceFactory other ) ; // new >> >> Object make_object( in String repositoryid, in ObjectId id ) ; >// unchanged >> >> ProfileSeq make_profiles( in String repositoryid, >> in ObjectId id ) ; // really almost the same as make_object >> >> ComponentSeq get_components( in IOP::ProfileId profile_id ) ; >// new >> } > >You are right. That looks good. > >> >> However, I really don't like putting make_profiles here, assuming >that we >> have a good solution for IOR <-> objref somewhere else. The >alternative >> make_object from above would look like (for example) > >I still believe that's useful and more efficient. Your approach below >would require the orig.make_object to create the profiles, then the >IOR >and then a delegate and an objectimpl, only for all of it to be >thrown >away and a new set created. considering that this is being done every >single time an object is created, I would expect some optimization. On thinking about this further, I tend to agree. Creating an IOR from a template is very efficient in the Sun ORB. Allocating delegates is not too inefficient, but it is certainly possible that an ORB could have significant overheads in general for this. Let's add the make_profiles method. I am simply trying to simplify as much as possible. >> >> where get_components is provided as a convenience, to avoid >> extracting >> components from a profile. However, I don't like the fact that the >> only >> ProfileIds that I am guaranteed to understand are TAG_INTERNET_IOP >> and >> TAG_MULTIPLE_COMPONENTS. If an ORB supports other proprietary >> profiles, >> how does a user-defined implementation of ObjectReferenceFactory >> implement >> get_components using portable APIs? The implementation would need >> to understand the ORBs proprietary profiles. >> >> I also disagree about the mixing of tagged components from >> different profiles. >> The case in PI that does something similar is >> add_ior_component_to_profile, >> which adds the same component to all profiles. However, the >> profiles >> could themselves contain information that needs to be interpreted >> in the >> context of the profile itself. >> >> As an example, consider the TAG_PRIMARY component defined by >> CORBA_FT. >> This is supposed to indicate the profile to be used as the >> preferred >> profile to reach the server. Calling get_components( >> TAG_INTERNET_IOP ) >> would return a list of TAG_PRIMARY, TAG_GROUP, and possibly >> TAG_ALTERNATE_ADDRESS components all mixed together, making it >> impossible >> to determine which TAG_ALTERNATE_ADDRESS components were in the >> same >> profile as the TAG_PRIMARY component. However, the behavior of >> add_ior_component_to_profiles is still perfectly reasonable in the >> IOGR case. > >You are right. this isn't very clean. >As a compromise, how about replacing the get_components w/ the >get_profiles. That way the factory has a way to look for the >> components >it needs as well as the profiles it must add to its IOR. > I think that is what I have been calling make_profiles, but that sounds good to me. I think we then have: abstract valuetype ObjectReferenceFactory { boolean equals( in ObjectReferenceFactory other ) ; // new Object make_object( in String repositoryid, in ObjectId id ) ; // unchanged ProfileSeq make_profiles( in String repositoryid, in ObjectId id ) ; // almost the same as make_object } If we are agreed on this, let's write up the issue and resolution and get a vote out tommorrow (or, well, later today at this point :-). The IOR conversion issue then needs further discussion, and possibly forwarding to a different task force (we certainly could start an issue here and get it reassigned, perhaps to PI if we decide that's what we want to do). Thanks, Ken. Date: Tue, 14 Aug 2001 10:13:51 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Finishing the FTF To: Ken.Cavanaugh@sun.com, vnatarajan@borland.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, issues@omg.org, kkchan@borland.com, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: uFyGE/zehlF05L6SctETtQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: Y4m!!h>> >>> However, I really don't like putting make_profiles here, assuming >>> that we >>> have a good solution for IOR <-> objref somewhere else. The >>> alternative >>> make_object from above would look like (for example) >> >>I still believe that's useful and more efficient. Your approach >>> below >>would require the orig.make_object to create the profiles, then the >>> IOR >>and then a delegate and an objectimpl, only for all of it to be >>> thrown >>away and a new set created. considering that this is being done >>> every >>single time an object is created, I would expect some optimization. > >On thinking about this further, I tend to agree. Creating an IOR >>> from >a template is very efficient in the Sun ORB. Allocating delegates is >>> not >too inefficient, but it is certainly possible that an ORB could have significant >overheads in general for this. Let's add the make_profiles method. >I am simply trying to simplify as much as possible. > I should have said creating an IOR IN THE INTERNAL REPRESENTATION IN THE SUN ORB from a template is very efficient. It's actually more expensive to marshal it out as an encapsulation (though of course that could be cached) in order to construct the IOP::IOR or the ProfileSeq than it is to construct the delegate and objref and throw them away later. I think either make_profiles or make_object could be the more efficient call depending on the ORB representation. We should still provide both to make this easy to use and support different types of optimization. However, this really doesn't change anything that we have discussed. The real underlying problem is that the ORB can use a more efficient IOR representation, but portable code cannot use it, and code like MyFactory.make_XXX must go through the inefficient interal IOR to IOP::IOR transformation twice (once in each direction) in order to construct the IOR. But this is not a problem that we can address: it's outside the scope of the ORT (especially the FTF), and was discussed early on in the PI development, but not pursused further. Ken. Date: Tue, 14 Aug 2001 13:37:38 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Proposal for issue 4476 (access to IORs in ORT) To: ort-ftf@omg.org, issues@omg.org Cc: kkchan@borland.com, Ken.Cavanaugh@Sun.COM, carr@eng.sun.com MIME-Version: 1.0 Content-MD5: qk2rU8PtAql1JbDzjt6BXw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: FNQd9A4Vd9IQa!!p\Ud9 Here is the final form before I call for vote 2: -------------------------- Users of ORT may wish to accommodate the following two scenarioes: 1. The birth address optimization: when a persistent objref is created, include the profile(s) for the transient address of the server as well as the profile(s) that contain the permanent IOR address. 2. In a complex system with multiple authentication servers, the IMR and other CORBA servers may not all support the same authentication policies. This leads to a need for the IMR to construct a transient objref that points to the current incarnation of a persistent server and has security information in the IOR that is appropriate for that particular server. These scenarios are somewhat awkward to address with the current ORT definition for several reasons. The issue here focuses on the following problems: 1. A user defined IORInterceptor may need to determine whether the current_factory and adapter_template are actually the same valuetype or not. 2. Getting access to the profiles in an object reference is quite cumbersome, and possibly not portable. Proposal: Raise an interop issue to update the appropriate version of the core spec Chapter 13 as follows: In the IDL for module IOP in section 13.6.2, add typedef sequence TaggedProfileSeq ; and replace the anonymous sequence with TaggedProfileSeq Update the ORT specification (ptc/01-04-03) as follows: Change the IDL for ObjectReferenceFactory in section 21.5.3.1 and in section 21.10 as follows: abstract valuetype ObjectReferenceFactory { boolean equals( in ObjectReferenceFactory other ) ; Object make_object( in string repository_id, in ObjectId id ) ; IOP::TaggedProfileSeq make_profiles( in string repository_id, in ObjectId id ) ; } ; Change section 21.5.3.3 to read (that is, delete the last two sentences in the section): make_object creates an Object Reference from this factory using the given repository ID and object ID. Add new sections: 21.5.3.4 make_profiles make_profiles returns the sequence of tagged profiles for the IOR that corresponds to the object reference that would be created by a call to make_object with the same arguments. 21.5.3.5 equals equals satisfies the usual reflexive, symmetric, and transitive properties that equality normally respects. That is, for any ObjectReferenceFactories X, Y, and Z: 1. X.equals( X ) = true 2. X.equals( Y ) = Y.equals( X ) 3. if X.equals( Y ) = true and Y.equals( Z ) = true, then X.equals( Z ) = true If X and Y are different object adapters, and Xinfo and Yinfo are the IORInfo objects passed to the IORInterceptor, then Xinfo.adapter_template().equals( Yinfo.adapter_template() ) = false An equals method on a user defined ObjectReferenceFactory must return false when passed the value of an IORInfo.adapter_template attribute, unless the user defined make_profiles method returns the same ProfileSeq as the adapter_template make_profiles method when invoked with the same arguments, in which case the user defined ObjectReferenceFactory equals method may return true. renumber current sections 21.5.3.4-21.5.3.7 to 21.5.3.6-21.5.3.9 -------------------------- Thanks, Ken. Date: Tue, 14 Aug 2001 14:13:38 -0700 From: Vijaykumar Natarajan Subject: Re: Proposal for issue 4476 (access to IORs in ORT) To: Ken Cavanaugh Cc: ort-ftf@omg.org, kkchan@borland.com, carr@eng.sun.com Message-id: <3B799482.4CEA0B2E@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108142037.NAA08122@taller.eng.sun.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_RPJjabJTMDmAnhTSbyz/rA)" X-UIDL: 0,5e9aD#!!nZJe9JTA!! Looks good. Vijay Ken Cavanaugh wrote: > > Here is the final form before I call for vote 2: > > -------------------------- > > Users of ORT may wish to accommodate the following two scenarioes: > > 1. The birth address optimization: when a persistent objref is created, > include the profile(s) for the transient address of the server as well > as the profile(s) that contain the permanent IOR address. > > 2. In a complex system with multiple authentication servers, the IMR and > other CORBA servers may not all support the same authentication > policies. This leads to a need for the IMR to construct a transient > objref that points to the current incarnation of a persistent server > and has security information in the IOR that is appropriate for > that particular server. > > These scenarios are somewhat awkward to address with the current ORT definition > for several reasons. The issue here focuses on the following problems: > > 1. A user defined IORInterceptor may need to determine whether the > current_factory and adapter_template are actually the same valuetype > or not. > > 2. Getting access to the profiles in an object reference is quite cumbersome, > and possibly not portable. > > Proposal: > > Raise an interop issue to update the appropriate version of the core spec > Chapter 13 as follows: > > In the IDL for module IOP in section 13.6.2, add > > typedef sequence TaggedProfileSeq ; > > and replace the anonymous sequence with TaggedProfileSeq > > Update the ORT specification (ptc/01-04-03) as follows: > > Change the IDL for ObjectReferenceFactory in section 21.5.3.1 and in > section 21.10 as follows: > > abstract valuetype ObjectReferenceFactory { > boolean equals( in ObjectReferenceFactory other ) ; > > Object make_object( in string repository_id, > in ObjectId id ) ; > > IOP::TaggedProfileSeq make_profiles( in string repository_id, > in ObjectId id ) ; > } ; > > Change section 21.5.3.3 to read (that is, delete the last two sentences > in the section): > > make_object creates an Object Reference from this factory using the given > repository ID and object ID. > > Add new sections: > > 21.5.3.4 make_profiles > > make_profiles returns the sequence of tagged profiles for the IOR that > corresponds to the object reference that would be created by a call > to make_object with the same arguments. > > 21.5.3.5 equals > > equals satisfies the usual reflexive, symmetric, and transitive > properties that equality normally respects. That is, for any > ObjectReferenceFactories X, Y, and Z: > > 1. X.equals( X ) = true > 2. X.equals( Y ) = Y.equals( X ) > 3. if X.equals( Y ) = true and Y.equals( Z ) = true, then X.equals( Z ) = true > > If X and Y are different object adapters, and Xinfo and Yinfo are the > IORInfo objects passed to the IORInterceptor, then > Xinfo.adapter_template().equals( Yinfo.adapter_template() ) = false > > An equals method on a user defined ObjectReferenceFactory must return false when > passed the value of an IORInfo.adapter_template attribute, unless the > user defined make_profiles method returns the same ProfileSeq as the > adapter_template make_profiles method when invoked with the same arguments, > in which case the user defined ObjectReferenceFactory equals method > may return true. > > renumber current sections 21.5.3.4-21.5.3.7 to 21.5.3.6-21.5.3.9 > > -------------------------- > > Thanks, > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Wed, 15 Aug 2001 11:25:00 -0700 From: Vijaykumar Natarajan Subject: Re: Vote 2 To: Bob Kukura Cc: Ken Cavanaugh , ort-ftf@omg.org Message-id: <3B7ABE7C.66893F5@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <200108142227.PAA20395@taller.eng.sun.com> <3B7A8135.50701E00@iona.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_IeqGMyf0DCjDZ/o0y7Mzkw)" X-UIDL: &VDe9eKb!![Omd9DT1e9 Bob, You have mistaken the intent of this. The idea is not to modify the POA's ORT, but to provide the POA with a mechanism to influence the contents of the IOR. Currently, the way the spec is written, I (a user) can install an ObjectReferenceFactory and create an IOR, the contents of which are completely out of the control of the ORB. The concern you are having is the exact concern I was having, and this fixes that problem (and does not introduce it). Please reevaluate this proposal. Thanks, Vijay Bob Kukura wrote: > > IONA votes NO on the proposed resolution to issue 4476. We do not feel > it is desirable to enable modification of the POA's ORT via the > PortableInterceptor APIs. The contents of this ORT and the IORs it > generates is the business of the ORB, and any modifications made to it > by applications are inherently non-portable. The ORT submission is not > part of an extensible transport framework, so the addition of profiles > clearly seems out of scope for the FTF to add, particularly at this late > stage in the FTF process. > > -Bob > > Ken Cavanaugh wrote: > > > > This is ORT FTF vote 2, which consists solely of issue 4476. > > This vote is due 5pm PST on August 17, which gives me enough time > > to finish the FTF report. > > > > Issue 4476: > > > > (The original writeup in Juergen's email) > > > > There is no way to modify a POA's ORT and append to it > > > > If I wish to register an ORF (ObjectReferenceFactory) as the current > > factory, there is no way for it to append to the current template. In > > other words, an updated factory can only replace the original but not > > say add another profile to the one the given POA would generate w/ the > > adapter template. > > > > As an inverse, there is no way for a POA to require or even request an > > ORF to include profiles that it deems fit. > > > > (My revised summary of the issue and the proposed resolution follows) > > > > Users of ORT may wish to accommodate the following two scenarioes: > > > > 1. The birth address optimization: when a persistent objref is created, > > include the profile(s) for the transient address of the server as well > > as the profile(s) that contain the permanent IOR address. > > > > 2. In a complex system with multiple authentication servers, the IMR and > > other CORBA servers may not all support the same authentication > > policies. This leads to a need for the IMR to construct a transient > > objref that points to the current incarnation of a persistent server > > and has security information in the IOR that is appropriate for > > that particular server. > > > > These scenarios are somewhat awkward to address with the current ORT definition > > for several reasons. The issue here focuses on the following problems: > > > > 1. A user defined IORInterceptor may need to determine whether the > > current_factory and adapter_template are actually the same valuetype > > or not. > > > > 2. Getting access to the profiles in an object reference is quite cumbersome, > > and possibly not portable. > > > > Proposal: > > > > Raise an interop issue to update the appropriate version of the core spec > > Chapter 13 as follows: > > > > In the IDL for module IOP in section 13.6.2, add > > > > typedef sequence TaggedProfileSeq ; > > > > and replace the anonymous sequence with TaggedProfileSeq > > > > Update the ORT specification (ptc/01-04-03) as follows: > > > > Change the IDL for ObjectReferenceFactory in section 21.5.3.1 and in > > section 21.10 as follows: > > > > abstract valuetype ObjectReferenceFactory { > > boolean equals( in ObjectReferenceFactory other ) ; > > > > Object make_object( in string repository_id, > > in ObjectId id ) ; > > > > IOP::TaggedProfileSeq make_profiles( in string repository_id, > > in ObjectId id ) ; > > } ; > > > > Change section 21.5.3.3 to read (that is, delete the last two sentences > > in the section): > > > > make_object creates an Object Reference from this factory using the given > > repository ID and object ID. > > > > Add new sections: > > > > 21.5.3.4 make_profiles > > > > make_profiles returns the sequence of tagged profiles for the IOR that > > corresponds to the object reference that would be created by a call > > to make_object with the same arguments. > > > > 21.5.3.5 equals > > > > equals satisfies the usual reflexive, symmetric, and transitive > > properties that equality normally respects. That is, for any > > ObjectReferenceFactories X, Y, and Z: > > > > 1. X.equals( X ) = true > > 2. X.equals( Y ) = Y.equals( X ) > > 3. if X.equals( Y ) = true and Y.equals( Z ) = true, then X.equals( Z ) = true > > > > If X and Y are different object adapters, and Xinfo and Yinfo are the > > IORInfo objects passed to the IORInterceptor, then > > Xinfo.adapter_template().equals( Yinfo.adapter_template() ) = false > > > > An equals method on a user defined ObjectReferenceFactory must return false when > > passed the value of an IORInfo.adapter_template attribute, unless the > > user defined make_profiles method returns the same ProfileSeq as the > > adapter_template make_profiles method when invoked with the same arguments, > > in which case the user defined ObjectReferenceFactory equals method > > may return true. > > > > renumber current sections 21.5.3.4-21.5.3.7 to 21.5.3.6-21.5.3.9 > > > > -------------------------- > > > > Thanks, > > > > Ken. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Accelerate your Linux Date: Wed, 3 Oct 2001 11:56:33 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Remaining issue(s) To: ort-ftf@omg.org Cc: ken.cavanaugh@sun.com, harold.carr@sun.com MIME-Version: 1.0 Content-MD5: TQKGqbDUH/uLnv3imQuI/w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: jWAe9Vg=e9:I6e9k_O!! At the last OMG meeting in Toronto, the AB raised objections to the status of issue 4478 (objref to IOR conversion). Consequently, the FTF deadline was extended to 12/3/01, with the report due 3 weeks before the Dublin meeting. Alhough 12/3 is a ways off yet, 3 weeks before the Dublin meeting works out to 10/22. We will need to get out at least one more vote between now and then to deal with issue 4478 (and possibly 4476 again as well: see below). Just as a reminder, because the FTF was continued, we still have the same FTF membership, not the newly proposed RTF membership. The voting members of the ORT FTF are: Sun (Ken Cavanaugh) chair Borland (Vijaykumar Natarajan) Iona (Bob Kukura) IBM (Randy Fox) Recap Vijay raised the questions in issue 4476 to allow more manipulation of the objref that is created in an ObjectReferenceTemplate. This led to the introduction of ObjectReferenceFactory.make_profiles, which returns a sequence, which can then be (rather painfully and slowly) manipulated as desired, using the PI codecs. The main use cases for this are: 1. Birth address optimization, in which the POA must add a profile to an IOR of a persistent objref that contains the address at which the object was created (and in many cases is still served at this address). 2. Complex security models, where the IMR wants to construct an IOR containing multiple profiles with different security models. Proposal for consideration Let's create an abstract representation of an IOR roughly as follows: module IOR { abstract valuetype ProfileIterator ; abstract valuetype Profile ; abstract valuetype ComponentIterator ; abstract valuetype Component ; abstract valuetype IOR { readonly attribute string type_id ; ProfileIterator profiles() ; void add_profile( in Profile profile ) ; Object make_object() ; } ; abstract valuetype ProfileIterator { boolean has_next_profile() ; Profile next_profile() ; } ; abstract valuetype Profile { readonly attribute IOP::ProfileId id ; } ; abstract valuetype IIOPProfile : Profile { typedef sequence ObjectKey ; readonly attribute IIOP::Version version ; readonly attribute string host ; readonly attribute unsigned short port ; readonly attribute ObjectKey key ; ComponentIterator components() ; void add_component( in Component component ) ; } ; abstract valuetype ComponentIterator{ boolean has_next_attribute() ; Component next_component() ; } ; abstract valuetype Component { readonly attribute IOP::ComponentId id ; } ; } ; then the ObjectReferenceFactory just needs IOR::IOR make_ior( in string repoid, in ObjectId oid ) instead of make_profiles. The IOR can be composed out of abstract profiles as needed, and converted to an objref using IOR.make_object. This handles the cases where objrefs are created out of pieces of IORs created by multiple ObjectReferenceFactory instances. If there is a need to start with a random objref outside of the ORT framework, then we need an additional method to create an IOR::IOR out of an objref somewhere. But I'm not presenting this as a finished proposal, rather I intend to use it to continue the discussion. Problems this solves: 1. No inefficient conversion: the abstract valuetypes can be efficiently mapped to whatever internal architecture an ORB supports for objrefs and IORs. 2. No committment to particular encodings: all of that is deferred until needed. 3. This avoids concerns about which version of GIOP is used to encode the IOR using a codec approach. Questions (mainly for Vijay): 1. Do you want to move in this direction? 2. Do you need the general objref to abstract IOR conversion in this framewor? Let's get the ball rolling again and finish this FTF. Thanks, Ken. Date: Tue, 9 Oct 2001 12:44:10 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Remaining issue(s) To: Ken.Cavanaugh@sun.com, kukura@iona.com Cc: vnatarajan@borland.com, ort-ftf@omg.org, michi.henning@iona.com, matthew.newhook@iona.com MIME-Version: 1.0 Content-MD5: L3hA7MaJ5qTvfamVBGqhnA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: T`:e96,\d9*Y"!!O&hd9 >From: Bob Kukura >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: vnatarajan@borland.com, ort-ftf@omg.org, Michi Henning >, Matthew Newhook >Subject: Re: Remaining issue(s) >Content-Transfer-Encoding: 7bit > >Hi Ken, > >I appreciate your effort in producing this proposal to stimulate >discussion, but I believe IONA >would vote against this sort of proposal. The abstract model of IORs >that is presented has >significant incompatabilities with the internal model of IORs used in >some of our products. >These aren't just representational issues, but are related to the >architecture by which IORs, >Profiles, and Components are created and managed in our ORBs. The >model we use internally would >not necessarily be appropriate for other ORBs, either. > >For example, the read accessors of the proposed valuetypes could be >mapped efficiently. But the >the add_profile and add_component operations on the specified >valuetypes just don't fit our >model, as our internal equivalent of IOR templates are created via a >different process tied to >our transport framework. > Actually, this is basically true for the Sun ORB as well. add_profile and add_component would basically require that we create a new IOR template for the additions and use the template just for the particular objref being created. However, this is still better than alternative models using the standard IOP::IOR, which require CDR encapsulation. Encapsulating information just for the purpose of satisfying an OMG standard API is a high performance price to pay. My efforts are aimed at producing the best specification that I can given Vijay's requirements. >Also, our model does not treat TAG_INTERNET_IOP profiles specially - components can be used >transparently in TAG_MULTIPLE_COMPONENTS profiles or other profile types, with ORB services >(even those implemented using Portable Interceptors) supported regardless of what profiles are >used to advertize the transports and protocols supported by the IOR. If someone really needs >this level of IOR access using our products, they would be much better off using our >proprietaty APIs. They'd get better performance, better scalability, and better compatibility >with the other components making up our ORB products. > >My general reaction is that this proposal is attempting to extend the reach of ORT into >territory not intended in the RFP submission. Specifically, IONA did not intend to expose >transport level details, such as specific profiles and the ability to manipulate their >contents, via ORT. Manipulating "birth addresses" or implementing "complex security models" >were not considered requirements. We feel that the mechanisms already present in the Portable >Interceptor specification for accessing IOR components are sufficient for portably >implementating transport-independent ORB services, and that providing access to >transport-specific IOR information should be considered out of scope. Even if these sorts of >APIs were provided, it would simply not be portable for an application to manipulate transport >information in IORs outside the context of a specific ORB's transport framework. > This of course is the problem with issue 4476, which arguably does move beyond the original RFP requirements, which I tried to target very carefully at the server activation issues. But 4476 is incomplete without 4478 (4478 calls for methods to convert CORBA::Object to/from IOP::IOR). One problem I have with 4478 is that IOP::IOR is too concrete a representation for everything that can be done with object references. In particular, it assumes CDR encapsulation, so IOP::IOR is protocol specific (and indeed which version of GIOP encoding for the encapsulation might matter). To finish this FTF, we need to either move forward with 4476/4478 and produce a complete solution for Vijay's concerns, or get rid of the mechanism altogether. >By the way, what were the specific objections of the AB on issue 4478? > >From Jeff's email of 9/5/01: Final status of the spec: (Unfortunately for the FTF, I'm on its mailing list so I got to watch the flurry of mail on issue 4478. :-) IMO the deferred issue 4478 is fairly serious, and should be resolved and implemented before the spec will be suitable for being considered to be finalised. Note: If I've misunderstood, I'm quite willing to be convinced otherwise. All of the other issues Jeff had with the earlier vcersion of the FTF report were minor and could easily be corrected. But given Jeff's feelings on this issue, I decided it was best to extend the FTF one meeting to address issue 4478. I was unable to attend the Toronto meeting (and I won't be in the Dublin meeting either; Sun's travel restrictions basically keep everyone home in nearly all cases except critical company business). From what Peter Walker said, we just proposed the extension and the board