bodom_lx at task3 dot cc

It took us more than two months of discussions in order to decide which protocol to adopt for procedure calls in Dycapo.

Our intentions were to extend an existing XML-based protocol, built-over Atom specification. The first solution we took in consideration was to implement a remote procedure call protocol based on OpenTrip. That is, directly passing OpenTrip objects over HTTP methods.

Unfortunately, the most elegant solution immediately appeared as unsuitable for those reasons:

1. There exists AtomPub that seemed to fit our needs. Unfortunately there are no interesting free implementation for it, both for the server and the mobile side. Moreover, the author of the protocol seems the first one declaring it is a failure.
2. The adoption of OpenTrip as it is would imply the creation of new parsers and utilities for (Un)Marshalling data: nobody would write a client for Dycapo if he/she has to implement everything else from scratch
3. OpenTrip is at a “0.1 draft” status. It may change very often in the future. I would not have the time to create and update parsers and utilities while developing Dycapo.

Therefore, we took the decision to adopt OpenTrip entities and propose Dycapo Protocol over some existing protocol. We looked at REST, XML-RPC and SOAP.

REST was seriously taken into consideration, as it is successfully used by Flickr, Delicious, Yahoo and Twitter (and many others). Even if it is not a protocol, it permits to define coincise locations for resources and imposes some rules on the vocabulary used, creating self-descriptive messages. Moreover, there are many Django extensions that support REST.
Unfortunately, I could find some reasons to adopt a RESTlike protol NOW.

1. It is NOT a protocol but an architecture, or a set of conventions. Therefore, it does not define a format for data exchange. There exist JSON, YAML 1.0, YAML 2.0, arbitrary XML formats. Every successful RESTful WS either defines its own XML format or provides support for all these formats. We would like to be completely architecture independent. Therefore we need a strong data exchange format in order to handle our quite complex objects sent and received by and from clients.
2. It may still require a lot of work on the client side caller of the library to make use of data (custom serialization and so forth)
3. But it seems that JSON is the most adopted and widely accepted format, also officially supported by mobile OS like Android

We are not aware of any successful application using REST that needs to pass around complex objects. For example Flickr specifies which parameters must be passed to methods and their format. See an example on this API page.
Our goal in adopting OpenTrip objects was to don’t worry about parameter passing but to just have OpenTrip objects defined in the client, in the server and also inside the databases they keep. Therefore, to have universal objects that can be passed around as parameters.

Regarding XML-RPC and Soap, we know that they are very similar (first drafts of Soap were about XML-RPC with namespaces). After analyzing both of them, we agreed on discarding SOAP in favor of XML-RPC because

1. It is lighter than SOAP: you just put objects/method calls encoded in XML in HTTP methods. SOAP adds overheads by using namespaces, envelopes, a header, body and fault sections.
2. It exists since 1998.It is supported by all modern mobile devices, from iPhone to Android to Symbian. Moreover, its data exchange and message formats are very simple. It would be easy even to write a library from scratch. As an example, look at how tiny and simple is android-xmlrpc. SOAP is not widespread on mobile devices as XML-RPC is. Its complexity is also a barrier to write libraries and parsers.
3. XML-RPC permits us to exchange quite complex objects regardless the implementation of server and clients. It has many data types already available. In particular our OpenTrip objects passed as parameters surely contain arrays and structs.
   (Un) Marshalling of data is often possible with XML-RPC. Developers just have to look at our method signature and object structure and forget about the RPC structure and formats. Everything should be automatically handled by existing libraries

We did some tests with available XML-RPC libraries for Java (also Android) and Python (Django). We found that marshalling and unmarshalling of OpenTrip objects is possible, i.e. objects can be serialized and passed via XML-RPC by django and received and deserialized by Java with none or little adjustments.

But, to completely switch to a Service Oriented Architecture seemed to extreme, as we would also give back to the community. Moreover, we would like to publish a serious publication about the protocol and push it as a standard.

Therefore, we decided to act as follows:

1. To implement some server prototypes using XML-RPC methods carrying our extended OpenTrip Dynamic objects, encoded in its format. This is for quickly develop, testing and discuss the objects and operations, thus letting people easily write test clients.
2. When the prototype reaches a mature stage, we will introduce a RESTful protocol using the same objects and document all the operations.
3. The XML-RPC interface will stay active but won’t likely be developed anymore and we will uniquely focus on the RESTful protocol