OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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