Guerra de objetos

A favor de OpenDoc

El presente artículo recoge las opiniones de dos especialistas sobre las tecnologías OpenDoc y OLE/COM. En su primera parte, se realiza una defensa de OpenDoc, mientras en la segunda la balanza se inclina a favor de OLE/COM. El lector sabrá decidir, a la vista de los diferentes argumentos utilizados, cuál de las dos alternativas es la mejor.

Comparar OpenDoc con OLE es como comparar un hombre moderno con el hombre de Neardenthal. Existen similitudes. Si se vistiera a un Neardenthal con un traje moderno y se alejara uno un poco, podrían incluso parecer iguales. Pero para que uno de ellos sirviera de ayuda en el negocio, habría que mirar mucho más de cerca. Ser competitivo significa poder reaccionar y adaptarse al cambio rápidamente. El software de componentes es la clave. OpenDoc ha sido diseñado para crear aplicaciones flexibles en base a componentes. Por otra parte, Object Linking and Embedding (OLE) y su Common Object Model (COM) han sido diseñados para enlazar las aplicaciones monolíticas y de uso general del pasado. OLE/COM representa una ramificación anterior en el período de la evolución del software.

Un estándar de componente debe evolucionar sin obstáculos, estar ampliamente disponible, y ser fácil de utilizar. OpenDoc es el único estándar de componente de software disponible que cumple con este criterio, y puede obtenerse actualmente para Windows, MacOS y OS/2. IBM ha anunciado planes para hacerlo disponible para sistemas Unix, OS/400 y MVS.

WordPerfect de Novell, Apple Computer e IBM han entregado kits de desarrollador a más de 54.000 desarrolladores de aplicaciones en todo el mundo. Muchos vendedores de software, incluyendo Taligent, Adobe Systems, Novell, Apple e IBM entregarán componentes y herramientas OpenDoc durante este año. El software que ofrece una ventaja competitiva para las empresas es una mezcla rica y variada de partes corrientes y especializadas. Algunas partes se compran dispuestas para funcionar; los integradores de sistemas adaptan otras; y unas pocas las crean a medida los propios usuarios. Este entorno a medida y abierto aumentará la flexibilidad de las aplicaciones y reducirá los costos. OpenDoc ha sido creado para este entorno.

OpenDoc eleva el listón que deben superar los usuarios y los desarrolladores de aplicaciones, y ofrece el conjunto de funciones siguiente, bajo el que debe juzgarse cualquier tecnología de componentes:

- Servicios de gestión de objetos, basados en el modelo SOM (System Object Model) de IBM, que cumplen completamente con la arquitectura CORBA (Common Object Request Broker Architecture) del Object Management Group (OMG). Estos servicios permiten acceder a los componentes y protegerlos, dondequiera que se encuentren. Su pueden añadir o sustituir componentes a voluntad, reaccionando rápidamente ante las oportunidades comerciales del momento.

- Servicios de componentes, basados en el formato de ficheros Bento de Apple, que son utilizados ampliamente por Lotus Development y otros. Estos servicios permiten a los usuarios salvar a intercambiar datos de componentes. Cuando un departamento desarrolla nueva información comercial, otros departamentos pueden actuar rápidamente sobre esa información. Los servicios de documentos combinados y automatización, que incluyen la arquitectura OSA (Open Scripting Architecture) de Apple, permiten a los desarrolladores adaptar fácilmente las aplicaciones y reducir el costo de formación de los usuarios.

OpenDoc ha sido diseñado para crecer sin problemas para los desarrolladores y usuarios, de forma que las aplicaciones puedan recoger nuevas funciones y características de forma rápida y económica. Thomas J. Mowbray, director científico de la firma Mitre, ha comentado recientemente esta flexibilidad en la revista Object, señalando que, a diferencia de OLE/COM, OpenDoc ha sido diseñado con arquitecturas extensibles que no requieren una revisión sustancial para soportar requerimientos de aplicación especializados. Esto se debe a que OpenDoc ha sido diseñado para componentes extensibles -objetos reales- y no para aplicaciones.

Por ejemplo, el depósito de entrada de OpenDoc puede ser ampliado rápidamente para clasificar y filtrar el correo. La tecnología de objetos reales hace que los componentes OpenDoc sean pequeños, eficientes y fáciles de desarrollar. En comparación con esto, la programación para OLE es compleja y poco flexible. OLE 1.0, con 50 interfaces de programación de aplicaciones (API) específicos, ha resultado un producto bastante difícil. Los 400 interfaces API de OLE 2.0 traumatizaron a los desarrolladores y requirieron una sustancial reestructuración de las aplicaciones.

Un obstáculo importante

La parte COM de OLE -es decir, la forma en que los desarrolladores OLE deben definir sus componentes- hace más difíciles las cosas. Es una especificación (no una implementación) que debe implementar cada desarrollador, y sin embargo impide a los desarrolladores extender eficientemente los componentes sub-clasificándolos. COM presenta tantas restricciones que Digital Equipment ha emprendido la tarea de arreglarlo.

OpenDoc fue desarrollado concurrentemente en múltiples plataformas, y se adaptará a los servicios de software y de red necesarios para el funcionamiento de las empresas. Por ejemplo, WordPerfect ha añadido funciones que permiten a los componentes OpenDoc trabajar sin fisuras con aplicaciones OLE y viceversa. Este año, IBM extenderá su soporte de red SOM para incluir las funciones de asignación de nombres y seguridad del Entorno de Proceso Distribuido (DCE) de la Open Software Foundation, y los servicios de transacciones de OMG.

En contraste, OLE/COM sólo será adecuado para sistemas desktop y herramientas propietarias de Microsoft. OLE está más ligado a Windows porque los interfaces API de COM dependen en gran medida de la implementación C++ de Microsoft. Microsoft, por su parte, asegura que implementará OLE distribuido en su producto Cairo, que probablemente será objeto de un aplazamiento, lo mismo que sucedió con Windows95.

OpenDoc hace más productivos a los usuarios y reduce los costos de formación, al ser más eficiente de utilizar. Las raíces y los antecedentes de OLE en el enlace de aplicaciones hacen que las aplicaciones OLE sean grandes, lentas y poco naturales para los usuarios y desarrolladores. Por ejemplo, ningún componente OLE puede exceder de una página de longitud, los componentes no pueden superponerse unos a otros, y cada uno de ellos debe tener una forma rectangular. Además, sólo un componente OLE puede estar activo en un momento dado.

Microsoft se ha comprometido a resolver estos problemas, pero el historial pasado muestra su herencia de carencia de funciones y características, upgrades frecuentes y causantes de alteraciones, implementaciones inconsistentes y sistemas inflados que funcionan deficientemente.

Así que eso es lo que hay. Si se tiene previsto utilizar sólo Windows, si todo el software que se utiliza no requiere adaptaciones, si la empresa no tiene una red funcionando, y si no hay inconveniente en sustituir el software cada dos años, deberá contratarse al hombre de Neardenthal.

A favor de OLE

No tengo muchas dudas de quién ganará la guerra OLE versus OpenDoc. Object Linking and Embedding (OLE) supera a su rival tanto desde el punto de vista comercial como técnico, en tal medida que esta guerra es una pérdida de tiempo y esfuerzo sin sentido.

Entre las ventajas que cabe apreciar en el momento en que se empieza a trabajar con OLE, cabe destacar el disponer de una ruta de evolución clara desde las aplicaciones de productividad personal más populares actualmente hacia el componentware. Y su modelo COM (Common Object Model) ofrece una vía hacia los objetos distribuidos.

Tanto OLE/COM como OpenDoc tienen el objetivo de facilitar el c