Issue 2396:  Correct issues with CosObjectIdentity::IdentifiableObject in StateIDManage                                                                                                                             (currency-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: Use of CosObjectIdentity::IdentifiableObject as the interface for a
 stateIdentifier. There is a particularly concerning paragraph in v1.0 of
 the Relationship Service regarding the interface: “The value of this
 attribute [readonly attribute ObjectIdentifier constant_random_id] is not
 guaranteed to be unique; that is, another identifiable object can return
 the same value. However, if objects return different identifiers, clients
 can determine that two identifiable objects are not identical”.
 

Resolution: closed, no changes
Revised Text: Resolution:  Because the IdentifiableObject will be replaced with a basic type (see Issue 2776), this is no longer an issue.  It is the implementors responsibility that stateId stays unique.
Actions taken:
January 11, 1999: received issue
May 4, 2000: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <Robert_Mickley@CYBORG.COM>
From: Robert_Mickley@CYBORG.COM
X-Lotus-FromDomain: CYBORG@CYBORG_NET
To: issues@omg.org
cc: Robert_Mickley@CYBORG.COM, Amy_Griffis@CYBORG.COM
Date: Mon, 11 Jan 1999 21:28:52 -0700
Subject: Currency RTF Issues
Content-Disposition: inline



Today is the deadline for comments for the Currency RTF.  Below is an
itemized list of additions to that list.

Use of CosObjectIdentity::IdentifiableObject as the interface for a
stateIdentifier. There is a particularly concerning paragraph in v1.0
of
the Relationship Service regarding the interface: attribute [readonly
attribute ObjectIdentifier constant_random_id] is not
guaranteed to be unique; that is, another identifiable object can
return
the same value. However, if objects return different identifiers,
clients
can determine that two identifiable objects are not identicla.

Issue Title: Correct issues with CosObjectIdentity::IdentifiableObject
within StateIDManager
Issue Type: Text and IDL Revision
Issue Description:
Use of CosObjectIdentity::IdentifiableObject as the interface for a
stateIdentifier. There is a particularly concerning paragraph in v1.0
of
the Relationship Service regarding the interface: attribute [readonly
attribute ObjectIdentifier constant_random_id] is not
guaranteed to be unique; that is, another identifiable object can
return
the same value. However, if objects return different identifiers,
clients
can determine that two identifiable objects are not identicla.

        The first sentence in the paragraph is the most
concerning. There
        must be a one to one correlation between a given
stateIdentifier
        and the configuration/session which it identifies. Thus, if
two
        different IdentifiableObject instances return the same
        constant_random_id, they then
        must refer to the same configuration/session or
IdentifiableObject
        is an unsuitable interface for stateIdentifier. i.e. If two
        different IdentifiableObject instances (in the same or
different
        process space or computer) have the same underlying
        constant_random_id (e.g. 323) the configuration values for
both
        instances indicate the same stateIdentifier. Thus, both
        IdentifiableObjects would have the same
        MoneyCalculator.internalPrecision,
MoneyFormatter.formattingString,
        CurrencyBook.baseCurrencyMnemonic, etc. through all
stateIdentifier
        based configuration settings. If this is not correct, then a
        stateIdentifier should live up to a DIFFERENT interface than
        IdentifiableObject.

        The second sentence is also of concern as it states that a
client
        should determine stateIdentifier equality without using the
        is_identical interface. The client then has the option of
        containing the knowledge of  what determines equality for a
        stateIdentifier. The interface that the stateIdentifier lives
up to
        should insulate all consumers from that knowledge, even if it
is a
        simple comparison.

        What can be done to solve this problem?

1.   Use IdentifiableObject for the interface that a stateIdentifier
lives
up to, but our implementation has different intent
(i.e. is_identical()
returns true if otherObject represents the same stateIdentifier) than
that
documented in the Relationship Service.
2.   stateIdentifier becomes a simple unsigned long or int.
3.   Create a different interface for stateIdentifier such as:

        interface StateIdentifier
        {
           readonly attribute stateId;

           //
           // Returns true if otherObject represents the
          // same state, configuration, or session as this
          // StateIdentifier instance.
           //

           boolean equal(in StateIdentifier otherObject);
        }