Mike Rettig announced the Jetlang Remoting Specification back in June. This extends the Jetlang library to IPC and distributed scenarios. It’s intentionally language-agnostic but to the best of my knowledge there is currently only a Java implementation (Retlang doesn’t have it.) It’s flavour is of a really stripped down version of ZeroMQ:
- It implements packet sending across TCP/IP
- It doesn’t tell you how to serialize your objects; that’s your concern, not Jetlang’s.
- It handles publish/subscribe and request/reply scenarios.
In other ways, it feels like Retlang 0.2. In particular, subscriptions are on the basis of topics. Retlang 0.3 replaced this with the channel model, which only works in memory.
So, given that I’ve got a well-known obsession with Retlang and have recently been working with ZeroMQ, how do they stack up?
Advantages
Well, for one thing it’s a lot, lot easier to use. The implementation is in easy-to-read Java, not C, then JNI, then Java. The wire protocol is simple and documented so you can connect things to it without having to port the code. Jetlang’s documentation has never been the greatest, but ZeroMQ’s is nowhere near as good as it looks. In short, if I needed to do something in a hurry, I’d favour Jetlang Remoting.
Second, Jetlang Remoting is designed to be asynchronous. Sending two requests to the same destination and getting back the results when they finish (rather than the order in which they were sent) is considered “advanced usage” by ZeroMQ, and is the default use case for Jetlang Remoting.
The biggest difference has to be in pub/sub scenarios, though. In ZeroMQ, if you subscribe to a socket, you get the firehose. There’s no way to say “please only send me orders that this trader can see” without opening up another socket. Jetlang’s topics provide a mechanism for achieving that. I would be surprised if a parallel ZeroMQ and Jetlang pub/sub project resulted in far less wire traffic in the Jetlang case.
Finally, Jetlang Remoting doesn’t pretend to be sockets. I’m sure it’s a lovely idea and there are many, many powerful things you can achieve with it, but if all I needed was asynchronous RPC and pub/sub, ZeroMQ proves bizarrely opinionated about what exactly I’m allowed to put down the wire. You’ll note, for instance, that the Jetlang spec makes no reference to “client” and “server”. The concepts aren’t needed.
Disadvantages
Jetlang doesn’t handle anything like store and forward. One of the cool things with a ZeroMQ solution is that you can power-cycle a server and everyone connecting will continue to work. This includes those who sent messages while the box was down, providing they didn’t choose to time out. Jetlang does do automatic reconnection, but that’s about it.
ZeroMQ also supports more protocols than just TCP. In particular, it would probably be significantly faster in the case of two processes communicating in the same memory space. (Mongrel does this.) It probably wouldn’t be hard to extend Jetlang Remoting to these cases, it probably just isn’t necessary for the project they’re working on.
Differences
ZeroMQ does its damnedest to make intra-process communication look the same as inter-process communication. Mike Rettig doesn’t believe that’s a good idea, If you’re looking for a unified API where you can invisibly move components into and out of process, you really should look somewhere else. YMMV on this one.
Criticisms
Just a couple of annoyances I found in the spec:
- Topics are ASCII only. I really don’t think it would have done much harm to make it UTF-8. Anything that actually is ASCII would have the exact same wire representation.
- For that matter, why not make topics byte arrays? or integers?
- Receivers detect heartbeats, but senders configure when they send them, which introduces a co-ordination annoyance. One extra message would enable the sender to inform the receiver of his heartbeat schedule. (FIX suffers from the same problem.)
Conclusion
All in all, it looks like Mike Rettig has done it again. He’s taken something that’s widely regarded as difficult and made it look easy. If you need all the bells and whistles of ZeroMQ, obviously you’re going to go down that route. But if you just need asynchronous rpc and pub/sub, Jetlang Remoting looks like the best option.
Colour Coding 