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

Информацию о формате исполняемого файла с аналогичным названием в операционной системе HP-UX см. В разделе Системная объектная модель (формат файла).

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «Системная объектная модель IBM»  -  новости  · газеты  · книги  · ученый  · JSTOR ( март 2013 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

IBM SOMobjects

Разработчики)	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 наследует набор виртуальных методов, которые можно использовать, например, для поиска имени класса объекта или для определения того, доступен ли данный метод для объекта.

Приложения [ править ]

• OS / 2
• OpenDoc

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. ^[1]

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

Исчезновение [ править ]

Этот раздел, возможно, содержит оригинальные исследования . Пожалуйста, улучшите его , проверив сделанные утверждения и добавив встроенные цитаты . Заявления, содержащие только оригинальные исследования, следует удалить. ( Июль 2013 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

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

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

• Первой версией 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 ), несмотря на несколько статей ^{[7] [8]} и петиции. ^[9]

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

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

Сравнение поддержки скомпилированных библиотек классов [ править ]

Исторически SOM сравнивали с моделью компонентных объектов Microsoft (COM) IBM. Однако с некоторых точек зрения COM вообще нет места. С точки зрения преобразований от выпуска к выпуску, COM находится на процедурном уровне, поэтому таблица 1 в статье RRBC ( Двоичная совместимость от выпуска к выпуску упоминалась ранее) вообще не содержит столбца COM. Вместо этого SOM сравнивают с:

• скомпилированный Smalltalk
• скомпилированная объектная система Common Lisp (CLOS)
• общий C ++
• SGI Delta / C ++
• Двоичный интерфейс объекта Sun
• Цель-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 примечательны тем, что описывают усилия, необходимые для поддержания бинарной совместимости без специальной поддержки в инструментах разработки. ^[10]

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 ^[11] в OpenDoc для Windows. Эта технология предоставляла различные средства для интеграции компонентов на основе COM и SOM. В частности, объекты SOM могут быть доступны для приложений OLE2 либо мостом позднего связывания (на основе IDispatch), либо интерфейсами COM, имеющими более высокую производительность. По сути, классы SOM реализуют COM-интерфейсы таким образом.

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

См. Также [ править ]

• Компонентная объектная модель
• GObject
• Цель-C
• XPCOM
• Среда выполнения Windows

Ссылки [ править ]

External links[edit]

• IBM SOMobjects Developer's Toolkit Version 3.0 for Windows NT, OS/2 Warp, and AIX Documentation