En informática, el modelo de objetos del sistema ( SOM ) es un sistema de biblioteca compartida orientado a objetos desarrollado por IBM . DSOM , una versión distribuida basada en CORBA , permitía que objetos en diferentes computadoras se comunicaran.
SOM define una interfaz entre programas, o entre bibliotecas y programas, de modo que la interfaz de un objeto está separada de su implementación. SOM permite que se definan clases de objetos en un lenguaje de programación y se utilicen en otro, y permite que las bibliotecas de dichas clases se actualicen sin necesidad de volver a compilar el código del cliente.
Una biblioteca SOM consta de un conjunto de clases, métodos, funciones estáticas y miembros de datos. Los programas que usan una biblioteca SOM pueden crear objetos de los tipos definidos en la biblioteca, usar los métodos definidos para un tipo de objeto y derivar subclases de clases SOM, incluso si el lenguaje del programa que accede a la biblioteca SOM no admite la escritura de clases. No es necesario que una biblioteca SOM y los programas que utilizan objetos y métodos de esa biblioteca estén escritos en el mismo lenguaje de programación. SOM también minimiza el impacto de las revisiones de las bibliotecas. Si se cambia una biblioteca SOM para agregar nuevas clases o métodos, o para cambiar la implementación interna de clases o métodos, aún se puede ejecutar un programa que use esa biblioteca sin volver a compilar. Este no es el caso de todas las demás bibliotecas de C++ , que en algunos casos requieren recompilar todos los programas que las usan cada vez que se cambian las bibliotecas, lo que se conoce como el problema de la interfaz binaria frágil .
SOM proporciona una interfaz de programación de aplicaciones (API) que brinda a los programas acceso a información sobre una clase SOM o un objeto SOM. Cualquier clase SOM hereda un conjunto de métodos virtuales que se pueden usar, por ejemplo, para encontrar el nombre de clase de un objeto o para determinar si un método determinado está disponible para un objeto.
SOM estaba destinado a ser utilizado universalmente desde las computadoras centrales de IBM hasta el escritorio en OS/2 , permitiendo escribir programas que se ejecutarían en el escritorio pero usarían computadoras centrales para el procesamiento y almacenamiento de datos. IBM produjo versiones de SOM/DSOM para OS/2, Microsoft Windows y varios tipos de Unix (en particular, el propio AIX de IBM ). Durante algún tiempo después de la formación de la alianza AIM , Apple Computer también utilizó SOM/DSOM para fines similares. Fue más utilizado en su marco OpenDoc , pero también tuvo un uso limitado en otras funciones.
Quizás los usos más extendidos de SOM dentro de IBM fueron en versiones posteriores de OS/2, que lo utilizaron para la mayor parte del código, incluido Workplace Shell . Object REXX para OS/2 es capaz de manejar clases y objetos SOM, incluido WPS. [1]
IBM no cerró por completo SOObjects. Fueron portados a OS/390 y todavía están disponibles en este sistema operativo. Se puede leer la documentación en el sitio web de IBM. [2] En 1996 Tandem Computers Inc. obtuvo la tecnología SOMobjects. [3] Tandem se vendió a Compaq, Compaq se vendió a Hewlett-Packard. NonStop DOM y algunas otras tecnologías eventualmente se fusionaron en NonStop CORBA, pero la documentación actual de los productos NonStop no contiene signos de que la tecnología SOM todavía impulse los productos NonStop.
Con la "muerte" de OS/2 a mediados de la década de 1990, la razón de ser de SOM/DSOM desapareció en gran medida; Si los usuarios no ejecutaran OS/2 en el escritorio, de todos modos no habría una biblioteca de objetos universal. En 1997, cuando Steve Jobs regresó a Apple y puso fin a muchos esfuerzos de desarrollo, incluidos Copland y OpenDoc , SOM fue reemplazado por Objective-C [4] que ya estaba en uso en OPENSTEP (que luego se convertiría en Mac OS X). El desarrollo de SOM/DSOM se desvaneció y ya no se desarrolla activamente, aunque continúa incluyéndose y utilizándose en sistemas basados en OS/2 como ArcaOS . [5]
A pesar de la muerte efectiva de OS/2 y OpenDoc, SOM podría tener otro nicho más: Windows y el desarrollo multiplataforma . SOM 3.0 para WinNT estuvo disponible de forma generalizada en diciembre de 1996. Las razones para no avanzar en estas direcciones van más allá de los problemas de adopción en el mercado. Implican oportunidades perdidas por IBM , [6] y cambios destructivos e incompatibles:
Existen dos proyectos de implementaciones SOM de código abierto. Uno es el modelo de objetos Netlabs (NOM), que es técnicamente el mismo, pero incompatible binariamente. Otro es somFree, que es un diseño de sala limpia de IBM SOM y compatible con binarios. [ cita necesaria ]
Históricamente, IBM comparó SOM con el modelo de objetos componentes (COM) de Microsoft. Sin embargo, desde algunos puntos de vista, no hay lugar para COM en absoluto. Desde el punto de vista de las transformaciones de versión a versión, COM está en el nivel de procedimiento, por lo tanto, la tabla 1 en el artículo de RRBC ( Compatibilidad binaria de versión a versión a la que se hizo referencia anteriormente) no contiene ninguna columna COM. En cambio, se compara SOM con:
La mayor parte de la información en esta tabla todavía es aplicable a las versiones modernas (a partir de 2015), excepto que Objective-C 2.0 obtiene las llamadas variables de instancia no frágiles. Algunas soluciones siguieron siendo experimentales: SGI Delta/C++ o Sun OBI. La mayoría de los enfoques basados en un lenguaje de programación fueron eliminados o nunca se utilizaron activamente de la misma manera. Por ejemplo, los complementos del navegador Netscape Plugin Application Programming Interface ( NPAPI ) se escribieron utilizando la API de Java inicialmente (LiveConnect), pero luego la máquina virtual Java (JVM) se excluyó de la cadena. Puede verse como Java reemplazado por el modelo de objetos componentes multiplataforma ( XPCOM ). Common Lisp Object System (CLOS) y Smalltalk no son conocidos como eslabones de cadena como Java en LiveConnect. Objective-C tampoco es muy conocido en esta función y no se sabe que se comercialice de esta manera, pero su tiempo de ejecución es uno de los más amigables 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 se destacan por describir los esfuerzos necesarios para mantener la compatibilidad binaria sin soporte especial en las herramientas de desarrollo. [10]
GObject solo tenía como objetivo evitar la dependencia del compilador de C++, pero los problemas de RRBC son los mismos que en C++ genérico.
Sin un tiempo de ejecución especial, muchos otros lenguajes de programación tendrán los mismos problemas, por ejemplo, Delphi , Ada . Puede ilustrarse con el llamado enfoque sin precedentes que se tomó para producir la versión Delphi 2007 compatible con binarios de 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 preferentemente con Objective-C en lugar de COM, como sucedió históricamente. Con variables de instancia no frágiles en Objective-C 2.0, es la mejor alternativa entre las que cuentan con soporte activo.
COM , XPCOM se utilizan activamente, pero solo administran interfaces, no implementaciones y, por lo tanto, no están al mismo nivel que SOM, GObject y Objective-C . Windows Runtime, visto más de cerca, se comporta de forma muy parecida a COM. Su descripción de metadatos se basa en .NET, pero como WinRT no contiene un tiempo 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 de procedimiento:
Tipo de sistema (C++/CX)
Componentes de Windows Runtime - Componentes de Windows Runtime en un mundo .NET
SOM es similar en concepto a COM. Ambos sistemas abordan el problema de producir un formato de biblioteca estándar al que se pueda llamar desde más de un idioma. SOM puede considerarse más robusto que COM. COM ofrece dos métodos para acceder a métodos de un objeto, y un objeto puede implementar uno de ellos o ambos. El primero es dinámico y de enlace tardío ( IDispatch ) y es neutral en cuanto al idioma, similar a lo que ofrece SOM. El segundo, llamado Interfaz personalizada, utiliza una tabla de funciones que se puede construir en C pero que también es directamente compatible con el diseño binario de la tabla virtual de objetos C++ en el compilador C++ de Microsoft. Por lo tanto, con compiladores de C++ compatibles, las interfaces personalizadas se pueden definir directamente como clases virtuales puras de C++. Luego, la interfaz resultante puede ser llamada por lenguajes que pueden llamar a funciones C mediante punteros. Las interfaces personalizadas intercambian solidez por rendimiento. Una vez que se publica una interfaz en un producto lanzado, no se puede cambiar, porque las aplicaciones cliente de esta interfaz se compilaron con un diseño binario específico de esta interfaz. Este es un ejemplo del problema de la clase base frágil , que puede llevar al infierno de DLL , ya que se instala una nueva versión de una biblioteca compartida y todos los programas basados en la versión anterior pueden dejar de funcionar correctamente. Para evitar este problema, los desarrolladores COM deben recordar no cambiar nunca una interfaz una vez publicada y es necesario definir nuevas interfaces si se requieren nuevos métodos u otros cambios.
SOM evita estos problemas al proporcionar solo enlace tardío, para permitir que el vinculador en tiempo de ejecución reconstruya la tabla sobre la marcha. De esta manera, los cambios en las bibliotecas subyacentes se resuelven cuando se cargan en los programas, aunque hay un costo de rendimiento.
SOM también es mucho más sólido en términos de soporte total para una amplia variedad de lenguajes OO. Mientras que COM básico esencialmente define una versión reducida de C++ para programar, SOM admite casi todas las características comunes e incluso algunas más esotéricas. Por ejemplo, SOM admite herencia múltiple , metaclases y distribución dinámica . Algunas de estas características no se encuentran en la mayoría de los idiomas, lo que ha llevado a que la mayoría de los sistemas tipo SOM/COM sean más simples a costa de admitir menos idiomas. Sin embargo, la flexibilidad total del soporte multilenguaje era importante para IBM, ya que tenían un gran esfuerzo en marcha para soportar tanto Smalltalk ( herencia única y distribución dinámica ) como C++ ( herencia múltiple y distribución fija).
La diferencia más notable entre SOM y COM es la compatibilidad con la herencia; COM no tiene ninguna. Puede parecer extraño que Microsoft haya producido un sistema de biblioteca de objetos que no pudiera soportar uno de los conceptos más fundamentales de la programación orientada a objetos; La razón principal de esto es que es difícil saber dónde existe una clase base en un sistema donde las bibliotecas se cargan en un orden potencialmente aleatorio. COM exige que el programador especifique la clase base exacta en el momento de la compilación, lo que hace imposible insertar otras clases derivadas en el medio (al menos en otras bibliotecas COM).
En cambio, SOM utiliza un algoritmo simple, que busca posibles clases base siguiendo el árbol de herencia y deteniéndose en la primera que coincida; ésta es la idea básica detrás de la herencia en la mayoría de los casos. La desventaja de este enfoque es que es posible que las nuevas versiones de esta clase base ya no funcionen incluso si la API sigue siendo la misma. Esta posibilidad existe en cualquier programa, no sólo en aquellos que usan una biblioteca compartida, pero un problema puede resultar muy difícil de localizar si existe en el código de otra persona. En SOM, la única solución es realizar pruebas exhaustivas de nuevas versiones de bibliotecas, lo que no siempre es fácil.
Si bien IBM contrapuso SOM y COM, no eran mutuamente excluyentes. En 1995, Novell contribuyó con la tecnología ComponentGlue [11] a OpenDoc para Windows. Esta tecnología proporcionó diferentes medios para integrar componentes basados en COM y SOM. En particular, los objetos SOM pueden estar disponibles para aplicaciones OLE2 mediante un puente de enlace tardío (basado en IDispatch) o interfaces COM que tienen un mayor rendimiento. En esencia, las clases SOM implementan interfaces COM de esta manera.
Casi todos [ cita requerida ] consideraron que la flexibilidad ofrecida por SOM valía la pena , pero sistemas similares, como Distributed Objects Everywhere de Sun Microsystems , también admitían herencia completa. Los objetos distribuidos portátiles de NeXT evitaron estos problemas a través de un sólido sistema de control de versiones, lo que permitió a los autores de bibliotecas enviar nuevas versiones junto con las antiguas, garantizando así la compatibilidad con versiones anteriores por el pequeño costo de espacio en disco.