Comments
inline, <JC>like this</JC>.
-----Original Message-----
From: Luc Clement
[mailto:lclement@windows.microsoft.com]
Sent: 04 May 2003 19:28
To: John Colgrave;
uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Issue
with Value Sets with entity keys as values
My take-back
from this thread is that this TN is considering introducing to v3
(arguably v2) a new canonical categorization tModel that is internally verified
by a node supported by an additional attribute on categorization indicating the
need to perform key mapping. owningBusiness and isReplacedBy tModels were also
identified as being at issue.<JC>If by “this TN” you mean the WSDL TN then
there are three Category Systems that rely on the “key-mapping”
behaviour. It is also my view that the Value Sets in V3 that take entity keys
are not usable in a registry that supports both V2 and V3. Key-mapping issues
are of course irrelevant to a V2-only registry or a V3-only registry. The new
Category System is therefore not needed in the V2 specification, although V2
support in a V2/V3 registry will have to be aware of it.</JC>
I sense that the discussion too quickly jumped to the
"node-performs-the-mapping solution". Sam pointed out a reasonable
option that needs further discussion: "a burden to the publishers (or
publishing app), who have to explicitly publish two keyedReferences: one for v2
and one for v3". <JC>I have
already pointed out why this would not work: a V2 app would definitely not know
the correct V3 key to use and a V3 app would almost certainly not know the
correct V2 key to use. I have also pointed out what would be a compromise
solution, having the registry generate the “partner” keyedReference,
but two of the Value Sets in V3 do not have a V2 equivalent therefore it is not
possible to save a keyedReference containing a V2 key. This approach would
also not work for signed data.</JC>
What happens to digital signed data if a node was to
perform server-side mapping? We went to some length to ensure that a v3 node
did not modify any of part of a publisher's data specifically to avoid
situations where a node would break a signature. This argues against any form
of mapping server-side.<JC>This
has already been addressed by myself and Tony. A digital signature is only
relevant when V3 code has published the data and V3 code is doing the inquiry.
In this case no mapping is necessary, the correct data will be returned and the
signature will be valid. Also, the tModelKey is already mapped and people are
quite happy with that. All I am saying is that in those cases where the
keyValue is an entity key then the keyValue should be mapped in exactly the
same way.</JC>
Internally Checked Categorization:
The issue of "magic" behaviour discussed is related
but orthogonal. I dislike the "magic" of the owningBusiness and
isReplacedBy tModels in that it requires nodes to special-sauce behaviour;
what's called for by server-side key mapping is yet another example of
"internally checked" behaviour. <JC>Mapping goes beyond “mere” checking, and
indeed requires checking as part of its operation.</JC>What is at the core of this issue IMO is that
we do not have a generalized mechanism to express "internally
checked" behaviour<JC>I
agree that there is no definition of internal checking and therefore no way to declare
it. This is the aspect I said I had chosen not to address. The proposed
solution takes the same approach as the current specification as far as
checking is concerned. If a Value Set is categorized as having entity keys for
valid values then the implementation knows exactly what to do.</JC>. Every new internally checked behaviour requires an
implementor to crack open the code and implement new behaviour. What is a node
to specifically check when it encounters such a categorization? <JC>In the case of an internally checked Value
Set that is declared as taking entity keys as valid values, the node has to
check that the keyValue supplied is a valid key of the correct type of entity.</JC>To date, we're identified the behaviour to
implement in the core spec. We now are considering a TN that calls for the
introduction of yet new behaviour.<JC>The WSDL TN does not require any additional behaviour
over and above what I claim is required to fix V3.</JC>
Even if we were to accept the proposed "additional attribute
on a tModel indicating key mapping" that would still be insufficient to
express the specific semantic checks to be performed; <JC>I disagree</JC>we'd have to modify the spec. The v3 spec isn't
broken as such, it's lacking. <JC>It is broken if you want to support both V2 and V3 at the
same time.</JC>We could accept
Sam's proposal without making any changes.<JC>I disagree. Somebody will have to explain how V2 code
can know V3 keys and vice versa.</JC>
I think that we need to consider these issues as part of our v4
activities.<JC>Obviously,
given all the above, I disagree. This needs fixing in V3.</JC>
Luc Clément
Microsoft
-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Thursday, May 01, 2003 04:24
To: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Issue with Value Sets with entity keys as values
Sam,
I have prepared a Change Request (CR-032) for this which I will be making
available shortly (as soon as I figure out how to!).
I do not think that the V2 specification needs to change. I am a little
concerned that we still use "checked" to mean both internally
verified and externally verified but I am choosing to ignore that for the
moment. The tModels for owningBusiness and isReplacedBy are both
categorized as checked in V2, so V2 already has the concept of validating that
a keyValue is a valid entity key, relying on "magic", or at least the
words in the V2 specification, to know which type of entity keys are valid.
It is tempting to leave the affected tModels in the WSDL TN as unchecked to simplify
the implementation of the TN but I think that the right thing to do is to
declare them checked. I have updated the TN accordingly. It will be
part of a V2 implementation of the WSDL TN to do the validation in the same way
that it is currently done for owningBusiness and isReplacedBy, using the same
amount of "magic" as for owningBusiness and isReplacedBy.
I think this is sufficient for a V2-only implementation of the WSDL TN.
The extra work to map the keys only applies to a multi-version registry.
I think it is a good idea to remove "magic" where we can so I am
still proposing a new categorization to indicate both that key mapping is
required and also the valid type(s) of entity keys. I think this is an
improvement on the "magic" in V2. The V3 versions of the
existing V2 tModels and all the new V3 tModels that take entity keys as values
will have this extra categorization added to them, including the WSDL TN
tModels, and this will allow a multi-version registry implementation to do the
appropriate validation and mapping
I disagree with a few elements of your recap but I will leave any further
discussion until the CR appears.
John Colgrave
IBM
-----Original Message-----
From: Wai-Kwong Sam
LEE [mailto:Sam.Lee@oracle.com]
Sent: 30 April 2003 23:15
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
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
>>
>>
>>
>
>
|