Issue 2934: ots-rtf: TransactionFactory (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: Page 10-21: A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification. There are a number of issues here: 1) The section referred to here no longer exists. 2) The life cycle is not an optional component of CORBA. Yet, it appears that OTS cannot be implemented without the Life Cycle Service. 3) Neither OTS nor the Life Cycle Service make a statement as to how I could obtain the FactoryFinder interface that I need to get the transaction factory. I therefore cannot write portable code. 4) The OTS spec makes no statement as to, once I have obtained a factory finder, what factory name I should provide to the find_factories() operation in order to obtain a reference to the transaction factory, so it is impossible to write portable code. 5) We already have resolve_initial_references to solve initial reference problem. Why use a factory finder for this then? In particular, resolve_initial_references("TransactionCurrent") is already in use to obtain a reference to the Current object, so why have two different mechanism for locating initial objects within the same service? Resolution: Remove the text that describes how to find the TransactionFactory in section 10.3.2. Revised Text: Change the first paragraph of section 10.3.2 TransactionFactory Interface from: "The TransactionFactory interface is provided to allow the transaction originator to begin a transaction. This interface defines two operations, create and recreate, which create a new representation of a top-level transaction. A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification." to: "The TransactionFactory interface is provided to allow the transaction originator to begin a transaction. This interface defines two operations, create and recreate, which create a new representation of a top-level transaction." Actions taken: October 11, 1999: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 14:24:10 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: TransactionFactory Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :JX!!)k^!!jaU!!>>;e9 Page 10-21: A TransactionFactory is located using the FactoryFinder interface of the life cycle service and not by the resolve_initial_reference operation on the ORB interface defined in "Example Object Adapters" in Chapter 2 of the Common Object Request Broker: Architecture and Specification. There are a number of issues here: 1) The section referred to here no longer exists. 2) The life cycle is not an optional component of CORBA. Yet, it appears that OTS cannot be implemented without the Life Cycle Service. 3) Neither OTS nor the Life Cycle Service make a statement as to how I could obtain the FactoryFinder interface that I need to get the transaction factory. I therefore cannot write portable code. 4) The OTS spec makes no statement as to, once I have obtained a factory finder, what factory name I should provide to the find_factories() operation in order to obtain a reference to the transaction factory, so it is impossible to write portable code. 5) We already have resolve_initial_references to solve initial reference problem. Why use a factory finder for this then? In particular, resolve_initial_references("TransactionCurrent") is already in use to obtain a reference to the Current object, so why have two different mechanism for locating initial objects within the same service? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 14:49:34 -0800 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Finding the TransactionFactory In-Reply-To: <20000208175456.H430@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ^4-!!+WKe9hH3!!$Sdd9 That text was actually added by an earlier OTS RTF in response to an issue about how to find the TransactionFactory. IMHO, adding new resolve_initial_refernces values everytime we have a bootstrap issue, is a lousy solution. - It requires an ORB upgrade even if the service is provided by a different vendor - It locks us into a single service provider per ORB (chosen by the ORB vendor) - It doesn't give the customer any standard way to configure the value Having said that, I've been out-voted in Notification at least three times and have seen other services do the same thing. I even fell victim to this "disease" in the components spec, in part because I seem to be in the minority who thinks adding arbitrary services to resolve_initial_references is NOT a good thing. In hindsight, using the LifeCycle FactoryFinder was a less than optimal choice, but that was not obvious in 1995. Is there something in INS that might be a better one? At 05:54 PM 2/8/00 -0800, Blake Biesecker wrote: >At the very least, I think we should remove this section from >the spec. If we others think it is important to mention how >to find a TransactionFactory, I don't have a problem I have with >using resolve_initial_references, although we might want to >discuss the need to find more than one TransactionFactory. >(So, just allowing resolve_initial_references("TransactionFactory") >might not meet needs of all applications.) > >comments? suggestions? > >Blake > > >issue archive: >------------------------------- >Issue 2934: ots-rtf: TransactionFactory (ots-rtf) >Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Page 10-21: > > A TransactionFactory is located using the FactoryFinder interface > of the life cycle service and not by the resolve_initial_reference > operation on the ORB interface defined in "Example Object Adapters" > in Chapter 2 of the Common Object Request Broker: Architecture > and Specification. > >There are a number of issues here: > > 1) The section referred to here no longer exists. > > 2) The life cycle is not an optional component of CORBA. Yet, > it appears that OTS cannot be implemented without the Life Cycle > Service. > > 3) Neither OTS nor the Life Cycle Service make a statement > as to how I could obtain the FactoryFinder interface that I > need to get the transaction factory. I therefore cannot > write portable code. > > 4) The OTS spec makes no statement as to, once I have obtained > a factory finder, what factory name I should provide to the > find_factories() operation in order to obtain a reference to the > transaction factory, so it is impossible to write portable code. > > 5) We already have resolve_initial_references to solve initial > reference problem. Why use a factory finder for this then? > In particular, resolve_initial_references("TransactionCurrent") > is already in use to obtain a reference to the Current object, > so why have two different mechanism for locating initial objects > within the same service? > >Resolution: >Revised Text: >Actions taken: >October 11, 1999: received issue >Discussion: > >End of Annotations:===== >Date: Mon, 11 Oct 1999 14:24:10 +1000 (EST) >From: Michi Henning >X-Sender: michi@bobo.triodia.com >To: issues@omg.org >Subject: ots-rtf: TransactionFactory >Message-ID: >Organization: Object Oriented Concepts >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >X-UIDL: :JX!!)k^!!jaU!!>>;e9 > >Page 10-21: > > A TransactionFactory is located using the FactoryFinder >interface > of the life cycle service and not by the >resolve_initial_reference > operation on the ORB interface defined in "Example Object >Adapters" > in Chapter 2 of the Common Object Request Broker: Architecture > and Specification. > >There are a number of issues here: > > 1) The section referred to here no longer exists. > > 2) The life cycle is not an optional component of CORBA. Yet, > it appears that OTS cannot be implemented without the Life >Cycle > Service. > > 3) Neither OTS nor the Life Cycle Service make a statement > as to how I could obtain the FactoryFinder interface that I > need to get the transaction factory. I therefore cannot > write portable code. > > 4) The OTS spec makes no statement as to, once I have obtained > a factory finder, what factory name I should provide to the > find_factories() operation in order to obtain a reference >to the > transaction factory, so it is impossible to write portable >code. > > 5) We already have resolve_initial_references to solve initial > reference problem. Why use a factory finder for this then? > In particular, >resolve_initial_references("TransactionCurrent") > is already in use to obtain a reference to the Current >object, > so why have two different mechanism for locating initial >objects > within the same service? > > Cheers, > > Michi. >-- >Michi Henning +61 7 3236 1633 >Object Oriented Concepts +61 4 1118 2700 (mobile) >PO Box 372 +61 7 3211 0047 (fax) >Annerley 4103 michi@ooc.com.au >AUSTRALIA http://www.ooc.com > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Thu, 10 Feb 2000 08:57:48 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Finding the TransactionFactory In-Reply-To: <3.0.5.32.20000209144934.00b5a7b0@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: N>Sd9k+7e9(opd9Ef(e9 On Wed, 9 Feb 2000, Edward Cobb wrote: > That text was actually added by an earlier OTS RTF in response to an issue > about how to find the TransactionFactory. > IMHO, adding new resolve_initial_refernces values everytime we have a > bootstrap issue, is a lousy solution. > - It requires an ORB upgrade even if the service is provided by a > different vendor No. > - It locks us into a single service provider per ORB (chosen by the ORB > vendor) No. > - It doesn't give the customer any standard way to configure the value No again :-) INS solves all of these issue portably. > In hindsight, using the LifeCycle FactoryFinder was a less than optimal > choice, but that was not obvious in 1995. Is there something in INS that > might be a better one? INS permits full configurability of resolve_initial_references. That solves the problem neatly, as far as I can see. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38A1F406.ACC0BF70@floorboard.com> Date: Wed, 09 Feb 2000 15:11:02 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Edward Cobb CC: Blake Biesecker , ots-rtf@omg.org Subject: Re: Finding the TransactionFactory References: <3.0.5.32.20000209144934.00b5a7b0@svlhome2.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *VAe9cb\!!Ni$e9P[F!! Edward Cobb wrote: > > That text was actually added by an earlier OTS RTF in > response to an issue > about how to find the TransactionFactory. > IMHO, adding new resolve_initial_refernces values everytime > we have a > bootstrap issue, is a lousy solution. > - It requires an ORB upgrade even if the service is provided > by a > different vendor > - It locks us into a single service provider per ORB (chosen > by the ORB > vendor) > - It doesn't give the customer any standard way to configure > the value > Having said that, I've been out-voted in Notification at > least three times > and have seen other services do the same thing. I even fell victim > to this > "disease" in the components spec, in part because I seem to be in > the > minority who thinks adding arbitrary services to > resolve_initial_references > is NOT a good thing. > In hindsight, using the LifeCycle FactoryFinder was a less > than optimal > choice, but that was not obvious in 1995. Is there something in INS > that > might be a better one? INS does ameliorate this, since it makes adding a new identifier for resolve_initial_references an administrative function that does not require buying a new ORB. :-) Particularly when combined with Portable Interceptors which provides the ability for services to get hooks into the ORB startup process and add new inital reference identifiers for locality constrained objects. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 09 Feb 2000 18:22:32 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: Edward Cobb , Blake Biesecker , ots-rtf@omg.org Subject: Re: Finding the TransactionFactory References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: a%p!!U,cd9P\9!!^9Sd9 Michi Henning wrote: > On Wed, 9 Feb 2000, Edward Cobb wrote: > > > That text was actually added by an earlier OTS RTF in response to an issue > > about how to find the TransactionFactory. > > IMHO, adding new resolve_initial_refernces values everytime we have a > > bootstrap issue, is a lousy solution. > > - It requires an ORB upgrade even if the service is provided by a > > different vendor > > No. > > > - It locks us into a single service provider per ORB (chosen by the ORB > > vendor) > > No. > > > - It doesn't give the customer any standard way to configure the value > > No again :-) > > INS solves all of these issue portably. > > > In hindsight, using the LifeCycle FactoryFinder was a less than optimal > > choice, but that was not obvious in 1995. Is there something in INS that > > might be a better one? > > INS permits full configurability of resolve_initial_references. That solves > the problem neatly, as far as I can see. Isn't it Interceptors that fixes this problem via register_initial_reference? Or am I losing my mind again? Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Thu, 10 Feb 2000 10:04:27 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Edward Cobb , Blake Biesecker , ots-rtf@omg.org Subject: Re: Finding the TransactionFactory In-Reply-To: <38A1F6B8.DE6B694A@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: PHP!!WSYd9-n8e96'Qe9 On Wed, 9 Feb 2000, Jishnu Mukerji wrote: > Isn't it Interceptors that fixes this problem via register_initial_reference? Or am I > losing my mind again? PI can do this too, even for local objects. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html