Re: External communication with SCXML

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

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 ;)

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.


> Could you elaborate as to which parts are "actually covered by the spec"? There is certainly the possibility that I missed them.

I mentionned two of them (maybe the only two, I'm afraid): one just above about 'origin';

and, as you noticed yourself, <invoke> is well-suited to abstracting a persistent connection with events going back and forth, you can use the default 'SCXML' type even if the remote system isn't an SCXML interpreter (it just needs to understand SCXML events), though the SCXML specification does not define how SCXML events shoud be serialized for transport (except when using the basichttp I/O Processor, and as I said, I won't get into that) nor how authors may tell the interpreter which protocol to use.
Of course, I would push for the EventSource protocol as the default, because it's now part of HTML, and because it's very simple, generic and effective.


> Having a <fetch> element such as yours definitely seems suited to invoke external services and process its results. It is in essence the solution I proposed above, but with a dedicated element for executable content, rather than a special type with <send>. I would support such a thing in our interpreter, though I am indifferent as to whether it ought to be <fetch> or a special ioprocessor. The key point, I guess, is to represent replies as events again.

It has to be a different element because <send> is defined as fire-and-forget, where the receiving party is supposed to send an event itself rather than reply to the request, as I said before.

Also, using a custom element allows me to define XHR-specific attributes, behavior, and the <header> children to define HTTP headers.

			David

Received on Monday, 11 February 2013 22:02:03 UTC