I
have uploaded CR-032.
I agree that the tModels don’t need
to be checked for the mapping to happen, and in fact being able to do the
mapping is (almost) a sufficient check! However, as I said in my response
to Sam, I think it is reasonable to require checking in V2 to be consistent with
the other V2 Value Sets that have entity keys as valid values.
I have gone for a categorization
approach. I think that this is a perfectly valid categorization and has
the benefit that it can be queried, although off the top of my head I can’t
think why someone would want to find all tModels that have this categorization,
but you never know.
I agree that this is a pretty fundamental
problem, at least for multi-version registries, and as you will see if you read
the CR I can think of only one solution: that which I have already described.
-----Original Message-----
From: Rogers, Tony
[mailto:Tony.Rogers@ca.com]
Sent: 01 May 2003 01:34
To: Wai-Kwong Sam LEE ; John
Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Issue
with Value Sets with entity keys as values
Sorry, Sam, but I don't think I agree. I do not see
that the tModels must be checked for the mapping to happen. Oh, it is a
"nice to have" that the keys be genuine, but we can still cope even
if they are not, surely? It is possible to identify whether a "key"
is version 2 or version 3 by inspection, and there is an algorithm we can apply
to convert in either direction, so we can convert a "key", even if it
isn't genuine. Or have I missed something?
I am, however, increasingly of the mind that this
particular functionality should not be "magic" (I really detest
"magic"!)- that we do not want to have "magic" tModels that
get special treatment for their values. I believe we should include (yes, as a
change to V3 that will have an impact of V4) the ability to mark a tModel as
"version-key-converting" (I'm open to a better name, though). Any
such tModel will have all its values run through a filter on read and write,
with appropriate conversions based on the API version of the request.
To add to my heresy, I wonder if this might not be
better handled by adding an attribute to the tModel structure. Yes, it would be
possible to identify tModels with this property by adding an entry to their
category bag, but I suggest this because we already know this will require
change to any UDDI server implementing it, and it may be simpler to implement
the change if the server is checking for an attribute rather than for the
presence of a particular tModel key in the category bag. We are asking the
server to do some special processing of the values - it seems only reasonable
not to pretend that this is some kind of "normal" addition.
I have to say that this problem feels like one part of
the version 3 spec that is fundamentally broken, and if it requires an
unpleasant change to fix it, I'd suggest we accept that unpleasant change,
rather than painting over it and pretending that it's not a problem. I was not
around when the decision was made to change the keying system from version 2 to
version 3, but I think we are still dealing with the ramifications of that
change.
Now excuse me while I crawl behind this handy concrete
wall... I suspect I may get an "education" in the next little while
:-)
Tony Rogers
-----Original Message-----
From: Wai-Kwong Sam LEE
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Sent: 1/05/2003 8:14 AM
Subject: Re: [uddi-spec] Issue with
Value Sets with entity keys as values
John / Claus / Others,
I think if we go down the path of making the registry
do the mapping,
UDDIv2
specification may need to be
changed as well.
The scenario is, in order to allow the registry do the
automatic mapping
of the
keyValue from v2 keys to v3 keys,
the registry needs to know that the
keyValues
are indeed geniue entity keys,
(similar to the case that the registry
needs to
validate that
tModelInstanceInfo/@tModelKey is indeed a real tModelKey).
Currently, these tModels (defined in UDDI-WSDL TN,
such as
portTypeReference)
are unchecked. They need to be made
checked so that the registry can
reject
invalid keyedReferences (that do
not reference to a real tModelKey).
Making these tModels checked is probably a good
feature to begin with.
It can
reduce the likelihood of poor data
and be consistent with the checking
behavior
of similar canonical tModels like
owningBuinsess. But the catch is, we
need to
start doing it in UDDIv2.
A recap of the discussion so far:
1. owningBussiness_v3 approach
- a burden to
the publishers (or publishing app),
who
have to explicitly publish two keyedReferences: one for v2
and
one for v3.
- in particular,
a burden to publisher during v2-v3 migration
- inquiry users
/apps are not affected, as they know the
version-specific
keys: both the categorization scheme tModelKey and the value sets
are
version-specific.
2. make registry do the mapping, by categorizing these
new tModels
with an
indication that the value set keyspace is UDDI entity keys
- relieves the
burden on publishers in approach 1
- inquiry users
/ apps are again not affected, as in approach 1
- some burden to
registry implementation, potentially performance
concern.
- need to change
the v3 spec
- need to change
the v2 spec too, in my opinion.
- sam
John Colgrave wrote:
> 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
>>
>>
>>
>
>