¿Cuál es el papel de un sacerdote? Actuar como proxy de su dios, naturalmente. ¿Y cuál el de un camello? Nodo de una red de distribución de drogas. ¿Qué es el beso de la muerte de la Mafia? Un protocolo de comunicación particularmente efectivo. ¿Y las relaciones sado-masoquistas? Topologías Cliente-Servidor en sentido estricto. Bueno, ya ven que la vida supera a la informática, de nuevo. Pero fíjense que las comparaciones más jugosas se dan en el lado del delito. Piensen, por ejemplo, que u n chute de caballo es como un applet, pues se descarga del servidor (gratis las primeras veces) y se ejecuta siempre en el cliente (que contará con la herramienta paginadora/pinchadora adecuada): de hecho el abuso lleva, en ambos casos, a una exasperante lentitud e incluso al “cuelgue” del cliente. O reparen en que el chulo en una red de prostitución actúa como un ORB CORBA: nos acerca el objeto deseado (del deseo, claro), junto con su interfaz de polvos y poses afectadas (¡Diantre! ¡Cuántos sentidos!), y además aplica lo que ahora se consideran modernísimas técnicas de control de clientes: pay-per-view, pay-per-touch, pay-per-<Nacionalidad>, pay-per-all y pay-before-all. De hecho las prostitutas pueden estar albergadas/almacenadas en diferentes tugurios o ubicaciones, relacionales (madres/padres, hijos/as e incluso hermanas/os, ya saben) o tratadas como objetos (el caso más general), pero nuestro ORB proxeneta conseguirá que la gestión de obtención de recursos sexuales resulte transparente para el usuario. Y eso sin contar los catálogos de patrones que abundan en carreteras y cruces. Pero, ¿y la seguridad? ¿Hemos de confiar nuestra integridad VIH certificados tipo ActiveX? ¿O más bien deberíamos contar con un esquema condónico que impidiera el acceso de cualquier infección a los recursos locales?. Pero la cosa no queda aquí: Imaginemos una red de apuestas y juego ilegal: ¿Cómo se relacionaría con nuestra red de prostitución? CORBA 2.0 nos asegura la interoperabilidad entre ORBs: esto es, un chulo puede interactuar con un corredor de apuestas o un camello. De hecho, es más que frecuente que los chulosputas se chuten para olvidar el fracaso de sus apuestas. Así que “ La Familia es la red” (según el nuevo lema de la Mafia, influido por Sun, Oracle y la CNN), y el “login” implica la comisión de algún delito (usualmente de sangre), como está siendo habitual en las multinacionales. De igual manera la estructura universitaria, en su vertiente criminal, interactúa con... ¡Alto, alto! ¿Qué demonios tiene que ver esto con Java, con CORBA o con cualquier otra cuita de programación? ¡Mucho, naturalmente! Uno tiende a olvidar con demasiada facilidad que la programación no es un fin en sí misma, sino que representa el modelado/solución software de/a un escenario/problema del mundo real. Así que si el mundo es irrebatiblemente heterogéneo y la sociabilidad es una premisa ineludible, ¿cómo nos atrevemos siquiera a plantearnos un universo software homogéneo, con una sola puerta [1] o alumbrado por un único sol? Mi imagen se acerca más a una estampa de dibujos animados en la que el inmaduro y barbilampiño Geek le preguntaría al amanerado Duke: “¿Dónde quieres ir mañana?”. O sea: urbanidad moderna (interoperabilidad CORBA) en la que se confundirían anfitrión e invitados [2].

EL PROBLEMA DEL FILTRO

¿CORBA? ¿IIOP? ¿IDL? Los asistentes a mis conferencias y cursos suelen mostrar un creciente catálogo de poses y componendas gestuales conforme avanza la masacre acronímica. Claro que para mí es fácil enunciar que CORBA 2.0 establece la especificación de la interoperabilidad entre ORBs mediante GIOP (General Inter-ORB Protocol), cuyo formato de mensajes es la base de la especificación del IIOP (Internet Inter-ORB Protocol), que a su vez usa TCP/IP como protocolo de transporte. ¿Y por qué no hablar también de DCE-CIOP (DCE Common Inter-ORB Protocol), que utiliza el mecanismo DCE-RPC? ¿O hablar de IORs (Interoperable Object References)? ¿Y por qué no...? Humm, mi consejo, repetido en multitud de ocasiones, es: “Señores, tienen a su libre disposición las especificaciones CORBA 2.0 en http://www.omg.org, así que ¿por qué permitir que tales correctas y completas descripciones les lleguen mancilladas, deformadas e incluso irreconocibles merced al filtro de un mediocre profesor, un informático vengativo o un articulista inmaduro? ¿No ven que su lectura ha de resultar más gratificante que la explicación de alguien que a su inexperiencia práctica ha de unir las ínfulas del magister dixit?”. Claro que yo, de nuevo, podría caramelizar su atención estableciendo que “IIOP soluciona el problema del cuello de botella esencial a CGI”, pero note el lector que si cambia los acrónimos por términos políticos obtendrá el mismo voluntarioso –y comunmente falaz- lema electoral. ¿CORBA es bueno? ¿Microsoft es malo? ¿COM es malo por depender de Microsoft? Si mueres con Java y sin CORBA, ¿irás al Purgatorio? ¿Cuántos días de bula se obtienen usando un JavaBean? Y, en todo esto, ¿dónde encaja el presente artículo? La verdad es que mi intención inicial fue mostrar las líneas gruesas de una programación Java que usara ORBs CORBA, javatizados o no, pero los comentarios recibidos en el último mes en relación a mi anterior artículo sobre RMI y mis últimas experiencias “de campus” sobre estudiantes y profesionales han causado que me cuestione la utilidad de “resumir lo ya resumido”. Para abreviar diré que el panorama tecnológico español se me antoja áridamente desolador, grumosa bechamel poblada por grupúsculos que pretenden construir “castillos en España [3] ” empezando por las almenas. Y es que, como también he repetido con frecuencia las últimas semanas (sin ánimo de ser “vox clamantis in deserto”) es que “cualquiera que les enseñe sólo el lenguaje Java o es un ignorante o es un canalla”, con lo que quería indicar que se supone, en lo que pretendemos Ingeniería Informática, un cierto núcleo tecnológico (que no doctrinal) sobre el que descansarían apéndices como la programación, la síntesis, los métodos o el modelado. Pero parece que tal núcleo no existe. Esto es, se asimila programación modular con “packages” Ada, se iguala especificación formal con requerimientos formales y se sueñan sistemas automatizados (formales, ¿cómo no?) de modelado de la realidad. O sea, la matemática imperativa o la práctica declarativa; o el formalismo declarativo y la experiencia imperativa, tanto da. En los últimos dos meses he asistido -ya no impertérrito, sino felizmente beligerante- al desprecio académico por CORBA en la práctica y a la ignorancia empresarial de los modelos de componentes. Ah, ah, pero me desvío, porque el horror me descoloca. Decía que ¿cómo voy a explicar Java en CORBA si el lector desconoce tanto CORBA como Java? Oh, claro, ya oigo las quejas, pero es que saber codificar una Pila dice bien poco del conocimiento de estructuras de datos. Así que en vez de resumir me esforzaré en pontificar.

CGI, PANDORA Y LOS CONSEJOS DE ADMINISTRACIÓN

Ya sabe el lector que la tontería de Internet está obligando a las empresas a plantearse la apertura hacia usuarios remotos de sus “viejos” sistemas software, hasta ahora no necesitados de apéndices o paginadores. Lo que sigue es sorprendente y repetidamente lineal: tras un somero estudio se encuentra una pretendidamente fácil vía de escape: “Usemos formularios HTML embebidos en páginas web y accedamos a la lógica de negocio inserta en nuestras aplicaciones in-house mediante CGI (Common Gateway Interface)”. De hecho la abundancia en el mercado software de herramientas que posibilitan el desarrollo de clientes de esta guisa refuerza la convicción de la empresa de que “se está abordando el problema en la dirección y sentido adecuados”. No se repara, empero, en que:

• Todos los criterios y principios de modularidad software, los esfuerzos de la programación orientada-a-objetos, las directrices de reutilización de métodos de análisis y diseño, y las ventajas de los modernos entornos de programación se van al traste con la codificación de clientes como páginas HTML. Y es que ¿tanto reclamar una fácil mantenibilidad del software para al final ir a recaer en un estúpido –por simple- y difícilmente mantenible lenguaje de marcas? Y si alguien cree que lenguajes como “JavaScript” son mejores, que no lo crea.
• El chequeo estático de tipos, tan mentado y necesitado en C++, Eiffel, Java, etc., hace mutis por el foro. Oh, sí: todo el gran esfuerzo de diseño de los lenguajes de programación para evitar errores en la fase de ejecución mediante el control estricto de tipos en compilación se va al garete aquí, pues la información que se pasa del cliente al servidor ha de ser codificada en la cadena de la URL que, además, ha de ser analizada de nuevo por el servidor cada vez que se produce una llamada CGI.
• La interacción cliente-servidor mediante CGI genera un rosario de páginas HTML, de forma que cada respuesta del cliente genera, además, una nueva codificación en la cadena de la URL que no aprovecha, por inexistente, el supuesto “estado interno” de la “aplicación”. O sea, que decimos “Adios, objetos” como Clarín decía “Adiós Cordera”.
• Resulta impío obligar al usuario-cliente a ejecutar una aplicación en un paginador. Tanto como obligarle a vivir en una colmena o a trabajar en un cubículo. Esto es, désele la posibilidad, pero otórguensele más opciones. Uno espera que los platos que introdujo en el lavavajillas sean los mismos que obtendrá una vez limpios. Y si tal se espera de un electrodoméstico, ¿por qué no de una simple aplicación software?
• El “diálogo”, como las “ventanas de diálogo” a que estamos tan acostumbrados, desaparece y se troca en lectura de una suerte de libro interactivo: “Si cree que el héroe debe salvar y casarse con la chica, vaya a la página 52; si por el contrario cree que debe amigarse con el chico, diríjase a la página 89”. Una respuesta de cualquiera de las partes genera una nueva página que de nueva tiene usualmente poco: nada se reutiliza, con lo que vuelven a dibujarse formularios, preguntas, etc., de forma que, además, se genera un trabajo adicional para ambas partes, que se complica por el hecho de que, mediante HTTP, la carga de una simple URL puede generar, que es lo usual, múltiples conexiones, de forma que se genera un “cuello de botella” (lo siento, no me pude resistir J ) en el servidor de difícil, cuando no imposible, resolución.

“Problemas, problemas. Pero el consejo de administración de la empresa estableció bien clarito que no podemos quedarnos atrás, que hay que hacer algo con Internet, con Java y con el WWW”. Aquí es cuando, de acuerdo con los esquemas televisivos, el hombre-factótum del detergente, del desodorante o del champú anti-caspa aparecen ofreciendo soluciones milagrosas a precios ridículos. El crédulo lector ahora podría, pues, suponer que Geek, en formato televisivo, traerá la solución a los problemas del CGI en un frasco CORBA con el lema “Duke no le abandonaría”. Bueno, ciertamente un ORB Java solucionaría en gran medida los problemas expuestos, pues procuraría la conexión entre servidor y cliente mediante la invocación de mensajes (con argumentos a los que se aplicaría un –estricto chequeo de tipos, de acuerdo con lo especificado en los interfaces IDL que posibilitarían la comunicación), entre objetos de ambas partes, objetos que mantendrían sus estados internos y que podrían utilizar las capacidades gráficas de la AWT y de las JFC (Java Foundation Classes) para permitir a los usuarios interactuar mediante auténticos “diálogos” con las aplicaciones en la parte servidora. Los problemas de eficacia relacionados con el uso de CGI/HTTP quedarían grandemente disminuidos debido a que la invocación de métodos en objetos remotos procurada por la infraestructura del ORB origina el transporte únicamente de la información necesitada en cada interacción, además de que la carga de invocaciones podría distribuirse entre distintos ORBs. “Pero esto suena a solución milagrosa” -exclamará el ingenuo lector-: “Lo mejor de Java con lo bueno de CORBA”. Hay, no obstante, que leer bien el folleto con las contraindicaciones:

• Los entornos de desarrollo Java todavía dejan muchísimo que desear, y su soporte de la plataforma Java (JavaBeans, nuevo modelo de eventos, etc.) es irregular.
• Los ORBs Java disponibles (Joe, Visibroker for Java y OrbixWeb) no son precisamente sencillos de usar y su precio no es precisamente “ridículo”.
• La comunicación bidireccional con el modelo de componentes de Microsoft, COM, no está garantizada. El mero enlace, pese al puente CORBA-COM, es deficiente en muchos aspectos y de difícil y costosa implementación.
• Las ventajas modulares reseñadas requieren una segmentación modular inteligente de la aplicación. Las carencias en análisis y diseño software pueden de hecho conseguir que los problemas derivados del uso de CGI aumenten incontroladamente con el uso de ORBs.
• El esquema de seguridad respecto de applets Java de paginadores como Netscape Communicator o Microsoft Internet Explorer (esto es, su instanciación de un objeto SecurityManager restrictivo, por otra parte perfectamente deseable), restringe la conexión de un applet mediante un socket únicamente a la URL desde la que la fue cargado, con lo que, a no ser que se utilice un proxy, los servidores y demonios CORBA habrán también de restringirse a tal misma URL.
• Los actuales entornos no poseen facilidades en desarrollo para el paso de cadenas IOR entre JavaBeans.
• La adición de CORBA a Java no es como la de azúcar al café, de manera que los programadores/diseñadores necesitarán estar en posesión de un buen nivel de conocimiento teórico-práctico en ambas tecnologías. Las carencias formativas serán, pues, difícilmente salvables con el esquema “prueba-error” tan querido por los informáticos.

RMI VERSUS CORBA

¿RMI o CORBA? ¿Mundo Javatizado o no? ¿Y por qué no ambos (planteamientos)? Finalmente Javasoft anunció, en nota de prensa del 26-06-97, además de la reafirmación de su intención de incluir Java IDL en el núcleo de la plataforma Java y su voluntad de desarrollar y mejorar RMI, que sería añadido a RMI soporte para CORBA IIOP y sus extensiones, a la vez que se intentarían añadir a IIOP (por medio de OMG) algunas de las facilidades ya presentes en RMI. O sea, que de golpe, como por ensalmo, se despojó de sentido la discusión y se deshizo la bifurcación, así que si se trabaja con Java (y se cumple lo anunciado), RMI aparece como la solución natural. Claro que esto no es completamente exacto. Actualmente RMI utiliza el protocolo JRMP (Java Remote Method Protocol) y las capacidades del API de Serialization (embebido ya en el núcleo de la plataforma Java) para conseguir la conversión transparente de invocaciones locales en invocaciones remotas, y esto no va a cambiar con el anunciado soporte de IIOP. En realidad se va a producir una “convivencia” con ciertas restricciones y condiciones. Esto es: será posible el acceso a objetos CORBA mediante el uso de IIOP, pero el uso genérico de RMI seguirá requiriendo el protocolo de transporte JRMP. La intención de Javasoft es especificar un subconjunto estricto de RMI “compatible” con IIOP (un bígamo tiene que repartir su cariño), a la vez que se forzará la modificación de CORBA IIOP para extender tal subconjunto y así mejorar la integración deseada (el bígamo hace partícipes de la situación dicotómica a ambas esposas, confiando en que una mayor comprensión facilite la convivencia y el reparto de fiestas).

JAVA IDL

Si se cumplen los deseos de Javasoft, la plataforma Java estará en breve distribuida por doquier, pero difícilmente llenara todos los huecos. El lector ya sabe que los interfaces Java semejan sobremanera los interfaces IDL CORBA, pero no debido a una buscada convergencia, sino a que IDL CORBA se basa grandemente en la sintaxis C++, como también lo hace el lenguaje de programación Java (cuyos interfaces son una transcripción de los “protocolos” de Objective-C). Pero, claro, los interfaces Java sólo servirán para acceder objetos Java desde objetos Java. IDL, en cambio, no es parte de un lenguaje de programación, sino una estructuración que permite el acceso a objetos con independencia del lenguaje del lenguaje de programación en que éstos hayan sido codificados. Tal independencia se sustancia en las correspondencias (mappings) entre IDL y distintos lenguajes (C++, C, Smalltalk, etc.), a los que ahora se añadiría Java. Lo primero, claro, es ajustar la nomenclatura genérica de IDL a la de cada lenguaje:

Además IDL provee tipos predefinidos (esto es, declaraciones de tipos) y facilidades para la creación de nuevos tipos (o sea, soporte para clases o estructuras de datos –no olvidemos C- codificadas en auténticos lenguajes de programación).De hecho el “mapping” entre IDL y un lenguaje particular –Java, en nuestro caso- procura el pegamento y el transporte que posibilitarán que la invocación IDL remota de un método en un objeto Java pueda “llegar”, por mediación de la máquina virtual Java, hasta el cuerpo de tal método [4].

La próxima versión del JDK [5] contendrá (además de especificaciones como InfoBus, el modelo de delegación añadido a JavaBeans –actualmente conocido como Glasgow-, soporte de IIOP, Enterprise JavaBeans, el núcleo de un ORB y muchas cosas más) soporte directo para Java IDL, con lo que el ánimo de interoperabilidad será sustancial a la plataforma. Java IDL consta de:

• El núcleo de un ORB genérico, que procuraría capacidades de ejecución Java a las aplicaciones Java IDL, de tal manera que éstas puedan ejecutarse bien como applets en continentes apropiados (appletviewers, paginadores, etc.) bien como aplicaciones autónomos en las distintas plataformas soportadas por Java.
• La herramienta –de nombre autodescriptivo- “idltojava” que, a partir de interfaces remotos, genera esqueletos de definiciones de interfaces y stubs para las partes cliente y servidora.
• Una implementación (nameserv) del servicio de nombres del COS (CORBA Object Service).

Es importante notar que Java IDL se basa en el núcleo de un ORB Java transportable especialmente diseñado para trocar fácil la conexión de distintos protocolos ORB, de manera que la herramienta de línea de comando “idltojava” generaría stubs independientes de implementaciones de ORBs específicos, que a su vez se enlazarían con los módulos de protocolo del ORB concreto finalmente utilizado.

JAVA Y TAU ZERO

a masa de la plataforma Java aumenta a ojos vista conforme su velocidad de desarrollo crece hasta extremos inabordables. De un mes a otro artículos, esquemas, opiniones y propuestas quedan desfasados, inservibles o ridículos. Con todo, quedan temas que tratar: Infobús (cuyo borrador de especificación, versión 0.04, fue sometido a revisión pública, por vez primera, a finales de julio-97), la biblioteca JFC, Glasgow, etc. Veremos qué ocurre hasta el próximo número de RPP.

[1] Tras los escándalos “WaterGate” e “IranGate”, es de esperar que los términos “BillGate”, “SunGate” y “LacaGate” hayan de indicar fracasos, traiciones y desesperanzas. Y es que el “orpín” finalmente moja.

[2] Ya saben que el perfecto invitado es el que consigue que su anfitrión se sienta como en casa.

[3] Como “castles in Spain” son “castillos en el aire”, parece que a algunos sólo les queda el consuelo del recubrimiento artístico a-la-Hendrix (ya saben, me refiero a la canción).

[4] Tal método, inserto en una clase Java, no ha de estar codificado necesariamente en Java, pues no hemos de olvidar que el JNI (Java Native Interface) permite que la máquina virtual Java ligue en fase de ejecución la invocación de un método a una implementación codificada en un lenguaje distinto, como C ó C++, por lo común contenida en una DLL.

[5] Se trata, naturalmente, de JDK 1.2, que se supone aparecerá a finales de 1.997, pues el lector ya sabe que las versiones del JDK de tercer nivel (JDK X.X.X) se refieren a fases de mantenimiento.