Venza al Cocodrilo: Integrando aplicaciones y sobreviviendo a ello

- "Ya está listo! Dalé probá!!"
- Mmmmm... no amigo, no funciona!
- "Es en serio?? Si yo lo probé!"
- Si... pero no funciona! Te voy a enviar el log con el error para que lo revises.
- "Ok mandalo! Solo que voy saliendo, pero lo veo mañana a primera hora..."

Photo By Zach Klein

Y así termina otro día para el programador de front end, donde no pudo avanzar todo lo que quería y donde tendrá que atrasarse unas horas mas para poder terminar sus tareas.

Esta es una historia repetida diariamente para muchos programadores de clientes para internet, donde sus aplicaciones son apenas la interfaz de acceso para sus usuarios a servicios con bases de datos, servicios externos y demas aplicaciones que pueda tener un sitio corporativo.

Hablando con mi colega y amigo Ivan Alvarez - quien trabaja en la Bolsa Nacional de Valores en Mexico desarrollando aplicaciones financieras de ultima tecnología con Adobe Flex y Java en el lado del servidor - nos dimos cuenta que nuestros trabajos aunque son en areas totalmente distintas (yo trabajo para Scrapblog un sitio en Flex para crear tarjetas y manualidades digitales) enfrentamos estas mismas situaciones aunque estemos a miles de millas de distancia, con gente completamente distinta.

Photo by: http://www.lumaxart.com/

La integración de aplicaciones con clientes en Flex y código de servidor se puede convertir muchas veces en una tarea titánica y dolorosa. Sin embargo estamos convencidos que no debe ser así:

Existen distintas formas para comunicarse: Webservices, Rest Services y Remote Objects.
Los tres metodos son robustos, probados y comprobados.
Para Remote Objects, existe un protocolo de comunicacion (para la serializacion y deserializacion de la informacion) definido por Adobe que es AMF3. Este protocolo es bastante rapido, comprimido y binario lo cual hace que la informacion se transmita mas rapido.
Este protocolo ha sido implementado multiples veces para distintas plataformas, empezando con Java (BlazeDS, LifeCycle Data Services, Weborb, GraniteDS), .Net (Weborb, FluorineFx), Rails (Weborb, RubyAMF), PHP(Weborb, AMFPHP), entre otras. Esto quiere decir que puedes hacer tu backend en el lenguaje que quieras y utilizar esta implementación de AMF para comunicar tu aplicación Flex con el servidor de manera rapida, robusta y segura.

Con estos antecedentes, podemos decir que crear aplicaciones en Flex conectada a un servidor de aplicaciones con bases de datos o cualquier servicio que se ocupe es bastante sencillo. Sin embargo el problema que mas sufrimos es cuando tratamos de comunicarnos con los servicios expuestos por nuestro servidor. Generalmente hemos visto los siguientes problemas:

Los servicios no estan correctamente configurados y por lo tanto es imposible a nuestras aplicaciones accesarlos.
El nombre de los métodos no son los mismos que como se definió previamente (si es que tiene la suerte que le definan los nombres de sus servicios en algún lugar como un Wiki, email o un documento más oficial.
La signatura de los métodos no es la misma que la que esta documentada (error muy parecido al anterior)
El servicio no fue probado y sus métodos tiran excepciones cuando son llamados. Este es el mas común. Parece que nuestros amigos de backend nunca prueban, ya sea por Unit Testing o al menos ejecutar desde un cliente la invocacion al método. Esto tan simple, puede ayudarlos a ellos a darse cuenta mas tempranamente que hay errores y arreglarlos antes de decirnos que ya esta listos nuestros servicios.
Problemas de serialización al enviar la información. Debemos recordar que hay una capa intermedia entre nuestra aplicacion cliente y nuestro servidor. Ese se va a encargar de convertir nuestra informacion y datos en terminos que nuestra contra parte pueda entender. Por ejemplo algunas implementaciones del AMF3 tienen problemas a la hora de serializar fechas (zonas de horario, 24 horas vrs 12 -AM/PM, etc), otras problemas a la hora de serializar numeros, las enumeraciones por ejemplo son estructuras que no todas las implementaciones soportan. Este tipo de problemas hacen que la integración sea mas lentas, es un constante hacer/probar/repetir.

Ahora, todo esto presentado anteriormente no quieredecir que no hay manera de solucionar esta situación:

Documentacion de los servicios, métodos, parametros, valores de retorno,excepciones, etc. No tiene que ser una documentacion de 3 paginas por servicio. Lo minimo debe incluir eso que puse arriba. Muchos desarrolladores sienten pereza de hacer esta documentacion y ahi es donde empiezan los problemas.
Uso de unidades de prueba (o algún tipo de prueba) en el código del servidor que sea ejecutado antes de "entregar" el código.
Como dije anteriormente, existe una capa intermedia entre nuestro cliente y el servidor y ocupamos probar que esa capa funciona correctamente, por eso es bueno probar nuestros clientes y los respectivos llamados al servidor con utilidades como Flex Unit 4, Fluint, etc. Incluso algunas herramientas para llamados remotos (como Weborb) incluyen consolas para probar directamente estos servicios desde un ambiente creado en Flex.
Investigar la herramienta que utilizamos y conocer cuales son problemas conocidos en las mismas. Investigar más del proceso de serialización esto nos ayudara a reconocer posibles problemas tempranamente.
Aprender un poco como es el desarrollo en el lado del servidor. Si tienes ese conocimiento vas a tener un valor agregado en el mercado y ademas vas a conocer más del proceso y poder ayudar a detectar errores, sugerir formas de implementación, etc.
Enseñar. Si tienes estos conocimientos de arriba, enseñar a otros desarrolladores sobre todo esto. Iniciar la chispa en ellos para que investiguen igual. Esto debe ser de conocimiento para la mayoría de personas en el proyecto.
Cruzar los dedos y esperar que todo salga bien... :-P