Issue with Value Sets with entity keys as values

["John Colgrave" <colgrave@hursley.ibm.com>]

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