JEDI es el acrónimo de "Java Enabled Database access over the Internet", un proyecto liderado por TransTOOLs SA [1], y en el que participan ST&C GmbH, Anaya Multimedia SA, CSC Ploenke GmbH, Giunti Multimedia SRL, constituidos como "Consorcio JEDI", que pretende, mediante el uso extremo de la tecnología Java, revolucionar el mercado de herramientas multimedia y el uso de recursos en Internet. Claro que esto lo dicen todos: lo mejor, lo más eficiente, lo más flexible, lo más neumático es... ¡lo mío! Pero en realidad no es esto lo que interesa probar o, siquiera, mostrar aquí, sino más bien el proceso, preñado de decisiones, esperanzas y desazones, que ha llevado al proyecto a una posición de "altura tecnológica" no exenta de riesgos, pero también repleta de ventajas técnológico-empresariales. De hecho, la facilidad con que en Java se anuncian, publican y promocionan APIs, notas de prensa y voluntades empresariales, da finalmente en conseguir que proyectos como éste deban situarse en puntos temporales estratégicos para esperar a la tecnología y, en ese momento preci(o)so, usarla con una preparación muy buscada. Como cazar patos. O como esperar un trolebús en la vía. En lo que sigue se mostrarán, pues, decisiones, pero también sus antecedentes; tecnología, pero también sus riesgos; herramientas, pero con su pléyade de bondades e inconvenientes. Se explicitarán, en fin, y dentro de lo posible, situaciones que se pretende hagan pensar al lector: ¡Diantre! ¡La tecnología está disponible y yo estoy perdiendo el tiempo sin hacer nada! Con todo, las características de ventajas estratégicas competitivas que poseen algunas partes del proyecto impedirán su difusión aquí, pero en todo caso espero que resulte claro el mensaje tecnológico-empresarial. El tono será, por tanto, intencionadamente elemental, pero pretendidamente ilustrativo. A ello.

BREVE OBJETIVO

El objetivo principal del proyecto JEDI, que comenzó el 15-01-1997 con una duración estimada de dos años, es el desarrollo tanto de una herramienta como de un método de trabajo que permita crear con facilidad títulos multimedia multi-soporte: es decir, publicaciones que combinen los actuales formatos físicos (libros, CD-ROMs, etc.) con el acceso a bases de datos en Internet. De esta forma los editores podrían centrarse en la información en sí, obviando buena parte de los aspectos técnicos, no sólo para construir un título, sino también para mantenerlo actualizado. Naturalmente se espera que el concepto desarrollado en JEDI traspase el mercado editorial hasta llegar a los integradores de sistemas que requieran un acceso no trivial a bases de datos corporativas. Así que JEDI es... ¡un momento! Repasemos brevemente el mercado antes de entrar en materia.

EDITORES, HERRAMIENTAS Y CRITERIOS

La segmentación actual del uso de herramientas multimedia (con el predominio comercial de un grupo muy reducido de compañías) plantea varias cuestiones. La primera es: ¿Qué criterios aplican los Editores Multimedia (EMs, en adelante) en el proceso de elección de una herramienta para el desarrollo de títulos? Las encuestas nos muestran que, de forma no sorpresiva, el mercado multimedia observa los mismos esquemas, desviaciones y errores que el segmento genérico de desarrollo de software: esto es, la herramienta se impone a sus creadores. Esto es, los EMs en realidad no eligen un "paradigma" para la creación de sus títulos editoriales, sino que más bien eligen, principalmente por razones comerciales, una herramienta dada y posteriormente -¡qué remedio!- se ajustan a su enfoque de modelado. Es lo que ocurre, sin ir más lejos, con la metáfora "cast-score-scripting" de Macromedia Director. ¿Es una buena metáfora? No es mala, ciertamente. Pero, ¿es suficiente? Yo diría que no, al menos manteniendo ciertos índices de adecuación. La cuestión adicional que se plantea es: ¿dónde se sustancia el precio? Esto es, ¿es realmente importante el precio en la decisión de compra y extensión de una herramienta? De nuevo los EMs, en rangos razonables, estiman que no. Bueno, la verdad es que estiman que sí, pero finalmente el estudio a posteriori de la compra muestra que no se tomó el precio como factor crítico en la decisión de adquisición. Y aquí es donde el lector se cuestiona: ¿se trata, pues, de una cuestión de integración de herramientas y sistemas? De nuevo... ¡no! "Hay lo que hay, y a eso nos ajustamos", parece querer decirse desde las EMs, abstracción hecha del soporte PC-Mac. Y es que, ¿dónde están los requerimientos de clientes respecto de los títulos multimedia? Oh, no puede haberlos más allá de los que se desprenden del estudio de las cifras de mercado, pues el flujo de comunicación EM-cliente es todavía grandemente unidireccional.

EL SER Y EL NO-SER

Como base para la ocupación de su propio nicho de mercado, JEDI necesita diferenciarse de la competencia, de tal forma que no debiera recrear herramientas bien establecidas como Director 6 o Toolbook II, con incontables apósitos y sofisticados esquemas de integración interna; como tampoco debiera basarse en un modelo restringido de componentes o en el simple enlace de tuberías respecto de una herramienta "Big Brother". Claro que el producto JEDI no debe, en ningún caso, ser tan simple que resulte inoperativo respecto de buena parte de los títulos multimedia. Pero todo lo dicho está más en el no-ser que la esencia de lo que queremos, que en realidad es crear un producto:

• Plenamente operativo en Internet (Network-aware: esto es, manteniendo esquemas de comunicación remota, seguridad, transparencia, etc.

• Ligero y orientado-a-tareas , obviando así el problema TMF (Too Many Features) típico de las aplicaciones hegemónicas [2], como MS Word [3].

• Actualizable remotamente con facilidad, mediante el empotramiento de una arquitectura de distribución.
• Ajustable a los requerimientos específicos del cliente , pues así como un notario usualmente requiere un procesador de textos específico, distintas familias de productos multimedia han de requerir distintas herramientas de desarrollo.
• Sensible a cambios y ajustable sin intervención directa, de forma que JEDI pueda manejar automáticamente la adición y eliminación de componentes y comportamientos.
• Multi-Plataforma
• Fácilmente personalizable en la parte cliente , mediante la aplicación de libros de propidades y asistentes, ambos posiblemente transportables por la red.

En razón de lo cual se decidió que JEDI, que por su naturaleza y su acrónimo de principio ya es "Java Enabled", debiera ser, más que una herramienta monolítica de difícil introducción en el competitivo mercado actual, una "familia abierta de continentes especializados con fuertes posibilidades multimedia, capacidades transaccionales y suites físicas de validación". ¡Dios mío! ¿Cómo se pudo llegar a esta frase sin drogas? Veámoslo.

DE LOS APPLETS A LOS JAVABEANS

En el "kick-off meeting" (o "reunión de despegue") del proyecto, en enero-97, el sentimiento previo de los participantes se sustentaba en el aprovechamiento del esquema de ejecución-en-el-cliente Java mediante "applets". ¡Claro! Ésta era entonces la promesa más práctica de Java y, además, la concreción de su pasmo masivo. Así que resultó especialmente delicado plantear la migración hacia algo que, pese a sus tangibles beneficios teóricos, había sido anunciado sólo tres meses atrás y carecía de respaldo comercial explícito: JavaBeans, el nuevo modelo de componentes de JavaSoft o, lo que es lo mismo, la definitiva desviación respecto de Microsoft y el acercamiento a una nueva plataforma Java (JDK 1.1) en versión beta en aquel entonces. Bien: finalmente se planteó la migración desde [código Java + applets] hasta [JavaBeans + JDK 1.1] y fue aceptada en febrero-97. Esto supuso la inoperancia práctica de las herramientas en aquel momento disponibles (por su soporte sólo de JDK 1.0.X) y el trabajo directo con las distintas versiones del JDK 1.1 en línea de comando. Pero es que la opción "appletante" hubiera conducido al proyecto con inusitada rapidez hacia un camino cegado poblado por GIFs animados, niños en edad pre-escolar y adultos presas de la compulsión internista [4]. Con todo, la decisión se tomó una vez comprobado el tendido de puentes JavaBeans desde y hacia applets. También, para minimizar riesgos, se examinaron los componentes Java existentes en el mercado (controles arbóreos, clientes ftp, etc.) y se comprobó su movimiento hacia los APIs de JavaBeans. Finalmente, el establecimiento por parte de Javasoft de lo que llamaron "transitional beans" (esto es, componentes "sujetos" a los nuevos APIs que resolverían sus necesidades con JDK 1.0.2 y otras bibliotecas situadas en el sito web de Sun) convino en asegurar todavía más la decisión de migración.

MICROSOFT Y MODELOS DE COMPONENTES

Varios estudios de mercado revelaron, aun en tan tempranas fechas, que los modelos de componentes LiveConnect, de Netscape, y OpenDoc, de CI Labs, se aglutinarían en torno al nuevo modelo de componentes "abierto" -JavaBeans- para formar masa crítica frente al modelo "propietario" de Microsoft -ActiveX/OLE/COM-. Claro que esto son simplemente etiquetas, pero el dilema es claro: COM/DCOM o CORBA/JavaBeans (y si el lector piensa que esta última unión no es de recibo, debiera revisar la propuesta de CORBA Beans, o la de acercamiento de IIOP a RMI, a buen seguro presentes en la especificación CORBA 2.2 ó 3.0 [5]). ¿Microsoft o Java? ¡Pero Microsoft también se adhirió a Java! No exactamente. En realidad MS acogió en su seno a la realidad comercial de los applets, pero aún ahora está retrasando sobremanera la adopción del resto de la plataforma Java, sustanciado en el JDK 1.1.X y siguientes. Claro que la elección de ActiveX, impecable para departamentos de Intranets, restringiría sobremanera las posibilidades de JEDI. En contrapartida la plataforma Java y, por ende, su modelo de componentes poseía -y posee- los esquemas multi-plataforma, de seguridad e integración que el consorcio pretendía. La existencia, por otro lado, de puentes CORBA/COM (pese a sus manifiestas incapacidades actuales) y la previsión de empaquetadores para que JavaBeans pudieran operar como controles ActiveX en continentes Microsoft. De esta forma finalmente se adoptó JavaBeans como el modelo de componentes de base para la familia de herramientas JEDI. La arquitectura así planteada necesitaba del nuevo JDK 1.1 (con los nuevos APIs) y entornos de desarrollo que la soportaran (en concreto que soportaran JavaBeans y continentes de beans). Las suites de validación habrían de ser implementadas por medio de objetos de implementación que serían empotrados dinámicamente en continentes JEDI. Se estableció, pues, que el modelo de componentes de Java sería usado como modelo troncal, claro que con el corolario de que la integración con COM/DCOM es un objetivo prioritario, por lo que habrían de establecerse procedimientos y políticas de validación inter-modelos para cada uno de los subsistemas JEDI implementados.

ENFOQUE TÉCNICO Y CAPAS ARQUITECTÓNICAS

La "herramienta" JEDI en realidad consta -en esencia práctica- de:

• una familia de continentes jerárquicos Java, basados en los APIs JavaBeans y sujetos a las indicaciones (sugerencias de diseño) del BDK (Beans Development Kit, de Javasoft).
• una galería de componentes (JavaBeans) en calidad de piezas utilitarias (esto es, utilidades)
• un conjunto de modelos de roles, que representan interacciones colaborativas entre JavaBeans individuales y que, a su vez, también son JavaBeans.

En realidad la segmentación en capas de la arquitectura de JEDI obedece al siguiente esquema:

De estas capas quizá sea la básica la que resulte más interesante al lector: como quedo anunciado antes, JEDI comprende un conjunto de herramientas organizadas jerárquicamente en familias de continentes orientados-a-tareas, entre los que cabría destacar:

• Un contenedor de implementación básico cuya misión es operar como la base cósmica de la jerarquía troncal de los JCs. En este contenedor se establecen modelos y reglas de uso de interfaces gráficos de usuario, intentando proveer a la familia entera de continentes JEDI del mismo look-n-feel y comportamiento.
• Una familia/subjerarquía de continentes de validación, dotados con una clase base de implementación para asegurar la aplicación en los continentes derivados de los controles de calidad y métricas obtenidos a resultas de una actividad de I+D paralela al mismo proyecto JEDI y naturalmente inserta en el mismo.
• Una familia/subjerarquía de continentes de integración, a modo de entorno-marco (framework) destinado al filtrado e interacción con los resultados (finales o intermedios) de otros aplicativos, permitiendo así, a la vez, que los resultados de JEDI puedan ser insertados en otras herramientas.
• Una familia/subjerarquía de continentes multimedia, con una clase base "flat" que ha de contener el comporamiento genérico y los módulos de implementación intercambiables.
• Un pequeño conjunto de continentes conceptuales que habrían de servir, como ejemplificación práctica, para demostrar la adecuación orientada-a-tareas de JEDI.
• Una familia/subjerarquía de continentes kioskos que habrían de permitir la construcción simplificada de títulos para kioskos multimedia, direccionando las necesidades de este medio y manejando la actualización de contenidos por medio de una arquitectura de distribución del tipo Castanet.

MODELOS DE ROLES JEDI

Siguiendo estrictamente lo establecido por Trygve Reenskaug, un modelo de roles es una estructura de objetivos colaborativos que representa un modelo de objetos de la comprehensión del mundo real. Los modelos de roles se sustancian en la evidencia de que es imposible hallar objetos completamente aislados en el mundo real, porque en tal caso no participarían en el sistema al que teóricamente pertenecen. Los modelos de roles JEDI (JRMs) constituyen una capa de alto nivel en la arquitectura JEDI y representan las unidades de composición/síntesis para sistemas medios y grandes.

Los beneficios de la incorporación de modelos de roles como capa arquitectónica se derivarían de la creación de modelos colaborativos representativos de problemáticas sectoriales industriales, sin necesitar expresamente de entornos-marco (frameworks) de construcción dirigida, permitiendo, con todo, su uso discrecional.

Los modelos de roles permitirán la personalización "controlada" de los continentes JEDI, además de la fácil creación tanto de continentes de validación específicos por proyecto como la asunción de características de herramientas CAME (Computer Aided Method Engineering) y CAPE (para proyectos).

A la vez, el establecimiento de modelos de roles como componentes básicos de análisis/síntesis de sistemas permitirá la codificación (mediante objetos de implementación JEDI) de precondiciones y postcondiciones para cada JRM que garantizarían su uso en composiciones libres, sobre todo en aplicativos de gestión, pero también respecto de la creación de continentes específicos para "series" de títulos multimedia.

PLANTILLAS Y ROLES

Las plantillas JEDI (JTs) son, en esencia, instanciaciones de modelos de roles JEDI (JRMs), y su intención es proveer a los suarios experiencia y facilidad de uso en áreas anteriormente poco conocidas. Esto es, se trata de un concepto similar al de los patrones textiles o las plantillas de MS Word, pero con un acercamiento consciente (en su calidad de desplazamiento dentro del "manifest model" cooperiano) al modelo del usuario. En realidad son las JTs son más un prueba conceptual que una capa tecnológica, pues su misión es asistir al usuario, utilizando tecnología de duplicación, en la clonación de ejemplares (en el sentido de Coplien) que inmediatamente pudieran ser ejecutados y personalizados.

HERRAMIENTAS Y ESPERAS

En febrero-97, cuando prácticamente sólo existían entornos de desarrollo de juguete (esto es, buenos-para-applets) como MS Visual J++ 1.0, Symantec Cafe o Sun Java Workshop 1.0, el consorcio JEDI decide elegir como herramienta "VisualAge for Java", cuya primera versión es liberada en el mercado por IBM en agosto-97. Se trata de una decisión con una proyección temporal importante, basada en el convencimiento del consorcio de tres supuestos que a estas fechas han sido suficientemente corroborados por la industria:

• La aceptación masiva de JDK 1.1
• La inoperancia práctica de los applets respecto de aplicaciones genéricas de carácter industrial y su carácter básico de elemento fundamental de interfaz gráfica de usuario.
• La aceptación industrial de JavaBeans, debido a la bondad del modelo de componentes de Java frente al de Microsoft y a los previsibles puentes entre ambos (siempre tendidos desde el lado Java).

No obstante el consorcio JEDI decide validar, mediante un continente JEDI de filtro y las oportunas herramientas Microsoft (sustanciadas en Visual J++ 1.1 y el API Jdirect, dependientes en la actualidad de Visual Studio), cada uno de los resultados del proyecto.

El anuncio, por otra parte, de la integración de los productos de Taligent (provenientes en buena medida de una adecuada migración del trabajo desarrollado en los frameworks en C++ del ex-joint-venture) con el entorno IBM y de la adición de capacidades de trabajo en equipo, en la línea Envy Developer (como en la familia VisualAge for Smalltalk), ha redundado en afirmar la conveniencia de tal temprana decisión de producto por parte del consorcio JEDI (a más de las excelentes críticas -entre las que cabría destacar la difundida por Jeff Sutherland- recibidas respecto a su adecuación a los procesos de ingeniería de software, en el sentido de Humphrey). La pasarela CICS y el soporte RMI y de JDBC ha afianzado aún más la propuesta.

ORBs Y NOTAS DE PRENSA

El anuncio de que Netscape distribuiría un ORB Java (concretamente Visibroker for Java) con cada producto "Communicator" (con más de veinte millones de clientes) no hizo sino afianzar la confianza del consorcio en la adopción masiva de JDK 1.1 y en el decidido direccionamiento CORBA de la industria. De hecho Netscape finalmente anunció el pasado 26-08-97 su soporte expreso a JDK 1.1. Por tanto JEDI decidió, ya desde el principio, compatibilizar el acceso HTML/CGI con CORBA IIOP mediante ORBs u ORBlets (esto es, ORBs descargables dinámicamente). El ORB final elegido para ser empaquetado con el producto será probablemente uno de los tres ORBs Java (servidores y clientes) comercialmente estables: el mencionado Visibroker, de Visigenic, OrbixWeb, de Iona, y Joe, de Sun.

ACCESO A BASES DE DATOS

Tanto ODBC como las tecnologías binarias parejas de Microsoft compatibles con Java (DAO, RDO) tienen un techo bien conocido (DAO, basado en JET, alcanzó sus límites tiempo ha, y necesita de parches como Direct ODBC, mientras que RDO es un cul-de-sac). JDBC, sin embargo, a juicio del consorcio JEDI, permite la construcción de topologías cliente/servidor flexibles n-tier, en las que el middleware (previsiblemente Java, gracias a los compiladores Just-in-Time) procuraría la capa adicional de control, independencia y seguridad usualmente necesitada en los proyectos objetivos del producto. Es más: la adopción completa de la plataforma Java posibilita, también, la adopción de esquema en los que caben, incluso, el uso de bases de objetos como middleware para el almacenamiento de HTML generado dinámicamente, con pasarelas para las distintas bases de datos relacionales del mercado.

DISEMINACIÓN Y ACADEMIA

En mayo de 1997 se mostró el proyecto JEDI en la Universidad de Deusto, y en julio-97 en la Universidad de Oviedo -con la que el Consorcio JEDI firmó un convenio de colaboración y tutela-, a la vez que se expusieron sesiones divulgativas en las III Jornadas ATI Orientadas-a-Objetos celebradas en Sevilla en octubre-97. Quizás uno de los aspectos más importantes del proyecto es que pueda convertirse en núcleo doctrinal (tanto en la aplicación de métricas de validación como en la generación de componentes colaborativos para la creación de software basado en cadenas de valor) de investigación en algunos centros académicos, promoviendo así el uso y la aplicación práctica de una tecnología que en absoluto queda lejana, a la vez que permitiría la transferencia tecnológica a núcleos académicos. No queda atrás, con todo, la colaboración con empresas de software para la realización de subsistemas afectos al proyecto JEDI, incluyendo aspectos de documentación, métricas, etc.

AGRADECIMIENTOS

uiero expresar mi agradecimiento al Consorcio JEDI por permitir la publicación siquiera de esta somera información, como también al énfasis puesto por TransTOOLs en el proyecto y, en particular, a la dedicación y soporte de César Pérez-Chirinos y Jorge Murcia, a los lúcidos comentarios de Dirk Fehrman y a las atinadas cuestiones de Enrique Velasco (SIP). Los interesados en obtener cualquier tipo de información adicional sobre el proyecto JEDI y sus actividades pueden dirigirse a Jorge Murcia <jorge@transtools.com>.

[1] Pues sí: TransTOOLs, una empresa netamente española, dirige un proyecto de tecnología punta con un importantísimo bagaje teórico, que ha de generar algunos segmentos doctrinales, y una clara disposición a la practicidad. Y es que finalmente resultará que en España no somos tan timoratos como pudiera pensarse.

[2] Alan Cooper califica las aplicaciones software en hegemónicas, transitorias, demoníacas (en malévola traducción) y parasitarias. Ah, ¿todavía no lo leyó?

[3] El exceso de barras es enemigo de la practicidad, como podría enunciar cualquier borracho habitual.

[4] Abundando en la metáfora de "Star Wars", los applets representarían "el lado oscuro de la Fuerza": esto es, la tentación del movimiento fácil y el cercenamiento del camino de retorno. Luego repararíamos en que no atracamos en la India, sino en las Américas, y quizás nos dé igual.

[5] No existe, a esta fecha, un "borrador de CORBA 3.0", pese a que en USA se anuncia su edición para principios de 1.988. Sí existen, empero, especificaciones y propuestas diferenciales respecto de CORBA 2.0 y que, de hecho, constituirían esa supuesta versión. Con todo, esto no impedirá que en breve el mercado editorial nos inunde con libros sobre CORBA 3.0.