(I crosspost this to the API mailing list, because I think that this
problem is another use case of the more general problem of p2p
communication between applications we are discussing; in the API ml we
can brainstorm better)
On Sun, Mar 30, 2008 at 8:38 PM, Egon Willighagen
<[EMAIL PROTECTED]> wrote:
> BTW, let me say that asynchronous RPC support in XMPP is very
> interesting for scientific workflow environments. This proposal
> addresses two problems which are important limitations of current
> approaches like SOAP over HTTP.
Indeed, it's interesting in general ;)
> 1. many different data types. This is particularly a problem in
[...]
> 2. asynchronise calls. This is also a big limitation of our current
> tools. Call-by-reference does solve the problem of HTTP time outs on
[...]
> These two items combined, make this proposal an excellent candidate
> for running webservices in sciences like chemistry and biology.
I understand the scenario, as I've written it's more general than
scientific or biological computations (e.g send the input events from
a UI widget placed somewhere to a remote service). Basically you'd
like to do something like this:
- retrieve a data scheme from an end point
- send data to that end point
- receive (also asynchronously) data from that end point
Let's try to RESTify it in order to have a more general solution:
- retrieving the data scheme is an operation on a particular node (a
GET), so we don't need a particular action, just get it from the
correct node, e.g. GET /nodename/schemata
<iq from="..." to="..." id="..." type="set">
<rest node="/nodename/schemata" action="get" xmlns="api:rest"/>
</iq>
- sending data is another operation on the node (the semantics of the
operation on the data is given by the combination of the data and the
node): POST /nodename payload
<iq from="..." to="..." id="..." type="set">
<rest node="/nodename" action="post" xmlns="api:rest">
<header><!-- optional --></header>
<body><!-- optional xml payload--></body>
<rest/>
</iq>
- receiving the result depends on whether the operation is synchronous
or not. If synchronous it's just the payload of the answer, and we can
correlate them using the id in the <iq/> stanza. If asynchronous the
service should create a session on the client, by adding the session
id to the headers of the subsequent asynchronous messages (this
mechanism is application defined, other applications may create a
specialized node or use other strategies for handling sessions)
<iq from="..." to="..." id="..." type="result">
<rest xmlns="api:rest">
<header>
<session id="...." xmlns="api:session"><open/></session>
</header>
<rest/>
</iq>
Well, this is just a first attempt to brainstorm... The structure is
much like HTTP, where we have actions, headers (for carrying optional
metadata concerning the document) and the exchanged document, with all
the semantics left to the application. In this way we have the same
expressiveness of HTTP, with the advantage of a bidirectional
asynchronous support as XMPP.
> I am not too much into XMPP myself, but hope the discussions on this
> mailing list will help us get the proposal in shape, because we really
> like to see this functionality. The example code from Johannes looks
> great, and eager to start using it. We are setting up webservices for
> metabolomics, where the data that needs to be passed around goes in
> the gigabytes, and where processing easily goes into the tens of
> minutes.
Do you send it all through XMPP? Is it all in small chunks as in the
examples you wrote, ore there may be also bigger chunks of data? I'm
asking because I think that everybody here would like to know more
about real life examples of binary data transfer through XMPP. Keep us
informed about the performance and the setup you use.
> I am aware that we continue the unofficial extension of Edrin, but
> having this as an official XEP will make it much easier to roll out
> XMPP-based webservices on a larger scale.
>
> Looking forward to hearing further comments!
sure
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
