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. I personally had quite a few cases when AMF diagnostics of the protocol problems required me to debug flashremoting servlet. Compared to other protocols I have seen there is no magic - just a good implementation of serialization / deserialization machanism (I might of missed something though) with very few basic types - and that is not different from any other proprietary protocol Dave is refering to. Webservices usually requre 2 roundtrips - one to get metadata and create "client proxy" and one for actual code execution. Good implementations suppose to cache the first call thus making that cost negligible. Client proxy can be made more efficient then dynamic built-in one. The benchmarks creation is a separate art form - and is too often in line to what we expect to see. If I was serious about performance I still should be coding in Assembly language. Chances are that most of us code mostly in Java or scripting environment. Personal note: There pros and cons for use of XML to serialize ActionScript objects misses the point that XML is the universe of it's own. I hope that with E4X in the core product people will gradually get in more complex data models that will move this discussion from comparison simple "POC" apps to real world ones. As you move your application towards use of stateful datasets and other large transfers you will find yourself using HTTPRequests and WebServices more often. Sincerely, Anatole Tartakovsky ----- Original Message ----- From: "Kevin Langdon" <[EMAIL PROTECTED]> To: <flexcoders@yahoogroups.com> Sent: Friday, October 21, 2005 3:55 PM Subject: RE: [flexcoders] Re: Open source AMF solutions that work with flex > - AMF is binary data passed over standard HTTP request and responses. So > you should not have any problem with packet filtering. > > - You can turn on GZIP compression with remoting just as you cand with > SOAP. That means it be even smaller. Remoting cuts out all the extra > metadata so its always going to be smaller. > > - GZIP compression doesn't improve the client side processing of the data, > it actually hurts it in a small way. This is why AMF is so much faster > than > SOAP. Flash uses DOM to parse XML, due to this you will see that the > client > side parsing time grows exponentially with the size of your data. AMF > grows > linearly. Even with small datasets AMF is much faster due to the > simplicity > of its serialization. > > Its not difficult to setup a simple benchmark test. Do this and you will > quickly see how much better AMF performs compared to SOAP, especially with > large datasets. > > > -----Original Message----- > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Dave Wolf > Sent: Friday, October 21, 2005 3:42 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Re: Open source AMF solutions that work with flex > > A few comments. > >> * Binary transport > > So is SOAP when you turn on GZIP compression in your container. And I > would > argue that binary transmission can be a bad thing too. What if a firewall > used on a corporate environment has packet filtering turned on. Does that > firewall have an AMF filter and did the firewall admin know what it was? > I > spent oodles of time working in CORBA. IIOP is a binary protocol and I > cant > tell you how often we bumped intot his issue in a true distributed > application. We actually used to tunnel the IIOP through HTTP a lot to > avoid this. > >> * 50% percent faster then SOAP or Webservice > > Not true with GZIP turned on. > >> * Automatic object serialization/deserialization > > So does XML web services in Flex. > > > -- > Dave Wolf > Cynergy Systems, Inc. > Macromedia Flex Alliance Partner > http://www.cynergysystems.com > > Email: [EMAIL PROTECTED] > Office: 866-CYNERGY x85 >> >> >> -abdul >> >> >> >> -----Original Message----- >> From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] >> On Behalf Of Dave Wolf >> Sent: Friday, October 21, 2005 12:29 PM >> To: flexcoders@yahoogroups.com >> Subject: [flexcoders] Re: Open source AMF solutions that work with >> flex >> >> I do want to know why you're prefering AMF over HTTP or WebService. >> >> Just curious on the motivation there. >> >> -- >> Dave Wolf >> Cynergy Systems, Inc. >> Macromedia Flex Alliance Partner >> http://www.cynergysystems.com >> >> Email: [EMAIL PROTECTED] >> Office: 866-CYNERGY x85 >> >> --- In flexcoders@yahoogroups.com, Clint Modien <[EMAIL PROTECTED]> wrote: >> > >> > I guess I should specify that they don't need to be open source at >> all they >> > could be 3rd party as well. (More than willing to pay for a >> > solution) >> > >> > >> > On 10/21/05, Clint Modien <[EMAIL PROTECTED]> wrote: >> > > >> > > Anyone get any open source amf solutions to work with flex? >> > > Looking into this due for the most part to the lack of amf >> support in the >> > > flex alpha release. I'm also guessing that this is what MM will >> release as >> > > the non enterprise version of flex. So I'm looking for >> > > alternatives >> to >> > > webservices and httpservices. >> > > >> > >> >> >> >> >> >> >> >> -- >> 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 >> > > > > > > > > -- > 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 > > > > > > > > > > > > -- > 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 > > > > > > > > -- 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 ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/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/
