ObjectWatch Newsletter #7

Durante la última semana, he oído que Microsoft

a) Está tratando de tomar el control de Java
b) Está tratando de esconderse de Java
c) Merece ser demandado por Sun por crímenes contra la humanidad
d) Debe ser venerado por los mortales por sus grandes logros

Y por último pero no menos importante, el humilde, pero siempre muy popular

e) Ama a Java
f) Odia a Java

Yo pasé gran parte del último año investigando la posición de Microsoft sobre Java. Necesitaba entender este asunto para mi nuevo libro (COM y DCOM; la visión de Microsoft para los Objetos Distribuidos). Leí cada memo, noticia, y paper que pude encontrar sobre este asunto. Hablé con muchos del equipo Java de Microsoft. Para bien o para mal, parece que me convertí en el experto de "lo que Microsoft piensa de Java". De hecho, basándome en algunas de mis últimas discusiones, sospecho que yo entiendo este tema mejor que mucha de la gente que trabaja en Microsoft.

Pero antes de que pueda meterme dentro de la perspectiva de Microsoft sobre Java, necesito darte una "ambientación". Primero, tengo que darte una perspectiva histórica sobre de dónde viene Java. Segundo, te tengo que dar una explicación un poco más técnica de qué es Java. Tercero, te tengo que contar qué es lo que Microsoft está tratando de lograr para los próximos cinco años. Con este trasfondo, podremos discutir qué es lo que Microsoft realmente piensa sobre Java.

Empecemos con la historia de Java. Java fue creado por Sun. Muchas compañías se subieron al tren de Java. El más notorio de estos "conversos precoces" fue IBM.

¿Qué impulsó esta arriesgada alianza entre Sun e IBM? ¿La increíble superioridad de Java como tecnología de programación? Difícil. Recuerda, esta alianza fue formada lejos y hace tiempo cuando Java tenía un mínimo de sus capacidades y era poco más que un juguete.

Podemos excavar más hasta encontrar el propósito de esta alianza al fijarnos en la última vez que estas dos empresas se unieron en un inmenso esfuerzo para la industria. Esta última colaboración resultó en la tecnología de objetos distribuidos conocida como CORBA, producida por un consorcio de la industria llamado Grupo de Manejo de Objetos (OMG).

Yo estaba muy involucrado en el OMG. Yo trabajaba para IBM en esa época, y era un arquitecto líder de uno de los servicios de CORBA. Escribí mi último libro en este asunto (Persistencia de Objetos; detrás de las bases de datos orientadas a objetos).

El consorcio OMG se mantenía junto con un único propósito: detener a Microsoft. El OMG falló en este esfuerzo, y se mantiene solo con unas pocas compañías generando una mínima ganancia con la tecnología CORBA.

Mucha gente acusa a Microsoft de enfrentar cualquier amenaza tecnológica con un abrazo y una estrategia más suave. Esto ciertamente no es verdad debido a la reacción de Microsoft ante CORBA. A pesar de los millones de dólares que IBM, Sun, y otros estaban gastando en CORBA, Microsoft nunca tomó a CORBA en serio. Microsoft se unió al OMG, y ocasionalmente envió un representante a las reuniones del OMG, pero veían todo el asunto con un aire de diversión, como si estuvieran viendo a un chico jugando.

Para 1994, estaba claro para Sun e IBM (y más tarde Netscape y el resto de la industria) que el OMG no iba a ser el caballero en la armadura brillante que los protegería del dragón de Microsoft. Así que empezaron a buscar a un nuevo protector. Y creyeron que lo encontraron en Java. Pronto la mayoría de la industria se había subido en el tren de Amar-a-Java/Detener-a-Microsoft.

¿Porqué la industria creyó que Java detendría a Microsoft? Y yendo al caso... ¿Qué era exactamente lo que la industria quería impedir que Microsoft haga?

Sun e IBM en particular vieron al mundo entero moviéndose en la dirección de los sistemas operativos de Microsoft. IBM había sido humillado en su intento de que el OS/2 sea tomado en serio. Sun dependía del éxito de su versión de Unix "Solaris".

Pero los vendedores de sistemas operativos estaban en una mala posición. Para 1995, la mayoría de las computadoras del mundo corrían alguna versión de Windows. Nadie iba a escribir nuevo software para otra cosa que no fuese Windows.

Con Java, la industria creyó que tenía un mecanismo para escribir software que correría en cualquier sistema operativo. Para los vendedores de sistemas operativos, esto sería grandioso. De pronto no importaría si tan sólo tenían una pequeña franja del mercado de sistemas operativos, ellos podrían seguir ofreciendo a los vendedores de software un mercado viable. Así Sun e IBM tomaron la posta de crear software "escribir-una-vez/correr-donde-sea" (WO/RE) usando Java.

Java prometió una solución WO/RE mediante una combinación de tecnologías probadas y comprobadas. Éstas incluyen una especificación de lenguaje, un pseudo-compilador, una máquina virtual, y una serie de librerías. Éstas librerías estarían disponibles para todas las plataformas Java y definirían la Java API WO/RE "oficial". Estas librerías son básicas para WO/RE y de acuerdo a Sun e IBM, WO/RE es básico para Java.

Ésta no es la primera vez en la que la industria promete la solución WO/RE. De hecho, éste es un tema recurrente desde el amanecer del software. Unix, CORBA, y C++ son algunos ejemplos de los muchos productos que originalmente hicieron promesas similares.

George Santayana dijo: "Aquellos que no puedan recordar el pasado están condenados a repetirlo." Desafortunadamente, la memoria colectiva de nuestra industria parece particularmente pobre. WO/RE nunca funcionó y me parece improbable que algún día funcione. Y parece que estamos atrapados en un ciclo sin fin de re-aprender esta lección.

El sueño WO/RE enfrenta un dilema tecnológico. Los usuarios, como el grupo mimado que son, esperan una experiencia interactiva de gran calidad y una rica funcionalidad. El software sólo puede cumplir estas expectativas tomando toda ventaja posible del sistema operativo subyacente. Pero el software que haga esto no va a correr donde sea. El software que realmente corre en cualquier lado sólo puede usar tecnología que exista en cualquier lado. Servicios que estén universalmente disponibles son servicios universalmente chotos. Software basado en características tan chotas sólo puede terminar como el McDonalds del software: sin ofender a nadie pero sin impresionar a nadie.

Mientras que a los vendedores de software les interesa que sus productos corran en todos lados, a sus usuarios no les importa. A un usuario sólo le importa que el producto corra bien en una máquina en particular, la que está usando. Un producto escrito para servicios genéricos nunca podrá competir en el corazón del usuario contra un producto escrito especialmente para el sistema operativo del usuario.

Si bien el fracaso de WO/RE era predecible, muchos vendedores de software no pudieron resistir el brillo. Ellos trabajaron duro para escribir productos usando sólo Java y las librerías WO/RE. Esos vendedores aprendieron la lección por el peor camino. Hasta donde sé, no queda ningún vendedor de software importante que siga desarrollando un producto comercial basado en la capacidad WO/RE de las librerías Java.

Pero el hecho de que WO/RE no funcione no significa que Java deba ser abandonado.No queremos matar al perro para acabar con la rabia. Java sigue siendo un excelente lenguaje, mucho mejor que C++. El problema no es el lenguaje, sino las librerías WO/RE. Es más, el problema real no son las librerías en sí, sino el "edicto" de que esas librerías consistan en todo el rango de posibilidades de la programación en Java.

Las metas de Microsoft para los próximos cinco años son bastante simples. Quieren que NT sea la plataforma de elección para hacer todas las aplicaciones de comercio distribuido. Esto básicamente prepara el terreno para una nueva batalla, y el campo de batalla es la arquitectura de los tres niveles.

Microsoft cree que la arquitectura de tres niveles será la base del comercio distribuido. La arquitectura de tres niveles define un nivel de cliente, un nivel de componentes, y un nivel de datos. El nivel cliente es de Microsoft desde hace rato. Microsoft ahora va tras el nivel de componentes con una venganza, y se prepara para ir tras el nivel de datos mediante una guerra de desgaste.

Microsoft definió una arquitectura que soporta aplicaciones distribuidas basada en componentes. Un componente es un paquete de software que puede hacer algo específico, tareas bien definidas. Los componentes pueden comunicarse unos con otros, y esta comunicación puede ocurrir dentro de un nivel o entre niveles.

Microsoft quiere estar en el negocio de los tres niveles. Quiere proveer el sistema operativo en el cual corra el software basado en componentes de tres niveles. Microsoft soportará felizmente cualquier producto que encaje en esta visión, y no dará soporte a aquellos que no encajen. Las piezas más importantes en el plan de Microsoft son COM, DCOM, y MTS. Eventualmente éstas tres se van a unir en COM+.

Ahora que hemos visto la historia de Java, la tecnología Java, y la agenda técnica de Microsoft, podemos entender mejor cuál es la posición de Microsoft acerca de Java.

Sería lógico pensar que Microsoft odia a Java. Después de todo, Java carga desde su nacimiento con la tarea de poner a Microsoft de rodillas. Y esa era, en efecto, la posición original de Microsoft en cuanto a Java.

Pero entonces dos cosas pasaron que hicieron que Microsoft repiense su posición. Primero, el grupito de curiosos e inteligentes ingenieros de Microsoft descubrieron lo fácil que era trabajar con Java en lugar de C o C++. Segundo, Microsoft descubrió que Java es un lenguaje ideal para implementar el tipo de componentes en el que Microsoft basó toda su estrategia corporativa.

Así que Microsoft hizo un lavado de cara, y puso sus fichas en el lenguaje Java. No veo ninguna evidencia de que ese apoyo haya decaído en lo más mínimo. Microsoft se ve totalmente comprometido a proveer las mejores herramientas para crear componentes usando Java. Si bien Microsoft siempre va a soportar otros lenguajes de desarrollo de componentes, creo que Java será el lenguaje de elección de Microsoft para implementar el software que corra en el nivel de componentes.

Pero entonces aparece el problema de las librerías WO/RE. Aquí Microsoft difiere del resto de la comunidad Java, y en particular, de Sun.

Algunas de estas librerías WO/RE están pensadas para soportar interfaces gráficas. Microsoft tiene herramientas mucho mejores para crear el software que corra en el lado cliente que Java. Algunas de estas herramientas, como DHTML, van a estar incluso disponibles para plataformas que no son de Microsoft. Estoy de acuerdo con Microsoft que Java es una tecnología inferior en cuanto a interfaces gráficas.

Algunas de estas librerías WO/RE compiten directamente con la arquitectura de Microsoft. La capacidad de Java llamada Invocación de Métodos Remotos (RMI), por ejemplo, permite a los objetos de Java comunicarse entre distintos procesos. Microsoft ve esto como una competencia con DCOM. En mi opinión, RMI no se acerca ni por asomo a COM/DCOM/MTS, y ni siquiera se ocupa de temas importantes como la independencia del lenguaje, pooling de objetos, seguridad, y soporte de transacciones. Pero esas librerías WO/RE que Microsoft vé, bien o mal, como competencia a su propia arquitectura van a tener, con suerte, muy poco soporte de Microsoft.

Microsoft cree que la arquitectura COM/DCOM/MTS es un avanzado ambiente de runtimes de componentes, y los componentes de Java deben tomar ventajas de todo lo que ese ambiente pueda ofrecer. Obviamente componentes que tomen ventajas de este ambiente no van a funcionar en ambientes distintos de COM/DCOM/MTS. Pero, continuando el razonamiento, ¿Vos querés componentes full que trabajen bien en la plataforma para la cual fueron creados, o componentes insípidos que corran en cualquier tostadora que tenga un microchip con una máquina virtual de Java embebida?

Microsoft no apoya la filosofía WO/RE. Si estás molesto, podrás pensar que WO/RE está en conflicto con el interés propio de Microsoft. Pero yo creo que WO/RE es una fantasía por fuera del mundo trivial de los applets para navegadores. Las librerías WO/RE de Java actuales ni siquiera se acercan a proveer la rica infraestructura necesaria para las aplicaciones de comercio distribuido.

Parte de la actual disputa legal entre Sun y Microsoft tiene que ver con esta visión y en parte tiene que ver con control.

La visión de Java que tiene Sun es muy diferente de la que tiene Microsoft. Sun ve a Java como un entorno de objetos completo, propocionando un paquete de APIs para todo, desde interfaces gráficas hasta comunicación con bases de datos. Microsoft ve a Java como un buen lenguaje para desarrollar componentes que vivan en uno de los tres niveles, específicamente, el nivel de componentes. No creen que un programador deba ser forzado a usar Java en uno de los otros niveles, donde Java es una tecnología básicamente inferior, tan sólo porque lo están usando en el nivel de componentes. Y no creen que los programadores en Java deban ser forzados a programar en un entorno de rutinas medieval como el precio por usar el lenguaje.

Sun parece estar diciendo que Microsoft quiere tomar el control de Java. Yo encuentro este argumento poco convincente. Yo escuché a Microsoft diciendo que nadie debe controlar a Java. Distintas compañías deberían ser capaces de mejorar a Java como mejor les parezca. Un mercado libre y abierto es el foro apropiado para decidir el futuro de Java, no cortes judiciales y cárteles corporativos. Los programadores que quieran un entorno WO/RE deben ser libres de elegir implementaciones WO/RE. Los programadores que quieran hacer aplicaciones comerciales de alto rendimiento, deben ser libres de elegir implementaciones de fuerza industrial y entornos de rutinas específicas. Si alguna compañía está tratando de controlar a Java, es obvio para mí que esa compañía es Sun, y no Microsoft.

En mi estudio de la arquitectura de componentes distribuidos de Microsoft, incluyendo Java, COM, DCOM, MTS, Falcon, y Wolfpack, descubrí que Microsoft consistentemente provee frameworks abiertos que alientan la participación de terceras partes, incluso cuando esas terceras partes estén vendiendo productos que compiten directamente con Microsoft. En algunos casos Microsoft ni siquiera espera a que sus competidores se adapten a los frameworks de Microsoft, ¡Microsoft escribe las adaptaciones por ellos! ¿Acaso esto suena como el comportamiento de una compañía que tiene miedo de competir?

Así que yo pienso que se puede resumir la posición de Microsoft acerca de Java en una forma muy simple. Apoyan totalmente a Java como lenguaje. Están comprometidos a proveer herramientas competitivas para desarrollar componentes en Java que corran en el nivel de componentes. Y en cuanto a las librerías y a las rutinas del entorno Java, digamos que cada compañía provea el mejor soporte para Java que pueda, y dejemos que la mejor arquitectura gane.