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


Claus,

I regard the current specification of owningBusiness_v3 etc. to be an error
as it has the same problems I described for the new Category Systems in the
WSDL TN.

I quite agree that this will require a change to the V3 specification and
envisaged turning my e-mail into a Change Request for V3.  I saw this as
introducing another dependency of the WSDL TN on a V3 CR.

Given/Assuming that the V3 spec. is in error then I think it is appropriate
to change the V3 spec. to add this extra Category System, describe how a
V2/V3 registry implementation must handle Category Systems that have entity
keys as values and remove the V3 versions of any affected Category Systems.

As you know, I do not regard this as a significant performance issue as it
is "just" another instance of multi-version key handling, but triggered by
categorization rather than static typing.  If people feel that this feature
will significantly impact UDDI performance they should certainly say so but
I think this feature is something that we have to have to make current V3
functionality usable, not to mention its critical importance to the way that
the WSDL TN would work in a multi-version registry, and so any performance
concerns would have to be weighed against that.

John Colgrave
IBM


-----Original Message-----
From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com] 
Sent: 28 April 2003 08:39
To: Anne Thomas Manes; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Issue with Value Sets with entity keys as values

Separate tModels for V2 and V3 are necessary since the V3 specification by
no means outlines a special handling of uddiKey-based value sets.
I agree that it would be a good thing to have it - at least for the users of
a UDDI registry - but it would require at least
- a specification of the special behavior for uddiKey-based value sets in a
multiversion registry
- a canonical categorization of such value sets so that both the nodes of a
UDDI registry and UDDI users can programmatically discover when such
behavior is to be applied.

As a consequence, I don't see a possibility to introduce such a behavior in
a Technical Note. It would be possible if we change the V3 specification
itself accordingly (including the currently built-in behavior for the
"owningBusiness" and "validatedBy" value sets). However, there are at least
two
issues this approach faces:
1) We decided to change the V3 specification for errors, inconsistencies and
ambiguities only. The proposed behavior is certainly a new feature. Thus, we
must have good reasons to introduce a new feature in a V3 errata.
2) While the proposed behavior certainly helps UDDI users, it puts another
burden on UDDI implementations, at least as far as the performance is
concerned. I would like to see more feedback from other implementers on this
issue.

Claus

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net] 
Sent: Mittwoch, 16. April 2003 15:46
To: uddi-spec@lists.oasis-open.org
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]