Re: [Standards] Proposed XMPP Extension: IO DATA
Alexander Gnauck wrote: > Artur Hefczyc schrieb: >> >> On 4 Apr 2008, at 12:05, Richard Smith wrote: >> Johannes Wagener wrote: >>> Proposed XMPP Extension: IO DATA >> >> >> I second this proposal. > > I also second this proposal. > > I have done lots of Jabber RPC stuff in the past. RPC is poorly > documented and supports only basic data types. > > Using this XEP its very easy to integrate XMPP in existing business > applications without converting or mapping existing (xml)data to RPC or > xdata. Well, we seem to have a lot of interest in this proposal. :) Johannes, could you send me updated XML sometime in the next week so that I can put this on the agenda for the next Council meeting? Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
Artur Hefczyc schrieb: On 4 Apr 2008, at 12:05, Richard Smith wrote: Johannes Wagener wrote: Proposed XMPP Extension: IO DATA I second this proposal. I also second this proposal. I have done lots of Jabber RPC stuff in the past. RPC is poorly documented and supports only basic data types. Using this XEP its very easy to integrate XMPP in existing business applications without converting or mapping existing (xml)data to RPC or xdata. Alex
Re: [Standards] Proposed XMPP Extension: IO DATA
On Sat, Apr 5, 2008 at 6:05 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > Maybe we should change the title to "Web Services over XMPP"? :) definetely > However, I suppose that when most people think of web services they > think of SOAP and the whole WS-* stack... So let's teach them how to apply the real definition ;) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: IO DATA
Richard Smith wrote: > Johannes Wagener wrote: >> Proposed XMPP Extension: IO DATA > > > +1 > > I'd like to endorse this proposal. > > While AD-Hoc commands and Data Forms does offer a lot of flexibility, XMPP > could benefit from extended capability in terms of representation of in > terms of machine-to-machine communications that are outside of XMPP which is > operating as a transport layer. > > I would like to make a suggestion though. > > I can see this proposal being used in my application framework where I have > to ship lots of user interface specifications, SNMP information, accounting > information and other stuff around the XMPP network. My current > implementation is a hack on top of data-forms and various other namespace > hacks. My only reservation is with the error conditions. > > The proposal currently states that error conditions are handled according to > the AD-Hoc commands which IMO is not sufficient. > > Sure, sending a element in response to a submission is > possible, but it doesn't give the machine receiving this error any specific > detail as to the nature of the problem, other than a string. > > Would be nice if there was an element that would specify a schema > for errors possibly? I don't know... > > Apologies if this doesn't make much sense, but it was written on the move... Yes I think that makes a lot of sense. Given the limits on the number of child elements allowed in by the core XMPP spec, I think we'd need to include the IO-specific conditions as children of the ad-hoc commands errors. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
Johannes Wagener wrote: > Peter Saint-Andre schrieb: > >> Yes, ad-hoc commands can include payloads other than XEP-0004 data >> forms. It's good to see someone using that extensibility. >> >> Just curious: did you look at XForms? >> > I looked at XForms. XForms is primarily used for a form based data > transmission while describing certain layers of abstraction. We thought > that these abstractions are already too restrictive and are not required > for a general usage. Though it is still possible to pass XForms in the > data container of our XEP proposal without changing anything. all that > would be advised is to publish a schema with the linking to the XForm > Schema. Heh, good point. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
Ola Spjuth wrote: > Hi, > > I'd like to add our strong support to the "IO DATA" XEP proposal. I > represent the Bioclipse project (www.bioclipse.net) providing a > workbench for life science that currently relies heavily on SOAP Web > services for remote execution of jobs. The biggest problem for us is > long lasting calls, as many of the calculations in life science are > computationally expensive and we have had big problems with asynchronous > calls over SOAP. This XEP looks very promising, and I think it could > bring several long-desired features that have been requested by our > users, such as stable long-running jobs and service-discovery. Thanks for weighing in. > In my opinion, Bioclipse will be an excellent showcase for XMPP-based > Web services, and we will continue to support this technology in the > future. Maybe we should change the title to "Web Services over XMPP"? :) However, I suppose that when most people think of web services they think of SOAP and the whole WS-* stack... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
Luis Peralta wrote: >Overall I like this XEP. What I missed are more possible status > values for the commands. Being in execution and completed is way too > simple for some applications. The initial state after submitting a > command would be 'accepted' and letting the client know that it is in > fact sending commands to a batch service. IMO, the state diagram > should something like: accepted -> executing -> completed, even if in > the current spec 'executing' means both things. Is this at the XEP-50 level or the IO-Data level? >I would also explicitly refer the possibility of canceling a > running command by using xep-50 'cancel' action. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
On Fri, Apr 4, 2008 at 5:35 PM, Luis Peralta <[EMAIL PROTECTED]> wrote: > >Overall I like this XEP. What I missed are more possible status > values for the commands. Being in execution and completed is way too > simple for some applications. The initial state after submitting a > command would be 'accepted' and letting the client know that it is in > fact sending commands to a batch service. IMO, the state diagram > should something like: accepted -> executing -> completed, even if in > the current spec 'executing' means both things. > >I would also explicitly refer the possibility of canceling a > running command by using xep-50 'cancel' action. > > +1 for this XEP. I think that we can reach what you say by allowing any value in the type attribute of the x child -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: IO DATA
On Sun, Mar 30, 2008 at 10:59 PM, Johannes Wagener <[EMAIL PROTECTED]> wrote: > 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. Indeed for M2M I'm concerned about the lack of extensibility of the actions of ad hoc commands, since they their only purpose is describing the which is the next step required for performing an operation, while they don't say anything about which kind of operation we are doing on a node. The type of the the http://xmpp.org/protocol/io-data child tries to fix this limitation with some possible meanings of the command: input/output/get-schemata, but it still uses a fixed vocabulary. Perhaps if you just allow any value for type attribute we reach full flexibility and equivalence with REST. > > > 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'd let the application decide which is the best way to handle the session. For example there are session associated with a previous authentication process and applied to different nodes, or sessions lasting for ever, even after the restart of the service. The session-id of ad hoc commands is limited from this point of view. However it's not written anywhere that that's the only session-id we can use, and this - I think - keeps the necessary extensibility for session handling. For example the app could get an auth token logging to a given node, and then add the token to the payload of different commands to different nodes. I'd add an example about this to the XEP, just for showing the the concept of session is not limited to the ad-hoc commands scope. Finally I think that the and children are unnecessary in commands of type input and output, but that's just a minor adjustment. If you agree with these two observations, I'm absolutely fine with the XEP (I even think that it could be a better way for transporting SOAP itself) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: IO DATA
On 4 Apr 2008, at 12:05, Richard Smith wrote: Johannes Wagener wrote: Proposed XMPP Extension: IO DATA I second this proposal. I've read this XEP and I love it. This is exactly what I needed when I was working on the server configuration via XMPP. I decided to use ad-hoc commands because that was the best available way to do it. But I really struggled with conversion data between string and other types. Using this XEP would be much, much more efficient and easier to implement as I could just skip all types conversion stuff and detecting/ remembering what type apply to which configuration parameter. I second this XEP as an official XMPP XEP :-) Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Proposed XMPP Extension: IO DATA
On Sun, 2008-03-30 at 01:16 +0100, Johannes Wagener wrote: > Further explanation comes here: > We want to do dynamic Web Services over XMPP. For certain reasons we > explain in the XEP we think neither SOAP over XMPP nor Jabber-RPC is > the way to go. We think future asynchronous Web Services can be best > implemented with the session based Ad-Hoc Commands XEP-0050. I can easily see the need for such a protocol. Looking at Data Forms in there is no real way of transporting XML data. There are quite a few applications that can make better use of transporting XML with Ad-Hoc commands instead of resorting to complex things like SOAP and the rest. In general, lot of the things that hover around xmpp are more geared towards the IM side of xmpp, while there are kinds of needs too. Addressing the need to do Ad-Hoc command with program data is a good thing. Regards, Sami
Re: [Standards] Proposed XMPP Extension: IO DATA
2008/3/30, Johannes Wagener <[EMAIL PROTECTED]>: > Proposed XMPP Extension: IO DATA > > Hello, > here I submit a proposal for a new XEP called "IO DATA". > Hi, Overall I like this XEP. What I missed are more possible status values for the commands. Being in execution and completed is way too simple for some applications. The initial state after submitting a command would be 'accepted' and letting the client know that it is in fact sending commands to a batch service. IMO, the state diagram should something like: accepted -> executing -> completed, even if in the current spec 'executing' means both things. I would also explicitly refer the possibility of canceling a running command by using xep-50 'cancel' action. +1 for this XEP. Regards, -- http://www.ziritione.org
Re: [Standards] Proposed XMPP Extension: IO DATA
Johannes Wagener wrote: > Proposed XMPP Extension: IO DATA +1 I'd like to endorse this proposal. While AD-Hoc commands and Data Forms does offer a lot of flexibility, XMPP could benefit from extended capability in terms of representation of in terms of machine-to-machine communications that are outside of XMPP which is operating as a transport layer. I would like to make a suggestion though. I can see this proposal being used in my application framework where I have to ship lots of user interface specifications, SNMP information, accounting information and other stuff around the XMPP network. My current implementation is a hack on top of data-forms and various other namespace hacks. My only reservation is with the error conditions. The proposal currently states that error conditions are handled according to the AD-Hoc commands which IMO is not sufficient. Sure, sending a element in response to a submission is possible, but it doesn't give the machine receiving this error any specific detail as to the nature of the problem, other than a string. Would be nice if there was an element that would specify a schema for errors possibly? I don't know... Apologies if this doesn't make much sense, but it was written on the move... -- Richard
Re: [Standards] Proposed XMPP Extension: IO DATA
Peter Saint-Andre schrieb: Johannes Wagener wrote: Proposed XMPP Extension: IO DATA Hello, here I submit a proposal for a new XEP called "IO DATA". The XEP is already located in the XEP inbox directory: URL: http://www.xmpp.org/extensions/inbox/io-data.html However, the initial version is erroneously missing some namespaces in the examples, therefore we append the current fixed version as PDF to the mail directly to the standards mailing list. Feel free to send updated versions to me and I'll update that URL. Yes, I will do so this weekend. I will have fixed the issues I got pointed to within the discussion... Abstract: This specification defines an XMPP protocol extension for handling the input to and output from a remote entity. Further explanation comes here: We want to do dynamic Web Services over XMPP. For certain reasons we explain in the XEP we think neither SOAP over XMPP nor Jabber-RPC is the way to go. We think future asynchronous Web Services can be best implemented with the session based Ad-Hoc Commands XEP-0050. Thus, and as already suggested in Ad-Hoc Commands we describe an alternative data container IO DATA that can transport more complex data than Data Forms. The specification describes a way to discover the Schemata of the IO DATA input and output at runtime, too. Thus a client implementation can dynamically marshal an API for the input and output of a certain service. Yes, ad-hoc commands can include payloads other than XEP-0004 data forms. It's good to see someone using that extensibility. Just curious: did you look at XForms? I looked at XForms. XForms is primarily used for a form based data transmission while describing certain layers of abstraction. We thought that these abstractions are already too restrictive and are not required for a general usage. Though it is still possible to pass XForms in the data container of our XEP proposal without changing anything. all that would be advised is to publish a schema with the linking to the XForm Schema.
Re: [Standards] Proposed XMPP Extension: IO DATA
Hi Peter Saint-Andre schrieb: 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. Good question. Typically I think that computational processes might want to include binary blobs. The question is how best to do that -- e.g., a element per XEP-0231 or a reference to a URI where the data can be retrieved via HTTP or FTP or XMPP or whatever. Yes, that's true: many real life examples will have to transport binary data somehow. In fact one of the Examples in the xep proposal (in section 4.4) makes use of XEP-0231 (encrypting a wav file into an mp3 file). But as XML is very flexible itself we can think about various legal ways of passing data via the stream. For example it might be possible to make use of XEP-0065 SOCKS5 Bytestream or maybe reference data via HTTP/FTP. Initially we thought about specifying this, but then we thought, that there is already enough flexibility coming with XML. It is possible for the client to discover the io schemata of the ad hoc service io data container. These schemata can hint to the way of data transfer (for example namespace forXEP 0231) compatible with the service. Example: 4.2 Plenty options here.
Re: [Standards] Proposed XMPP Extension: IO DATA
Johannes Wagener wrote: > Proposed XMPP Extension: IO DATA > > Hello, > here I submit a proposal for a new XEP called "IO DATA". > > The XEP is already located in the XEP inbox directory: > URL: http://www.xmpp.org/extensions/inbox/io-data.html > > However, the initial version is erroneously missing some namespaces in > the examples, therefore we append the current fixed version as PDF to > the mail directly to the standards mailing list. Feel free to send updated versions to me and I'll update that URL. > Abstract: This specification defines an XMPP protocol extension for > handling the input to and output from a remote entity. > > Further explanation comes here: > We want to do dynamic Web Services over XMPP. For certain reasons we > explain in the XEP we think neither SOAP over XMPP nor Jabber-RPC is the > way to go. We think future asynchronous Web Services can be best > implemented with the session based Ad-Hoc Commands XEP-0050. > > Thus, and as already suggested in Ad-Hoc Commands we describe an > alternative data container IO DATA that can transport more complex data > than Data Forms. The specification describes a way to discover the > Schemata of the IO DATA input and output at runtime, too. Thus a client > implementation can dynamically marshal an API for the input and output > of a certain service. Yes, ad-hoc commands can include payloads other than XEP-0004 data forms. It's good to see someone using that extensibility. Just curious: did you look at XForms? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
Fabio Forno wrote: > (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: What is the particular benefit here of having a RESTful interface? In particular, do you think that we need to reference each action via a URI? Such as: xmpp:compute.example.com?io;node=foo;action=get;data=schema > - 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 > > I think you meant type='get' :) > > It might be good to separately specify the node and the data type (in this case, the schema). > - 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 > > > > > > > > > - 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 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) > > > > > > > > > > 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. Good question. Typically I think that computational processes might want to include binary blobs. The question is how best to do that -- e.g., a element per XEP-0231 or a reference to a URI where the data can be retrieved via HTTP or FTP or XMPP or whatever. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: IO DATA
On Sun, Mar 30, 2008 at 2:16 AM, Johannes Wagener <[EMAIL PROTECTED]> wrote: > > Proposed XMPP Extension: IO DATA > > Hello, > here I submit a proposal for a new XEP called "IO DATA". > > The XEP is already located in the XEP inbox directory: > URL: http://www.xmpp.org/extensions/inbox/io-data.html > > However, the initial version is erroneously missing some namespaces in > the examples, therefore we append the current fixed version as PDF to > the mail directly to the standards mailing list. > > Abstract: This specification defines an XMPP protocol extension for > handling the input to and output from a remote entity. > > Further explanation comes here: > We want to do dynamic Web Services over XMPP. For certain reasons we > explain in the XEP we think neither SOAP over XMPP nor Jabber-RPC is the > way to go. We think future asynchronous Web Services can be best > implemented with the session based Ad-Hoc Commands XEP-0050. > > Thus, and as already suggested in Ad-Hoc Commands we describe an > alternative data container IO DATA that can transport more complex data > than Data Forms. The specification describes a way to discover the > Schemata of the IO DATA input and output at runtime, too. Thus a client > implementation can dynamically marshal an API for the input and output > of a certain service. > > Johannes > +1 This data container is really useful for a lot applications. Through my development of the Data Form Designer Suite for XMPP I've learned a lot about x-data and ad-hoc enhancement proposals. This showed me that ad-hoc commands which aren't emitted by humans might not need the overhead of static forms and structure. That's why this XEP is useful for all future machine-to-machine application and will largely ease development of them. Best of all there is already a working implementation so the concept has been more than proven. Cheers Tobias
Re: [Standards] Proposed XMPP Extension: IO DATA
Dear Fabio, thank you for your comment/clarification about the term "REST". Fabio Forno schrieb: 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. The basic principles of REST in fact are: Sorry for causing confusion with this term. In conclusion we - as egon already mentioned we will use another term and fix the sentences where "RESTful" term was used. Johannes
Re: [Standards] 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 - 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 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 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
Re: [Standards] Proposed XMPP Extension: IO DATA
(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 - 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 - 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 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) 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]
Re: [Standards] Proposed XMPP Extension: IO DATA
On Sun, Mar 30, 2008 at 7:09 PM, Fabio Forno <[EMAIL PROTECTED]> 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. Fabio, 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 minutes. 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! Egon -- Post-doc in Metabolomics Wageningen Universtity & Research Center, The Netherlands http://chem-bla-ics.blogspot.com/
Re: [Standards] Proposed XMPP Extension: IO DATA
On Sun, Mar 30, 2008 at 2:16 AM, Johannes Wagener <[EMAIL PROTECTED]> wrote: > Proposed XMPP Extension: IO DATA > > > Abstract: This specification defines an XMPP protocol extension for > handling the input to and output from a remote entity. > Some remarks. You write "While SOAP over XMPP supports complex functionality it lacks an obvious mechanism for asynchronous usage (for example it has no default RESTful design: there is no sessionid like in Ad-Hoc Commands)." 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. The basic principles of REST in fact are: - being able to address "resources" with URIs; since ad hoc commands end points nodes, whose URI may be xmpp:[EMAIL PROTECTED]/resource;node=nodename (if I remember well), they are RESTful in this aspect - be able to do actions (verbs like post/get/delete/put) on that resources; in this ad hoc commands are not RESTful, since they don't define a real action, they just provide a generic "execute" - stateless operations, and state or sessions are intentionally left out from REST, since they are too much application dependent; ad hoc commands have just a limited "session" concept, which is a sequence of operations forming a wizard with a start and an end. However applications may have different concepts of sessions, such as all operation between a login and logout, on a given resource or on a set of resources, or all operations in period of time; these are all concepts more complex than the model provided by ad hoc commands. For this reason I'd leave the responsibility of handling a session to the application, which should find a way for passing state information among requests as cookies or other mechanisms in HTTP. bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
