Interaccion de Flex con datos externos

Empiezo este tema hablando lo negativo... Flex no tiene acceso directo a bases de datos.

Y la respuesta inicial de muchos:

Como???? Entonces de que me va a servir a mi o a mis clientes, si lo más importante de sus aplicaciones es la información, que generalmente se guarda en una Base de Datos??? Mejor me quedo con mi lenguaje web que me permite conectarme con la base de datos desde la misma página que esta cargando el usuario (por que para muchos esa es la mejor manera de hacerlo...)
Si Flex no tiene acceso directo a base de datos, como entonces puedo acceder a mi informacion?

Funcionalidad Flex

Flex fue hecho para funcionar como una interfaz de interacción de un usuario con un determinado sistema. Razón suficiente para preocuparse en brindarle al programador los recursos necesarios para realizar una experiencia totalmente distinta a la de sitios con el tradicional HTML.

Ahora, lógicamente que para interactuar con un sistema, se debe de tratar con datos. La datos es lo más importante en un sistema y de que sirve interactuar con alguien si no le responde a uno nada...? Se hace necesario el uso de un Backend que se encargue de manipular la informacion y transmitirla a la aplicación en Flex.

Ocupo programar en algún lenguaje especial para que funcion esto?

El acceso a datos desde Flex es totalmente independiente del lenguaje en que se programe en el backend. Puede hacerse en Java, Cold Fusion, PHP, Ruby, .NEt, lo que usted se imagine ya que provee varias maneras distintas de accesar la información.

Métodos Básicos

HTTPService: Permite acceder a la un archivo "hosteado" en un servidor. Se puede acceder a información en el mismo servidor o en otro. Esto permite realizar peticiones tipo REST a un servidor, ya que permite el envio de Parametros en el request, pero además permite la manipulación del resultado que esa página produzca... todo por medio de llamadas asincrónimas. Permite no solo la invocación a HTML plano, sino tambien a archivos generados dinámicamente en PHP, JSP, ASP, etc, devolviendo estos el resultado en la forma en que quieran y que el programador pueda interpretar más facilmente. Lo general es devolver el resultado en formato XML. El Actionscript 3 provee una forma muuuuuuy sencilla de manipular el XML (E4X), pero eso se merece otro post aparte

Ejemplo:

<mx:httpservice id="httpLogin" destination="http://127.0.0.1/login.php" result="resultHandler(event)" fault="faultHandler(event)">

</mx:httpservice>

Esto es:

id ==> Nombre con que se manejara el servicio en el MXML y en el Actionscript
destination ==> Direccion del recurso que se quiere accesar. Puede ser incluso un archivo XML directamente
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolver el script login.php (en este ejemplo)
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)

Todavía no hemos invocado a la pagina, solo tenemos la definicion del servicio... Esta definicion se puede hacer tambien por actionscript.

Continuamos con el ejemplo:

<mx:script>
<!--[CDATA[      
//Funcion que invocara el servicio      
public function invocarLogin():void {
 //Uso de Token          
 var call:AsyncToken = MyService.send();
 //Hasta aqui se hace la invocacion a la página          
 call.marker = "login";      
}  
//Manejo de resultado      
private function resultHandler(event:ResultEvent):void {          
 var call:object = event.token          
 if (call.marker == "login") {           
  //manipular informacion a través de: event.result; 
  trace(event.result) //imprime el resultado enviao por la pagina          
 }      
} 
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void { 
 Alert.show(event.fault);
}
]]-->
</mx:script>

<mx:remoteobject id="ro_tasklist" destination="TasklistService" result="onROResult(event)" fault="onROFault(event)" showbusycursor="true">
</mx:remoteobject>

Precaución: Al igual que con Ajax y con otras aplicaciones que se ejecutan en el cliente, el acceso a recursos que se encuentren en un servidor distinto al en que se descarga la aplicación flex, esta prohibido. Las reglas para acceso a recursos de un proveedor externo están restringidos por motivos de seguridad. Sin embargo una manera de evitar este problema, es utilizando un "proxy". Por ejemplo (un poco cavernicola...) tengo mi aplicacion flex en miserver.com que lee los feeds de un RSS localizado en CNN.com, puedo crear un archivo en mi servidor (el proxy) php, jsp, asp, o lo que quiera que se encargue de leer el contenido en CNN.com y se lo devuelva a mi flex...

RemoteObject: Mi favorito....este es definitivamentelo que hizo que me enamorara del Flex. Es totalmente RPC (remote procedure calls). Funciona en palabras simples asi:
Se tiene un backend creado en X lenguaje, en servidor se tiene una configuración especial para ese lenguaje y el Flex a través de esa configuración puede acceder a los métodos de las clases definidas en la configuración, pasando objetos como parametros y recibiendo objetos como resultados (literalmente objetos, nada de XML ni eso). Esto a través del protocolo AMF, que lo que haces serializar los objetos y mandarlos sea al servidor o al cliente para su respectiva deserialiazación y manipulación. El AMF serializa estos objetos en formato binario, osea es mucho más rápido (mucho más y sino lo cree, corra este ejemplo de James Ward: http://www.jamesward.org/blazebench/) y los manda encapsulados y comprimidos en un metodo POST por http (no teniendo problemas con proxies ni firewalls). No tienen que ser solamente un objeto a la vez, puede enviar colecciones de objetos (Arrays, listas, etc)
Algo bueno es que acaba de ser abierto por Adobe, lo que permitirá que otras personas intenten mejorarlo o darle nuevas aplicaciones...
RemoteObject es asincronimo tambien y hay que manejar tambien el Resultado o la Falla como en el HTTP Service.
Inicialmente funcionaban solamente con Java y ColdFusion (adobe provee librerias para configurar los servicios) sin embargo ya existen las librerias necesarias para configurar en otros lenguajes, ejemplo PHP --> amfphp, Ruby --> rubyamf, WEBORB, AMF.NET --> .NET entre otros.
Ejemplo:

Suponga que tenga una aplicación que tiene un metodo para crear usuarios llamado creaUsuario y que recibe un parametro de tipo Usuario (una clase) con nombre, username y password.

En actionscript, define su clase llamada Usuario también, con las propiedades nombre, username y password, esta clase es un mapeo de la clase Usuario en el server.
Algo asi:

package com.sitio.clases
{
//RemoteClass especifica a que clase en el server va a asemejarse esta. Apunta al mismo folder donde se encuentra la clase pero en el server.
[RemoteClass (alias="com.sitio.clases.Usuario")]
public class Usuario
{
public var nombre:String;
public var username:String;
public var password:String;
}
}

En el MXML (o en Actionscript tambien) se definira el RemoteObject

<mx:remoteobject id="ro_usuario" destination="ServicioEnServidor" result="resultHandler(event)" fault="faultHandler(event)" showbusycursor="true">
</mx:remoteobject>

Esto es:

id ==> Nombre con que se manejara el servicio en el MXML y en el Actionscript
destination ==> Nombre del Servicio o Clase que se configuro en el servidor para ser accesado por el Flex
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolvera el método
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)
showBusyCursor ==> Muestra un cursor con un relojito, mientras se hace el request...mas estetico que otra cosa

Todavía no hemos invocado al metodo, solo tenemos la definicion del remote object... Esta definicion se puede hacer tambien por actionscript.

Además en su aplicacion tiene un boton, que cuando sera presionado invocara a una funcion que preprara el usuario e invocara el metodo en el server:

<mx:button label="Add Item" id="submit" click="enviarForm()"/>

El Script:

<mx:script>
<!--[CDATA[      
//Funcion que invocara el servicio, ejecutada cuando se apreta boton      
public function enviarForm():void {     
 //Creacion de un objeto en AS3 de tipo usuario, que sera transmitido al server    
 var usuario:User = new Usuario();    
 usuario.nombre = "Mi Nombre";    
 usuario.username = "username";    
 usuario.password = "password";     
 //Uso de Token          
 var call:AsyncToken = ro_usuario.creaUsuario(usuario);
 //Hasta aqui se hace la invocacion al metodo, pasandose de parametro el usuario creado          
 call.marker = "crearusuario";      
}  
//Manejo de resultado      
private function resultHandler(event:ResultEvent):void {          
 var call:object = event.token          
 if (call.marker == "crearusuario") {           
  //manipular informacion a través de: event.result; 
  trace(event.result) //imprime el resultado del metodo          
 }      
} 
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void { 
 Alert.show(event.fault);
}  
]]-->
</mx:script>

De verdad.. si está pensando en iniciar una aplicación en Flex con acceso a datos en el servidor, considere seriamente esta opción pues es mucho más facil que las demás...

WEBService: Permite acceder a información por medio de SOAP. Utiliza la especificación WSDL 1.1. Este método en realidad no lo he usado. Sin embargo está disponible y funciona igualmente con llamadas asincrónimas, haciendo que el programador maneje las funciones de resultado y de falla igual como el HTTP Service. Existen ya varias aplicaciones que utilizan de este medio, por ejemplo Yahoo ofrece varios de sus servicios para desarrolladores en Flex por medio de Web Services, como en los mapas o el clima: http://developer.yahoo.com/flash/astra-webapis/ (ellos "wrappean" los llamados a los servicios desde sus librerías)

Esto por ahora en cuanto a interaccion con datos...
Saludos

Japón, nuestro segundo barrio

Sin duda alguna las agencias de publicidad están empezando a reconocer la influencia del internet.
Debido a la participación de Boca Juniors en el mundial de Japón, Nike sacó una campaña que se llama "Japón, nuestro segundo barrio" y como forma de exponer su campaña decidieron cambiarle la cara completa a la página web del diario Ole en Argentina (no sé si lo hicieron con otros) que es un períodico totalmente deportivo.
Todos los titulares de las noticias fueron puestos en Japonés (o quiero pensar que se tomaron la molestia de traducirlos en verdad, aunque estoy casi seguro que sí)
A continuación un screenshot... me parece una idea genial y una excelente forma de mercadear a través del internet, ojala otras personas vean esto, agarren ideas de genios como los que están detrás de esto...

Llamadas Asincrónicas

Tecnologías como Flex, Ajax, .NET entre otras, hacen uso de lo que se conoce como comunicación asincrónica. Esto es: llamadas a un cierto servicio en las cuales no sabemos cuando se recibirá la respuesta. Hay mucho factores que pueden modificar el tiempo de respuesta de un servicio, como puede ser la carga en el server, bandwidth del cliente, entre otros...
En comunicaciones sincronizadas, la aplicación no continuará trabajando hasta que reciba una respuesta a la petición hecha, en una aplicación asincrónica no.
Pensando en este ambiente, planteo la siguiente situación que se puede presentar en cualquier tecnología asincrónima:

Se tienen dos botones, que se conectan a un mismo servicio (archivo XML, un script PHP, ASP, JSP, un webservice o lo que sea) pero que hacen distintas funciones, se presiona uno primero y medio segundo después el segundo... En la forma en que se programa asincrónimamente, no sabemos cual respuesta va a llegar primero, puede ser la del segundo boton y después la respuesta del primero. Si nos ponemos a programar y pensar "sincronizadamente", esperaríamos la primer respuesta y luego la segunda y esto puede ocasionar problemas en nuestras aplicaciones ya que si el orden es distinto la forma en que se manejará la respuesta variará el procesamiento de la respuesta recibida y por lo tanto el funcionamiento normal de la aplicación.

Solución en Flex

El AsyncToken es una clase usada para manejar llamadas asincronicas... Es aplicable con lo que se conoce como el ACT Pattern o Asyncronous Completition Token. Este patrón se encarga de procesar la acción indicada a la respuesta recibida a una llamada asincrónima. Esto quiere decir que la llamada realizada por el boton 2, no procesara la acción a la respuesta del llamado del botón 1 aunque llegase primero... sino solamente la que esta relacionada con su llamada.

Las funciones principales del AsyncToken son agregar información que puede ser util para identificar la llamada... y permitir definir quien se encargara de procesar los resultados(y sus fallas en caso que hayan).

Como ejemplo para el primer caso que mencione antes (identificacion de quien hizo una llamada), al trabajar asincronimamente no sabemos cuando iremos a recibir el resultado, en el ejemplo anterior de los botones que se conectan a un mismo remote object pero hacen distintas funciones, se presiona el primero e inmediatamente el segundo.. como va a saber el Result Handler cual de los dos llamados fue invocado? El ASyncToken nos permite agregar cierta informacion que permitira marcar cada llamada y asi se sabra como procesar cada
informacion.... Este token sera agregado al llamado, así que cuando se reciba información el token va a ir pegado con el evento resultado.
Por ejemplo (muy basico) utilizando una "bandera" en el token, que se llamará marker:

//Ejecutado cuando se presiona Boton 1.
private function llamada1():void{
var token:AsyncToken = remote_object.agregarUsuario(instancia_usuario);
token.marker= "agregarUsuario";
}

//Ejecutado cuando se presiona Boton 2.
private function llamada2():void{
var token:AsyncToken = remote_object.modificarUsuario(instancia_usuario);
token.marker= "modificarUsuario";
}

private function resultHandler(event:ResultEvent):void{
var token:Object = event.token;//se carga desde el evento, el token que se instanció en cada función
if(token.marker == "agregarUsuario"){

//codigo para manipular resultado cuando se agrega usuario

}else if(token.marker == "modificarUsuario"){

//Codigo para manipular resultado de modificar usuario...

}
}

Ya en Cairngorm especificamente, en el delegate se utiliza esta funcionalidad, ya que permite asignar quien se encargara de procesar los resultados de una llamada a servicio externo. Generalmente en la comunidad de flex, se le encarga esa responsabilidad a los comandos, por eso los comandos con llamados a datos externos (remote objects, web services o http services) generalmente implementan la interfaz IResponder, que expone los servicios: result(en caso de resultado satisfactorio) y fault (en caso de error). Lo que permite concretamente el asynctoken en este caso, es asignar a otra clase el manejo de los resultados que se vayan a recibir, ej desde un delegate:

var call:AsyncToken = service.agregarUsuario(instancia_usuario);
call.addResponder(responder);

En este caso, quien manejara los resultados del metodo agregar usuario, no sera el delegate, sino el objeto Responder, que será un objeto de un tipo de Clase que implemente IResponder (como mencione antes) y que generalmente es el command, aunque se puede hacer aun en otra clase, para "favorecer la composicion sobre la herencia", pero eso es tema de otro topic...

Así de sencillo, lo bueno es que por la arquitectura de servicios que tiene el Flex, esta misma solución es aplicable a Web Services, HTTP Services y Remote Objects.
Saludos