Fastest reliable way for Clojure (Java) and Ruby apps to communicate
We have cloud-hosted (RackSpace cloud) Ruby and Java apps that will interact as follows:
- Ruby app sends a request to Java app. Request consists of map structure containing strings, integers, other maps, and lists (analogous to JSON).
- Java app analyzes data and sends reply to Ruby App.
We are interested in evaluating both messaging formats (JSON, Buffer Protocols, Thrift, etc.) as well as message transmission channels/techniques (sockets, message queues, RPC, REST, SOAP, etc.)
Our criteria:
- Short round-trip time.
- Low round-trip-time standard deviation. (We understand that garbage collection pauses and network usage spikes can affect this value).
- High availability.
- Scalability (we may want to have multiple instances of Ruby and Java app exchanging point-to-point messages in the future).
- Ease of debugging and profiling.
- Good documentation and community support.
- Bonus points fo开发者_运维知识库r Clojure support.
- Good dynamic language support.
What combination of message format and transmission method would you recommend? Why?
I've gathered here some materials we have already collected for review:
- Comparison of various java serialization options
- Comparison of Thrift and Protocol Buffers (old)
- Comparison of various data interchange formats
- Comparison of Thrift and Protocol Buffers
- Fallacies of Protocol Buffers RPC features
- Discussion of RPC in the context of AMQP (Message-Queueing)
- Comparison of RPC and message-passing in distributed systems (pdf)
- Criticism of RPC from perspective of message-passing fan
- Overview of Avro from Ruby programmer perspective
- Overview of Thrift from Ruby programmer perspective
- Overview of Thrift from Java programmer perspective
- Introduction to MessagePack
- Introduction to BERT by dynamic language enthusiast
- Message Queue Evaluation Notes
- ZeroMQ and Clojure
We have decided to go with BSON over RabbitMQ.
We like BSON's support for heterogeneous collections and the lack of the need to specify the format of messages up-front. We don't mind that it has poor space usage characteristics and likely poorer serialization performance than other message formats since the messaging portion of our application is not anticipated to be the bottleneck. It doesn't look like a nice Clojure interface has been written to let you directly manipulate BSON objects, but hopefully that won't be an issue. I will revise this entry if we decide that BSON won't work out for us.
We chose RabbitMQ mainly because we already have experience with it and are using it in a system that demands high throughput and availability.
If messaging does become a bottleneck, we will look first to BERT (we rejected it because it currently does not appear to have Java support), then to MessagePack (rejected because it appears that there isn't a large community of Java developers using it), then to Avro (rejected because it requires you to define your message format up-front), then Protocol Buffers (rejected because of the extra code generation step and lack of heterogeneous collections) and then Thrift (rejected for the reasons mentioned for Protocol Buffers).
We may want to go with a plain RPC scheme rather than using a message queue since our messaging style is essentially synchronous point-to-point.
Thanks for your input everyone!
Update: Here is the project.clj
and core.clj
that shows how to convert Clojure maps to BSON and back:
;;;; project.clj (defproject bson-demo "0.0.1" :description "BSON Demo" :dependencies [[org.clojure/clojure "1.2.0"] [org.clojure/clojure-contrib "1.2.0"] [org.mongodb/mongo-java-driver "2.1"]] :dev-dependencies [[swank-clojure "1.3.0-SNAPSHOT"]] :main core) ;;;; core.clj (ns core (:gen-class) (:import [org.bson BasicBSONObject BSONEncoder BSONDecoder])) (defonce *encoder* (BSONEncoder.)) (defonce *decoder* (BSONDecoder.)) ;; XXX Does not accept keyword arguments. Convert clojure.lang.Keyword in map to java.lang.String first. (defn map-to-bson [m] (->> m (BasicBSONObject.) (.encode *encoder*))) (defn bson-to-map [^BasicBSONObject b] (->> (.readObject *decoder* b) (.toMap) (into {}))) (defn -main [] (let [m {"foo" "bar"}] (prn (bson-to-map (map-to-bson m)))))
I can't speak from personal experience, but I know that Flightcaster is using JSON messaging to link their back-end clojure analytics engine to a front-end Rails app and it seems to be working for them. Here's the article (appears near the end):
Clojure and Rails - the Secret Sauce Behind FlightCaster
Hope this helps. --Mike
I have no experience in this regard. I will post this possibly-helpful guess anyway.
ZeroMQ offers point-to-point messaging, including with various types of network topologies. Messages consist of arbitrary binary values - so you will just need a binary serialization format for your structured messages.
BSON, ProtoBuffers, and BERT offer serialization of arbitrary data structures (numbers, strings, sequential arrays, associative arrays) into binary values.
GitHub invented BERT for fast RCP; BSON was invented by MongoDB (or 10gen) for the same reason; and ProtoBuffers likewise by Google.
I believe Protocol-buffers would be a lot faster and more efficient than JSON (last time i checked it was around 40 times faster, i didn t try it with ruby tho so your mileage may vary).
精彩评论