Modelo de objetos del sistema IBM

El Modelo de Objetos del Sistema ( SOM ) es una tecnología de biblioteca compartida orientada a objetos desarrollada por IBM que permite definir una interfaz para un objeto de manera que su interfaz esté separada de su implementación .

DSOM , una variante distribuida basada en CORBA , permitía que objetos en diferentes ordenadores se comunicaran entre sí.

Una biblioteca SOM se puede actualizar sin necesidad de recompilar el código del cliente. Si se modifica una biblioteca para añadir nuevas clases o métodos, o para cambiar la implementación interna de clases o métodos, un programa que la utilice podrá seguir usándola sin necesidad de recompilarla. De esta forma, SOM resuelve el problema de la interfaz binaria frágil que afecta a otras tecnologías de bibliotecas como C++ .

SOM permite definir clases en un lenguaje de programación y utilizarlas en otro. Un cliente puede crear y usar objetos de las clases expuestas y derivar subclases de estas, incluso si el lenguaje del cliente no admite la tipificación de clases.

SOM proporciona una interfaz de programación de aplicaciones (API) que permite acceder a los metadatos de la biblioteca . Cada objeto expone métodos que proporcionan el nombre de la clase y si el objeto implementa un método en particular, por ejemplo.

SOM se diseñó para usarse universalmente en los ordenadores centrales y de escritorio ( OS/2 ) de IBM, permitiendo que los programas diseñados para escritorio utilizaran un ordenador central para el procesamiento y el almacenamiento de datos. IBM produjo versiones de SOM/DSOM para OS/2, Microsoft Windows y diversas variantes de Unix (en particular, AIX, de IBM ). Durante un tiempo después de la formación de la alianza AIM , Apple Computer también utilizó SOM/DSOM con fines similares. Su uso más extendido fue en su plataforma OpenDoc , aunque también tuvo un uso limitado en otras funciones.

Quizás los usos más extendidos de SOM dentro de IBM se dieron en versiones posteriores de OS/2, que lo utilizaban para la mayor parte del código, incluido el Workplace Shell . Object REXX para OS/2 puede manejar clases y objetos SOM, incluido WPS. ^{[ 1 ]}

IBM no eliminó por completo SOMobjects. Se adaptó a OS/390 y aún está disponible en este sistema operativo. Se puede consultar la documentación en el sitio web de IBM. ^{[ 2 ]} En 1996, Tandem Computers Inc. adquirió la tecnología SOMobjects. ^{[ 3 ]} Tandem fue vendida a Compaq, y Compaq fue vendida a Hewlett-Packard. NonStop DOM y otras tecnologías se fusionaron finalmente en NonStop CORBA, pero la documentación actual de los productos NonStop no muestra indicios de que la tecnología SOM siga presente en ellos.

Con la desaparición de OS/2 a mediados de la década de 1990, la razón de ser de SOM/DSOM prácticamente desapareció; si los usuarios no ejecutaban OS/2 en sus ordenadores de escritorio, no existiría una biblioteca de objetos universal. En 1997, cuando Steve Jobs regresó a Apple y puso fin a muchos proyectos de desarrollo, incluidos Copland y OpenDoc , SOM fue reemplazado por Objective-C, que ya se utilizaba en OPENSTEP (que más tarde se convertiría en Mac OS X). El desarrollo de SOM/DSOM se estancó y ya no se desarrolla activamente, aunque sigue incluido y utilizándose en sistemas basados ​​en OS/2 como ArcaOS . ^{[ 4 ]}

A pesar de la desaparición efectiva de OS/2 y OpenDoc, SOM podría tener otro nicho: Windows y el desarrollo multiplataforma . SOM 3.0 para WinNT estuvo disponible en general en diciembre ^de 1996. Las razones para no avanzar en estas direcciones van más allá de los problemas de adopción del mercado. Implican oportunidades perdidas por IBM [ ^{5 ]} y cambios incompatibles destructivos:

• La primera versión de VisualAge C++ para Windows fue la 3.5. Fue la primera y la única versión compatible con SOM. Incluía SOM 2.1 y compatibilidad directa con SOM en el compilador. Las versiones 3.6.5 y posteriores no tenían ninguna compatibilidad con SOM.
• Los objetos SOMobject dependían en gran medida de los makefiles . VisualAge C++ 4.0 introdujo los proyectos .icc y eliminó el compilador y enlazador de línea de comandos icc.exe e ilink.exe. Es imposible compilar cualquier ejemplo de SOM DTK directamente con VAC++ 4.0. VisualAge C++ incluye sus propios ejemplos, pero no hay ejemplos de SOM .icc ni siquiera en VAC++ 4.0 para OS/2. vacbld.exe, la única herramienta de compilación de línea de comandos, no es compatible con SOM.
• La biblioteca de componentes de objetos (OCL) de VisualAge C++ incluida no se basaba en SOM. Probablemente estaba pensada para portarse a SOM mediante el modo C++ Direct-to-SOM, pero en VAC v3.6.5 este modo se abandonó y, hasta el momento, OCL no tiene interfaz SOM.
• A finales de la década de 1990, IBM cerró los sitios de descarga de SOMobjects y nunca los volvió a poner en línea. El SOM 3.0 DTK para WinNT no se encuentra en el FTP de IBM, a pesar de que muchos otros archivos antiguos están disponibles gratuitamente. A pesar de la disponibilidad general del SOM 3.0 para WinNT, fue casi imposible localizarlo hasta finales de 2012.
• Finalmente, IBM nunca liberó el código fuente de SOM (como hizo con Object REXX ), a pesar de varios artículos ^{[ 6 ] [ 7 ]} y peticiones. ^{[ 8 ]}

Existen dos proyectos de implementación de SOM de código abierto. Uno es Netlabs Object Model (NOM), que técnicamente es idéntico, pero incompatible a nivel binario. El otro es somFree, un diseño completamente nuevo de IBM SOM, compatible a nivel binario.

SOM se puede comparar con las siguientes bibliotecas compiladas: ^{[ 9 ]}

• Charla informal
• Sistema de objetos Lisp común (CLOS)
• C++ genérico
• SGI Delta/C++
• Interfaz binaria de objetos de Sun
• Objetivo-C
• Java

A partir de 2015, la mayor parte de la información en la tabla enlazada es aplicable a las versiones modernas, excepto Objective-C 2.0, que obtiene las llamadas variables de instancia no frágiles. Algunas soluciones permanecieron experimentales: SGI Delta/C++ o Sun OBI. La mayoría de los enfoques basados ​​en un lenguaje de programación fueron eliminados gradualmente o nunca se utilizaron activamente de la misma manera. Por ejemplo, los complementos del navegador Netscape Plugin Application Programming Interface ( NPAPI ) se escribieron inicialmente usando la API de Java (LiveConnect), pero la Java Virtual Machine (JVM) fue posteriormente excluida de la cadena. Puede considerarse como la sustitución de Java por el Cross Platform Component Object Model ( XPCOM ). Common Lisp Object System (CLOS) y Smalltalk no son conocidos como eslabones de la cadena como Java en LiveConnect. Objective-C tampoco es muy conocido en este rol ni se sabe que se comercialice de esta manera, pero su entorno de ejecución es uno de los más adecuados para casos de uso similares.

El C++ genérico todavía se utiliza en Qt y en el entorno de escritorio K ( KDE ). Qt y KDE son notables por describir los esfuerzos que se realizan para mantener la compatibilidad binaria sin soporte especial en las herramientas de desarrollo. ^{[ 10 ]}

GObject solo pretendía evitar la dependencia del compilador de C++, pero los problemas de RRBC son los mismos que en C++ genérico.

Sin un entorno de ejecución especial, muchos otros lenguajes de programación tendrán los mismos problemas, por ejemplo, Delphi y Ada . Esto se puede ilustrar con el enfoque sin precedentes que se adoptó para producir una versión de Delphi 2007 compatible binariamente con Delphi 2006: Cómo agregar una propiedad "publicada" sin romper la compatibilidad con DCU. Archivado el 8 de diciembre de 2015 en Wayback Machine.

Objective-C es el competidor más prometedor de SOM (aunque no se comercializa activamente como plataforma multilingüe), y SOM debería compararse preferiblemente con Objective-C en lugar de con COM, como se ha hecho históricamente. Gracias a las variables de instancia robustas de Objective-C 2.0, es la mejor alternativa entre las que cuentan con soporte activo.

COM y XPCOM se utilizan activamente, pero solo gestionan interfaces, no implementaciones, y por lo tanto no están al mismo nivel que SOM, GObject y Objective-C . Windows Runtime, al examinarlo más de cerca, se comporta de forma muy similar a COM. Su descripción de metadatos se basa en .NET, pero dado que WinRT no contiene un entorno de ejecución especial para resolver problemas de RRBC, como en Objective-C o SOM, se tuvieron que aplicar varias restricciones que limitan WinRT a nivel procedimental:

Sistema de tipos (C++/CX)

Una clase de referencia que tenga un constructor público debe declararse como sellada para evitar su posterior derivación.

Componentes de Windows Runtime: Componentes de Windows Runtime en un entorno .NET

Otra restricción es que no se pueden exponer clases o interfaces públicas genéricas. El polimorfismo no está disponible para los tipos WinRT, y lo más parecido que se puede conseguir es implementar interfaces WinRT; se deben declarar como selladas todas las clases que exponga públicamente el componente de Windows Runtime.

SOM se suele comparar con el modelo de objetos de componentes (COM) de Microsoft. Ambos admiten un formato de biblioteca que puede utilizarse desde más de un lenguaje.

Algunos consideran que SOM es más robusto, ya que solo admite un mecanismo de llamada independiente del lenguaje, similar al enlace tardío de COM . COM también admite el enlace temprano , también conocido como interfaz personalizada, que es menos seguro, aunque más eficiente. Permite que un cliente acceda a un objeto mediante una tabla de funciones compatible con C y, por lo tanto, compatible con la disposición binaria de la tabla virtual de objetos C++ (al menos en el compilador C++ de Microsoft). Con un compilador C++ compatible, se puede definir una interfaz personalizada como una clase C++ virtual pura. La interfaz puede ser llamada por cualquier lenguaje que pueda llamar a funciones C mediante un puntero.

Un riesgo de las interfaces personalizadas es que una incompatibilidad puede provocar un comportamiento indefinido . En particular, si se publica una versión del objeto con una interfaz personalizada modificada, el cliente podría fallar. Este es un ejemplo del problema de la clase base frágil . Para evitarlo, una regla para el desarrollo COM es que, una vez publicada, una interfaz personalizada no se puede modificar. Para añadir o cambiar las funcionalidades expuestas de un objeto, este puede implementar interfaces personalizadas adicionales.

SOM evita este problema proporcionando únicamente enlace tardío , lo que permite que el enlazador en tiempo de ejecución reconstruya la tabla sobre la marcha. De esta forma, los cambios en las bibliotecas subyacentes se resuelven cuando se cargan en los programas.

SOM es más robusto en cuanto a la compatibilidad con características de programación orientada a objetos (POO). Mientras que COM define esencialmente una versión reducida de C++ para programar, SOM admite casi todas las características comunes. También admite algunas características menos comunes, como la herencia múltiple , las metaclases y el despacho dinámico , lo que ha llevado a que la mayoría de los sistemas tipo SOM/COM sean más simples a costa de admitir menos lenguajes. La compatibilidad con múltiples lenguajes era importante para IBM, ya que querían admitir tanto Smalltalk ( herencia simple y despacho dinámico ) como C++ ( herencia múltiple y despacho fijo).

Una diferencia notable es la compatibilidad con la herencia. COM no la admite. Aunque pueda parecer extraño que Microsoft haya creado una tecnología de bibliotecas de objetos que no admita un concepto tan fundamental de la programación orientada a objetos, la razón principal es que resulta difícil saber dónde se encuentra una clase base en memoria cuando las bibliotecas se cargan en un orden desconocido en tiempo de diseño. COM exige que el programador especifique la clase base exacta en tiempo de compilación, lo que imposibilita la inserción de otras clases derivadas, al menos en otras bibliotecas COM.

SOM utiliza un algoritmo que busca clases base potenciales siguiendo el árbol de herencia y deteniéndose en la primera que coincide. Esta es la idea detrás de la herencia en la mayoría de los casos. La desventaja de este enfoque es que las nuevas versiones de esta clase base podrían dejar de funcionar, incluso si la API permanece igual. Esta posibilidad existe en cualquier programa, no solo en aquellos que usan una biblioteca compartida, pero un problema puede volverse difícil de resolver si se encuentra en el código de otra persona. En SOM, la única solución es probar las nuevas versiones de las bibliotecas.

Si bien IBM contrapuso SOM y COM, no eran mutuamente excluyentes. En 1995, Novell aportó la tecnología ComponentGlue ^{[ 11 ]} a OpenDoc para Windows. Esta tecnología proporcionaba diferentes maneras de integrar componentes COM y SOM. En particular, los objetos SOM podían estar disponibles para aplicaciones OLE2 mediante un puente de enlace tardío (basado en IDispatch) o interfaces COM de mayor rendimiento. En esencia, las clases SOM implementaban las interfaces COM de esta forma.

Tecnologías similares, como Distributed Objects Everywhere , también admiten la herencia completa. Portable Distributed Objects evitó estos problemas mediante un sólido sistema de control de versiones, que permite a los autores de bibliotecas distribuir nuevas versiones junto con las antiguas, garantizando así la compatibilidad con versiones anteriores a costa de ocupar más espacio en disco.