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

Не путать с системной объектной моделью (формат файла) .
IBM SOMobjects
Логотип IBM SOM
Разработчики) IBM
Стабильный выпуск
3.0 / декабрь 1996 г.
Операционная система OS / 2 , Windows , AIX , классическая Mac OS , Copland , OS / 390 , NonStop OS
Тип объектно-ориентированная система общих библиотек

В области вычислений Системная объектная модель ( SOM ) - это объектно-ориентированная система разделяемых библиотек , разработанная IBM . DSOM , распределенная версия, основанная на CORBA , позволяла объектам на разных компьютерах обмениваться данными.

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

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

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

Приложения

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

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

IBM не закрыла полностью SOMobjects. Они были перенесены на OS / 390 и до сих пор доступны в этой ОС. Документацию можно прочитать на сайте IBM. В 1996 году Tandem Computers Inc. приобрела технологию SOMobjects. Тандем был продан 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 и компоновщик. С VAC ++ 4.0 невозможно собрать любой образец SOM DTK из коробки. VisualAge C ++ поставляется со своими собственными образцами, но образцы SOM .icc отсутствуют даже в VAC ++ 4.0 для OS / 2. vacbld.exe, единственный инструмент компиляции командной строки, не поддерживает SOM.
  • Встроенная библиотека объектных компонентов (OCL) VisualAge C ++ не была основана на 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 сравнивали с моделью компонентных объектов Microsoft (COM) IBM. Однако с некоторых точек зрения COM вообще нет места. С точки зрения преобразований от выпуска к выпуску, COM находится на процедурном уровне, поэтому таблица 1 в статье RRBC ( бинарная совместимость от выпуска к выпуску, упоминавшаяся ранее) вообще не содержит столбца COM. Вместо этого SOM сравнивают с:

Большая часть информации в этой таблице по-прежнему применима к современным версиям (по состоянию на 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

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 предлагает два метода доступа к методам объекта, и объект может реализовать либо один из них, либо оба. Первый - это динамическое и позднее связывание ( IDispatch ), он не зависит от языка, аналогично тому, что предлагает SOM. Второй, называемый пользовательским интерфейсом, использует таблицу функций, которая может быть построена на C, но также напрямую совместима с двоичной компоновкой виртуальной таблицы объектов C ++ в компиляторе Microsoft C ++. Таким образом, с совместимыми компиляторами C ++ пользовательские интерфейсы могут быть определены непосредственно как чистые виртуальные классы C ++. Полученный интерфейс затем может вызываться языками, которые могут вызывать функции C через указатели. Пользовательские интерфейсы приносят надежность в обмен на производительность. После того, как интерфейс опубликован в выпущенном продукте, его нельзя изменить, поскольку клиентские приложения этого интерфейса были скомпилированы в соответствии с определенной двоичной компоновкой этого интерфейса. Это пример проблемы хрупкого базового класса , которая может привести к аду DLL , поскольку установлена ​​новая версия разделяемой библиотеки и все программы, основанные на более старой версии, могут перестать работать должным образом. Чтобы предотвратить эту проблему, разработчики COM должны помнить, что никогда не изменяйте интерфейс после его публикации, и необходимо определить новые интерфейсы, если требуются новые методы или другие изменения.

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

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

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

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

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

Гибкость, SOM считается стоит свеч почти все, но подобные системы, такие как Sun Microsystems " Распределенные объекты Везде , также поддерживает полное наследование. NeXT «s Портативные Распределенные объекты избежать этих проблем с помощью сильной системы управления версий, что позволяет библиотечные авторам поставлять новые версии вместе со старым, тем самым гарантируя обратную совместимость для небольшой стоимости дискового пространства.

Смотрите также

использованная литература

  1. ↑ SOM и Object REXX доктора Уиллиса Боутона (август 2004 г.)
  2. ^ SOMobjects для документации OS / 390
  3. ^ Тандем использует технологию IBM SOMobjects для распределенных объектных вычислений
  4. ↑ Ира Р. Форман и Скотт Дэнфорт (1999). Запуск метаклассов в работу . ISBN 0-201-43305-2.
    Глава 11 «Двоичная совместимость от выпуска к выпуску», стр. 246.
    В Интернете можно найти статью с таким же названием и аналогичным содержанием, принадлежащую одному и тому же автору: Совместимость двоичных версий от выпуска к выпуску
  5. ^ «Список классов ArcaOS 5.0 WPS» . Проверено 3 сентября 2020 .
  6. ↑ Lost in the Garden , Роджер Сешнс (август 1996)
  7. ^ Просто небольшая вещь SOM для разработчиков Linux Эстер Шиндлер (февраль 2008 г.)
  8. ^ Оживление OS / 2 лучших на рабочем столе Linux архивной 2010-04-17 в Wayback Machine Стивен Дж Vaughan-Nichols (февраль 2008 г.)
  9. ↑ Петиция OS / 2 , второй раунд (2007–2010)
  10. ^ Проблемы двоичной совместимости с C ++
  11. ^ ComponentGlue (tm) Обеспечивает полную совместимость с OLE, элементами управления OCX

внешние ссылки