[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Async Proposal...
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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]