W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2006

Re: some comments on an SCXML draft

From: Sheth Raxit <raxit@phonologies.com>
Date: Thu, 06 Apr 2006 13:11:09 +0530
Message-ID: <4434C615.8050509@phonologies.com>
To: James.Barnett@Aspect.com, www-voice@w3.org

James Barnett and Other VBVG members,

Barnett, James wrote:

> Raxit,
>  We think it would be a bad idea for the state machine to wait
> automatically for the CancelResponse event.


I agree with this, as i mentioned in  my previous reply,(just copied 
below,partially)

"One solution (but may not be good)  to make 'FULL Synchronization' (But 
Work only for Synchronized Web-Services,)"


> While it is true that
> waiting for the event would solve the problem Al Gilman poses, it would
> cause the state machine to block forever in the case where the other
> entity did not send the CancelResponse event (e.g., because it had
> crashed.) 
>  
>

I completely agree with Your points as I mentioned in my previous reply,

What i think  is that two issues/solutions raised by Al Gilman, is 
complmentry,
and providing EVENT_ID would make possible [<invoke> and <state>] pair 
and [<invoke> and <parallel> ]
and [Multiple Invoke within One State] will be compatible. (which are 
not possible as per current SCXML Draft)


Please refer the previous post
http://lists.w3.org/Archives/Public/www-voice/2006JanMar/0099.html



any known issue ? (at the implementation level, I think one need to 
implement Publish-Subscribe with composite state or simillar)


> - Jim
>  
>
Many Thanks,
Raxit Sheth


>>   
>
>
> I think the issue 1  is due to "PARTIAL SYNCH",While Cancelling the call
>
> to web service.
>
>
> 4.4 <invoke> Para 3,
>
> The 'Cancel' event will be sent as if it were the final <onexit> handler
>
> in the invoking state. The invoked component must respond to the 
> 'Cancel' event with a 'CancelResponse' event (syntax of both events
> TBD).
>
> ---->The invoking state machine will take its transition without waiting
>
> for the CancelResponse event, which will be processed like any other 
> external event.<----- Synchronization Breaks Here...
>
>
> As per current SCXML draft Only One Call of Web-Service per State is 
> possible  at any given time(except this case, due to PARTIAL SYNCH) 
> and as per current SCXML draft call to  Asynchronous Web-Services may 
> not handled easily.
>
>
> One solution (but may not be good)  to make 'FULL Synchronization' 
> (But Work only for Synchronized Web-Services,)
>
> as per this, Invoking State Machine will take its transition ONLY 
> AFTER It recieves CANCELRESPONSE Event.
> (here the case of NO Response or TIMEOUT would need to handle)
>
>
>
> While if implementation is done using EVENT_ID as suugested by Gilman, 
> One can make multiple web-services call also, because solution itself 
> say that call would not 'bind' to SCXML State id, but would 'bind' 
> with Event_ID.( And in current SCXML draft only one <invoke> in the 
> state is because of synchronization done using state id, or it may be 
> one reason
> )
>
> it may possible that one thread would invoke the web-service, without 
> blocking activity of whole state, state can continue to do other 
> stuff.(may be call to next <invoke>, as per current draft only one  
> <invoke> in state possible.)
>
>
>
> and in that context ( i am not sure here...) [<invoke> and <state>] pair
>
> and [<invoke> and <parallel> ] will be compatible,But NOT  [<state> 
> and <parallel> ]
>
>
>
> any known issue ?
>
>
>
>
> Waiting for response,
>
> Thanks & Regards
> Raxit Sheth
>
>
>  
>


-- 

Raxit Sheth
Systems Software Engineer
Raxit@Phonologies.com

***********************
Please note our new Address.
***********************
Phonologies (India) Private Limited
17/18 Metro House, Colaba Causeway,
Mumbai 400001. INDIA.
Ph:+91-22-22029732 / 36   Fax:+91-22-22029728

Info@Phonologies.COM
http://www.phonologies.com

****The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this email by
anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it, is prohibited and may be unlawful****
Received on Thursday, 6 April 2006 07:31:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:02 GMT