AMF: Not just for Flash anymore.
Things have been quiet on the blog front, mainly because we’re busy working on stuff that we can’t talk about. One thing that I have been researching though is protocols and serialization. I’ve had a few conversations about all the various formats out there, and I wanted to talk about a great tech: AMF.
For purposes of this post, I’m going to use the term ‘protocol’ loosely. A protocol to me can mean many things: serialization, deserialization, messages, gateways, code generation, etc. Yes, I know AMF isn’t technically a protocol. Please forgive me, purists.
I’ve used a lot of different protocols: SOAP, RESTful, and various and sundry custom protocols. At the end of the day, I seem to keep coming back to AMF.
Protocol Landscape
When reviewing the various types of protocols out there to use, we looked at the following options:
A comparison of different protocol technologies.
In our research on the web, these seemed to be the best options we could find. We could roll our own, but we wanted something well supported.
Based on our criteria, the best options were Google Protocol Buffers and AMF. I highly recommend checking out GPB, but there were a couple drawbacks for us (mainly involving code generation and file system operations). So in the end AMF won out.
AMF is an open source binary protocol, developed by Adobe for object transfer in the Flash player. There is something called AMF Remoting which is a quasi-standard for transferring AMF objects using an AMF ‘gateway’. Gateways can provide ‘discovery’ services similar to WSDLs for SOAP. AMF sends class/instance data and a ‘remote alias’ so that on the other end the deserializer can take the AMF object and convert it into a strongly typed object based upon this alias.
Benefits of AMF
Lightweight
The only thing smaller in file size is probably Google Protocol Buffers. The message format contains a description of the class, the instance object’s data, and any strings used in a reference table. Each of these is only in their once, so things are tiny.
Strong library support
You can find libraries pretty much everywhere. Objective-C, Flash, PHP, Python, Android, Java, C#. Most of these are very mature at this point too.
Strong Typing
Its possible to strongly type objects across subsystems quite easily. We used GraniteDS and AMF to send strongly typed messages back and forth at a previous job. I am currently sending strongly typed AMF objects using the CocoaAMF library. This means you know what you are sending and receiving.
This was a place where we debated the benefits of Google Protocol Buffers vs. AMF. GPB also strongly types your objects, and its expected that you will use code generation tools to output your objects’ code using the GPB toolset. Code generation is a double edged sword. If we were say, Google-sized, I think we would most likely use GPB, because of the convenience of code generation in a larger coding ecosystem.
Ease of Debugging
Charles debugging an AMF connection.
One of the more problematic aspects of protocols is figuring out if they’re doing what you want them to. If you are using HTTP to send your AMF, it is quite easy to use things such as Charles to view the AMF data being sent between your client and server. Couple this transparency with strong typing and you can dramatically reduce your debugging times.
Reference-based
A lesser-known feature of AMF is that it handles references to multiple objects within its hierarchy. This is much different than, say, JSON or SOAP, which provide a strict non-recursive graph of objects. In AMF, the same object may be referenced in multiple places, and the object is not duplicated when serialized/deserialized. This works very similarly to Apple’s NSCoding protocol, and indeed CocoaAMF‘s AMFArchiver/AMFUnarchiver implement the NSCoding protocol.
Drawbacks
So AMF is…just peachy? Well, it does have a couple drawbacks.First, its a *binary* protocol. So that means if your target doesn’t speak binary, AMF isn’t an option. AMF also doesn’t have any built-in code generation. Lastly, even though its binary, Google Protocol Buffers is better for size in certain cases.
Conclusion
Overall AMF is a great technology, and can be used in many non-flash applications. Check it out!