IBM System Object Model - IBM System Object Model

Nu trebuie confundat cu Modelul de obiecte de sistem (format de fișier) .
Obiecte IBM SOM
Sigla IBM SOM
Dezvoltatori IBM
Versiune stabila
3.0 / decembrie 1996
Sistem de operare OS / 2 , Windows , AIX , Mac OS clasic , Copland , OS / 390 , sistem de operare NonStop
Tip sistem de bibliotecă partajată orientat obiect

În calcul, Modelul de obiect sistem ( SOM ) este un sistem de bibliotecă partajată orientat pe obiecte dezvoltat de IBM . DSOM , o versiune distribuită bazată pe CORBA , a permis obiectelor de pe diferite computere să comunice.

SOM definește o interfață între programe sau între biblioteci și programe, astfel încât interfața unui obiect să fie separată de implementarea sa. SOM permite definirea claselor de obiecte într-un limbaj de programare și utilizarea în altul și permite actualizarea bibliotecilor acestor clase fără a fi necesară recompilarea codului clientului.

O bibliotecă SOM constă dintr-un set de clase, metode, funcții statice și membri de date. Programele care utilizează o bibliotecă SOM pot crea obiecte de tipurile definite în bibliotecă, pot folosi metodele definite pentru un tip de obiect și pot deriva subclasele din clasele SOM, chiar dacă limbajul programului care accesează biblioteca SOM nu acceptă tastarea clasei. O bibliotecă SOM și programele care utilizează obiecte și metode ale bibliotecii respective nu trebuie să fie scrise în același limbaj de programare. SOM minimizează, de asemenea, impactul reviziilor asupra bibliotecilor. Dacă o bibliotecă SOM este modificată pentru a adăuga noi clase sau metode sau pentru a schimba implementarea internă a claselor sau metodelor, se poate rula în continuare un program care folosește acea bibliotecă fără recompilare. Acest lucru nu este cazul pentru toate celelalte biblioteci C ++ , care, în unele cazuri, necesită recompilarea tuturor programelor care le folosesc ori de câte ori bibliotecile sunt schimbate, cunoscută sub numele de problema interfeței binare fragile .

SOM oferă o interfață de programare a aplicației (API) care oferă programelor acces la informații despre o clasă SOM sau un obiect SOM. Orice clasă SOM moștenește un set de metode virtuale care pot fi utilizate, de exemplu, pentru a găsi numele clasei unui obiect sau pentru a determina dacă o metodă dată este disponibilă pentru un obiect.

Aplicații

SOM a fost destinat să fie utilizat universal de la computerele mainframe IBM chiar până la desktop în OS / 2 , permițând să fie scrise programe care să ruleze pe desktop, dar să utilizeze mainframe pentru procesare și stocare a datelor. IBM a produs versiuni ale SOM / DSOM pentru OS / 2, Microsoft Windows și diverse arome Unix (în special AIX proprii IBM ). De ceva timp după formarea alianței AIM , SOM / DSOM a fost, de asemenea, utilizat de Apple Computer în scopuri similare. A fost cel mai utilizat în cadrul lor OpenDoc , dar a văzut o utilizare limitată și în alte roluri.

Poate că cele mai răspândite utilizări ale SOM în cadrul IBM au fost în versiunile ulterioare ale OS / 2, care l-au folosit pentru majoritatea codului, inclusiv Workplace Shell . Object REXX pentru OS / 2 este capabil să facă față claselor și obiectelor SOM, inclusiv WPS.

SOMobjects nu au fost închise complet de IBM. Au fost portate la OS / 390 și sunt încă disponibile pe acest sistem de operare. Se poate citi documentația pe site-ul IBM. În 1996 Tandem Computers Inc. a obținut tehnologia SOMobjects. Tandem a fost vândut către Compaq, Compaq a fost vândut către Hewlett-Packard. NonStop DOM și alte tehnologii au fuzionat în cele din urmă în NonStop CORBA, dar documentația actuală a produselor NonStop nu conține semne ale tehnologiei SOM care alimentează încă produsele NonStop.

A se sterge

Odată cu „moartea” OS / 2 la mijlocul anilor 1990, rațiunea de a fi pentru SOM / DSOM a dispărut în mare măsură; dacă utilizatorii nu ar rula OS / 2 pe desktop, oricum nu ar exista o bibliotecă universală de obiecte. În 1997, când Steve Jobs s-a întors la Apple și a încheiat multe eforturi de dezvoltare, inclusiv Copland și OpenDoc , SOM a fost înlocuit cu Objective-C deja în uz în OPENSTEP (pentru a deveni Mac OS X mai târziu). Dezvoltarea SOM / DSOM a dispărut și nu mai este dezvoltată activ, deși continuă să fie inclusă și utilizată în sistemele bazate pe OS / 2, cum ar fi ArcaOS .

În ciuda morții efective a OS / 2 și OpenDoc, SOM ar putea avea încă o nișă: Windows și dezvoltarea pe mai multe platforme . SOM 3.0 pentru WinNT a fost în general disponibil în decembrie 1996. Motivele pentru care nu am avansat în aceste direcții depășesc problemele de adoptare a pieței. Acestea implică oportunități ratate de IBM și modificări incompatibile distructive:

  • Prima versiune a VisualAge C ++ pentru Windows a fost 3.5. A fost prima și ultima versiune care a acceptat SOM. Avea pachetul SOM 2.1 și suportul Direct-to-SOM în compilator. Versiunile 3.6.5 și ulterioare nu aveau nici o urmă de SOM.
  • SOMobjects s-a bazat în mare parte pe makefiles . VisualAge C ++ 4.0 a introdus proiectele .icc și a eliminat compilatorul și linker-ul icc.exe și ilink.exe din linia de comandă. Este imposibil să construiți orice probă SOM DTK din cutie cu VAC ++ 4.0. VisualAge C ++ vine cu propriile eșantioane, dar nu există eșantioane .IC SOM chiar și în VAC ++ 4.0 pentru OS / 2. vacbld.exe, singurul instrument de compilare a liniei de comandă, nu acceptă SOM.
  • VisualAge C ++ inclus în pachetul de obiecte (OCL) nu a fost bazat pe SOM. Probabil a fost menit să fie portat la SOM folosind modul Direct-to-SOM C ++, dar în VAC v3.6.5 acest mod a fost abandonat, iar OCL nu are interfață SOM până acum.
  • Aproape de sfârșitul anilor 1990, IBM a închis site-urile de descărcare SOMobjects și nu le-a pus niciodată înapoi online. SOM 3.0 DTK pentru WinNT nu poate fi găsit pe IBM FTP, în ciuda multor alte lucruri vechi care stau în jur în mod liber. În ciuda disponibilității generale a SOM 3.0 pentru WinNT, a fost aproape imposibil de localizat până la sfârșitul anului 2012.
  • În cele din urmă, IBM nu a deschis niciodată SOM open-source (așa cum se face la Object REXX ), în ciuda mai multor articole și petiții.

Implementări alternative

Există două proiecte de implementări SOM open-source. Unul este Netlabs Object Model (NOM), care este tehnic același, dar binar incompatibil. Un alt este somFree, care este un design de cameră curată al IBM SOM și compatibil cu binar.

Compararea suportului pentru bibliotecile de clase compilate

Din punct de vedere istoric, SOM a fost comparat cu Microsoft Component Object Model (COM) de către IBM. Cu toate acestea, din unele puncte de vedere, nu există deloc un loc pentru COM. Din punctul de vedere al transformărilor release to release, COM se află la nivel procedural, astfel, tabelul 1 din articolul RRBC ( Compatibilitatea binară Release-to-Release, menționat anterior) nu conține deloc coloana COM. În schimb, SOM este comparat cu:

Majoritatea informațiilor din acest tabel sunt încă aplicabile versiunilor moderne (începând cu 2015), cu excepția ca Objective-C 2.0 să obțină așa-numitele variabile de instanță non-fragile. Unele soluții au rămas experimentale: SGI Delta / C ++ sau Sun OBI. Majoritatea abordărilor bazate pe un limbaj de programare au fost eliminate treptat sau nu au fost niciodată utilizate în mod activ în același mod. De exemplu, pluginurile browserului Netscape Plugin Application Programming Interface ( NPAPI ) au fost scrise folosind inițial Java API (LiveConnect), dar Java Virtual Machine (JVM) a fost ulterior exclusă din lanț. Poate fi văzut ca Java înlocuit cu Modelul de obiecte componente cu platforme multiple ( XPCOM ). Common Lisp Object System (CLOS) și Smalltalk nu sunt cunoscute ca fiind verigi de lanț precum Java în LiveConnect. Obiectivul-C nu este cunoscut prea mult în acest rol și nu este cunoscut pentru a fi comercializat în acest fel, dar timpul său de rulare este unul dintre cele mai prietenoase cu cazuri de utilizare similare.

C ++ generic este încă utilizat în Qt și în mediul desktop K ( KDE ). Qt și KDE sunt remarcabile pentru descrierea eforturilor necesare pentru menținerea compatibilității binare fără suport special în instrumentele de dezvoltare.

GObject a avut ca scop doar evitarea dependenței de compilatorul C ++, dar problemele RRBC sunt aceleași ca în C ++ generic.

Fără un timp de rulare special, multe alte limbaje de programare vor avea aceleași probleme, de exemplu, Delphi , Ada . Poate fi ilustrat prin așa-numita abordare fără precedent necesară pentru a produce versiunea Delphi 2006 compatibilă binară Delphi 2007: Cum se adaugă o proprietate „publicată” fără a rupe compatibilitatea DCU

Objective-C este cel mai promițător concurent pentru SOM (deși nu este comercializat în mod activ ca platformă multi-limbă), iar SOM ar trebui, de preferință, comparat cu Objective-C spre deosebire de COM, așa cum sa întâmplat istoric. Cu variabilele de instanță non-fragile în Objective-C 2.0 este cea mai bună alternativă dintre cele acceptate activ.

COM , XPCOM sunt utilizate în mod activ, dar gestionează doar interfețe, nu implementări și, prin urmare, nu sunt la același nivel cu SOM, GObject și Objective-C . Windows Runtime sub o privire mai atentă se comportă la fel ca COM. Descrierea metadatelor sale se bazează pe .NET, dar din moment ce WinRT nu conține un timp de execuție special pentru rezolvarea problemelor RRBC, cum ar fi în Objective-C sau SOM, trebuiau aplicate mai multe restricții care limitează WinRT la nivel procedural:

Tip sistem (C ++ / CX)

O clasă ref care are un constructor public trebuie declarată sigilată, pentru a preveni derivarea ulterioară.

Componente Windows Runtime - Componente Windows Runtime într-o lume .NET

O altă restricție este că nu pot fi expuse clase sau interfețe publice generice. Polimorfismul nu este disponibil pentru tipurile WinRT, iar cel mai aproape puteți veni este implementarea interfețelor WinRT; trebuie să declarați sigilate orice clase expuse public de componenta dvs. Windows Runtime.

Comparație cu COM

SOM este similar ca concept cu COM. Ambele sisteme abordează problema producerii unui format de bibliotecă standard care poate fi apelat din mai multe limbi. SOM poate fi considerat mai robust decât COM. COM oferă două metode de accesare a metodelor pe un obiect, iar un obiect poate implementa fie una, fie ambele. Primul este obligatoriu dinamic și târziu ( IDispatch ) și este limbaj neutru similar cu ceea ce este oferit de SOM. A doua, numită interfață personalizată, folosește un tabel de funcții care poate fi încorporat în C, dar este, de asemenea, direct compatibil cu aspectul binar al tabelei virtuale a obiectelor C ++ din compilatorul Microsoft C ++. Cu compilatoarele C ++ compatibile, interfețele personalizate pot fi, prin urmare, definite direct ca clase C ++ virtuale pure. Interfața rezultată poate fi apoi apelată de limbi care pot apela funcții C prin pointeri. Interfețele personalizate comercializează robustețe pentru performanță. Odată ce o interfață este publicată într-un produs lansat, aceasta nu poate fi modificată, deoarece aplicațiile client ale acestei interfețe au fost compilate pe baza unui aspect binar specific al acestei interfețe. Acesta este un exemplu de problemă fragilă a clasei de bază , care poate duce la DLL , deoarece este instalată o nouă versiune a unei biblioteci partajate și toate programele bazate pe versiunea mai veche pot înceta să funcționeze corect. Pentru a preveni această problemă, dezvoltatorii COM trebuie să-și amintească să nu schimbe niciodată o interfață odată ce aceasta este publicată, iar interfețele noi trebuie definite dacă sunt necesare metode noi sau alte modificări.

SOM previne aceste probleme oferind doar legarea târzie, pentru a permite linker-ului de execuție să reconstruiască tabelul din mers. În acest fel, modificările aduse bibliotecilor subiacente sunt rezolvate atunci când sunt încărcate în programe, deși există un cost de performanță.

SOM este, de asemenea, mult mai robust în ceea ce privește sprijinirea completă a unei largi varietăți de limbi OO. În timp ce COM de bază definește în esență o versiune redusă a C ++ pentru a programa, SOM acceptă aproape toate caracteristicile comune și chiar unele mai ezoterice. De exemplu, SOM acceptă moștenirea multiplă , metaclasele și dispecerizarea dinamică . Unele dintre aceste caracteristici nu se găsesc în majoritatea limbilor, ceea ce a condus la majoritatea sistemelor de tip SOM / COM să fie mai simple cu prețul suportării unui număr mai mic de limbi. Cu toate acestea, flexibilitatea completă a suportului pentru mai multe limbi a fost importantă pentru IBM, întrucât au avut un efort major în desfășurare pentru a sprijini atât Smalltalk ( moștenire unică, cât și expediere dinamică ) cu C ++ ( moștenire multiplă și dispecerat fix ).

Cea mai notabilă diferență dintre SOM și COM este suportul pentru moștenire - COM nu are. Ar putea părea ciudat faptul că Microsoft a produs un sistem de bibliotecă de obiecte care nu putea suporta unul dintre cele mai fundamentale concepte ale programării OO; principalul motiv pentru aceasta este că este dificil să se știe unde există o clasă de bază într-un sistem în care bibliotecile sunt încărcate într-o ordine potențial aleatorie. COM solicită programatorului să specifice clasa de bază exactă la momentul compilării, făcând imposibilă inserarea altor clase derivate în mijloc (cel puțin în alte biblioteci COM).

SOM folosește în schimb un algoritm simplu, căutând clase de bază potențiale urmărind arborele moștenirii și oprindu-se la primul care se potrivește; aceasta este ideea de bază din spatele moștenirii în majoritatea cazurilor. Dezavantajul acestei abordări este că este posibil ca noile versiuni ale acestei clase de bază să nu mai funcționeze, chiar dacă API - ul rămâne același. Această posibilitate există în orice program, nu numai în cei care utilizează o bibliotecă partajată, dar o problemă poate deveni foarte dificil de depistat dacă există în codul altcuiva. În SOM, singura soluție este testarea extinsă a noilor versiuni de biblioteci, ceea ce nu este întotdeauna ușor.

În timp ce SOM și COM au fost contrapuse de IBM, acestea nu s-au exclus reciproc. În 1995, Novell a contribuit cu tehnologia ComponentGlue la OpenDoc pentru Windows. Această tehnologie a furnizat diferite mijloace de integrare între componentele bazate pe COM și SOM. În special, obiectele SOM pot fi puse la dispoziția aplicațiilor OLE2 fie prin punte de legare târzie (bazată pe IDispatch), fie prin interfețe COM cu performanțe mai mari. În esență, clasele SOM implementează astfel interfețe COM.

Flexibilitatea oferită de SOM a fost considerată merită de necazuri de aproape toți, dar sisteme similare, cum ar fi Sun Microsystems ' Distributed Objects Everywhere , au acceptat și moștenirea completă. Obiectele distribuite portabile ale NeXT au evitat aceste probleme printr-un sistem puternic de versionare, permițând autorilor bibliotecilor să livreze versiuni noi împreună cu cele vechi, garantând astfel compatibilitatea înapoi pentru costul redus al spațiului pe disc.

Vezi si

Referințe

  1. ^ SOM și Object REXX de Dr. Willis Boughton (august 2004)
  2. ^ SOMobjects pentru documentația OS / 390
  3. ^ Tandem valorifică tehnologia IBM SOMobjects pentru calculul obiectelor distribuite
  4. ^ Ira R. Forman și Scott Danforth (1999). Punerea la lucru a metaclaselor . ISBN 0-201-43305-2.
    Capitolul 11 ​​„Compatibilitate binară Release-to-Release”, pagina 246
    Un articol cu ​​nume identic și conținut similar al aceluiași autor poate fi găsit pe Web: Compatibilitate binară Release-to-Release
  5. ^ "Lista claselor ArcaOS 5.0 WPS" . Adus 03-09-2020 .
  6. ^ Lost in the Garden de Roger Sessions (august 1996)
  7. ^ Doar un mic lucru SOM pentru dezvoltatorii Linux de Esther Schindler (februarie 2008)
  8. ^ Reviving OS / 2's best in the Linux desktop Arhivat 17.04.2010 la Wayback Machine de Steven J. Vaughan-Nichols (februarie 2008)
  9. ^ Petiția OS / 2 , runda a doua (2007-2010)
  10. ^ Probleme de compatibilitate binară cu C ++
  11. ^ ComponentGlue (tm) Oferă interoperabilitate completă cu comenzile OLE, OCX

linkuri externe