Hace unos meses, el equipo de investigación de Berger Levrault publicó un artículo sobre la resultado de un experimento que permite que una aplicación JAVA trabaje conjuntamente con una aplicación Visual Basic 6. Este trabajo demostró que se podían utilizar componentes de negocio desarrollados en Visual Basic 6 desde JAVA e incluso "ejecutar" una aplicación completa sin tener que utilizar su GUI.
El mismo equipo se complace en anunciar que se ha reproducido con éxito el mismo enfoque pero esta vez con el lenguaje PowerBuilder en su versión 12.5. Aunque este lenguaje es muy diferente de VB6, los problemas relacionados con PowerBuilder son los mismos, especialmente en términos de funcionamiento: no es posible la programación web, no hay una clara separación funcional del código y, finalmente, la opacidad del trabajo real del compilador.

PowerBuilder es un entorno de desarrollo integrado propiedad de SAP desde la adquisición de Sybase en 2010. El 5 de julio de 2016, SAP y Appeon llegaron a un acuerdo por el cual Appeon sería responsable del desarrollo, las ventas y el soporte de PowerBuilder. A lo largo de los años, PowerBuilder ha sido actualizado con nuevos estándares. En 2010, una importante actualización de PowerBuilder fue lanzada para proporcionar soporte al Microsoft .NET Framework. El soporte oficial para la versión 12.5.1 y anteriores finalizó en abril de 2013. PowerBuilder 12.5.2 finalizó el 31 de agosto de 2015.

PowerBuilder dispone de un objeto nativo de gestión de datos llamado DataWindow, que puede utilizarse para crear, modificar y visualizar datos de la base de datos. Este objeto ofrece al programador varias herramientas para especificar y controlar la apariencia y el comportamiento de la interfaz de usuario, y también proporciona un fácil acceso al contenido de la base de datos.

PowerBuilder es un lenguaje de programación orientado a objetos. Casi todos los objetos visuales y no visuales soportan la herencia, el polimorfismo y la encapsulación. El programador puede utilizar un marco de código común como PowerBuilder Foundation Classes, también conocido como PFC, para heredar objetos de código preexistente y aprovecharlo. Las aplicaciones PowerBuilder se compilan normalmente en código p, que luego es interpretado por el motor de ejecución de PowerBuilder. Aunque se puede compilar en código máquina, una aplicación empresarial típica no se ejecuta mucho más rápido, excepto para los cálculos intensivos de la CPU. La razón principal por la que no se ha utilizado la compilación en código máquina es debido a los numerosos errores que presenta PowerBuilder, especialmente en la generación de código máquina.
La extensibilidad del lenguaje es bastante limitada para las versiones antiguas de PowerBuilder. Powerbuilder proporciona para superar esto una extensión de C ++ llamada PBNI (PowerBuilder Native Interface). Desarrollar una solución que incluya código C ++ externo implica la necesidad no sólo de desarrolladores con conocimientos de C ++, sino también de un experto en PowerBuilder que guíe al desarrollador a través de la miríada de sutilezas del lenguaje y de la máquina virtual. PowerBuilder.
La herencia y la funcionalidad orientada a objetos están limitadas a ciertos tipos de objetos (Windows, objetos de usuario y menús). En particular, no es posible heredar de un DataWindow.

La interoperabilidad, una cuestión de código nativo.

La forma de intercambiar entre dos lenguajes informáticos es reducir su composición al nivel más bajo posible, en lenguaje de máquina, binario; luego retroceder según sea necesario a uno u otro lenguaje.

En nuestro caso, la extensión de PowerBuilder "PBNI" (PowerBuilder Native Interface), inspirada en Java Native Interface, habrá proporcionado parte de la solución. De hecho, esta extensión, suministrada de forma nativa desde PowerBuilder 11, permite "incrustar" la máquina virtual de PowerBuilder (PBVM) en una aplicación C ++. Con el efecto inmediato de ser compilado en ... ¡lenguaje de máquina!

Haciendo de esta aplicación C ++ una clásica Dynamic-Link Library (DLL), resolvemos el segundo problema, que es exponer las funciones de nuestros objetos powerbuilder. De hecho, la DLL de C ++ accede a la aplicación Powerbuilder y a los objetos que la componen, luego la propia DLL expone funciones que representan el acceso a toda la aplicación Powerbuilder, y nosotros utilizamos estas funciones para acceder desde java a los resultados de las llamadas a funciones correspondientes a las peticiones del cliente WEB. Esta pasarela la proporciona JNA (Java Native Access), una superposición de JNI (Java Native Interface).

• La última cuestión es la de la arquitectura de destino, del lado de JAVA. En efecto, son posibles varias ópticas:
  Representar completamente lo que es una aplicación Powerbuilder en el lado Java permite considerar la programación de nuevas funcionalidades utilizando objetos y métodos de Powerbuilder en clases java. Esto también implica "lastrar" el código de destino con un importante volumen de código que debe desaparecer una vez finalizada la migración.
• Representar sólo lo que es único de una aplicación Powerbuilder en comparación con otra aplicación PowerBuilder, esta vez en el lado C ++ DLL ofrece la garantía de fluidez y velocidad de ejecución, sin embargo esto implica una opacidad importante para los desarrolladores y una dificultad significativa para codificar nuevas características en el lado JAVA. En este contexto, Java sólo accede a las funciones (puntos de entrada) de la aplicación y no a los objetos que la componen.

Ambas opciones garantizan el mismo resultado de acceso ya sea al tiempo de ejecución de una aplicación (con su contexto) o a los objetos de negocio que la componen.

JNA está construido y probado en macOS, Microsoft Windows, FreeBSD / OpenBSD, Solaris, GNU con Linux, AIX, Windows Mobile y Android. También es posible modificar y recompilar las configuraciones de construcción nativa para que funcione en la mayoría de las otras plataformas que ejecutan Java. Con Java y Java Native Access, podemos sustituir el "Main" de un programa VB (Contexto) por una Aplicación Java que utiliza el Objeto COM (Dll) como código de Lógica de Negocio.

Este enfoque ha sido probado y validado en una herramienta de la suite sanitaria de las soluciones de Berger Levraut, ha mostrado la posibilidad de considerar una migración tecnológica iterativa y la posibilidad de codificar nuevas funcionalidades en otro lenguaje. En efecto, este enfoque garantiza liberaciones regulares y probadas en producción. Además, permite la implementación inmediata de prácticas "modernas" como el "Test Driven Management (TDD)" ya que los lenguajes de destino pueden implementar desde el inicio de nuestro proceso de migración los frameworks más eficaces en estas áreas.

Conclusión

Después de Visual Basic 6, el equipo de Migración y Arquitectura de Berger Levrault vuelve a demostrar, pero esta vez con PowerBuilder, que los lenguajes de programación y frameworks más antiguos, sin mantenimiento y sin soporte de sus editores; no requieren necesariamente un proceso de migración con una reescritura total de las aplicaciones.
El departamento de Migración y Arquitectura de la Dirección de Investigación, Innovación y Tecnología de Berger Levrault rompe aquí la idea que se puede tener de una migración con todo un lapso de tiempo con una reescritura completa de la aplicación en un nuevo lenguaje, y donde sólo se puede desplegar cuando está casi completamente recodificada.

Al ofrecer un enfoque técnico y arquitectónico centrado en las necesidades transversales de los clientes, los equipos de desarrollo y la empresa, BL demuestra una vez más su capacidad para ofrecer soluciones innovadoras y eficaces.