Con nuestro título, no queremos sugerir que los usuarios de System-i se estén lanzando a por SOA con la misma avidez con la que la multitud corría a buscar monedas de oro confederado en la gran película a la que hacemos referencia. Tampoco pretendemos insinuar que se estén utilizando métodos poco ortodoxos, sino que simplemente intentamos abordar algunos de los interrogantes a los que se enfrentan los usuarios de System-i cuando toman la decisión de incluir SOA en las aplicaciones de sus empresas.
La finalidad de este artículo es hablar de qué es lo bueno y lo malo de SOA –incluso a riesgo de tocar los aspectos más “feos” del tema-. Sugeriremos a los lectores por dónde empezar a la hora de optar por SOA y qué es lo que se debe evitar. Asimismo, ofreceremos nuestro punto de vista sobre el alcance de SOA y sus posibles beneficios.
SOA es el nombre que recibe un estilo de arquitectura de software donde las aplicaciones web están conectadas entre sí. Un buen ejemplo podría ser cuando alguien utiliza una web de viajes para reservar un vuelo. En este caso, el software también ofrecería reservas on-line de hoteles y coches. Los entornos que más se utilizan son JAVA y la estructura .net, que en ocasiones incluyen Servicios Web, .net assemblies y Java Beans, cumpliendo cualquier finalidad que las aplicaciones existentes tuvieran por objetivo.
Sin embargo, puede que estos estilos de programación basados en la web no tengan mucho que ver con el entorno de programación profesional de IBM. Además, no es tan sencillo integrar las grandes aplicaciones que se utilizan en las oficinas con la unidad central de IBM o con el software de alcance medio -AS400 o System-i, en este servicio web-.
La aplicación principal puede representar treinta años de inversión en software, por lo que antes de cambiar todo esto, recomendaríamos un acercamiento suave y progresivo, teniendo en cuenta factores relacionados con la arquitectura de software y con cómo se organiza la infraestructura tecnológica.
Por otro lado, si contamos con las correctas herramientas de integración, la migración a SOA no tiene por qué ser intimidatoria. Hay algunos productos middleware, o herramientas de integración en el mercado que permiten la comunicación entre System-i y los Servicios Web.
Sólo seleccionando las herramientas correctas conseguiremos que las cosas empiecen a moverse y que nuestra empresa disfrute de Servicios Web sin tener que invertir en nuevo software. Así, aprovecharemos los recursos existentes, los cuales han demostrado ya su eficacia.
Al utilizar rápidas herramientas de integración para Web Services, podemos transformar el software más antiguo en Servicios Web orientados al cliente, a pesar de la tecnología subyacente. Los cambios necesarios para obtener un Servicio Web piloto pueden estar listos en un pequeño periodo de tiempo -en la mayoría de los casos no hablamos de días, sino incluso de horas-.
Aunque SOA puede traer consigo beneficios y oportunidades de negocio, construir un servicio web puede no ser lo más efectivo en algunas ocasiones. Que su implantación sea buena o mala depende de lo que cada uno quiera conseguir con el uso de SOA.
El bueno
No hay ninguna duda de que la implementación de SOA traerá muchos beneficios. Las empresas podrán adaptarse con facilidad a las nuevas propuestas del mercado sin quedarse obsoletas y las infraestructuras IT se simplificarán, reduciendo el coste derivado de integrar los módulos de los programas ya existentes.
De hecho, las ventajas pueden ser impresionantes. La tecnología SOA es vista por los expertos como una oportunidad inmejorable para conseguir reducir los costes de la integración IT e incluir nuevo software en las unidades de negocio en un tiempo récord. Si a esto unimos buenas herramientas para gestionar la integración de SOA, obtendremos ventajas para integrar las aplicaciones legacy al proceso natural de nuestro negocio.
A menudo, las aplicaciones legacy carecen de acceso Web y utilizan ventanas orientadas a la terminal que son antiguas –lo mismo ocurre con su interfaz de usuario-. Pero las herramientas de integración de SOA pueden partir de estas aplicaciones para crear otras análogas que estén orientadas al consumidor, tanto en lo que se refiere a los servicios que se ofrecen a los clientes como para los que se ofrecen a los partners –por ejemplo, un servicio de banca “self-service”-.
Este tipo de avances son los que pueden dar a un negocio una verdadera ventaja competitiva, al permitir a los empresarios ofrecer un servicio más valioso y rápido a sus clientes. Los que lo han probado indican que no presenta ninguna desventaja, exceptuando que el código establecido no es accesible. Por este motivo, la posibilidad de utilizar o reutilizar estos procesos de negocio en nuevos entornos tiene que ser una buena idea.
El feo y el malo
Llegados a este punto, es importante adoptar un punto de vista equidistante y reconocer que en algunas situaciones el SOA no tiene éxito. Nosotros, por ejemplo, no recomendamos su uso cuando las ventanas son complicadas y poseen sub-archivos pesados. En estos casos, sería mejor utilizar en su lugar tecnología Revamping o Refacing.
Del mismo modo que SOA no es recomendable para operaciones que requieren muchos datos, por los elevados tiempos de espera que los gráficos conllevan, conviene saber que las ventanas Web requieren con frecuencia más tiempo del habitual. Si tenemos en cuenta que cualquier software orientado a la rápida introducción de datos ha sido diseñado para trabajar de una manera diferente a la que SOA ofrece, es mejor dejar estas aplicaciones tal y como están.
El SOA se recomienda en casos en los que las aplicaciones desarrollan su actividad en diferentes hosts y existe la posibilidad de instalar el servidor en cualquier lugar. Esto se debe a que las herramientas de integración de SOA exigen no estar instaladas en la misma máquina que el resto de las aplicaciones del negocio –a menos que la Arquitectura Orientada a Servicios haya sido elegida para proporcionar comunicación entre dos aplicaciones que funcionan dentro del mismo host-.
La razón para elegir hosts diferentes es contundente: los problemas de coexistencia desaparecen, así como los problemas derivados de la utilización de diferentes versiones de software. Sin embargo, introducir otro servidor en la misma máquina para poner en marcha la integración puede provocar un exceso innecesario de trabajo para la máquina y aumentar los tiempos de respuesta. La solución entonces pasaría por introducir una máquina autónoma para el Middleware, pero a su vez presentaría el inconveniente de que entonces habría un único fallo para todo el sistema.
Nuestro consejo
Cambiar el legacy software puede ser difícil y caro. Un enfoque rip-and-replace puede afectar de manera negativa a los usuarios y plagar de riesgos nuestra actividad empresarial. La mayoría de las compañías prefieren pasar a SOA de una manera lenta y progresiva. A menudo, la mayor barrera con la que las organizaciones se enfrentan es la falta de know-how y experiencia en lo que a SOA se refiere.
Las empresas que adaptan sus aplicaciones legacy a la era SOA pueden optar por diferentes opciones. Por un lado, existe la posibilidad de reemplazar y modernizar el software legacy o por el contrario se puede ampliar y enriquecer. En este sentido, se puede utilizar mensajería CICS, API’s y nuevo middleware SOA para mantener el hardware existente e integrar el código legacy para proporcionar otros servicios.
Con frecuencia el software representa un punto crítico que puede afectar justo al corazón del negocio. Esto da lugar a que reemplazar este software sea poco atractivo y, en el peor de los casos, inviable. Rediseñar la aplicación puede resultar muy costoso o, incluso, puede ocurrir que los recursos técnicos (la programación) no estén disponibles.
Además, cambiar el software que ha funcionado de una manera eficiente durante un amplio periodo de tiempo puede representar un enorme riesgo para el negocio. Las compañías que elijan este enfoque serán a menudo las que ya desearan re-implementar su código de antemano, o tuvieran pensado cambiarse a otra plataforma como parte de una migración ya planeada.
Si optamos por renovar aplicaciones de una plataforma de hardware existente, tendremos la ventaja de que las inversiones en sistema ya realizadas podrán seguir siendo utilizadas y la estructura de software familiar se mantendrá sin cambios. A menudo esto significa que un menor número de plataformas son empleadas, lo que se traduce en un buen enfoque para empresas que buscan la integración con las plataformas .net de Microsoft y Server de Windows.
