On Monday I showed two screenshot showing our\nnew XMPP-based web/cloud services in action\ninside Taverna.
\n\nI promised details, but realize I have actually already posted a lot of them in October :
\n\n\n\n\nJohannes ideas led to the IO-DATA proposal (XEP-0244), which is currently\nmarked experimental and being discussed on the ws-xmpp mailing list. He gathered a few people around him to get it going,\nresulting in working stuff! Yeah!
\n
Joerg asked\nCould you post more results, what is it, why do we need it, e.g. why are you mentioning SOAP and cloud? Do not know enough to see the bonus right now.
\n\nWhat is it? IO-DATA is a protocol on top of the XMPP protocol to allow machine-to-machine communication. Actually,\nmuch like SOAP, RPC, and other platforms. How IO-DATA differs lies to some extend to the transport layer: instead of\nusing HTTP, it used the XMPP transport protocol, also used for Jabber chat clients. It basically allows clients like\nTaverna to chat with services running elsewhere.
\n\nWhy do we need it? Most services run over HTTP, making them web services. This is convenient, because there is\nmuch infrastructure around, like web browsers. REST services also take advantage of this. However, for heavy\ncomputing this sometimes leads to problems. For example, routers are known to have time outs on HTTP connections.\nTo solve this, SOAP services often introduce a polling mechanism. IO-DATA takes a different approach. Instead of\nhaving to ask all the time how a calculation is doing, you can just wait for the service to send you a message\nwhen it is done. Instead of working around the lack of asynchronous aspects, IO-DATA introduces these in the protocol.
\n\nOther interesting features include that the IO-DATA integrates the interface formats for services into the service\nitself, SOAP needs WSDL for this, and that it features service discovery via DISCO. The latter is done with SOAP\ntoo, for example with UDDI and BioMoby. The latter also adds strong data typing for input and output of services.
\n\nIO-DATA addresses the data typing by allowing asking the service what XML Schema it uses for input and output.\nWhile XML Schema has alternative, and which may be prefered in some situations, it does allow strong data typing\nand supports a lot of formats in life sciences\n(which I’ll summarise soon).
\n\nMoreover, if there just happens not to be a suitable schemata around, you can just define one yourself, which can\nbe as simple as a single element wrapper around some custom text-based format. You worry about supporting many\nformats? Well, no need. Johannes’ xws4j library, which I used for the Taverna plugin too, allows compiling a Java\nbinding code. Bioclipse’s script environment allows you do to this on the fly: you find a service, ask for the\nschema, compile bindings for input and output, set up the input with the input binding, send it of to the service,\nand use the output binding for convenient access to the computation results. Without having to reboot Bioclipse.\nIsn’t that cool? Can your software do that? (See this example Gist: the io\nfactory creates the binding).
\n\nWhy do I mention SOAP and the cloud? It should be clear from the above why I mention SOAP: it offer the same\nfunctionality, but more conveniently, we think. I mention cloud here, to refer to cloud computing which is doing\ncomputation on the cloud, which is a synonym for the internet (see\nCloud Computing @ Wikipedia). Because it does\nnot use HTTP, we do not feel we can call it web service. Instead, cloud computing is a more general term, not\ntied to any particular architecture. IO-DATA is just one possible architecture, one we think is promising for\nlife science applications.
", "summary": "On Monday I showed two screenshot showing our new XMPP-based web/cloud services in action inside Taverna.", "date_published": "2009-01-21T00:00:00+00:00", "date_modified": "2025-10-26T00:00:00+00:00", "tags": ["xmpp","taverna"], "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286" } ] } ] }