Система объектных моделей SOM/DSOM: история и перспективы

Введение

В вычислительной технике, Система Объектная Модель (SOM) — это объектно-ориентированная система общих библиотек, разработанная IBM. DSOM, распределенная версия на основе CORBA, обеспечивала взаимодействие объектов на разных компьютерах. SOM определяет интерфейс между программами или между библиотеками и программами, отделяя интерфейс объекта от его реализации. SOM позволяет определять классы объектов на одном языке программирования и использовать их в другом, а также обновлять библиотеки таких классов без перекомпиляции клиентского кода. Библиотека SOM состоит из набора классов, методов, статических функций и членов данных. Программы, использующие библиотеку SOM, могут создавать объекты заданных типов, использовать определенные для этих типов методы и создавать подклассы на основе классов SOM, даже если язык программы, обращающейся к библиотеке SOM, не поддерживает строгую типизацию классов. Библиотека SOM и программы, использующие объекты и методы этой библиотеки, могут быть написаны на разных языках программирования. SOM также минимизирует влияние изменений в библиотеках. Если библиотека SOM изменяется с добавлением новых классов или методов, либо с изменением внутренней реализации классов или методов, программу, использующую эту библиотеку, можно запустить без перекомпиляции. Это не характерно для многих других библиотек C++, которые в некоторых случаях требуют перекомпиляции всех программ, использующих их, при изменении библиотек – проблема, известная как хрупкий бинарный интерфейс. SOM предоставляет интерфейс прикладного программирования (API), обеспечивающий программам доступ к информации о классе SOM или объекте SOM. Любой класс SOM наследует набор виртуальных методов, которые можно использовать, например, для определения имени класса объекта или для проверки доступности определенного метода для объекта.

Уходит в прошлое

С "смертью" OS/2 в середине 1990-х годов, raison d'être 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. Объекты SOM в значительной степени полагались на makefiles. VisualAge C++ 4.0 представил проекты icc и удалил из дистрибутива командную строку компилятора icc.exe и линкера ilink.exe. Невозможно собрать какой-либо пример SOM DTK "из коробки" с помощью VAC++ 4.0. VisualAge C++ поставляется со своими собственными примерами, но даже в VAC++ 4.0 для OS/2 нет примеров icc SOM. 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 не удается найти на FTP-сервере IBM, несмотря на обилие другого устаревшего программного обеспечения, доступного для свободного скачивания. Несмотря на общую доступность SOM 3.0 для WinNT, его было практически невозможно найти до конца 2012 года. Наконец, IBM так и не открыла исходный код SOM (как это было сделано с Object REXX), несмотря на многочисленные статьи и петиции.

With the "death" of OS/2 in the mid 1990s, the raison d'être for SOM/DSOM largely disappeared; if users would not be running OS/2 on the desktop, there would be no universal object library anyway. In 1997, when Steve Jobs returned to Apple and ended many development efforts including Copland and OpenDoc, SOM was replaced with Objective C already being in use in OPENSTEP (to become Mac OS X later). SOM/DSOM development faded, and is no longer actively developed, although it continues to be included and used in OS/2 based systems such as ArcaOS. Despite effective death of OS/2 and OpenDoc, SOM could have yet another niche: Windows and cross platform development. SOM 3.0 for WinNT was generally available in December 1996. The reasons for not advancing in these directions go beyond market adoption problems. They involve opportunities missed by IBM, and destructive incompatible changes:
The first version of VisualAge C++ for Windows was 3.5. It was the first and the last version to support SOM. It had SOM 2.1 bundled in and Direct to SOM support in the compiler. Versions 3.6.5 and later had no trace of SOM. SOMobjects largely relied on makefiles. VisualAge C++ 4.0 introduced icc projects and removed icc. exe and ilink. exe command line compiler and linker from supply. It is impossible to build any SOM DTK sample out of box with VAC++ 4.0. VisualAge C++ comes with its own samples, but there are no icc SOM samples even in VAC++ 4.0 for OS/2. vacbld. exe, the only command line compilation tool, doesn't support SOM. VisualAge C++ bundled in Object Component Library (OCL) was not based on SOM. It was probably meant to be ported to SOM using C++ Direct to SOM mode, but in VAC v3.6.5 this mode was abandoned, and OCL has no SOM interface so far. Near the end of the 1990s, IBM shut down SOMobjects download sites and never put them back online. SOM 3.0 DTK for WinNT can't be found on IBM FTP, despite much other legacy stuff lying around freely. Despite general availability of SOM 3.0 for WinNT, it was nearly impossible to locate until the end of 2012. Finally, IBM never open sourced SOM (as done to Object REXX), despite several articles and petitions.

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

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

Сравнение с ОМ

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, почти всеми считалась оправданной, но подобные системы, такие как Distributed Objects Everywhere от Sun Microsystems, также поддерживали полное наследование. Portable Distributed Objects от NeXT избегали этих проблем благодаря надежной системе версионирования, позволяющей авторам библиотек поставлять новые версии вместе со старыми, тем самым гарантируя обратную совместимость за небольшую плату в виде дискового пространства.

SOM is similar in concept to COM. Both systems address the problem of producing a standard library format that can be called from more than one language. SOM can be considered more robust than COM. COM offers two methods of accessing methods onto an object, and an object can implement either one of them or both. The first one is dynamic and late binding (IDispatch), and is language neutral similar to what is offered by SOM. The second, called a Custom Interface, is using a function table which can be built in C but is also directly compatible with the binary layout of the virtual table of C++ objects in Microsoft's C++ compiler. With compatible C++ compilers, Custom Interfaces can therefore be defined directly as pure virtual C++ classes. The resulting interface can then be called by languages that can call C functions through pointers. Custom Interfaces trade robustness for performance. Once an interface is published in a released product, it can not be changed, because client applications of this interface were compiled against a specific binary layout of this interface. This is an example of the fragile base class problem, which can lead to DLL hell, as a new version of a shared library is installed and all programs based on the older version can stop functioning properly. To prevent this problem, COM developers must remember to never change an interface once it is published, and new interfaces need to be defined if new methods or other changes are required. SOM prevents these issues by providing only late binding, to allow the run time linker to re build the table on the fly. This way, changes to the underlying libraries are resolved when they are loaded into programs, although there is a performance cost. SOM is also much more robust in terms of fully supporting a wide variety of OO languages. Whereas basic COM essentially defines a cut down version of C++ to program to, SOM supports almost all common features and even some more esoteric ones. For instance SOM supports multiple inheritance, metaclasses and dynamic dispatching. Some of these features are not found in most languages, which had led most SOM/COM like systems to be simpler at the cost of supporting fewer languages. The full flexibility of multi language support was important to IBM, however, as they had a major effort underway to support both Smalltalk (single inheritance and dynamic dispatch) with C++ (multiple inheritance and fixed dispatch). The most notable difference between SOM and COM is support for inheritance—COM does not have any. It might seem odd that Microsoft produced an object library system that could not support one of the most fundamental concepts of OO programming; the main reason for this is that it is difficult to know where a base class exists in a system where libraries are loaded in a potentially random order. COM demands that the programmer specify the exact base class at compile time, making it impossible to insert other derived classes in the middle (at least in other COM libraries). SOM instead uses a simple algorithm, looking for potential base classes by following the inheritance tree and stopping at the first one that matches; this is the basic idea behind inheritance in most cases. The downside to this approach is that it is possible that new versions of this base class may no longer work even if the API remains the same. This possibility exists in any program, not only those using a shared library, but a problem can become very difficult to track down if it exists in someone else's code. In SOM, the only solution is extensive testing of new versions of libraries, which is not always easy. While SOM and COM were contrapositioned by IBM, they were not mutually exclusive. In 1995 Novell contributed ComponentGlue technology to OpenDoc for Windows. This technology provided different means to integrate between COM and SOM based components. In particular, SOM objects can be made available to OLE2 applications by either late binding bridge (based on IDispatch) or COM interfaces having higher performance. In essence, SOM classes are implementing COM interfaces this way. The flexibility offered by SOM was considered worth the trouble by almost all , but similar systems, such as Sun Microsystems' Distributed Objects Everywhere, also supported full inheritance. NeXT's Portable Distributed Objects avoided these issues via a strong versioning system, allowing library authors to ship new versions along with the old, thereby guaranteeing backward compatibility for the small cost of disk space.