> app
> can only access a server resource if it resides on the same server as
> the published SWF file or if crossdomain.xml allows it. If you have
> access to the server it really only makes sense to take advantage of
> the
> Remoting performance boost. Remember Remoting works with SOAP but the
> deserialization occurs on the server not the client so the issue of
> SOAP
> vs Remoting really isn't there.
>
It might make sense to use Flash Remoting, but you have to remember
that Flash Remoting is a product that costs money, so even if you have
access to the server, you will still need a license to Flash Remoting
before you can use it. On the other hand, there are plenty of server
products that have built-in support for SOAP meaning that adding Flash
Remoting to the mix will actually cost more.
> 3. I have found Flash Remoting and AMF to be more robust than the web
> service implementations I have used.��I have forced myself to use web
> services in newer projects rather than Flash Remoting just to get the
> experience, and I have found bugs in both the Flash implementation and
> in Apache Axis which caused a lot of frustration and would have been
> avoided if I had used Flash Remoting.��So far, I have not run into any
> significant bugs with Flash Remoting that I can recall.
>
> Very true.
>
Maybe true for some, but there are plenty of Flash Remoting issues that
still haven't been addressed. For example, you still can't consume
services from Java classes and CFCs in the same context as both rely on
different gateways that are not compatible. Further, there is serious
marshaling challenges for Java-based services that Flash Remoting
consumes not the least of which is corrupted objects.
-Matt
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
