> following pros and cons as they relate to SOAP vs. AMF. > > - AMF requires less bandwidth > - AMF is faster to parse on the client side > - AMF parsing time grows linearly, SOAP exponentially > - SOAP is usually easier to debug > - SOAP is easier to extend server side handling > - SOAP is more widely supported by server and application vendors > - SOAP is open and well documented > > Any one else want to add to that list? >
The only extreemly important things you left off are that - AMF requires the use of the FlashGateway and linking your POJO code to the FlashGateway libraries (such as Gateway class to get references to the HttpRequest etc) - AMF is not interoperable with third parties like SOAP would be. If I could sum up my point through this whole discussion as succinctly as possible, I want to get across that these decisions should be driven by your enterprise architecture. They should not be driven by blanket statements like AMF & binary protocols good and fast, SOAP and XML slow and bad. No IT topology answer is that simple. Each has their advantages, each alligns differently into your overall architectures and requirements. In the end, you should make an *informed* decision. Experiences from folks that have deployed enterprise class Flex applications into production should be a gold mine for those working on doing the same in the future. -- Dave Wolf Cynergy Systems, Inc. Macromedia Flex Alliance Partner http://www.cynergysystems.com Email: [EMAIL PROTECTED] Office: 866-CYNERGY x85 > The best public performance information that I have seen is from FlashOrb: > http://www.flashorb.com/articles/soap_vs_flash_remoting_benchmark.shtml > This is slightly outdated since the release of Flash 8. The memory leaks > the article mentions have been addressed in later versions of Flash 7. > > An important distinction between the FlashOrb benchmarks and the ones > Anatole posted are that these are comparing SOAP and AMF from within the > Flash Player. I believe Anatole was comparing AMF in the Player to SOAP in > IE. > > Another part of the discussion was some excited comments about something > called E4X or ECMAScript for XML. This is really only a new syntax for > traversing and writing xml. Kind of a Actionscript meets XPath thing. I > would also expect that the rewriting of the Flash XML parsers will bring > some dramatic improvements to performance. For details on E4X check out the > ECMAScript 4.0 specifications. > > Kevin > > -----Original Message----- > From: Robert Thompson [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 22, 2005 7:44 PM > To: flexcoders@yahoogroups.com > Subject: Re: [flexcoders] Re: Open source AMF solutions that work with flex > > Would either of you mind giving people like me a > one-liner and perhaps a url to an introduction to the > issue you are talking about? > > It sounds quite interesting, but I'm afraid I'm lost. > > -r > > --- Anatole Tartakovsky <[EMAIL PROTECTED]> wrote: > > > Kevin, > > We had performance as a priority as weel . As a > > result we went further > > in reduction of metadata in packages by generating > > client-side proxies for > > all server-side methods thus giving much smaller > > footprint then SOAP or AMF. > > That was really minor improvememnt though - main > > benefits were in ability to > > extend the set of basic types to framework specific > > data types. The real > > performance issues start with thousands of rows in ( > > im most cases) > > relational format. AMF goes to some extent in those > > (and I was very pleased > > with performance results) but final performance is > > going to depend on > > ability to search, filter and render portions of > > information. Moreover, when > > you apply changes to those you need to "remember" > > old state and some other > > info - XML allows you to extend itself for "data > > aware framework" eathier > > then arrays. > > I can only relate to my benchmarks. Here is what > > I observed for 20K > > rows/5 columns result sets on the same client/server > > platform: > > > > Flex 1.5 - 11 seconds to see datagrid - AMF > > Proprietary AJAX with IE/MicrosoftXML as a data > > model using GZip/ > > JavaScript+htc for rendering - 8 seconds > > (compression ratio of XML was 94%) > > Java front end with XML to Java Arrays - 43 seconds > > Java front end with RPC to Java Arrays - 9 seconds > > > > While I have no doubt that ActionScript model is > > more efficient than > > Microsoft's requiring recompilation of JavaScript on > > each screen invocation > > the MSXMLparser seems to provide better performance > > then (binary > > protocol+object instantiation). > > > > I am really looking forward to Flex 4 / E4X > > implementation, especially > > in MM would be able to provide comparable or better > > performance/features on > > parser level or use native ones for the appropriate > > platforms. > > > > > > As far as abstacting code - most of long term > > developers are likely to > > generate most of the server interface code with > > automated tools that would > > export both data structure and methods signatures. > > We have ones that > > generate wrappers for both WebServices and SQL > > statements generating both > > server and client code. That generated code is > > already outside of the > > "client" code and is referenced by name only. If > > that approach is of > > interest by the community, we could open source it > > and turn it into plugin / > > make sure that methods and their signatures are > > exposed in the > > FlexBuilder/Eclipse providing much better > > development environment. > > > > Sincerely, > > Anatole > > > > > > ----- Original Message ----- > > From: "Kevin Langdon" <[EMAIL PROTECTED]> > > To: <flexcoders@yahoogroups.com> > > Sent: Saturday, October 22, 2005 10:08 AM > > Subject: RE: [flexcoders] Re: Open source AMF > > solutions that work with flex > > > > > > > Anatole, > > > > > > 1. Yes I am very aware of how Firewalls and > > Proxies can wreak havoc on > > > binary streaming protocols. AMF is not a binary > > streaming protocol, its > > > simply a stateless HTTP POST of data. If a > > firewall can't handle AMF then > > > it will likely have problems on things as simple > > as multi-part form POST. > > > > > > 2. This is a mute argument. Your standard AMF > > packet is smaller than a > > > similar SOAP envelope. Yes, if you GZIP the SOAP > > it will be comparable to > > > the AMF packet. But you can also GZIP the AMF and > > then it is that much > > > smaller yet. > > > > > > 3. Your talking about the speed on the server > > side. The issues are in the > > > speed of parsing on the client-side. The simple > > truth is that it will > > > always take longer to parse XML compared to a > > binary protocol. In one I > > > have a string that I need to check every character > > for a tag close. In > > > the > > > second I have two bytes that tell me exactly how > > many characters to read > > > in. > > > > > > I think there are many times when SOAP is a better > > solution than AMF. > > > SOAP > > > has much better support and community around it. > > Its much easier to > > > debug. > > > When dealing with 3rd parties SOAP makes much more > > sense. What I am > > > arguing > > > is that if performance is your top priority, AMF > > is a better solution. > > > And > > > I don't think that its relationship to SOAP has > > anything to do with Java's > > > relationship to Assembly. > > > > > > It is not difficult to abstract your code in a way > > that allows you to > > > easily > > > toggle between SOAP and AMF or even have both > > working in parallel. It is > > > worth the effort to do this to ensure that you can > > benefit from both > > > protocols in different situations. > > > > > > Kevin > > > > > > -----Original Message----- > > > From: flexcoders@yahoogroups.com > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of Anatole Tartakovsky > > > Sent: Saturday, October 22, 2005 9:54 PM > > > To: flexcoders@yahoogroups.com > > > Subject: Re: [flexcoders] Re: Open source AMF > > solutions that work with > > > flex > > > > > > Kevin, > > > I do not think Dave needs help on this one as > > he obviously is expert in > > > this field. Just let me note that Dave's > > experiences were independently > > > seen > > > in our apps as well as we were doing a lot of > > proprietary remoting over > > > HTTP > > > in the last 7 years for RIA type of applications. > > Here are the results: > > > 1. Firewalls will through some problems. Much > > more will come from proxy > > > servers. HTTPS/keepAlive bugs in apache and clones > > will add theirs. There > > > are bugs in URLMon ( Microsoft module that handles > > HTTP streams) with > > > handling large compressed streams that will make > > you loose your sleep. > > > You > > > want your protocol be as much debuggable and > > configurable as possible - > > > preferably on per client basis - to be able to > > send data differently to > > > Japan or New York. > > > > > > 2. GZip is a huge win for relational type of info > > (DataGrids and lists). > > > AMF > > > Remoting does not remove metadata info - and with > > GZip the package size of > > > XML output should be comparable. > > > > > > 3. Main difference in the speed is in the way AMF > > "optimistic" approach > > > works. You send request to the server and it tries > > to introspect Java > > > classes and find best match (by doing comparison > > of all methods > > > signatures) - and all that is somewhat optimized > > and cached . Obviously > > > all > > > metadata - including field names and types - > > travel with the package. When > > > it comes back - the same deal here - either it > > uses packet metadata to > > > create dynamic object or reconcile it with > > registered class. > > > === message truncated === > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
