| Modelo de objetos del sistema (SOMObjects) | |
|---|---|
| Desarrollador | CILabs ( IBM , Apple Computer , etc.) |
| Sistema operativo | Mac OS , OS /2 , AIX , Windows , DOS |
| ultima versión | 3.0 (diciembre de 1996 ) |
System Object Model ( SOM ) es un sistema de bibliotecas dinámicas orientadas a objetos desarrollado por CILabs ( IBM , Apple , OMG, Adobe , Oracle, etc.). DSOM, una versión distribuida de SOM basada en CORBA que permite que los objetos se distribuyan en diferentes sistemas informáticos. Hay implementaciones para los sistemas operativos Windows NT, MacOS Classic, OS/2, AIX, DOS, Copland, OS/390, NonStop OS. Para Windows NT, MacOS y OS/2, existe una implementación del desarrollo de componentes OpenDoc basado en SOM/DSOM. El sistema fue desarrollado a mediados de la década de 1990, fue abandonado en 1998 [1] .
El SOM de IBM es conceptualmente similar al modelo de objetos componentes de Microsoft . Ambos sistemas resuelven el problema de crear un formato de biblioteca estándar que se pueda llamar desde más de un idioma. SOM se considera más funcional que COM. COM proporciona dos formas de llamar a métodos en un objeto, y un objeto puede implementar uno o ambos. El primero es la invocación dinámica y el enlace tardío (IDispatch) y, al igual que SOM, es independiente del idioma. La segunda forma, a través de una interfaz privada, usa una tabla de funciones que se puede construir en C, o usa una tabla de método virtual compatible de nivel inferior de un objeto C++. Usando compiladores de C++ compatibles, puede declarar interfaces privadas como clases de C++ virtuales puras. Las interfaces privadas son un compromiso entre la funcionalidad y el rendimiento. Una vez que se ha publicado una interfaz en un producto lanzado, no se puede modificar porque las aplicaciones de usuario de la interfaz se han compilado para un dispositivo de tabla específico en un nivel bajo. Este es un ejemplo de un problema de clase base frágil que puede resultar en un infierno de DLL , donde después de instalar una nueva versión de una biblioteca compartida, todos los programas que usan la versión anterior dejan de funcionar correctamente. Para evitar este problema, los desarrolladores de COM siempre deben tener en cuenta que las interfaces que ya se han publicado no deben cambiarse. Si desea agregar nuevos métodos o realizar otros cambios, debe definir nuevas interfaces. SOM evita estos problemas al proporcionar solo enlaces en tiempo de ejecución y permitir que el vinculador en tiempo de ejecución reconstruya las tablas sobre la marcha. Por lo tanto, los cambios en las bibliotecas subyacentes se vuelven a calcular cuando se cargan en los programas, a costa de un pequeño impacto en el rendimiento.
Sin embargo, la interfaz no se puede cambiar no solo por razones técnicas, sino también desde el punto de vista de la programación orientada a objetos. Una interfaz, a diferencia de una clase, no tiene una implementación predeterminada y cualquiera puede implementarla, incluido un desarrollador externo. En consecuencia, si se realizan cambios en la interfaz, las clases de terceros no pueden admitir automáticamente la nueva interfaz. Por lo tanto, puede usar solo clases en lugar de interfaces, proporcionando una implementación predeterminada siempre actualizada, o puede evitar que los desarrolladores de terceros implementen una interfaz potencialmente extensible, en cuyo caso la palabra "interfaz" pierde su significado en Términos de programación orientada a objetos.
SOM también es más funcional en términos de soporte completo para varios lenguajes OO. Si bien el desarrollo de COM se limita al uso de una versión simplificada de C++, SOM admite casi todas las funciones habituales e incluso algunas más esotéricas. Por ejemplo, SOM admite herencia múltiple, metaclases y llamadas dinámicas. Algunas de estas funciones no están disponibles en la mayoría de los idiomas, por lo que muchos sistemas similares a SOM/COM son más fáciles de implementar a expensas de admitir un conjunto más pequeño de idiomas. La total flexibilidad del soporte multilingüe era importante para IBM debido a la necesidad de soportar tanto Smalltalk (herencia única, enlace dinámico) como C++ (herencia múltiple y enlace estático). La necesidad de soportar la herencia múltiple es, entre otras cosas, una consecuencia del hecho de que en lugar de interfaces solo hay clases. Cabe señalar que el soporte de C++ para herencia múltiple difiere de CLOS, Dylan, SOM y Python, y los problemas de herencia múltiple de C++ no son específicos de SOM.
La diferencia más notable entre SOM y COM es el soporte para la herencia, que COM no tiene en absoluto. Puede parecer extraño que Microsoft haya producido un sistema de biblioteca de objetos que no es compatible con el principio más fundamental de OOP. El principal obstáculo para esto es la dificultad de determinar dónde se encuentra la clase base en el sistema mientras las bibliotecas se cargan en un orden potencialmente arbitrario. COM requiere que el desarrollador especifique la clase base exactamente en el momento de la compilación, lo que hace imposible insertar otras clases heredadas en el medio (al menos en bibliotecas COM extranjeras).
Por el contrario, SOM utiliza un algoritmo simple, atravesando el árbol de herencia en busca de una clase base potencial y decidiéndose por la primera adecuada. En la mayoría de los casos, este es el principio básico de la herencia. La desventaja de este enfoque es la posibilidad de que las nuevas versiones de la clase base no funcionen a pesar de la API sin cambios. Esta posibilidad existe en cualquier programa, no solo en aquellos que usan bibliotecas compartidas, pero el problema se vuelve muy difícil de rastrear si existe en el código de otra persona. En SOM, la única solución es probar completamente las nuevas versiones de las bibliotecas, lo que no siempre es fácil.
La comparación con otros enfoques se realizó en el informe "Compatibilidad binaria de versión a versión y corrección de la compilación separada" [2] , en particular, Smalltalk, CLOS, Generic C++, SOM, SGI Delta/C++, OBI, Objective-C , JAVA. De los sistemas modernos, es el más cercano a SOM en términos de compatibilidad con Objective-C de bajo nivel, especialmente después de la implementación de ivars no frágiles.
Los emisores para C y C++ se incluyen en el propio SOMobjects Developer Toolkit y le permiten llamar a métodos de objetos y heredar de clases. Algunos compiladores de C++, primero MetaWare High C++, luego IBM VisualAge C++, implementaron la capacidad Direct-to-SOM. VisualAge C++ para Windows introdujo esta función en la versión 3.5 [3] , que también fue la última versión compatible con esta función.
ObjectREXX, enviado con OS/2, está integrado con SOM, lo que le permite llamar a métodos en objetos y heredar de clases. Cuando las fuentes de ObjectREXX se lanzaron a la comunidad de código abierto, no se transfirieron todos los archivos necesarios para que esta integración funcionara, y esta característica no se incluyó en la versión de código abierto. Durante algún tiempo hubo rastros de integración con SOM en el repositorio, pero fue imposible compilarlo y, posteriormente, todo lo relacionado con SOM se eliminó por completo.
El paquete VisualAge SmallTalk SOMSupport le permite llamar a métodos SOM en objetos y crear contenedores SOM para clases SmallTalk .
IBM ObjectCOBOL originalmente usó SOM como un sistema de objetos en modo Directo a SOM. Posteriormente, ObjectCOBOL fue portado a Java y comenzó a utilizar el sistema de objetos de Java en lugar de SOM.
Algunas versiones de VisualAge for Basic tenían integración SOM [4] . Además, Lotus Script, incluido en la distribución de OpenDoc, también puede trabajar con objetos SOM a través de OpenDoc Direct Scripting (ODDS) [5] .
En SOMObjects Java Client [6] era posible llamar objetos SOM solo de forma remota, a través de DSOM. El ejemplo de demostración tenía clases que estaban disponibles en el servidor DSOM, y luego el applet de Java se alojó en un recurso de Internet, creó objetos remotos y llamó a sus métodos. No se proporcionan llamadas a métodos locales.
Los emisores para Virtual Pascal fueron desarrollados por un individuo privado, luego adaptados a Free Pascal [7] (solo OS/2). Le permiten llamar a métodos y crear sus propias clases.
SOMIRIMP.exe [8] (solo Windows), un importador de la base de datos binaria SOM.IR en los enlaces de Delphi, fue desarrollado de forma independiente por otra persona. Le permite llamar a métodos, pero no crear clases. A diferencia del emisor anterior implementado en C, SOMIRIMP está escrito en Delphi y utiliza enlaces autogenerados.
Los desarrolladores del compilador PowerAda crearon emisores [9] y ejemplos del uso de SOM. PowerAda solo estaba disponible en AIX y el emisor requiere SOM 3.0 Beta, también para AIX, para ejecutarse. Se ha perdido SOM 3.0 para AIX.
Canterbury Modula-2 para OS / 2 tenía extensiones orientadas a objetos similares a Oberon-2 y admitía el modo de compilación Direct-to-SOM en la versión profesional. [diez]
Oberon Microsystems ha anunciado la compatibilidad con Direct-to-SOM en Mac OS Classic, pero se desconoce el estado de este proyecto. [once]
Por lo general, el desarrollo de SOM procede de la siguiente manera:
En modo consumidor:
el desarrollador ejecuta el compilador SOM con un emisor para el lenguaje de programación deseado, especificando a qué archivos IDL de la biblioteca deseada enlazar. Por ejemplo:
sc -sada somcm.idl
El emisor crea uno o más archivos en el formato que entiende el compilador del lenguaje de programación seleccionado. Con la ayuda de estos archivos, es posible crear objetos de las clases descritas y llamar a sus métodos.
En modo productor:
el desarrollador escribe sus propios archivos .idl, que #incluyen otros archivos .idl y heredan de las clases descritas en otros archivos .idl. Luego, el desarrollador ejecuta un emisor especial que creará archivos con código auxiliar y archivos con implementaciones vacías de métodos de clase.
Por ejemplo:
sc -sih animals.idl
sc -sc animals.idl
la primera llamada creará animals.ih, que contendrá, por ejemplo, una implementación de Animals_AnimalNewClass que ejecutará somBuildClass2, pasándole una estructura compleja sintetizada a partir de la entrada .idl. Además de esta llamada, este archivo contiene esta estructura en sí y algunos otros elementos auxiliares que el desarrollador no debería cambiar en absoluto. La segunda llamada creará animals.c con implementaciones de métodos vacíos. El emisor C y C++ de IBM puede funcionar de manera incremental, agregando nuevos métodos vacíos sin tocar el código de los métodos existentes.
Además, hay emisores para crear .dll. El emisor IMOD sintetiza la función principal .dll, el emisor DEF sintetiza archivos .def y .nid.
El emisor es una biblioteca llamada emit*.dll, donde * es una opción para el argumento -s del compilador SOM. La biblioteca debe exportar un procedimiento emit (SOM 2.1) o emitSL (SOM 3.0) que, cuando se llama desde el compilador SOM, realiza un trabajo específico para el emisor seleccionado. El trabajo puede ser cualquiera. Para crear nuevos emisores, hay un script newemit.
Los emisores incluyen un emisor de infrarrojos que crea o actualiza la base de datos binaria SOM.IR. Esta base de datos se puede abrir luego usando el marco de repositorio de interfaz. Esto se usa más comúnmente para llamadas a procedimientos remotos y lenguajes de programación dinámicos. Así es como funcionan VisualAge SOMSupport para Smalltalk y ObjectREXX.
Además, el estándar OpenDoc incluye OpenDoc Direct Scripting (ODDS) y los intérpretes de lenguaje de scripting que implementan la interfaz ODScriptComponent pueden acceder a las clases SOM a través de ODDS. Un ejemplo de dicho lenguaje de programación es Lotus Script, suministrado con OpenDoc [5] .
La base de datos SOM.IR también se puede utilizar para crear enlaces para lenguajes de programación compilados [12] .
Novell ha desarrollado un puente que hace que los objetos SOM estén disponibles desde lenguajes compatibles con la automatización OLE. Además, Novell ComponentGlue permite que las aplicaciones que utilizan una de las tecnologías OLE u OpenDoc utilicen componentes creados con otra tecnología, así como envolver la parte OpenDoc como un componente OLE (OCX). Esto utiliza la utilidad ctypelib . Al usar esta utilidad, no se genera ningún código de programa durante la compilación. La misma DLL de OpenDoc está registrada en el registro, que puede cargar la biblioteca SOM en la memoria y crear tablas de métodos virtuales, trampolines y otros elementos necesarios para los objetos COM proxy en tiempo de ejecución. Por lo general, ComponentGlue solo implementa la interfaz IDispatch, pero para acelerar las cosas, es posible declarar e implementar su propia interfaz COM marcando la interfaz SOM con el modificador ODdual y cumpliendo con todas las reglas para las interfaces OLE.
Otra herramienta para integrar SOM y COM es la utilidad emitcom , que crea contenedores COM para clases SOM en C++. emitcom se incluyó en SOM 3.0 Beta (febrero de 1996), pero no se incluyó en SOM 3.0 Release (diciembre de 1996), como muchas otras características.
Sin embargo, debe tenerse en cuenta que, dado que COM no hace nada para resolver el problema de la clase base frágil, debe tener cuidado con tales puentes. Los envoltorios COM producidos por emitcom corresponden al nugget de interfaz de la clase en el momento de la creación, y cuando la interfaz cambia, se deben crear nuevas versiones de los envoltorios con nuevos GUID de interfaz COM que aún admitan las interfaces COM de las versiones antiguas del envoltorio. . Las interfaces COM generadas por la utilidad ctypelib para las clases SOM marcadas con el modificador ODdual no deben usarse desde lenguajes de programación compilados, porque la representación de bajo nivel de dicha interfaz no es estable. ctypelib generalmente sobrescribe la biblioteca de tipos COM, y no existe ninguna disposición para mantener varias versiones diferentes de una interfaz en paralelo.
Cuando se usan emisores en lenguajes de programación compilados como C++, el emisor de C++ da la apariencia de que la clase SOM es una clase de C++. somInit se asigna al constructor estándar y somAssign se asigna a operator=. Sin embargo, al implementar sus clases, escribir .idl juega un papel importante y la implementación de métodos no se parece a la implementación de métodos de clase. Debe llamar constantemente al compilador SOM para actualizar los archivos. SOM resulta ser algo ajeno a los lenguajes de programación cuyos compiladores no tienen soporte incorporado para SOM.
El compilador Direct-to-SOM C++ elimina la necesidad de escribir archivos .idl. Los archivos .idl se generan en función de los archivos de encabezado DTS de C++, no al revés. Por lo tanto, el compilador DTS C++ proporciona un entorno de desarrollo completo y homogéneo que le permite escribir todo en un solo idioma. Trabajar con som.dll en DTS C++ es similar a trabajar con objc.dll en Objective-C.
Todavía se necesitan emisores, pero solo para importar bibliotecas de terceros. Microsoft C++ tiene la capacidad de escribir #import <algo.tlb>. Se podría hacer lo mismo con IDL en DTS C++, pero esto no se implementó. En su lugar, debe aplicar un emisor que creará los archivos .hh requeridos por el compilador DTS C++. El compilador DTS C++ es compatible tanto con las clases regulares de C++ como con las clases SOM que heredan de SOMObject (explícita o implícitamente, con #pragma SOMAsDefault (on)). Al igual que con otro híbrido, Objective-C++, la capacidad de mezclar clases de diferentes jerarquías es limitada.
Direct-to-SOM C++ apareció en MetaWare High C++ y luego se duplicó en VisualAge C++; además, estas implementaciones no son directamente compatibles, solo a través de la importación/exportación a .idl. En el libro "Putting Metaclasses to Work" se describió otro tercer dialecto conocido de DTS C ++, cuyo compilador aún no existe.
Hay una implementación abierta de SOM - somFree [13] . El proyecto reclama compatibilidad binaria con la implementación original de IBM. Netlabs.org mantiene una implementación de NOM que se basa en los principios de SOM, pero no es compatible con código fuente ni binario.
| Componentes y API de OS/2 | |
|---|---|
| Principal | |
| Servicios de gestión | |
| Juegos |
|
| núcleo del sistema operativo | |
| Sistemas de archivos | |
| subsistema de gráficos |
|
| modelo de objetos | MOS
|
| Compatibilidad |
|