gistfile1.rst

Concerns about IO Data

I unfortunately missed the community conversation about the XEP up until now.

I have been working with web services (XML-RPC, SOAP, etc), and have concerns about the custom protocol in the IO Data XEP.

I'll be comparing IO Data with SOAP, and highlighting the various shortcomings. I'm not comparing it with the existing SOAP over XMPP XEP mind. I'm inclined more towards using Ad-Hoc Commands, but with SOAP payloads instead of IO Data.

The IO Data rationale for not using SOAP

I'll start by disecting the rationale used for not using SOAP.

While SOAP over XMPP supports complex data types it lacks an obvious mechanism for asynchronous usage.

That's untrue. Nothing prevents SOAP from being used over non-HTTP protocols in an asynchronous fashion. SOAP has an SMTP binding for example: http://www.w3.org/TR/2001/WD-soap12-part0-20011217/#SMTP

For example it has no default stateful design: there is no sessionid like in Ad-Hoc Commands.

That's left up to the transport. See how the SMTP binding for SOAP uses a Message-Id. No reason it can't be used with Ad-Hoc Commands.

Beside this SOAP brings in severe complexity (XML associated abstractions) that was required for the primary transport layer HTTP.

SOAP payloads are no more complicated than IO Data payloads. All that's required is the service-defined payload inside a <soap:Body> element, which would be inside a <soap:Envelope> element. SOAP can be extended using SOAP headers, but those are optional, and implementations are not required to support them.

And SOAP was designed to be automated. You are supposed to use SOAP libraries, which exist for pretty much any language in common use. The most complex part in SOAP is processing WSDL (the most complicated part of which is XML Schemas), but then IO Data is equivalent.

This complexity is not required because XMPP does already implement the required XML associated abstractions.

Much of the complexity you are talking about here is optional. Implementations are not required to implement the whole family of specifications of which SOAP is a part. Just use the core RPC mechanism.

For example to date most HTTP SOAP implemented services are only compatible with a subset of SOAP libraries.

But they exist, and are in wide use. In wider use than any other competing standard. And they are easy to construct, thanks to the large number of tool implementations.

Advantages that SOAP has over IO Data

A W3C Recommedation

SOAP (along with WSDL) is a W3C Recommendation. It's mature, and has seen extensive consensus-building. It's part of a large family of web services specifications which build on top of each other (see http://en.wikipedia.org/wiki/List_of_Web_service_specifications - the WS-* ones are W3C specifications). IO Data has no such supporting standards.

Tool support

SOAP and WSDL have tools and libraries available for pretty much all languages in common use. You can take a WSDL document, process it using a tool or library, and get static or dynamic marshalling without much effort. It's integrated with IDEs. In Visual Studio for example, you can add a WSDL URL in the same way you would add a library. Then you get to use it as any other local library. That kind of seamless approach saves a lot of time and effort.

Tools and libraries matter. A lot. With IO Data you would be required to roll your own from scratch.

Existing use

When it comes to web service standards, SOAP has probably gained the broadest acceptance in the industry. That's thanks to it being an open protocol, and not being CORBA. It's /the/ open web services protocol used in B2B transactions and SOAs. That represents a huge investment by large businesses.

The protocol

WSDL describes a service (which is a collection of functions). It's a single document, which can be retrieved with a single request. IO Data's Schemata discovery on the other hand requires a separate request for each function. That's significant overhead if you are trying to do dynamic marshaling. Also, since it's a single document, the schemas can be shared, reducing bandwidth usage significantly for large APIs.

Here's how Example 1 in the XEP can be reduced by using SOAP+WSDL:

service = client.getService("database.server.com"); // this effectively gets the full schema

if (service.getXMLFile) {
 // Invoke the function and get the output
 output1 = service.getXMLFile("doc-ID-011021");
 title1 = output1.getDocumentTitle();

 // Next document
 output2 = service.getXMLFile("doc-ID-833423");
 title2 = output2.getDocumentTitle();
}

The point here is the better integration with the language, and the lack of per-function schemata.

-- Waqas Hussain