Objetos distribuidos por todas partes

Distributed Objects Everywhere ( DOE ) fue un proyecto de larga duración de Sun Microsystems para crear un entorno de computación distribuida basado en el sistema CORBA como backend y OpenStep como interfaz de usuario. Iniciado en 1990 y anunciado poco después, permaneció como un proyecto fantasma durante muchos años antes de ser finalmente lanzado como NEO en 1995. Se comercializó solo por un corto período antes de ser abandonado (junto con OpenStep) en 1996. En su lugar se encuentra lo que hoy se conoce como Enterprise JavaBeans .

A principios de la década de 1990, la gran novedad en informática consistía en utilizar microordenadores de escritorio para visualizar y editar datos procedentes de mainframes y miniordenadores . Si bien ya existían varios métodos para este tipo de acceso, la división del trabajo no era equitativa. Por ejemplo, SQL requería que la estación de trabajo descargara enormes conjuntos de datos y los procesara localmente, mientras que el uso de emuladores de terminal dejaba todo el trabajo al servidor y no ofrecía interfaz gráfica de usuario .

Parecía que la distribución adecuada de tareas consistiría en un conjunto cooperativo de objetos, donde la estación de trabajo se encargaría de la visualización y la interacción con el usuario, mientras que el procesamiento se realizaría en el servidor. Sin embargo, esta solución se veía obstaculizada por las enormes diferencias en los sistemas operativos y los lenguajes de programación entre las distintas plataformas. Si bien podría ser posible construir un sistema que funcionara en cualquier combinación de estación de trabajo y servidor, la misma solución no funcionaría en ningún otro sistema.

Curiosamente, las diferencias entre dos lenguajes de programación cualesquiera en una misma plataforma eran casi igual de grandes. Cada lenguaje tenía su propio formato para pasar parámetros a las llamadas a procedimientos , y los formatos de archivo que generaban solían ser bastante diferentes. En términos generales, no siempre era posible escribir distintas partes de un programa en lenguajes diferentes, aunque hacerlo suele ser muy útil. El problema no era tan grave en minicomputadoras y mainframes, donde el proveedor solía especificar estándares para sus bibliotecas, pero en microcomputadoras los sistemas de programación generalmente eran proporcionados por diversas empresas externas sin interés en la estandarización.

No obstante, este problema se abordó a principios de la década de 1990 mediante la introducción de diversos sistemas de bibliotecas compartidas . Estos sistemas tenían como objetivo facilitar el uso de recursos en plataformas más pequeñas, permitiendo que varios programas que utilizaban un recurso común, como la interfaz gráfica de usuario (GUI), compartieran una única copia del código en lugar de que cada uno cargara una copia independiente en la memoria. Como consecuencia de poder ser llamados desde múltiples programas, estos sistemas también definieron una forma estándar de invocarlos, utilizando un lenguaje de definición de interfaz (IDL), que permitía a cualquier lenguaje de la plataforma comprender el código de la biblioteca.

La ampliación de estos sistemas para admitir llamadas a procedimientos remotos en segundo plano se consideró una evolución natural, que ofrecía una solución al problema de la programación cliente/servidor. En aquel momento, existían varios proyectos importantes para desarrollar un sistema de este tipo, como el System Object Model (SOM/DSOM) de IBM , los Portable Distributed Objects de NeXT , el Component Object Model (COM/DCOM) de Microsoft y diversas variantes de CORBA . Sun, en su intento por posicionarse como el futuro IBM en lo que respecta al soporte administrativo, consideró que también debía incursionar en este mercado.

La solución de Sun se basó en el trabajo realizado en su sistema operativo Spring , que utilizaba objetos interconectados para casi todas las tareas de programación. Modificarlo para que funcionara en un sistema Unix "tradicional" como Solaris no fue demasiado difícil, aunque Unix parte del supuesto de que todos los programas se ejecutan localmente, por lo que fue necesario añadir una interfaz para el acceso remoto. Para ello, el Departamento de Energía (DOE) añadió un agente de solicitudes de objetos (ORB) que se ejecutaba en los servidores de back-office, escuchando las solicitudes del DOE y transfiriéndolas al programa adecuado para su procesamiento. Durante el desarrollo, CORBA se convirtió en un término clave en la industria. Esto provocó un retraso mientras se rediseñaba el ORB para que fuera compatible con CORBA. Bajo el modelo CORBA, diferentes objetos, como los del DOE o SOM, podrían interactuar compartiendo una interfaz común.

Un problema mayor para Sun era que no contaban con una solución integrada de programación de objetos para escritorio. Si bien las bibliotecas de objetos de C++ se estaban volviendo comunes en algunas plataformas, su propio sistema operativo SunOS (más tarde conocido como Solaris ) y los sistemas asociados SunView y X window se basaban en C puro, mientras que su nuevo entorno de ventanas NeWS se basaba en un dialecto orientado a objetos extensible en red de PostScript .

Para ofrecer una solución de programación orientada a objetos completa y flexible, Sun recurrió a NeXT y juntos desarrollaron OpenStep . La idea era que los programas de OpenStep llamaran a objetos del Departamento de Energía (DOE) en servidores Sun, proporcionando una solución integral que conectara el backoffice con el frontoffice en máquinas Sun. OpenStep no se lanzó hasta 1993, lo que retrasó aún más el proyecto.

Para cuando DOE, ahora conocido como NEO, se lanzó en 1995, ^{[ 1 ]} Sun ya se había volcado a Java como su próximo gran proyecto. Java era ahora la interfaz gráfica de usuario preferida para las aplicaciones del lado del cliente, y los planes de Sun para OpenStep se abandonaron discretamente (véase Diseño de Lighthouse ). NEO se reposicionó como un sistema Java con la introducción del marco "Joe", ^{[ 2 ]} pero tuvo poco uso. Los componentes de NEO y Joe finalmente se integraron en Enterprise JavaBeans . ^{[ 3 ]}

Si bien los objetos distribuidos, y CORBA en particular, fueron la gran novedad a principios de la década de 1990, en la segunda mitad de la década el interés por ellos prácticamente desapareció. Las aplicaciones web que se ejecutaban completamente en el servidor se convirtieron en la nueva gran novedad, y la necesidad de un sistema de visualización potente en el lado del cliente se desvaneció, siendo reemplazada en gran medida por interfaces gráficas de usuario ligeras basadas en HTML y JavaScript (" Interfaces de usuario de navegador ").

• Shah, Rawn (1 de junio de 1996). "Computación de objetos distribuidos con Joe y NEO" . JavaWorld . Recuperado el 15 de julio de 2020 .