[Standards] Proposed XMPP Extension: IO DATA

Johannes Wagener johannes.wagener at med.uni-muenchen.de
Sun Mar 30 20:59:27 UTC 2008


Fabio Forno schrieb:
>>  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 ;)
>   
I think so, too. Therefore as our protocol is a very general approach we 
sent the specs to the standards mailing list. It's worth to note that we 
already wrote an opensource client and component side library for this 
protocol to be used from java or scripting languages to 
discover/invoke/manage (start/cancel/continue/complete) remote 
processes. The sample code in the section 1.3 of the XEP proposal is 
very similar to how it is actually implemented. We hope that other 
libraries will have interest in the protocol in future, too.
>>  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>
>   
Indeed. If you read the xep you might see that the XEP is very much the 
same as you suggest here. Ad-Hoc Commands do also support several 
actions: For example execute/next/prev/cancel/complete are actions 
supported by Ad-Hoc Commands. We think that this facilitates everything 
that is required to completely manage/control a remote process. As I 
already mentioned our approach is a very general one. The specs in the 
XEP is that open that it is of course possible to do what you suggest, 
for example see section 4.2 for getting the schemata. See 4.3 for 
sending data.
> - 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.  
Exactly. That's how we do it.
> 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)
>   
Yes, that's why the XEP uses Ad-Hoc Commands. Because it has already a 
session concept as you suggest here. In addition to this it is a widely 
supported XEP, we think that - with the very generic io data container 
in our specs - it is a friendly way to also support machine2machine 
parseable/readable and especially marshal-able services with it. As I 
already mentioned our approach is a very general one. The specs in the 
XEP is that open that it is of course possible to do what you suggest 
here: for example doing it in an asynchronous way there is the sessionid 
of Ad-Hoc Commands - especially Examples in section 4.4 and 4.2.

>>  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
>
>   
Thank you for your comments





More information about the Standards mailing list