OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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]