Oh sí: los JavaBeans se comunicarán entre sí (a fin de publicar y compartir datos) en la misma máquina virtual por medio de InfoBus (el novísimo bus de Kona/Lotus/IBM/Javasoft, en orden inverso de prevalencia), mientras que utilizarán RMI para tratar con otras maquinas virtuales. Y, claro, se mantendrán en todo caso los esquemas de seguridad propios de la plataforma Java; se accederá a bases de datos remotas mediante JDBC y JSQL (el SQL embebido en Java promovido, principalmente, por Oracle); se vivirá, en definitiva, en un mundo totalmente Javatizado, porque lo bueno se expande y universaliza: JavaChips que soportarán sistemas operativos Java segmentados en razón de su uso (domótica, informática personal, etc.), conectividad segura entre dispositivos heterogéneos, etc. ¿Y les hablé de los Enterprise JavaBeans? ¿O de los APIs de comercio Java? ¿O de...? En fin, ya ven: parece que se aproxima la catarsis solar: todo Java, todo Java, todo... ¡Mentira! ¡Ea! Me niego a aceptar que podamos pasar del monopolio Microsoft al monopolio Sun/Javasoft sin que medien manifestaciones de turbas enfurecidas o enfebrecimientos iracundos. Incluso me niego a aceptar que tales monopolios, entendidos en su sentido estricto, puedan existir. Java está muy bien (la plataforma tecnológica, que no el lenguaje), pero ¿significa eso que tengo que tirar mi viejo sistema Obsydian y el buen servicio que durante años me generó en el entorno AS/400? ¿He de trasladar mis datos y programas desde Natural/Adabas a nuevos esquemas basados en Vapor/Java/Sunware? ¿Tengo que obligar a mis programadores a aprender Java, a llevar gorras y camisetas gringas y a no usar el cuchillo? No, si puedo evitarlo. Y estoy convencido que puedo, porque yo no concibo un mundo Java. De hecho la situación me recuerda a la que plantearon, años ha, los fabricantes de bases de objetos en los albores de la OOT: "Tirad vuestras caducas bases de datos relacionales, porque el futuro se ha hecho luz: ObjectStore, GemStone, O2, Objectivity/DB, POET, Ontos, etc.". Han bastado pocos años para mostrar -de nuevo- que los usuarios no quieren revoluciones, sino soluciones y, en el mejor de los casos, prudentes evoluciones. Y es aquí donde entra CORBA. CORBA (Common Object Request Broker Architecture) define la funcionalidad e interoperabilidad entre ORBs (Object Request Broquers), componentes al fin de la OMA (Object Managemente Architecture), resultante del proceso de normalización emprendido por OMG (Object Management Group). ¡Alto, alto! ¿No nos hemos saltado algo? ¿Cómo hemos pasado de unas frases quasi-prudentes a un batiburrillo de acrónimos? Volvamos atrás. Quería yo decir que CORBA es la solución software a un mundo diverso formado por componentes heterogéneos. O sea, que CORBA puede resolver el problema de interoperabilidad entre porciones software inicialmente desconectadas. Esto es, que podré conseguir que la lógica de negocio embebida en código COBOL pueda ser utilizada mediante invocación de métodos desde un entorno, por ejemplo, C++ o Smalltalk. Ah, Ah, ya veo expresiones pensativas maliciosas. Pero no: CORBA no es un producto software tipo "Bálsamo de Fierabrás"; CORBA no es, tampoco, un término resonante comercial del tipo "reingeniería de procesos de negocio"; CORBA ni siquiera es, por fin, una opción: y es que es imposible pensar en el futuro a corto plazo sin CORBA.

EPDLA Y EPDTH

El problema de los acrónimos y el problema del tecnicismo huero: esto es lo que significan las mayúsculas del título de esta sección. Y estos son los problemas a los que se enfrenta el que quiere iniciarse en CORBA. La cuestión es uno empieza a hablar de interconexión, de comunicación, de prudencia y, de pronto, se descubre profiriendo siglas impronunciables con la ligereza con que se detalla una receta de cocina. Les pongo un ejemplo: Orfali y compañía, "los autores de los marcianitos" han publicado recientemente un libro titulado "Instant CORBA" que pretende ser algo así como "CORBA para torpes" o "CORBA para ejecutivos", pero que en realidad no resulta fácil de tragar ni por unos ni por otros: IIOP, ORB, PO, DCE, IDL, DSI, DII, GIOP, PDS, OMA, ESIOP, BOA, POS, DDO, OTS y otras parecidas lindezas nos llevan a un estado en el que se comprende el polimorfismo en acrónimos. La cuestión es que no puedo, en el reducido espacio de un artículo, explicar con un mínimo rigor qué se esconde detrás de tantas siglas. No puedo, tampoco, siquiera detallar, al nivel menos explicativo, los Servicios CORBA. No hay espacio ni para un ejemplo decente, a no ser que dé por supuesto que el lector ya conoce CORBA, pero es que en ese caso le mandaría directamente a leer un buen libro o alguno de tantos buenos artículos sobre la materia.

EL INFIERNO DE LAS BUENAS INTENCIONES

Tras el cúmulo de imposibilidades CORBA, he aquí mi intención resumida en tres puntos:

• Convencer al lector de la importancia de CORBA, sustanciando mis argumentos en su adopción por importantes valedores industriales (IBM, Netscape, etc.)
• Insuflar al lector la idea de que Java + CORBA es un enlace deseable y con posibles.
• Dirigir al lector hacia libros interesantes por medio de los que habrá de profundizar en CORBA.

Todo esto se sustancia, como los mandamientos cristianos, en la intención última de despertar el interés del lector por la computación distribuida heterogénea (¡Menuda conjunción de "buzzwords"!). Lo cierto es que intentaré comunicar al lector una cierta y muy grosera idea de cómo funciona lo esencial, de cuáles son las razones, groseras de nuevo, que se esconden tras tanta especificación y tanto pasmo.

SOPORTE INDUSTRIAL

JavaSoft está construyendo los servicios transaccionales (JTS: Java Transaction Services) de su plataforma Enterprise (sí, ya saben, esa que añade a la plataforma básica características transaccionales y de escalabilidad, entre otras; la misma en la que se basan los Enterprise JavaBeans) sobre CORBA e IIOP (Internet Inter-ORB Protocol). IBM, por otro lado, está portando la plataforma Java a todos sus sistemas operativos (ya existe para AIX y OS/2, en breve para AS/400, etc.), y su intención es añadir, empaquetado, su conocido ORB CORBA SOM 4.0. Aparte de su soporte CORBA en la parte servidora, Netscape va a distribuir, por otro lado, indisolublemente unido a su nuevo paginador "Communicator", un ORB (en concreto VisiBroker for Java), lo que permitirá invocación de métodos remotos mediante IIOP desde más de veinte millones de paginadores. La NCA (Network Computing Architecture) de Oracle (esto es, su línea de software al completo) ha tomado de base a CORBA, mientras que se anuncia el lanzamiento de un ORB en Oracle Web Server 3.0. Microsoft, por otro lado, ... ¿soporta CORBA? Pues sí: lo soporta, en el sentido más exacto del término. Lo cierto es que Microsoft posee su propia arquitectura de distribución y comunicación entre componentes: COM (Component Object Model) y DCOM (Distributed Component Object Model), la versión distribuida del primero. Pero, perdón, ¿dije COM? Quise decir ActiveX. Pero no, dejémoslo en COM. Lo malo es que COM no se ajusta a CORBA. Se trata, como no podría ser de otra manera, de un modelo propietario. Claro que existen puentes CORBA-COM, pero su funcionamiento dista mucho de ser sencillo e incluso, en algunos casos, efectivo. Claro que, por otro lado, Microsoft, junto con Digital (DEC), posee otro "COM (Common Object Model)" que sí se aviene a las razones CORBA, aunque carente de protagonismo en las plataformas wintel. La cuestión, como yo la veo es la siguiente: las herramientas de desarrollo Microsoft (sobre todo a partir de Visual Studio) desprenden el mensaje "El lenguaje de programación no es lo importante: codifica pensando en componentes ActiveX y hazlo en cualquiera de los lenguajes/entornos Microsoft: Visual Basic, Visual J++, Visual C++, etc.", pero entonces ¿por qué no codificar módulos en Java y luego decidir qué residencia, qué modelo de componentes, quiero procurar a mi código? O sea, si yo codifico cierta lógica de negocios en Java y necesito embeberla en un control ActiveX para su uso en una ASP (Active Server Page), lo único que necesito es ejecutar el asistente de creación de objetos COM que viene con MS Visual J++ 1.1 y... ¡voilà! Claro que se me podría argumentar que los controles ActiveX no son tan simples como pudiera parecer en una demostración comercial, y que en realidad has de codificar sabiendo para qué modelo de componentes lo haces. Bien, esto es cierto (¡Cómo se nota que los lectores trabajan en el mundo real!), pero también lo es que existe actualmente en versión beta -pero pronto en versión definitiva como parte inseparable de la plataforma Java- una "Herramienta Asistente de Migración para ActiveX" que procura el suficiente soporte para codificar tanto para ActiveX como para JavaBeans. O sea, que con el mínimo esfuerzo tendremos la posibilidad de operar en ambos modelos, así que ... que gane el mejor. Así que, volviendo al punto de partida de esta digresión, ¿por qué no utilizar Java y obviar así, en gran medida, el problema de los modelos de componentes en principio no encajables? Java se convierte así en un magnífico puente y excelente pegamento, proporcionando además argumentos para decantarnos por un modelo teórico mejor que COM, y encima sin entrar en fanatismos hueros.

LA RAZÓN DEL PASMO

Ya vio el lector que la industria del software se está vertebrando en torno a CORBA. ¿O era en torno a Java? En realidad lo está haciendo en torno a ambas. Claro que parece que de todo existe dicotomía (parte buena y parte mala, Jekyll y Hide, vino y vino con gaseosa, etc.), así que también podría decirse que el software se vertebra en torno a Microsoft. Aunque en esa misma línea podría también afirmarse que la organización de un ejercito depende de la de sus enemigos..., y se tendría razón. Bien, la cuestión es: ¿qué demonios me ofrece CORBA? En esencia: portabilidad entre plataformas. O sea, puedo codificar módulos software con distintos lenguajes de programación e instalarlos en distintas plataformas y, más tarde, establecer comunicación entre ellos: un módulo COBOL inserto en un RS/6000 bajo AIX podrá invocar un método en un módulo Java sito en una SparcStation bajo Solaris. Claro que, ¿cómo diantre se entienden distintos lenguajes, distintas implementaciones? Mediante un filtro intermedio, que en el caso de CORBA son los interfaces IDL (Interface Definition Language). O sea, se trata de interfaces (sin implementación) codificados con un lenguaje especialmente creado a tal fin y que se asemeja mucho a C++ (y también a Java, de retruque). Así las invocaciones de métodos se realizarían sobre signaturas de métodos explicitadas en interfaces IDL, para luego traspasar tales peticiones al código de implementación por debajo del interfaz. He aquí un ejemplo:

interface Politico {

public void saluda();

};

El lector ya habrá adivinado que se trata de un lenguaje orientado-a-objetos. Hablo de IDL, naturalmente (admito críticas, discusiones y exabruptos). El lector se habrá percatado, igualmente, que habrá que unir el interfaz a la implementación con algo más que meras palabras: con compiladores IDL. Y el lector notará, por último, que la conectividad no es automática (y si no lo nota es porque quizás piense que en el software anida un no-sé-qué de ingeniería). La gran ventaja es que los resultados típicos de métodos de análisis y diseño (estructurados u orientados-a-objetos) pueden ser expresados mediante IDL (que, por cierto, es, como CORBA, resultado de OMG, el Grupo de Gestión de Objetos, que ha conseguido un importante apoyo industrial porque intenta crear normalizaciones con los pies en el suelo). La gran ventaja de usar IDL como lenguaje de especificación es que, de paso, hemos adelantado más de un paso para conectar nuestra solución software mediante CORBA al resto del universo (algo se me pegó de los marcianitos y de Orfali y compañía).

TIEMPO DE REFLEXIÓN

Bien: ya hemos empezado. Pero necesito un compromiso más sentido por parte del lector. Así que, antes de seguir, voy a detallar qué lecturas debería abordar para que no nos perdamos en detalles que al final no son sino copia de especificaciones que pueden encontrarse en cualquier sitio, incluso gratis en Internet (http://www.omg.org).

LIBROS

La unión CORBA y Java necesita de más referencias bibliográficas CORBA que Java. Y es que del último existen estanterías llenas, mientras que el primero se arreglaría con un rinconcito en una papelería. Como siempre, he aquí mi selección personal:

• The Essential Distributed Objects Survival Guide, por Robert Orfali, Dan Harkey y Jeri Edwards, 1996, Wiley Computer Publishing, 0-471-12993-3.
• La distribución de objetos aparece en este libro como la evolución natural del esquema cliente/servidor, de forma que se asegura que elementos clásicos como monitores transaccionales se convertirán finalmente en ORBs, y se lanzan predicciones no demasiado aventuradas. Tras esta introducción, el texto se dedica a describir CORBA y los más importante entornos-marco de objetos: OpenDoc, OLE y otros. En realidad el libro entero es un panfleto a favor del software distribuido, acompañado de didácticas descripciones y de buenas explicaciones de CORBA, COM y OpenDoc. Con todo, para mi gusto esta obra necesitaría de una segunda edición en la que se ampliara y mejorara la descripción de OLE/COM/ActiveX y se diera soporte, también, a JavaBeans. La ventaja del libro es su acopio enciclopédico y, por ende, su defecto. De cualquier forma el lector no encontrará muchos libros que puedan competir con éste, que asegura que CORBA es teóricamente mejor, pero que COM está para quedarse.
  
• Client/Server Programming with Java and Corba, por Robert Orfali y Dan Harkey, 1997, Wiley Computer Publishing, 0-471-16351-1.
• Se trata de la evolución de lo expuesto en la guía de supervivencia de objetos distribuidos. Quedó claro que CORBA... ¡sí! Y aquí se explica que Java... ¡sí! O sea, que nos encontramos ante una historia de amor. Los autores extienden un ejemplo bien simple a lo largo de su obra: se trata de un simplísimo contador remoto, que se remoza de lo que en cada capítulo se trata. Lo mejor es que sitúa al dúo Java/CORBA en un espacio en el que tiene que defenderse de competidores como RMI (de la propia Javasoft), DCOM ó HTTP/CGI. El libro contiene, además, lo que los autores denominan el más extenso tutorial JDBC de la galaxia (con revisiones 2-tier y 3-tier). Claro que el texto se escribió utilizando versiones beta de JDK 1.1 y, por tanto, de JDBC, así que ya han aparecido libros completos sobre la materia (por no mencionar los usualmente apropiados textos PDF de la misma Javasoft). El ORB usado en el libro es VisiBroker for Java, debido, sobre todo, a que fue el único disponible para Java tanto en la parte cliente como en la parte servidora en el momento de escribir el texto. La competencia ha aumentado notablemente en estas fechas (OrbixWeb de Iona, etc.). Mi impresión es que el libro es tremendamente didáctico, y el ejemplo, aunque simple, está muy exprimido y no da lugar a equívocos.
  
• Instant CORBA, por Robert Orfali, Dan Harkey y Jeri Edwards, 1997, Wiley Computer Publishing, 0-471-18333-4.
• Los autores estiman un plazo de una semana para empaparse de este libro, que pretende, tras situar al lector en el panorama de CORBA 2.0, explicar de una manera amable (esto es, en pocas páginas) qué es un ORB y qué son (y cuáles) los servicios CORBA, para acabar elucubrando sobre direcciones futuras y deseos sentidos. Por el libro se pasea el espíritu de los dos anteriores, así que se menciona continuamente el "Object Web", esto es, el web galáctico de interconectabilidad total. En fin, se trata de una suerte de "CORBA en 7 días" para lectores que necesitan que se les diga que tienen poco tiempo y muchas obligaciones. Es, con todo, un buen resumen.
  
• Java Programming with CORBA, por Andreas Vogel y Keith Duddy, 1997, Wiley Computer Publishing, 0-471-17986-8.
• Casi la mitad del libro la componen apéndices que pretenden ser referencia resumida de la OMA y de la especificación CORBA 2.0, tablas de utilidad (correspondencias Java para tipos predefinidos IDL) y listados del código completo de los ejemplos del libro. Esta es, naturalmente, la parte que se encuentra con cierta facilidad en otras obras. El resto del texto se divide en diez capítulos que constituyen una de las más asequibles introducciones a Java y CORBA que haya yo leído. Para evitar tener que elegir, cada paso se triplica: esto es, se explica para cada uno de los tres ORBs Java más extendidos: VisiBroker for Java (de Visigenic), OrbixWeb (de Iona) y Joe (de Sun), de forma que el lector, además de apreciar las diferencias entre las distintas implementaciones de ORBs, también puede apreciar sus similitudes. El tono del texto es simple y pretende ser ante todo pedagógico, así que se convierte en un excelente candidato para la primera aproximación al monstruo de dos cabezas.
  
• CORBA Design Patterns, por Thomas J. Mowbray y Raphael C. Malveau, 1997, Wiley Computer Publishing, 0-471-15882-8.
• Este libro me encanta, porque los patrones de diseño me encantan, naturalmente. Se trata del detalle de soluciones CORBA a problemas concretos, dentro de un esquema documentario pre-establecido: escala de aplicabilidad, tipo de solución, nombre del patrón, intención, fuerzas primarias, aplicabilidad a la escala dada, sumario de la solución, beneficios, otras consecuencias, reescalado de la solución a otros niveles, soluciones relacionadas, ejemplo y contexto. El Object Request Broker se presenta, de hecho, como un patrón de diseño con el mismo nombre que representa la solución al problema de la simplificación de la computación distribuida, de forma que el lector ya no examina especificaciones, sino que estudia soluciones (lo que ayuda mucho a la comprensión del ORB). Otros patrones detallados suenan tan interesantes como la "Pasarela CORBA-CGI", que pretende usar CORBA como fuente de datos para la generación de páginas HTML, o el "Object Wrapper", que intenta integrar "legacy applications" en arquitecturas orientadas-a-objetos de la forma más efectiva, corta y barata posible. En fin, un recetario de soluciones CORBA. Pero es que leer ciertas recetas genera deseos de ir al restaurante. Esperémoslo así.
  
• CORBA Fundamentals and Programming, escrito y editado por Jon Siegel, 1996, Wiley Computer Publishing, 0-471-12148-7.
• ¡Por fin! Un libro destinado a programadores CORBA, con multitud de ejemplos y código C, C++ y Smalltalk. Me explico: los anteriores libros están bien, pero difícilmente podrían pasar mucho tiempo en la mesa de un programador: es decir, se trata de textos explicativos, de especificaciones o de conceptos de análisis/diseño de software. El presente es el típico libro que consulto (como de hecho hago, sobre todo respecto de los ejemplos Smalltalk) en proyectos de programación reales. El cuadro de autores es impresionante, pero la obra resultante no es la típica "capítulo por autor", sino que se trata de un impresionante trabajo conjunto con autoría múltiple. En fin, la sola descripción del índice se llevaría más de una página, así que me aprestaré a recomendarlo. Punto.

No quisiera acabar sin recomendar dos textos adicionales que, sin ser geniales (ni siquiera divertidos), podrían resultar adecuados para asentar los conocimientos adquiridos con los anteriores. De hecho yo los utilizo como "prueba de evaluación" de conocimientos CORBA, precisamente porque no aportan nada y, sin embargo, constituyen una introducción sin entrada visible a CORBA. Helos aquí:

• The Essential CORBA: Systems Integration Using Distributed Objects, por Thomas J. Mowbray y Ron Zahavi, 1995, John Wiley & Sons Inc, 0-471-10611-9
  
• CORBA: A Guide to Common Object Request Broker Architecture, por Ron Ben-Natan, 1995, McGraw-Hill, 0-07-005427-4