|
AMF is faster in 3 fundamental ways:
Web Services are dependent on XML Parsing on both the
client and server side. Although it’s a good story, XML parsers are not
very efficient as parsing documents is an interpreted process. The Flash Player
XML parser will always be dramatically slower than AMF parsing, binary formats
are notoriously faster in this regard. XML parsing additionally decays rapidly as the file size
increases. Flash Player XML parsing time increase non-linearly with larger XML
documents. With AMF parsing times are linear with data size. The XML decay can
be attributed to the number of inner objects that need to be created during a
parsing run. AMF objects are 1:1 with the data received where XML data is 1:N
per Elements/Attribute. Comparing XML to AMF is an unfair race, AMF wins every
time. When you add in the overhead of WS SOAP parsing atop the base XML parser speed
you begin to see performance issues. With SOAP, you interpret an XML document
back into typed objects depending on the SOAP specifics used. Sure 350ms is ok
once or twice, but try doing 200 transactions in this format and you will see
performance issues arise. Using Web Services you are forcing the Flash Player
to do allot of unneeded work. The goal is to build richer applications, not
burn up player performance in crud operations. Additionally non-proxied Web Service use suffers with
Flash Player because of the browser variation in the plug-in APIS. You cannot
get the 500 Errors response content in IE and thus the SOAP fault standard breaks
down. In SOAP there are important messages that arrive with 500 Errors and the
inability of the Flash Player to receive these is a problem. Unfortunately
there is no seamless way to get 500 Errors into the Flash Player other then
rewriting an HTTP Client in the Socket class. This effort would also require a
new SOAP library within Flex and socket use on low ports requires a more
complex crossdomain.xml configuration. Even then you still suffer the same
performance issues. Performance aside, the productivity discussion is much
more important. AMF3 and Flex Data Services are wildly productive. Once you
compile your Java Class and configure a destination in FDS (1 XML Element), you
are done. All typing is handled, All methods are ready to run with any number
of client applications. It is the easiest way to create a server side API that
I know of. Actually most cases, implementing FDS will removes $20,000 of
developer time wasted on implementing other data exchange for an application.
FDS value is easy to see when viewed through this productivity ROI metric. If
you add CF integration into FDS, you enjoy an even more productive jump. We
spend so much time talking about performance but we often waste so much developer
time doing mundane data exchange when things could be automated. Having worked at Cynergy Systems, everyone needs to
realize that Carson, Dave and Team are industry leading professionals at Web
Services. They know SOAP better than any single consulting firm that I know of.
These guys were on teams at Sybase and Microsoft building the first generation
of Web Services integration servers (MS BizTalk, EAServer)!!! They have the expertise
to make Web Services/JAVA work seamlessly with Flex but this is out of reach
for most (unless you hire them). They can jump through flaming hoops that few
developers can with the FLEX / TOMCAT / AXIS / JAVA stack. They have been down
a very hard road and have learning all the tricks to making this stack work
very well for their clients. Looking back and knowing what I know now about Flex
Data Services much of this hard work could have been dramatically simplified
and automated (but then again Flex 2/FDS hadn’t shipped yet…). FDS makes
all this hard work evaporate and makes easy for anyone to exchange data like an
industry leading professional. The really funny part is that we are only talking about
the RPC portions of Flex Data Services. Messaging and Data Management are
really valuable features to understand and explore. These two features are 70%
of the FDS product. We(Adobe) need to do a better job of making this value crystal
clear. Flex Data Services is the most productive and high
performance way to exchange data with the Flash Player. Period, Hands Down,
Next! My 2 cents, Flex Evangelist Adobe Systems Incorporated -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
__,_._,___ |
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backen... Martin Wood
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Jack Caldwell
- [flexcoders] Adobe? Choice of backend systems Shannon Hicks
- [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Dave Wolf
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Ted Patrick
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Martin Wood
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Tom Lee
- [Junk E-Mail - LOW] [flexcoders] Re: Choice of backe... Dave Wolf
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... James Ward
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... James Ward
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Ted Patrick
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Franck de Bruijn
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Ted Patrick
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Claus Wahlers
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Ted Patrick
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Claus Wahlers
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Ted Patrick
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Franck de Bruijn

