Re: External communication with SCXML

Hey David,

On Feb 11, 2013, at 11:01 PM, David Junger <tffy@free.fr> wrote:

> Le 11 feb 2013 à 21:35, Stefan Radomski a écrit :
> 
>>> The spec says the URL you should reply to, when receiving a remote http event, must be included in the _event.origin property.
>> 
>> Yes, but in my case I just have a pending http request from a client. There is no remote URL to reply to. If there were, we could go for <send> again.
> 
> You don't need to make up the remote URL. It's easy to miss since it is not mentionned at all in the chapter about <send>, but the remote system should, when sending an event to you, "set [the 'origin'] field to a value which, when used as the value of 'target',  will allow [you] to <send> a response back to the originating entity via the Event I/O Processor specified in 'origintype'."
> http://www.w3.org/TR/scxml/#InternalStructureofEvents
> 

This would require every entity which posts requests to have an http server itself. This will work with other SCXML implementations as _ioprocessors['basichttp'].location is supposed to be just this URL. But I want to just e.g. "wget" a JSON/XML snippet from a running SCXML session.

> Note that I/O Processors are not designed for implementing an HTTP server, and when you receive a remote event you are not supposed to think of it as a request, it's just an event to which you reply by sending other events. In a way, it's an abuse of the underlying HTTP, but then, HTTP is abused a lot these days ;)
> 

It is clear that <send> was not specified with request/reply in mind.

> If you do want to implement an HTTP server in SCXML (and why not? event-based servers are great), you would need some way to keep track of the requests (<invoke> a session for each request maybe?) and some kind of custom <respond> element.
> 

Yes, these are the kind of language features I was thinking about. The way I see it, pragmatically, is a http request arriving, being "eventified" and passed into the SCXML interpreter via its external queue. Now I do have an event that represents a http request and would need to construct a reply. You argue for a new element <respond> for executable content that, when executed, would get passed the requestId and send the reply. My approach was to abuse <send> with a special #_http.requestId target.

The benefit with dedicated invokers could be that you have a way to "register" URLs dynamically, that is, you invoke one such "servlet" per path where you want to serve data. This approach would hint at using <send> again though, as you can use its invokeId as a target for send (http://www.w3.org/TR/scxml/#DataSharing) and sending a reply would be to send a special event to the invoker via its #_invokeId. Then again, you could just enter a new state where your transitions dispatch the path via their conds.

I guess the best approach is to go for:
  "http request" -> 
  event -> 
  external SCXML queue -> 
  processing -> 
  [<respond requestexpr="_event.requestId"> | <send targetexpr="'#_http.' + _event.requestId">]

Having a dedicated respond element in executable content offers more flexibility and fits nicely with the fetch element, I think I'll go for this and see where it takes me.

Thank you.
  Stefan

Received on Tuesday, 12 February 2013 11:53:25 UTC