|
Hi Ted, We all understand your arguments 1 and 2.
But in the end, and that’s already identified in this topic, it’s
the user experience that counts. If it does not suffer by using web services,
it’s not an issue! I’d like to hear the first story that changing
webservices by AMF increased the user experience significantly and sealed a
certain business proposition. For argument 3 ‘Developer
Productivity’ it’s true that developers need to program more lines
of code to obtain the same result (having your webservice result as an
ActionScript object), which is, I admit, error prone. But in the total view of
the costs of a development project ... it will not make much of a difference.
The actual additional lines of code I’m talking about, however, are very
easy to generate from a model if you wish. Again, FDS is cool, really true and it
does have its place. But for many applications FDS (including the extra
features messaging and data management) is neither an option nor necessary. Cheers, Franck From: 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. 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... James Ward
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... James Ward
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Franck de Bruijn
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of b... Franck de Bruijn
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice ... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice ... Ted Patrick
- Re: [Junk E-Mail - LOW] [flexcoders] Re: Cho... Claus Wahlers
- RE: [Junk E-Mail - LOW] [flexcoders] Re:... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re:... Ted Patrick
- Re: [Junk E-Mail - LOW] [flexcoders... Claus Wahlers
- RE: [Junk E-Mail - LOW] [flexco... Ted Patrick
- RE: [Junk E-Mail - LOW] [flexcoders] Re: Cho... Tom Lee
- RE: [Junk E-Mail - LOW] [flexcoders] Re:... Franck de Bruijn

