Re: [provision] Async Proposal...

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Jeff,

I *do* like the simplification of your approach.  (You may recall that I 
proposed something similar--an AsyncRequestType that wrapped an instance 
of SpmlRequestType--when the topic of an Async Capability first came 
up.)  This isolates the complication of asynchronous execution to a 
specific operation that must be requested explicitly.

One of the arguments against that idea--the one that took me by 
surprise--was that almost any of the core operations could be converted 
to asynchronous execution at the provider's initiative. (For example, an 
add or a modify could require workflow, which would slow it down.  Worse 
yet, the workflow could require approvals, which means that the add 
operation could take days to succeed or fail.)  Jeff Larson said that 
this was agreed at the last Face-to-Face that Mr. Larson attended.

At present, nothing indicates to a requestor that an operation may 
require asynchronous execution.  This means that nothing tells a 
requestor ahead of time to use the AsyncRequestType.  This leaves the 
requestor to rely on using trial-and-error.  I think you called this 
"programming by exception".

If a requested operation fails because the operation requires 
asynchronous execution, we *could* simply return a specific value of of 
ErrorCode (e.g., "error='mustBeAsync'") that tells the requestor that 
the operation requires asynchronous execution. However, this train of 
thought previously led to the conclusion that we should *automatically 
convert* the requested operation to asynchronous execution (rather than 
failing the operation).  If it was indeed generally the case that an 
operation could require asynchronous execution (and that only the 
provider would know for sure), then we should specify the core 
operations accordingly.  That's how we got where we are today, with the 
standard ResponseType possibly returning "status='pending'" and a token 
("requestId" or "asyncOperationId") that the requestor can use to cancel 
or obtain the status of the async operation.

I'm open to the idea of an 'async' operation if everyone's okay with the 
requestor having to "program by exception"--i.e., trap a specific error 
code and re-request asynchronously.  I would prefer that the 'async' 
operation *always* executed the operation in the nested request 
asynchronously rather than *possibly* doing so. (After all, if you're 
using the asyncRequest because a sync request previously failed with 
"error='mustBeAsync'", you pretty much know that it's going to be 
async.  Beyond that, you'd *rather* just know that it's going to be 
async since it's one less thing to guess at.)

What do you think?  Can you live with the requestor "programming by 
exception"?  Is a sentinel value of ErrorCode acceptable? Is it okay for 
the 'async' operation always to execute the nested operation asynchronously?

gpc

Jeff Bohren wrote:

>Yes, that is essentially my proposal. I see the async capability being
>used when the request is know to be asynchronous, or if it may be
>asynchronous. If the core requests are used, it is assumed to be
>synchronous or fail. 
>
>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: Friday, December 03, 2004 1:02 PM
>To: provision@lists.oasis-open.org
>Subject: Re: [provision] Async Proposal...
>
>Jeff,
>
>I don't understand. Do you intend that a requestor must use the 
>AsyncRequestType to request asynchonous execution (and that core 
>operations would otherwise be synchronous)?
>
>I like the basic idea (if that's what you're getting at), but what about
>
>the fact that a core operation might be converted to asynchronous 
>execution at the provider's initiative (e.g., because workflow requires 
>approvals)?
>
>Jeff Bohren wrote:
>
>  
>
>>I would like to propose a way to make the core and async capability 
>>more independent. First I would remove pending from the ResultCode in 
>>core and make a StatusCodeType in async.
>>
>>I would like to propose that all the sync/async semantics should be 
>>removed from spml:RequestType and an spmlasync: AsyncRequestType 
>>should be created. The spmlasync:AsyncRequestType would be a wrapper 
>>that would hold one an spml request. It would be defined as:
>>
>><complexType name="AsyncRequestType">
>>
>><complexContent>
>>
>><extension base="spmlasync:StatusRequestType">
>>
>><sequence>
>>
>></sequence>
>>
>><attribute name="execution" type="spmlasync:ExecutionType" 
>>use="optional"/>
>>
>></extension>
>>
>></complexContent>
>>
>></complexType>
>>
>><complexType name="AsyncResponseType">
>>
>><complexContent>
>>
>><extension base="spmlasync:StatusResponseType">
>>
>><sequence>
>>
>></sequence>
>>
>></extension>
>>
>></complexContent>
>>
>></complexType>
>>
>>An example would be:
>>
>><asyncRequest statusReturns="results">
>>
>><addRequest>...</addRequest>
>>
>></asyncRequest>
>>
>>If the response would equivalent to a StatusResponseType and would 
>>indicate if the submitted request was still pending or completed (i.e.
>>    
>>
>
>  
>
>>it was executed synchronously).
>>
>>For requests that worked asynchronously, the response would be:
>>
>><asyncResponse status="pending">
>>
>></asyncResponse >
>>
>>For requests that worked synchronously, the response would be:
>>
>><asyncResponse status="complete">
>>
>><addResponse>...</addResponse>
>>
>></asyncResponse >
>>
>>By making these changes there would be no async/sync semantics left in
>>    
>>
>
>  
>
>>the core, and the async capability would be improved (in my opinion).
>>
>>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** 
>><http://www.opennetwork.com/eval>**.**
>>
>>    
>>
>
>
>
>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_workgroup.php.
>
>  
>