So I've been reading up a bit on Flash Remoting, webservices in general and stuff like that. What snapped me off was that you either need Cold Fusion to flash remote easily, or write your own XML accoring to Flash Remoting protocol. Other standard webservices are not supported by Flash unless you write your own xml receiver/transmitter for it. At least, this is what I got from all of this so far.

So, to get my own webservice running in PHP and Flash (or rather RPC server, Remote Procedure Call), I've written a very simple remoting protocol. It supports only strings, but that can really contain anything when you use serializing (if you want to transfer Objects from flash or something). I'm very happy with how it works, so I thought I'd enrich your life with it as well

source: PHP RPC example server & Flash client
should be ready to run right away

What I did was enable flash in such a way that you can call methods in flash that are executed on the server. This way you don't need to concern yourself with sending and loading php pages yourself, you just call the method and use whatever values the webservice returned. This on its own isn't such a big deal (it's been done before), but the simplicity of the passed and received XML is why I think this is much more accessible and usable by a flash developer, or anyone really that doesn't have a strong programming background. It's lightweight compared to other available solutions out there.

This is how the remote call looks like in flash:

// setup rpc client
import rpcclient.*;
var rpcservice:String = "http://localhost/ultrashock/rpc/server/rpcserver_example.php";
var server = new ExampleServerStub(new RPC(rpcservice));
 
// perform the remote procedure call and handle the response
server.doTest("test stringy", showTestResult, null);
function showTestResult(answer:RPCAnswer, params:Array):Void {
    trace("test ok: " + answer.ok);
    if (answer.ok) {
        trace("result: " + answer.data); // should be "test stringy"
    } else {
        trace("test status: " + answer.message);
    }
} 

I typical server response looks like this:

<?xml version="1.0"?>
<answer>
  <status>OK: some explanation provided by called method</status>
  <result><![CDATA[whatever result the called method gave back, can be xml!]]></result>
  <method>the called method, for debugging purposes</method>
</answer>

This is interpreted by the RPCClient class and converted to an RPCAnswer object, which is passed to the callback the user specified when making the remote call.

Here's all the available properties of the RPCAnswer object:

// answer: formatted server response
// params: the method params passed to the server
// data: whatever extra data was specified when calling the function
private function callBack(answer:RPCAnswer, params:Array, data:Array):Void {
trace("methodcall successful: " + answer.ok);
trace("methodcall status: " + answer.message);
trace("methodcall returned result: " + answer.data);
// this prints out the server's response like in the code above
trace("methodcall raw response: " + answer.rawdata);
} 

A more general approach to handling the answers could be like this (these functions are also in the source files):

// setup rpc client
import rpcclient.*;
var rpcservice:String = "http://localhost/ultrashock/rpc/server/rpcserver_example.php";
var server = new ExampleServerStub(new RPCClient(rpcservice));
 
// perform a call
server.doTest("test stringy", handleAnswer, showTestResult);
server.doRandom(15, 25, handleAnswer, showRandom);
server.doInvalidFunction(handleAnswer, null);
 
// handle the calls to generally check for an error
// you don't have to use this, but I found myself checking answer.ok
// in every single answer handler, so I made this function
function handleAnswer(answer:RPCAnswer, params:Array, handler:Function) {
    if (answer.ok) {
        handler(answer, params);
    } else {
        trace(answer.message + " (method '" + answer.method + "')");
    }
}
 
// displays the string returned by the server test
function showTestResult(answer:RPCAnswer, params:Array):Void {
    trace("test result: " + answer.data); // should be "test stringy"
}
// displays the random number returned by the server
function showRandom(answer:RPCAnswer, params:Array):Void {
    trace("random number: " + answer.data); // should be between 15-25
}
 
 
/* output:
*   test result: test stringy
*   random number: 16
*   ERROR: unknown function (method 'doInvalidFunction')
*/ 

Here I used the extra data parameter to specify which handler should handle the answer if the answer is ok (so no error occurred).

Now ok, random numbers on the server is pretty weird. But it's only to illustrate how this works. Imagine you need to store/fetch articles that are xml files or something. You can very easily do this with this server. In fact, I've been using this behind a hobby cms project I'm working on. It's very satisfying to work with php consistently like this, instead of hacking my way through the server response. Also debugging is a consistant operation now.

you probably think I'm mad by now, so I'll stop rambling now. Let me know what you think

XML is the glue of the future.
"Alkland's in Jeamland," I said. "Do you know what happened? I fell awake."

[flashext]

hey Codemonkey it seams that your download link is broken.

[InfinityI]

LOL, did i just see that, a moderator posting a link to his localserver. Wow. . Great article though .

[Tcoz]

On Windows, .Net webservices are insanely easy to set up. You can download the Visual Web Developer 2005 Express Edition for free and have one up and running in as much time as it takes to File...New...Project...C# Web Service. The Flash code is similarly easy, examples are provided all over the web. In fact, the book Flash MX Professional exclusively uses .Net web services, as do many others, because they are so incredibly simple to set up and use from Flash.

The open source Flash remoting gateway, Fluorine, is also very simple to use if Remoting is your thing. I have an example of the setup and use posted on my website, www.tcoz.com, in the code bits 'n bytes section (lower left). The protocol used by .Net (and the MM commercial product) remoting is AMF, you never get involved with messing with it though.

In addition, Fluorine, and .Net Web Services, remote many Flash objects natively, and you can map user object types to the serializer. For standard use, you never worry about the protocol, the listeners, or anything.

Another more sophisticated option that offers bidirectional communication (as opposed to web service and remoting stateless send/receive), and my preference over FCS (which as far as I'm concerned doesn't really have any use anymore) is XMLSocket. If you don't have the means to write a socket server though, you can grab ElectroServer, which has an integrated Flash object that makes calls fairly easy. I'll also be making a lightweight .Net 2.0 socket server available in a couple of weeks (already running but want to ensure it's stable and clean).

Tons of options these days.

[Codemonkey]

Originally posted by InfinityI
LOL, did i just see that, a moderator posting a link to his localserver. Wow. . Great article though .

ha, I forgot to replace local host with my server's address. I had to test it you know

@Tcoz
All options you mentioned require the user to run on windows, buy IIS/.NET, or write their own server. Like I said, I'm trying to not intimidate smalltime users that don't have a strong programming background, but still like a way of consistently communicating with their server, including debugging errors.

[Tcoz]

ElectroServer runs on many platforms (it's java) and is free for 20 users, .Net is free, VS Express is free, IIS comes with XP Home/Pro/2000. VS Studio also comes with an integrated dev server that does not require IIS...AND you get SQL Server Express Edition for nothing as well. VSExpress is community based and targeted at the neophtye, but is suitable for advanced users as well. No cost here at all. It is so popular people are writing books on using this tool, and VS.Net Commercial sales are falling (which is fine, they lost money on it anyway, only the heavy duty Windows dev really needs it anyway). The tools are actually pretty unbelievable (though I still prefer mySQL, and am a total Flash Eclipse nut).

Communication debugging is generally done through the NetConn debugger (free, it's already in your Flash 8 first run WindowsSWF directory), and your dev tool attached to your server side process (for debugging the web service or remoting dlls, or socket server runtime) The great thing is, you get real runtime debugging, not just exception traces in the browser a la scripting flavor du jour.

Regarding windows, yes, but if you own Windows already you more than likely have everything you need to set up a web service in 10 minutes (including the time it will take to download VS.Net C# or VB Express). On any other platform, Eclipse has a great web service project.

Not trying to knock your suggestion Codem, but you did say that "What snapped me off was that you either need Cold Fusion to flash remote easily, or write your own XML accoring to Flash Remoting protocol. Other standard webservices are not supported by Flash unless you write your own xml receiver/transmitter for it.", and that's really not so; I've had the good fortune to get paid to explore many options, nice to be able to spread it around some.

[bambi]

...you either need Cold Fusion to flash remote easily, or write your own XML accoring to Flash Remoting protocol.

i don't know if it's what you mean (probably not) but remoting isn't XML. it's a binary messaging protocol called AMF.

anyway, i don't think anyone mentioned http://www.amfphp.org the PHP solution for remoting, which is insanely easy to use.

[Tcoz]

There is also openAMF for java remoting. Not so insanely easy to set up, but after that, works like anything else.

[Codemonkey]

Ok, so it's free. I still don't like being cornered to using Microsoft stiff though, or using tools other than flash and a notepad with highlighting to write php if I don't have to. I don't think a lot of people who are just doing something very simple in php and flash are feeling comfortable with using yet another editor like VS. I've used it, you've used it, but we have a programming background, most flashers probably don't.

I've done a number of projects with people who are just doing their thing, barely manage to get their php running for their flash movie. Or some designer that wants a menu system built from xml, or store/fetch articles from a server. I know I wished I had thought of writing what I've written now, in just about an hour or so. It would save me time and headaches figuring out which sql query failed this time... and I'm sure there are lots of people who could really use this.

[Codemonkey]

Originally posted by bambi
i don't know if it's what you mean (probably not) but remoting isn't XML. it's a binary messaging protocol called AMF.

anyway, i don't think anyone mentioned http://www.amfphp.org the PHP solution for remoting, which is insanely easy to use.

Yeah I know, I was confusing things I guess. I know I got fed up with the lack of cohesive information when I wrote this little thing.

[Codemonkey]

actually, isn't AMF encoded in XML? I'm not sure what to make of http://amf.openlib.org/doc/ebisu.html otherwise

[bambi]

nope, that's not it. i could swear i'd seen the AMF0 spec somewhere in the form of a pdf but i can't find it now. someone has reverse-engineerd AMF3 here: http://osflash.org/amf3/index

the nice thing about AMF is that it kind of works like XML, but the envelopes are tiny, parse much faster.
you can receive built-in and custom classes classes in flash through remoting (you can in XML too, but with a LOT more processing overhead).

[Tcoz]

Correct, AMF is not XML compliant, unlike SOAP. It is optimized for transmission and does not have the overhead of extensive schema incorporation and such. Not unusual at all for any binary technology, where data transmission is expected to be far more frequent, as opposed to web services, where you are expected to intelligently package up, and return, as much data as possible when a call is made.

Great stuff.

[Mike]

Well even with binary remoting, the use of remote facades would still be good practice as calls still cost (all be it not as much).

An XML endpoint does have the advantage of being manipulated by any interface you wish to plug onto it, now or down the road. Whereas Using a proprietary protocol like AMF could just lead to another area of maintenance.

Actually I do wonder in most apps if the processing of xml makes a huge difference to the end user experience? Is there a noticeable slowdown which would make a user walk? Surly if the data is fed sensibly to the interface (good pagination etc.) this would not be an issue.

I'm thinking a flash interface plugged into a RESTful architecture could be a great option & remain easy to update years down the road.

Anyway nice post CM

Hey Nutrox did you post something along these lines a few months back?

[bambi]

i usually use XML for the reason mike describes.

if you build you application in such a way that you can load data in small pieces when it's required, you avoid hangups when processing large XML documents.

anyway, i think i derailed

[Codemonkey]

ugh, you guys are way boyond me. I should've done my research before posting this. I think I missed the mark with this thread

[Tcoz]

If you need near realtime data processing of say, thousands of nested objects for a complex UI, you will see a HUGE difference if you use XML (as in, a huge perf hit). Believe me I know this the hard way. The leaner and meaner, the better; remoting means you are looking for speed.

That is a proven inverse proportion; > flexibility = < speed. Not very visible for your typical remote data needs, but try doing an online game with frequent positional updates or real time network monitor with XML...nuh uh, especially not in Flash, which is notorious for slow XML perf (better now, and moreso in Flex). Just gimme an ASObject (preferably something typed, but again, mapping = perf hit. ASObjects are native and reasonably fast).

XML, when you build out serialized object trees with references to parents, can get prohibitively large. Keep in mind, I see a lot of people use remoting just because they think it is an "elite" technology and so on, when in fact they could actually use loadVars from a PHP script with the same results.

Remoting is for heavy duty work, enthusiasts, or people with very specific protocol needs. 95 percent of the flash projects I see that use remote data don't do more than an init grab or a periodic poll/update. Almost any technology can manage that.

[bambi]

i don't think you missed the mark, necessarily. one of the problems with things like SOAP is they're very verbose in order to handle a broad range of conditions. your requirements in flash are smaller, so you can write an RPC-like package that uses looser, smaller XML documents.