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