| Rendszerobjektum-modell (SOMObjects) | |
|---|---|
| Fejlesztő | CIlabs ( IBM , Apple Computer stb.) |
| Operációs rendszer | MacOS , OS /2 , AIX , Windows , DOS |
| legújabb verzió | 3.0 ( 1996. december ) |
A System Object Model ( SOM ) a CILabs ( IBM , Apple , OMG, Adobe , Oracle stb.) által kifejlesztett objektumorientált dinamikus könyvtárak rendszere . A DSOM, a SOM CORBA -alapú elosztott változata, amely lehetővé teszi az objektumok elosztását a különböző számítástechnikai rendszerek között. Vannak implementációk Windows NT, MacOS Classic, OS/2, AIX, DOS, Copland, OS/390, NonStop OS operációs rendszerekhez. Windows NT, MacOS és OS/2 esetén létezik SOM/DSOM alapú OpenDoc komponensfejlesztés megvalósítása. A rendszert az 1990-es évek közepén fejlesztették ki, 1998-ban felhagytak vele [1] .
Az IBM SOM elvileg hasonló a Microsoft komponensobjektum modelljéhez . Mindkét rendszer megoldja a szabványos könyvtárformátum létrehozásának problémáját, amely több nyelvről is hívható. A SOM funkcionálisabbnak tekinthető, mint a COM. A COM kétféle módot biztosít metódusok meghívására egy objektumon, és egy objektum megvalósíthatja az egyiket vagy mindkettőt. Az első a dinamikus hívás és a késői kötés (IDispatch), és a SOM-hoz hasonlóan nyelvfüggetlen. A második mód egy privát felületen keresztül egy C-ben összeállítható függvénytáblázatot használ, vagy egy C++ objektum alacsonyabb szintű kompatibilis virtuális metódustábláját. Kompatibilis C++ fordítók használatával a privát interfészek tisztán virtuális C++ osztályokként deklarálhatók. A privát interfészek kompromisszumot jelentenek a funkcionalitás és a teljesítmény között. Miután egy felületet közzétettünk egy kiadott terméken, azt nem lehet módosítani, mert a felület felhasználói alkalmazásai egy adott táblaeszközhöz lettek lefordítva alacsony szinten. Ez egy példa egy törékeny alaposztály - problémára , amely DLL pokolhoz vezethet , ahol egy megosztott könyvtár új verziójának telepítése után a régi verziót használó összes program leáll. A probléma elkerülése érdekében a COM-fejlesztőknek mindig szem előtt kell tartaniuk, hogy a már közzétett felületeket nem szabad módosítani. Ha új metódusokat szeretne hozzáadni vagy más változtatásokat szeretne végrehajtani, új interfészeket kell meghatároznia. A SOM megakadályozza ezeket a problémákat azáltal, hogy csak késői kötést biztosít, és lehetővé teszi a futásidejű linker számára, hogy menet közben újraépítse a táblákat. Így az alapul szolgáló könyvtárakban végrehajtott módosítások újraszámításra kerülnek, amikor betöltik őket a programokba, kis teljesítménybüntetés árán.
A felület azonban nem csak technikai okokból, hanem az OOP szempontjából sem változtatható. Az interfésznek az osztályokkal ellentétben nincs alapértelmezett megvalósítása, és bárki megvalósíthatja, beleértve a külső fejlesztőket is. Ennek megfelelően, ha módosításokat hajtanak végre a felületen, a harmadik féltől származó osztályok nem tudják automatikusan támogatni az új felületet. Így vagy csak osztályokat használhat az interfészek helyett, biztosítva a mindig naprakész alapértelmezett megvalósítást, vagy megakadályozhatja, hogy a külső fejlesztők potenciálisan bővíthető felületet implementáljanak, ebben az esetben az "interfész" szó értelmét veszti. OOP feltételek.
A SOM a különféle OO nyelvek teljes támogatása szempontjából is funkcionálisabb. Míg a COM-fejlesztés a C++ lecsupaszított verziójának használatára korlátozódik, a SOM szinte az összes szokásos funkciót támogatja, sőt néhány ezoterikust is. Például a SOM támogatja a többszörös öröklődést, a metaosztályokat és a dinamikus hívásokat. Ezen szolgáltatások némelyike nem érhető el a legtöbb nyelven, így sok SOM/COM-szerű rendszer könnyebben megvalósítható kisebb nyelvkészlet támogatásának rovására. A többnyelvű támogatás teljes rugalmassága fontos volt az IBM számára, mivel mind a Smalltalkot (egyszeri öröklődés, dinamikus linkelés), mind a C++-t (többszörös öröklődés és statikus összekapcsolás) támogatni kellett. A többszörös öröklődés támogatásának szükségessége többek között annak a következménye, hogy az interfészek helyett csak osztályok vannak. Meg kell jegyezni, hogy a C++ többszörös öröklődés támogatása eltér a CLOS-tól, a Dylan-től, a SOM-tól és a Pythontól, és a C++ többszörös öröklődési problémái nem a SOM-ra jellemzőek.
A legszembetűnőbb különbség a SOM és a COM között az öröklődés támogatása, amivel a COM egyáltalán nem rendelkezik. Furcsának tűnhet, hogy a Microsoft olyan objektumkönyvtár-rendszert készített, amely nem támogatja az OOP legalapvetőbb elvét. Ennek fő akadálya az, hogy nehéz meghatározni, hol van az alaposztály a rendszerben, miközben a könyvtárak potenciálisan tetszőleges sorrendben kerülnek betöltésre. A COM megköveteli a fejlesztőtől, hogy a fordítási időben pontosan adja meg az alaposztályt, ami lehetetlenné teszi más örökölt osztályok beszúrását középre (legalábbis a külföldi COM-könyvtárakba).
Ezzel szemben a SOM egy egyszerű algoritmust használ, bejárja az öröklődési fát, keresve egy lehetséges alaposztályt, és az első megfelelőre telepszik. A legtöbb esetben ez az öröklés alapelve. Ennek a megközelítésnek a hátránya, hogy az alaposztály új verziói a változatlan API ellenére nem működnek. Ez a lehetőség minden programban létezik, nem csak a megosztott könyvtárakat használókban, de a probléma nagyon nehezen követhető nyomon, ha valaki más kódjában van. A SOM-ban az egyetlen megoldás a könyvtárak új verzióinak teljes tesztelése, ami nem mindig egyszerű.
Összehasonlítás más megközelítésekkel történt a „Release-to-Release bináris kompatibilitás és a külön fordítás helyessége” című jelentésben [2] , különösen a Smalltalk, CLOS, Generic C++, SOM, SGI Delta/C++, OBI, Objective-C. , Java. A modern rendszerek közül az alacsony szintű Objective-C kompatibilitást illetően áll a legközelebb a SOM-hoz, különösen a nem törékeny ivarok megvalósítása után.
A C és C++ emittereit magában a SOMobjects Developer Toolkit tartalmazza, és lehetővé teszik az objektummetódusok meghívását és az osztályokból való öröklést. Néhány C++ fordító, először a MetaWare High C++, majd az IBM VisualAge C++, implementálta a Direct-to-SOM képességet. A VisualAge C++ for Windows a 3.5-ös verzióban vezette be ezt a funkciót [3] , amely egyben az utolsó verzió is támogatta ezt a funkciót.
Az OS/2-vel együtt szállított ObjectREXX integrálva van a SOM-mal, lehetővé téve az objektumok metódusainak hívását és osztályokból való öröklést. Amikor az ObjectREXX forrásokat kiadták a nyílt forráskódú közösségnek, az integráció működéséhez szükséges összes fájl nem került átvitelre, és ez a szolgáltatás nem szerepelt a nyílt forráskódú verzióban. Egy ideig a SOM-mal való integráció nyomai voltak az adattárban, de nem lehetett lefordítani, és ezt követően mindent, ami a SOM-mal kapcsolatos, teljesen eltávolították.
A VisualAge SmallTalk SOMSupport csomag lehetővé teszi SOM metódusok meghívását az objektumokon, és SOM burkolók létrehozását a SmallTalk osztályokhoz .
Az IBM ObjectCOBOL eredetileg a SOM-ot objektumrendszerként használta Direct-to-SOM módban. Ezt követően az ObjectCOBOL-t Java-ra portolták, és a Java objektumrendszert kezdte használni a SOM helyett.
A VisualAge for Basic egyes verzióiban volt SOM-integráció [4] . Ezenkívül az OpenDoc disztribúciójában szereplő Lotus Script az OpenDoc Direct Scripting (ODDS) révén SOM objektumokkal is tud dolgozni [5] .
A SOMObjects Java Clientben [6] csak távolról, DSOM-on keresztül lehetett SOM objektumokat hívni. A demópéldában olyan osztályok voltak, amelyeket elérhetővé tettek a DSOM-kiszolgálón, majd a Java kisalkalmazást egy internetes erőforráson tárolták, távoli objektumokat hoztak létre, és meghívták metódusaikat. Helyi metódushívás nem biztosított.
A Virtual Pascalhoz való emittereket egy magánszemély fejlesztette ki, később Free Pascal-ra [7] portolták (csak OS/2). Lehetővé teszik metódusok meghívását és saját osztályok létrehozását.
A SOMIRIMP.exe [8] (csak Windows esetén), a SOM.IR bináris adatbázis Delphi-kötésekbe való importálója, egy másik személy önállóan fejlesztette ki. Lehetővé teszi metódusok meghívását, de osztályok létrehozását nem. A korábbi C-ben megvalósított emitterrel ellentétben a SOMIRIMP Delphiben íródott, és saját generált összerendeléseket használ.
A PowerAda fordító fejlesztői emittereket [9] és példákat készítettek a SOM használatára. A PowerAda csak AIX rendszeren volt elérhető, és a kibocsátóhoz SOM 3.0 Beta szükséges, szintén AIX rendszerhez. A SOM 3.0 for AIX elveszett.
A Canterbury Modula-2 for OS/2 az Oberon-2-höz hasonló objektumorientált kiterjesztéssel rendelkezik, és a professzionális verzióban támogatta a Direct-to-SOM fordítási módot. [tíz]
Az Oberon Microsystems bejelentette a Direct-to-SOM támogatását a Mac OS Classic rendszeren, de ennek a projektnek az állapota nem ismert. [tizenegy]
A SOM fejlesztése általában a következőképpen zajlik:
Fogyasztói módban:
A fejlesztő a SOM fordítót a kívánt programozási nyelv emitterével futtatja, megadva, hogy a kívánt könyvtár mely IDL fájljaihoz kapcsolódjon. Például:
sc -sada somcm.idl
Az emitter egy vagy több fájlt hoz létre olyan formátumban, amelyet a kiválasztott programozási nyelv fordítója megért. Ezen fájlok segítségével lehetővé válik a leírt osztályok objektumai létrehozása és metódusaik meghívása.
Termelői módban:
A fejlesztő megírja saját .idl fájljait, amelyek #tartalmazzanak más .idl fájlokat, és öröklik a többi .idl fájlban leírt osztályokból. Ezután a fejlesztő egy speciális kibocsátót futtat, amely fájlokat hoz létre segédkóddal és fájlokat az osztálymetódusok üres megvalósításával.
Például:
sc -sih animals.idl
sc -sc animals.idl
Az első hívás létrehozza az animals.ih-t, amely tartalmazni fogja például az Animals_AnimalNewClass implementációját, amely a somBuildClass2-t futtatja, átadva neki az .idl bemenetből szintetizált összetett struktúrát. Ezen a híváson kívül ez a fájl tartalmazza magát ezt a struktúrát és néhány további segédelemet, amelyeket a fejlesztőnek egyáltalán nem szabad megváltoztatnia. A második hívás létrehozza az animals.c fájlt üres metódusmegvalósításokkal. Az IBM C és C++ kibocsátói fokozatosan működhetnek, üres új metódusokat adva hozzá anélkül, hogy megérintenék a meglévő metódusok kódját.
Ezen kívül vannak emitterek a .dll fájl létrehozásához. Az IMOD-kibocsátó a fő .dll-függvényt, a DEF-kibocsátó pedig a .def és a .nid fájlokat szintetizálja.
Az emitter egy emit*.dll nevű könyvtár, ahol a * a SOM fordító -s argumentumának egy opciója. A könyvtárnak exportálnia kell egy emit (SOM 2.1) vagy emitSL (SOM 3.0) eljárást, amely a SOM fordítóból való meghívásakor a kiválasztott emitterre jellemző munkát végez. A munka bármilyen lehet. Új emitterek létrehozásához van egy newemit szkript.
Az emitterek közé tartozik egy infravörös sugárzó, amely létrehozza vagy frissíti a SOM.IR bináris adatbázist. Ez az adatbázis ezután megnyitható az Interface Repository Framework segítségével. Ezt leggyakrabban távoli eljáráshívásokhoz és dinamikus programozási nyelvekhez használják. Így működik a VisualAge SOMSupport for Smalltalk és az ObjectREXX.
Ezenkívül az OpenDoc szabvány magában foglalja az OpenDoc Direct Scriptinget (ODDS), és az ODScriptComponent interfészt megvalósító szkriptnyelv-tolmácsok ezáltal hozzáférhetnek a SOM osztályokhoz az ODDS-en keresztül. Ilyen programozási nyelv például a Lotus Script, amely az OpenDoc-hoz tartozik [5] .
A SOM.IR adatbázis használható kötések létrehozására is lefordított programozási nyelvekhez [12] .
A Novell kifejlesztett egy hidat, amely elérhetővé teszi a SOM objektumokat az OLE Automationt támogató nyelvekről. Ezenkívül a Novell ComponentGlue lehetővé teszi az OLE vagy OpenDoc technológiát használó alkalmazások számára, hogy más technológiával készült összetevőket használjanak, valamint az OpenDoc részt OLE (OCX) komponensként csomagolják. Ez a ctypelib segédprogramot használja . A segédprogram használatakor a fordítás során nem jön létre programkód. Ugyanaz az OpenDoc DLL van regisztrálva a rendszerleíró adatbázisban, amely képes betölteni a SOM-könyvtárat a memóriába, és virtuális metódustáblákat, ugródeszkákat és egyéb, futás közbeni proxy COM-objektumokhoz szükséges elemeket létrehozni. A ComponentGlue általában csak az IDispatch interfészt valósítja meg, de a dolgok felgyorsítása érdekében lehetőség van saját COM interfész deklarálására és megvalósítására, ha a SOM interfészt az ODdual módosítóval jelöli meg , és megfelel az OLE interfészek összes szabályának.
A SOM és a COM integrálásának másik eszköze az emitcom segédprogram , amely COM-burkolókat hoz létre a SOM osztályokhoz C++ nyelven. Az emitcom bekerült a SOM 3.0 bétaverziójába (1996. február), de a SOM 3.0 kiadásba (1996. december), sok más szolgáltatáshoz hasonlóan nem.
Meg kell azonban jegyezni, hogy mivel a COM semmit sem tesz a rideg alaposztály problémájának megoldására, óvakodni kell az ilyen hidaktól. Az emitcom által gyártott COM wrapperek megfelelnek az osztály interfész nuggetjének a létrehozáskor, és az interfész megváltozásakor a burkolók új verzióit kell létrehozni új COM interfész GUID-okkal, amelyek továbbra is támogatják a régi wrapper verziók COM interfészeit. . A ctypelib segédprogram által generált COM interfészek az ODdual módosítóval jelölt SOM osztályokhoz nem használhatók lefordított programozási nyelvekből, mert egy ilyen interfész alacsony szintű reprezentációja nem stabil. A ctypelib általában felülírja a COM-típuskönyvtárat, és nincs lehetőség egy interfész több különböző verziójának párhuzamos karbantartására.
Amikor emittereket használunk olyan lefordított programozási nyelvekben, mint például a C++, a C++ emitter azt a látszatot kelti, hogy a SOM osztály egy C++ osztály. A somInit a szabványos konstruktorra, a somAssign pedig az operator=-re van leképezve. Osztályaik megvalósítása során azonban az .idl írása kap főszerepet, és a metódusok megvalósítása nem úgy néz ki, mint az osztálymetódusok megvalósítása. A fájlok frissítéséhez folyamatosan hívnia kell a SOM fordítót. A SOM-ról kiderül, hogy valami idegen az olyan programozási nyelvektől, amelyek fordítói nem rendelkeznek beépített SOM-támogatással.
A Direct-to-SOM C++ fordító szükségtelenné teszi az .idl fájlok írását. Az .idl fájlok a C++ DTS fejlécfájlok alapján jönnek létre, nem pedig fordítva. Így a DTS C++ fordítója teljes, homogén fejlesztői környezetet biztosít, amivel mindent egy nyelven írhatunk. A som.dll-lel való munkavégzés DTS C++-ban hasonló az Objc.dll-lel az Objective-C-ben.
Kibocsátókra továbbra is szükség van, de csak harmadik féltől származó könyvtárak importálásához. A Microsoft C++ képes #import <valami.tlb> írására. Ugyanezt meg lehetett tenni az IDL-lel DTS C++-ban, de ez nem valósult meg. Ehelyett egy emittert kell alkalmaznia, amely létrehozza a DTS C++ fordító által igényelt .hh fájlokat. A DTS C++ fordító támogatja a normál C++ osztályokat és a SOMObjecttől öröklődő SOM osztályokat (kifejezetten vagy implicit módon, #pragma SOMAsDefault (be) értékkel). Egy másik hibridhez, az Objective-C++-hoz hasonlóan a különböző hierarchiákból származó osztályok keverésének lehetősége korlátozott.
A Direct-to-SOM C++ a MetaWare High C++-ban jelent meg, majd később a VisualAge C++-ban is megkettőződött, ráadásul ezek az implementációk nem is közvetlenül kompatibilisek, csak .idl-be való importálás/exportálás révén. A "Putting Metaclasses to Work" című könyvben a DTS C ++ egy másik, harmadik ismert dialektusát írták le, amelynek fordítója még nem létezik.
Létezik a SOM - somFree [13] nyílt megvalósítása . A projekt bináris kompatibilitást követel az IBM eredeti megvalósításával. A Netlabs.org fenntart egy NOM-megvalósítást, amely SOM-elveken alapul, de nem kompatibilis sem a forrás-, sem a bináris fájlokkal.
| OS/2 összetevők és API -k | |
|---|---|
| Fő | |
Menedzsment szolgáltatások | |
| Játékok |
|
| OS kernel | |
| Fájlrendszerek | |
| Grafikai alrendszer |
|
| Objektummodell | SOM
|
| Kompatibilitás |
|