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

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

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>
> > >
> > 
> > 
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > 
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>