Amn
09-12-2005, 02:46 PM
Hi all,
Thought of giving away a "disassembly-hour" report of mine (i am sure the gurus already did the same discovery on their own long time ago), which have to do with discovering what lies beneath the 'NetServices.as' library and all its offspring, including the newer AS 2.0 Remoting classes like Service etc, and uncovering the true nature of Flash Remoting..
For those of you who wonder what the Remoting is like on the most basic level, a NATIVE-only level of interpreting, a little tutorial:
var gateway_nc:NetConnection = new NetConnection;
gateway_nc.connect("http://localhost/flashservices/gateway.aspx");
var responder = {};
responder.onResult = function(r)
{
for(var i in r) trace(i + ":" + r[i]);
};
gateway_nc.call("MyService.MyFunction", responder, "someParameter");
What it does is it creates a NetConnection object, which establishes a connection between the client and the Flash Remoting Gateway (essential part of Flash Remoting) be it on a .NET, CFusion or a Java server. You dont have to wait for a successful connection, because, apparently since 'http' is a stateless and non-persistent protocol, the state of the NetConnection object after the 'connect' call allows for immediate calling of service functions. Remember that in case of connecting to a Macromedia Flash Communication Server MX thru the RTMP protocol, which IS persistent keep-alive protocol, you have to actually wait for the connection to be available before doing anything with the NetConnection object. Ok, so back to the script: calling then a service function requires that you specify a responder object which will asynchroniously receive the results of your particular remote function call - so you have to create an object which defines a 'onResult' method - the so-called 'responder' object. Results arrive by the Flash player calling the 'onResult' method with the results returned, be it a single or several parameters, depending on the nature of your remote function. The actual call of the remote function happens by using the NetConnection.prototype.call method (simpler put the 'call' method of your NetConnection object), and here some explanation is required. First, since the connection to the gateway is a general all-purpose multi-service connection, the call of 'call' method needs BOTH the service name and the name of the service function. You do that by supplying a string as the first parameter which identifies the remote function across the whole gateway - service name followed by dot followed by function name (in case for .NET, which I cover here). Second parameter is the 'responder' object which tells where to return the call return values, and starting from the third parameter are the parameters to your actual remote function, which may or may not be present at all (i.e. the 'call' method can have only two parameters - the function string and the responder object). That's it :)
I know the practical use of doing everything the 'native' way is not so popular, since the Macromedia classes present a more user friendly scripting interface, but in case of small projects or where one simply wants to do Remoting another way, by building his/her own programming interface, this should explain little bit more than the basics.
Comments are welcome, criticism as well ;)
Thought of giving away a "disassembly-hour" report of mine (i am sure the gurus already did the same discovery on their own long time ago), which have to do with discovering what lies beneath the 'NetServices.as' library and all its offspring, including the newer AS 2.0 Remoting classes like Service etc, and uncovering the true nature of Flash Remoting..
For those of you who wonder what the Remoting is like on the most basic level, a NATIVE-only level of interpreting, a little tutorial:
var gateway_nc:NetConnection = new NetConnection;
gateway_nc.connect("http://localhost/flashservices/gateway.aspx");
var responder = {};
responder.onResult = function(r)
{
for(var i in r) trace(i + ":" + r[i]);
};
gateway_nc.call("MyService.MyFunction", responder, "someParameter");
What it does is it creates a NetConnection object, which establishes a connection between the client and the Flash Remoting Gateway (essential part of Flash Remoting) be it on a .NET, CFusion or a Java server. You dont have to wait for a successful connection, because, apparently since 'http' is a stateless and non-persistent protocol, the state of the NetConnection object after the 'connect' call allows for immediate calling of service functions. Remember that in case of connecting to a Macromedia Flash Communication Server MX thru the RTMP protocol, which IS persistent keep-alive protocol, you have to actually wait for the connection to be available before doing anything with the NetConnection object. Ok, so back to the script: calling then a service function requires that you specify a responder object which will asynchroniously receive the results of your particular remote function call - so you have to create an object which defines a 'onResult' method - the so-called 'responder' object. Results arrive by the Flash player calling the 'onResult' method with the results returned, be it a single or several parameters, depending on the nature of your remote function. The actual call of the remote function happens by using the NetConnection.prototype.call method (simpler put the 'call' method of your NetConnection object), and here some explanation is required. First, since the connection to the gateway is a general all-purpose multi-service connection, the call of 'call' method needs BOTH the service name and the name of the service function. You do that by supplying a string as the first parameter which identifies the remote function across the whole gateway - service name followed by dot followed by function name (in case for .NET, which I cover here). Second parameter is the 'responder' object which tells where to return the call return values, and starting from the third parameter are the parameters to your actual remote function, which may or may not be present at all (i.e. the 'call' method can have only two parameters - the function string and the responder object). That's it :)
I know the practical use of doing everything the 'native' way is not so popular, since the Macromedia classes present a more user friendly scripting interface, but in case of small projects or where one simply wants to do Remoting another way, by building his/her own programming interface, this should explain little bit more than the basics.
Comments are welcome, criticism as well ;)