Re: External communication with SCXML

On Feb 15, 2013, at 10:13 AM, David Junger <tffy@free.fr> wrote:

> <respond> does not use I/O Processors, therefore it does not need an access URI (not in the same sense, though of course it needs to listen somewhere like any other Web server) and does not need (shouldn't, maybe) to share its domain / port with the basichttp access URI. You should view it as a saparate communication channel rather than a different method used over the same channel.

The draft requires the basichttp ioprocessor to listen at "access URI" and deliver incoming requests as events, using either a _scxmlEventName header or the request method as the event's name. Therefore, every request that arrives at the "access URI" will be delivered as an event in the basichttp sense with an immediate reply. The question was, how we could distinguish basichttp requests from respondable requests. You propose to move it to another domain / port (something I'd like to avoid as I would need to run yet another HTTP server per SCXML instance) - the key point is that I am afraid that it would be hard to grasp for an application developer that there are two different http servers, both feeding into the same SCXML session. The way I solved it was to do the following:

<host> := gethostname
<port> := first free port above 8080 or specified at command line
<basePath> := name of SCXML interpreter with increasing digits appended for uniqueness or a UUID

The "access URI" for basichttp is now "http://host:port/basePath/basichttp" and everything else beneath "http://host:port/basePath" will be feed as respondable events into the interpreter. Do you think this is insufficient / confusing? We do feature the possibility to run many concurrent SCXML interpreters on our platform, that's why the first element of the path has to select the running instance.

Best regards
Stefan

Received on Friday, 15 February 2013 12:54:37 UTC