La movida de los GXtips sigue su curso. Consejos claros y prácticos que nos simplifican las tareas a la hora de trabajar. En esta oportunidad, Luís Murillo, integrante del Equipo de Soporte de Artech, nos explica qué facilidades ofrece GeneXus para generar aplicaciones apuntando a una Arquitectura Orientada a Servicios.

Cuando hablamos de Arquitectura Orientada a Servicios (SOA por sus siglas en inglés), estamos hablando de una arquitectura de software, que facilita el desarrollo de aplicaciones empresariales, como servicios de negocio con bajo nivel de acoplamiento. La clave es la autonomía entre los componentes, dividir en módulos con el objetivo que puedan ser intercambiables. Pero éstos tienen que estar fuertemente comunicados porque los procesos de negocio cruzan los módulos, cada subproceso debe ocultarle toda su lógica al resto, solo disponer el cumplimiento de una tarea comunicándose a través de mensajes, o sea utilizar servicios.
 
Estamos hablando de módulos que cumplen una funcionalidad específica del negocio (por ejemplo: Ventas, Compras) pero a su vez cada modulo también es construido con esta arquitectura (definir hasta donde bajar con esta arquitectura para que no se transforme en contraproducente es la tarea del arquitecto). Se debe motivar la construcción de servicios. Estos se encargarán de exponer una funcionalidad bien definida a la aplicación que la requiera. De esta manera, una aplicación final simplemente orquesta la ejecución de un conjunto de servicios, añade su lógica particular y le presenta una interfaz al usuario final. Exponer procesos de negocio como servicios es la clave a la flexibilidad de la arquitectura. Esto permite que otras piezas de funcionalidad (incluso también implementadas de esta manera) hagan uso de otros servicios de manera natural, sin importar su ubicación física. Así un sistema evoluciona con la adición de nuevos servicios y su mejoramiento, donde cada uno evoluciona de una manera independiente. La Arquitectura (SOA) resultante, define los servicios de los cuales estará compuesto el sistema, sus interacciones, y con qué tecnologías serán implementados.
 
El primer problema con el que nos enfrentamos es que tenemos dos situaciones bien diferenciadas: tendremos aplicaciones de la vieja escuela y aplicaciones de la nueva escuela. O sea, aquellas aplicaciones que no fueron diseñadas con esta visión (o con esta arquitectura) y las nuevas aplicaciones que nosotros diseñemos, las cuales las debemos pensar con Orientación a Servicios. Por lo tanto no solo debemos resolver el problema de “mí” aplicación sino que tendré que permitir comunicarme con aplicaciones existentes (legacy) las cuales no hayan sido pensadas de esta manera.

Para poder incorporar estas aplicaciones a una arquitectura SOA, lo mejor es lograr rodearlas de una capa para disponibilizar lo que se necesite de ella en forma de WS. Habrá veces que no tendremos otra alternativa que acceder directamente a los datos, a efectos de construir esa capa de integración. Para esto contamos con DBRET, DataBase Reverse Engineering Tool. El cual nos permite crear Data Views en nuestra KB para acceder a los principales DBMS.

A su vez como esta capa se irá construyendo en forma incremental, podemos utilizar la metodología incremental de GeneXus que se adapta inmejorablemente a la construcción de esta capa. Así también, la facilidad de construcción de Web services en GeneXus es buena para disponer luego estas funcionalidades como servicios, así también como para cuando nosotros construimos nuestro sistema (ahora sí pensándolos SOA) disponer servicios a la red empresarial y externa. Basta con indicarlo en dos properties del objeto GeneXus que será WS, Main program en True y Call protocol SOAP.

Para consumir funcionalidades de otros Sistemas/módulos/servicios, contamos con WSDLInspector. Ésta es una herramienta que automáticamente define en nuestro modelo el WebService que debemos consumir y todos los tipos de datos para poder interactuar con éste. Luego simplemente definimos variables basadas en dichos tipos de datos y podremos en cualquier parte de nuestro modelo invocar al WS.

Los Business Components son otro elemento útil a la hora de construir nuestra aplicación, ya que nos permite fácilmente la disponibilidad de una transacción GeneXus como WS, con lo cual solamente seteando una property de la transacción. Se habilita la posibilidad de disponer toda la lógica de esta y chequeo de reglas hacia otra aplicación como un WS.
 
Finalmente, para resolver la capa lógica de User Interfase, contamos con nuestra herramienta de construcción de portales GXportal.

En nuestra próxima versión GeneXus (code name Rocha) en la cual ya estamos trabajando, seguiremos redoblando la apuesta en este sentido, acompañando la tecnología y mejorando lo que ya tenemos (interactuando con herramientas que ya hay en el mercado y resuelven bien problemas específicos, como ser motores  BPEL).