IBM システム オブジェクト モデル

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ
IBM SOM オブジェクト
開発者IBM
安定版リリース
3.0 / 1996 年 12 月
オペレーティング·システムOS/2WindowsAIXクラシック Mac OSコープランドOS/390ノンストップ OSOS/400
タイプオブジェクト指向の 共有ライブラリシステム

コンピューティングでは、System Object Model ( SOM ) は、IBMによって開発されたオブジェクト指向の 共有ライブラリシステムです。CORBAに基づく分散バージョンであるDSOMは、異なるコンピューター上のオブジェクトが通信できるようにしました。

SOM は、プログラム間、またはライブラリとプログラム間のインターフェイスを定義し、オブジェクトのインターフェイスがその実装から分離されるようにします。SOM を使用すると、オブジェクトのクラスをあるプログラミング言語で定義し、別のプログラミング言語で使用できます。また、クライアント コードを再コンパイルすることなく、そのようなクラスのライブラリを更新できます。

SOM ライブラリは、一連のクラス、メソッド、静的関数、およびデータ メンバーで構成されます。SOM ライブラリを使用するプログラムは、SOM ライブラリにアクセスするプログラムの言語がクラス型付けをサポートしていない場合でも、ライブラリで定義された型のオブジェクトを作成し、オブジェクト型に対して定義されたメソッドを使用し、SOM クラスからサブクラスを派生させることができます。SOM ライブラリと、そのライブラリのオブジェクトとメソッドを使用するプログラムは、同じプログラミング言語で作成する必要はありません。SOM はまた、ライブラリに対するリビジョンの影響を最小限に抑えます。SOM ライブラリを変更して新しいクラスやメソッドを追加したり、クラスやメソッドの内部実装を変更したりした場合でも、そのライブラリを使用するプログラムを再コンパイルせずに実行できます。これは、他のすべてのC++には当てはまりません。これは、ライブラリが変更されるたびに、ライブラリを使用するすべてのプログラムを再コンパイルする必要がある場合があり、脆弱なバイナリ インターフェイスの問題として知られています。

SOM は、プログラムが SOM クラスまたは SOM オブジェクトに関する情報にアクセスできるようにするアプリケーション プログラミング インターフェイス(API) を提供します。どの SOM クラスも、オブジェクトのクラス名を検索したり、特定のメソッドがオブジェクトで使用可能かどうかを判断したりするために使用できる一連の仮想メソッドを継承します。

アプリケーション

SOMは、IBM のメインフレームコンピュータからOS/2のデスクトップに至るまで普遍的に使用されることを意図しており、デスクトップ上で実行されるプログラムを作成でき、処理とデータ ストレージにはメインフレームを使用します。IBM は、OS/2、 Microsoft Windows、およびさまざまなUnixフレーバー (特に IBM 独自のAIX )用に SOM/DSOM のバージョンを作成しました。AIM アライアンスの形成後しばらくの間、SOM/DSOM はApple Computerでも同様の目的で使用されていました。OpenDocフレームワークで最も広く使用されていましたが、他の役割でも限られた使用しか見られませんでした。

おそらく、IBM 内で SOM が最も広く使用されたのは、OS/2 の新しいバージョンであり、Workplace Shellを含むほとんどのコードで SOM が使用されていました。Object REXX for OS/2 は、WPS を含む SOM クラスとオブジェクトを処理できます。[1]

SOMobjects は、IBM によって完全にはシャットダウンされませんでした。これらは OS/390 に移植され、この OS でも引き続き使用できます。IBM Web サイトでドキュメントを読むことができます。[2] 1996 年、Tandem Computers Inc. は SOMobjects テクノロジを取得しました。[3] Tandem は Compaq に売却され、Compaq は Hewlett-Packard に売却されました。NonStop DOM およびその他のいくつかのテクノロジは、最終的に NonStop CORBA に統合されましたが、NonStop 製品の現在のドキュメントには、SOM テクノロジが NonStop 製品を強化している兆候は含まれていません。

消えゆく

1990 年代半ばの OS/2 の「死」により、SOM/DSOM の存在理由はほとんどなくなりましたユーザーがデスクトップで OS/2 を実行していなければ、ユニバーサル オブジェクト ライブラリはありません。1997 年、Steve Jobsが Apple に戻り、CoplandOpenDocを含む多くの開発作業を終了したとき、SOM はOPENSTEP (後に Mac OS X になる)で既に使用されているObjective-C [4]に置き換えられました。SOM/DSOM の開発は衰退し、積極的に開発されることはなくなりましたが、ArcaOSなどの OS/2 ベースのシステムに組み込まれ、使用され続けています。[5]

OS/2 と OpenDoc が実質的に消滅したにもかかわらず、SOM にはさらに別のニッチが存在する可能性があります。それは、Windows とクロスプラットフォーム開発です。WinNT 用の SOM 3.0 は、1996 年 12 月に一般公開されました。これらの方向に進まない理由は、市場での採用の問題を超えています。それらには、 IBMが逃した機会[6]、および破壊的な互換性のない変更が 含まれます。

  • VisualAge C++ for Windows の最初のバージョンは 3.5 でした。SOM をサポートする最初で最後のバージョンです。SOM 2.1 がバンドルされており、コンパイラで Direct-to-SOM がサポートされていました。バージョン 3.6.5 以降には、SOM の痕跡はありませんでした。
  • SOMobjects は主にmakefileに依存していましたVisualAge C++ 4.0 では、.icc プロジェクトが導入され、icc.exe および ilink.exe コマンド ライン コンパイラとリンカーが供給から削除されました。VAC++ 4.0 では、SOM DTK サンプルをすぐにビルドすることはできません。VisualAge C++ には独自のサンプルが付属していますが、OS/2 用の VAC++ 4.0 にも .icc SOM サンプルはありません。唯一のコマンド ライン コンパイル ツールである vacbld.exe は、SOM をサポートしていません。
  • VisualAge C++ にバンドルされているオブジェクト コンポーネント ライブラリ (OCL) は、SOM に基づいていませんでした。おそらく、C++ Direct-to-SOM モードを使用して SOM に移植することを意図していましたが、VAC v3.6.5 ではこのモードは廃止され、OCL にはこれまでのところ SOM インターフェイスがありません。
  • 1990 年代の終わり頃、IBM は SOMobjects のダウンロード サイトを閉鎖し、オンラインに戻すことはありませんでした。WinNT 用の SOM 3.0 DTK は IBM の FTP で見つけることができません。WinNT 用の SOM 3.0 が一般に入手可能になったにもかかわらず、2012 年末まで見つけることはほとんど不可能でした。
  • 最後に、いくつかの記事[7] [8]と請願にもかかわらず、IBM は ( Object REXXに対して行われたように) SOM をオープンソース化することはありませんでした。[9]

代替実装

オープンソース SOM 実装の 2 つのプロジェクトが存在します。1 つは Netlabs Object Model (NOM) で、技術的には同じですが、バイナリ互換性がありません。もう 1 つは、IBM SOMのクリーン ルーム設計であり、バイナリ互換である somFreeです。[引用が必要]

コンパイル済みクラス ライブラリのサポートの比較

歴史的に、SOM は IBM によって Microsoft のコンポーネント オブジェクト モデル(COM) と比較されてきました。ただし、一部の観点からは、COM の場所がまったくありません。リリースからリリースへの変換の観点から見ると、COM は手続きレベルにあるため、RRBC 記事の表 1 (前述のリリースからリリースへのバイナリ互換性) には COM 列がまったく含まれていません。代わりに、SOM は次のものと比較されています。

この表のほとんどの情報は、Objective-C 2.0 がいわゆる非壊れやすいインスタンス変数を取得することを除いて、現在のバージョン (2015 年現在) にも適用できます。一部のソリューションは実験的なままでした: SGI Delta/C++ または Sun OBI。1 つのプログラミング言語に基づくほとんどのアプローチは段階的に廃止されるか、同じように積極的に使用されることはありませんでした。たとえば、Netscape Plugin Application Programming Interface ( NPAPI ) ブラウザー プラグインは、最初は Java API (LiveConnect) を使用して作成されましたが、Java 仮想マシン(JVM) は後にチェーンから除外されました。これは、Java が Cross Platform Component Object Model ( XPCOM )に置き換えられたものと見なすことができますCommon Lisp Object System (CLOS) と Smalltalk は、LiveConnect の Java のようなチェーン リンクとしては知られていません。Objective-Cもこの役割ではあまり知られておらず、このように販売されていることも知られていませんが、そのランタイムは同様のユース ケースに最も適したものの 1 つです。

Generic C++ は、 Qtおよび K デスクトップ環境 ( KDE )で引き続き使用されています。Qt と KDE は、開発ツールでの特別なサポートなしでバイナリ互換性を維持するために必要な努力を説明していることで有名です。[10]

GObjectは C++ コンパイラへの依存を回避することのみを目的としていましたが、RRBC の問題は一般的な C++ と同じです。

特別なランタイムがなければ、 DelphiAdaなど、他の多くのプログラミング言語でも同じ問題が発生しますこれは、Delphi 2006 バイナリ互換の Delphi 2007 リリースを作成するために取った、いわゆる前例のないアプローチによって説明できます。

Objective-Cは SOM の最も有望な競争相手です (ただし、多言語プラットフォームとして積極的に販売されているわけではありません)。SOM は、歴史的に発生した COM とは対照的に、Objective-C と比較する必要があります。Objective-C 2.0 の壊れにくいインスタンス変数では、積極的にサポートされている中で最良の代替手段です。

COMXPCOMは積極的に使用されていますが、実装ではなくインターフェイスのみを管理するため、 SOM 、 GObject、およびObjective-Cと同じレベルではありませんよく見ると、 Windows ランタイムは COM と同じように動作します。そのメタデータの記述は .NET に基づいていますが、WinRT には Objective-C や SOM のように RRBC の問題を解決するための特別なランタイムが含まれていないため、手続きレベルで WinRT を制限するいくつかの制限を適用する必要がありました。

型システム (C++/CX)

パブリック コンストラクターを持つ ref クラスは、さらなる派生を防ぐために、sealed として宣言する必要があります。

Windows ランタイム コンポーネント - .NET の世界における Windows ランタイム コンポーネント

もう 1 つの制限は、ジェネリック パブリック クラスまたはインターフェイスを公開できないことです。ポリモーフィズムは WinRT 型では使用できません。最も近いのは、WinRT インターフェイスを実装することです。Windows ランタイム コンポーネントによって公開されているすべてのクラスをシール済みとして宣言する必要があります。

COMとの比較

SOM の概念は COM に似ています。どちらのシステムも、複数の言語から呼び出すことができる標準ライブラリ形式を作成するという問題に対処しています。SOM は、COM よりも堅牢であると見なすことができます。COM はオブジェクトのメソッドにアクセスする 2 つの方法を提供し、オブジェクトはそれらのいずれかまたは両方を実装できます。1 つ目は、動的で遅延バインディング( IDispatch)、SOM が提供するものと同様に言語中立です。カスタム インターフェイスと呼ばれる 2 つ目は、C で作成できる関数テーブルを使用していますが、Microsoft の C++ コンパイラの C++ オブジェクトの仮想テーブルのバイナリ レイアウトと直接互換性があります。したがって、互換性のある C++ コンパイラを使用すると、カスタム インターフェイスを純粋な仮想 C++ クラスとして直接定義できます。結果として得られるインターフェイスは、ポインターを介して C 関数を呼び出すことができる言語によって呼び出すことができます。カスタム インターフェイスは、堅牢性とパフォーマンスのトレードオフです。このインターフェイスのクライアント アプリケーションは、このインターフェイスの特定のバイナリ レイアウトに対してコンパイルされているため、リリースされた製品でインターフェイスが公開されると、インターフェイスを変更することはできません。これは脆弱な基本クラスの問題の例であり、 DLL 地獄につながる可能性があります、共有ライブラリの新しいバージョンがインストールされ、古いバージョンに基づくすべてのプログラムが正常に機能しなくなる可能性があるためです。この問題を回避するために、COM 開発者は、公開されたインターフェイスを決して変更しないように注意する必要があります。また、新しいメソッドやその他の変更が必要な場合は、新しいインターフェイスを定義する必要があります。

SOM は、実行時リンカーがその場でテーブルを再構築できるように、遅延バインディングのみを提供することでこれらの問題を防ぎます。このように、基礎となるライブラリーへの変更は、プログラムにロードされるときに解決されますが、パフォーマンス コストはかかります。

また、SOM は、さまざまな OO 言語を完全にサポートするという点で、はるかに堅牢です。基本的な COM は基本的に、プログラミング対象の C++ の簡易バージョンを定義しますが、SOM はほとんどすべての一般的な機能をサポートし、いくつかの難解な機能もサポートします。たとえば、SOM は多重継承メタクラス動的ディスパッチをサポートしています。これらの機能のいくつかは、ほとんどの言語には見られないため、ほとんどの SOM/COM のようなシステムは、サポートする言語が少なくなるという犠牲を払って単純化されました。多言語サポートの完全な柔軟性は、IBM にとって重要でした。IBM はC++でSmalltalk (単一継承動的ディスパッチ)の両方をサポートするための主要な取り組みを進めていたからです。多重継承固定発送)。

SOM と COM の最も顕著な違いは継承のサポートです。COM には継承がありません。Microsoft が作成したオブジェクト ライブラリ システムが、OO プログラミングの最も基本的な概念の 1 つをサポートしていないというのは奇妙に思えるかもしれません。これの主な理由は、ライブラリが潜在的にランダムな順序でロードされるシステムでは、基本クラスがどこに存在するかを知るのが難しいためです。COM では、プログラマがコンパイル時に正確な基本クラスを指定する必要があるため、途中で他の派生クラスを挿入することはできません (少なくとも他の COM ライブラリでは)。

代わりに、SOM は単純なアルゴリズムを使用し、継承ツリーをたどって最初に一致するもので停止することにより、潜在的な基本クラスを探します。これは、ほとんどの場合、継承の背後にある基本的な考え方です。このアプローチの欠点は、APIが同じままであっても、この基本クラスの新しいバージョンが機能しなくなる可能性があることです。この可能性は、共有ライブラリを使用するプログラムだけでなく、どのプログラムにも存在しますが、問題が他の人のコードに存在すると、追跡が非常に困難になる可能性があります。SOM では、唯一の解決策は新しいバージョンのライブラリを広範囲にテストすることですが、これは必ずしも容易ではありません。

SOM と COM は IBM によって対置されましたが、相互に排他的ではありませんでした。1995 年、Novell は ComponentGlue [11]テクノロジをOpenDoc for Windows に提供しました。このテクノロジは、COM ベースのコンポーネントと SOM ベースのコンポーネントを統合するためのさまざまな手段を提供しました。特に、SOM オブジェクトは、レイト バインディング ブリッジ (IDispatch に基づく) またはパフォーマンスの高い COM インターフェイスのいずれかによって、OLE2 アプリケーションで使用できるようになります。本質的に、SOM クラスはこのように COM インターフェイスを実装しています。

SOM が提供する柔軟性は、ほとんどすべての人がトラブルに見合うだけの価値があると考えていました[要出典]が、 Sun MicrosystemsDistributed Objects Everywhereなどの同様のシステムも完全な継承をサポートしていました。NeXTPortable Distributed Objectsは、強力なバージョン管理システムによってこれらの問題を回避し、ライブラリの作成者が古いバージョンと共に新しいバージョンを出荷できるようにし、ディスク容量のわずかなコストで 下位互換性を保証しました。

も参照

参考文献

  1. ^ Willis Boughton 博士によるSOM と Object REXX (2004 年 8 月)
  2. ^ OS/390 ドキュメントの SOMobjects
  3. ^ Tandem は分散オブジェクト コンピューティングに IBM の SOMobjects テクノロジを活用
  4. ^ アイラ・R・フォーマンとスコット・ダンフォース (1999). メタクラスを機能させる. ISBN 0-201-43305-2.
    Chapter 11 "Release-to-Release Binary Compatibility", page 246
    Web では、同じ著者による同一の名前と同様の内容の記事を見つけることができます: Release-to-Release Binary Compatibility
  5. ^ 「ArcaOS 5.0 WPS クラスのリスト」. 2020-09-03閲覧
  6. ^ ロジャー・セッションズ著「ロスト・イン・ザ・ガーデン」(1996年8月)
  7. ^ Esther Schindler によるLinux 開発者向けのちょっとした SOM の話 (2008 年 2 月)
  8. ^ Linux デスクトップに OS/2 の最高の機能を復活 させる 2010年 4 月 17 日、Wayback Machine でアーカイブされました。
  9. ^ OS/2 請願、第 2 ラウンド (2007–2010)
  10. ^ C++ のバイナリ互換性の問題
  11. ^ ComponentGlue(tm) は、OLE、OCX コントロールとの完全な相互運用性を提供します

外部リンク