RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backend systems - which provides

[Bjorn Schultheiss]

Hi Franck,   Although your post was directed at Ted my opinion is that for UI performance, transferring XML is just too slow. Having to construct XML on the server, send it and then parse it in Flex is just too much hassle without any benefits over the AMF. The main attraction of AMF3 for our company is being able to maintain complex typed object structures without any parsing when communicating between JAVA and FLEX. The UI response time is also a huge plus when dealing with user interaction, XML is just to cumbersome. Development time is also greatly reduced, provided the technology works, which seems to be the case with AMF3 as opposed to AMF0 which we faced all sorts of issues when pushing it to it's limits.   Regards,   Bjorn Schultheiss Senior Flash Developer QDC Technologies   From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Franck de Bruijn Sent: Friday, 25 August 2006 3:38 PM To: flexcoders@yahoogroups.com Subject: RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backend systems - which provides Hi Ted, At the risk of offending you ... the more people shout, the less I listen to them. I totally agree with you (again!) that FDS is much more than just remoting. And if the solution requires the other features of FDS (that webservices cannot provide), FDS is a good option to choose. Pricing might be an issue, but in the area (financial services) I work in, I don’t expect it to be a real issue. If the requirement of your software project is indeed to support client PCs from the previous century, of course you need to check what the user experience is on those machines (again: that’s the only driving factor). For me, this does not apply, since the applications I build are 90% intranet applications (enterprise administrative systems); these environments normally do not have so many problems parsing an XML message. I always strive to build my solutions on standards and don’t want to rely on proprietary frameworks and tools, when I don’t need to. It gives me freedom and makes me more resilient to change. So, for the last time, in my area I don’t see the need for messaging and data management (2 of the 4 major parts that you mention), and so far I have not suffered from any user experience issues due to the usage of webservices (point 4). Remains the productivity issue (point 3). For that I am willing to pay the price of choosing a standard instead of locking into a proprietary framework, since I believe that it will not drive up the total costs of a software development project significantly. To your question ‘Would non-flash clients for AMF and Messaging help?’ ... I don’t think so. AMF will never become a standard like webservices are now. Pushing AMF as a new remoting standard would be a big mistake. You’d burn a lot of money with probably no success. Maybe this will sound strange now, but I am no great fan of web services. I think it is a lousy technology. But it’s the technology that the big industries are standardizing on now. And that’s the great benefit. Although the technology is lousy, it does its job. There are interoperability issues, but in due time they will be fixed. After the journey of RPC, CORBA, RMI (and other proprietary communication protocols ... I remember PowerBuilder had its own as well), I hope that web services will be the final technology that will be settled on. Then, we can start focusing our valuable time on the business at hand and not on the exchange of data between client and server, which should be something trivial. By the way, writing that last paragraph made me wonder why Macromedia did not choose RMI for the remoting protocol, but have you chosen to develop your own (AMF)? Cheers, Franck From: [EMAIL PROTECTED]ups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Ted Patrick Sent: Thursday, August 24, 2006 6:50 PM To: [EMAIL PROTECTED]ups.com Subject: RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backend systems - which provides Frank, RPC IS LESS THAN 25% OF FLEX DATA SERVICES!!! Flex Data Services is so much more that RPC. This entire discussion is really FDS.RPC to WebServices. FDS contains 4 major parts: 1. Messaging - ASMessaging and JMSMessaging 2. Data Management - Data Synchronization and Distributed ArrayCollections 3. Web Tier Compiler - Compilation of AS/MXML on the server side. 4. RPC - Remoting and WebService Proxy Using Web Services directly affects user experience!!! Using Web Services directly affects user experience!!! Using Web Services directly affects user experience!!! Web Services burns up player performance that you could be using to make the user experience better. When working in Flash Player, everything affects performance. If you abuse the player in one area, you limit what you can do elsewhere before the player starts to slow down. The Flash Player (like all software) is limited in capability; if you spend that capability doing hard things (read Web Services) then you will not be able to do other things. On a high quality machine, WS can take 400ms, but on a slower machine it can take 3-10 seconds for a single call and the larger the data exchanged, the worse it gets. Not good. With Flash Player it is important to keep things light and fast. Web Services are abusive to the Flash Player runtime. Support is included for integration purposes but it was really not designed as an optimized way to exchange data. Web Services view: Flash Player Receives XML ASCII Text XML Parsing → XML Parsing!!! SOAP Parsing occurs to AS Objects → Traverse SOAP Objects Recursively!!! Objects are passed into events RemoteObject: Flash Player Receives AMF Data AMF Binary Decoding → Direct to typed objects. Objects are passed into events I am sure there are many smart people out there who will get WebServices to work well for them with Flex. It is a lot of hard work to make this work well and I have only seen one company do it really well. I do not doubt that others will make this work reliably but I question its use. It will affect performance which is why AMF was created in the first place as an optimized data exchange format for Flash Player. One of the key advantages for WebServices is the wide availability of Web Service clients for any language. With AMF we only have one client( Flash Player ) and several AMF servers. One key enterprise objection to using AMF is the lack of AMF clients for integration. Cases: - PHP form could remote to FDS - C++ application joins FDS messaging as a client - Java process remotes to FDS - Python process remotes to Data Services for Ruby (MidnightCoders) - C# remotes data with FDS as a client Part of the distributed computing revolution is the realization that anything can be both a client and a server. One of the problem areas in FDS is that only Flash and Java:JMS can participate within the FDS as clients. Would non-flash clients for AMF and Messaging help? Regards, Ted Patrick Flex Evangelist Adobe Systems Incorporated ________________________________________ From: [EMAIL PROTECTED]ups.com [mailto:[EMAIL PROTECTED]ups.com] On Behalf Of Franck de Bruijn Sent: Wednesday, August 23, 2006 10:33 PM To: [EMAIL PROTECTED]ups.com Subject: RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backend systems - which provides 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 __._,_.___ -- 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 Software development tool Software development Software development services Home design software Software development company YAHOO! GROUPS LINKS  Visit your group "flexcoders" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___