Email lists > XMPP Extension Discussion List > Re: [Standards] Proposed XMPP Extension: IO DATA > Re: [Standards] Proposed XMPP Extension: IO DATA

Re: [Standards] Proposed XMPP Extension: IO DATA




This post if a part of  this thread

2008-03-30 15:59:27
Re: Proposed XMPP Extension: IO DATA 
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

about | contact  Other archives ( Real Estate discussion Medical topics )