RE: [uddi-spec] CR-010: isReplacedBy tModel

[Anne Thomas Manes <anne@manes.net>]

Question:

What is the expected behavior if someone queries for an entity using an
identifier and the registry finds more than one match? (has this expected
behavior been specified?)

Anne



> -----Original Message-----
> From: Daniel Feygin [mailto:feygin@unitspace.com]
> Sent: Thursday, January 23, 2003 9:36 AM
> To: 'Von Riegen, Claus'; 'Anne Thomas Manes'; 'Uddi-Spec'
> Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
>
>
> Claus,
>
> I did not realize that the identifiers' uniqueness is scoped to an
> entire registry.  I went by the assumption that a given entity could
> have only one value for a given identifier (one keydReference of a given
> tModelKey in the entity's identifierBag), but that there were no other
> requirements on that.  I looked through the spec and found no guidance
> as to what the registry is supposed to do when a businessEntity is
> published with an identifier that is already "claimed" (perhaps
> unjustifiably) by another businessEntity publisher.
>
> V3 definition of an identifier introduces by implication a requirement
> that establishes an indirect relationship between potentially unrelated
> entities.  Thus registry owners are put in the position of not only
> validating publishers' content, which is fine within clearly defined and
> reasonable syntactic and semantic bounds, but also policing
> publisher-to-publisher relationships, which may be quite tricky in some
> circumstances (consider the UBR as an extreme case).  Appendix E, Using
> Identifiers, does not mention the uniqueness requirements of identifier
> values, so one might question the suitability of introducing normative
> requirements (if my assessment of the definition is correct) in the
> glossary appendix of the specification.
>
> Clearly my prior remarks on isReplacedBy capability are inconsistent
> with the apparent 'idea' of the identifier in UDDI V3.  I found no
> references to the scope of identifier uniqueness in V2 though, so I
> wonder if my comments could still apply to V2.  With regard to V3 we
> thus have a choice between adopting the solution proposed in Anne's CR
> or adopting the alternative she mentioned with the implication that the
> definition of the identifier in V3 will have to be revised.  Also it
> would not hurt to add more normative guidance explaining the proper
> enforcement of identifiers' uniqueness characteristics.  If this could
> be left up to registry policy, then we should probably also specify
> that.
>
> Lets try to analyze your point of this being an errata, because it fixes
> an inconsistency.  I can identify 4 scenarios relevant to our
> discussion:
> 1. One entity is replaced by one other entity.  This is one-to-one
> relationship that is covered under existing specification.
> 2. One entity is replaced by multiple entities.  This is one-to-many
> relationship that cannot be implemented under existing specification and
> requires a categorization.  I do not see an inconsistency with the spec
> here, we are extending the spec to cover a new function.
> 3. Multiple entities are replaced by one other entity.  This is
> one-to-many relationship that can be modeled with isReplacedBy, but will
> cause the inconsistency which I assume you are referring to, as multiple
> entities will become identified by one value.  However, the replacement
> entity's identity can be traced to the multiple entities it is
> replacing.  Therefore IMHO it would be more consistent with the general
> idea of identity to model this relationship with an identifier rather
> than with a categorization.  But even if we choose to represent this
> scenario with a categorization, this would still be a new capability
> which I would therefore favor being implemented with a new tModel (say,
> isConsolidatedReplacedBy for the purpose of discussion).
> 4. Multiple entities are replaced by multiple other entities.  I do not
> have a clue as to how this might be modeled without the use of an
> intermediary entity, which would have one-to-many relationships to the
> group of multiple entities being replaced and to the group of newly
> created entities.  That is covered in (2) and (3).
>
> So I assume it is scenario (3) above you find inconsistent with the
> wording of the identifier definition.  I would argue though, that that
> definition is inconsistent with the ability for one-to-many
> transformation of an entity's identity.  Thereby the inconsistency is
> only with the V3 definition of identifiers in UDDI.  isReplacedBy could
> be used as identification scheme tModel to model scenario (3).
> Alternatively, it is possible to model scenario (3) with a
> categorization.  Then we face another choice of either making up another
> tModel or redefining isReplacedBy as a categorization scheme, risking to
> inflict pain on the users.
>
> Also, I searched through the text of V2 specs and found no reference to
> the V3 definition of identifier.  So it is only an inconsistency in V2
> if you consider the general agreement of the Consortium's Working Group
> members as to the concept of identifiers.
>
> Regards,
> Daniel
>
>
> > -----Original Message-----
> > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > Sent: Thursday, January 23, 2003 11:31 AM
> > To: 'Anne Thomas Manes'; Daniel Feygin; 'Uddi-Spec'
> > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
> >
> >
> > Anne, Daniel,
> >
> > Daniel's proposal to let two businessEntities be "identified"
> > by the merged businessEntity (second case from below) seems
> > to be attractive at first view, but it actually contradicts
> > to the idea of an identifier in UDDI.
> >
> > An entity's identifierBag contains identifiers (specified as
> > keyValues in keyedReferences) for the entity itself (see
> > section 3.3.2.10 of the UDDI V3 specification). That's why
> > any identifier should be used only once in a UDDI registry -
> > the V3 glossary (see Appendix L of the UDDI V3 specification)
> > defines an identifier system as "Any value set intended to be
> > used to identify the entities in which it is referenced. An
> > identifier system is distinct from a category system in that
> > only one entitty in a given registry should be associated
> > with a given identifier." And that's why we changed the
> > categorization of the owningBusiness tModel from "identifier"
> > to "categorization" in one of the V2 errata sets. It is used
> > in a tModel to identify the businessEntity that owns the
> > tModel - but it does not identify the tModel, it categorizes
> > it (and many tModels can carry the same category, i.e. be
> > owned by the same businessEntity).
> >
> > Again, the most consistent solution, IMO, would be to change
> > the categorization for the isReplacedBy tModel in both UDDI
> > V2 and V3, if possible at all (in V2). The change can
> > certainly be viewed as a valid errata, since it removes an
> > inconsistency. If the change in V2 is not acceptable, we can
> > start to find the second-best solution.
> >
> > Claus
> >
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Mittwoch, 22. Januar 2003 17:34
> > To: Daniel Feygin; 'Uddi-Spec'; Von Riegen, Claus
> > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
> >
> >
> > +1
> >
> > > -----Original Message-----
> > > From: Daniel Feygin [mailto:feygin@unitspace.com]
> > > Sent: Wednesday, January 22, 2003 11:18 AM
> > > To: 'Uddi-Spec'; 'Anne Thomas Manes'; 'Von Riegen, Claus'
> > > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
> > >
> > >
> > > Anne, Claus,
> > >
> > > Please see my comments inline.
> > >
> > > Thank you,
> > > Daniel
> > >
> > >
> > > > -----Original Message-----
> > > > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > > > Sent: Wednesday, January 22, 2003 5:56 PM
> > > > To: 'Anne Thomas Manes'; Uddi-Spec
> > > > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
> > > >
> > > >
> > > > Anne,
> > > >
> > > > If we have two different tModels for nearly the same concept,
> > > > it would complicate the decision for the publisher which
> > > > tModel to use, but would of course help the inquirer to more
> > > > clearly distinguish between the different cases.
> > > >
> > > > So, let us assume three cases.
> > > >
> > > > First, tModel T1 represents a Web service type for which a
> > > > new version is developed and published as tModel T2. Assuming
> > > > that this is a one-to-one relationship (one tModel can be
> > > > found by using the key of one tModel it is replaced with),
> > > > the publisher of tModel T1 should then add an identifierBag
> > > > to T1 that contains a keyedReference isReplaceBy / tModelKey T2.
> > >
> > > That is how I would prefer to see this recommended.
> > >
> > > > Second, businessEntities B1 and B2 represent businesses that
> > > > are merged to a business, that is published as businessEntity
> > > > B3. This is a many-to-one relationship (many businessEntities
> > > > can be found by using the key of one businessEntity they are
> > > > replaced with), that means the key of B3 is not an
> > > > identifier, neither for B1 nor for B2. Should we recommend to
> > > > use "isReplacedByMultiple" due to this reason, that is, the
> > > > publishers of B1 and B2 each add a categoryBag to their
> > > > businessEntities that contains a keyedReference
> > > > isReplacedByMultiple / businessKey B3?
> > >
> > > No, I would rather see this done by the application of existing
> > > identifier isReplacedBy to both B1 and B2.  That is, the
> > publishers of
> > > B1 and B2 would each add an identifierBag to their businessEntities
> > > that contains a keyedReference isReplacedBy referring to the
> > > businessKey of B3.  The use of isReplacedByMultiple would
> > apply in the
> > > unlikely event of a businessEntity B selling off all of its
> > > businesses, resulting in a number of identities Bx that are
> > separate
> > > from the original B (perhaps a sad example of this could be the
> > > sell-off of some defunct dom-com's assets to different
> > buyers; another
> > > one could have been the court-ordered break up of our good friend
> > > Microsoft [no emotion of any kind intended]).  Then the original B
> > > would add a categoryBag containing several keyedReferences
> > > isReplacedByMultiple enumerating businessKeys of each of resultant
> > > businessEntities Bx.  Am I missing something here?
> > >
> > > > Third, tModel T1 represents a Web service type for which a
> > > > new version is developed that consists of multiple single Web
> > > > service types that are published as separate tModels, for
> > > > example, T2 - T4. The RosettaNet PIP 3A4 is an example for
> > > > this, since up to version 1.4, it consists of messages that
> > > > represent a Purchase Order Request, a Purchase Order Change,
> > > > a Purchase Order Cancellation, and a Purchase Order
> > > > Acceptance, whereas it is followed by PIP 3A4 2.0 (Purchase
> > > > Order Request & Purchase Order Confirmation), PIP 3A8 1.0
> > > > (Purchase Order Change) and PIP 3A9 1.0 (Purchase Order
> > > > Cancellation). This is a one-to-many relationship (one
> > > > businessEntity can be found by using one of the keys of many
> > > > tModels it is replaced with), that means the keys of T2, T3
> > > > and T4 are identifiers, the all "identify" T1. Should we
> > > > recommend to use "isReplacedBy" due to this reason, that is,
> > > > the publisher of T1 adds a categoryBag to A1 that contains
> > > > three keyedReferences isReplacedByMultiple / tModelKey T2,
> > > > isReplacedByMultiple / tModelKey T3, isReplacedByMultiple /
> > > > tModelKey T4?
> > >
> > > That is exactly along the lines of what I am thinking.
> > >
> > > > I fear that I would have problems to explain this to
> > > > publishers so that they make consistent use of the different
> > > > isReplacedBy tModels.
> > > The publishers shouldn't really care - that would be taken
> > care of by
> > > the software they use.  Their only problem would be if we
> > deprecate or
> > > change the definition of existing isReplacedBy tModel that
> > they use.
> > > Guidance to UDDI client implementers is fairly simple too:
> > > 1) when an entity is replaced by one other entity, the
> > _preferred_ way
> > > of communicating that is isReplacedBy;
> > > 2) when an entity is replaced by more than one other entity, the
> > > _only_ way of communicating that is isReplacedByMultiple.
> > >
> > > Hence my interpretation that we are introducing a new
> > capability and
> > > not fixing a bug.  What am I missing?
> > >
> > > > What do you think?
> > > >
> > > > Claus
> > > >
> > > > -----Original Message-----
> > > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > > Sent: Mittwoch, 22. Januar 2003 14:25
> > > > To: Von Riegen, Claus; Uddi-Spec
> > > > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
> > > >
> > > >
> > > > I'm thinking that the better alternative is to create an
> > > > isReplacedByMultiple tModel.
> > > >
> > > > > -----Original Message-----
> > > > > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > > > > Sent: Wednesday, January 22, 2003 7:42 AM
> > > > > To: 'Anne Thomas Manes'; Uddi-Spec
> > > > > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
> > > > >
> > > > >
> > > > > Anne,
> > > > >
> > > > > Thanks for the well-prepared change request.
> > > > >
> > > > > As you note in section 3 (Impact statement), there is a
> > > > > significant
> > > > > impact for UDDI V2 registries if we make the change for
> > V2 also,
> > > > > especially if the tModel is already used often.
> > > > >
> > > > > However, there is at least a similar impact for UDDI V3
> > registries
> > > > > that also support UDDI V2 APIs: at the time UDDI V3 is
> > implemented,
> > > > > all keyedReferences to the V2 isReplacedBy identifier
> > > > system within an
> > > > > identifierBag have to be migrated to then occur within a
> > > > categoryBag.
> > > > > Otherwise, the V2/V3 multi-version registry would have to switch
> > > > > between the two personalities of the keyedReference on the
> > > > fly - and
> > > > > would have to support two personalities of the same
> > tModel for the
> > > > > different UDDI versions as well (note that the key for the
> > > > > isReplacedBy tModel is not changed).
> > > > > But the migration would mean that V2 API call response messages
> > > > > would contain the isReplaceBy tModel as a category system, which
> > > > > is simply wrong per the V2 specification.
> > > > > Thus, I have the dim feeling that we have to change the
> > > > > categorization for the isReplacedBy tModel already in
> > V2 in order
> > > > > to prevent problems that can occur later.
> > > > >
> > > > > An alternative could be to not change the categorization at all
> > > > > ...
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Claus
> > > > >
> > > > > -----Original Message-----
> > > > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > > > Sent: Mittwoch, 22. Januar 2003 00:39
> > > > > To: Uddi-Spec
> > > > > Subject: [uddi-spec] CR-010: isReplacedBy tModel
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Anne Thomas Manes
> > > > > 617-497-1748 (land)
> > > > > 617-642-3144 (mobile)
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>