Mobile, Genexus y BlackBerry II

Hola a todos. Siguiendo con el tema de mi post anterior, les contaré brevemente algunas cosas sobre el funcionamiento de la tecnología BlackBerry y de nuestra experiencia con ella. Para comenzar, haré una corta reseña del estado del arte en temas de tecnología móvil destinada a soluciones de negocios.

Existen varios tipos de diseños de arquitectura para las soluciones móviles, enumeraré las tres más importantes y conocidas:

1) WAP (Wireless Application Protocol). Corresponde a una de las primeras formas de desarrollo de aplicaciones móviles basadas en telefonía celular. Básicamente se trata de un subconjunto de instrucciones HTML, conocido como WML que es interpretado por un browser bastante rudimentario que corre sobre el dispositivo celular. Se justificaba inicialmente, ya que los anchos de banda y la circuitería de los equipos no permitían soluciones más potentes, pero actualmente está francamente en desuso. Sus principales problemas eran lo básico de su interfase (similar a una pantalla de texto pequeña) y a que nunca existió un real standard al respecto, existiendo algunos problemas en su ejecución, según la marca y tipo de navegador en los celulares. Por otra parte, requería de un gateway especial que encarecía bastante la solución.
2) J2ME (Java 2 Mobile Edition). Tal como existe una especificación Java Standard (J2SE) y una empresarial (J2EE), se creó una versión de este lenguaje para dispositivos móviles. Está bastante extendida, ya que actualmente los procesadores y memorias de los aparatos permiten la ejecución de este tipo de programas. Mayormente se ha utilizado para aplicaciones que no requieren mayor conectividad, como juegos, agendas y cosas similares. Para cualquier desarrollador Java es conocido que pese a existir una especificación aceptada en la industria para el lenguaje de programación, la ejecución de este código en diferentes JVM puede producir resultados bastante diferentes. En los celulares no es diferente, razón por lo que uno de los problemas de esta plataforma es que siempre debe tenerse muy presente el tipo de máquina en que correrá. Otro problema es que en su especificación el manejo de dispositivos es bastante complejo, así como las herramientas de integración. Estas últimas son parte principalmente de J2EE, por lo que hay que ser bastante ingenioso y experimentado para lograr buenas integraciones desde esta plataforma.
3) WEB mobile. La irrupción del aumento del ancho de banda inalámbrico (principalmente EDGE), ha permitido que se pueda navegar en Internet desde un celular con tiempos de respuesta y costos razonables. Sin embargo, aún está pendiente un mayor desarrollo de los navegadores de las máquinas, siendo actualmente habitual tener serios problemas con la ejecución de scripts, el manejo de certificados y las resoluciones de las pantallas. Esta es una solución muy utilizada en la actualidad para desarrollar aplicaciones móviles de negocio, por no requerir de un esfuerzo adicional al ya requerido para el desarrollo web. Sin embargo, no soluciona muchas de las problemáticas mencionadas en mi post anterior, así como sub utiliza la potencia total de los dispositivos.

En términos generales, las soluciones móviles actuales adscriben a alguna de estas arquitecturas, sobre todo a las dos últimas. Esto aplica tanto a aparatos celulares como a dispositivos celulares. Se que a esta altura todos habrán saltado porque no puse .net mobile, pero la verdad es que esta herramienta es utilizada en menor medida que las anteriores, por cuanto tiene la limitante de solo correr en aparatos con Windows CE o Windows Mobile, como las PPC. A mi me parece que es una plataforma bastante poderosa, pero al tener esa gran limitante está lejos de posicionarse como una alternativa fuerte en el mercado, más aún con el auge que está teniendo el Open Source.

Hasta acá, hemos mencionado algunas alternativas de solución utilizadas, pero si se fijan bien encontrarán que hay cabos sueltos, tales como:

Todas estas opciones son variaciones de otras de corte más tradicional (WAP-WEB, J2ME-J2SE, etc.), heredando muchas de sus virtudes, pero también muchos de sus problemas y complejidades.
Todas ellas dan cuenta de formas de desarrollar aplicaciones para LOS CLIENTES, pero ninguna está centrada en solucionar el ciclo completo, es decir, la capa servidora, la integración, las comunicaciones, etc).

En definitiva, si necesito desarrollar un sistema que me permita exponer mis procesos de negocios a los ejecutivos para que puedan interactuar con ellos desde sus dispositivos móviles lo más probable es que desarrollar la aplicación cliente sea una de las labores más sencillas, quedando pendiente todo el resto de los elementos. Bueno, justamente este es el elemento central de la solución desarrollada por RIM, las BlackBerries.
Hay que partir aclarando que esta no es una plataforma o un tipo de lenguaje de programación, es una arquitectura que da cuenta de la problemática completa, que incluye la capa servidora, las comunicaciones y las aplicaciones clientes. Las BlackBerries también pueden trabajar como cualquier celular en las modalidades que mencioné anteriormente, pero no es hasta que se implementan como solución corporativa que demuestran su real potencialidad.
En primer lugar, existen dos formatos de la arquitectura: BIS y BES. El primero de ellos corresponde a un tipo de solución parecido a una solución Java tradicional. Este es el esquema de ella:

Los dispositivos trabajan permanentemente en formato EDGE con buenos anchos de banda (se debe tener un contrato con la compañía respectiva para el tráfico de datos). En Chile he llegado a medir casi un mega, según la calidad de la señal. Cuando se compran o arriendan, se deben configurar para que trabajen contra un servidor del carrier con que contratamos. Este servidor es un GateWay o APN, que permite al aparato tener acceso full a Internet y, a través de ella, acceso a los servicios que tengamos publicados, como por ejemplo el mail.

La segunda modalidad es donde radica la mayor potencialidad de esta solución. El esquema de arquitectura es el siguiente:

La primera diferencia está en que el dispositivo interactúa inicialmente con un Gateway de RIM, el fabricante. Esto aplica a todos los aparatos repartidos por el mundo, estén donde estén. Este servidor está interconectado con otra máquina propiedad del cliente, el BES (BlackBerry Enterprise Server), el que a su vez está en la misma red que los servidores de nuestra compañía. Algunas de las características y consecuencias directas de este modelo son las siguientes:

1) La comunicación completa, desde el aparato hasta la red del usuario, es por defecto totalmente encriptada y segura.
2) El BES permite un control completo sobre las transmisiones y usos de cada uno de los dispositivos registrados en el.
3) El BES al estar en el dominio de red de la compañía, permite al usuario BB el acceso a los recursos de red, como si se tratara de una WAN. Obviamente, estamos hablando de los recursos accesibles desde un teléfono, tales como los servicios web, ftp, etc.
4) A través del BES podemos publicar hacia el dispositivo datos y aplicaciones mediante sus servicios. Esto es absolutamente consistente con una arquitectura SOA integrada con dispositivos móviles.

Hasta ahora no he mencionado en ningún momento el desarrollo de aplicaciones cliente para las soluciones corporativas. Bueno, en el caso de BIS, se pueden desarrollar en JAVA, como en cualquier teléfono con esta plataforma habilitada. Un ejemplo lo pueden ver en una solución desarrollada por nosotros, en conjunto con MapCity.com: http://www.mapcity.com/bb/
En el caso de una arquitectura BES, esto es diferente. La herramienta de desarrollo de aplicaciones es MDS (BlackBerry Mobile Data System). En realidad MDS es un framework completo, que permite el desarrollo de las aplicaciones, la administración de estas y de los dispositivos, manejo de la seguridad, etc. En lo referido al desarrollo, es interesante mencionar que se realiza en un ambiente gráfico y es automáticamente distribuida a los aparatos deseados, sin ningún proceso manual de instalación. Las aplicaciones obtenidas son de una calidad gráfica aceptable, con una interfaz similar a la de una aplicación Web sencilla. Ahora, pensemos en el flujo completo de la solución para que veamos su potencialidad, suponiendo que se trata de una aplicación de captura de datos en terreno. Por ejemplo, datos metereológicos (este corresponde a un caso real de solución):

1) El desarrollador genera la aplicación con MDS, incorporando todos los controles y objetos gráficos necesarios para su operación.
2) La aplicación se instala automáticamente el los aparatos de los operarios deseados.
3) Estas personas la ejecutan.
4) La aplicación captura las coordenadas geográficas obtenidas por el GPS del aparato (BB 8800) y la almacenan localmente.
5) El operario comienza a registrar las variables ambientales desde las estaciones correspondientes y las tipea en su celular (temperatura, humedad, etc).
6) Los datos se transmiten en protocolo seguro hasta el BES central de la empresa, el que los inyecta en las bases de datos inmediatamente.
7) Los datos recién capturados están disponibles de inmediato para los analistas situados en la capital, o vía BB.

Es verdad que de una u otra manera todo esto se puede conseguir de otras formas, pero la facilidad y rapidez de los resultados logrados es tremendamente superior a otras plataformas.
Ahora, ¿qué pasa con Genexus?. Bueno, todos sabemos que Genexus no genera J2ME ni MDS, por lo que no podemos pensar en desarrollar aplicaciones para ser ejecutadas directamente por una BB. Sin embargo, tanto esta como las demás alternativas requieren de un poderoso set de servicios asociados, los que pueden ser perfectamente desarrollados con Genexus. En este sentido, nuestra experiencia nos indica que las herramientas de Genexus que potencian las características de backend son tremendamente valiosas a la hora de enfrentar este tipo de proyectos y las iniciativas SOA en general. Las features como los business components, SDT y otros, permiten desarrollar rápida y fácilmente los servicios necesarios para poder hacer interactuar las BB con nuestras aplicaciones, vía BES.
A manera informativa, les cuento algunas otras gracias de la arquitectura BES y BB en general:

Es posible trabajar en modalidad “Push”, en la que se envía desde el BES requerimientos a los dispositivos para tareas específicas. Por ejemplo, la actualización en línea de una aplicación, sincronización de los relojes, cambios de configuración, bloqueos, etc.
Hay absoluta compatibilidad en las diferentes versiones de HDW. Si se cambia un aparato por uno más moderno o con características diferentes, las aplicaciones continuarán trabajando correctamente. Esto baja tremendamente la obsolescencia de las soluciones.
Es posible trabajar en forma “stand alone” con las aplicaciones en caso de no tener señal y posteriormente, enviar a proceso los datos.
Existen varios modelos de máquinas, destinados para ambientes de trabajo diferentes.
Se pueden encontrar múltiples accesorios destinados a trabajar en soluciones de nicho. Por ejemplo, impresoras, lectores de códigos de barra, etc.

Espero haber aportado en algo al conocimiento de esta tecnología, al menos a las personas que se tomaron la molestia de contactarme. Si alguien quiere iterar un poco más, no tiene más que mandarme un correo a alvaro@gici.cl

Mobile, Genexus y BlackBerry

Después de mucho tiempo por fin puedo continuar con este agradable hábito del blog, les pido las disculpas por el abandono.
En esta oportunidad les quiero conversar sobre un tema que si bien no guarda una relación directa con Genexus, si es bastante interesante y, curiosamente, ha sido motivo de varios correos que me han llegado en el último tiempo de parte de algunos de los suscritos al foro. Me refiero al estado del arte de las plataformas y aplicaciones mobile en general y, en particular, de la plataforma BlackBerry.
Para comenzar debo advertirles que GiCi, la compañía en que trabajo (o eso parece al menos), tiene un área de desarrollo específica para esa plataforma, siendo uno de los pocos ISV en Latinoamérica. Ahora, no comercializamos aparatos ni nada por el estilo, solo adoptamos la arquitectura para nuestros proyectos y productos futuros, por lo que de alguna manera tengo una visión quizás algo sesgada. Trataré de ser claro y objetivo en mis opiniones. También trataré de explicar las diferencias con las arquitecturas más conocidas y contarles acerca de algunos proyectos que hemos realizado, que involucran a esta tecnología y a Gx.
Hace algunos meses, en un blog de Genexus Planet recuerdo haber leído un post de alguien de Artech (que me disculpe por no recordar su nombre) que comentaba entre otras cosas que a su parecer el mercado validaba la opción de Artech de optar por PPC y que esta tecnología había tenido un crecimiento muy superior a las demás. Desde mi punto de vista, el análisis del mercado mobile debe considerar varias aristas, al menos una tecnológica y una comercial.
En nuestros días la tecnología móvil está experimentando un fenómeno ya conocido: el de la “convergencia tecnológica”, pero con una fuerza aún mayor que otras industrias. Para los que no la hayan escuchado nombrar antes, se trata básicamente de que toda la electrónica que nos rodea en casa, en el trabajo y en la calle, pueda comunicarse e interactuar entre sí, ojalá en los menos dispositivos posibles. De ahí que ya no nos extraña que, por ejemplo, los celulares modernos tengan radio, reproductor MP3, cámaras de alta resolución, GPS, etc. Todo indica que la tendencia seguirá por este camino, pero esto mismo está provocando que los caminos tecnológicos de las soluciones de negocios y las de “consumo” (para ponerles un nombre) tomen caminos drásticamente diferentes. Por una parte, elementos como las memorias portátiles de estado sólido que se conocen como “pen drivers” están evolucionando a reproductores mp3 y a computadores de bolsillo que incluso permiten navegar por wi-fi. También los celulares están incorporando cosas nuevas y dentro de poco ya no será necesario portar varios artefactos diferentes al estilo Batman para escuchar música, hablar por teléfono y tomar fotos de calidad. Ahora, ¿las empresas adoptan estas tecnologías para sus soluciones de negocios?, ¿las grandes compañías comprarán iphones para sus ejecutivos?, ¿se desarrollará un mercado de soluciones mobile para ERPs basadas en Nokia o en IPaq?. Desde mi punto de vista, no.
El mercado de las soluciones empresariales móviles ha sido fuertemente potenciado por las problemáticas asociadas a la logística, a los ERPs y a la necesidad de mayor competitividad, lo que se traduce de alguna manera a mejorar el “time in market” de los procesos de negocios, haciendo necesario mejorar la eficiencia de los procesos, la oportunidad de ellos y la conectividad de los involucrados en las decisiones. La bajada estrepitosa de precios de los notebooks ha traído como consecuencia que la cobertura de la conectividad inalámbrica mejorara substancialmente, razón por la que cualquiera puede revisar sus correos, trabajar en planillas o documentos, quitando un elemento fundamental a la estrategia de las PDA. De hecho, mi IPaq la uso casi exclusivamente como una suerte de “IPOD”, para aprovechar las tarjetas de memoria que he comprado en el tiempo.
Pensemos por un momento en las soluciones basadas en Genexus. Si por ejemplo, tenemos un ERP que requiere un flujo crítico de aprobación de órdenes de compra que no debe parar nunca, sería tremendamente aconsejable incorporar en la solución una aplicación móvil que le permita a los ejecutivos revisar estas tareas en línea desde donde se encuentren, ya sea en sus casas, fuera de la oficina, en el extranjero, etc. Bueno, hoy la única alternativa que existe en Gx es utilizar el generador .Net para PPC. Sin embargo, tenemos que resolver algunos temas técnicos propios de la plataforma. Por ejemplo: ¿qué pasa si donde está el usuario no hay red inalámbrica (situación aún no poco común en sectores rurales, ciudades de provincias e incluso en algunas capitales)?, ¿la transmisión de los datos es segura, tanto en términos de confidencialidad como de integridad de ellos?, si hay 100 usuarios de esta solución repartidos geográficamente, ¿cómo mantenemos actualizadas las IPaq con la última versión de nuestra aplicación?, si a algún usuario le es robado el dispositivo, ¿podemos bloquear rápidamente el acceso a los datos desde ese aparato?, ¿tiene la aplicación desarrollada una conectividad en línea con las bases de datos de la compañía?, ¿qué pasa con la obsolescencia tecnológica de los aparatos?, ¿puedo garantizar que nuevas versiones de la aplicación correrán en nuevas versiones del hardware?. Bueno, preguntas como estas son típicas cuando una compañía evalúa proyectos que involucran tecnología mobile. Volviendo al ejemplo, la mayoría de las respuestas de esas interrogantes serían insatisfactorias. Es cierto que existen IPaq con telefonía y modelos con algunas características superiores, pero el costo que tienen hacen la mayor parte de las veces el proyecto inviable. Desde mi punto de vista, estas son algunas de las mayores limitantes que existen para el crecimiento y consolidación de este tipo de soluciones. El que mi PPC me permita ver y trabajar en un Excel, revisar mi mail o escuchar música no es nada especial, muchos teléfonos hacen eso, sin mencionar que al menos en Santiago de Chile, existe muy buena cobertura wi-fi (incluso en algunas estaciones del tren subterráneo) por lo que puedo conectarme con mi notebook a Internet desde casi cualquier parte, por lo que si un ejecutivo pretende adoptar la tecnología PPC para soluciones corporativas en su compañía, esperará valor agregado en los elementos que justamente están fuera de la famosa “convergencia tecnológica”.
Por otra parte, una segunda lectura de las estadísticas del mercado global permite darnos cuenta de este fenómeno, que un crecimiento mayor en algunas plataformas puede significar simplemente que se están haciendo masivas en un segmento de mercado que no necesariamente es el mismo al que apunta Genexus. Creo que son más decidoras aquellas que reflejan el crecimiento de los proyectos mobile y las arquitecturas implementadas, verán que no son iguales. No les daré cifras acá, no es el objetivo de mi post, pero en Internet podrán encontrar mucho material al respecto.
Espero que se hayan entendido los conceptos que quise tratar acá. En el próximo post que espero sea pronto, les contaré algunos detalles sobre la arquitectura BlackBerry, como propone solucionar las problemáticas que enuncié y cómo la hemos usado en conjunto con Genexus.

Servicios y otras hierbas

Hasta ahora ya entendemos lo que son los Servicios, BPM, ESB y conocemos algunos conceptos claves como "Orquestación". Sin embargo, hasta ahora no hemos hablado respecto a el impacto que esta arquitectura tiene en la manera de enfrentar los desarrollos y en las herramientas que usamos o deberíamos utilizar...Genexus entre ellas.
En este punto es cuando debemos invocar al menos común de los sentidos, el sentido común. En general, no existen reglas fijas para este tipo de problemáticas, escencialmente porque la manera de enfrentar los proyectos va muy relacionada con el estilo de las empresas, su infraestructura y la experiencia que tengan los arquitectos y desarrolladores. Trataré de dar algunas ideas para que ustedes mismos vayan dándose cuenta de la manera en que conviene ir desmenuzando este tema, retomando el ejemplo inicial.
Lo primero, revisemos la definición inicial que hicimos y como lo fuimos armando en el BPM. A primera vista (por temas de tiempo y espacio no seré demasiado riguroso en estas cosas) podemos determinar los siguientes puntos de contacto:

1) Recepción de las planillas electrónicas con las carteras.
2) Ingreso de los datos en el sistema.
3) Revisión de antecedentes comerciales en un proveedor especializado.
4) Enviar la solicitud de verificación de domicilio y recibir el resultado.
5) Cargar aquellos que pasen los filtros en el motor de reglas.
6) Cargar algunos en el sistema de Call Center.
7) Inyección de registros en la base de datos de clientes, en el AS/400.
8) Envío a los sistemas internos para la creación del o los productos.
9) Integrar uno o más puntos del flujo con SAP
10) Herramientas de consulta y gestión.

Bueno, esta primera mirada no es nada de profunda ni detallada, pero así y todo ya tenemos 10 cosas en las que pensar. Si somos un poco observadores veremos que hay dos tipos de integraciones en la lista...las que interactúan con sistemas propios (y por tanto tenemos algún control) y las que corresponden a interacciones con sistemas de terceros. Este es un punto clave. Una de las promesas de SOA es que viene a resolver los temas de integración hacia adelante y hacia atras con clientes y proveedores, ya que define estándares y herramientas comunes para el traspaso de información. Curiosamente este es el aspecto más débil de SOA actualmente. Aún no existe un acuerdo claro entre empresas, ni SLAs definidos para la integración con terceros, aunque se está avanzando en la materia. Sigamos, veamos el primer tipo de integraciones:

Aquí la cosa se pone algo más técnica. Debemos comenzar a trabajar con el arquitecto de abordo para encontrar las alternativas más eficientes y prácticas de desarrollar los servicios e integraciones. Por ejemplo, la inyección en nuestros sistemas de los datos recibidos es algo relativamente sencillo, pero debemos determinar cosas como "¿la inyección será registro por registro en forma sincrónica o todos juntos asincrónicamente?"...esto puede ser relevante, ya que posteriormente podríamos decidir que los procesos de inyección serán diferentes según el origen de los datos o el tipo de negocio. En términos del desarrollo, si nuestra plataforma de desarrollo es java, quizás nos convenga más pensar en exponer estos servicios como ejbs y no como web services, ya que en procesos masivos estos últimos no tienen muy buen rendimiento.
Otros puntos que presentan desafíos interesantes son el 5, el 9 y el 10. El caso real que tomé para este ejemplo involucraba la integración con Expirian, un software bastante conocido en el mundo financiero y del retail, el cual presenta dos modalidades de integración: web services y un run time que corre en diversas plataformas. Si ocupamos la primera alternativa, el camino a seguir es bastante claro aunque, como dije anteriormente, con grandes volumenes transacionales podríamos llegar a tener problemas. En ese caso, optamos por la segunda alternativa, encapsulamos el runtime en un objeto java y lo expusimos vía RMI.
La integración con SAP puede ser un gran dolor de cabeza si no se tiene experiencia en el tema. Para no ahondar demasiado en esa problemática, solo les comentaré que básicamente hay cuatro manera de integrarse dentro de una arquitectura SOA con SAP...lo primero es utilizar una herramienta que antiguamente SAP proveía en forma gratuita, pero que actualmente está descontinuada: "Business Connector". La segunda es comprar y utilizar los conectores propios de cada proveedor, según el WAS, mensajería o ESB que estemos utilizando; lo típico son los conectores para SAP de IBM, BEA, MQ, etc. La tercera opción es usar la plataforma NetWeaver de SAP, siempre se que se tenga la versión de R/3 correcta y se hayan comprado, instalado y configurado los componentes para SOA. La tercera es usar nuestro middleware de integración con SAP, que resuelve el problema...jeje...obviamente, es lo que utilizamos en nuestro proyecto.
Si les llama la atención el que haya puesto la gestión y la reportería como puntos de integración, entonces se los aclaro. Muchas veces (y fue el caso del proyecto) la gerencia solicita poder acceder a los indicadores de gestión y a los datos resumen desde diversas plataformas, incluidos sitios web, dispositivos mobile, etc., por lo que siempre conviene incluir estos elementos en el diseño para poder ofrecer flexibilidad a los usuarios.
Ahora vayamos de atrás hacia adelante. Desde Genexus no es muy difícil desarrollar procedimientos que entreguen datos resumen y/o totalizados. Si estos procedimientos se implementan a manera de "reportería sin presentación", podemos generarlos como web services para ser expuestos hacia diferentes clientes, entregando los reportes como XML. Respecto a la interacción con SAP, si optamos por GiOne o por Business Connector, no deberemos preocuparnos por desarrollos en la capa del servidor de aplicaciones, pero las otras opciones implicarán desarrollar algún grado de encapsulamiento de los conectores para lograr exponer como servicio la conectividad.
En general, este tipo de problemáticas se repite en la mayoría de los casos. No hay recetas, pero si les puedo comentar algunas cosas que nos ha enseñado la experiencia:

• Los web services son una gran solución para las necesidades de integración on line donde no se conoce a priori el tipo de cliente que se tendrá.
• Cuando a partir de un flujo se requiera exponer datos resultantes, es una buena idea generar el servicio desde el mismo ESB, en vez de desarrollar un componente aparte. Esta es una capacidad de casi todos los ESB.
• Es importante tener claro el tipo de interfaz a utilizar (SOAP, Pipe, DataQue, FTP, etc) desde etapas tempranas para cada servicio.
• Un elemento fundamental es tener un control de cada uno de los servicios disponibles y a desarrollar, para evitar duplicar esfuerzos inutilmente. En otro post hablaremos del concepto de "Governance".

ESB...el corazón de SOA

Primero que todo, les presento mis disculpas por la demora en continuar el blog, pero he tenido muchísimo trabajo estas últimas semanas y no he tenido tiempo para nada. Retomando el post anterior, en esta oportunidad hablaremos sobre el componente tecnológico central en una arquitectura SOA: el ESB.

Como se habrán dado cuenta, casi todo en esta tecnología recibe como nombre un acrónimo referenciando las cosas que hace...esta no es la excepción a la regla. ESB="Enterprise Service Bus". En términos muy simples, un ESB es un middleware que se preocupa de todos los aspectos de la conectividad e integración entre las aplicaciones clientes y los servicios y datos en la capa de backend. En el reside la resposnsabilidad de ejecutar el flujo, las orquestaciones y en general, todas las labores que guardan relación con la ejecución de los servicios.
Veamos esto con un poco más de detalle. Un ESB debe cumplir con las normas definidas en el patrón de integración VETRO, otro acrónimo, que indica y define las labores del ESB:

(V)alidation.

Se encarga de realizar la validación de la mensajería involucrada, generalmente basada en estándares, como por ejemplo, validar el XML de entrada contra su respectivo XSD u otras validaciones de estructuras del mismo estilo.

(E)nrichment.

Corresponde al enriquecimiento del mensaje inicial del cliente con la información necesaria para la invocación del servicio final. En la mayoría de las ocasiones, este enriquecimiento es generado en llamadas a servicios de negocio, adicionando información al mensaje en tiempo de ejecución.

(T)ransformation.

Es la transformación del mensaje original a algún otro formato que sea requerido por el servicio final. Por ejemplo, utilizar Xquery para trasformaciones entre archivos XML, de pipe a XML, etc.

(R)outing.

Consiste en el ruteo del mensaje a diferentes servicios, de acuerdo al contenido de este, a la operación, tablas de configuración, etc.

(O)perate.

Comunicación con el servicio final, es decir, con los servicios de negocio. Para estos efectos se vale de una serie de conectores que cumplen una norma en particular y que solucionan la problemática de conectividad puntual.

Adicionalmente, sobre los ESB podemos agregar:

• Un ESB es distribuido, no corresponde a la arquitectura clásica de los middleware de mensajería, por lo que se puede distribuir en toda la red física.

• Está basado en un sistema de mensajería o Message Oriented Middleware, lo cual permite manejar muchos escenarios de manera asíncrona.
  
• Permite el monitoreo detallado de niveles de servicio.

Como verán, estos estándares VETRO trabajando en conjunto, implementan lo que se conoce como “Orquestación”. En resumen, la Orquestación es la implementación de la interoperabilidad, la transformación y control de un flujo de datos a través de los servicios involucrados en el proceso. Generalmente se implementa en el ESB vía BPEL, un lenguaje parecido a un "XML potenciado".

Existen multiplicidad de ESBs en el mercado. Lo habitual es que las compañías que tradicionalmente han ofrecido servidores de aplicaciones ahora los publiciten como "SOA Compliant" y lancen un producto adicional tipo "XX ESB". Es el caso de IBM, BEA, etc. Sin embargo, también existen algunos productos Open Source muy interesantes y que no tienen mucho que envidiar de los comerciales. Las principales diferencias están dadas por la integración con la plataforma nativa (obviamente IBM ESB anda muy bien en WebSphere...) y por lo potente de las herramientas gráficas que los administran. Pero en el fondo, casi todos los ESB hacen lo mismo. Nosotros en GiCi optamos por sugerir MULE ESB a los clientes que no cuentan con una plataforma previa, es un ESB Open Source que anda muy bien y que ha llegado a un muy alto grado de madurez, incluso mayor que el de muchos productos empaquetados, ya que es uno de los primeros que salieron al mercado. Les contaré un poco más de el:

• Es una plataforma de mensajería. Está diseñado para la implementación de arquitecturas orientadas a servicios. El núcleo de Mule es un contenedor de servicios basado en SEDA (staged event-driven architecture).
  Mule administra componentes llamados UMOs (Universal Message Objects), que en la práctica son plain old java objects, lo que se traduce en una gran facilidad para la construcción de nuevos conectores a plataformas no incluidas inicialmente. Nosotros hemos construido algunos y podemos dar fe de que es relativamente sencillo.
  SEDA:
  Significa “arquitectura por etapas gatillada por eventos”. Es utilizada en el desarrollo de sistemas que procesan grandes cantidades de mensajes en forma concurrente basándose en el diseño de la lógica de negocios en etapas independientes y que se intercomunican por medio de colas de mensajes.
  
  
• Contenedor de aplicaciones. Mule actúa como un contenedor de aplicaciones sencillo y robusto, integrado de forma transparente a sistemas externos con los estándares de comunicación más conocidos. El desarrollo de componentes se basa en el estándar más sencillo de Java (plain old java objects), evitando la complejidad innecesaria de J2EE.

• Plataforma para proceso masivo de mensajes. Mule provee la plataforma ideal para la construcción de aplicaciones de procesamiento masivo de mensajes, agregando inmediatamente a la solución la administración, monitoreo, log y configuración centralizadas, que son propias del producto.
  
  
• Administración gráfica centralizada de los componentes. La operación de cada componente por separado puede ser controlada, por ejemplo, pausando y encolando los requests para solucionar problemas eventuales en otras etapas del proceso.
  

• Monitoreo de los componentes. Estadísticas en tiempo real del comportamiento de los componentes pueden ser observadas en la consola del sistema
  

En resumen, el ESB es la pieza de software que coordina y ejecuta los flujos y servicios, entre otras cosas. En este punto, ya deben tener muy claro el por qué una colección de servicios no define por si mismo una arquitectura SOA...

Volviendo al ejemplo de la entrada anterior, luego de haber diseñado los flujos en el BPM podríamos pensar que generando el BPEL e instalándolo en el ESB ya estaríamos en condiciones de realizar las primeras pruebas...pero no es tan así. En el próximo post seguiremos avanzando en esta materia.

¿Y con SOA...?

Pensemos ahora en cómo podríamos enfrentar esto con SOA.
Lo primero es modelar el proceso, sin preocuparnos inicialmente de su implementación técnica. ¿Conocen el BPM de GxFlow?...existen variadas herramientas de modelamiento de negocio que tienen un gran parecido con el, se les conoce justamente por esas siglas, BPM (Business Process Modeler). En general, cada gran compañía de software cuenta con una asociada a sus productos base, IBM, SAP, etc. También existen alguas open source bastante buenas, tales como JBossBPM, Intalio, etc. Lo que todas ellas tienen en común es que además de poder modelar y validar los diseños gráficamente permiten definir en línea las interfaces necesarias para la conectividad en cada nodo del proceso, ya lo explicaré con más calma. Lo otro fundamental es que, una vez finalizado el diseño del proceso, se genera una metadata en un lenguaje llamado BPEL, el que puede ser leído e interpretado por los diferentes ESB. Esta metadata contiene la lógica asociada al "workflow", las integraciones y la orquestación de los diferentes servicios involucrados.
Siendo más "simplistas": con la herramienta BPM se diseña el diagrama de flujo involucrado con el mayor detalle posible, identificando los puntos de integración. Por ejemplo, el primero sería la obtención de la información "materia prima" para la evaluación. Definimos el set de datos necesario (RUT o DNI, nombre, fecha de nacimiento, etc.), sin saber a priori de donde saldrían. Lo mismo en cada punto de contacto, la validación comercial, la validación de domicilio y así... Entonces, nos sentamos con los usuarios líderes de negocio y definimos este diagrama. Una imágen típica de como se ven y trabajan estas herramientas es esta:

En este punto comenzamos a ver un poco más de detalle. Estas famosas cajitas la mayoría de las veces requieren interactuar con uno o más servicios, por lo que deberemos especificar en este punto la interfaz y datos que intercambiaremos. No entraré en el detalle de la manera técnica en que esto se hace, pero es fundamental tener claro el set de datos que se inyectará a cada servicio y la información que estos retornarán; es algo muy parecido a lo que se suele hacer en un motor de Workflow. Otros elementos que se deben indicar en esta etapa son las transformaciones que irán sufriendo los datos a medida que el proceso avanza y se van ejecutando los diversos servicios involucrados. Esto puede parecer bastante sencillo, pero habitualmente las principales dificultades en el diseño se dan en el manejo de las integraciones con los servicios y en lo complicado de llegar al nivel de detalle necesario para lograr una implementación eficiente.

Si se fijan bien, un subproducto de este proceso es que tenemos la especificación de varios de los servicios algo avanzadas. Sabemos lo que deben recibir, retornar y lo que deben hacer en términos funcionales. También sabemos cuantos de ellos intervendrán en nuestro modelo y la criticidad de cada uno.

Por lo general, los BPM generan una metadata en un lenguaje llamado BPEL, el que contiene la "programación" de las transformaciónes e integraciones que acabamos de construir. Estos archivos serán posteriormente ejecutados por el ESB, lo que se conoce habitualmente como "Orquestación". En la entrada siguiente le daremos una mirada a lo que es un ESB.

Vamos al grano...

Bueno, me arrepentí...

Dije que ahora les hablaría de las ventajas y desventajas de ir a SOA, pero los minutos bajo la ducha de esta mañana me hicieron entender que antes de eso sería mejor seguir con lo que he estado comentando hasta ahora. En el post anterior traté de explicar de alguna manera lo que son los servicios y algunas de sus características. Ahora, ¿por qué SOA no es solo una colección de servicios?. Creo que lo mejor es tratar de responder a esta pregunta con un caso práctico, muy cercano a un proyecto real que hicimos hace un tiempo.

Imaginemos que trabajamos en un Banco (al menos yo debo hacerlo, quizás tu si trabajes en uno...) y que debemos enfrentar la labor de implementar un sistema de evaluación de riesgo de potenciales clientes. El escenario es el siguiente:

Tenemos una serie de captadoras de empresas externas dando vueltas por la ciudad, ofreciendo un producto financiero a la gente que sale de los centros comerciales, cines, etc. Ellas actualmente llenan unas hojas en papel con una lista de datos, las que posteriormente son digitadas en una planilla excel y enviadas cada noche por correo electrónico a los analistas de riesgo del Banco. Estos últimos deben redigitar la información en los sistemas departamentales internos (VB-SqlServer), consultar los antecedentes comerciales de los postulantes en una página web de la cámara de comercio y luego enviar una lista de solicitudes de validación de domicilio a una empresa que hace esas labores. Sólo estos pasos toman de 3 a 5 días hábiles. Una vez retornada la información se deben filtrar los registros que presenten protestos o morosidades, aquellos a los que no se les pudo comprobar domicilio y luego recién cargarlos en un motor de reglas corporativo que se le compró a una empresa de software extranjera (Java-Oracle). Este sistema retorna un set de datos calificando a los posibles clientes; algunos deben ser contactados por el call center (CTI) para obtener algún dato adicional, otros deben ingresarse al sistema de clientes de la compañia (que corre en AS/400) y se debe dejar registro de los rechazados, para que sirva de filtro si la misma persona vuelve a postular. Finalmente, a todos aquellos que pasaron exitosamente el proceso se les debe contactar y generar la documentación para ser firmada y acticado el producto.

Bueno, pensemos el desafío de una manera convencional. Para comenzar, salta a la vista el problema de la conectividad, son plataformas diversas y a algunas de ellas es bastante complicado integrarse. Otra cosa es diseñar el modelo de control, es decir, ver desde donde se va a monitorear el flujo completo del proceso, se irán gatillando cada una de las etapas, se tomarán las decisiones de acuerdo a los resultados y, por último, resta definir la plataforma tecnológica. Ahora supongamos que se nos comunica que el Banco acaba de comprar SAP y que deberá incluirse en los flujos, llegado el momento...y para colmo, el Gerente de Riesgo nos pide que veamos la manera de flexibilizar la operación del producto para que los analistas financieros puedan modificar los flujos de acuerdo a las variaciones del mercado...¡toda una pesadilla!.

De buenas a primeras a alguien con experiencia se le podría ocurrir que requerirá un motor de workflow y muy probablemente un middleware tipo MQSeries. Sin embargo quedan un montón de cosas que resolver, además de la manera en que integraremos esos dos productos con el resto. Muchos de ustedes ya deben estar imaginando la forma de implementarlo en Genexus, algunos DataViews, GxBPM, etc.
En el post siguiente conversaremos el detalle de como podríamos enfrentar esta problemática desde un punto de vista SOA.

Partamos con algo más técnico

SOA es el acrónimo de Service Oriented Architecture, o Arquitectura Orientada a Servicios. No hay que ser muy despierto para darse cuenta que SOA corresponde a un modelo tecnológico basado en servicios. Hasta ahí todo bien...pero si preguntamos a un grupo de 50 personas relacionadas con IT "¿qué es un servicio?", les aseguro que se sorprenderían de las respuestas. Entonces, partamos revisando lo que es un servicio:

La Real Academia de la lengua Castellana tiene 10 acepciones para servicio, entre ellas "retrete", "urinal" y "enema"...mal comienzo. Quizás en Wikipedia..."Servicio es un conjunto de actividades que buscan responder a una o más necesidades de un cliente." Mucho mejor.

Si buscamos más a fondo encontraremos muchas definiciones, pero la gran mayoría de ellas coincidirán en los puntos siguientes.

• Un servicio es "atómico". En otras palabras, realiza una tarea puntual que no es divisible en tareas menores (esto no siempre es cierto, pero es lo suficientemente habitual como para considerarlo verdadero).
• No conserva relación con otros servicios. Un servicio no depende del estado de otros "congeneres". Nada más egoista y huraño que un servicio, nunca debe tener ninguna relación operativa con otros servicios. Eso no quiere decir que no puedan trabajar en conjunto, pero cada uno de ellos debe poder realizar su labor propia con total independencia.
• Un servicio es independiente de la forma en que se implemente. Esto es muy importante, aunque suene algo raro. Es como decir que las personas son personas por su alma, independiente del cuerpo en que estén atrapados...¿muy esotérico?. Entonces como le suele gustar a los informáticos: "un servicio tiene total independencia de su implementación e interface y no guarda datos de contexto".

Ahora en cristiano: Los servicios son pequeños programas que cumplen una labor de negocio puntual y acotada y que trabajan en conjunto, pero independientemente unos de otros. Algo así como "juntos, pero no revueltos".
Luego, ¿si genero mis programas en muchos pedacitos pequeños y los publico como web services, habré entrado al selecto mundo SOA?....lamentablemente no. La arquitectura SOA es orientada a servicios, pero los servicios sólo son una parte de ella. Mirando desde más arriba:

• SOA utiliza servicios individuales para construir redes de inter operabilidad. Esto quiere decir una de las ideas centrales de SOA es construir grandes mapas de procesos a partir de servicios que solucionen cada uno de los pequeños nodos de ellos, haciéndolos trabajar de manera coordinada. Más adelante veremos esto, cuando hablemos de orquestación.
• Estos servicios se pueden ejecutar en unidades discretas de trabajo, lo que permite desacoplar fuertemente servicios, lógica y presentación. Recordemos la aparición triunfal que tuvo hace muchos años la arquitectura cliente/servidor. Planteaba la separación de la lógica de negocios de la de presentación, pero con el tiempo se fue descubriendo que no siempre se podía poner este tipo de procesamiento en los DBMS. Luego vinieron las arquitecturas en tres capas, ellas permitieron la separación real de la lógica, pero tienen la problemática de la disponibilización y la baja portabilidad. Con SOA podemos tener baterías de servicios que implementan completamente grandes y complejos procesos, quedando disponibles para cualquier tipo de cliente o sistema con independencia de su presentación. Un servicio puede ir desde la validación de un dígito verificador hasta la validación de crédito de un cliente.
• Resuelve las problemáticas generales y particulares de conectividad. Este es otro elemento fundamental que diferencia a SOA de arquitecturas anteriores. Un buen ESB (ya veremos más adelante de que se trata) nos permite trabajar con casi cualquier fuente de datos con total independencia y flexibilidad. Por ejemplo: en un proceso cualquiera podemos incluir datos que vengan de una planilla Excel, una puerta serial, un GPS, Oracle, SAP, COBOL o cualquier otra fuente digital de información sin preocuparnos de su capa de conectividad!!!!. Suena mágico...y a veces lo es.
• Una arquitectura que permite una real reusabilidad masiva. Esto es bastante claro. Un servicio no se desarrolla sólo para una aplicación. Si tengo uno que trae los datos de un cliente, puedo usarlo desde cualquier aplicación de índole comercial.
• Permite una gran independencia de las plataformas, rentabilizando las existentes. Como he mencionado anteriormente, SOA no es un producto. Sí, se requieren algunos productos de software para implementarla, pero cuando está operativa permite potenciar las plataformas legacies. Un ejemplo típico es SAP. Desarrollar nuevas funcionalidades dentro de este ERP es un proceso complejo, caro y lento, pues requiere programadores y consultores altamente especializados, sobre todo cuando debe interactuar con otras aplicaciones. Con SOA podemos desarrollar servicios que implementen estas funcionalidades yendo a SAP a través de un conector para R/3 sin necesidad de grandes desarrollos ABAP. De esta forma podemos hacer crecer las funcionalidades de SAP desde las plataformas ya existentes en nuestra empresa.

Antes de terminar esta entrada preguntémonos: "¿La implementación de los servicios se hace a través de web services?"...y la respuesta correcta es.......NO!!! (o al menos, solo a veces).
Un web service puede ser la interface de un servicio, es decir, la manera en que se publica para que sea usado por clientes, pero así mismo un servicio puede tener más de una interface. Por ejemplo, imaginemos que desarrollaremos un servicio que nos entrega los datos personales de un cliente. Lo usaremos en nuestro CRM que está desarrollado en JAVA, en los terminales de auto servicio que están en .NET y en los sistemas de backoffice que corren en COBOL en un AS/400. Si pudiéramos exponer este servicio como EJB, web service y DQ al mismo tiempo podríamos sacarnos el problema de encima. Bueno, eso es justamente lo que se hace, separar la implementación del servicio de su interface de publicación. Bonito, ¿cierto?
En la próxima entrada conversaremos sobre las ventajas y desventajas de ir a SOA.