uddi-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [uddi-spec] Update to CR-034 (Creating self-referencing tModels)
- From: Andrew Hately <hately@us.ibm.com>
- To: "Luc Clement" <lclement@windows.microsoft.com>
- Date: Tue, 8 Jul 2003 10:30:44 -0500
Regarding the following: "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."
That requirement exists in the specification
in Section 5.2:
"API calls in this section MUST all
be implemented as synchronous and “atomic” from the point of view of
the caller. That is, each call MUST either succeed completely or fail completely.
Partial results MUST NOT be returned."
Therefore, if the underlying system does
not allow for a transaction for a publication request, a 2 pass processing
methodology is required.
Regarding "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 :-("
There are also use cases for saving
entities in the same call. Any registrar system that batches publication
updates using a transaction log format may not optimize the log to remove
duplicate entries before publication. There used to be some marketplace
software that existed and took advantage of this behavior. While
the software no longer exists, I believe the use should still be considered
as valid. Data promotion/import tools are also likely to take advantage
of the multiple entities in a save_xx call to reduce the number of network
calls, so this issue will likely resurface in implementation (in that case
I would hope that the data is not duplicated, but to get around circular
or self referencing, it might be).
It is probably worth noting with import
tools that part 2 of this solution (the part that is not contentious...
"(2) a
tModel cannot be created with a reference to itself"),
requires that data promotion/import tools that make use of the default
save_tModel behavior will need to save a self referencing tModel using
two API calls.
Specifying that all internal references
are precluded would essentially always require 2 pass validation to occur,
which prohibits registry implementation to take advantage of an underlying
transactional system should one exist, or even a reference resolution system.
I believe that the note as written provides
the most implementable solution to an obscure use of the key assigmnent
allowed in the V3 specification.
It is worth noting, that Tony may have
outlined an other issue that needs to be addressed in this CR which is
hostingRedirectors and serviceProjections created and referenced in single
save_service and save_business calls.
Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies
Lotus Notes: Andrew Hately/Austin/IBM@IBMUS
Internet: hately@us.ibm.com
(512) 838-2866, t/l 678-2866
"Luc Clement"
<lclement@windows.microsoft.com>
07/08/2003 12:36 AM
|
To
| "Rogers, Tony"
<Tony.Rogers@ca.com>, "Von Riegen, Claus" <claus.von.riegen@sap.com>,
<uddi-spec@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [uddi-spec] Update to
CR-034 (Creating self-referencing tModels) |
|
I do appreciate the issues wrt th is in the
face of 2-pass architectures, that said, a change in favour of rejecting
self-referencing imposes additional validation requirements on single-pass
implementations which otherwise do not have to perform this.
The out suggested is that we make this a "MAY"
and registry policy (an absolute requirement in a registry replicating
data between its nodes). I'm really not too keen making this a registry
policy and would prefer making this normative behaviour. If we accept this,
then we have a choice of picking between the needs of single-pass vs 2-pass
architectures.
Let's discuss tomorrow.
From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Monday, July 07, 2003 21:54
To: Luc Clement; Von Riegen, Claus; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Update to CR-034 (Creating self-referencing
tModels)
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:lclement@windows.microsoft.com]
Sent: Tuesday, 8 July 2003 14:37
To: Rogers, Tony; Von Riegen, Claus; uddi-spec@lists.oasis-open.org
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ément
Microsoft
From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Thursday, July 03, 2003 05:45
To: Von Riegen, Claus; uddi-spec@lists.oasis-open.org
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:claus.von.riegen@sap.com]
Sent: Thu 3/07/2003 20:59
To: uddi-spec@lists.oasis-open.org
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 You may leave a Technical
Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]