[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] The modification problem gets worse...
Jeff,
I'm sorry, I hadn't realised that you agreed on the common problem with
replace. In the example at the start of this thread you claimed that an
approach based on XPath would not work but your example assumes that the
XPath specifier would be relying on the existing values of the contact
list. Instead, it could easily identify the contact list as a whole to
perform the add, just as you would identify the specific attribute to which
you wished to add the value. It would also be possible, as I said in a
previous message, for the target to use some kind of timestamping to
version the data so that a replace would fail if the data was stale.
Either of these approaches is possible. A request based on the first,
XPath, might look something like:
POST /services/provisioningServicePoint HTTP/1.1
Host: www.tiny.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction:
"urn:oasis:names:tc:SPML:0.1:provisioning:psp:modifySubscription"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<psp:modifySubscription
xmlns:psp="urn:oasis:names:tc:SPML:0.1:provisioning:psp">
<add>
<identifier
xmlns="urn:oasis:names:tc:SPML:0.1:provisioning:spmlquery">
<select>//parameters/ns1:FriendsAndFamilyAccount/ns1:contacts</select>
<namespace prefix="ns1">
<uri>http://www.tiny.com/schema/friendsAndFamily</uri>
<namespace>
</identifier>
<parameters>
<Contact
xmlns="http://www.tiny.com/schema/friendsAndFamily">
<firstname>Tilly</firstname>
<lastname>Ledbetter</lastname>
<nickname>Cousin</nickname>
<phone>(321)555-1236</phone>
</Contact>
</parameters>
</add>
</psp:modifySubscription>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
This is very similar to the SPML/DSML approach, even down to the same
operation name but with a complex data item rather than a simple
attribute/value set. As I said before, I've seen a versioning system used
frequently where the data item carries around a version in the form of a
timestamp or a simple integer that at least allows the system to figure out
that there is a conflict. For this scenario, the friends and family schema
produced by the target would be ameded to include such a timestamp:
...
<xsd:complexType name="FriendsAndFamilyAccountType">
<xsd:sequence>
<xsd:element name="contacts" type="fnf:ContactList" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="version" type="dateTime" minOccurs="1"
maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
...
The system would then reject a second modify request because the
modification time on the data would be older than the time specified in the
request.
Of these two approaches I have to admit that the first is more appealing to
me. It's more explicit, removes the burden of carrying around data just
for this purpose, and it alleviates the responsibility on the target,
client, and possibly even the PSP to manage the version.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/13/2003 10:26 |
| | AM |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Gearard Woods/Irvine/IBM@IBMUS |
| cc: <provision@lists.oasis-open.org> |
| Subject: RE: [provision] The modification problem gets worse... |
| |
>------------------------------------------------------------------------------------------------------------------------------|
Gerry,
In the current specification there are three modification options. There
is add, replace, and delete. In your current proposal there is only one
replace. That is the basic problem. For replace operations the two are
identical. That is why you should not use replace to add a value or to
remove a value.
Instead of showing a case involving replace (which I have said is not
different between the two) please explain how your proposal correctly
handles add and remove. Let me repeat my previous example, setting a
starting condition:
1) RA 1 and RA 2 read the same fiends and family account
2) RA 1 adds contact D using a modify request (add modification)
3) The modify request is finished, the contact list now contains A, B,
C, and D
4) RA 2 removes contact B using a modify request (delete modification)
5) The modify request is finished, the contact list now contains A, C,
and D
Now in your current proposal the events would be:
1) RA 1 and RA 2 read the same fiends and family account
2) RA 1 adds contact D using a modify request that updates the list to
be A, B, C, and D (replace modification)
3) The modify request is finished, the contact list now contains A, B,
C, and D
4) RA 2 removes contact B using a modify request that updates the list
to be A, C (replace modification)
5) The modify request is finished, the contact list now contains A, C
Now before we discuss another example, does this work correctly in your
proposal or not? If so how? I contend that this works correctly in the
current spec. Why do you think it does not?
I am being quite clear about the fact that you would not use a replace
modification. That is the whole point to having different modification
operations.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, March 13, 2003 12:56 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] The modification problem gets worse...
Jeff,
Your argument here and in your previous message is predicated on the
assumption that the RAs in my scenario hold the state of the data while
in
yours they do not. In yours they simply request a modification that is
independent of the current state of the data. You argue that this is
not a
race condition problem and that your scenario will not suffer from it.
Let's go through it again using your implementation:
RA 1 Entry RA2
create
A: 1,2
B: 3,4
read
A:1,2
B:3,4
replace
B: 5,6
A:1,2
B:5,6
replace
B:3,5
A:1,2
B:3,5
This is how the current specification works and according to you this is
fine. I'm not sure that I see much of a difference in the end result.
Please explain.
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/13/2003 05:22 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: provision@lists.oasis-open.org
|
| cc:
|
| Subject: [provision] The modification problem gets worse...
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
In a previous posting I have shown how the current proposal by Gerry
Woods
will cause data corruption when doing modifications. I have shown this
using a very simple case. Gerry has suggested that this could be
overcome
by a modification mechanism that uses XPath in combination with ldap
like
modification semantics. Although this alternative has not been fully
fleshed out, it will not work either. Even theoretically it will fail.
Let
me explain why.
Suppose a record has data that looks like:
<A>
<B>
<C>foo1</C>
<C>foo2</C>
<C>foo3</C>
</B>
<B>
<C>foo4</C>
<C>foo5</C>
<C>foo6</C>
<B>
</A>
No suppose RA1 wants to change the first B component. It would have to
issues a modification request with an XPath that refers to B where B has
foo1, foo2, and foo3. Now suppose the modification changes the record so
that it looks like:
<A>
<B>
<C>foo1</C>
<C>bar8</C>
<C>foo3</C>
</B>
<B>
<C>foo4</C>
<C>foo5</C>
<C>foo6</C>
<B>
</A>
Now suppose at a later time RA2 wants to remove the first B component
from
A. It would have to issues a modification request with an XPath that
refers
to B where B has foo1, foo2, and foo3. This request would now fail.
There
is no automatic way for RA2 to reconcile the differences.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]