[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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>**.** >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]