|
Hi Franck,
I guess when faced with the situation of the back-end
technology with exposed webservicesis already in place and the UI having to
conform to it then that does not leave you much option then having to use
XML.
In an ideal development process for Client and Server side
to make use Value Objects as currency compared to XML is much more
efficient.
To answer your first question, these objects converted to
XML would be around the 1000 nodes mark.
Regards,
Bjorn
Schultheiss
Senior Flash
Developer
QDC
Technologies
Hi
Bjorn,
Could you provide me
some insight in how large your objects are and how complex they are? In XML, how
many lines would it be? And how many nested levels would it
be?
In the applications I
build, the XML is at the most 100 – 1000 lines, and I don’t see many problems
with it. But, if you are pushing 1000s of lines over the line, I can understand
it can become an issue. In terms of nesting I typically encounter 2 or 3 levels
(objects) deep, but not much deeper. Also this is not causing many issues. It
always depends on how you have architectured your
interface.
Probably you are in the
luxury where you can also dictate the back-end technology. This is not always
the case. Most often the back-end is already there and you just have to plug a
GUI on top of it.
Cheers,
Franck
From:
[EMAIL PROTECTED]ups.com [mailto:flexcoders@yahoogroups.com]
On Behalf Of Bjorn
Schultheiss
Sent: Friday,
August 25, 2006 8:09 AM
To:
[EMAIL PROTECTED]ups.com
Subject: RE: [Junk E-Mail - LOW]
[flexcoders] Re: Choice of backend systems - which
provides
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:
[EMAIL PROTECTED]ups.com [mailto:flexcoders@yahoogroups.com]
On Behalf Of Franck de
Bruijn
Sent: Friday, 25 August
2006 3:38 PM
To:
[EMAIL PROTECTED]ups.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
YAHOO! GROUPS LINKS
__,_._,___
|
