Genero -sí, así se llama- es el protagonista de esta crónica llena de acción y recuerdos del pasado.
Si quien lee viene de una búsqueda, es evidente que conoce qué es Genero. Para quienes lo desconocen y se encuentran leyendo la crónica por curiosidad morbosa, daré una breve introducción de lo que es.
Genero es una plataforma propiedad de la empresa francesa 4Js; yo lo describo como un compilador y runtime moderno basado en el lenguaje de programación (y plataforma) 4GL de Informix.
Cuenta la leyenda que cuando IBM decidió no continuar con el desarrollo de 4GL, algunas empresas vieron en esta falta de oferta del fabricante una oportunidad. Una fue 4Js (Francia) y la otra, Querix (Reino Unido). Ambos desarrollaron su compilador y entorno de ejecución alrededor de 4GL, agregando extensiones: despliegue en ambiente gráfico y web para Windows, Linux y UNIX (recordemos que 4GL ejecuta enteramente en entornos CLI); nuevos tipos de datos y extensión para utilizar clases (aunque la programación se mantiene procedimental); emisión de reportes en formatos MS Word, Excel, PDF e imágenes; conexión con otros motores de base de datos (4GL originalmente solo funciona con Informix) y más de una conexión simultánea; y dos de los más útiles actualmente: la posibilidad de utilizar extensiones al lenguaje hechas en Java y exposición de los programas como web services de tipo SOAP.
Hagan clic en los enlaces a continuación para obtener más información acerca de Genero (4Js) o Lycia (la oferta de Querix).
Regresando a la crónica, esta se encuentra relacionada precisamente con un web service hecho en Genero, desplegado en linux que sirve… pero no sirve… a ver, ¿de qué va esto?
Nuevamente, un poco de teoría y la descripción del escenario.
Cuando se desea publicar un web service hecho con Genero, la versión básica consiste de un programa 4GL que contiene un ciclo WHILE “infinito” (entrecomillado porque hay una forma de detener el ciclo while para apagar el servicio) que expone funciones del propio programa como métodos del servicio y se queda en escucha en un puerto determinado. Este programa, mediante las bibliotecas correspondientes, expone su WSDL, procesa la entrada y salida de datos y es capaz de exponer uno o más métodos.
Una vez que el programa-web service funciona como se espera, es momento de publicarlo a través de un servidor web que será quien de la cara y gestione las peticiones con los clientes. Para este particular se emplea una herramienta proporcionada por 4Js como parte de Genero y se trata del dispatcher. El esquema de comunicación entre el servidor web, el dispatcher y el programa 4GL es como sigue:
Genero es una plataforma propietaria controlada por licenciamiento. Dependiendo de las características de este, se tienen tales o cuales limitaciones para el número de procesos concurrentes en ejecución. Para explicar esto, digamos que se tiene un esquema en que un programa ejecutando consume una licencia. Si tenemos un tope de 10, solo podemos ejecutar 10 programas 4GL a la vez. Como se puede tener múltiple cantidad de servicios web (además de que estos consumen recursos de hardware) es inviable dejar ejecutando los servicios, por lo que un esquema mejor es que se ejecuten solo cuando sean necesarios. Pues básicamente eso es lo que hace el dispatcher, es un programa que escucha las peticiones para determinado servicio y se queda en segundo plano. Cuando recibe una petición, busca (o instancia) un proxy, y ese proxy a su vez trata de conectar o ejecuta una máquina virtual de Genero (un programa 4GL) que se encargará de despachar la petición y devolver la respuesta usando el mismo camino, es decir, del 4GL al proxy, del proxy al dispatcher, del dispatcher al cliente.
Cuando se agrega la capa del servidor web, éste se convierte en el cliente exclusivo del dispatcher y es quien expone los servicios en un ambiente de red “controlado”, o quien expondría los servicios al público por ejemplo, de forma que el servidor de aplicaciones, donde reside el dispatcher, permanezca oculto.
Bueno, nuevamente con la crónica cuyo título incluye la leyenda Application not found, ¿qué es lo que sucedió?
Con base en el diagrama de interacción descrito anteriormente, es justo lo ocurrido. Tengo un servidor web, que está configurado para usar un FastCGI para exponer los servicios que están publicados mediante un dispatcher en el servidor de aplicaciones que a su vez también hospeda los programas 4GL. Cuando finalmente decido comenzar con las pruebas del servicio publicados con este esquema: kaput!
La respuesta recibida en el navegador cuando se le solicita la WSDL al servicio no podía ser más ambigua (¿o no lo era?):
Recordemos aquí que las pruebas ejecutando el programa directamente, sin el dispatcher, habían sido exitosas, por lo que se podía descartar con toda certeza un error en el programa, y máxime si solo se estaba solicitando la WSDL.
¿Qué podía ser entonces? Había llegado el momento de leer logs.
Vemos un evento, donde se cubrió en rojo el nombre del programa (créanme, es el correcto) para respetar la privacidad de la información, que aunque el dispatcher ejecuta, no logra obtener la configuración del servidor.
Cuando se exponen los programas como servicios con el dispatcher, este utiliza un archivo de configuración de estructura XML con extensión xcf. En este se definen las variables de entorno, rutas de configuración y componentes extra, como la ubicación de los drivers de la base de datos, así como el propio runtime de Genero y el/los programas 4GL expuestos. Haciendo una revisión detallada del archivo, constaté que la ruta de Informix era incorrecta. Por eso el programa nunca lograma arrancar del todo. Eso solventó el encontrar ese error en el dispatcher, pero el navegador continuaba recibiendo un “Application not found”, y ya no había errores en los logs.
¿Entonces?
La última parte de teoría es esta. Cuando se desarrollan los programas para exponer los servicios, existe una instrucción específica para declarar el servicio, y es como sigue:
com.WebService.CreateWebService(WEB_SERVICE_NAME, WEB_SERVICE_NAMESPACE)
Que como se aprecia en los parámetros, el primero corresponde con el nombre que se le dará al servicio (su contexto) y el segundo, el namespace al que pertenece (por si existe más de un servicio con el mismo nombre).
Y cuando se publican con el dispatcher, en el archivo de configuración xcf existe la siguiente sección:
Donde se declara el nombre con el que el servicio en turno será conocido a través del dispatcher, que a su vez, es con el que el servidor web lo mostrará.
Entonces, ese “Application not found”, era el mensaje de error exacto, sólo que fuera de contexto parece errático. El motivo de este error es el siguiente: el nombre del servicio en el código fuente no es el mismo que el que se usó en el dispatcher.
Para las pruebas directas, sin dispatcher, el servicio se identifica por el nombre declarado en código, y con dispatcher, se utiliza el nombre declarado en el archivo de configuración. Si uno pierde ese detalle de vista, se puede encontrar con esta condición, que aquí se aprecia como que la detecté rápidamente, pero en realidad me tomó un par de días.
Evidentemente el que no coincidan los nombres del servicio con y sin dispatcher es una mala práctica de programación y administración, y habrá que resolverlo a la brevedad.
Deja un comentario