Me gustaría empezar por ahí porque todo lo que hago hoy en día en cuanto a Soluciones de Movilidad está basado en esta tecnología que forma el "núcleo duro" de todas nuestras implantaciones (M-FRONT® Platform).
Lo que te quiero explicar aquí (¡amigo "javero"!) es cómo, a partir de una infraestructura middleware J2EE™, 100% diseñada/preparada (como bien sabes) para aplicaciones n-tier en entornos Web, podemos llegar a crear servicios móviles de mensajería SMS de una forma elegante, extensible, reusable y sólida.
¿Preparado?...
Hace algo así como 5-6 años, me dí cuenta de que se estaban comentiendo para el desarrollo de servicios de mensajería SMS, exactamente los mismos errores que los que cometimos todos en los inicios de J2EE™:
- Diseño de código Java monolítico,
- Poca orientación a la reusabilidad,
- Interdependencia entre las capas de presentación y de negocio,
- Interfaces de programación propietarios,
- etc.
En aquel entonces, en paralelo a todo esto, recuerdo que ofrecí mi colaboración para la definición del JSR-212, JSR que pretendía definir un API Java genérico y adaptable para la mensajería SMS y multimedia. Lo comento porque esa colaboración me permitió "atinar" un poco más en cuanto a necesidades e implicaciones ligadas a un API Java de mensajería SMS/MMS (aspectos comunes con otros APIs, independencia con respecto a proveedores físicos, etc.).
Era una pena observar cómo, una vez más, las soluciones que habíamos ido encontrando, entre todos, para mejorar la mantenibilidad de nuestras aplicaciones Web no se estaban trasladando al Canal SMS, es decir al software que lleva los servicios SMS! Me estoy refiriendo, por supuesto, a interfaces de programación estándares para la programación y a patrones de diseño y "Best Practices" en cuanto a arquitectura técnica.
Personalmente, la reflexión más importante que me hice a mí mismo, la que al final me permitió trazar el camino que tenía que seguir para mis futuros desarrollos SMS/MMS/WAP-PUSH, fué:
"El paradigma request/response del Canal HTTP y su carácter Stateless... no son tan distintos al paradigma pull/push de los Canales de Mensajería Móvil y a la naturaleza de los mismos."
Cierto... dicho de otro modo, enviar una petición HTTP a un servidor Web para activar un servicio y/o que este nos conteste simplemente con un contenido HTML, es exactamente igual a cuando enviamos un mensaje a un servicio SMS y este nos devuelve un mensaje de texto a modo de respuesta (por ejemplo).
Y por otro lado, recibir un correo electrónico es también similar a la recepción de mensajes de alerta SMS... sólo cambia el Canal, los terminales clientes y los servidores de comunicaciones que llevan la tecnología de transporte. ¡Sin más!
En un entorno middleware J2EE™, existen determinados interfaces de programación, librerías y frameworks muy bien preparados para esas necesidades HTTP:
- Servlet (capa de gestión request/response con soporte de mantenimiento de sesión),
- JSP y tag libraries (capa de presentación),
- STRUTS (paradigma model/view/controller),
- Java Resource Bundle (internacionalización),
- etc.
¿Porqué no reusar estos recursos ya muy bien conocidos por los programadores Java?, ¿Porqué no aprovechar esos conocimientos y lograr que los programadores Web Java se conviertan "de un día para otro" (en realidad, estamos hablando de 2 días!) en programadores de servicios SMS/MMS/WAP-PUSH? Sin conocimientos de telecomunicaciones, sin necesidad de "pelearse" con interfaces de programación propietarios (cada SMSC [Centros de Mensajería SMS], apartando unos pocos estándares que pocos te ofrecen, tiene su propio API para el envío y la recepción de mensajes cortos), sin tener que lidiar con políticas de reintentos o de gestión de tickets para mantener sesiones y/o contextos transaccionales, etc. etc. etc. etc.
Todo esto y más era lo que quería yo servirle en bandeja al programador Java, a través de un "middleware de movilidad" que no iba a ser otra cosa sino una extensión de J2EE™.
... [¡unas 100,000 líneas de código Java más tarde!] ...
Logré finalmente poner en marcha una primera versión beta de este middleware (denominado M-FRONT® Platform) sobre dos servidores de aplicaciones J2EE™ bien distintos:
- JBoss Server,
- WebLogic Application Server.
La independencia lograda fué bestial en cuanto al Canal (SMS, MMS, WAP-PUSH, IVR, FAX) y al Proveedor del Canal (NetSize, modem SMS, Tempos21, NVIA, etc.).
Las similitudes del API de desarrollo de servicios de mensajería interactivos (ej. servicios SMS Premium) con el API Servlet son verdaderamente impresionantes, lo cual facilita muchísimo su aprendizaje para un programador Java. Y, además, aquí también tienes la posibilidad de recuperar la sesión del usuario móvil que te está enviando un mensaje... todo ¡automáticamente! (no tienes que preocuparte por codificar tu propia estrategia de mantenimiento de datos de sesión para tus servicios SMS).
El paradigma MVC (model/view/controller) llevado a cabo a través de un Contenedor de "Componentes de Movilidad" convierte la tarea de "programación de servicios SMS" en una tarea de "ensamblaje de componentes reusables" mediante un simple trabajo de configuración de nuestro servidor, configuración cargada/guardada en un fichero central XML:
- Tienes componentes para generar los contenidos de tus mensajes: componentes MPage (que físicamente son páginas JSP estándares basadas en una infraestructura de librería de tags y unas capacidades multi-idioma derivadas del estándar Java Resource Bundle)
- Tienes componentes que se encargan del control (validación y demás) de los mensajes entrantes: componentes Mlet (¡que ofrecen un API casi idéntico al de Servlet!)
- Y finamente, tienes componentes de acceso a la lógica de negocio (un tipo de "Business Delegate"): estos son los componentes MComponent.
Todos los tipos de mensajes posibles (entrantes y salientes, SMS, MMS, IVR y demás) son convertidos a un tipo genérico denominado UMSMessage (UMS, como Unified Messaging Service) y el transporte interno de los mismos (dentro del middleware, entre sus diferentes componentes y subsistemas) se realiza sobre el kernel de mensajería JMS que tengas configurado para tu servidor de aplicaciones base. De esta forma, heredamos también de todas las bondades de un buen servidor JMS!
Bueno... enfín, después de todo esto, creo que ya te haces ahora una idea mejor de qué es (o debería ser) una buena infraestructura middleware para el desarrollo de aplicaciones y servicios de mensajería móvil, y cuáles fueron mis objetivos, en particular, cuando diseñé y programé M-FRONT® Platform.
Para concluir este pequeño "inciso tecnológico", simplemente comentarte que hoy en día esta Plataforma ofrece un soporte a muchas más cosas que los servicios de mensajería móvil ya comentados, como por ejemplo aplicaciones BlackBerry, Windows Mobile y J2ME.
Pero ya hablaremos de todo esto más adelante....
Muchas gracias.
Atentamente,
JV.
No hay comentarios:
Publicar un comentario