Proyecto NACA: Migración de código COBOL a Java.

Ver para creer!! El Proyecto NACA de Publicitas Ltd. acaba de migrar satisfactoriamente 4 millones de líneas de código fuente COBOL de una aplicación que corría en un IBM/Mainframe a código Java 100% funcional sobre arquitectura Intel en Linux.

Lo mejor de todo es que este proyecto fue publicado como Software Libre bajo la licencia GNU GPL/LGPL, la versión 1.0 pueden descargarla aquí.

Suena un poco raro que existan casos para este tipo de migraciones, normalmente los proyectos de COBOL se situan en IBM Mainframes debido al alto volumen de manejo de datos, no sé hasta qué punto una migración a Java sería 100% exitosa, es decir no solo que sea funcional sino también del mismo o mejor rendimiento.

Sin duda es un gran trabajo de ingeniería que colocará a Java como una nueva alternativa a proyectos ya existentes en la plataforma de IBM.

Saludos!

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Interesante!

Muy interesante en verdad... probablemente la migración no es al 100% y haya que hacerle unos ajustes al final, sobre todo para lo que mencionas de performance, pero eso es precisamente lo mejor: Suponiendo que este software te deja tu sistema corriendo en Java haciendo exactamente lo que hacía antes en COBOL, pero tal vez más lento porque maneja archivos planos (o estructurados, pero no una RDBMS), pues al menos funcionalmente ya tienes algo equivalente en Java y lo bueno es que ahora ya tienes un sistema en una tecnología más actual, lo cual significa que es más fácil conseguir gente para que le mueva a ese sistema y le mejoren el performance, tal vez distribuyendo ciertas partes del mismo entre distintos equipos.

Con esto puede nacer un nuevo tipo de especialización, que consiste en saber bien Java y además conocer de la arquitectura de aplicaciones en COBOL en Mainframe. Ya no tienes que conocer el lenguaje a fondo, pero ayuda bastante el saber cómo suele (o solía) hacerse software en esa plataforma, para saber cómo queda la migración a Java y así saber por dónde empezar con las optimizaciones y modificaciones. Supongo que mucho depende de la documentación que deja el NACA (que no solamente depende de los comentarios originales, los cuales seguramente migra, sino de que deje documentado de qué módulo, programa, archivo, etc de COBOL viene el código que ves en Java).

Imagen de benek

Sí que lo es! Aunque COBOL

Sí que lo es! Aunque COBOL (y la arquitectura mainframe) para nada está en desuso... es antigua quizá, pero muy utilizada hoy en día. Siempre he dicho que COBOL es como la cucaracha de los lenguajes de programación, difícilmente desaparecerá en corto o mediano plazo, la mayoría de las empresas grandes tienen una cantidad exorbitante de desarrolladores mainframe, principalmente sector financiero.

Eso último que mencionaste es muy importante, se abre un horizonte más para Java como alternativa de migración. Ojalá que este proyecto sea exitoso y aliente a proyectos mainframe a probar Java como opción.

Estaría bastante bueno probar la herramienta, me quedan muchas dudas sobre como es que hace la conversión del código, dónde y cómo quedan los jobs de JCL, la COMMAREA y todas esas hierbas que no me imagino como habrán hecho para pasarlas a Java :-S

Re: Proyecto NACA

Suena un poco raro que existan casos para este tipo de migraciones, normalmente los proyectos de COBOL se situan en IBM Mainframes debido al alto volumen de manejo de datos, no sé hasta qué punto una migración a Java sería 100% exitosa, es decir no solo que sea funcional sino también del mismo o mejor rendimiento.

De hecho desde hace años ha existido un mercado de migración de aplicaciones escritas en COBOL/RPG a Java. La traducción a Java no parte del código fuente COBOL/RPG, sino de una representación intermedia. Si mal no recuerdo, en algunos casos se obtiene una representación binaria del código original y se procede a traducirlo directamente a bytecode Java. En este caso en particular, parece ser que se genera código Java a partir de la representación del grafo de código COBOL (expresado en XML).

Generalmente el código resultante resulta inmantenible (razón que me han dado algunos clientes para haber descartado en su momento alternativas como esa). Entonces, ¿por qué usarlo? Pueden existir varias razones, por ejemplo, tu razón costo/beneficio al realizar la migración es mejor usando este código generado automáticamente que pagar otro año de servicio y soporte para tu mainframe (los montos son muy, muy elevados).

Sin duda es un gran trabajo de ingeniería que colocará a Java como una nueva alternativa a proyectos ya existentes en la plataforma de IBM.

La alternativa de la traducción del código ha existido durante varios años, y tal vez uno de los más grandes promotores de la migración a Java haya sido precisamente IBM.

Saludos

Javier

Imagen de ezamudio

dos migraciones?

Entonces se requieren dos migraciones? Primero con una herramienta para automatizar este paso a Java, con código resultante inmantenible, pero al menos ya está en Java, y con eso ya le puedes decir adiós al mainframe.

Después ya comienzas a hacer un refactoring monstruoso (o reingeniería, o reescribir todo, o como le quieran decir) de ese código generado por la herramienta, pero para eso ya no necesitas ser un experto en COBOL (aunque seguramente sí ayuda saber algo de la plataforma original). A fin de cuentas se trata de encontrar la lógica de negocio y conservar ese código, reestructurando lo demás para darle forma de una aplicación Java empresarial típica...

RE: dos migraciones?

Entonces se requieren dos migraciones? Primero con una herramienta para automatizar este paso a Java, con código resultante inmantenible, pero al menos ya está en Java, y con eso ya le puedes decir adiós al mainframe.

Ándale, más o menos. El problema no es tanto de portabilidad de código, sino de portabilidad de los programadores que conocen la lógica de negocio. Generalmente no aprenden Java, así que tienen una especie de seguro de desempleo, hasta que llegue un equipo nuevo que no conoce COBOL, reimplementa en varios años lo que los demás ya habían escrito, corregido, etc.

A fin de cuentas se trata de encontrar la lógica de negocio y conservar ese código

Exactamente, ahí es donde está el problema.

Saludos

Javier

Imagen de CesarAlducin

Que tal me agrado mucho

Que tal me agrado mucho encontrar este post dentro del foro, precisamente porque ahorita estoy haciendo una investigación
sobre el proceso de migración de aplicaciones, investigando un poco me encontré con una que te cambia código Visual Basic 6.0
a .NET, pero no me imagina que existiera una para java y precisamente hacia haya va mi pregunta, ustedes conocen o me podrían
proporcionar información sobre lo que se esta trabajando en java a parte del proyecto NACA.

Y otra cuestión ustedes consideran que seria un buen tema de investigación el desarrollar una arquitectura para la migración de sistemas y a parte
desarrollar una herramienta con el mismo fin, se que estoy tomaría demasiado tiempo pero a mi punto de vista podíamos desarrollar
la arquitectura de migración de tal manera que al aplicarla ya nos hiciera este proceso y nos facilitara la migración.

Saludos

Cesar