OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [provision] Async execution (was "Re: [provision] Asynchronous requests").


I apologize for not commenting on this earlier. I have been extremely
tied up with other things. 

Anyway I agree with most of Gary's suggestions, with the exception of 4.
If a requestor specifies asynchronous, the provider should be allowed to
process the request synchronously and indicate so in the results. Since
the spec can not enforce that a provider actually process anything
asynchronously, there is no reason that this should not be allowed. 

Also I would qualify 1 by stating that status requests and cancel
request can not be asynchronous. That could result in an infinite
recursive loop.



Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 
Try the industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
 
 

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Tuesday, October 19, 2004 11:36 AM
To: PSTC
Subject: [provision] Async execution (was "Re: [provision] Asynchronous
requests").

Having heard no objection, I assume that everyone accepts the following 
positions:
1. ANY operation may be requested as asynchronous.
2. ANY operation may be converted to asynchronous execution at the 
provider's initiative.
3. If a requestor explicitly specifies synchronous execution,
    the provider must execute the operation synchronously (or must fail 
the operation).
4. If a requestor explicitly specifies asynchronous execution,
    the provider must execute the operation asynchronously (or must fail

the operation).
5. If a provider executes an operation asynchronously
    (whether at the requestor's or the provider's initiative),
    - the provider's response must indicate that the operation is 
pending and
    - the provider's response must return a requestID
       that the requestor may use to follow up.
6. Unless a requestor explicitly specifies synchronous execution,
     the requestor must be prepared to accept a response from the
provider
     that indicates the operation was converted to asynchronous
execution.

gpc

Gary P Cole wrote:

> I don't really like a value of "either" value for ExecutionType.  I 
> was trying only to elucidate Doron's point in order to draw out his 
> opinions (and those of others) without putting forth my own.  At least

> not yet. :-)
>
> Having said that, however, my analysis and opinions follow.  I 
> apologize in advance for the length of this note.
>
> 1) The following set illustrates choices (for asynchronous execution 
> at requestor initiative).
> A requestor may request async execution for:
>   A) NONE:  for no operation.
>   B) BATCH:  only for the 'batch' operation.
>   C) BATCHABLE:  for any 'add', 'modify', 'delete' and 'batch'
operation.
>   D) ANY operation at all.
>   E) Any operation EXCEPT 'cancel' or 'status'.
>
> I think (A) is probably unreasonable, since it would be nice to 
> execute 'batch' operations asynchronously.  Of course, this might make

> more sense if 'batch' operations always execute asynchronously or if 
> 'batch' operations can be converted to asynchronous execution at the 
> provider's initiative.  For the purposes of this particular 
> discussion, however, I'd call that (B).
>
> I think (B) is a good choice. The batch operation is the operation for

> which asynchronous execution is most clearly desirable (and perhaps 
> even necessary).
>
> I think (C) is okay, but I would argue that this is easy enough to 
> achieve with (B) since a requestor can put any batchable request into 
> a 'batch' request.
>
> I think (D) is a good choice.  This approach is very general, and we 
> can make it clean and consistent.  If every response is synchronous 
> and if every response indicates whether the operation is pending or 
> succeeded or failed (and, if pending, contains a requestId), then a 
> client simply must be prepared to deal with this.
>
> I think (E) is okay, but I would argue that (D) would be better.  If 
> we cannot enumerate the set of operations for which someone would want

> asynchronous execution, then we should leave it up to the requestor.
>
> If this question were completely independent of the question of 
> asynchronous *conversion* (at the provider's initiative), I would 
> choose either B or D.
>
> Next, let's summarize the options with respect to asynchronous 
> *conversion*.
> 2) A provider may convert to asynchronous execution:
>  A) NONE: no operation at all.
>  B) BATCH: only the 'batch' operation.
>  C) BATCHABLE: the 'batch' operation plus 'add', 'modify' and
'delete'.
>  D) ANY: any operation, regardless of what execution type was
requested
>  E) EXCEPT: any operation that is not explicitly requested as
synchronous
>
> I think (A) is probably unreasonable.  Jeff has explained that 
> workflow can produce arbitrary delays.
>
> I think (B) is nice but may be unrealistic. Since workflow can produce

> arbitrary delays, this could affect any singleton 'add', 'modify' or 
> 'delete'. If the 'batch' operation is the only operation that a 
> provider can convert to asynchronous execution, then this means that 
> (in a workflow scenario) any 'add', 'modify' or 'delete' operation 
> would fail as a singleton but would succeed if it were part of a 
> batch.  This seems unfriendly. Therefore I think (B) pushes toward
(C).
>
> I think (C) is a good choice.  I haven't heard that any other 
> operation (such as 'listTargets', 'lookup', 'cancel', 'status' or 
> 'search') needs to be asynchronous.
> gpc
>
> I think (D) is a good choice.  I don't know why 'listTargets', 
> 'lookup', 'cancel', 'status' or 'search' needs to become asynchronous 
> at provider's initiative, but perhaps I lack imagination.  This has at

> least the advantages of generality and consistency.
>
> I think (E) is a lot like (D).  To me, this simply means that the 
> provider must fail the request if the requestor specifies synchronous 
> execution and the provider cannot execute the operation synchronously.
>
> So, after looking at the interaction between questions (1) and (2), I 
> think only a couple of approaches seem viable:
>
> C) BATCHABLE.  Only specific operations (e.g., 'add', 'modify', 
> 'delete' and 'batch') may be requested as asynchronous and only those 
> same operations may be converted to asynchronous execution at a 
> provider's initiative.  An AsyncableRequestType will be available to 
> custom requests as well.
>
> D) ANY operation may be requested as asynchronous and ANY operation 
> may be converted to asynchronous execution at the provider's
initiative.
> With either approach, if an operation is converted, the provider's 
> response must indicate that the operation is pending and must return a

> requestID that the requestor may use to follow up.
>
> I lean toward (D), since it is the most general and is the easiest to 
> explain.  It does impose on any client the burden of following up on 
> asynchronous operations.  However, a client that cannot follow up on 
> asynchronous operations can explicitly specify synchronous execution. 
> This will force the provider to fail any operation that must convert 
> to asynchronous execution.
>
> Approach (C) could work, but it's harder to explain and doesn't buy us

> much.  A client still must be prepared to follow up on asynchronous 
> operations converted at provider initiative (or must explicitly 
> specify synchronous execution in order prevent conversion to 
> asynchronous execution).  Yes, this applies only to certain 
> operations, but it applies to all the basic operations ('add', 
> 'modify' and 'delete').  That's why I think it doesn't buy us much.
>
> What does everybody else think?
>
> gpc
>
> Jeff Larson wrote:
>
>> As far as the client being prepared to handle an async request, I 
>> think this
>> will always be the case.  The client has to have some awareness of 
>> whether
>> the PSP does workflow or not, otherwise it isn't going to be able to 
>> do anything
>> since the PSP will throw back errors on every sync request.
>>
>> But let me state again that I don't think workflow semantics should 
>> be modeled using
>> ExecutionType.  The spec would be more useful if it formally modeled 
>> at least
>> a few of the basic workflow concepts.  The sync mode then applies 
>> only to the
>> message protocol, not the time at which provisioning eventually
happens.
>>
>> In many cases (ours certainly) the client doesn't really care if the 
>> request
>> is queued pending approval, they just want to make sure the process
>> is successfully started.  In those cases, a synchronous request is 
>> convenient
>> for the client.  If we overload ExecutionType with workflow this 
>> forces the
>> client to adopt  an async-polling style of interface for EVERY
request,
>> even the ones that might be able to run synchronously.    The
"either"
>> type addresses this, but it just feels strange to me.
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
>
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
kgroup.php. 
>
>



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
kgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]