Re: some comments on an SCXML draft

Al Gilman wrote:

>
> [These are some old-ish notes from the Plenary week.  Sorry if these
> are things you have dealt with already.  - Al]
>
> Reference: http://www.w3.org/TR/2006/WD-scxml-20060124/
>
> ** event identification [this idea was discussed/accepted at the MMI
> meeting on Tuesday IIRC]
>
> ref: section 4.4 <invoke> second paragraph
>
> In the current draft it is stated that detached-process response
> events can be identified by the ID of the state that spawned the
> event being responded to.
>
> I don't believe that this is true, and that the computational model 
> needs to be
> shifted from an event identification based on the XML ID of the note
> that spanwned the event to the idea that there is a unique ID per
> event message, and that response messages have an "in reply to"
> attribute which bears the ID of *the event* being responded to, not
> just the locus in XML of the activity template that was being
> executed by the process that threw the event.  Compare with Message-ID
> in RFC 821/822.
>
> A counter-example can be constructed as follows.
>
> A remote detached process is spawned by one thread forked by a 
> <parallel>.
>
> The <parallel> is aborted by one of the other threads executing a
> transition out of the <parallel>. This causes some cleanup activity
> including the sending of a cancel-message to the spawned process.
>
> But the thread the went off outside the <parallel> returns and
> re-enters the same <parallel>.
>
> So the first branch once again spawns a "distinct logical instance"
> of the same activity template. If we only know the ID of the
> requesting state, we don't know the response to the first request
> from the response to the second. But we need to know. There is no
> guarantee that the cancel message will be handled before the first
> execution of the detached process has dispatched a response event.
> The second instance of the detached process can return a response
> event before you get the response to the first request or the
> response to the cancel message. So the events need their own IDs.
>
>
> ** can't mix 'incompatible' statments
>
> Ref: 3.2.2 children (of 3.2 <state>)
>
> last bullet, it says <invoke> is incompatible [sic] with the <state> and
> <parallel> elements.
>
> First, I don't understand what is being said by the term 'incompatible.'
> What is the content model?
>
> Second, I don't know why this is thought to be true.  If you can put
> an <invoke> inside a <state> but you can't put it after another
> child <state> then you can simply follow the first sub <state>
> with a second sub <state> which is a wrapper for the <invoke>
> that is a content-free workaround for the immiscibility condition.
>
> HTH
>
> Al
>
>

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 Monday, 27 March 2006 07:40:32 UTC