I’ve been fortunate to be involved in a project that makes use of OpenAMF. Although I didn’t spend a lot of time with the technology, it is an interesting proposition.
AMF is the binary wire protocol for RPC calls between a Flash player and a server. OpenAMF is a Java-based open source implementation, providing an alternative to Macromedia’s Flash Remoting MX (and also therefore providing a saving of something like £750 per CPU).
In practice, a Flash client makes calls to OpenAMF which sits inside a servlet engine. It’s the right way to do things (as of 2005): you end up with an SOA-based rich internet application.
- Tools: the Flash authoring editor is unrivaled, and although open source or free tooling is available, it’s nothing like the editor. In the AJAX world there are no special tools needed.
- Protocols: The “open” in OpenAMF refers to an open source implementation, not the nature of AMF. Although the Flash file format specification has been released, AMF has not. AJAX has HTTP as a protocol, which can’t be any more open, and builds on that with either REST or SOAP services.
- All-or-nothing: The impression is that if you’re going to use Flash you’re going to use it for the whole project. AJAX is more amenable to being mixed in, gradually, to existing “regular” web sites to add dynamic features where they are needed the most. Less risk (or more, depending on your point of view w.r.t Flash).
- Mobile: SOA is, theoretically, client neutral. What is the protocol to use for a mobile application? Although Flash Lite is making its way to mobile devices, the player omits support for remoting. Macromedia have to fix that.
The conclusion I draw is that AJAX is the path of least resistance. Assuming most people go that route, OpenAMF could still work as a bridge between services for AJAX and services for Flash. Either way, it looks like the demand for rich internet applications is going to continue to grow, and SOA is going to stick around for a while.