Issue 3342: Correction of CORBA specification (page 18-51) (issues) Source: (, ) Nature: Uncategorized Issue Severity: Summary: >You write on page 18-51: >In COM V2.0, interfaces can have single inheritance. However, as opposed to >CORBA, >there is a standard mechanism by which an object can have multiple interfaces >(without >an inheritance relationship between those interfaces) and by which clients can >query >for these at run-time. (It defines no common way to determine if two interface >references refer to the same object, or to enumerate all the interfaces >supported by an >entity.) > >It's not right, that there's no common way to determine if two interface >references refer to the same object. The IUnknown-Pointer of two different >interfaces of the same object must be the same (object identity in COM). Resolution: Revised Text: Actions taken: February 22, 2000: received issue Discussion: End of Annotations:===== X-Sender: siegel@192.67.184.65 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 22 Feb 2000 05:08:36 -0500 To: issues@omg.org From: Jon Siegel Subject: Fwd: Correction of CORBA specification (page 18-51) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: _+[!!E5Pe9C@_d9p3o!! Hi -- Recently received this issue from a correspondent. Jon Siegel >X-Sender: dody@emerald.omg.org >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 >Date: Tue, 15 Feb 2000 10:42:26 -0500 >To: siegel >From: oliver.wulff@zurich.ch (by way of Dody Keefe ) >Subject: Correction of CORBA specification (page 18-51) > > > >Hi > >I'm doing my dissertation at the ETH in Zurich. I'm occupying with CORBA and >DCOM. > >I have a correction to document "The Common Object Request Broker: Architecture >and Specification" > >You write on page 18-51: >In COM V2.0, interfaces can have single inheritance. However, as opposed to >CORBA, >there is a standard mechanism by which an object can have multiple interfaces >(without >an inheritance relationship between those interfaces) and by which clients can >query >for these at run-time. (It defines no common way to determine if two interface >references refer to the same object, or to enumerate all the interfaces >supported by an >entity.) > >It's not right, that there's no common way to determine if two interface >references refer to the same object. The IUnknown-Pointer of two different >interfaces of the same object must be the same (object identity in COM). > > >You don't mention, how you could solve the following in CORBA. You have defined >an interface ICustomer and implemented it -> COM-Customer- and >CORBA-Customer-Object. Because your system grows and grows, you need a manager >service and define a new interface IManage. It's easy to implement it in COM, >because you implement the additional interface. You can query the new interface >with QueryInterface. There exists no inheritance relationsship between those >interfaces. In CORBA, you need to define a new interface, that is derived from >IManage and ICustomer and implement an new Customer-Object (called >CustomerMan). >In CORBA: I don't think that you can change the parent interface hierarchy (by >adding the IManage at the top) without recompiling the client-applications. >It's >easy to add the IManage interface in CORBA if you've got only the Customer >object. But if you've implemented already a lot of objects like Bank, Account >(different types),... you have to create a new interface for each object: >IBankMan, IAccountMan, ... But you only need to add one interface in COM. >If you >want to implement different behaviors (interface) in CORBA without an >inheritance relationship you need to create a synthetical interface (IBankMan) >to force an inheritance relationship. >I think, an interface defines the object type of an object in CORBA and an >interface defines only a behavior of an object in COM. But, an natural object >(also called business object) can have different behaviors. (BTW, I know, that >my additional interface (IManage) doesn't describe a behavior of a business >object; I only want to make a simple example). The enhanced COM-object is still >the same Customer-Object (same GUID or UUID) whereas the enhanced CORBA-object >is a differente object. CORBA-clients can't refer instances of the enhanced >Customer-Object. But so you can in COM, because you haven't changed the >previous >interface (ICustomer). You have added an interface (behavior) to the existent >object. So newer clients can use both interfaces and older clients use only the >ICustomer interface. >I think, that this difference is an important advantage of COM. An object can >provide interfaces without an inheritence relationship. > >You write, that COM doesn't support expections in the IDL. You note, that CORBA >is language-independent, but not all languages support exceptions. Hence, >Microsoft has chosen the return value HRESULT. If you need more informations >about the error, you can use the error-object which is again a COM-object. >Therefore, language-independence is garanteed. > >I've only mentioned some advantages of COM in this mail. There exists enough >disadvantages of COM that you've mentioned in this specification particularly. > >It would be nice, if you could answer me. > >Thanks a lot > >Oliver Wulff > > ================================================================== Jon Siegel email: siegel@omg.org Director, Technology Transfer http://www.omg.org Object Management Group PLEASE MAKE A NOTE OF OUR NEW ADDRESS AND PHONE NUMBERS: First Needham Place Phone: 781-444-0404 250 First Avenue, Suite 201 Fax: 781-444-0320 Needham, MA 02494 USA ================================================================== Date: Thu, 4 May 2000 15:24:27 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3342 - a proposal - Clarification - Transaction Policy and TransactionalObject Message-ID: <20000504152426.B14264@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: cDAe9d/id9jQ'e9!oW!! Here is a complet proposal for Issue 3343. Please let me know if you see any glaring mistakes or if you think it should be changed. Blake Issue 3343: Clarification - Transaction Policy (ots-rtf) Source: International Business Machines (Mr. Thomas Freund, tjfreund@uk.ibm.com) Nature: Clarification Severity: Summary: Since the updates for TransactionPolicy remove all references to the TransactionalObject Interface how is backward compatibility addressed. As existing BOA/TransactionalObject implementations will continue to exist how do we expect these to interact with the proposed POA/Policy-based implementations. Resolution: Instead of completely removing the TransactionalObject interface, it will instead be deprecated with a note saying that it is in the CosTransactions module only for backward compatibility with OTS 1.0 and 1.1. The Synchronization interface will, however, no longer inherit from TransactionalObject. Revised Text: Modify the text in section 10.3.10 called "TransactionalObject Interface" from OTS 1.1 as follows: Replace the first paragraph with: The TransactionalObject interface is a remnant of previous versions of this specification and is no longer used. It is retained here only for backward compatibility with OTS 1.0 and OTS 1.1. [ Box showing interface TransactionalObject {}; ] The above is to be done instead of removing that section. Adding this section back to the specification will mean that the following sections will need to be renumbered: Renumber the section called "Transaction Policy" (added by Messaging) from 10.3.10 to 10.3.11. Renumber the section called "Creating Transactional Object References" (added by Messaging) from 10.3.11 to 10.3.12. Add these two line to the CosTransactions module in section 10.6: // TransactionalObject has been deprecated. See 10.3.10. interface TransactionalObject {}; Actions taken: February 22, 2000: received issue