[infinispan-issues] [JBoss JIRA] Commented: (ISPN-508) ProtoBuf as portable serialization for Hot Rod

[Galder Zamarreno (JIRA)]

    [ https://jira.jboss.org/browse/ISPN-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12538625#action_12538625 ] 

Galder Zamarreno commented on ISPN-508:
---------------------------------------

I've had a brief look at Apache Avro and here's what I've found out so far:

In terms of documentation, it's way behind protobufs. The only examples available are the quickstart which covers just one case (which btw is the same one as protobug where it generates classes based on a given JSON schema!) and then the Avro testsuite. The key thing in Avro is that is supposed to be consumed as an RPC library where you have the objects you want to write to wire and the remote methods you actually want to call where you marshall that data. So, all examples are geared towards that, rather than showing how to convert an object back/fwd a byte[]. For example, examples focus on creating a ServerSocket, Socket and how it creates a proxy for the object containing the RPC method and how you pass your object to it.

One of the most appealing things about Avro was dynamic typing where Avro does not require code to be generated as data is always accompanied by the schema. The schema is gonna have to come from somewhere and this means that either: you're gonna have to come up with a schema and generate your java code (same thing as protobufs does. In avro terms, they call this specific API) or let the reflection layer in avro do this which I'm not terribly excited about, particularly after reading the note in http://avro.apache.org/docs/current/api/java/org/apache/avro/reflect/package-summary.html#package_description where it says that reflection should only be used as a bridge until you've moved to used specific API where schemas are known at compilation time. The final way to serialize data is what they call generic where an object to serialize is constructed from a JSON schema known at runtime. We're not interested in this since we get the pojo given to us by the user.

It's worth noting that reflection based marshalling is not covered in the benchmarks shown in http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking. It only covers specific (ala protobuf) and generic APIs.

I'm gonna try to build small prototypes with both to get a better idea of how all this would be coded.

> ProtoBuf as portable serialization for Hot Rod
> ----------------------------------------------
>
>                 Key: ISPN-508
>                 URL: https://jira.jboss.org/browse/ISPN-508
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Cache Server
>            Reporter: Galder Zamarreno
>            Assignee: Galder Zamarreno
>            Priority: Critical
>             Fix For: 5.0.0.BETA1, 5.0.0.Final
>
>
> Consider using Google ProtoBufs as a way to serialize data into a wire so that a single Hot Rod server can simulatneously be accessed by clients written in different languages. At the moment, cos Java client uses standard serialization, only Java clients would really be able to understand the contents of it, unless there's a non-JVM implementation that can understand java serialization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira