flash remoting - sleight of hand?

[Flash-db]

To be honest, the question you are asking is the one thing I don't really know the answer to i.e. how to create an object oriented (rather than scripted) server side element to a flash application.

I started my first real (well somewhat real Object Oriented) project a couple of days ago - this is what I came up with: http://www.flash-db.com/FlashTable/  - what it does is basically parse HTML/table tags as if they where XML (which they basically are anyways) - then draws the table and populates it.  It's as Object Oriented as I could make it - but it is not completly Object oriented.  I think as MX becomes more standard - with lots more developers we'll see some really cool things come out of it.  I found and learned quite a bit from doing the above - and realized that their is a lot of potential from MX.  Also tried to dig as deep into 'Flash remoting' as possible in the process:

I can actually see some use's for it -not many though, and nothing that can't be done with loadVars/xml.load  - And can think of many ways to mimic what it's doing.  Server side actionscript - is not really server side actionscipt - it's still client side but is just interacting with cold fusion components - so I guess somehow they came up with the name 'Server side' out of that somehow.  I could go into it quite a bit, but I'll spare everyone.

All that would be needed for basically anyone to come up with some new and improved ways of the macromedia coined term 'Flash Remoting' would be for them to release the specifications for their "AMF" format - that sends message's back and forth.  That's sort of like their hidden Key in the matter - their Tollbooth if you will.  And what their banking on.  Everything else is pretty much standard.

I've looked into some of their undocumented functions and concluded it probably won't be long before someone comes up with an Open standard for doing the same thing (or just a much better way) - I can almost put it together - But that message format is blocking the way.  (and if I can almost imagine it - then I'm sure it's being worked on by lots of others).

In Conclusion:  
Is Flash remoting Necessary - No, Not at all.  
Does it make things easier - Maybe, or Maybe not.
Restrictions: (as stated previously)  You would have to own your own server to deploy your website on - and it would be quite a bit more expensive.  Most client sites are not worth the cost of using a custom server. Those that are - well you probably won't be using Flash for whole site.

Why would you use Flash remoting: If you happen to be one of the design companies that MM sponsers  

<end ramble>

[julian]

Why is it that you have to use the AMF format? Can't you just use HTTP like in the good old days? If the answer to that is no then I think MM really have shot themselves in the foot.

[Musicman]

Hi,

one part of the 'flash remoting' hype - two very distinct concepts are sort of mixed together (honi soit qui mal y pense - you might believe they want some customers with money to spend, but lack of knowledge, buy a product they do not really want)
One is traditional - gui-based - web sites where you log into a site, then fill some html forms or use a flashy interface, and have some action done or results passed back to you (once again through html or flash interface)
The other one is web services - "something" is sending a request to a server (like a search engine, flight booking system, online bank) and gets a response back. Now it is up to the "something" to use / display the results. Since flash's security model does not allow to connect to foreign servers, all extra services that you might find on html websites (say google, stock quotes, weather forecast) have to be done via a "middle man" on your own server.
This is where web services come in nicely - their data format is designed for interacting with software rather than a human user, and it is usually documented and does not change. Contrast this with a gui website that is rebuilt every now and then. If you were using it like a service (having a script post form data to it and extracting results from the html page that comes back), most likely your script will need to be changed.

Now, if you are making a traditional site, just make it the same way you ever did...
If you think that your site could be a useful service as well (say you are selling goods nd anticipate that business users might want to order straight from their own business software) you should perhaps consider a design that consists of separate web service nd user interface layers.

As for simply passing variables around - there should be some code, probably at layer51.com, that serializes / deserializes a complex flash object. Using such code as a component, it should be possible to build systems that just transfer a structured variable from frontend to backend and vice versa. This does not seem to be different in concept from amf or even xml

Musicman

[psychlonex]

Hey all - good to see this thread back after a good break. Hopefully everyone has been doing well, and that we've all had some time to learn more!

My latest take on remoting is that I still like it, I'm praying for a stand-alone server, that will run on apache's tomcat. It's already been done by a few, but mm hasn't officially supported it yet. My point is that since Apache seems to be the most popular web server, it's bound to happen. Even without mm's approval, if it works, people will probably use it anyway.

That's a bit off topic, a few other things I think are good reasons to use remoting, or at least that the idea is a good one:

I've always stayed away from using xml unless I was using it with the socket server, in which case the xml docs being sent back and forth were fairly small. Whenever I tried to load anything fairly large, the player would freeze up for a few seconds while it parsed the data. This is really, really, really bad from my point of view. One thing I've always tried to do with my flash projects is to make them run smoothly even on my aging powerbook (which also is my dev machine!). One of my biggest complaints from clients is that it runs too fast on their pc's!!

If I was able to directly connect to a remote web-service, I think I'd be all for using an xml solution, but since I can't (security restrictions!) I have to connect to a server in my domain, which in turn connects to the service and returns the results.  At this point, I'd rather not do anymore parsing/processing. By the time it gets back to flash, I want my data to be ready to use! This is where remoting comes in, my data will come back as an object, ready for use in my flash.  

I guess that's about it, my point being that no matter what, If I want data from anywhere outside my flash movie (with the exception of text files) I will need something additional running on a server in my domain. PHP would be the first choice, but if that's not available, my second choice would be a remoting server with their choice of j2ee/database combination. At least then I'll have a good idea how to use it, and should they really want to use that one component, It'll already work with it.

Psx

[aversion]

so, as musicman states above, in my case web services would not be an issue, since i will only be communicating with my own db (at this point) and would not require data from external sources. I'll simply be making calls to a server side script that queries the db and returns data.

i do own my own server box but my application will be installed on client's own servers (they can host with us but most big companies will want the security of keeping all their project data on their own servers) and so installing CF on all of them could be impossible and damned expensive.

flash remoting remains attractive because, as you guys have mentioned, you receive a well formed data object ready for flash to use,  but it's annoyed me how so many things i've read have been pushing CF and cold shouldering PHP... take a look at the new riders book 'inside flash mx', PHP is treated like a poor cousin to ASP and CF.

I will persist with PHP and explore the world of loadvars, and examine the progress of object oriented server side element for a flash application,  it sounds like this is something that a  lot of people would find useful and hopefully there will be a solution forthcoming. I'll take a look at layer51.com and any other links to sites pushing these concepts will be welcome, i'm really pretty new to this stuff  

thanks again for your help.

[Robin Hilliard]

The reason Flash Remoting needs the server component is because Flash applications are only allowed to communicate with the server they were downloaded from for security reasons.  This applied to existing server connectivity features (loadVariables, XML), same applies to Webservices from Flash.  If Flash applications could connect to any server, then a Flash movie downloaded through a firewall could fish around looking for servers to connect to, grab info over http and retransmit to the server it came from.  Nothing diabolical about it.

[Musicman]

Hi Robin,

flash's security is one reason to have server scripts. The other, more important one: everything inside the movie can be seen by people who are just curious, so business logic, database passwords etc. certainly should be kept on the server rather than inside the movie.
The question here is - do we need an extra data format besides the usual var=value&var=value and xml formats? In particular this extra data format seems to cost $xxx and will not be available on standard servers while the other formats can be handled on any cgi or php enabled system.

As of F5, there was protection against malicious movies spying around in intranets, but it was well possible for a malicious movie to spy at the visitor. This hole has been plugged now.
In rare situations you can still use movies to attack internets (but they would probably involve insider knowledge - say a programmer has been fired by a company and then makes a "must see" movie specifically for them)

[stf]

Maybe we should try to bring flash down to earth again: It's just a client-Gui. That's a lot. But BusinessLogic has nothing to do in  GUI. I remember with horror those crappy Visual Basic-Frontends that mixed View&Presentation to a point where you often could not change the background-colour without breaking the Logic of the application (of course none of the people on this board code as bad as a common VB-Programmer8) ).

So in some way, flash MX is a dangerous step, as it empowers the gui to a level where you drop hide all sorts of business-logic inside - where it gets lost un-reusable for all time.  So the question, if Flash should handle WSDL directly or just connect to a server-side-component that "hides" the existence of a Webservice, provides caching mechanisms, security, webservices Choreography and so on, really comes down to question of partitioning business-Logic. I don't think that it is even useful, apart from minor sample applications to place the burden of accessing webservices on the front-end gui. In the State Flash MX is now, I think it is more than useful to keep simplify the access for the gui using remoting: It hides away the complexity of Webservices (and believe me, they are complex and will even grow more complex with things like security, choreography, transactions on the horizon), and speeds up the access by using a binary format...  

I don't think that Flash is anywhere near to being a full-fledged stand-alone enviroment for accessing webservices, and I don't think it will arrive there in the near future...

[drZoode]

Sorry for the slightly OT post,
but about the security issues in Flash Remoting, I have just learned that *gateway hijacking* was possible:
http://www.flash-remoting.com/notablog/home.cfm?newsid=14
http://www.markme.com/mesh/archives/000377.cfm
..seems like Flash client can use somebody else's gateway and steal the bandwidth.

[eyenine too]

Ahhhh.

I'm so glad I found this thread. I too am considering Flash Remoting with ASP.NET but have detected something fishy about this. I have tried various options to consume a web service using Flash as the front end, but have met too many obstacles. Consider the following HTTP request template to send XML data through SOAP into an ASP.NET application:

POST /ws/servicename.asmx HTTP/1.1
Host: irqnine.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://irqnine.com/ws/ActionName"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
   <ActionName xmlns="http://irqnine.com/ws/">
     <Field>int</Field>
   </ActionName>
 </soap:Body>
</soap:Envelope>

The only differences between this and a normal HTTP request string are the SOAPAction header, Content-TYpe and an XML document as the body. There is a documentation on this as a workaround listed on Flash MX release notes that allows header addition and overriding (XML.addRequestHeaders) to allow Flash to communicate through SOAP. But it doesn't work... I examined the raw HTTP request string and the HTTP headers remained intact.

There was also another way to deal with SOAP, and is designed for Flash 5 - the free Flash SOAP component develop by MediaRevolution, as discussed by this DevX article - which unfortunately is not available anymore... weird.

So there's really no way of doing this, other than writing a server-side script acting as a middle man.

My 2 cents after 12 hours of continuous research.

[pixelbath]

One problem I've noticed in this thread is the tendency to confuse Flash Remoting with SOAP and Webservices.  Specifically, Flash Remoting is the term used by Macromedia for their proprietary system, the Action Message Format (AMF).  AMF uses HTTP, but instead of sending XML it sends lightweight binary data (and since it's a proprietary format, can encapsulate AS objects without changing types).  Good in theory, but I wouldn't suggest it to anyone using MS technologies (yes, I know AMF for .Net exists, but I cannot comment on how good/complete it is).

SOAP is an open protocol, and can be consumed by Flash Web Services.  In my experience though, it's the consuming of standard web services where Flash falls short (as of version 7).  I can use the internal Web Service browser, and Flash will consume it fine, but when actually using Actionscript to do so, I'm forced to process it like normal XML using XPath and firstChild methods.  That's my real question to Macromedia: how can one part of your application work fine, and the implementation of that technology for developers fall horribly short?

Given that every example I've seen uses the WebServiceConnector component to bind to other data-aware components.  That's all well and good for people looking for the "out of the box" solution and don't care as much about overhead in their final application, but for the rest of us who write everything from the ground up it's incredibly frustrating not to see any examples of the "official" way to consume a web service in Flash.  Maybe it's just me though, because I've seen other examples working fine, but when using the same code on our .Net web services, I get nothing (or have to manually parse the return XML).