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] Asynchronou s requests").



That seems like a reasonable solution to me. 

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: Monday, October 25, 2004 2:19 PM
To: Jeff Bohren
Cc: PSTC
Subject: Re: [provision] Async execution (was "Re: [provision]
Asynchronou s requests").

Could we address the interoperability problem by defining an 
AsyncCapability?  A provider that supports only synchronous execution 
would not support the AsyncCapability.  The AsyncCapability could define

the 'cancel' and 'status' operations, since they are useful only when a 
provider supports asynchronous execution.

Jeff Bohren wrote:

>Certainly we can specify that a service that does not support
>asynchronous request MUST fail any asynchronous request. But in my
>opinion that would cause interoperability to suffer. 
>
>To me it seems more logical that if a service can execute a request
>synchronously (or only executes synchronously) that this should not
>cause interoperability problems. 
>
>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: Monday, October 25, 2004 1:28 PM
>To: Jeff Bohren
>Cc: PSTC
>Subject: Re: [provision] Async execution (was "Re: [provision]
>Asynchronou s requests").
>
>Thank you, Jeff.  I agree that the client's effort to check the
response
>
>(and see that it is complete rather than pending) is not very large.  I

>also understand that certain providers will not support asynchronous 
>operations at all.
>
>Since the requestor has a way to specify that either type of execution 
>is okay (that is, by omitting the execution attribute of the request) 
>and since this is implicitly the default, shouldn't a provider that
will
>
>not support asynchronous operations fail any request that specifies 
>execution="asynchronous"? (We can have it return result="failed" and 
>error="unsupportedExecutionType" to make this clear.)
>
>gpc
>
>Jeff Bohren wrote:
>
>  
>
>>Gary,
>>
>>If the provider is not a provisioning system, but rather is a SPML
>>    
>>
>front end to a resource (such and a directory, an RDBMS, etc), then it
>will likely not support asynchronous operations at all. In such a case
>the choice would be to execute everything synchronously or fail every
>asynchronous request. 
>  
>
>>No developer is going to add asynchronous message handling code to a
>>    
>>
>provider for a system to which they can execute all requests
>synchronously. It's not going to be done because it adds no additional
>real functionality.
>  
>
>>It seems to me that to have a client look at the results of the
request
>>    
>>
>and detect that an asynchronous request was performed synchronously is
>not a lot of extra work. After all, the client must look at the
response
>anyway to know that the request was successfully submitted. To have one
>extra bit of logic to see the the request was actually fulfilled seems
>to be worth the benefit.
>  
>
>>Jeff Bohren
>>
>>	-----Original Message----- 
>>	From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>>	Sent: Mon 10/25/2004 12:57 PM 
>>	To: Cohen, Doron; Jeff Bohren; Jeff Larson 
>>	Cc: PSTC 
>>	Subject: Re: [provision] Async execution (was "Re: [provision]
>>    
>>
>Asynchronou s requests").
>  
>
>>	
>>	
>>
>>	Doron,  yes, this does help.  I think we agree, although I must
>>    
>>
>confess
>  
>
>>	that I am still unsatisfied.  I think that I would prefer to say
>>    
>>
>that if
>  
>
>>	a requestor specifies execution="asynchronous" that a provider
>>    
>>
>must
>  
>
>>	either execute the requested operation asynchronously (or must
>>    
>>
>fail the
>  
>
>>	request).
>>	
>>	Jeff Bohren and Jeff Larson,  why it is so important that a
>>    
>>
>provider
>  
>
>>	must be able to execute synchronously an operation that was
>>    
>>
>requested to
>  
>
>>	execute asynchronously?  (I understand that it may be a little
>>    
>>
>bit
>  
>
>>	unnecessarily expensive, but is there a deeper reason?)
>>	
>>	gary
>>	
>>	Cohen, Doron wrote:
>>	
>>	>Gary,
>>	>
>>	>I think we are close and I agree to the way you put it,
>>    
>>
>however, with the
>  
>
>>	>risk I am repeating myself, I would like to stress that I do
>>    
>>
>not really
>  
>
>>	>object to the optimization involved in changing a async request
>>    
>>
>to sync. I
>  
>
>>	>am concerned with the way one would design an RA client app. If
>>    
>>
>I have a
>  
>
>>	>client that issue async operations to PSP and use separate
>>    
>>
>thread to check
>  
>
>>	>for the results, then the fact that the PSP does the
>>    
>>
>optimization and return
>  
>
>>	>the results to the requesting thread is of little help to me.
>>    
>>
>In fact, it
>  
>
>>	>may well introduce to me more burden of enhancing the client
>>    
>>
>code to handle
>  
>
>>	>that situation.
>>	>
>>	>Now, I agree that for the sake of satisfying the optimization
>>    
>>
>requirement,
>  
>
>>	>we would need to enables the RA to specify to the PSP, "handle
>>    
>>
>the request
>  
>
>>	>async, but in case you can do it quickly, do a sync". If we
>>    
>>
>choose to go
>  
>
>>	>this way we need to provide a clear definition on how the
>>    
>>
>implementation is
>  
>
>>	>supposed to achieve this. For me it is sufficient that we state
>>    
>>
>it in a
>  
>
>>	>clear manner either by adding a new mode or by explicit
>>    
>>
>description in the
>  
>
>>	>normative text for the case no mode is specified.
>>	>
>>	>Does this help?
>>	>
>>	>Doron
>>	>
>>	>-----Original Message-----
>>	>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM]
>>	>Sent: Monday, October 25, 2004 6:24 PM
>>	>To: Cohen, Doron
>>	>Cc: PSTC
>>	>Subject: Re: [provision] Async execution (was "Re: [provision]
>>    
>>
>Asynchronou s
>  
>
>>	>requests").
>>	>
>>	>Doron,
>>	>
>>	>I'm not sure that you're in the minority.  I agree with you
>>    
>>
>that
>  
>
>>	>honoring a request for explicit execution mode (or failing the
>>    
>>
>request)
>  
>
>>	>is more straightforward.  The notion that a client can simply
>>    
>>
>omit the
>  
>
>>	>'execution' attribute (in order to indicate that the client
>>    
>>
>will accept
>  
>
>>	>either mode) makes this argument even more compelling.
>>	>
>>	>However, it seems to me that Jeff Bohren's point is also very
>>    
>>
>good:
>  
>
>>	>    If a service processes an asynchronous request
>>    
>>
>synchronously,
>  
>
>>	>    there is no reason to return an asynchronous response.
>>	>    The service knows the request was processed synchronously,
>>	>    and it should be reported as such.
>>	>
>>	>Executing an operation synchronously (whenever a provider knows
>>    
>>
>that it
>  
>
>>	>can do this) seems to be a reasonable optimization.  It does
>>    
>>
>seems a
>  
>
>>	>little silly to make a provider 1) generate and return a
>>    
>>
>requestID and
>  
>
>>	>2) hold onto results waiting to be asked for status.
>>	>
>>	>I suppose that I could live with a little bit of silliness
>>    
>>
>(since the
>  
>
>>	>provider always has the option of failing the request if it is
>>	>absolutely unwilling to execute asynchronously an operation
>>    
>>
>that the
>  
>
>>	>provider could execute synchronously), but it would be nice to
>>    
>>
>have a
>  
>
>>	>better answer to Jeff Bohren's point.
>>	>
>>	>If a request for asynchronous execution will always receive a
>>	>synchronous response
>>	>(that contains the requestID), and
>>	>if a provider can execute the requested operation
>>    
>>
>synchronously, then
>  
>
>>	>why not let the provider return the results of the completed
>>    
>>
>operation
>  
>
>>	>(rather than a requestID)?
>>	>
>>	>gary
>>	>
>>	>Cohen, Doron wrote:
>>	>
>>	> 
>>	>
>>	>>1) I may be in a minority here, but I still feel differently
>>    
>>
>about this
>  
>
>>	>>point. To me ,honoring the client request with regard to the
>>    
>>
>mode of the
>  
>
>>	>>operation is key. Allowing the PSP to behave differently than
>>    
>>
>requested
>  
>
>>	>>means more complexity on the RA side since the RA must be able
>>    
>>
>to handle
>  
>
>>	>>both scenarios instead of maintaining a simplicity of acting
>>    
>>
>in one manner.
>  
>
>>	>>Also, the RA has no way to predict the time that the request
>>    
>>
>would execute
>  
>
>>	>>   
>>	>>
>>	>,
>>	> 
>>	>
>>	>>and I must admit that in most cases, even the PSP would not
>>    
>>
>really know
>  
>
>>	>>that.
>>	>>Overall, I find a design that honors the RA request more
>>    
>>
>straight forward
>  
>
>>	>>and recommend that if we choose to allow the PSP to convert
>>    
>>
>the execution
>  
>
>>	>>mode, let the RA say so by providing an additional indication
>>    
>>
>that he is
>  
>
>>	>>capable of handling PSP change of mode.
>>	>>
>>	>>
>>	>>   
>>	>>
>>	>
>>	>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_wo
r
>kgroup.php.
>  
>
>>	>
>>	> 
>>	>
>>	
>>	
>>	
>>
>> 
>>
>>    
>>
>
>
>  
>




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