Бағдарламалық ая: SOM және DSOM жүйелері

Кіріспе

Бағдарламалау аясы

Есептеу техникасында, System Object Model (SOM) – IBM компаниясы жасаған нысанға бағытталған ортақ кітапхана жүйесі. CORBA негізіндегі DSOM-ның таратылған нұсқасы әртүрлі компьютерлердегі нысандардың өзара байланысуына мүмкіндік берді. SOM бағдарламалардың немесе кітапханалар мен бағдарламалардың арасындағы интерфейсті анықтайды, сондықтан нысанның интерфейсі оның іске асырылуынан бөлек болады. SOM бір бағдарламалау тілінде нысандар кластарын анықтауға және басқа тілдерде пайдалануға мүмкіндік береді, сондай-ақ клиенттік кодты қайта компиляциялауды қажет етпей, мұндай кластардың кітапханаларын жаңартуға мүмкіндік береді. SOM кітапханасы кластар, әдістер, статикалық функциялар және дерек мүшелерінің жиынтығынан тұрады. SOM кітапханасын пайдаланатын бағдарламалар кітапханада анықталған типтердің нысандарын құра алады, нысан түрі үшін анықталған әдістерді қолданады және SOM кластарынан қосалқы кластарды тудыра алады, тіпті SOM кітапханасына кіретін бағдарламаның тілі кластарды типтеуді қолдамаса да. SOM кітапханасы мен сол кітапхананың нысандарын және әдістерін пайдаланатын бағдарламалар бірдей бағдарламалау тілінде жазылуы міндетті емес. SOM сонымен қатар кітапханаларға енгізілген өзгертулердің әсерін азайтады. Егер SOM кітапханасы жаңа кластар немесе әдістерді қосу үшін немесе кластардың немесе әдістердің ішкі іске асырылуын өзгерту үшін өзгертілсе, сол кітапхананы қайта компиляциялаусыз пайдаланатын бағдарламаны іске қосуға болады. Бұл басқа C++ кітапханаларының барлығына тән емес, кейбір жағдайларда кітапханалар өзгерген сайын оларды пайдаланатын барлық бағдарламаларды қайта құрастыру қажет болады, бұл әлсіз бинарлық интерфейс мәселесі деп аталады. SOM бағдарламаларға SOM класы немесе SOM нысаны туралы ақпаратқа қол жеткізуге мүмкіндік беретін қолданбалық бағдарламалау интерфейсін (API) ұсынады. Кез келген SOM класы, мысалы, нысанның кластық атауын табу немесе берілген әдістің нысан үшін қолжетімді екенін анықтау үшін пайдаланылатын виртуалды әдістер жиынтығын мұра етеді.

Өте төмендеу

1990 жылдардың ортасында OS/2-нің «өлімімен» бірге SOM/DSOM-ның негізгі мақсаты жоғалып кетті; егер пайдаланушылар OS/2-ні жұмыс үстелінде қолданбаса, онда жалпылама объектілер кітапханасының қажеті болмас еді. 1997 жылы Стив Джобс Apple-ге оралғанда және Copland және OpenDoc сияқты көптеген әзірлемелерді тоқтатқанда, SOM орнына Objective C, OPENSTEP-те (кейіннен Mac OS X-ке айналған) қолданылып келді. SOM/DSOM әзірлемесі тоқырап, енді белсенді түрде дамытылмайды, бірақ ол ArcaOS сияқты OS/2 негізіндегі жүйелерде қолданыла береді және кіріктіріледі. OS/2 және OpenDoc-тың тиімді тоқтатылуына қарамастан, SOM үшін тағы бір сала болуы мүмкін: Windows және кросс-платформалық әзірлеме. WinNT үшін SOM 3.0 1996 жылдың желтоқсанында қолжетімді болды. Осы бағыттағы дамудың тоқтауы нарықтағы қабылдау мәселелерінен асып түседі. Олар IBM-нің жіберген мүмкіндіктерін және зиянды, үйлесімсіз өзгерістерді қамтиды: Windows үшін VisualAge C++-тың алғашқы нұсқасы 3.5 болды. Бұл SOM-ды қолдаған алғашқы және соңғы нұсқа еді. Ол SOM 2.1 жиынтығымен бірге келді және компиляторда Direct to SOM қолдауы болды. 3.6.5 және одан кейінгі нұсқаларында SOM-ның ізі де жоқ. SOMobject-ілер көбінесе makefile-дарға сүйенді. VisualAge C++ 4.0 icc жобаларын енгізді және icc.exe және ilink.exe командалық жолды компиляторы мен байланыстырғышын алып тастады. VAC++ 4.0-пен бірге SOM DTK үлгісін тікелей қораптан шығару мүмкін емес. VisualAge C++ өзінің үлгілерімен бірге келеді, бірақ OS/2 үшін VAC++ 4.0-та icc SOM үлгілері жоқ. vacbld.exe, жалғыз командалық жолды құрастыру құралы, SOM-ды қолдамайды. VisualAge C++ жиынтығындағы Object Component Library (OCL) SOM-ға негізделмеген. Ол, мүмкін, C++ Direct to SOM режимін пайдаланып SOM-ға портталған болуы керек еді, бірақ VAC v3.6.5-те бұл режим тоқтатылды және OCL-де SOM интерфейсі жоқ. 1990 жылдардың соңында IBM SOMobject жүктеу сайттарын жапты және оларды қайтадан іске қоспады. WinNT үшін SOM 3.0 DTK IBM FTP-де табылмайды, басқа көптеген ескі материалдар еркін түрде орналасқан болса да. WinNT үшін SOM 3.0-дың қолжетімділігіне қарамастан, оны 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-де құрастырылатын функциялар кестесін пайдаланады, бірақ Microsoft C++ компиляторындағы C++ нысандарының екілік макетімен де тікелей үйлесімді. Үйлесімді C++ компиляторларымен Custom Interfaces тікелей таза виртуалды C++ кластары ретінде анықталуы мүмкін. Алынған интерфейске C функцияларын көрсеткіштер арқылы шақыра алатын тілдер шақыруы мүмкін. Custom Interfaces беріктіктің орнына өнімділікті ұсынады. Интерфейс шығарылған өнімде жарияланғаннан кейін оны өзгертуге болмайды, себебі осы интерфейстің клиенттік қосымшалары осы интерфейстің нақты екілік макетіне сәйкес құрастырылған. Бұл DLL тозағына әкелуі мүмкін нәзік негізгі сынып мәселесінің мысалы, себебі ортақ кітапхананың жаңа нұсқасы орнатылғанда және ескі нұсқаға негізделген барлық бағдарламалар дұрыс жұмыс істеуін тоқтатуы мүмкін. Бұл мәселені болдырмау үшін COM әзірлеушілері интерфейсті жариялағаннан кейін оны ешқашан өзгертуге болмайтынын есте сақтауы керек, ал жаңа әдістер немесе басқа өзгерістер қажет болған жағдайда жаңа интерфейстерді анықтау қажет. SOM осы мәселелерді болдырмау үшін тек кешіктірілген байланысты қамтамасыз етеді, бұл орындалу уақыты байланыстырушыға кестені динамикалық түрде қайта құруға мүмкіндік береді. Осылайша, кітапханаларға өзгерістер енгізілгенде, олар бағдарламаларға жүктелген кезде шешіледі, бірақ өнімділік төмендеуі мүмкін. SOM сонымен қатар ОО тілдерінің кең спектрін толық қолдау тұрғысынан әлдеқайда сенімді. COM C++ бағдарламалаудың қысқартылған нұсқасын анықтайтын болса, SOM барлық жалпы мүмкіндіктерді және тіпті кейбір ерекше мүмкіндіктерді қолдайды. Мысалы, SOM көптеген мұрагерліктерді, метакласстарды және динамикалық жіберуді қолдайды. Бұл мүмкіндіктердің кейбіреулері көптеген тілдерде жоқ, бұл SOM/COM сияқты жүйелердің көпшілігін аз тілдерді қолдау есебінен қарапайым етуге әкелді. Көп тілді қолдаудың толық икемділігі IBM үшін маңызды болды, себебі олар Smalltalk (бір мұрагерлік және динамикалық жіберу) пен C++ (көп мұрагерлік және тұрақты жіберу) қолдау үшін үлкен күш-жігер жұмсады. SOM мен COM арасындағы ең маңызды айырмашылық мұрагерлік қолдауы болып табылады. Microsoft OO бағдарламалаудың ең негізгі ұғымдарының бірін қолдамайтын нысан кітапханасы жүйесін жасағаны таңғаларлық көрінуі мүмкін; Мұның басты себебі кітапханалар ықтимал кездейсоқ тәртіппен жүктелетін жүйеде базалық сыныптың қайда екенін білу қиындығы. COM бағдарламалаушыдан компиляция кезінде нақты базалық сыныпты көрсетуді талап етеді, бұл ортаға басқа туынды сыныптарды енгізуді мүмкін емес етеді (кем дегенде басқа COM кітапханаларында). SOM оның орнына қарапайым алгоритмді пайдаланады, мұрагерлік ағашын жалғап, сәйкес келетін біріншіге тоқтап, әлеуетті базалық сыныптарды іздейді; бұл көп жағдайда мұрагерліктің негізгі идеясы. Бұл тәсілдің кемшілігі базалық сыныптың жаңа нұсқалары API өзгермесе де жұмыс істемеуі мүмкін. Бұл мүмкіндік кез-келген бағдарламада бар, тек ортақ кітапхананы пайдаланғандар ғана емес, бірақ егер ол басқа біреудің кодында болса, мәселені анықтау өте қиынға соғуы мүмкін. SOM-да жалғыз шешім кітапханалардың жаңа нұсқаларын кеңінен сынау, бұл әрқашан оңай емес. SOM және COM IBM тарапынан қарама-қарсы қойылғанмен, олар бір-бірінсіз де жарамайтын емес. 1995 жылы Novell Windows үшін OpenDoc-қа ComponentGlue технологиясын қосты. Бұл технология COM және SOM негізіндегі компоненттерді біріктірудің әртүрлі тәсілдерін ұсынды. Атап айтқанда, SOM нысандарын OLE2 қосымшаларына кешіктірілген байланыс көпірі (IDispatch негізінде) немесе COM интерфейстері арқылы қол жетімді етуге болады. Негізінде, SOM сыныптары осылайша COM интерфейстерін жүзеге асырады. SOM ұсынған икемділік көптеген адамдар үшін қиындыққа тұрарлық деп есептелді, бірақ Sun Microsystems-тің Distributed Objects Everywhere сияқты ұқсас жүйелер де толық мұрагерлікті қолдады. NeXT-тің Portable Distributed Objects осы мәселелерді күшті нұсқалау жүйесі арқылы болдырмады, бұл кітапхана авторларына ескі нұсқалармен бірге жаңа нұсқаларды жіберуге мүмкіндік берді, осылайша дискідегі орынның шағын құнымен кері үйлесімділікті қамтамасыз етті.

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.