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.
2. This implied 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 more reasons against the adoption of REST than in favor:

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 SON, YAML 1.0, YAML 2.0, arbitrary XML formats. Every successful REST-ful 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. REST is a Resource-Oriented Architecture. Everything is thought around representation of resources. Dycapo implementation would fit with difficulty in this way of thinking. A Service-Oriented Architecture fits our needs and way of thinking.
3. 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)

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 the adoption 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. An example could be an array of 4 Locations as part of a Trip object. In Rest we would have needed to decide how to marshall arrays into parameters, and developers would have needed to create their own parsers and serializers.
   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 adjustements.

As a tiny example, look at the following code. It is a snippet of the current method call when searching for a ride. I just included the generated XML-RPC for the second parameter, as the first one is an object of the same type.

dycapo.search_trip ( Location source , Location destination )

< ?xml version='1.0'?>
 
  dycapo.search_trip
 
      [..]
 
 
 
 
              georss_point
              1.0,1.0
 
 
               point
               dest
 
 
                leaves
                2010-03-12 14:36:54.772156
 
 
                label
                office

See how simple and elegant it is? We are simply passing an object, represented as a struct, with 4 attributes:

• georss_point: "1.0,1.0"
• point: "dest"
• leaves: "2010-03-12 14:36:54.772156"
• label: "office"

Don't try to reason about types, names and quality: we are still experimenting.

Here I provide a tiny mindmap summarizing the basic concepts of SOAP.
I'm using it for studying Advanced Internet Technologies.

• See the exported clickable map + HTML
• Download the original Freemind document

As sources, I used W3C official specification and w3schools.

My third meeting at FBK is about to end. Today we discussed about some use-case, sequence and class diagrams I wrote during the week. Obviously there were lots of changes after the discussion and I will post them as soon as I've updated them. For the next time I will take a look at some implementation issues. The client side could be written using Android while for the server side we are seriously looking at Python and Django. It would be very interesting! For the communication, we are reasoning about XML-RPC, SOAP or a personalized Restful API. OpenTrip protocol might not be included in our implementation, as we don't have the time to parse non-standard XML and adapt the system to use it. But this is not a final decision.
I will also write some simple mockups to test all the possible combinations.