Title: Message
I
believe we are all agreed about 2 and 3. The rub comes in 1, because it causes
problems with 2-pass architectures vs 1-pass architectures.
A
2-pass architecture validates the entire content of the save operation, then
executes it. That fits well with the requirement that the entire save fails if
any element of it fails. Indeed, I thought this was the intended implementation
while I was reading the standard initially.
A
1-pass architecture validates one item, then saves it, then proceeds to the next
one, rolling the entire transaction back if there's a problem. That's all very
well for those using a transaction-based storage system, but that's not
a prerequisite that we should be placing on the
implementor.
My strong preference is to forbid all internal references
within a single save_ call - we have witnessed all manner of
strange and horrible behaviours that must be specified if one permits references
within the call. Things like: "what if someone saves a service under a different
business after saving it under a first business, all in the one save_business
call?".
Is
there a real use case for allowing resaving within a single call? It seems to me
that the only reason it's allowed is so we have a whole pile of problems to
solve :-(
Tony
Rogers
-----Original Message-----
From: Luc Clement
[mailto:]
Sent: Tuesday, 8 July 2003
14:37
To: Rogers, Tony; Von Riegen, Claus;
Subject: RE: [uddi-spec] Update to
CR-034 (Creating self-referencing tModels)
I have a problem making this
a registry policy. I'm concerned about allow too many degrees of freedom in
the spec when what the CR proposes is consistent with the spec today. To
restate, given:
(1)
a tModel being saved refers to a tModel that is
created earlier in the sequence of tModels
(2)
a tModel being saved (and created) refers to
itself
(3)
a tModel being saved refers to a tModel that is
created later in the sequence of tModels
The proposed solution
(below) seems entirely reasonable and consistent with the rest of the
spec in regards to the processing in document order principle (as well as
satisfying the principle of least astonishment IMO).
Case (1)
is allowed since tModels, like all other entities in save_xx API calls, are
processed in document order.
Case (3)
is not allowed since the tModel to which a keyedReference points to is to be
saved at a later time. An E_invalidKeyPassed error must be
returned.
Case (2)
is not o.k. since it would otherwise require a special processing behavior.
An E_invalidKeyPassed error message must be
returned.
Luc Cl幦ent
Microsoft
From: Rogers, Tony [mailto:]
Sent: Thursday, July 03, 2003 05:45
To: Von Riegen,
Claus;
Subject: RE: [uddi-spec]
Update to CR-034 (Creating self-referencing tModels)
Perhaps we can avoid your discomfort with my suggestion by making the
policy of whether to disallow references within the batch a policy that
applies to the registry as a whole, rather than on a node-by-node basis.
Oh, on re-reading your comments, I see that you've suggested the same
thing. :-)
Tony Rogers
-----Original Message-----
From: Von Riegen,
Claus [mailto:]
Sent: Thu 3/07/2003 20:59
To:
Cc:
Subject: [uddi-spec] Update to CR-034 (Creating self-referencing
tModels)
I took an action item at our May 27 TC meeting to
update CR-034 to meet the following requests:
"Claus took us through the description of this
CR. Tony would rather we disallow references to any tModels not
already in the registry. The problem here is that it imposes an extra
check to do the saves in the registry. A suggestion was made that we
say nodes "MAY" allow (1), but now (2) or (3). Things like service
projections and hosting redirectors would be complicated as well.
We agreed that the CR needs to be changed to
get around the problem by saying that a node MAY permit (1), but MUST
disallow (2) and (3). There is also some confusion in the
CR indicating the error condition as E_invalidKey. It should be
E_invalidValue, depending upon whether it's being used as the category, or
as a value in the category. Need to clarify. Also note
that the entire request may fail, saving the entities separately eliminates
the problem. A similar problem exists with hosting redirector.
Should we create a recommended policy on which
behavior the node supports? Claus will suggest one. Claus will change
the CR and resubmit."
After reviewing the CR and these requests again,
I now believe that the requests lead to additional
problems/questions.
1) Tony's suggestion that a node MAY disallow
references to any tModels not already in the registry is not acceptable
since this may result to a situtation where one node in a registry decides
to allow such references and another decides to disallow them. If such data
is replicated from the first node to the second, this would result in an
unacceptable replication error.
As a result, two alternatives remain: either we
decide that the behavior with regard to such references (allow or disallow
them) MUST be specified on registry level or we decide that they are always
allowed, that is, we stay with the currently specified (V3)
behavior.
2) I don't recall why there was a discussion
about including E_invalidValue as a possible error condition. A tModelKey in
a keyedReference is always a tModelKey, and if it is invalid the
E_invalidKey error condition applies. A tModelKey can certainly be used as a
keyValue in a keyedReference (remember our discussion on value sets that are
based on entity keys) but whether the key is valid or not is a matter of
value set validation. This is specified in a separate section (5.2.3) and
the corresponding error condition is already listed in section 5.2.18.5 of
the save_tModel API call section.
As a result, I don't see a need to update the
specification in this regard.
3) Depending on the outcome of 1), we may even
don't need a corresponding policy.
I'd be interested in differing opinions so that I
can update the CR, if required.
Regards,
Claus
