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

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

+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>
>