Issue 2935: ots-rtf: TSIdentification (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: Page 10-64 shows the TSIdentification PIDL interface, which must be provided by the ORB core to the OTS service. Several questions here: 1) TSIdentification is not part of any module on page 10-64, and the IDL summary in Section 10.6 does not mention it at all. Which module does it belong to? CORBA? CosTSPortability? Note that the text for the NotAvailable exception states: The NotAvailable exception is raised if the ORB implementation does not support the CosTSPortability module. This seems to be a hint that TSIdentification *is* meant to be part of CosTSPortability. However, that itself raises another question: an ORB core can raise this exception only if there actually *is* a TSIdentification interface that the service can call. In other words, we seem to have a requirement on the ORB core here, namely, that all ORBs must provide this interface, at least to the extent that an OTS implementation can call it (so that the ORB core can raise the exception). 2) The AlreadyIdentified exception is raised if identify_sender() or identify_receiver() were previously called "for this addressing domain". What is an "addressing domain"? The term is never defined. I assume what is meant is "address space"? (That would make sense because, given how the interfaces work, a single process can only deal with a single OTS implementation at a time. 3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping does not specify special mapping rules for these interfaces. In absence of special rules, the default rules apply. However, that begs the question: how does the OTS service get hold of the object reference for TSIdentification, and how does the OTS create references to Sender and Receiver? 4) The spec says: "Prior to the first transactional request, the Transaction Service will identify itself to the ORB within its domain to establish the transaction callbacks to be used for transactional requests and replies." I don't understand how this works. In particular, how does the thread of control get into the OTS service so that the service can register itself? At the very least, there would have to be some sort of call like "initialize_OTS()" that the application code can call, otherwise, the service doesn't ever get a foot in the door. To me, it looks like what would be needed is something on resolve_initial_references that returns an initialization object of some kind, so the client can hand the thread of control to the OTS implementation. resolve_initial_references does mention OTS, for "TransactionCurrent". However, if I call ORB_init() immediately followed by a request for TransactionCurrent, the OTS implementation won't have had a chance yet to intialize itself. In turn, that might make it difficult to return a Current object. The upshot appears to be that there is no way to implement OTS in a way that wouldn't force the developer to use proprietary calls. Resolution: Revised Text: Actions taken: October 11, 1999: received issue Discussion: End of Annotations:===== Date: Mon, 11 Oct 1999 15:02:18 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: issues@omg.org Subject: ots-rtf: TSIdentification Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: k9;!!c8#e9Zjl!!+;fd9 Page 10-64 shows the TSIdentification PIDL interface, which must be provided by the ORB core to the OTS service. Several questions here: 1) TSIdentification is not part of any module on page 10-64, and the IDL summary in Section 10.6 does not mention it at all. Which module does it belong to? CORBA? CosTSPortability? Note that the text for the NotAvailable exception states: The NotAvailable exception is raised if the ORB implementation does not support the CosTSPortability module. This seems to be a hint that TSIdentification *is* meant to be part of CosTSPortability. However, that itself raises another question: an ORB core can raise this exception only if there actually *is* a TSIdentification interface that the service can call. In other words, we seem to have a requirement on the ORB core here, namely, that all ORBs must provide this interface, at least to the extent that an OTS implementation can call it (so that the ORB core can raise the exception). 2) The AlreadyIdentified exception is raised if identify_sender() or identify_receiver() were previously called "for this addressing domain". What is an "addressing domain"? The term is never defined. I assume what is meant is "address space"? (That would make sense because, given how the interfaces work, a single process can only deal with a single OTS implementation at a time. 3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping does not specify special mapping rules for these interfaces. In absence of special rules, the default rules apply. However, that begs the question: how does the OTS service get hold of the object reference for TSIdentification, and how does the OTS create references to Sender and Receiver? 4) The spec says: "Prior to the first transactional request, the Transaction Service will identify itself to the ORB within its domain to establish the transaction callbacks to be used for transactional requests and replies." I don't understand how this works. In particular, how does the thread of control get into the OTS service so that the service can register itself? At the very least, there would have to be some sort of call like "initialize_OTS()" that the application code can call, otherwise, the service doesn't ever get a foot in the door. To me, it looks like what would be needed is something on resolve_initial_references that returns an initialization object of some kind, so the client can hand the thread of control to the OTS implementation. resolve_initial_references does mention OTS, for "TransactionCurrent". However, if I call ORB_init() immediately followed by a request for TransactionCurrent, the OTS implementation won't have had a chance yet to intialize itself. In turn, that might make it difficult to return a Current object. The upshot appears to be that there is no way to implement OTS in a way that wouldn't force the developer to use proprietary calls. 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 Date: Wed, 1 Nov 2000 11:36:20 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 2935 - TSIdentification Message-ID: <20001101113620.B22222@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: gN To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: Issue 2935 - TSIdentification Message-ID: <20001101162826.B13615@ooc.com> References: <20001101113620.B22222@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20001101113620.B22222@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: VA)!!AD9!!j(^d9_-7e9 Hi Blake, Why bother to fix this? Does anyone implement this interface? It's been replaced (or will be replaced) by the portable interceptors. Matthew On Wed, Nov 01, 2000 at 11:36:20AM -0800, Blake Biesecker wrote: > Michi, > > Are you interested in taking a shot at resolving this? > > Blake > > Issue 2935: ots-rtf: TSIdentification (ots-rtf) > Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) > Nature: Uncategorized Issue > Severity: > Summary: Page 10-64 shows the TSIdentification PIDL interface, which must be > provided by the ORB core to the OTS service. Several questions here: > > 1) TSIdentification is not part of any module on page 10-64, > and the IDL summary in Section 10.6 does not mention it at > all. Which module does it belong to? CORBA? CosTSPortability? > > Note that the text for the NotAvailable exception states: > > The NotAvailable exception is raised if the ORB > implementation does not support the CosTSPortability module. > > This seems to be a hint that TSIdentification *is* meant to > be part of CosTSPortability. However, that itself raises another > question: an ORB core can raise this exception only if there > actually *is* a TSIdentification interface that the service > can call. In other words, we seem to have a requirement on > the ORB core here, namely, that all ORBs must provide this > interface, at least to the extent that an OTS implementation > can call it (so that the ORB core can raise the exception). > > 2) The AlreadyIdentified exception is raised if identify_sender() > or identify_receiver() were previously called "for this addressing > domain". > > What is an "addressing domain"? The term is never defined. I assume > what is meant is "address space"? (That would make sense because, > given how the interfaces work, a single process can only deal > with a single OTS implementation at a time. > > 3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping > does not specify special mapping rules for these interfaces. > In absence of special rules, the default rules apply. However, > that begs the question: how does the OTS service get hold of > the object reference for TSIdentification, and how does > the OTS create references to Sender and Receiver? > > 4) The spec says: > > "Prior to the first transactional request, the > Transaction Service will identify itself to the ORB > within its domain to establish the transaction callbacks > to be used for transactional requests and replies." > > I don't understand how this works. In particular, how does the > thread of control get into the OTS service so that the service > can register itself? At the very least, there would have to > be some sort of call like "initialize_OTS()" that the application > code can call, otherwise, the service doesn't ever get a foot > in the door. > > To me, it looks like what would be needed is something on > resolve_initial_references that returns an initialization > object of some kind, so the client can hand the thread of > control to the OTS implementation. > > resolve_initial_references does mention OTS, for > "TransactionCurrent". However, if I call ORB_init() immediately > followed by a request for TransactionCurrent, the OTS > implementation won't have had a chance yet to intialize itself. > In turn, that might make it difficult to return a Current object. > > The upshot appears to be that there is no way to implement OTS in a way > that wouldn't force the developer to use proprietary calls. -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 1 Nov 2000 12:25:50 -0800 From: Blake Biesecker To: Matthew Newhook Cc: ots-rtf@omg.org Subject: Re: Issue 2935 - TSIdentification Message-ID: <20001101122550.D22092@gemstone.com> References: <20001101113620.B22222@gemstone.com> <20001101162826.B13615@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20001101162826.B13615@ooc.com>; from matthew@ooc.com on Wed, Nov 01, 2000 at 04:28:26PM -0330 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: =\U!!B)5!!Oim!!@,e!! This OTS RTF is about providing clarification and fixes for CORBA 2.4 (1.2). Since OTS 1.2 will be around for a while, I think we should consider issues that only impact 1.2. That said, I'd be happy to close this particular issue since portable interceptors is the way to fix this and I'd rather not spend time patching up TSIdentification. Does OOC support closing this issue without action? Blake On Wed, Nov 01, 2000 at 04:28:26PM -0330, Matthew Newhook wrote: > Hi Blake, > > Why bother to fix this? Does anyone implement this interface? It's > been replaced (or will be replaced) by the portable interceptors. > > Matthew > > On Wed, Nov 01, 2000 at 11:36:20AM -0800, Blake Biesecker wrote: > > Michi, > > > > Are you interested in taking a shot at resolving this? > > > > Blake > > > > Issue 2935: ots-rtf: TSIdentification (ots-rtf) > > Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) > > Nature: Uncategorized Issue > > Severity: > > Summary: Page 10-64 shows the TSIdentification PIDL interface, which must be > > provided by the ORB core to the OTS service. Several questions here: > > > > 1) TSIdentification is not part of any module on page 10-64, > > and the IDL summary in Section 10.6 does not mention it at > > all. Which module does it belong to? CORBA? CosTSPortability? > > > > Note that the text for the NotAvailable exception states: > > > > The NotAvailable exception is raised if the ORB > > implementation does not support the CosTSPortability module. > > > > This seems to be a hint that TSIdentification *is* meant to > > be part of CosTSPortability. However, that itself raises another > > question: an ORB core can raise this exception only if there > > actually *is* a TSIdentification interface that the service > > can call. In other words, we seem to have a requirement on > > the ORB core here, namely, that all ORBs must provide this > > interface, at least to the extent that an OTS implementation > > can call it (so that the ORB core can raise the exception). > > > > 2) The AlreadyIdentified exception is raised if identify_sender() > > or identify_receiver() were previously called "for this addressing > > domain". > > > > What is an "addressing domain"? The term is never defined. I assume > > what is meant is "address space"? (That would make sense because, > > given how the interfaces work, a single process can only deal > > with a single OTS implementation at a time. > > > > 3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping > > does not specify special mapping rules for these interfaces. > > In absence of special rules, the default rules apply. However, > > that begs the question: how does the OTS service get hold of > > the object reference for TSIdentification, and how does > > the OTS create references to Sender and Receiver? > > > > 4) The spec says: > > > > "Prior to the first transactional request, the > > Transaction Service will identify itself to the ORB > > within its domain to establish the transaction callbacks > > to be used for transactional requests and replies." > > > > I don't understand how this works. In particular, how does the > > thread of control get into the OTS service so that the service > > can register itself? At the very least, there would have to > > be some sort of call like "initialize_OTS()" that the application > > code can call, otherwise, the service doesn't ever get a foot > > in the door. > > > > To me, it looks like what would be needed is something on > > resolve_initial_references that returns an initialization > > object of some kind, so the client can hand the thread of > > control to the OTS implementation. > > > > resolve_initial_references does mention OTS, for > > "TransactionCurrent". However, if I call ORB_init() immediately > > followed by a request for TransactionCurrent, the OTS > > implementation won't have had a chance yet to intialize itself. > > In turn, that might make it difficult to return a Current object. > > > > The upshot appears to be that there is no way to implement OTS in a way > > that wouldn't force the developer to use proprietary calls. > > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 01 Nov 2000 13:00:08 -0800 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org, harold.carr@eng.sun.com Subject: Re: Issue 2935 - TSIdentification References: <20001101113620.B22222@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6Y`d9+H7!!M8Z!!6]Ke9 JTS spec specifies a mechanism (ie., the method TransactionService.identify_ORB()). http://java.sun.com/products/jts However, it will be nice if we could have some kind of PI (Portable Interceptors) based registration mechanism. I am not sure PI.ORBInitializers could help, since they do not see a ORB instance. Is it possible to use PI for service registration ? Blake Biesecker wrote: > > Michi, > > Are you interested in taking a shot at resolving this? > > Blake > > Issue 2935: ots-rtf: TSIdentification (ots-rtf) > Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) > Nature: Uncategorized Issue > Severity: > Summary: Page 10-64 shows the TSIdentification PIDL interface, which must be > provided by the ORB core to the OTS service. Several questions here: > > 1) TSIdentification is not part of any module on page 10-64, > and the IDL summary in Section 10.6 does not mention it at > all. Which module does it belong to? CORBA? CosTSPortability? > > Note that the text for the NotAvailable exception states: > > The NotAvailable exception is raised if the ORB > implementation does not support the CosTSPortability module. > > This seems to be a hint that TSIdentification *is* meant to > be part of CosTSPortability. However, that itself raises another > question: an ORB core can raise this exception only if there > actually *is* a TSIdentification interface that the service > can call. In other words, we seem to have a requirement on > the ORB core here, namely, that all ORBs must provide this > interface, at least to the extent that an OTS implementation > can call it (so that the ORB core can raise the exception). > > 2) The AlreadyIdentified exception is raised if identify_sender() > or identify_receiver() were previously called "for this addressing > domain". > > What is an "addressing domain"? The term is never defined. I assume > what is meant is "address space"? (That would make sense because, > given how the interfaces work, a single process can only deal > with a single OTS implementation at a time. > > 3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping > does not specify special mapping rules for these interfaces. > In absence of special rules, the default rules apply. However, > that begs the question: how does the OTS service get hold of > the object reference for TSIdentification, and how does > the OTS create references to Sender and Receiver? > > 4) The spec says: > > "Prior to the first transactional request, the > Transaction Service will identify itself to the ORB > within its domain to establish the transaction callbacks > to be used for transactional requests and replies." > > I don't understand how this works. In particular, how does the > thread of control get into the OTS service so that the service > can register itself? At the very least, there would have to > be some sort of call like "initialize_OTS()" that the application > code can call, otherwise, the service doesn't ever get a foot > in the door. > > To me, it looks like what would be needed is something on > resolve_initial_references that returns an initialization > object of some kind, so the client can hand the thread of > control to the OTS implementation. > > resolve_initial_references does mention OTS, for > "TransactionCurrent". However, if I call ORB_init() immediately > followed by a request for TransactionCurrent, the OTS > implementation won't have had a chance yet to intialize itself. > In turn, that might make it difficult to return a Current object. > > The upshot appears to be that there is no way to implement OTS in a way > that wouldn't force the developer to use proprietary calls. Date: Wed, 1 Nov 2000 18:40:35 -0330 From: Matthew Newhook To: Ram Jeyaraman Cc: Blake Biesecker , ots-rtf@omg.org, harold.carr@eng.sun.com Subject: Re: Issue 2935 - TSIdentification Message-ID: <20001101184035.A15430@ooc.com> References: <20001101113620.B22222@gemstone.com> <3A008458.FD6FC0B@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3A008458.FD6FC0B@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: io'e9iFHe9h'pd9PE/e9 Hi, On Wed, Nov 01, 2000 at 01:00:08PM -0800, Ram Jeyaraman wrote: > JTS spec specifies a mechanism (ie., the method TransactionService.identify_ORB()). > http://java.sun.com/products/jts > > However, it will be nice if we could have some kind of PI (Portable Interceptors) based registration > mechanism. I am not sure PI.ORBInitializers could help, since they do not see a ORB instance. > > Is it possible to use PI for service registration ? Of course, if it's not then what's the point? It's perfectly possible to implement OTS on-top of portable interceptors -- for an example see http://www.ooc.com/ots. I don't see the point of propagating the TSIdentification mess -- it's so broken that noone could possible use it anyway (as Michi's example points out). Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 01 Nov 2000 14:32:45 -0800 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Blake Biesecker , ots-rtf@omg.org, harold.carr@eng.sun.com Subject: Re: Issue 2935 - TSIdentification References: <20001101113620.B22222@gemstone.com> <3A008458.FD6FC0B@eng.sun.com> <20001101184035.A15430@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: MfA!!beT!!iL=e9T(2!! Thanks. could you pls send in a proposal for this issue's resolution based on PI based registration ? Ram Matthew Newhook wrote: > > Hi, > > On Wed, Nov 01, 2000 at 01:00:08PM -0800, Ram Jeyaraman wrote: > > JTS spec specifies a mechanism (ie., the method TransactionService.identify_ORB()). > > http://java.sun.com/products/jts > > > > However, it will be nice if we could have some kind of PI (Portable Interceptors) based registration > > mechanism. I am not sure PI.ORBInitializers could help, since they do not see a ORB instance. > > > > Is it possible to use PI for service registration ? > > Of course, if it's not then what's the point? It's perfectly possible > to implement OTS on-top of portable interceptors -- for an example see > http://www.ooc.com/ots. > > I don't see the point of propagating the TSIdentification mess -- it's > so broken that noone could possible use it anyway (as Michi's example > points out). > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 1 Nov 2000 16:58:12 -0800 From: Blake Biesecker To: Ram Jeyaraman Cc: Matthew Newhook , ots-rtf@omg.org, harold.carr@eng.sun.com Subject: Re: Issue 2935 - TSIdentification Message-ID: <20001101165811.H22092@gemstone.com> References: <20001101113620.B22222@gemstone.com> <3A008458.FD6FC0B@eng.sun.com> <20001101184035.A15430@ooc.com> <3A009A0D.61FC4961@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3A009A0D.61FC4961@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Wed, Nov 01, 2000 at 02:32:45PM -0800 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: =TJe9SCAe9;Fad9*@>e9 For clarity's sake, I'd like to vote to close this issue and open new issues explicitly calling out the need for changing the OTS to use PI. (The other option is to leave this issue open until an RTF passes a proposal that replaces TSIdentification with PI.) I'd like to maintain focus on OTS 1.2 fixes and let subsequent RTF's deal with CORBA 3.0 issues. (Remember, we only have two weeks left until the final report for this RTF.) Blake On Wed, Nov 01, 2000 at 02:32:45PM -0800, Ram Jeyaraman wrote: > Thanks. > > could you pls send in a proposal for this issue's resolution based on PI based registration ? > > Ram > > Matthew Newhook wrote: > > > > Hi, > > > > On Wed, Nov 01, 2000 at 01:00:08PM -0800, Ram Jeyaraman wrote: > > > JTS spec specifies a mechanism (ie., the method TransactionService.identify_ORB()). > > > http://java.sun.com/products/jts > > > > > > However, it will be nice if we could have some kind of PI (Portable Interceptors) based registration > > > mechanism. I am not sure PI.ORBInitializers could help, since they do not see a ORB instance. > > > > > > Is it possible to use PI for service registration ? > > > > Of course, if it's not then what's the point? It's perfectly possible > > to implement OTS on-top of portable interceptors -- for an example see > > http://www.ooc.com/ots. > > > > I don't see the point of propagating the TSIdentification mess -- it's > > so broken that noone could possible use it anyway (as Michi's example > > points out). > > > > Regards, Matthew > > -- > > Matthew Newhook E-Mail: mailto:matthew@ooc.com > > Software Designer WWW: http://www.ooc.com > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 01 Nov 2000 15:46:01 -0800 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 2935 - TSIdentification In-Reply-To: <20001101113620.B22222@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ]dVd9]JM!!(dQ!!?Vdd9 I'm not sure this is worth too much effort, since it should get deprecated once portable interceptors are in the core. At 11:36 AM 11/1/00 -0800, Blake Biesecker wrote: >Michi, > >Are you interested in taking a shot at resolving this? > >Blake > >Issue 2935: ots-rtf: TSIdentification (ots-rtf) >Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Page 10-64 shows the TSIdentification PIDL interface, which must be >provided by the ORB core to the OTS service. Several questions here: > > 1) TSIdentification is not part of any module on page 10-64, > and the IDL summary in Section 10.6 does not mention it at > all. Which module does it belong to? CORBA? CosTSPortability? > > Note that the text for the NotAvailable exception states: > > The NotAvailable exception is raised if the ORB > implementation does not support the CosTSPortability module. > > This seems to be a hint that TSIdentification *is* meant to > be part of CosTSPortability. However, that itself raises another > question: an ORB core can raise this exception only if there > actually *is* a TSIdentification interface that the service > can call. In other words, we seem to have a requirement on > the ORB core here, namely, that all ORBs must provide this > interface, at least to the extent that an OTS implementation > can call it (so that the ORB core can raise the exception). > > 2) The AlreadyIdentified exception is raised if identify_sender() > or identify_receiver() were previously called "for this addressing > domain". > > What is an "addressing domain"? The term is never defined. I assume > what is meant is "address space"? (That would make sense because, > given how the interfaces work, a single process can only deal > with a single OTS implementation at a time. > > 3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping > does not specify special mapping rules for these interfaces. > In absence of special rules, the default rules apply. However, > that begs the question: how does the OTS service get hold of > the object reference for TSIdentification, and how does > the OTS create references to Sender and Receiver? > > 4) The spec says: > > "Prior to the first transactional request, the > Transaction Service will identify itself to the ORB > within its domain to establish the transaction callbacks > to be used for transactional requests and replies." > > I don't understand how this works. In particular, how does the > thread of control get into the OTS service so that the service > can register itself? At the very least, there would have to > be some sort of call like "initialize_OTS()" that the application > code can call, otherwise, the service doesn't ever get a foot > in the door. > > To me, it looks like what would be needed is something on > resolve_initial_references that returns an initialization > object of some kind, so the client can hand the thread of > control to the OTS implementation. > > resolve_initial_references does mention OTS, for > "TransactionCurrent". However, if I call ORB_init() immediately > followed by a request for TransactionCurrent, the OTS > implementation won't have had a chance yet to intialize itself. > In turn, that might make it difficult to return a Current object. > >The upshot appears to be that there is no way to implement OTS in a way >that wouldn't force the developer to use proprietary calls. > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** Date: Thu, 2 Nov 2000 22:46:29 -0330 From: Matthew Newhook To: Ram Jeyaraman Cc: Blake Biesecker , ots-rtf@omg.org, harold.carr@eng.sun.com Subject: Re: Issue 2935 - TSIdentification Message-ID: <20001102224629.E1077@ooc.com> References: <20001101113620.B22222@gemstone.com> <3A008458.FD6FC0B@eng.sun.com> <20001101184035.A15430@ooc.com> <3A009A0D.61FC4961@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3A009A0D.61FC4961@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ~&l!!?/id9$Hc!!^GUd9 Hi, On Wed, Nov 01, 2000 at 02:32:45PM -0800, Ram Jeyaraman wrote: > Thanks. > > could you pls send in a proposal for this issue's resolution based on > PI based registration ? What exactly do you want a proposal for? How to implement the OTS spec based on portable interceptors? This issue (as I understand it) points out faults in the TSIdentification interface. This interface should be removed. I'm not sure if anything really needs to be added to the OTS spec to talk specifically about portable interceptors (although I do remember that the PI task force did make some recommendations to the OTS task force about changes to the spec). > Ram Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Thu, 02 Nov 2000 18:51:27 -0800 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Ram Jeyaraman , Blake Biesecker , ots-rtf@omg.org, harold.carr@eng.sun.com Subject: Re: Issue 2935 - TSIdentification References: <20001101113620.B22222@gemstone.com> <3A008458.FD6FC0B@eng.sun.com> <20001101184035.A15430@ooc.com> <3A009A0D.61FC4961@eng.sun.com> <20001102224629.E1077@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: '[n!!,2k!!*O7!!Mg)e9 Hi, Matthew Newhook wrote: > > Hi, > > On Wed, Nov 01, 2000 at 02:32:45PM -0800, Ram Jeyaraman wrote: > > Thanks. > > > > > could you pls send in a proposal for this issue's resolution based on > > PI based registration ? > > What exactly do you want a proposal for? How to implement the OTS spec > based on portable interceptors? No. The following is an excerpt from the issue raised my Mr. Henning. "4) The spec says: "Prior to the first transactional request, the Transaction Service will identify itself to the ORB within its domain to establish the transaction callbacks to be used for transactional requests and replies." I don't understand how this works. In particular, how does the thread of control get into the OTS service so that the service can register itself? At the very least, there would have to be some sort of call like "initialize_OTS()" that the application code can call, otherwise, the service doesn't ever get a foot in the door. " Atleast part of the issue was to specify how the Transaction Service registers with the ORB. I am not sure how the OTS vendors do it either. Anyway, Blake pointed out that this point maybe better addressed when we design post OTS 1.2 as a pluggable service completely based on PI. That is for later i assume. We should leave the issue to be resolved by a future RTF. Regards Ram Date: Thu, 2 Nov 2000 23:25:25 -0330 From: Matthew Newhook To: Ram Jeyaraman Cc: Blake Biesecker , ots-rtf@omg.org, harold.carr@eng.sun.com Subject: Re: Issue 2935 - TSIdentification Message-ID: <20001102232525.B1885@ooc.com> References: <20001101113620.B22222@gemstone.com> <3A008458.FD6FC0B@eng.sun.com> <20001101184035.A15430@ooc.com> <3A009A0D.61FC4961@eng.sun.com> <20001102224629.E1077@ooc.com> <3A02282F.F23DC01B@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3A02282F.F23DC01B@eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: SVO!!8mp!!W<1e9/#i!! Hi Ram, On Thu, Nov 02, 2000 at 06:51:27PM -0800, Ram Jeyaraman wrote: >[...] > Atleast part of the issue was to specify how the Transaction Service registers with the ORB. I am > not sure how the OTS vendors do it either. > > Anyway, Blake pointed out that this point maybe better addressed when we design post OTS 1.2 as a > pluggable service completely based on PI. That is for later i assume. > > We should leave the issue to be resolved by a future RTF. Yes, you're correct. It's necessary to say how the user causes the OTS to be enabled on a particular ORB. When is this going to be specified? I'd prefer sooner rather than later. > Regards > Ram Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725