Model obiektowy systemu IBM

Nie mylić z System Object Model (format pliku) .
IBM SOMobjects
Deweloperzy IBM
Wersja stabilna
3.0 / grudzień 1996
System operacyjny OS/2 , Windows , AIX , Klasyczny Mac OS , Copland , OS/390 , NonStop OS , OS/400
Typ zorientowany obiektowo system bibliotek współdzielonych

W informatyce System Object Model ( SOM ) to zorientowany obiektowo system bibliotek współdzielonych opracowany przez IBM . DSOM , rozproszona wersja oparta na CORBA , umożliwiała komunikację obiektów na różnych komputerach.

SOM definiuje interfejs między programami lub między bibliotekami a programami, dzięki czemu interfejs obiektu jest oddzielony od jego implementacji. SOM pozwala definiować klasy obiektów w jednym języku programowania i używać ich w innym, a także umożliwia aktualizowanie bibliotek takich klas bez konieczności ponownej kompilacji kodu klienta.

Biblioteka SOM składa się z zestawu klas, metod, funkcji statycznych i składowych danych. Programy korzystające z biblioteki SOM mogą tworzyć obiekty typów zdefiniowanych w bibliotece, używać metod zdefiniowanych dla typu obiektu i wyprowadzać podklasy z klas SOM, nawet jeśli język programu uzyskującego dostęp do biblioteki SOM nie obsługuje wpisywania klas. Biblioteka SOM i programy korzystające z obiektów i metod tej biblioteki nie muszą być napisane w tym samym języku programowania. SOM minimalizuje również wpływ poprawek na biblioteki. Jeśli biblioteka SOM zostanie zmieniona w celu dodania nowych klas lub metod lub zmiany wewnętrznej implementacji klas lub metod, nadal można uruchomić program korzystający z tej biblioteki bez ponownej kompilacji. Nie dotyczy to wszystkich innych C++ , które w niektórych przypadkach wymagają ponownej kompilacji wszystkich programów, które ich używają, po każdej zmianie bibliotek, znane jako problem delikatnego interfejsu binarnego .

SOM zapewnia interfejs programowania aplikacji (API), który zapewnia programom dostęp do informacji o klasie SOM lub obiekcie SOM. Każda klasa SOM dziedziczy zestaw metod wirtualnych, których można użyć na przykład do znalezienia nazwy klasy obiektu lub do określenia, czy dana metoda jest dostępna dla obiektu.

Aplikacje

SOM miał być używany powszechnie, od komputerów typu mainframe IBM aż po komputer stacjonarny w systemie OS/2 , umożliwiając pisanie programów, które działały na komputerze stacjonarnym, ale wykorzystywały komputery typu mainframe do przetwarzania i przechowywania danych. IBM wyprodukował wersje SOM / DSOM dla OS / 2, Microsoft Windows i różnych odmian Uniksa (zwłaszcza własnego AIX ). Przez jakiś czas po utworzeniu sojuszu AIM , SOM/DSOM był również używany przez Apple Computer do podobnych celów. Był w nich najczęściej używany OpenDoc , ale miał również ograniczone zastosowanie w innych rolach.

Być może najbardziej rozpowszechnione zastosowania SOM w IBM miały miejsce w późniejszych wersjach OS/2, w których używano go w większości kodu, w tym w powłoce Workplace Shell . Obiekt REXX dla OS/2 może obsługiwać klasy i obiekty SOM, w tym WPS.

SOMobjects nie zostały całkowicie zamknięte przez IBM. Zostały one przeniesione do systemu OS/390 i nadal są dostępne w tym systemie operacyjnym. Dokumentację można przeczytać na stronie IBM. W 1996 roku firma Tandem Computers Inc. uzyskała technologię SOMobjects. Tandem został sprzedany firmie Compaq, Compaq został sprzedany firmie Hewlett-Packard. NonStop DOM i niektóre inne technologie ostatecznie połączyły się w NonStop CORBA, ale obecna dokumentacja produktów NonStop nie zawiera oznak technologii SOM, która nadal napędza produkty NonStop.

Zanikanie

Wraz ze „śmiercią” OS / 2 w połowie lat 90. raison d'être dla SOM / DSOM w dużej mierze zniknęła; gdyby użytkownicy nie korzystali z systemu OS/2 na pulpicie, i tak nie byłoby uniwersalnej biblioteki obiektów. W 1997 roku, kiedy Steve Jobs wrócił do Apple i zakończył wiele prac programistycznych, w tym Copland i OpenDoc , SOM został zastąpiony przez Objective-C, który był już używany w OPENSTEP (aby później stać się Mac OS X). Rozwój SOM / DSOM wyblakł i nie jest już aktywnie rozwijany, chociaż nadal jest dołączany i używany w systemach opartych na OS / 2, takich jak ArcaOS .

Pomimo skutecznej śmierci OS/2 i OpenDoc, SOM może mieć jeszcze jedną niszę: Windows i programowanie międzyplatformowe . SOM 3.0 dla WinNT był ogólnie dostępny w grudniu 1996 roku. Powody braku postępu w tych kierunkach wykraczają poza problemy z przyjęciem na rynek. Wiążą się z szansami, które przegapił IBM i destrukcyjnymi, niekompatybilnymi zmianami:

  • Pierwsza wersja VisualAge C++ dla Windows to 3.5. Była to pierwsza i ostatnia wersja obsługująca SOM. Miał dołączony SOM 2.1 i obsługę Direct-to-SOM w kompilatorze. Wersje 3.6.5 i nowsze nie miały śladu SOM.
  • SOMobjects w dużej mierze opierał się na plikach makefile . VisualAge C++ 4.0 wprowadził projekty .icc i usunął kompilator i linker wiersza poleceń icc.exe i ilink.exe z dostaw. Niemożliwe jest zbudowanie dowolnej próbki SOM DTK z VAC++ 4.0. VisualAge C++ zawiera własne próbki, ale nie ma próbek .icc SOM nawet w VAC++ 4.0 dla OS/2. vacbld.exe, jedyne narzędzie do kompilacji wiersza poleceń, nie obsługuje SOM.
  • VisualAge C++ dołączona do pakietu Object Component Library (OCL) nie była oparta na SOM. Prawdopodobnie miał być przeportowany do SOM przy użyciu trybu C++ Direct-to-SOM, ale w VAC v3.6.5 ten tryb został porzucony, a OCL nie ma jak dotąd interfejsu SOM.
  • Pod koniec lat 90. IBM zamknął witryny pobierania SOMobjects i nigdy nie umieścił ich ponownie w Internecie. SOM 3.0 DTK dla WinNT nie można znaleźć na IBM FTP, pomimo wielu innych starszych rzeczy leżących swobodnie. Pomimo ogólnej dostępności SOM 3.0 dla WinNT, jego zlokalizowanie było prawie niemożliwe do końca 2012 roku.
  • Wreszcie, IBM nigdy nie udostępnił SOM typu open source (jak to zrobiono w przypadku Object REXX ), pomimo kilku artykułów i petycji.

Alternatywne implementacje

Istnieją dwa projekty implementacji SOM typu open source. Jednym z nich jest Netlabs Object Model (NOM), który jest technicznie taki sam, ale niekompatybilny binarnie. Innym jest somFree, który jest IBM SOM do pomieszczeń czystych i jest kompatybilny z formatem binarnym. [ potrzebne źródło ]

Porównanie obsługi skompilowanych bibliotek klas

Component Object Model (COM) firmy Microsoft przez IBM. Jednak z niektórych punktów widzenia w ogóle nie ma miejsca na COM. Z punktu widzenia transformacji wydania do wydania, COM jest na poziomie proceduralnym, dlatego tabela 1 w artykule RRBC ( Release-to-Release Binary Compatibility, o którym mowa wcześniej) nie zawiera w ogóle kolumny COM. Zamiast tego SOM jest porównywany do:

Większość informacji w tej tabeli nadal ma zastosowanie do nowoczesnych wersji (od 2015 r.), Z wyjątkiem Objective-C 2.0 otrzymującego tak zwane niekruche zmienne instancji. Niektóre rozwiązania pozostały eksperymentalne: SGI Delta/C++ czy Sun OBI. Większość podejść opartych na jednym języku programowania została wycofana lub nigdy nie była aktywnie wykorzystywana w ten sam sposób. Na przykład wtyczki przeglądarki Netscape Plugin Application Programming Interface ( NPAPI ) zostały napisane przy użyciu Java API początkowo (LiveConnect), ale Java Virtual Machine (JVM) została później wykluczona z łańcucha. Można to postrzegać jako zastąpienie Java przez Cross Platform Component Object Model ( XPCOM ). Common Lisp Object System (CLOS) i Smalltalk nie są znane jako ogniwa łańcucha, tak jak Java w LiveConnect. Objective-C jest również mało znany w tej roli i nie jest znany z tego, że jest sprzedawany w ten sposób, ale jego środowisko wykonawcze jest jednym z najbardziej przyjaznych dla podobnych przypadków użycia.

Generic C++ jest nadal używany w Qt i K Desktop Environment ( KDE ). Qt i KDE wyróżniają się tym, że opisują wysiłki podejmowane w celu utrzymania kompatybilności binarnej bez specjalnego wsparcia w narzędziach programistycznych.

GObject miał na celu jedynie uniknięcie zależności od kompilatora C++, ale problemy z RRBC są takie same jak w ogólnym C++.

Bez specjalnego środowiska uruchomieniowego wiele innych języków programowania będzie miało te same problemy, np. Delphi , Ada . Można to zilustrować tak zwanym bezprecedensowym podejściem zastosowanym do wyprodukowania Delphi 2006 zgodnego z formatem binarnym Wydanie Delphi 2007: Jak dodać „opublikowaną” właściwość bez przerywania kompatybilności z DCU

Objective-C jest najbardziej obiecującym konkurentem dla SOM (chociaż nie jest aktywnie sprzedawany jako platforma wielojęzyczna), a SOM powinien być raczej porównywany z Objective-C, w przeciwieństwie do COM, jak to miało miejsce w przeszłości. Dzięki niedelikatnym zmiennym instancji w Objective-C 2.0 jest to najlepsza alternatywa wśród aktywnie obsługiwanych.

COM , XPCOM są aktywnie używane, ale zarządzają tylko interfejsami, a nie implementacjami, a zatem nie są na tym samym poziomie co SOM, GObject i Objective-C . Środowisko wykonawcze systemu Windows przy bliższym przyjrzeniu się zachowuje się podobnie do modelu COM. Jego opis metadanych jest oparty na .NET, ale ponieważ WinRT nie zawiera specjalnego środowiska uruchomieniowego do rozwiązywania problemów RRBC, jak w Objective-C lub SOM, należało zastosować kilka ograniczeń, które ograniczają WinRT na poziomie proceduralnym:

System typów (C++/CX)

Klasa ref, która ma konstruktora publicznego, musi być zadeklarowana jako zapieczętowana, aby zapobiec dalszemu wyprowadzaniu.

Składniki środowiska wykonawczego systemu Windows — składniki środowiska wykonawczego systemu Windows w świecie platformy .NET

Kolejnym ograniczeniem jest to, że nie można ujawnić żadnych ogólnych klas publicznych ani interfejsów. Polimorfizm nie jest dostępny dla typów WinRT, a najbliższe, co można osiągnąć, to implementacja interfejsów WinRT; musisz zadeklarować jako zapieczętowane wszystkie klasy, które są publicznie udostępniane przez składnik środowiska wykonawczego systemu Windows.

Porównanie do COM

SOM jest podobny w koncepcji do COM. Oba systemy rozwiązują problem tworzenia standardowego formatu biblioteki, który można wywołać z więcej niż jednego języka. SOM można uznać za bardziej niezawodny niż COM. Model COM oferuje dwie metody uzyskiwania dostępu do metod obiektu, a obiekt może implementować jedną z nich lub obie. Pierwszy to dynamiczne i późne wiązanie ( IDispatch ) i jest neutralny językowo, podobnie jak to, co oferuje SOM. Drugi, zwany interfejsem niestandardowym, wykorzystuje tablicę funkcji, którą można zbudować w C, ale jest również bezpośrednio kompatybilna z binarnym układem wirtualnej tabeli obiektów C++ w kompilatorze C++ firmy Microsoft. Dzięki kompatybilnym kompilatorom C++ interfejsy niestandardowe można zatem zdefiniować bezpośrednio jako czysto wirtualne klasy C++. Wynikowy interfejs może być następnie wywoływany przez języki, które mogą wywoływać funkcje C za pomocą wskaźników. Niestandardowe interfejsy zamieniają solidność na wydajność. Po opublikowaniu interfejsu w wydanym produkcie nie można go zmienić, ponieważ aplikacje klienckie tego interfejsu zostały skompilowane z określonym binarnym układem tego interfejsu. To jest przykład tzw z delikatną klasą bazową , który może prowadzić do piekła DLL , ponieważ instalowana jest nowa wersja biblioteki współdzielonej i wszystkie programy oparte na starszej wersji mogą przestać działać poprawnie. Aby zapobiec temu problemowi, programiści COM muszą pamiętać, aby nigdy nie zmieniać interfejsu po jego opublikowaniu, a nowe interfejsy muszą zostać zdefiniowane, jeśli wymagane są nowe metody lub inne zmiany.

SOM zapobiega tym problemom, zapewniając tylko późne wiązanie, aby umożliwić konsolidatorowi czasu wykonywania ponowne zbudowanie tabeli w locie. W ten sposób zmiany w bazowych bibliotekach są rozwiązywane, gdy są ładowane do programów, chociaż wiąże się to z kosztami wydajności.

SOM jest również znacznie bardziej niezawodny pod względem pełnej obsługi szerokiej gamy języków OO. Podczas gdy podstawowy COM zasadniczo definiuje okrojoną wersję C++ do programowania, SOM obsługuje prawie wszystkie wspólne funkcje, a nawet niektóre bardziej ezoteryczne. Na przykład SOM obsługuje wielokrotne dziedziczenie , metaklasy i dynamiczne wysyłanie . Niektóre z tych funkcji nie występują w większości języków, co spowodowało, że większość systemów podobnych do SOM / COM była prostsza kosztem obsługi mniejszej liczby języków. Pełna elastyczność obsługi wielu języków była jednak ważna dla IBM, ponieważ podjęto znaczne wysiłki w celu obsługi obu Smalltalk ( pojedyncze dziedziczenie i dynamiczna wysyłka ) z C++ ( wielokrotne dziedziczenie i stała wysyłka).

Najbardziej zauważalną różnicą między SOM i COM jest obsługa dziedziczenia — COM jej nie ma. Może wydawać się dziwne, że Microsoft stworzył system bibliotek obiektów, który nie mógł obsługiwać jednej z najbardziej podstawowych koncepcji programowania obiektowego; głównym tego powodem jest to, że trudno jest ustalić, gdzie istnieje klasa podstawowa w systemie, w którym biblioteki są ładowane w potencjalnie losowej kolejności. COM wymaga, aby programista określił dokładną klasę bazową w czasie kompilacji, co uniemożliwia wstawienie innych klas pochodnych w środku (przynajmniej w innych bibliotekach COM).

Zamiast tego SOM używa prostego algorytmu, szukając potencjalnych klas bazowych, podążając za drzewem dziedziczenia i zatrzymując się na pierwszej pasującej; jest to podstawowa idea dziedziczenia w większości przypadków. Wadą tego podejścia jest to, że możliwe jest, że nowe wersje tej klasy podstawowej mogą przestać działać, nawet jeśli interfejs API pozostanie taki sam. Taka możliwość istnieje w każdym programie, nie tylko korzystającym z biblioteki współdzielonej, ale problem może stać się bardzo trudny do wyśledzenia, jeśli istnieje w czyimś kodzie. W SOM jedynym rozwiązaniem jest szeroko zakrojone testowanie nowych wersji bibliotek, co nie zawsze jest łatwe.

Chociaż SOM i COM były przeciwstawiane przez IBM, nie wykluczały się wzajemnie. W 1995 roku Novell wniósł technologię ComponentGlue do OpenDoc dla Windows. Ta technologia zapewniła różne sposoby integracji komponentów opartych na COM i SOM. W szczególności obiekty SOM mogą być udostępniane aplikacjom OLE2 przez most późnego wiązania (oparty na IDispatch) lub interfejsy COM o wyższej wydajności. Zasadniczo klasy SOM implementują w ten sposób interfejsy COM.

Elastyczność oferowana przez SOM została uznana za wartą zachodu przez prawie wszystkich [ potrzebne źródło ] , ale podobne systemy, takie jak Distributed Objects Everywhere firmy Sun Microsystems , również obsługiwały pełne dziedziczenie. Przenośne rozproszone obiekty NeXT uniknęły tych problemów dzięki silnemu systemowi wersjonowania, umożliwiając autorom bibliotek dostarczanie nowych wersji wraz ze starymi, gwarantując w ten sposób kompatybilność wsteczną przy niewielkich kosztach miejsca na dysku.

Zobacz też

  1. ^ SOM and Object REXX autorstwa dr Willisa Boughtona (sierpień 2004)
  2. ^ SOMobjects dla dokumentacji OS/390
  3. ^ Tandem wykorzystuje technologię IBM SOMobjects do przetwarzania rozproszonych obiektów
  4. ^

      Ira R. Forman i Scott Danforth (1999). Wdrażanie metaklas do pracy . ISBN 0-201-43305-2 . Rozdział 11 „Zgodność plików binarnych między wydaniami”, strona 246 Artykuł o identycznej nazwie i podobnej treści tego samego autora można znaleźć w sieci Web: Zgodność plików binarnych między wydaniami
  5. ^ „Lista klas ArcaOS 5.0 WPS” . Źródło 2020-09-03 .
  6. ^ Zagubieni w ogrodzie , Roger Sessions (sierpień 1996)
  7. ^ Tylko mała rzecz SOM dla programistów Linuksa autorstwa Esther Schindler (luty 2008)
  8. ^ Ożywienie najlepszych OS / 2 na pulpicie Linux zarchiwizowane 17.04.2010 w Wayback Machine przez Stevena J. Vaughana-Nicholsa (luty 2008)
  9. ^ Petycja OS / 2 , druga runda (2007–2010)
  10. ^ Problemy ze zgodnością binarną z C++
  11. ^ ComponentGlue(tm) zapewnia pełną interoperacyjność z kontrolkami OLE i OCX

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=IBM_System_Object_Model&oldid=1121429193 ”