> serverside deserialization of said webservice to native ActionScript
> whereas the webservices API is a clientside deserialization of the
> compressed web service soap.
That isn't entirely true. Yes, if you want to consume an actual web
service then you can use Flash Remoting to do it for you or you can
consume the web service directly assuming it is on the same server.
However, if you use Flash Remoting you might not need to consume a web
service at all. For example, with Flash Remoting you can make use of
Java classes or CFCs on the web server directly i.e. Flash Remoting
invokes the Java class or CFC without going through a web service
layer. This means that Java types are directly serialized into AMF as
opposed to being serialized to SOAP and then to AMF.
Now if you do actually use Flash Remoting to proxy a web service then
that web service is delivered to Flash via AMF; not SOAP. Thus, there
is a difference in performance on the server-side when you use Flash
Remoting to proxy a web service, but not on the client-side. Again
though, you can avoid that proxy step by no using Flash Remoting at all
and allow Flash to consume the web service directly. This means more
work on the client-side and less work on the server-side, which of
course should be the desired result. The only undesirable result is
long wait times on the client-side for large payloads. And again, AMF
produces smaller payloads than SOAP, but using HTTP compression with
SOAP fixes that issue too. So in the end, using SOAP and HTTP
compression means that you reduce the amount of server-side overhead,
have similar payload sizes, but increase the amount of client-side
overhead.
> The actionscript webservices api uses the
> built in xml classes in the flash player to parse the soap whereas the
> remoting gateway does this process for you.
Again, only when the gateway is proxing a web service. If it has direct
access to the class then there is no need to go through the web
services layer.
> The http compression thing
> is completely unrelated to the respective implementations-- in other
> words it would benifit both but remoting would still ultimately be
> faster because it is a binary protocol.
Incorrect, you could use HTTP compression for both protocols, but the
amount of work on the server-side for Flash Remoting is simply higher,
so while the payload size of AMF would be reduced further it would be
insignificant since the protocol is already pretty small.
> Thats what I mean by common
> sense.... I suppose its common sense only if you understand that BOTH a
> remoting server and the clientside webservices api can consume web
> services.
Again, it is not common sense because I understand how Flash Remoting
is actually implemented. Based on your comments you seem to have the
wrong understanding of how things work.
> You see I'm not contending that you should use webservices for
> your service layer. In fact I encourage it. I'm suggesting you consume
> those services with a remoting server if you want to enjoy a
> performance
> boost.
>
The only performance boost will be on the client-side, while you will
be occurring extra overhead on the server-side. If possible, it is
always better to place the overhead on the client-side, so scalability
is improved.
> As that a swf can only consume a service from the same domain it
> resides
> on the developer has little choice about this anyhow-- unless you have
> access to the server publishing the service / then you can edit the
> crossdomain.xml to allow access. A luxuery that somewhat defeats the
> purpose of a service oriented architecture imo.
>
Depends on how you are looking at Flash. If you look at Flash as a
client-side part of a client/server application then everything makes
perfect sense since you control the server.
-Matt
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
