[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]