Introducción
Durante los últimos veinticinco años, el servidor iSeries, orgullo de IBM y conocido sucesor del AS/400, ha sido implementado a gran escala en pequeñas y medianas empresas (PyME). Esta computadora de rango medio sigue siendo objeto reconocida por su facilidad de uso, confiabilidad, flexibilidad y capacidad de graduación. Sin embargo, debido a que carece de una interfaz gráfica de usuario (GUI) y que su integración con otros productos es débil, su uso ha disminuido y los usuarios han optado por sistemas más fáciles de usar basados en Windows e INTEL.
IBM trató de resolver este problema con WebSphere. La base del desarrollo de software de iSeries eran conceptos Java como Enterprise Java Beans, HTML y servidores web.
Sin embargo, la comunidad de iSeries no estaba recibiendo bien esta solución nueva y para muchos de sus desarrolladores, seguía siendo algo lejano. No querían una revolución radical, sino una modernización paso a paso de sus aplicaciones empresariales. Esto se debía a que, sin contar algunos paquetes de software estándar, gran parte de sus soluciones de TI son hechas a la medida y sirven para almacenar todo el conocimiento y la experiencia de una empresa. La idea detrás de la modernización de las aplicaciones empresariales es la renovación del software existente de forma que satisfaga la necesidad de integración y la presentación gráfica sin perder su funcionalidad.
Java es un lenguaje ideal para desarrollar soluciones de tecnología de la información y las comunicaciones porque puede responder a las necesidades de los usuarios y, al mismo tiempo, ajustarse al patrón de diseño modelo-visualización-controlador aceptado en la industria.
El marco de trabajo que se describe a continuación muestra cómo al combinar Java en el lado del cliente y un motor integrado de lenguaje para la lógica del negocio y el acceso a las bases de datos en el lado del servidor, se puede obtener una interfaz gráfica de usuario y abrir la posibilidad a la integración del software de terceros. Un buen ejemplo es la integración de las aplicaciones legadas a un ambiente nuevo tipo Windows. Esta capacidad de integración permite llevar a cabo una modernización paso a paso de las aplicaciones del negocio.
Arquitectura
Todos los marcos modernos de trabajo para el desarrollo de software son intrínsicamente una arquitectura de niveles múltiples formada por lógicas del negocio, lógicas de presentación y el controlador. La lógica del negocio se encarga de la gestión de las bases de datos y las transacciones que las acompañan; la lógica de presentación se usa para presentar datos al usuario mediante una interfaz intuitiva y el controlador interactivo dirige el flujo entre los sistemas frontal y trasero. Esta arquitectura puede representarse con la estructura de un cojinete de bolas (figura 1).
Figura 1: Arquitectura de niveles múltiples representada con la estructura de un cojinete de bolas
Al usar la arquitectura de niveles múltiples para diseñar software, se presenta la solución a problemas que ocurren en tres niveles diferentes: permite tener un rendimiento y reutilizar la lógica del negocio en iSeries, tiene un marco de trabajo para la construcción de aplicaciones complejas rich-client y ofrece un conector Java que se puede usar de forma genérica para la lógica del negocio de iSeries.
La lógica del negocio de iSeries
Una de las razones principales por las que la mayoría de los talleres iSeries buscan e incorporan tecnologías nuevas es la necesidad de tener interfaces de apariencia moderna y una integración con el software que no es de iSeries. Aunque durante años IBM ha sido uno de los principales predicadores de Java (basta pensar en WebSphere), muchas empresas iSeries siguen oponiéndose a dar el salto y empezar a usar Java, J2EE o Enterprise Java Beans. Es posible que las empresas carezcan de las habilidades y los conocimientos técnicos necesarios para implementar Java, o que se preocupen por la coexistencia, la integración y la capacidad de reutilización que requieren las aplicaciones iSeries actuales. También pueden tener reservas con respecto al desempeño, la estabilidad y la manejabilidad de las aplicaciones J2EE. Sin embargo, con frecuencia las empresas dudan y tienen cuidado de las consecuencias que puede tener la tecnología nueva en su lógica del negocio.
Para implementarla, es necesario reorientar el conocimiento técnico de iSeries. De modo específico, hay que trasponer las necesidades de experiencia en el campo a un contexto Java, que de acuerdo a varias empresas no ha demostrado suficiente valía. Para disipar estos miedos, IBM lanzó una nueva situación como parte de su estrategia de evolución para los clientes de iSeries. La situación inicia con el contexto transaccional actual de iSeries, modular las aplicaciones existentes y separar la lógica de interfaz de usuario, que será desarrollada mediante tecnologías nuevas de punta. En la versión 3.0 del plan de trabajo1 de IBM, la empresa confirmó que tanto los rich-clients como los web-clients son objetivos aceptables en el plan de los desarrolladores de iSeries, ya que la mayoría de los usuarios no son usuarios web.
El ambiente de lenguaje integrado (ILE) de iSeries es el ambiente perfecto para construir una lógica transaccional que pueda ser graduada y que tenga buen desempeño para iSeries. El bien pensado uso de los conceptos de trabajo y memoria del sistema operativo, combinado con los programas de servicio, los grupos de activación y RPG modulado, presentan el potencial necesario para crear un contexto transaccional invencible que sea capaz de responder rápidamente a las solicitudes entrantes. Ya se ha comprobado el valor de reutilizar la plataforma y la experiencia adquiridas de ILE, haciendo de ellas las dos ventajas principales de dicha estrategia.
Al usar generadores de código para crear esqueletos de código para las rutinas de la lógica del negocio, el desarrollador sólo tiene que centrar su atención en los aspectos de las aplicaciones del software. Estos generadores de esqueletos (a diferencia de los verdaderos ambientes 4GL) van más allá, cuando es necesario, del nivel de aplicación y, por ejemplo, construyen bases de datos de memoria (bases de datos virtuales) o incrustan SQL en el código generado. Las herramientas de desarrollo 4GL generan seudo código y, en general, no tienen mucha flexibilidad en los ambientes de negocios complejos.
Es cierto que el resultado más importante es un contexto transaccional y una lógica del negocio correspondiente que son accesibles universalmente y que pueden llamarse desde cualquier forma de presentación, no sólo para desplegar los datos, sino para lanzar las transacciones. Es posible escribir la lógica del negocio una vez y reutilizarla en cualquier parte con un desempeño controlado. La parte interna del cojinete representa esta parte del marco de trabajo.
1. Cfr. http://www-1.ibm.com/servers/enable/tools/innovation/roadmap.html
Aplicaciones rich-client
Como se mencionó antes, la demanda de interfaces de usuario modernas es, con frecuencia, la razón principal detrás de la búsqueda de tecnologías nuevas y arquitecturas de aplicación. A veces, las empresas consideran construir su extremo frontal con HTML. A pesar de las ventajas obvias que implica dicha organización, como la gestión centralizada del servidor web, etc., cada vez son más los profesionales que se enfocan en las desventajas intrínsecas de HTML: un nivel bajo de interactividad, problemas con la orientación de las páginas, límites del modelo de llamada/respuesta del protocolo HTTP y la gestión limitada del estado de las aplicaciones web. Otros argumentos que se oponen a este enfoque son el conjunto limitado de componentes y metáforas de la interfaz de usuario y la ausencia de manipulación de datos inteligente en el lado del cliente. Desde el punto de vista del desarrollador, es difícil escribir aplicaciones HTML. La gestión del estado se encuentra completamente en el lado del servidor, mientras que la implementación del manejo de eventos en el cliente del servidor crea un código de script complejo, cuyo mantenimiento es difícil. Desde el punto de vista de los usuarios, las aplicaciones HTML parecen tener poca interacción y su uso es incómodo.
Las características nuevas de las API Java se enfocan principalmente en el lado del servidor, es decir, en el modelo y el controlador de las arquitecturas MVC. Sin embargo, durante los últimos años, se han lanzado algunas tecnologías innovadoras para el nivel de extremo frontal, como las páginas de servidor Java (JSP) y las superficies de servidor Java (JSF). A pesar de que estos marcos de trabajo pueden resolver algunos problemas de los desarrolladores, no serán capaces de resolver los del usuario, ya que las interfaces de usuario siguen estando en HTML.
Aunque HTML puede tener un valor agregado para ciertas aplicaciones, como la interacción con los proveedores y los clientes, gran parte de los talleres iSeries no consideran que una aplicación web sea la ruta lógica de migración para sus aplicaciones críticas del negocio aplicaciones que se desarrollaron especialmente para los usuarios demandantes dentro de la empresa. Por lo mismo, la mayoría de las herramientas como los raspadores de pantalla, los facers web y los GUIfiers se consideran como embellecedores que no ofrecen un valor agregado real. Además, la mayor parte de las empresas tienen muchas preguntas acerca del impacto que tienen las modificaciones del extremo trasero en el extremo frontal. Lo que es más notable, estas herramientas no cambian la aplicación intrínsecamente ni ofrecen cosas nuevas a los usuarios. La selección de una tecnología de extremo frontal nueva debe, al menos, llevar a más funcionalidades para los usuarios, una mayor interactividad y un despliegue intuitivo mayor de los datos. Los desarrolladores críticos demandarán rich-clients para los usuarios privilegiados de las aplicaciones críticas de una empresa, en lugar de interfaces HTML.
¿Es posible superar esta falta de un marco de trabajo estructurado para los rich-clients? El marco de trabajo que se describió en la figura 1 está formado por dos niveles externos: una capa de presentación y un controlador interactivo, ambos desarrollados por completo en Java. Todos los eventos iniciados en la capa de presentación pasan a manos del controlador interactivo. El controlador llamará la lógica del negocio adecuada o guiará la capa en consecuencia. Un controlador interactivo, conocido como gerente del flujo de trabajo, dirige la interacción entre el usuario y el sistema de extremo trasero. Note que el gerente de flujo de trabajo controla por completo la GUI, es decir que la capa de presentación en realidad se convertirá en un cliente mudo. El controlador da significado y contenido a la sesión de trabajo del usuario.
La capa de presentación y el flujo de trabajo fueron diseñados de forma que puedan separarse físicamente. Esto significa que el nivel medio puede alojarse en un servidor de aplicaciones y que las conexiones al sistema de extremo trasero pueden dividirse entre varios usuarios. También puede usarse el servidor de aplicaciones para funcionalidades extra, como iniciar los procesos de fondo para los trabajos de impresión, y el servidor puede funcionar como plataforma de ayuda en línea, etc. El nivel medio fue desarrollado por completo en Java, por eso también puede funcionar en iSeries cuando así se desee.
La primera aplicación construida por encima de este marco de trabajo es el navegador de aplicaciones gráficas (GAN). Se trata de un sistema dinámico de creación de menús que ofrece a los usuarios acceso a distintas aplicaciones que están agrupadas en menús de árbol y menús secundarios y que se denominan funciones en GAN. Al hacer doble clic en la función se iniciará la aplicación. Puede tratarse de una aplicación de flujo de trabajo de rich-client Java, pero también puede ser un enlace a un sitio web, una aplicación web o hasta una aplicación de escritorio como Word y Excel. Finalmente, la integración completa de un emulador Java 5250 hace posible el coalojamiento del ambiente GUI dentro del ambiente 5250 existente. El emulador maneja el login automático y puede lanzar la aplicación 5250 deseada. Es posible unir en este marco de trabajo las aplicaciones antiguas y renovadas, y una simple función de paso permitirá que el usuario inicie la aplicación 5250 desde su contexto GUI. Todas estas funciones hacen de la combinación del marco de trabajo y el GAN la plataforma ideal de evolución para cada ambiente iSeries.
Java Connector
Para dejar que las dos capas exteriores de la arquitectura se comuniquen con la lógica del negocio de extremo trasero, el conector debe estar escrito en Java. Para iSeries y el i5 power server, este conector usa la versión de software libre de Java Toolbox para AS/400 . Este conjunto de herramientas puede abrir todos los recursos de iSeries para tener acceso TCP/IP. En la plataforma iSeries, este conjunto de herramientas se conecta con los servidores host que son estándar en el sistema operativo i5/OS. No será necesario tener funcionalidades extra en el lado del cliente que no sean proporcionadas por Java Virtual Machine. Además de las funcionalidades existentes del conjunto de herramientas estándar i5/OS, Java Connector proporciona un mecanismo de reunión para asegurarse de que los principios de gestión y de programación del trabajo de iSeries se usan de forma óptima. Los trabajos que resulten se integran de forma transparente en los mecanismos de seguridad de iSeries para preservar el objeto y las políticas de autoridad que se adoptaron.
En el lado de Java, el conector proporciona interfaces abstractas para el desarrollador. En otras palabras, la caja de herramientas no se usa directamente para codificar las aplicaciones. Esto provoca que el conector del componente del administrador del flujo de trabajo pueda usarse de forma universal y que se puedan llamar fuentes alternativas de datos de forma transparente y simultánea. Por lo tanto, es posible encontrar datos en las bases de datos relacionales usando SQL, o desde otros objetos Java, como enterprise Java beans (EJB) que se encuentran en otros servidores, usando una invocación de método remoto (RMI). También es posible buscar datos de otras aplicaciones mediante, por ejemplo, XML y servicios web o usando la arquitectura de conector Java (JCA) actual normalizada.
De forma paralela a este acceso universal para el marco del flujo de trabajo, el conector también se encarga de la reutilización universal en ambientes Java alternativos. Esto significa que se puede reutilizar la misma lógica del negocio iSeries en el conector en cualquier ambiente Java. Es posible crear aplicaciones web fácilmente de acuerdo a HTML, servlets, páginas de servidor Java y superficies de servidor Java. Estas aplicaciones web hasta pueden generar lenguaje de marcas inalámbrico (WML) para las aplicaciones que tienen base en asistentes personales digitales o teléfonos celulares. El conector también puede usarse para generar XML para construir servicios web o para convertir XML en documentos usando hojas de estilo. Es cierto que el objetivo final es reutilizar el mismo conjunto de rutinas de la lógica del negocio iSeries para todas las formas distintas de presentación.
Además de la consolidación del servidor o del hecho que se puede usar el mismo hardware para varios sistemas operativos, iSeries también puede usarse como un servidor del negocio integrado que ofrece una mayor ventaja a las empresas con respecto a la gestión y el mantenimiento del servidor. Consulte la figura 2.
Figura 2. Centro del negocio integrado
2. http://www.ibm.com/developerworks/oss/jt400/
Resumen
Estos tres componentes, la lógica del negocio iSeries independiente de las presentaciones, un marco de trabajo rich-client y un conector Java universal, hacen posible desarrollar todos los tipos de aplicaciones de acuerdo a las necesidades. La arquitectura que resulta se presenta en el esquema siguiente.
Conclusión
Finalmente, este marco de trabajo no debe considerarse una solución fácil. Requiere que se dediquen personas motivadas e inversiones importantes en la creación de conocimiento. Los productos de software que están disponibles deben usarse al máximo. Es necesario mantener los aspectos positivos del pasado, como la base de datos, el conocimiento del negocio, y la seguridad, y enriquecerlos con las ideas y las técnicas más recientes. De esta forma, las PyME pueden evitar perder el valor de sus soluciones ICT, cuya construcción tomó tantos años. Para aquellas PyME que sienten la necesidad de modernizar y enriquecer sus ambientes ICT, JAWFLOW es una solución ideal, ya que les permite hacerlo sin correr demasiados riesgos.
La modernización de las aplicaciones empresariales y la creación de aplicaciones gráficas modernas e intuitivas puede lograrse con un software IBM estándar en el i5 power server y un software libre J2EE o Java estándar.
Acerca de los autores
Ludo Dierckx es presidente de L.D. Consulting, en Bélgica. Tiene más de veinticinco años de experiencia usando computadoras medias IBM, desde S/38 hasta i5 power server. También ha creado varios conceptos basados en ERP sobre información de gestión mediante sistemas operativos. Inició su proyecto de investigación y desarrollo en 1999.
Ambos autores dan conferencias sobre IBM y Common.