Subject: [scim] Bulk request has a non-deterministic condition

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Jul 2014 08:46:20 -0400

The following paragraph in Bulk was brought to my attention as problematic:
   There can be more then one operation per resource in each bulk job.
   The Service client MUST take notice of the unordered structure of
   JSON and the service provider can process operations in any order.
   For example, if the Service client sends two PUT operations in one
   request, the outcome is non-deterministic.

From our perspective this makes Bulk un-implementable, since other paragraphs seem to depend on serial processing (eg bulkId). Anybody have any background for this? It seems to come from SCIM 1.

If we were to proceed with bulk, I would recommend striking this paragraph.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Bill Mills <[email-masked]>
Date: Mon, 21 Jul 2014 07:56:45 -0700

I think Bulk should be dropped in favor of something like supporting SPDY for high volume.

On Monday, July 21, 2014 7:41 AM, Phil Hunt <[email-masked]> wrote:

The following paragraph in Bulk was brought to my attention as problematic:
There can be more then one operation per resource in each bulk job. The Service client MUST take notice of the unordered structure of JSON and the service provider can process operations in any order. For example, if the Service client sends two PUT operations in one request, the outcome is non-deterministic. 

Phil

@independentid
[email-masked]

_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Erik Wahlström <[email-masked]>
Date: Mon, 21 Jul 2014 15:23:26 +0000

I would like to keep bulk in the core spec. It’s been implemented by some vendors and it does the job. It’s also an important part of a provisioning protocol that does a huge on boarding or migration between different systems.

SPDY is not standardised and adopted everywhere yet and non of the existing provisioning (standard and non standard) implementations that I know of uses it. Lets stick with what we know works.

A agree of removing the paragraph. I think it’s based on a misunderstanding from when writing it. It’s JSON objects that’s unordered, JSON arrays is ordered, so it will not be an issue.

/ Erik

On 21 Jul 2014, at 16:56, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Monday, July 21, 2014 7:41 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Jul 2014 11:32:30 -0400

Not sure I understand the use of spdy. 

Seems useful if you want to maintain a high rate update stream.  But in this case Bulk would simply be passing 1000s of changes at once which may be better than 1000s of separate req/responses which may get out of sequence if you aren't careful to account for connection pooling. 

Phil

> On Jul 21, 2014, at 10:56, Bill Mills <[email-masked]> wrote:
>

---

From: Bill Mills <[email-masked]>
Date: Mon, 21 Jul 2014 10:00:23 -0700

Implying that there is an ordering in bulk transactions is interesting, and I think not supported by the draft text.  I also doubt there is any great efficiency to be gained by having 1k transactions in a single bulk operation in the end, other than a single authn check instead of 1k.

SPDY would get you equivalent throughput and you lose the complexity of the bulk error message handling.

On Monday, July 21, 2014 8:33 AM, Phil Hunt <[email-masked]> wrote:

Phil

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Jul 2014 13:07:19 -0400

Bill,

Erik clarified that he believed the lack of ordering is a mistake.  Ordering is critical if you are using bulkIds (e.g. add a user then add that user to a series of groups).

One of our developers commented that Bulk is also potentially useful if you want to take a series of operations like add a user and place them all into a group and treat the whole thing as pass/fail.

I’ll do some more reading on SPDY. Curious to understand how that would fit.

It’s seeming like there are a lot who still want it.  Maybe splitting it off so we can explore things like SPDY is something to consider?  It also gives a chance for implementations to catch up on it.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Erik Wahlström <[email-masked]>
Date: Mon, 21 Jul 2014 21:56:35 +0000

Ordering is not critical, but more way more efficient. The following example bulk implementation iterates through the document 3 times, then cancels. That means that, using your example below, it first tries to resolve any bulkIds in a PATCH request on a Group, if the bulkId not yet resolved (user is not created yet), it just continues to go through the bulk job and then adding the new user. In a second iteration the bulkId can be resolved and the user is added to the group. It’s possible for the service provider to specify a limitation of the numbers of jobs in a request if it does not want to iterate to big requests to many times. It’s also possible for the client to add them in the correct order in the array, it’s maintains it’s order in the JSON document according to RFC4627 ("An array is an ordered sequence of zero or more values.”).

https://code.google.com/p/scimproxy/source/browse/trunk/scimproxy/src/main/java/info/simplecloud/scimproxy/ScimBulkServlet.java

I don’t really see any reason why we should split if off?

/ Erik

On 21 Jul 2014, at 19:07, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Bill,

Phil

@independentid

On Jul 21, 2014, at 1:00 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Monday, July 21, 2014 8:33 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Jul 21, 2014, at 10:56, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid

---

From: Bill Mills <[email-masked]>
Date: Mon, 21 Jul 2014 16:14:03 -0700

We're going down a very complicated path here.  If you have a sequence of operations that need to happen, do they need to be atomic?  Should you roll back the user add if the user can't be added to the right groups?  The error handling/recovery from "some stuff failed" gets pretty hairy.  It's SQL transactions with implicit commit and no rollback or transaction grouping.  If we need this kind of thing we should re-use an existing model.

Phil

@independentid

---

From: Erik Wahlström <[email-masked]>
Date: Mon, 21 Jul 2014 23:39:01 +0000

The solution for it is to keep the error handling very stupid/efficient. First of it’s not an atomic operation by the service provider. Secondly the client can decide if the service provider should go on and keep on trying to add resources or not using the failOnErrors attribute.

   The service provider MUST continue performing as many changes as
   possible and disregard partial failures.  The client MAY override
   this behavior by specifying a value for failOnErrors attribute

The important part of it all is the error codes returned for each job. It’s up to the client to see if all went well. If it did, the client can call it an “atomic” operation, if it’s not the client can rollback. It’s the exact same thing as the client has to do if bulk is not supported and it had to do a bunch of request right?

By the way, thanks for kicking the tires on it Bill. The more eyes, the better.

Cheers
Erik

On 22 Jul 2014, at 01:14, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Phil Hunt <[email-masked]>
Date: Tue, 22 Jul 2014 00:19:28 -0400

Except for the erroneous point that JSON order can’t be guaranteed (which it can), I think the signalling and sequencing is very well thought out.

Phil

@independentid
www.independentid.com
[email-masked]

On Jul 21, 2014, at 7:39 PM, Erik Wahlström <[email-masked]> wrote:

> On 22 Jul 2014, at 01:14, Bill Mills <[email-masked]> wrote:
>