Many thanks for these insights! I still have some questions: You say AMF/Remoting is "Modeled on SOAP" - what was the most compelling reason to invent something new and proprietary instead of just using soap?
You stated three reasons:
- size
- speed
- asynchronous invocation
size: Did you do any experiments in implementing SOAP or XML-RPC inside flash and came up with some thing much huger than NetServices.as? Do you have any experiences, how large a SOAP or XML-RPC library for flash would be (I think the XML-support in Flash would be sufficient, whats left is the parsing of the enevlope and the Mappings into flash -arrays or objects.) Comparable libs in java can be kept quite small depending on the functionality.
speed: this is obviously a SOAP-Problem that has nothing to with Flash; binary formats have less overhead and better support for compression - anyway, even bigger companies like MS move away from binary formats - was there some flash-specific reason to use a binary format? The size-difference between a message in binary-format or as XML becomes the more relevant, the bigger the Data-Chunks become - but i doubt, that a design that forces a Flash-Client to read huge piles of data is efficient anyway: So the main-case will be small to medium-sized chunks - do you have any experiences with the size-difference between the AMF and a SOAP/XML-RPC based format?!
asynchronous-invocation: I have a general Question about the asynchronous nature of the Remoting calls: With remoting, you generally call components with synchronous methods (e.g. a Method on a Session-Bean always works synchronous) - but in the Remoting-Calls, the invocation and the result is decoupled ( via service.callMethod and an onResult-handler): Where does this transformation synchronous to asynchronous take place? Does it happen in the gateway? Or is it part of the NetServices.as and happens in the Flash-Client (in much the same way the XML.sendAndLoad(....) transforms a synchronous call to a asynchronous) . If it happens in the Client, is there any conceptual reason, that the very same mechanism schould not work with XML-RPC or SOAP? Shouldn't it be possible to build this with XML.sendAndLoad?
Using XML-RPC/SOAP for Remoting instead of AMF would have had the obvious advantage of being more standards-compliant: You could have other clients than flash connect to the very same Webservice without any changes, and Flash could connect without the necessity to (buy&) install a gateway. Using SOAP allows you to debug the receiving site with tools of your choice: There exist numerous products out there that can intercept, parse and visualize SOAP-Messages, and they usually integrate quite well with the development-enviroment of the receiving side. The efforts, to reverse-enginner the AMF (thx to musicman) clearly show a need to integrate with the server-side without a gateway. Apart from the price (which sould not be relevant to a site that really needs it, as there exits numerous other ways to connect to server-side applications without remoting) - the gateway introduces another element that has to be managed, integrated and understood (and another possible cause for errors): Which may prevent Organizations that already have a well established Webservices-Infrastructure from connecting to Flash-Clients...
To sum it up: I really like the ease of use Remoting offers, but i still have not understood, why Remoting is not standards-based....
Topic: Flash Remoting - a technical explaination and resources (Read 5868 times)