IBM Systemobjektmodell - IBM System Object Model

Nicht zu verwechseln mit System Object Model (Dateiformat) .
IBM SOMobjects
IBM SOM-Logo
Entwickler IBM
Stabile Version
3.0 / Dezember 1996
Betriebssystem OS/2 , Windows , AIX , Klassisches Mac OS , Copland , OS/390 , NonStop OS
Typ objektorientiertes Shared-Library- System

In der Datenverarbeitung ist das System Object Model ( SOM ) ein objektorientiertes, gemeinsam genutztes Bibliothekssystem , das von IBM entwickelt wurde . DSOM , eine verteilte Version basierend auf CORBA , ermöglichte die Kommunikation von Objekten auf verschiedenen Computern.

SOM definiert eine Schnittstelle zwischen Programmen oder zwischen Bibliotheken und Programmen, sodass die Schnittstelle eines Objekts von seiner Implementierung getrennt ist. SOM ermöglicht es, Klassen von Objekten in einer Programmiersprache zu definieren und in einer anderen zu verwenden, und es ermöglicht die Aktualisierung von Bibliotheken solcher Klassen, ohne dass Clientcode neu kompiliert werden muss.

Eine SOM-Bibliothek besteht aus einer Reihe von Klassen, Methoden, statischen Funktionen und Datenelementen. Programme, die eine SOM-Bibliothek verwenden, können Objekte der in der Bibliothek definierten Typen erstellen, die für einen Objekttyp definierten Methoden verwenden und Unterklassen von SOM-Klassen ableiten, selbst wenn die Sprache des Programms, das auf die SOM-Bibliothek zugreift, die Klassentypisierung nicht unterstützt. Eine SOM-Bibliothek und die Programme, die Objekte und Methoden dieser Bibliothek verwenden, müssen nicht in derselben Programmiersprache geschrieben sein. SOM minimiert auch die Auswirkungen von Revisionen auf Bibliotheken. Wenn eine SOM-Bibliothek geändert wird, um neue Klassen oder Methoden hinzuzufügen oder um die interne Implementierung von Klassen oder Methoden zu ändern, kann ein Programm, das diese Bibliothek verwendet, immer noch ohne Neukompilierung ausgeführt werden. Dies ist bei allen anderen C++- Bibliotheken nicht der Fall , die in einigen Fällen eine Neukompilierung aller Programme erfordern, die sie verwenden, wenn die Bibliotheken geändert werden, was als fragiles Binärschnittstellenproblem bekannt ist .

SOM stellt eine Anwendungsprogrammierschnittstelle (API) bereit , die Programmen den Zugriff auf Informationen über eine SOM-Klasse oder ein SOM-Objekt ermöglicht. Jede SOM-Klasse erbt einen Satz virtueller Methoden, die beispielsweise verwendet werden können, um den Klassennamen eines Objekts zu finden oder zu bestimmen, ob eine bestimmte Methode für ein Objekt verfügbar ist.

Anwendungen

SOM sollte universell von IBMs Mainframe- Computern bis hinunter zum Desktop in OS/2 verwendet werden , um Programme zu schreiben, die auf dem Desktop laufen, aber Mainframes für die Verarbeitung und Datenspeicherung verwenden. IBM produzierte Versionen von SOM/DSOM für OS/2, Microsoft Windows und verschiedene Unix- Varianten (insbesondere IBMs eigenes AIX ). Einige Zeit nach der Gründung der AIM-Allianz wurde SOM/DSOM auch von Apple Computer für ähnliche Zwecke verwendet. Es wurde am häufigsten in ihrem OpenDoc- Framework verwendet, wurde jedoch auch in anderen Rollen nur eingeschränkt verwendet.

Die vielleicht am weitesten verbreitete Verwendung von SOM innerhalb von IBM war in späteren Versionen von OS/2, die es für den größten Teil des Codes verwendeten, einschließlich der Workplace Shell . Object REXX für OS/2 kann mit SOM-Klassen und -Objekten einschließlich WPS umgehen.

SOMobjects wurden von IBM nicht vollständig heruntergefahren. Sie wurden auf OS/390 portiert und sind auf diesem OS noch verfügbar. Die Dokumentation kann auf der IBM-Website gelesen werden. 1996 erwarb Tandem Computers Inc. die SOMobjects-Technologie. Tandem wurde an Compaq verkauft, Compaq wurde an Hewlett-Packard verkauft. NonStop DOM und einige andere Technologien wurden schließlich in NonStop CORBA fusioniert, aber die aktuelle Dokumentation von NonStop-Produkten enthält keine Anzeichen dafür, dass die SOM-Technologie noch immer NonStop-Produkte antreibt.

Verblassen

Mit dem „Tod“ von OS / 2 in der Mitte der 1990er Jahre, die raison d'être für SOM / DSOM weitgehend verschwunden; wenn Benutzer OS/2 nicht auf dem Desktop ausführen würden, gäbe es sowieso keine universelle Objektbibliothek. Als Steve Jobs 1997 zu Apple zurückkehrte und viele Entwicklungsbemühungen einschließlich Copland und OpenDoc beendete , wurde SOM durch Objective-C ersetzt, das bereits in OPENSTEP (später Mac OS X) verwendet wurde. Die SOM/DSOM-Entwicklung verblasste und wird nicht mehr aktiv weiterentwickelt, obwohl sie weiterhin in OS/2-basierten Systemen wie ArcaOS enthalten und verwendet wird .

Trotz des effektiven Todes von OS/2 und OpenDoc könnte SOM noch eine weitere Nische haben: Windows und plattformübergreifende Entwicklung. SOM 3.0 für WinNT war im Dezember 1996 allgemein verfügbar. Die Gründe für das Nichtvorankommen in diese Richtungen gehen über Markteinführungsprobleme hinaus. Sie beinhalten von IBM verpasste Chancen und destruktive inkompatible Änderungen:

  • Die erste Version von VisualAge C++ für Windows war 3.5. Es war die erste und letzte Version, die SOM unterstützte. Es hatte SOM 2.1 gebündelt und Direct-to-SOM-Unterstützung im Compiler. Versionen 3.6.5 und höher hatten keine Spur von SOM.
  • SOMobjects stützte sich weitgehend auf Makefiles . VisualAge C++ 4.0 führte .icc-Projekte ein und entfernte die Befehlszeilen-Compiler und -Linker icc.exe und ilink.exe aus dem Angebot. Es ist unmöglich, mit VAC++ 4.0 ein beliebiges SOM-DTK-Beispiel zu erstellen. VisualAge C++ wird mit eigenen Beispielen geliefert, aber selbst in VAC++ 4.0 für OS/2 gibt es keine .icc-SOM-Beispiele. vacbld.exe, das einzige Befehlszeilen-Kompilierungstool, unterstützt SOM nicht.
  • Die in VisualAge C++ enthaltene Object Component Library (OCL) basierte nicht auf SOM. Es sollte wahrscheinlich im C++ Direct-to-SOM-Modus auf SOM portiert werden, aber in VAC v3.6.5 wurde dieser Modus aufgegeben und OCL hat bisher keine SOM-Schnittstelle.
  • Gegen Ende der 1990er Jahre hat IBM SOMobjects-Download-Sites geschlossen und nie wieder online gestellt. SOM 3.0 DTK für WinNT kann auf IBM FTP nicht gefunden werden, trotz vieler anderer Legacy-Sachen, die frei herumliegen. Trotz allgemeiner Verfügbarkeit von SOM 3.0 für WinNT war es bis Ende 2012 kaum zu finden.
  • Schließlich hat IBM trotz mehrerer Artikel und Petitionen nie ein Open-Source-SOM (wie es bei Object REXX gemacht wurde ) bereitgestellt.

Alternative Implementierungen

Es gibt zwei Projekte von Open-Source-SOM-Implementierungen. Eines ist das Netlabs Object Model (NOM), das technisch gleich ist, aber binär inkompatibel. Ein anderer ist somFree, ein Reinraumdesign von IBM SOM und binärkompatibel.

Vergleich der Unterstützung für kompilierte Klassenbibliotheken

Historisch wurde SOM von IBM mit dem Component Object Model (COM) von Microsoft verglichen . Aus manchen Gesichtspunkten ist jedoch kein Platz für COM. Aus Sicht der Release-zu-Release-Transformationen befindet sich COM auf Verfahrensebene, daher enthält die Tabelle 1 im RRBC-Artikel ( Release-to-Release- Binärkompatibilität, auf die zuvor verwiesen wurde) überhaupt keine COM-Spalte. Stattdessen wird SOM verglichen mit:

Die meisten Informationen in dieser Tabelle gelten immer noch für moderne Versionen (Stand 2015), außer dass Objective-C 2.0 sogenannte nicht-fragile Instanzvariablen erhält. Einige Lösungen blieben experimentell: SGI Delta/C++ oder Sun OBI. Die meisten Ansätze, die auf einer Programmiersprache basierten, wurden ausgemustert oder nie in gleicher Weise aktiv genutzt. Zum Beispiel wurden Netscape Plugin Application Programming Interface ( NPAPI ) Browser-Plugins ursprünglich mit Java API (LiveConnect) geschrieben, aber Java Virtual Machine (JVM) wurde später aus der Kette ausgeschlossen. Es kann als Java durch das Cross Platform Component Object Model ( XPCOM ) ersetzt werden. Common Lisp Object System (CLOS) und Smalltalk sind nicht als Kettenglieder bekannt wie Java in LiveConnect. Objective-C ist in dieser Rolle auch nicht viel bekannt und wird nicht auf diese Weise vermarktet, aber seine Laufzeit ist eine der freundlichsten für ähnliche Anwendungsfälle.

Generisches C++ wird immer noch in Qt und der K Desktop Environment ( KDE ) verwendet. Qt und KDE zeichnen sich dadurch aus, dass sie die Bemühungen beschreiben, die erforderlich sind, um die Binärkompatibilität ohne spezielle Unterstützung durch Entwicklungstools aufrechtzuerhalten.

GObject zielte nur darauf ab, die Abhängigkeit vom C++-Compiler zu vermeiden, aber RRBC-Probleme sind die gleichen wie in generischem C++.

Ohne spezielle Laufzeit werden viele andere Programmiersprachen die gleichen Probleme haben, zB Delphi , Ada . Dies kann durch einen so genannten beispiellosen Ansatz veranschaulicht werden, der erforderlich war , um die binärkompatible Delphi 2007-Version zu erstellen: So fügen Sie eine "veröffentlichte" Eigenschaft hinzu, ohne die DCU-Kompatibilität zu beeinträchtigen

Objective-C ist der vielversprechendste Konkurrent von SOM (obwohl es nicht aktiv als mehrsprachige Plattform vermarktet wird), und SOM sollte vorzugsweise mit Objective-C verglichen werden, im Gegensatz zu COM, wie es in der Vergangenheit geschah. Mit nicht-fragilen Instanzvariablen in Objective-C 2.0 ist es die beste Alternative unter den aktiv unterstützten.

COM , XPCOM werden aktiv genutzt, verwalten aber nur Schnittstellen, keine Implementierungen und sind somit nicht auf der gleichen Ebene wie SOM, GObject und Objective-C . Windows-Runtime verhält sich bei näherer Betrachtung ähnlich wie COM. Seine Metadatenbeschreibung basiert auf .NET, aber da WinRT keine spezielle Laufzeit zum Beheben von RRBC-Problemen enthält, wie in Objective-C oder SOM, mussten mehrere Einschränkungen angewendet werden, die WinRT auf prozeduraler Ebene einschränken:

Typsystem (C++/CX)

Eine Referenzklasse mit einem öffentlichen Konstruktor muss als versiegelt deklariert werden, um eine weitere Ableitung zu verhindern.

Windows-Runtime-Komponenten - Windows-Runtime-Komponenten in einer .NET-Welt

Eine weitere Einschränkung besteht darin, dass keine generischen öffentlichen Klassen oder Schnittstellen verfügbar gemacht werden können. Polymorphismus ist für WinRT-Typen nicht verfügbar, und Sie können am nächsten kommen, wenn Sie WinRT-Schnittstellen implementieren. Sie müssen alle Klassen als versiegelt deklarieren, die von Ihrer Windows-Runtime-Komponente öffentlich verfügbar gemacht werden.

Vergleich zu COM

SOM ähnelt im Konzept COM. Beide Systeme adressieren das Problem, ein Standardbibliotheksformat zu erzeugen, das aus mehr als einer Sprache aufgerufen werden kann. SOM kann als robuster angesehen werden als COM. COM bietet zwei Methoden für den Zugriff auf Methoden auf ein Objekt, und ein Objekt kann entweder eine von beiden oder beide implementieren. Die erste ist die dynamische und späte Bindung ( IDispatch ) und ist sprachneutral, ähnlich wie bei SOM. Das zweite, Custom Interface genannt, verwendet eine Funktionstabelle, die in C erstellt werden kann, aber auch direkt kompatibel mit dem binären Layout der virtuellen Tabelle von C++-Objekten in Microsofts C++-Compiler ist. Mit kompatiblen C++-Compilern können Custom Interfaces daher direkt als reine virtuelle C++-Klassen definiert werden. Die resultierende Schnittstelle kann dann von Sprachen aufgerufen werden, die C-Funktionen über Zeiger aufrufen können. Benutzerdefinierte Schnittstellen tauschen Robustheit gegen Leistung. Sobald eine Schnittstelle in einem freigegebenen Produkt veröffentlicht wurde, kann sie nicht mehr geändert werden, da Clientanwendungen dieser Schnittstelle gegen ein bestimmtes binäres Layout dieser Schnittstelle kompiliert wurden. Dies ist ein Beispiel für das fragile Basisklassenproblem , das zur DLL-Hölle führen kann , da eine neue Version einer gemeinsam genutzten Bibliothek installiert wird und alle Programme, die auf der älteren Version basieren, nicht mehr richtig funktionieren. Um dieses Problem zu vermeiden, müssen COM-Entwickler daran denken, eine Schnittstelle nach der Veröffentlichung niemals zu ändern, und neue Schnittstellen müssen definiert werden, wenn neue Methoden oder andere Änderungen erforderlich sind.

SOM verhindert diese Probleme, indem es nur eine späte Bindung bereitstellt, damit der Laufzeitlinker die Tabelle im laufenden Betrieb neu erstellen kann. Auf diese Weise werden Änderungen an den zugrunde liegenden Bibliotheken beim Laden in Programme aufgelöst, obwohl dies mit Leistungseinbußen verbunden ist.

SOM ist auch viel robuster in Bezug auf die vollständige Unterstützung einer Vielzahl von OO-Sprachen. Während grundlegendes COM im Wesentlichen eine abgespeckte Version von C++ zum Programmieren definiert, unterstützt SOM fast alle gängigen Funktionen und sogar einige esoterischere. So unterstützt SOM beispielsweise Mehrfachvererbung , Metaklassen und dynamisches Dispatching . Einige dieser Funktionen sind in den meisten Sprachen nicht vorhanden, was dazu geführt hat, dass die meisten SOM/COM-ähnlichen Systeme auf Kosten der Unterstützung von weniger Sprachen einfacher waren. Die volle Flexibilität der Mehrsprachenunterstützung war für IBM jedoch wichtig, da große Anstrengungen unternommen wurden, um sowohl Smalltalk ( einfache Vererbung als auch dynamische Verteilung ) mit C++ ( mehrfache Vererbung und feste Verteilung ) zu unterstützen.

Der bemerkenswerteste Unterschied zwischen SOM und COM ist die Unterstützung für die Vererbung – COM hat keine. Es mag seltsam erscheinen, dass Microsoft ein Objektbibliothekssystem entwickelt hat, das eines der grundlegendsten Konzepte der OO-Programmierung nicht unterstützen konnte; Der Hauptgrund dafür ist, dass es schwierig ist zu wissen, wo eine Basisklasse in einem System existiert, in dem Bibliotheken in einer potenziell zufälligen Reihenfolge geladen werden. COM verlangt, dass der Programmierer zur Kompilierzeit die genaue Basisklasse angibt, was es unmöglich macht, andere abgeleitete Klassen in der Mitte einzufügen (zumindest in anderen COM-Bibliotheken).

SOM verwendet stattdessen einen einfachen Algorithmus, der nach potentiellen Basisklassen sucht, indem es dem Vererbungsbaum folgt und bei der ersten passenden anhält; Dies ist in den meisten Fällen der Grundgedanke der Vererbung. Der Nachteil dieses Ansatzes besteht darin, dass neue Versionen dieser Basisklasse möglicherweise nicht mehr funktionieren, selbst wenn die API gleich bleibt. Diese Möglichkeit besteht in jedem Programm, nicht nur in solchen, die eine gemeinsam genutzte Bibliothek verwenden, sondern es kann sehr schwierig werden, ein Problem aufzuspüren, wenn es im Code einer anderen Person vorhanden ist. In SOM besteht die einzige Lösung darin, neue Versionen von Bibliotheken ausgiebig zu testen, was nicht immer einfach ist.

Obwohl SOM und COM von IBM gegensätzlich waren, schlossen sie sich nicht gegenseitig aus. 1995 steuerte Novell die ComponentGlue-Technologie zu OpenDoc für Windows bei. Diese Technologie bot verschiedene Möglichkeiten zur Integration zwischen COM- und SOM-basierten Komponenten. Insbesondere können SOM-Objekte OLE2-Anwendungen entweder durch eine späte Bindungsbrücke (basierend auf IDispatch) oder COM-Schnittstellen mit höherer Leistung zur Verfügung gestellt werden. Im Wesentlichen implementieren SOM-Klassen auf diese Weise COM-Schnittstellen.

Die Flexibilität von SOM angeboten wurde der Mühe wert von fast allen in Betracht gezogen, aber ähnliche Systeme wie Sun Microsystems ' Distributed Objects Überall , auch die volle Erbe unterstützt. Die Portable Distributed Objects von NeXT umgingen diese Probleme durch ein starkes Versionierungssystem, das es Bibliotheksautoren ermöglichte, neue Versionen zusammen mit den alten auszuliefern, wodurch Abwärtskompatibilität für den geringen Plattenplatzpreis garantiert wurde .

Siehe auch

Verweise

  1. ^ SOM und Object REXX von Dr. Willis Boughton (August 2004)
  2. ^ SOMobjects für OS/390-Dokumentation
  3. ^ Tandem nutzt die SOMobjects-Technologie von IBM für Distributed Object Computing
  4. ^ Ira R. Forman und Scott Danforth (1999). Metaklassen zum Laufen bringen . ISBN 0-201-43305-2.
    Kapitel 11 „Release-to-Release-Binärkompatibilität“, Seite 246
    Einen gleichnamigen Artikel mit ähnlichem Inhalt desselben Autors finden Sie im Web: Release-to-Release-Binärkompatibilität
  5. ^ "Liste der ArcaOS 5.0 WPS-Klassen" . Abgerufen 2020-09-03 .
  6. ^ Im Garten verloren von Roger Sessions (August 1996)
  7. ^ Nur ein kleines SOM-Ding für Linux-Entwickler von Esther Schindler (Februar 2008)
  8. ^ Das Beste von OS/2 auf dem Linux-Desktop wiederbeleben Archiviert 2010-04-17 auf der Wayback Machine von Steven J. Vaughan-Nichols (Februar 2008)
  9. ^ Die OS/2-Petition , zweite Runde (2007–2010)
  10. ^ Probleme mit der Binärkompatibilität mit C++
  11. ^ ComponentGlue(tm) bietet volle Interoperabilität mit OLE, OCX Controls

Externe Links