Системная объектная модель IBM

Не путать с системной объектной моделью (формат файла) .

IBM SOMобъекты

Разработчик(и)	ИБМ
Стабильная версия	3.0 / декабрь 1996 г.
Операционная система	OS/2 , Windows , AIX , Classic Mac OS , Copland , OS/390 , NonStop OS , OS/400
Тип	объектно-ориентированная общих библиотек система

Системная объектная модель ( SOM ) — это объектно-ориентированная технология общих библиотек, разработанная IBM , которая поддерживает определение интерфейса для объекта так, чтобы его интерфейс был отделен от его реализации .

DSOM , распределенный вариант, основанный на CORBA , позволял объектам на разных компьютерах взаимодействовать.

Библиотеку SOM можно обновить, не требуя пересборки клиентского кода. Если библиотека изменяется для добавления новых классов или методов или для изменения внутренней реализации классов или методов, программа-потребитель все равно может использовать ее без пересборки. Таким образом, SOM решает хрупкую проблему двоичного интерфейса , которая затрагивает другие библиотечные технологии, такие как C++ .

SOM позволяет классы определять на одном языке программирования и использовать их на другом. Клиент может создавать и использовать объекты из представленных классов и получать подклассы из представленных классов, даже если язык клиента не поддерживает типизацию классов.

SOM предоставляет интерфейс прикладного программирования (API), который обеспечивает доступ к метаданным библиотеки . Каждый объект предоставляет методы, которые предоставляют, например, имя класса и информацию о том, реализует ли объект конкретный метод.

Приложения

SOM предназначался для универсального использования в мэйнфреймах и настольных компьютерах IBM ( OS/2 ), позволяя программам, разработанным для настольных компьютеров, использовать мэйнфрейм для обработки и хранения данных. IBM выпустила версии SOM/DSOM для OS/2, Microsoft Windows и различных разновидностей Unix от IBM (в частности, собственной AIX ). Некоторое время после образования альянса AIM SOM/DSOM также использовалась Apple Computer для аналогичных целей. Наиболее широко он использовался в их среде OpenDoc , но и в других целях использовался ограниченно.

Возможно, наиболее широкое применение SOM в IBM наблюдалось в более поздних версиях OS/2, в которых он использовался для большей части кода, включая Workplace Shell . Объект REXX для OS/2 может работать с классами и объектами SOM, включая WPS.

IBM не полностью закрыла SOMobjects. Они были портированы на OS/390 и до сих пор доступны в этой ОС. Документацию можно прочитать на сайте IBM. В 1996 году компания Tandem Computers Inc. приобрела технологию SOMobjects. Tandem был продан Compaq, Compaq был продан Hewlett-Packard. NonStop DOM и некоторые другие технологии в конечном итоге объединились в NonStop CORBA, но текущая документация продуктов NonStop не содержит признаков того, что технология SOM все еще используется в продуктах NonStop.

Угасание

Со «смертью» OS/2 в середине 1990-х годов смысл существования SOM/DSOM практически исчез; если бы пользователи не использовали OS/2 на настольных компьютерах, в любом случае не было бы универсальной библиотеки объектов. В 1997 году, когда Стив Джобс вернулся в Apple и завершил многие разработки, включая Copland и OpenDoc , SOM был заменен Objective-C, уже использовавшимся в OPENSTEP (позже ставшим Mac OS X). Разработка SOM/DSOM сошла на нет и больше не развивается активно, хотя продолжает включаться и использоваться в системах на базе OS/2, таких как ArcaOS .

Несмотря на фактическую смерть OS/2 и OpenDoc, у SOM может быть еще одна ниша: Windows и кроссплатформенная разработка. SOM 3.0 для WinNT стала общедоступной в декабре 1996 года. Причины отсутствия продвижения в этих направлениях выходят за рамки проблем внедрения на рынке. Они связаны с возможностями, упущенными IBM . и деструктивные несовместимые изменения:

• Первой версией VisualAge C++ для Windows была 3.5. Это была первая и последняя версия, поддерживающая SOM. В него была встроена SOM 2.1 и поддержка Direct-to-SOM в компиляторе. В версиях 3.6.5 и более поздних версиях SOM не было.
• SOMobjects в основном полагался на make-файлы . В VisualAge C++ 4.0 представлены проекты .icc и удалены из поставки компилятор и компоновщик командной строки icc.exe и ilink.exe. Невозможно собрать какой-либо образец SOM DTK «из коробки» с VAC++ 4.0. VisualAge C++ поставляется с собственными примерами, но образцы SOM .icc отсутствуют даже в VAC++ 4.0 для OS/2. vacbld.exe, единственный инструмент компиляции командной строки, не поддерживает SOM.
• Встроенная библиотека объектных компонентов VisualAge C++ (OCL) не основана на SOM. Вероятно, его планировалось портировать на SOM с использованием режима C++ Direct-to-SOM, но в VAC v3.6.5 от этого режима отказались, а у OCL до сих пор нет интерфейса SOM.
• Ближе к концу 1990-х годов IBM закрыла сайты загрузки SOMobjects и больше никогда их не открывала. SOM 3.0 DTK для WinNT невозможно найти на IBM FTP, несмотря на то, что множество других устаревших материалов лежит свободно. Несмотря на общедоступность SOM 3.0 для WinNT, до конца 2012 года ее было практически невозможно найти.
• Наконец, IBM никогда не открывала исходный код SOM (как это было с Object REXX ), несмотря на несколько статей. и петиции.

Альтернативные реализации

Существуют два проекта реализации SOM с открытым исходным кодом. Одной из них является объектная модель Netlabs (NOM), которая технически одинакова, но несовместима на уровне двоичного кода. Другой — somFree, который представляет собой версию IBM SOM для чистых помещений и совместим с двоичными файлами.

Сравнение со скомпилированными библиотеками классов

SOM можно сравнить с скомпилированными библиотеками:

• Смолток
• Общая объектная система Lisp (CLOS)
• универсальный С++
• SGI Дельта/C++
• Двоичный интерфейс объекта Солнца
• Цель-C
• Ява

По состоянию на 2015 год большая часть информации в связанной таблице применима к современным версиям, за исключением Objective-C 2.0, который получает так называемые нехрупкие переменные экземпляра. Некоторые решения остались экспериментальными: SGI Delta/C++ или Sun OBI. Большинство подходов, основанных на одном языке программирования, были постепенно выведены из употребления или никогда не использовались активно таким же образом. Например, плагины браузера Netscape Plugin Application Programming Interface ( NPAPI ) изначально были написаны с использованием Java API (LiveConnect), но позже виртуальная машина Java (JVM) была исключена из цепочки. Это можно рассматривать как замену Java кросс-платформенной объектной моделью компонентов ( XPCOM ). Common Lisp Object System (CLOS) и Smalltalk не являются звеньями цепочки, как Java в LiveConnect. Objective-C также мало известен в этой роли и не продается таким образом, но его среда выполнения является одним из наиболее дружественных к аналогичным вариантам использования.

Общий C++ до сих пор используется в Qt и K Desktop Environment ( KDE ). Qt и KDE известны тем, что описывают усилия, необходимые для поддержания двоичной совместимости без специальной поддержки в инструментах разработки.

GObject Целью было избежать зависимости от компилятора C++, но проблемы с RRBC такие же, как и в обычном C++.

Без специальной среды выполнения многие другие языки программирования будут иметь те же проблемы, например, Delphi , Ada . Это можно проиллюстрировать так называемым беспрецедентным подходом , который использовался для создания версии Delphi 2007, совместимой с двоичным кодом Delphi 2006: Как добавить «опубликованное» свойство, не нарушая совместимости с DCU. Архивировано 8 декабря 2015 г. на Wayback Machine.

Objective-C является наиболее многообещающим конкурентом SOM ​​(хотя он и не позиционируется активно как многоязычная платформа), и SOM предпочтительно следует сравнивать с Objective-C, а не с COM, как это было исторически. Благодаря нехрупким переменным экземпляра в Objective-C 2.0 это лучшая альтернатива среди активно поддерживаемых.

COM , XPCOM активно используются, но они управляют только интерфейсами, а не реализациями, и поэтому не находятся на одном уровне с SOM, GObject и Objective-C . Среда выполнения Windows при более пристальном рассмотрении ведет себя очень похоже на COM. Его описание метаданных основано на .NET, но поскольку WinRT не содержит специальной среды выполнения для решения проблем RRBC, как в Objective-C или SOM, пришлось применить несколько ограничений, которые ограничивают WinRT на процедурном уровне:

Система типов (C++/CX)

Класс ссылки, имеющий открытый конструктор, должен быть объявлен как запечатанный, чтобы предотвратить дальнейшее наследование.

Компоненты среды выполнения Windows — компоненты среды выполнения Windows в мире .NET

Другое ограничение заключается в том, что нельзя предоставлять общие общедоступные классы или интерфейсы. Полиморфизм недоступен для типов WinRT, и самое близкое к этому — реализация интерфейсов WinRT; вы должны объявить запечатанными все классы, которые общедоступны вашим компонентом среды выполнения Windows.

Сравнение с COM

SOM часто сравнивают с объектной моделью компонентов (COM). Оба поддерживают формат библиотеки, который можно использовать более чем на одном языке.

Некоторые считают SOM более надежным, поскольку он поддерживает только независимый от языка механизм вызова, аналогичный позднему связыванию COM . COM также поддерживает раннее связывание , иначе говоря, пользовательский интерфейс, который менее безопасен, но более эффективен. Он позволяет клиенту получить доступ к объекту через таблицу функций, совместимую с C и, следовательно, совместимую с двоичной структурой виртуальной таблицы объектов C++ (по крайней мере, в компиляторе Microsoft C++). При наличии совместимого компилятора C++ пользовательский интерфейс можно определить как чистый виртуальный класс C++. Интерфейс может быть вызван любым языком, который может вызывать функции C через указатель.

Риск пользовательского интерфейса заключается в том, что несовместимость может привести к неопределенному поведению . В частности, если версия объекта публикуется с измененным пользовательским интерфейсом, клиент может аварийно завершить работу. Это пример проблемы хрупкого базового класса . Чтобы предотвратить эту проблему, правило разработки COM заключается в том, что после публикации пользовательский интерфейс не может быть изменен. Чтобы добавить или изменить предоставляемые функции объекта, он может реализовать дополнительные пользовательские интерфейсы.

SOM позволяет избежать этой проблемы, предоставляя только позднее связывание, позволяя компоновщику во время выполнения перестраивать таблицу на лету. Таким образом, изменения в базовых библиотеках разрешаются при их загрузке в программы.

SOM более надежен с точки зрения поддержки объектно-ориентированных (ОО) функций. В то время как COM по существу определяет урезанную версию C++ для программирования, SOM поддерживает почти все распространенные функции. Он также поддерживает некоторые менее распространенные функции, такие как множественное наследование , метаклассы и динамическую диспетчеризацию , что привело к тому, что большинство SOM/COM-подобных систем стали проще за счет поддержки меньшего количества языков. Поддержка нескольких языков была важна для IBM, поскольку они хотели поддерживать как Smalltalk ( единое наследование и динамическая диспетчеризация ), так и C++ ( множественное наследование и фиксированная диспетчеризация).

Заметным отличием является поддержка наследования. COM нет. Хотя может показаться странным, что Microsoft создала технологию объектной библиотеки, которая не могла поддерживать столь фундаментальную концепцию объектно-ориентированного программирования; Основная причина заключается в том, что трудно определить, где в памяти находится базовый класс, где библиотеки загружаются в порядке, неизвестном во время разработки. COM требует, чтобы программист указал точный базовый класс во время компиляции, что делает невозможным вставку других производных классов в середину; по крайней мере, в других библиотеках COM.

Вместо этого SOM использует алгоритм, который ищет потенциальные базовые классы, следуя дереву наследования и останавливаясь на первом подходящем. В большинстве случаев именно эта идея лежит в основе наследования. Обратной стороной этого подхода является то, что новые версии этого базового класса могут перестать работать, даже если API останется прежним. Такая возможность существует в любой программе, не только в той, которая использует общую библиотеку, но проблема может оказаться трудноразрешимой, если она существует в чужом коде. В SOM единственное решение — тестирование новых версий библиотек.

Хотя IBM противопоставляла SOM и COM, они не были взаимоисключающими. В 1995 году Novell представила ComponentGlue. технологию OpenDoc для Windows. Эта технология предоставила различные средства интеграции между компонентами COM и SOM. В частности, объекты SOM могут быть доступны приложениям OLE2 либо с помощью моста позднего связывания (на основе IDispatch), либо с помощью COM-интерфейсов, имеющих более высокую производительность. По сути, классы SOM таким образом реализуют COM-интерфейсы.

Подобные технологии, такие как Distributed Objects Everywhere , также поддерживают полное наследование. Портативные распределенные объекты позволяют избежать этих проблем благодаря надежной системе управления версиями, позволяя авторам библиотек поставлять новые версии вместе со старыми, тем самым гарантируя обратную совместимость за счет дискового пространства.