I received a question about Flash Remoting and thought maybe my answer could be helpful for some other folks out there.

>> I'm looking into a job that would require working with AMFPHP. Has anyone dealt with it before?

I have to confess that I have never used AMFPHP, but I have used Open AMF, and Macromedia Flash Remoting for both Java and Cold Fusion. I have also worked with Carbon Five's ASTranslator, which can make working with Remoting at least a little less painful.

My opinions about Remoting have softened quite a bit over the past year or so, but remain nonetheless. Each objection that I have can be resolved one way or another, but I think one should be aware of these objections and their solutions before engaging in a Remoting project, regardless of the particular Remoting technology.

Tight Coupling: Remoting provides a very tight (and hidden) coupling between the client and the server. You can overcome this by creating an ActionScript mock implementation of your server that returns ActionScript objects just as if they were coming from the back-end. Your server developers need to also create a mock client. I think this is quite a lot of work and very difficult to keep in sync with changing APIs. This problem is a big deal. This problem means that unless you build the mock client and mock server, you can't really test your communication code until both the client and server are completely working. Additionally, there will come a day - that will probably turn into a week, when you have a server developer sitting next to you and the two of you have to struggle through "integration" just to get this layer resolved. It also makes it difficult to tell where a problem is. Is the problem on the server? Is the problem on the client? Is the problem in the mock server or mock client? Is the problem a bug in Macromedia's Remoting ActionScript code? How about the server side Remoting code? Don't forget that if you don't build a complete mock client and complete mock server, you will only be able to develop your client and server code while connected to the Internet - or at least while connected to one another. For example, you'll need a fully functional, CURRENT, configured server implementation on your client development machine. This will have to be kept in sync with updates as the server developers make them. This has additional development overhead as you learn the back-end build process. It also has additional performance overhead while you compile and test your client code.

Another issue with tight coupling is that you will have created server and client implementations that will only work with one another. You cannot take that PHP Remoting service and quickly build an HTML client for it. You are locked into Flash/Remoting/Your Server (FRYS!?). What if Adobe decides to bundle the Yahoo Toolbar, Acrobat Reader and some other unwanted junk into the Flash Player distribution? Your client might decide to use AJAX at that point. Now they're going to have to rebuild both halves of their application - not just the client code.

Debugging: There is a Remoting Debugger, but it's kind of useless in my experience, especially if you're transmitting large data sets, which ironically is the only reason to use Remoting in the first place!

Single Callback: Remoting provides a single callback for each remote method. This can cause a problem if your application calls the same method multiple times before the first result is returned. There is no guarantee that the results will be returned in order, and in fact they rarely are. Creation of additional gateways is fairly expensive in terms of performance, thanks to the NetService classes. There are some other workarounds like client-side connection pooling.

The only good justification that I have heard for Remoting is that it compresses your data into *much* smaller packets. I believe that if you really need to do this, you're probably doing something wrong in your data design. Your views will probably choke on such large record sets anyway. Have you considered paginated records? How about summary results that contain unique IDs, which then let you download single, client-requested record details? Consider how other people with extremely large data sets handle it. How does Google get terrabytes of data into a simple HTML web client? Do they just zip it all up and send it downstream for each request?

With the criticism out of the way, I do know some very smart people who use Remoting and they feel it's an excellent way to get data into and out of Flash. Based on discussions with them, it became clear to me that if you're experienced, have a fair amount of control over the back-end and don't mind building a mock server and mock client, it is certainly possible to build a respectable Flash application that uses some form of Remoting.

The primary alternative to Remoting is XML, which is extremely easy and increasingly efficient to parse in Flash, especially when using the Visitor pattern. XML inherently brings the following benefits:

• Easier/Faster Debugging: Because it is human readable, XML gives us the ability to instantly recognize where a problem exists in the communication layer of an application.


• Promotes Loose Coupling: It more effectively decouples the server from the client. We have options available (like XSLT) if there is a minor change to the server and we don't want to change the client.


• Verifiable Serialization: With XML, we can quickly see exactly what data is being used to create our objects and exactly what data is being sent from them. In contrast, Remoting serialization automates, and subsequently hides this information.


• Simpler Mock Services: XML lets us build a local human-readable, easy-to-modify mock server that runs from the hard disk with no other installation dependencies. Server developers can also build very simple mock clients so that their applications can be built and tested independently.


• Helps Prevent Miscommunication: It facilitates extremely clear communication about data formats between the front-end and back-end developers.


• Easier to find Developers: It's MUCH easier to find someone who can read and write XML than it is to find someone who has experience with Remoting. This makes hiring and replacing both server and client developers a much less risky task.


• You'll need it anyway: If the back-end has any sort of mass audience, your server developers will most certainly need to publish at least some subset of their APIs to XML. Is an RSS feed in the spec?


• It's not going anywhere: XML is the foundation of the Semantic Web.

I think I've rambled on long enough for now. The bottom line is that I have used Remoting on a handful of projects and it was extremely painful for me. Despite those experiences, I have seriously considered using Remoting on the last two large projects that I've worked on. I am pretty sure that I'll use it at some point in the future, but I would offer a whole lot of caution before diving into a Remoting project. Whatever you do - in the words of the immortal Flavor Flav, "Don't, Don't, Don't believe the Hype!"


Luke Bayes
www.lukebayes.com
www.asunit.com