" In the cases where you cannot use remote
objects, web services still
work great"
Andrew, do you have any examples when one would not be able to use
remote objects? I am interested to know if you have any technical
reasons, rather than just economical.
Cheers,
Mark
--- In [EMAIL PROTECTED]ups.com,
"Andrew Trice" <andrew.trice@...>
wrote:
>
> 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: andrew.trice@...
>
> Office: 866-CYNERGY
>
>
>
> ________________________________
>
> From: [EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On
> Behalf Of Jack Caldwell
> Sent: Wednesday, August 23, 2006 10:40 AM
> To: [EMAIL PROTECTED]ups.com
> 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:[EMAIL PROTECTED]ups.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.
>
