[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").
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_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]