Modelo de objetos del sistema de IBM - IBM System Object Model

No debe confundirse con el modelo de objetos del sistema (formato de archivo) .
IBM SOMobjects
Logotipo de IBM SOM
Desarrollador (es) IBM
Lanzamiento estable
3.0 / diciembre de 1996
Sistema operativo OS / 2 , Windows , AIX , Mac OS clásico , Copland , OS / 390 , NonStop OS
Escribe sistema de biblioteca compartida orientado a objetos

En informática, System Object Model ( SOM ) es un sistema de biblioteca compartida orientado a objetos desarrollado por IBM . DSOM , una versión distribuida basada en CORBA , permitía que los 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 las clases de objetos se definan 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. Una biblioteca SOM y los programas que utilizan objetos y métodos de esa biblioteca no necesitan estar escritos en el mismo lenguaje de programación. SOM también minimiza el impacto de las revisiones en 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 volver a compilar 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 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 dado está disponible para un objeto.

Aplicaciones

SOM estaba destinado a ser utilizado universalmente desde las computadoras mainframe de IBM hasta el escritorio en OS / 2 , permitiendo que se escribieran programas que se ejecutarían en el escritorio pero que usarían mainframes para el procesamiento y almacenamiento de datos. IBM produjo versiones de SOM / DSOM para OS / 2, Microsoft Windows y varios sabores 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 otros roles.

Quizás los usos más extendidos de SOM dentro de IBM se encontraban en versiones posteriores de OS / 2, que lo usaban para la mayor parte del código, incluido Workplace Shell . Object REXX para OS / 2 puede trabajar con clases y objetos SOM, incluido WPS.

IBM no cerró completamente SOMobjects. Fueron trasladados 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. En 1996 Tandem Computers Inc. obtuvo la tecnología SOMobjects. Tandem se vendió a Compaq, Compaq se vendió a Hewlett-Packard. NonStop DOM y algunas otras tecnologías finalmente se fusionaron en NonStop CORBA, pero la documentación actual de los productos NonStop no contiene indicios de que la tecnología SOM siga impulsando los productos NonStop.

Desvaneciendo

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 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 puso fin a muchos esfuerzos de desarrollo, incluidos Copland y OpenDoc , SOM fue reemplazado por Objective-C que ya estaba en uso en OPENSTEP (para convertirse en Mac OS X más tarde). El desarrollo de SOM / DSOM se desvaneció y ya no se desarrolla activamente, aunque continúa incluyéndose y usándose en sistemas basados ​​en OS / 2 como ArcaOS .

A pesar de la muerte efectiva de OS / 2 y OpenDoc, SOM podría tener otro nicho: Windows y 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 del mercado. Implican oportunidades perdidas por IBM y cambios incompatibles destructivos:

  • La primera versión de VisualAge C ++ para Windows fue 3.5. Fue la primera y la última versión compatible con SOM. Tenía SOM 2.1 incluido y soporte Direct-to-SOM en el compilador. Las versiones 3.6.5 y posteriores no tenían rastro de SOM.
  • SOMobjects se basaba en gran medida en archivos MAKE . VisualAge C ++ 4.0 introdujo proyectos .icc y eliminó el compilador y enlazador de línea de comandos icc.exe e ilink.exe del suministro. Es imposible crear una muestra de SOM DTK de fábrica con VAC ++ 4.0. VisualAge C ++ viene con sus propios ejemplos, pero no hay ejemplos de .icc SOM incluso 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) integrada de VisualAge C ++ no se basó en SOM. Probablemente estaba destinado a ser portado a SOM usando el modo C ++ Direct-to-SOM, pero en VAC v3.6.5 este modo fue abandonado y OCL no tiene interfaz SOM hasta ahora.
  • Hacia fines de la década de 1990, IBM cerró los sitios de descarga de SOMobjects y nunca los volvió a poner en línea. SOM 3.0 DTK para WinNT no se puede encontrar en IBM FTP, a pesar de muchas otras cosas heredadas que se encuentran libremente. A pesar de la disponibilidad general de SOM 3.0 para WinNT, fue casi imposible de localizar hasta finales de 2012.
  • Finalmente, IBM nunca abrió SOM (como se hizo con Object REXX ), a pesar de varios artículos y peticiones.

Implementaciones alternativas

Existen dos proyectos de implementaciones de SOM de código abierto. Uno es el modelo de objetos de Netlabs (NOM), que es técnicamente el mismo, pero binario incompatible. Otro es somFree, que es un diseño de sala limpia de IBM SOM y compatible con binarios.

Comparación de soporte para bibliotecas de clases compiladas

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. 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 mencionada anteriormente) no contiene ninguna columna COM. En cambio, SOM se compara con:

La mayor parte de la información de esta tabla sigue siendo 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 se eliminaron gradualmente o nunca se usaron activamente de la misma manera. Por ejemplo, los complementos de navegador de la Interfaz de programación de aplicaciones de complementos de Netscape ( NPAPI ) se escribieron inicialmente utilizando la API de Java (LiveConnect), pero luego se excluyó de la cadena Java Virtual Machine (JVM). Puede verse como Java reemplazado por el Modelo de objetos componentes multiplataforma ( XPCOM ). Common Lisp Object System (CLOS) y Smalltalk no se conocen como enlaces de cadena como Java en LiveConnect. Objective-C tampoco se conoce mucho en este rol 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 usa 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 un soporte especial en las herramientas de desarrollo.

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 . Se puede ilustrar con el llamado enfoque sin precedentes que se tomó para producir la versión Delphi 2007 compatible con el binario de Delphi 2006: Cómo agregar una propiedad "publicada" sin romper la compatibilidad con DCU

Objective-C es el competidor más prometedor de SOM (aunque no se comercializa activamente como una plataforma multilingüe), y SOM debería compararse preferiblemente con Objective-C en lugar de COM, como ha sucedido 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 bajo una mirada más cercana se comporta de manera muy similar a COM. Su descripción de metadatos se basa en .NET, pero dado que 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:

Sistema de tipos (C ++ / CX)

Una clase de referencia que tiene un constructor público debe declararse como sellada para evitar derivaciones posteriores.

Componentes de Windows Runtime: componentes de Windows Runtime en un mundo .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 de WinRT, y lo más cerca que puede llegar es la implementación de interfaces WinRT; debe declarar como selladas todas las clases expuestas públicamente por su componente de tiempo de ejecución de Windows.

Comparación con COM

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 en 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 un lenguaje neutro similar al que ofrece SOM. La segunda, denominada 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. Con compiladores de C ++ compatibles, las interfaces personalizadas se pueden definir directamente como clases de C ++ virtuales puras. Luego, la interfaz resultante puede ser llamada por lenguajes que pueden llamar a funciones C a través de punteros. Las interfaces personalizadas intercambian robustez 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 frágil problema de la clase base , que puede llevar al infierno de las 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 de COM deben recordar no cambiar nunca una interfaz una vez que se haya publicado, y es necesario definir nuevas interfaces si se requieren nuevos métodos u otros cambios.

SOM evita estos problemas proporcionando solo enlace tardío, para permitir 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 programas, aunque existe un costo de rendimiento.

SOM también es mucho más robusto en términos de compatibilidad total con una amplia variedad de idiomas 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 despacho dinámico . Algunas de estas características no se encuentran en la mayoría de los lenguajes, lo que ha llevado a la mayoría de los sistemas similares a SOM / COM a ser más simples a costa de admitir menos idiomas. Sin embargo, la flexibilidad total del soporte en varios idiomas era importante para IBM, ya que tenían un gran esfuerzo en marcha para admitir tanto Smalltalk ( herencia única y envío dinámico ) con C ++ ( herencia múltiple y envío fijo ).

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 pueda soportar uno de los conceptos más fundamentales de la programación OO; 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 tiempo de compilación, lo que hace imposible insertar otras clases derivadas en el medio (al menos en otras bibliotecas COM).

En cambio, SOM usa un algoritmo simple, buscando posibles clases base siguiendo el árbol de herencia y deteniéndose en la primera que coincide; esta 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 solo en aquellos que usan una biblioteca compartida, pero un problema puede volverse muy difícil de rastrear 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 se excluyen mutuamente. En 1995, Novell contribuyó con la tecnología ComponentGlue a OpenDoc para Windows. Esta tecnología proporcionó diferentes medios para la integración entre componentes basados ​​en COM y SOM. En particular, los objetos SOM se pueden poner a disposición de las aplicaciones OLE2 mediante un puente de enlace tardío (basado en IDispatch) o interfaces COM que tienen un rendimiento superior. En esencia, las clases SOM están implementando interfaces COM de esta manera.

La flexibilidad ofrecida por SOM se consideró vale la pena por casi todos, pero los sistemas similares, tales como Sun Microsystems ' objetos distribuidos en todas partes , también apoyó herencia completa. NeXT 's portátiles objetos distribuidos evitan estos problemas a través de un sistema de control de versiones fuertes, permitiendo a los autores de la biblioteca para enviar nuevas versiones junto con la edad, lo que garantiza la compatibilidad hacia atrás para el pequeño coste de espacio en disco.

Ver también

Referencias

  1. ^ SOM y Object REXX por el Dr. Willis Boughton (agosto de 2004)
  2. ^ SOMobjects para la documentación de OS / 390
  3. ^ Tandem aprovecha la tecnología SOMobjects de IBM para la computación de objetos distribuidos
  4. ^ Ira R. Forman y Scott Danforth (1999). Poniendo a trabajar las metaclases . ISBN 0-201-43305-2.
    Capítulo 11 "Compatibilidad binaria de versión a versión", página 246
    Se puede encontrar un artículo con el mismo nombre y contenido similar del mismo autor en la Web: Compatibilidad binaria de versión a versión
  5. ^ "Lista de clases de ArcaOS 5.0 WPS" . Consultado el 3 de septiembre de 2020 .
  6. ^ Perdido en el jardín por Roger Sessions (agosto de 1996)
  7. ^ Solo una pequeña cosa de SOM para desarrolladores de Linux por Esther Schindler (febrero de 2008)
  8. ^ Reviviendo lo mejor de OS / 2 en el escritorio de Linux Archivado el 17 de abril de 2010en Wayback Machine por Steven J. Vaughan-Nichols (febrero de 2008)
  9. ^ La petición OS / 2 , segunda ronda (2007-2010)
  10. ^ Problemas de compatibilidad binaria con C ++
  11. ^ ComponentGlue (tm) proporciona interoperabilidad total con controles OLE, OCX

enlaces externos