Modello a oggetti di sistema IBM - IBM System Object Model

Da non confondere con System Object Model (formato file) .
IBM SOMoggetti
Logo IBM SOM
Sviluppatore/i IBM
Rilascio stabile
3.0 / dicembre 1996
Sistema operativo OS/2 , Windows , AIX , Mac OS classico , Copland , OS/390 , NonStop OS
Tipo sistema di libreria condivisa orientato agli oggetti

In informatica, il System Object Model ( SOM ) è un sistema di librerie condivise orientato agli oggetti sviluppato da IBM . DSOM , una versione distribuita basata su CORBA , consentiva agli oggetti su computer diversi di comunicare.

SOM definisce un'interfaccia tra programmi, o tra librerie e programmi, in modo che l'interfaccia di un oggetto sia separata dalla sua implementazione. SOM consente di definire classi di oggetti in un linguaggio di programmazione e di utilizzarle in un altro e consente di aggiornare le librerie di tali classi senza richiedere la ricompilazione del codice client.

Una libreria SOM è costituita da un insieme di classi, metodi, funzioni statiche e membri dati. I programmi che utilizzano una libreria SOM possono creare oggetti dei tipi definiti nella libreria, utilizzare i metodi definiti per un tipo di oggetto e derivare sottoclassi dalle classi SOM, anche se la lingua del programma che accede alla libreria SOM non supporta la digitazione di classi. Una libreria SOM ei programmi che utilizzano oggetti e metodi di tale libreria non devono essere scritti nello stesso linguaggio di programmazione. SOM riduce inoltre al minimo l'impatto delle revisioni sulle librerie. Se una libreria SOM viene modificata per aggiungere nuove classi o metodi o per modificare l'implementazione interna di classi o metodi, è comunque possibile eseguire un programma che utilizza tale libreria senza ricompilare. Questo non è il caso di tutte le altre librerie C++ , che in alcuni casi richiedono la ricompilazione di tutti i programmi che le utilizzano ogni volta che le librerie vengono modificate, noto come problema dell'interfaccia binaria fragile .

SOM fornisce un'interfaccia di programmazione dell'applicazione (API) che fornisce ai programmi l'accesso alle informazioni su una classe SOM o un oggetto SOM. Qualsiasi classe SOM eredita un insieme di metodi virtuali che possono essere utilizzati, ad esempio, per trovare il nome della classe di un oggetto o per determinare se un determinato metodo è disponibile per un oggetto.

Applicazioni

SOM doveva essere utilizzato universalmente dai computer mainframe IBM fino al desktop in OS/2 , consentendo la scrittura di programmi che sarebbero stati eseguiti sul desktop ma avrebbero utilizzato i mainframe per l'elaborazione e l'archiviazione dei dati. IBM ha prodotto versioni di SOM/DSOM per OS/2, Microsoft Windows e varie versioni di Unix (in particolare AIX di IBM ). Per qualche tempo dopo la formazione dell'alleanza AIM , SOM/DSOM è stato utilizzato anche da Apple Computer per scopi simili. È stato più ampiamente utilizzato nel loro framework OpenDoc , ma ha visto un uso limitato anche in altri ruoli.

Forse gli usi più diffusi di SOM all'interno di IBM erano nelle versioni successive di OS/2, che lo utilizzavano per la maggior parte del codice, inclusa la Workplace Shell . L'oggetto REXX per OS/2 è in grado di gestire classi e oggetti SOM incluso WPS.

SOMobjects non è stato completamente chiuso da IBM. Sono stati portati su OS/390 e sono ancora disponibili su questo sistema operativo. È possibile leggere la documentazione sul sito Web IBM. Nel 1996 Tandem Computers Inc. ha ottenuto la tecnologia SOMobjects. Tandem è stata venduta a Compaq, Compaq è stata venduta a Hewlett-Packard. NonStop DOM e alcune altre tecnologie alla fine si sono fuse in NonStop CORBA, ma la documentazione attuale dei prodotti NonStop non contiene segni di tecnologia SOM che ancora alimenta i prodotti NonStop.

Scomparendo

Con la "morte" di OS/2 a metà degli anni '90, la ragion d'essere di SOM/DSOM è in gran parte scomparsa; se gli utenti non eseguissero OS/2 sul desktop, non ci sarebbe comunque alcuna libreria di oggetti universale. Nel 1997, quando Steve Jobs è tornato in Apple e ha concluso molti sforzi di sviluppo tra cui Copland e OpenDoc , SOM è stato sostituito con Objective-C già in uso in OPENSTEP (per diventare Mac OS X in seguito). Lo sviluppo di SOM/DSOM è sbiadito e non è più sviluppato attivamente, sebbene continui a essere incluso e utilizzato in sistemi basati su OS/2 come ArcaOS .

Nonostante l'effettiva morte di OS/2 e OpenDoc, SOM potrebbe avere un'altra nicchia: Windows e lo sviluppo multipiattaforma . SOM 3.0 per WinNT era generalmente disponibile nel dicembre 1996. Le ragioni per non avanzare in queste direzioni vanno oltre i problemi di adozione del mercato. Implicano opportunità perse da IBM e cambiamenti distruttivi incompatibili:

  • La prima versione di VisualAge C++ per Windows era la 3.5. È stata la prima e l'ultima versione a supportare SOM. Aveva SOM 2.1 in bundle e supporto Direct-to-SOM nel compilatore. Le versioni 3.6.5 e successive non avevano traccia di SOM.
  • SOMobjects si basava in gran parte sui makefile . VisualAge C++ 4.0 ha introdotto i progetti .icc e rimosso dalla fornitura il compilatore e il linker della riga di comando icc.exe e ilink.exe. È impossibile creare qualsiasi campione SOM DTK fuori dalla scatola con VAC++ 4.0. VisualAge C++ viene fornito con i propri esempi, ma non ci sono esempi SOM .icc anche in VAC++ 4.0 per OS/2. vacbld.exe, l'unico strumento di compilazione della riga di comando, non supporta SOM.
  • VisualAge C++ in bundle Object Component Library (OCL) non era basato su SOM. Probabilmente doveva essere portato su SOM utilizzando la modalità C++ Direct-to-SOM, ma in VAC v3.6.5 questa modalità è stata abbandonata e OCL non ha finora un'interfaccia SOM.
  • Verso la fine degli anni '90, IBM ha chiuso i siti di download di SOMobjects e non li ha più rimessi online. SOM 3.0 DTK per WinNT non può essere trovato su IBM FTP, nonostante molte altre cose legacy in giro liberamente. Nonostante la disponibilità generale di SOM 3.0 per WinNT, era quasi impossibile individuarlo fino alla fine del 2012.
  • Infine, IBM non ha mai reso SOM open source (come fatto per Object REXX ), nonostante diversi articoli e petizioni.

implementazioni alternative

Esistono due progetti di implementazioni SOM open source. Uno è Netlabs Object Model (NOM), che è tecnicamente lo stesso, ma binario incompatibile. Un altro è somFree, che è un design per camera bianca di IBM SOM e compatibile con il binario.

Confronto del supporto per le librerie di classi compilate

Storicamente, SOM è stato paragonato al Component Object Model (COM) di Microsoft di IBM. Tuttavia, da alcuni punti di vista, non c'è proprio posto per COM. Dal punto di vista delle trasformazioni da versione a versione, COM è a livello procedurale, quindi la tabella 1 nell'articolo RRBC ( Compatibilità binaria da versione a versione a cui si fa riferimento in precedenza) non contiene affatto la colonna COM. Invece, SOM viene paragonato a:

La maggior parte delle informazioni in questa tabella è ancora applicabile alle versioni moderne (a partire dal 2015), ad eccezione di Objective-C 2.0 che ottiene le cosiddette variabili di istanza non fragili. Alcune soluzioni sono rimaste sperimentali: SGI Delta/C++ o Sun OBI. La maggior parte degli approcci basati su un linguaggio di programmazione sono stati eliminati o non sono mai stati utilizzati attivamente allo stesso modo. Ad esempio, i plug-in del browser Netscape Plugin Application Programming Interface ( NPAPI ) sono stati scritti inizialmente utilizzando l'API Java (LiveConnect), ma in seguito Java Virtual Machine (JVM) è stato escluso dalla catena. Può essere visto come Java sostituito con Cross Platform Component Object Model ( XPCOM ). Common Lisp Object System (CLOS) e Smalltalk non sono noti come collegamenti a catena come Java in LiveConnect. Anche Objective-C non è molto conosciuto in questo ruolo e non è noto per essere commercializzato in questo modo, ma il suo runtime è uno dei casi d'uso più amichevoli per simili.

Il C++ generico è ancora utilizzato in Qt e nel K Desktop Environment ( KDE ). Qt e KDE sono noti per descrivere gli sforzi necessari per mantenere la compatibilità binaria senza un supporto speciale negli strumenti di sviluppo.

GObject mirava solo a evitare la dipendenza dal compilatore C++, ma i problemi RRBC sono gli stessi del C++ generico.

Senza un runtime speciale molti altri linguaggi di programmazione avranno gli stessi problemi, ad esempio Delphi , Ada . Può essere illustrato dal cosiddetto approccio senza precedenti adottato per produrre Delphi 2006 compatibile con i binari Versione Delphi 2007: come aggiungere una proprietà "pubblicata" senza interrompere la compatibilità con DCU

Objective-C è il concorrente più promettente di SOM (sebbene non sia attivamente commercializzato come piattaforma multilingua) e SOM dovrebbe preferibilmente essere paragonato a Objective-C anziché COM come è accaduto storicamente. Con variabili di istanza non fragili in Objective-C 2.0 è la migliore alternativa tra quelle supportate attivamente.

COM , XPCOM vengono utilizzati attivamente, ma gestiscono solo interfacce, non implementazioni, e quindi non sono allo stesso livello di SOM, GObject e Objective-C . Windows Runtime a uno sguardo più attento si comporta in modo molto simile a COM. La sua descrizione dei metadati è basata su .NET, ma poiché WinRT non contiene un runtime speciale per risolvere i problemi RRBC, come in Objective-C o SOM, è stato necessario applicare diverse restrizioni che limitano WinRT a livello procedurale:

Sistema di tipi (C++/CX)

Una classe ref che ha un costruttore pubblico deve essere dichiarata come chiusa, per evitare ulteriori derivazioni.

Componenti di Windows Runtime - Componenti di Windows Runtime in un mondo .NET

Un'altra restrizione è che non possono essere esposte classi o interfacce pubbliche generiche. Il polimorfismo non è disponibile per i tipi di WinRT e il più vicino possibile è implementare le interfacce WinRT; è necessario dichiarare come sigillate tutte le classi esposte pubblicamente dal componente Windows Runtime.

Confronto con COM

SOM è simile nel concetto a COM. Entrambi i sistemi affrontano il problema di produrre un formato di libreria standard che può essere chiamato da più di una lingua. SOM può essere considerato più robusto di COM. COM offre due metodi per accedere ai metodi su un oggetto e un oggetto può implementarne uno o entrambi. Il primo è l' associazione dinamica e tardiva ( IDispatch ) ed è indipendente dal linguaggio simile a quello offerto da SOM. La seconda, chiamata interfaccia personalizzata, utilizza una tabella di funzioni che può essere compilata in C ma è anche direttamente compatibile con il layout binario della tabella virtuale degli oggetti C++ nel compilatore C++ di Microsoft. Con i compilatori C++ compatibili, le interfacce personalizzate possono quindi essere definite direttamente come classi C++ virtuali pure. L'interfaccia risultante può quindi essere chiamata da linguaggi che possono chiamare funzioni C tramite puntatori. Le interfacce personalizzate scambiano robustezza per prestazioni. Una volta che un'interfaccia viene pubblicata in un prodotto rilasciato, non può essere modificata, poiché le applicazioni client di questa interfaccia sono state compilate rispetto a un layout binario specifico di questa interfaccia. Questo è un esempio del fragile problema della classe base , che può portare all'inferno delle DLL , poiché viene installata una nuova versione di una libreria condivisa e tutti i programmi basati sulla versione precedente possono smettere di funzionare correttamente. Per evitare questo problema, gli sviluppatori COM devono ricordarsi di non modificare mai un'interfaccia una volta pubblicata e devono essere definite nuove interfacce se sono necessari nuovi metodi o altre modifiche.

SOM previene questi problemi fornendo solo l'associazione tardiva, per consentire al linker di runtime di ricostruire la tabella al volo. In questo modo, le modifiche alle librerie sottostanti vengono risolte quando vengono caricate nei programmi, sebbene vi sia un costo in termini di prestazioni.

SOM è anche molto più robusto in termini di supporto completo di un'ampia varietà di linguaggi OO. Mentre il COM di base definisce essenzialmente una versione ridotta di C++ su cui programmare, SOM supporta quasi tutte le funzionalità comuni e anche alcune più esoteriche. Ad esempio, SOM supporta l'ereditarietà multipla , le metaclassi e l' invio dinamico . Alcune di queste funzionalità non si trovano nella maggior parte delle lingue, il che ha portato la maggior parte dei sistemi simili a SOM/COM a essere più semplici a costo di supportare meno lingue. La piena flessibilità del supporto multilingue era importante per IBM, tuttavia, poiché era in corso un grande sforzo per supportare sia Smalltalk ( ereditarietà singola e invio dinamico ) con C++ ( ereditarietà multipla e invio fisso ).

La differenza più notevole tra SOM e COM è il supporto per l'ereditarietà: COM non ne ha. Potrebbe sembrare strano che Microsoft abbia prodotto un sistema di librerie di oggetti che non potesse supportare uno dei concetti più fondamentali della programmazione OO; la ragione principale di ciò è che è difficile sapere dove esiste una classe base in un sistema in cui le librerie vengono caricate in un ordine potenzialmente casuale. COM richiede che il programmatore specifichi l'esatta classe di base in fase di compilazione, rendendo impossibile l'inserimento di altre classi derivate nel mezzo (almeno in altre librerie COM).

SOM utilizza invece un semplice algoritmo, cercando potenziali classi base seguendo l'albero dell'ereditarietà e fermandosi alla prima che corrisponde; questa è l'idea alla base dell'ereditarietà nella maggior parte dei casi. Lo svantaggio di questo approccio è che è possibile che le nuove versioni di questa classe base non funzionino più anche se l' API rimane la stessa. Questa possibilità esiste in qualsiasi programma, non solo in quelli che utilizzano una libreria condivisa, ma un problema può diventare molto difficile da rintracciare se esiste nel codice di qualcun altro. In SOM, l'unica soluzione è eseguire test approfonditi delle nuove versioni delle librerie, il che non è sempre facile.

Sebbene SOM e COM fossero contrapposti da IBM, non si escludevano a vicenda. Nel 1995 Novell ha contribuito con la tecnologia ComponentGlue a OpenDoc per Windows. Questa tecnologia ha fornito diversi mezzi per l'integrazione tra componenti basati su COM e SOM. In particolare, gli oggetti SOM possono essere resi disponibili alle applicazioni OLE2 tramite bridge di associazione tardiva (basato su IDispatch) o interfacce COM con prestazioni più elevate. In sostanza, le classi SOM implementano le interfacce COM in questo modo.

La flessibilità offerta da SOM è stato considerato degno la difficoltà da quasi tutti, ma sistemi simili, come ad esempio Sun Microsystems ' oggetti distribuiti ovunque , supportata anche piena eredità. I Portable Distributed Objects di NeXT hanno evitato questi problemi tramite un potente sistema di versioning, consentendo agli autori di librerie di distribuire nuove versioni insieme a quelle vecchie, garantendo così la retrocompatibilità per il piccolo costo dello spazio su disco.

Guarda anche

Riferimenti

  1. ^ SOM e Object REXX del Dr. Willis Boughton (agosto 2004)
  2. ^ SOMobjects per la documentazione di OS/390
  3. ^ Tandem sfrutta la tecnologia SOMobjects di IBM per il calcolo di oggetti distribuiti
  4. ^ Ira R. Forman e Scott Danforth (1999). Mettere al lavoro le metaclassi . ISBN 0-201-43305-2.
    Capitolo 11 "Compatibilità binaria da versione a versione", pagina 246
    Un articolo con nome identico e contenuti simili dello stesso autore può essere trovato sul Web: Compatibilità binaria da versione a versione
  5. ^ "Elenco delle classi WPS di ArcaOS 5.0" . Estratto 2020-09-03 .
  6. ^ Lost in the Garden di Roger Sessions (agosto 1996)
  7. ^ Solo una piccola cosa SOM per gli sviluppatori Linux di Esther Schindler (febbraio 2008)
  8. ^ Reviving OS/2's best in the Linux desktop Archiviato 2010-04-17 at the Wayback Machine da Steven J. Vaughan-Nichols (febbraio 2008)
  9. ^ La petizione OS/2 , secondo round (2007-2010)
  10. ^ Problemi di compatibilità binaria con C++
  11. ^ ComponentGlue(tm) fornisce completa interoperabilità con OLE, controlli OCX

link esterno