RE: [provision] Async execution (was "Re: [provision] Asynchronou s requests").

["Jeff Bohren" <jbohren@opennetwork.com>]

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_wor
kgroup.php.
>	>
>	> 
>	>
>	
>	
>	
>
>  
>