El modelo de objetos del sistema ( SOM ) es una tecnología de biblioteca compartida orientada a objetos desarrollada por IBM que admite la definición de una interfaz para un objeto de modo que su interfaz esté separada de su implementación .
DSOM , una variante distribuida basada en CORBA , permitía que objetos en diferentes computadoras se comunicaran.
Una biblioteca SOM se puede actualizar sin necesidad de reconstruir el código del cliente. Si se modifica una biblioteca para agregar nuevas clases o métodos, o para cambiar la implementación interna de clases o métodos, un programa que la consume puede seguir utilizándola sin tener que reconstruirla. De esta manera, 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 utilizar objetos de las clases expuestas y derivar subclases de las clases expuestas incluso si el lenguaje del cliente no admite la tipificación de clases.
SOM proporciona una interfaz de programación de aplicaciones (API) que brinda acceso a metadatos de bibliotecas . 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 fue pensado para ser usado universalmente en los mainframes y computadoras de escritorio ( OS/2 ) de IBM, permitiendo que los programas diseñados para el escritorio usen un mainframe para procesar y almacenar datos. IBM produjo versiones de SOM/DSOM para OS/2, Microsoft Windows y varias versiones de Unix (notablemente el propio AIX de IBM ). Durante algún tiempo después de la formación de la alianza AIM , SOM/DSOM también fue usado por Apple Computer para propósitos similares. Fue más ampliamente usado 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 utilizaban para la mayor parte del código, incluido Workplace Shell . Object REXX para OS/2 puede manejar clases y objetos SOM, incluido WPS. [1]
IBM no eliminó por completo los SOMobjects, sino que los trasladó a OS/390 y aún están disponibles en este sistema operativo. Puede leer la documentación en el sitio web de IBM. [2] En 1996, Tandem Computers Inc. adquirió la tecnología SOMobjects. [3] Tandem se vendió a Compaq y Compaq se vendió a Hewlett-Packard. NonStop DOM y algunas otras tecnologías acabaron fusionándose en NonStop CORBA, pero la documentación actual de los productos NonStop no contiene indicios de que la tecnología SOM siga funcionando en los productos NonStop.
Con la "muerte" de OS/2 a mediados de los años 1990, la razón de ser de SOM/DSOM desapareció en gran medida; si los usuarios no estuvieran ejecutando OS/2 en el escritorio, no habría una biblioteca de objetos universal de todos modos. En 1997, cuando Steve Jobs regresó a Apple y terminó muchos esfuerzos de desarrollo, incluidos Copland y OpenDoc , SOM fue reemplazado por Objective-C que ya se usaba 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 . [4]
A pesar de la muerte efectiva de OS/2 y OpenDoc, SOM podría tener otro nicho: Windows y el desarrollo multiplataforma . SOM 3.0 para WinNT estuvo disponible para el público en general 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 [5] y cambios incompatibles destructivos:
Existen dos proyectos de implementación de SOM de código abierto. Uno es Netlabs Object Model (NOM), que técnicamente es el mismo, pero es incompatible a nivel binario. Otro es somFree, que es un diseño de sala limpia de IBM SOM y es compatible a nivel binario. [ cita requerida ]
SOM se puede comparar con bibliotecas compiladas: [9]
A partir de 2015, la mayor parte de la información en la tabla vinculada es aplicable a las versiones modernas, excepto Objective-C 2.0 que 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 se eliminaron gradualmente o nunca se usaron activamente de la misma manera. Por ejemplo, los complementos del navegador Netscape Plugin Application Programming Interface ( NPAPI ) se escribieron utilizando Java API inicialmente (LiveConnect), pero Java Virtual Machine (JVM) se excluyó más tarde de la cadena. Puede verse como Java reemplazado por 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 y no se sabe que se comercialice de esta manera, pero su entorno 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 son conocidos por describir los esfuerzos que se realizan para mantener la compatibilidad binaria sin un 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 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 la compatibilidad binaria de Delphi 2006 Lanzamiento de Delphi 2007: 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 promociona activamente como plataforma multilingüe) y, de preferencia, se debería comparar a SOM con Objective-C en lugar de con 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 y XPCOM se utilizan activamente, pero sólo gestionan interfaces, no implementaciones, y por lo tanto no están al mismo nivel que SOM, GObject y Objective-C . Windows Runtime , si se analiza más de cerca, se comporta de forma muy similar a COM. Su descripción de metadatos se basa en .NET, pero como 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 de procedimiento:
Sistema de tipos (C++/CX)
Componentes de Windows Runtime: componentes de Windows Runtime en un mundo .NET
SOM suele compararse con el modelo de objetos de componentes (COM). 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 que es similar al enlace tardío de COM . COM también admite el enlace temprano , también conocido como interfaz personalizada, que es menos seguro pero de mayor rendimiento. Permite que un cliente acceda a un objeto a través de una tabla de funciones que es compatible con C y, por lo tanto, compatible con el diseño binario de la tabla virtual de objetos de 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 a través de un puntero.
Un riesgo de una interfaz personalizada es que una incompatibilidad puede dar como resultado un comportamiento indefinido . En particular, si se publica una versión del objeto con una interfaz personalizada modificada, un cliente puede bloquearse. Este es un ejemplo del problema de la clase base frágil . Para evitar el problema, una regla para el desarrollo COM es que una vez publicada, una interfaz personalizada no se puede cambiar. Para agregar o cambiar las características expuestas de un objeto, se pueden implementar interfaces personalizadas adicionales.
SOM evita este problema proporcionando únicamente un enlace tardío, lo que permite que el enlazador 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.
SOM es más robusto en términos de compatibilidad con funciones orientadas a objetos (OO). Mientras que COM define esencialmente una versión reducida de C++ para programar, SOM admite casi todas las funciones comunes. También admite algunas funciones menos comunes, como herencia múltiple , metaclases y distribución dinámica , que habían llevado a que la mayoría de los sistemas similares a SOM/COM fueran más simples a costa de admitir menos idiomas. La compatibilidad con varios idiomas era importante para IBM, ya que querían admitir tanto Smalltalk ( herencia simple y distribución dinámica ) como C++ ( herencia múltiple y distribución fija).
Una diferencia notable es el soporte para herencia, algo que COM no hace. Aunque puede parecer extraño que Microsoft haya producido una tecnología de biblioteca de objetos que no pudiera soportar un concepto tan fundamental de programación orientada a objetos, la razón principal es que es difícil saber dónde existe una clase base en la 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 hace imposible insertar otras clases derivadas en el medio, al menos en otras bibliotecas COM.
En cambio, SOM utiliza un algoritmo que busca posibles clases base siguiendo el árbol de herencia y deteniéndose en la primera que coincida. Esta es la idea 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 solo en aquellos que utilizan una biblioteca compartida, pero un problema puede volverse difícil de resolver si existe en el código de otra persona. En SOM, la única solución es probar nuevas versiones de bibliotecas.
Aunque 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 la integración entre componentes COM y SOM. En particular, los objetos SOM pueden ponerse a disposición de las aplicaciones OLE2 mediante un puente de enlace tardío (basado en IDispatch) o interfaces COM que tengan un mayor rendimiento. En esencia, las clases SOM implementan interfaces COM de esta manera.
Tecnologías similares, como Distributed Objects Everywhere , también admiten la herencia completa. Portable Distributed Objects evitó estos problemas mediante un sistema de control de versiones sólido, que permite a los autores de bibliotecas enviar nuevas versiones junto con las antiguas, garantizando así la compatibilidad con versiones anteriores a costa del espacio en disco.