OK, so I’ve watching this thread going back and forth over and over… Now it’s time for my two cents.  It looks like this thread began by someone saying that you cannot use web services in a real world flex application.  I’ve got to agree with Dave on this.  You definitely can, and we have done it numerous times here at Cynergy.  

 

Are there tradeoffs?  Yes.  As others have said already in the post:  The decision on what mechanism to use should be dealt with on a case by case basis.  Let’s consider a few things:

 

  1. Do the web services already exist and can they handle the current load?  If they do, use them.  Why reinvent the wheel? 
  2. Yes, there is a performance advantage to using AMF, but most users will not notice the difference in transport speed… it is fractions of a second.  If your application is properly architected and your backend is optimized, the end user will never know the difference.

 

I personally like using remote objects, but not every solution allows for this.  In the cases where you cannot use remote objects, web services still work great.  SOAP is a very verbose protocol, but by no means is it unusable.  If that were the case, why would web services be so prevalent?  Why would there be all the buzz about service oriented architectures? 

 

If you feel that a web service is too verbose or too slow, and you can’t use remote objects, then use a HTTPService to return XML.  There are many solutions.  It really all boils down to how you use and retrieve your data and depends on your requirements and application architecture.   If the processing time on the server is too much for your application to handle, then chances are there is a problem with your application’s back end, not the webservice/serialization layer. 

 

To generalize and say that you should never use a web service is a very big mistake. 

 

-Andy

_____________________________________

Andrew Trice

Cynergy Systems, Inc.

http://www.cynergysystems.com

 

Blog: http://www.cynergysystems.com/blogs/page/andrewtrice

Email: [EMAIL PROTECTED]

Office: 866-CYNERGY 

 


From: [email protected] [mailto:[email protected]] On Behalf Of Jack Caldwell
Sent: Wednesday, August 23, 2006 10:40 AM
To: [email protected]
Subject: RE: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backend systems - which provides

 

Martin:

 

OK . . . . so the lag time is when the data gets back to the end-user?

 

Bottom line . . . . with all things being equal . . . .

 

Does a web service request take longer to process on the server than

a AMF request?

 

If the answer is . . . . in general yes, then that can be an issue with an

increase in users.

 

If the answer is . . . . it depends on the data being requested and/or the

data format then that seems to suggest that everyone must run tests to

compare results and then test again based on scaling up.

 

Is that about right?

 

Thanks,

 

Jack

 


From: [EMAIL PROTECTED]ups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Martin Wood
Sent: Wednesday, August 23, 2006 8:13 AM
To: [EMAIL PROTECTED]ups.com
Subject: Re: [Junk E-Mail - LOW] [flexcoders] Re: Choice of backend systems - which provides



Jack Caldwell wrote:
> Dave:
>
> I agree that a 1/3 of a second is not going to be noticed by the end-user.
>
> However, when you add 100s or 1,000s of users . . . . does that make a
> difference?
>
> I don't know . . . . that's why I am asking. You guys have the experience.

It doesn't make any difference as the timings are on the client side, not the
server.

There will be some difference in time required to handle requests on the server
which may be down to the data format but they would have to be investigated on a
case by case basis.

martin.

__._,_.___

--
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




__,_._,___

Reply via email to