[Standards] Proposed XMPP Extension: IO DATA

Egon Willighagen egon.willighagen at gmail.com
Sun Mar 30 18:38:32 UTC 2008

On Sun, Mar 30, 2008 at 7:09 PM, Fabio Forno <fabio.forno at gmail.com> wrote:
>  While it's true that in SOAP+XMPP specs there is no asynchronous
>  message exchange pattern (and that was a mistake, though I think it's
>  possible to add a new MEP), this is not related to REST. Neither the
>  concept of session id is somewhat related to REST, at the contrary,
>  REST explicitly forbids things like session ids.


thank you for catching this misqualification. We'll fix this shortly.

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.

1. many different data types. This is particularly a problem in
(bio-)chemical sciences, where experimental data is found in many,
many data types, which, moreover, are increasingly semantic.
Currently, SOAP often cannot validate input unless the call has been
made, while this proposal promises to allow to do this at the gate.
Big improvement.

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
intermediate IP packet routers, but the only way to do long running
jobs is to have the client use a second 'service' to poll the primary
service and ask if it is done yet. XMPP is provides a much nicer
protocol for such situations, and this proposal formalizes this.

These two items combined, make this proposal an excellent candidate
for running webservices in sciences like chemistry and biology.

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

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!


Post-doc in Metabolomics
Wageningen Universtity & Research Center, The Netherlands

More information about the Standards mailing list