[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Issue with Value Sets with entity keys as values
+1. Having different tModels for V2 and V3 won't work. The only viable option is to use mapped keys. I'm not convinced that we need to create a new categorization, though. I think we can get by with a new uddi-type ("entityTypeKeys" similar to "checked") - or perhaps a set of types that would allow us to specify the type of entity key: - entityTypeKeys - businessKeys - serviceKeys - bindingKeys - tModelKeys Anne > -----Original Message----- > From: John Colgrave [mailto:colgrave@hursley.ibm.com] > Sent: Wednesday, April 16, 2003 5:25 AM > To: uddi-spec@lists.oasis-open.org > Subject: [uddi-spec] Issue with Value Sets with entity keys as values > > > The WSDL TN makes use of three Category Systems that have entity keys, > specifically tModel keys, as the valid values: > 1) portType tModel reference > 2) protocol categorization > 3) transport categorization > > The valid values of these Category Systems are, deliberately, dynamic and > depend on the registry content at the time that an entity is > published that > uses one of these Category Systems. The valid values also depend on which > version of the UDDI API is being used. If a keyedReference is being > published using V2 then the valid values are the set of V2 entity keys, > perhaps of one particular type such as tModel keys. If a > keyedReference is > being published using V3 then the valid values are the > corresponding set of > V3 keys. The valid UDDI entities are the same in each case, but > the type of > key that is used to refer to them is appropriate to the version > of the UDDI > API being used. > > These Category Systems are not compatible with the support for External > Checked Value Sets. > > The WSDL TN was written (implicitly) assuming that the keyValue in > keyedReferences for these Category Systems would be mapped > between V1/V2 and > V3 in the same way that entity keys are mapped between versions everywhere > else they are used. > > As an example, if a V2 application wanted to publish a binding > tModel for a > wsdl:binding that used the SMTP transport it would use the following > keyedReference: > > <keyedReference tModelKey="uuid:4eeccd58-d3b0-3a6f-a466-9cce01cb1273" > keyName="V2 transport" > keyValue="uuid:93335D49-3EFB-48A0-ACEA-EA102B60DDC6"/> > > If, on the other hand, it were a V3 application that wanted to publish the > same binding tModel, it would use the following keyedReference: > > <keyedReference tModelKey="uddi:uddi.org:wsdl:categorization:transport" > keyName="V3 transport" keyValue="uddi:uddi.org:transport:smtp"/> > > So far, so good. > > The issue is what happens when a V3 application retrieves a binding tModel > that was published by a V2 application, or vice versa. The WSDL > TN assumes > that both the tModelKey value and the keyValue are mapped as > appropriate so > that the application that retrieves the tModel sees exactly the same > keyedReference whether the keyedReference was saved by a V2 > application or a > V3 application. > > This would appear to me to be a good thing. > > The suggestion made by Claus is to have separate V3-specific Category > Systems that can only have V3 keys as their valid values, and have the > original Category Systems only have V2 keys as their valid > values. This is > similar to what was done with owningBusiness in V3. > > Note that both the "V2" and "V3" Category Systems would have both > V2 and V3 > keys so they could each be used by both versions of the UDDI API but the > application would have to know both the V2 key for an entity and the > corresponding V3 key for an entity, and both V2 and V3 applications would > have to be written to know about both versions, which is a significant > difference. > > If an application were not written with knowledge of both > versions then if a > V2 application published the binding tModel as above and a V3 application > were to retrieve it, the V3 application would see a single keyedReference > with a tModelKey that was the V3 key of the V2 Category System and a > keyValue that was the V2 key of a protocol tModel. This V2 key would be > meaningless to the V3 application. > > Conversely, if a V3 application published the binding tModel and then a V2 > application retrieved it, it would see a single keyedReference with a > tModelKey that was the V2 key of the V3 Category System, which it > would not > recognize as the V2 application was written without knowledge of V3, and a > keyValue that was the V3 key of a protocol tModel. This V3 key would be > meaningless to the V2 application. > > The only way that I can see the "owningBusiness" approach working > is if the > applications take responsibility for dealing with the > multi-version issues. > > To continue the example, this would mean that an application that > published > a binding tModel would have to be aware of both the V2 Category System and > the V3 Category System and publish two keyedReferences, one in each of the > Category Systems so that the binding tModel could be used by both > V2 and V3 > code. I do not know how it is intended that V2 code can find the V3 key > corresponding to a V2 key or vice versa. > > Assuming that the binding tModel were published with both keyedReferences, > then the code that retrieved the tModel would have to ignore one of the > keyedReferences (the one using the "foreign" version) and use the one that > matched its version of the UDDI API. > > There would be a migration issue as well as if the tModels were originally > published in a V2-only registry then there is no way that the V3-specific > keyedReference could be published, so when the registry were upgraded to > support both V2 and V3, the extra keyedReferences would have to > be added to > each tModel before they could be used by V3 applications. > > I just can't see how to make this approach work, and that applies > to things > like owningBusiness that are already in V3 as much as the WSDL TN. > > The only way that I can see to allow for Category Systems, or > Value Sets in > general, that can take entity keys as values is to apply the > mapping to the > entity keys that are used in the keyValue attribute in the same > way that we > map entity keys everywhere else. This is the only way that I can see to > allow both V2 code and V3 code to know about only their own version of > entity keys and have interoperability/portability of registry content > across/between applications written to different versions of the UDDI API > that access the same registry. > > As Tony pointed out, probably the best way to achieve this is to > categorise > such Value Sets with an indication that the valid values are UDDI entity > keys, and the specific type of entity if that is known, as it is > in the case > of the WSDL TN. > > Such a categorization would have to be done via a new canonical > tModel that > was added to V3, and the new Category Systems etc. such as > owningBusiness_v3 > would have to be removed from V3. > > John Colgrave > IBM > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]