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
