sábado, 4 de octubre de 2008

Integracion de Aplicaciones con Flex

Recientemente me solicitaron dar un training para desarrolladores de Flex para Java. Mi proposito era primordialmente presentar la herramienta de Flex a nuestros desarrolladores (que son bastantes) y a la vez enfocarme en la necesidad de estandarizar el proceso de la creacion de aplicaciones que utilicen ambas tecnologias.

Mi transfondo tecnico viene de Java y hace cuestion de dos anos le agregue a mi carrera el Flex. Fue una desicion dificil y confusa por la falta de conocimiento de dicha tecnologia, pero al final creo que tome la desicion correcta. Java y Flex es una mezcla excelente para la creacion de aplicaciones y tener un conocimiento en ambas tecnologias me ha podido dar una valor agregado para ofrecer.

Creo que en esto de aplicaciones con Flex y Java hay mucha tela que cortar. He hablado previamente de tecnicas como el remoting, llamadas asincronimas y otras cosas que nos permiten comunicarnos con el servidor para interactuar en nuestra aplicacion, sin embargo el sentido de este post va mas orientado al proceso y trabajo que tiene que haber para unir a estos dos juntos...
Flex como front end provee muchas ventajas que otras herramientas no pueden proveer en un 100%, empezando por que el virtual machine donde corre (Flash Player) esta instalado en mas de un 95% de las computadoras del mundo. Java, un lenguaje maduro, activo, con una comunidad de desarrolladores de mucha experiencia y que va rejuveneciendose poco a poco es una excelente desicion para construir aplicaciones transaccionales. La ventaja con Flex es que no solamente tiene que trabajar con Java, el puede trabajar con .Net, Ruby, PHP, etc... lo cual permite que la escogencia del servidor de aplicacion sea mas flexible.

Pero como dije.. este post no va en lo tecnico, que es mejor?, cual es mas rapido?, etc... este post va mas orientado al proceso de integracion entre Flex y una aplicacion de servidor, escrita en el lenguaje que usted quiera. Parte de mis conocimientos tecnicos hablare mas sobre java.
He podido trabajar en varias aplicaciones de tamano considerable en las que se usa Flex y una aplicacion en el servidor (Java en cada caso y ayude en una con PHP). En todos los casos noto lo mismo:

La integracion es la etapa mas dificil de todo.

Una incorrecta integracion hace que todo el desarrollo sea mucho mas lento. Podemos desarrollar nuestra aplicacion Flex en un dia y la aplicacion en el servidor en un dia tambien... y la integracion de algo sencillo puede tomar 2 dias mas...
Aqui una lista de razones por las que pienso esto pasa:
  • Falta de comunicacion entre los equipos de desarrollo. No se mantienen reuniones entre los equipos donde se definan que servicios, metodos, parametros y tipos de retorno se van a maneja o cambios que se hayan realizado. Esto hace que sea todo una caja negra, que se trate de integrar algo y se pasen parametros equivocados, que se llamen a metodos incorrectos, que se esperen valores distintos. 
  • Relacionado con lo anterior... no existe documentacion de los servicios expuestos por la aplicacion para ser accesados desde el front end. Si existiera una documentacion detallando descripcion, nombre del metodo, parametros, tipo de retorno, etc. que pueda ser accesado por todos los desarrolladores, en un solo lugar (wiki, etc.) facilitaria muchisimo la comunicacion y el desarrollo no se veria tan parado al hacer la integracion.
  • No existen por lo general pruebas de integracion. Podemos crear JUnits para probar nuestros metodos en Java, podemos crear Flex Units para probar metodos en Flex, pero por lo general no existe un mecanismo para probar la integracion. Por que es necesario probar esto? Bueno.. aunque nuestros JUnits salgan correctamente, debemos recordar que en el medio (entre Flex y nuestro back end) hay una capa de comunicacion en lo que pueden pasar muchisimas cosas, desde tipos de datos no reconocidos, nombres incorrectos de metodos hasta problemas con el servidor, que debemos ser capaces de probar. Mi propuesta inicial es hacer Flex Units con soporte para operaciones asincronimas que sean ejecutadas desde la maquina del developer del Back End y se encarguen de llamar los metodos remotos. Si algo falla en esos tests units a la hora de interactuar con los servicios o metodos provistos por nuestro back end, podran ser revisados y corregidos por parte de nuestros desarrolladores. Los programadores en Flex mientras tanto, pueden continuar con otras tareas sin tener que esperar a que cada vez que algo falle, sean arreglados.
Otra herramienta que he visto y me parece muy interesante es el uso de Mercury Pro, que viene con el Flex Builder y te permite crear pruebas de aplicaciones a modo de macros o robot, donde se graba una interaccion con una aplicacion y se graba toda la secuencia para probar que siempre de el mismo resultado. Igualmente si Flex Unit no te es funcional, puedes crear tu propia unidad de pruebas, talvez demore mas tiempo pero te dara mayor tranquilidad.

Otros pensamientos relacionados:

  • Quien lleva la batuta a la hora de escoger que metodos o servicios se van a exponer en una aplicacion al front end? Sera tarea solo del back end o tarea del front end? Estoy convencido que es una tarea de ambos equipos y que la comunicacion tiene que ser clave y en doble via. Front End provee una perspectiva de lo que necesita ser ingresado por el usuario para funcionar, pero back end provee una vision completa de todo lo que ocurre en un sistema y no solo en una pantalla. Nada peor que una aplicacion disenada enteramente por pantallas.. de ahi mi consejo de establecer estos servicios y metodo de forma conjunta.
  • Aunque de pereza y duplique el trabajo, es NECESARIO el uso de DTO's o Value Objects para comunicar informacion del back end al front end, sobre todo si se usa Remoting. Esto es necesario para evitar problemas con sesiones, enumeraciones y otras cosas que no esten aceptadas por Flex y que vayan a ser recibidas incorrectamete ademas nos permite obtener abstracciones mas exactas a lo que necesitemos.

Espero poder ahondar en otros temas relacionados a esto en un futuro...

No hay comentarios: