I have been trying to figure out what is going on with Flash remoting and PHP lately. Especially since Mike Chambers keep dropping hints that something might be happening.
For now, the best information (for us developers) that I have found, is a posting by one of the Flash Remoting and JRun developers, that goes into detail of how the Flash remoting actually works. (Thanks to Mike for the link)
Here is the posting from TheServerSide.com – Rich Client Apps are Back with new Macromedia MX Suite Launch
Posted By: Sean Neville on April 30, 2002 in response to this message.
Having spent the majority of the past year working on both JRun 4 and Flash Remoting for J2EE and .NET, the relation between Flash and J2EE (beyond ColdFusion) is of great importance to me and to the other engineers who pulled the products together. Although official announcements and docs will continue to flow through marketing and product management, here are some unofficial notes from engineering on the topic.
Flash Remoting — distinct from the low-level network I/O and XMLSocket available in Flash — is an asynchronous RPC model that allows Flash to invoke methods directly on web services, EJBs, JavaBeans, JMX MBeans, POJOs, ColdFusion pages, ASP pages, and a number of other resources in the ColdFusion and .NET worlds that are probably less important to you than the Java cases. This model uses a binary message format (called Action Message Format, or AMF) that is delivered over HTTP and is modeled on SOAP, though it is much smaller and faster that standard SOAP and is purely asynchronous and event-driven in order to meet the Flash player requirements. It allows you to send a variety of data types — RecordSets, full Java objects, primitives such as integers, Strings, XML Documents, references to EJBObjects, Dates, etc. — across the wire. Passing ValueObjects through existing EJB-based apps to Flash clients is certainly possible. A gateway on the server handles conversion of these various types from their ActionScript (ActionScript is the ECMA script syntax used in authoring Flash) versions to their Java versions and vice versa (the .NET version of Flash Remoting does the same for CLR/CLS types). This gateway is designed as a front controller to server processes, and contains a number of filters to handle issues such as serialization, logging, security, etc. before handling the actual invocation of the targeted service. The .NET version follows a similar architecture, although it was written from the ground-up in C# instead of Java and is packaged and deployed differently.
The client-side scripting model involves setting a connection to the gateway URL — and due to security sandbox concerns, a client delivered over HTTP is permitted to access a gateway only on the host that delivered the movie, ala Java Applets — and invoking the getService(…) method from the gateway connection. A “service” can be any server-side resource mentioned above, and the client assumes it exposes “functions” that can be invoked in the movie. If the remote service is an EJBHome, then the service functions are the EJBHome methods; if the service is a web service, the service’s functions are the same as the web service’s methods; if the service is a web context, then the service functions are ASP or CF pages available in that directory; etc. Through ActionScript, typically in response to client events such as clicks or data input, a service’s functions are invoked and the results are asynchronously (everything in Flash is asynchronous) returned to the movie, typically causing the movie to update in some manner. Regardless of whether the remote gateway is hosted in a J2EE, CF, and/or .NET environment, the client-side API is the same. A single Flash client might connect to both .NET and J2EE resources, but it does so with the same API.
There are other elements — we included a data binding API so that RecordSets and other relational data can be directly bound to Flash UI components, for example, and added a debugger and service browser to aid in development, and numerous new UI components — but this summarizes the basic approach.
There are two parts of the Flash Remoting product: client ActionScript extensions and a server gateway. The client extensions are free, but the server gateway is implemented as a J2EE application (packaged as an EAR) that currently ships in JRun 4 and ColdFusion, and will soon be available elsewhere through partnerships with IBM and Sun. If you download JRun 4 or CF, you’ll get this EAR as part of the install. I’m not yet sure how it will be productized in other application servers, but if not embedded I imagine it will be available for sale (look for official announcements as they occur).
For more information about Flash Remoting, I’d recommend downloading either JRun or ColdFusion (the default ColdFusion standalone version is now a web app that runs on an embedded version of JRun, essentially JRun with a large taglib and different web admin, though it will be released for other app servers as well) and fiddling with the Flash Remoting samples and bundled documentation there. Alternatively, you can grab Flash Remoting for WebSphere or for .NET in a beta program, if you’re working with either of those platforms, and fiddle with the samples and docs we include for those versions. There are certainly opportunities for improvement in the future, but the current MX launch in conjunction with the pending release of JRun 4 is a terrific start toward enriching J2EE development with extremely powerful media-rich clients.
PS Neville
[Via Mike Chambers]