Interoperabilidad entre visual .net J2EE

La Necesidad es del Negocio

Más allá de lo estrictamente técnico, existen variadas razones que provocan la existencia de ambientes heterogéneos en las empresas. Casi una mezcla de circo y museo, se conjuga lo último y lo antiguo con distintos sistemas operativos, bases de datos y plataformas de aplicaciones.
Es que al entrar en juego factores tan diversos tales como los cambios de estrategia desde la alta dirección, la selección de nuevos proveedores de software, el outsourcing del desarrollo, los recortes presupuestarios, las fusiones entre empresas, crisis y otras cuestiones político/económicas, hacen que inevitablemente las medianas y grandes empresas tengan “un poco de cada cosa”.
Veamos algunos escenarios posibles que pueden hacer necesaria la integración entre aplicaciones J2EE y .Net:
Surge un proyecto nuevo basado en .Net que tiene que reutilizar un set de librerías Java cuya migración es inviable, ya sea por su complejidad, por la inexistencia de documentación o bien porque se dispone únicamente de binarios desarrollados por terceros (que no participan del proyecto, claro).
El mecanismo estándar definido por las políticas internas de la empresa para comunicarse con otros sistemas propietarios, SAP, AS400 o el Datawarehouse está implementado únicamente en una sola de las dos plataformas.
El directorio de una empresa toma una decisión estratégica que dicta la migración de todos los sistemas a una plataforma única. La casa matriz decide que a partir de ahora “todas las aplicaciones serán construidas en la plataforma X”.
Se decide instalar una misma aplicación para todas las empresas de un mismo grupo y surgen casos donde la plataforma dominante es distinta a la prevista. Se prueban prototipos que una vez aprobados tienen que pasar a producción interactuando con plataformas distintas a la original. Dado que .Net y J2EE tienen fortalezas y debilidades que se complementan, se decide que una solución mixta podría hacer valer las fortalezas de cada una.
Encontraremos que casi la totalidad de las soluciones que existen apuntan a resolver el problema haciendo que la lógica desarrollada en Java/J2EE sea accedida desde C#/.Net y, en muy pocos casos, en sentido contrario. Esto tiene que ver con el hecho de que Java, y en particular J2EE, dominan fuertemente el ambiente corporativo donde se establecieron bastante antes del surgimiento de Microsoft .Net.
Tengamos en cuenta que la publicación del modelo J2EE impactó fuertemente en este sector al establecer una infraestructura basada en estándares abiertos para aplicaciones distribuidas incluyendo transacciones, seguridad, componentes server-side, acceso a datos, persistencia, clustering y balanceo de carga. El bonus adicional del modelo tiene que ver con asegurarse la independencia de un proveedor específico ya que teóricamente un desarrollo particular puede instalarse en cualquier plataforma que respete el estándar (esta “compatibilidad asegurada” se vio afectada negativamente cuando los proveedores empezaron a incorporar mejoras adicionales cubriendo las falencias del estándar). En este sentido, a pesar de que .Net es una excelente opción para el desarrollo de software, como participante tardío de esta carrera todavía tiene camino por recorrer para consolidarse.

¿Cómo lograrlo?

La aproximación más sencilla que podemos implementar es una base de datos de uso compartido, donde a través de JDBC y ADO .Net nuestras aplicaciones J2EE y .Net, respectivamente, puedan acceder para escribir y leer información. Esta opción tiene mucho sentido si consideramos componentes que en ambos casos se encuentren en la capa de negocios. Para hacer interoperar componentes que se encuentren en diferentes capas, el mecanismo a emplear dependerá del punto de interconexión que estemos considerando

Si el punto de interconexión se extiende a través de Internet o una intranet, la alternativa natural es la utilización deWeb Services. Tenemos herramientas para generarlos y consumirlos en ambas plataformas y cuentan con la ventaja de ser estándares abiertos que nos permitirán conservar la compatibilidad con futuras aplicaciones. Estaremos limitados, eso sí, por la velocidad del enlace y el costo de emplear XML para transmitir los mensajes.

Si no disponemos de un enlace permanente o el que tenemos es poco confiable, tendremos que considerar servicios de mensajería asíncrona que usualmente emplearemos para la interacción entre las capas de negocios y de datos. Lo que se hace es implementar colas de mensajes en cada una de las plataformas e interconectarlas a través de un bridge (cada aplicación produce y consume mensajes a través de la API habitual). Por otra parte, si podemos sacrificar el soporte de transacciones y callbacks, es posible generar un wrapper que permita el acceso a través de un Web Service.

Cuando lo que estamos buscando es acceder a nivel de clases y métodos, tendremos que optar por un runtime bridge. Estos componentes se agregan en cada plataforma para administrar la interacción y comunicación entre objetos de diferente origen.

Si nos animamos a una solución de más bajo nivel podemos llegar a eliminar el overhead de la comunicación remota aprovechando los métodos de interacción con código nativo que tiene cada plataforma.

Por último, si estamos encarando una migración masiva a gran escala, lo que seguramente resulte más conveniente sea emplear herramientas de conversión de plataforma, las cuales se hacen cargo del mapeo de tipos y de proporcionar las APIs correspondientes.

Mecanismos Orientados a Servicios

¿Qué es lo primero que nos viene a la mente cuando nos hablan de integración de aplicaciones? Algo que la maquinaria publicitaria viene machacando desde hace algunos años: ¡Los Web Services, por supuesto! Tenemos la ventaja de que se trata de un mecanismo estándar y que existen en ambas plataformas (aunque lo de “estándar” es algo bastante relativo pues todavía falta un poco para que los proveedores se pongan de acuerdo al respecto).

Repasemos brevemente el funcionamiento de un Web Service como mecanismo de integración  que se muestra a continuación: