Ever since joining Fuel Industries, I’ve had a new found respect for Flash development. Flash isn’t well suited for every types of development, for example I wouldn’t want to see google.com fully implemented in flash! When it comes to adver-gaming, which Fuel Industries is a leader of, Flash rules supreme (although more and more of our development is moving towards Virtools). You simply can’t build the same type of web-based immersion/branding in HTML/ASPX (even with Atlas/Ajax). We even build traditional web-based intranet application using Flash frontends. The end result is always something that impresses me a lot.that seems much more desktop-based than web-based.
Flash is just a presentation layer however, so how can it consume a business layer? The best solution is to use Macromedia’s Flash Remoting Technology, which uses a proprietary binary stream (AMF) to communicate with server-side code. Anyone familiar with AJAX should have a good feel for Flash Remoting. The main difference being that you aren’t using JavaScrit or XML – but rather ActionScript and AMF.
The problem with Macromedia’s Flash Remoting technology is the cost. It’s about $1000USD – which isn’t cheap. (the other problem is the “crapstically” written documentation, which I’ve railed against before). In response to the high price, a group of PHP developers created the highly popular AMFPHP – an open source alternative for PHP. This led to the development of OpenAMF – an open source alternative to Java. The first thing I was tasked with at Fuel was to create an open source .NET alternative – AMF.NET.
(there were some .NET alternatives already available, namely Fluorine, but I had some strong reservations against it).
Knowing little about Flash, my main goal was to make the process of consuming .NET code as transparent as possible. As a presentation layer, Flash should have no impact on how the business layer is implemented. The biggest problem I ran into was the disparity between data types. Of particular interest was the fact that all numeric types in AMF are treated as doubles. So if you call a server side function and pass the integer value 10, it’ll get converted to 10.0. A lot of the work AMF.NET does is iron out those riples so your C# or VB.NET code can be written like you’d expect – with an int and not a double and with no extra attributes.
AMF.NET is implemented as an HttpHandler. So all you need to do is drop the DLL in your bin folder, add a line to your web.config and you’re good to go. If you want to let your server-side code get called form multiple domains, you’ll also need to dro a crossdomain.xml on the server (more info here)
It just takes a couple of lines of ActionScript to execute a remoting call:
var service:Service =
var pc:PendingCall = service.GetUser(1);
A new service is created and pointing to our HttpHandler. Notice that the service is using the standard .NET type naming to specify the type (namespace.class, assemblyName). We can then call server side method (GetUser) which accept parameters and handle the response.
So far, AMF.NET has been used on three relatively small projects here. For example, we used it in Hershey’s Take5 candy bar game (http://www.hersheys.com/take5/). As we continue to use it, we’ll build onto AMF.NET – but so far it’s proven extremely capable of doing this simple jobs – and there’s no reason to think it can handle a lot more as-is.
Both the PHP and Java projects were hugely useful in creating AMF.NET. Fiddler was also incredibly useful.
You can learn more about AMF.NET form the official homepage: