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
- From: "Luc Clement" <lclement@windows.microsoft.com>
- To: "John Colgrave" <colgrave@hursley.ibm.com>,<uddi-spec@lists.oasis-open.org>
- Date: Sun, 4 May 2003 11:28:29 -0700
Title:
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.
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".
Question:
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.
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. What is at the core of this
issue IMO is that we do not have a generalized mechanism to express
"internally checked" behaviour. 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?
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.
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; we'd have to modify the spec. The v3 spec isn't broken as such, it's
lacking. We could accept Sam's proposal without making any changes.
I think that we need to
consider these issues as part of our v4 activities.
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
>>
>>
>>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]