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

IBM SOMオブジェクト

開発者	IBM
安定リリース	3.0 / 1996年12月
オペレーティング·システム	OS/2、Windows、AIX、クラシック Mac OS、コープランド、OS/390、NonStop OS、OS/400
タイプ	オブジェクト指向 共有ライブラリシステム

システムオブジェクト モデル( SOM ) は、IBMによって開発されたオブジェクト指向の 共有ライブラリテクノロジであり、オブジェクトへのインターフェイスを定義して、そのインターフェイスを実装から分離することをサポートします。

CORBAに基づく分散型であるDSOMにより、異なるコンピュータ上のオブジェクト間の通信が可能になりました。

SOM ライブラリは、クライアント コードを再構築することなく更新できます。ライブラリを変更して新しいクラスやメソッドを追加したり、クラスやメソッドの内部実装を変更したりした場合でも、使用するプログラムは再構築せずに引き続き使用できます。このようにして、SOM は、C++などの他のライブラリ テクノロジに影響を与える脆弱なバイナリ インターフェイスの問題に対処します。

SOM を使用すると、クラスを1 つのプログラミング言語で定義し、別のプログラミング言語で使用することができます。クライアントは、クライアント言語がクラスの型指定をサポートしていない場合でも、公開されたクラスからオブジェクトを作成して使用し、公開されたクラスからサブクラスを派生させることができます。

SOM は、ライブラリメタデータへのアクセスを提供するアプリケーション プログラミング インターフェイス(API)を提供します。各オブジェクトは、クラス名や、オブジェクトが特定のメソッドを実装しているかどうかなどを提供するメソッドを公開します。

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を含むほとんどのコードに使用されていました。OS /2用のObject REXXは、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年にスティーブ・ジョブズがアップルに戻り、 CoplandやOpenDocを含む多くの開発作業を終了したとき、SOMはOPENSTEP （後にMac OS Xとなる）ですでに使用されていたObjective-Cに置き換えられた。SOM/DSOMの開発は衰退し、もはや積極的に開発されていないが、 ArcaOSなどのOS/2ベースのシステムには引き続き含まれ、使用されている。^[4]

OS/2 と OpenDoc が事実上消滅したにもかかわらず、SOM には Windows とクロスプラットフォーム開発という別のニッチな分野があるかもしれない。WinNT 用の SOM 3.0 は 1996 年 12 月に一般公開された。これらの方向に進まない理由は、市場採用の問題だけではない。IBM が逃した機会、[5] と破壊的な非互換性の変更が関係して^いる。

• VisualAge C++ for Windows の最初のバージョンは 3.5 でした。これは SOM をサポートする最初で最後のバージョンでした。このバージョンには SOM 2.1 がバンドルされており、コンパイラには Direct-to-SOM サポートがありました。バージョン 3.6.5 以降には SOM の痕跡はありませんでした。
• SOM オブジェクトは主に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 のダウンロード サイトを閉鎖し、その後オンラインに戻すことはありませんでした。SOM 3.0 DTK for WinNT は、他の多くのレガシー コンテンツが自由に利用できるにもかかわらず、IBM FTP では見つかりません。SOM 3.0 for WinNT は一般に公開されていたにもかかわらず、2012 年末まで見つけることはほぼ不可能でした。
• 最後に、IBMはいくつかの記事^{[6] [7]}や請願^{[8]にもかかわらず、SOMを（} Object REXXに対して行ったように）オープンソース化することはありませんでした。

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

SOMはコンパイルされたライブラリと比較することができます: ^[9]

• 雑談
• コモン Lisp オブジェクト システム(CLOS)
• 汎用C++
• SGI デルタ/C++
• Sun オブジェクトバイナリインタフェース
• オブジェクティブC
• ジャワ

2015年現在、リンクされた表の情報のほとんどは、Objective-C 2.0がいわゆる非脆弱なインスタンス変数を取得することを除いて、最新バージョンに適用できます。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つです。

汎用C++はQtとKデスクトップ環境（KDE ）で現在も使用されています。QtとKDEは、開発ツールで特別なサポートなしにバイナリ互換性を維持するための努力を説明していることで有名です。^[10]

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

特別なランタイムがなければ、他の多くのプログラミング言語でも同じ問題が発生するでしょう。たとえば、DelphiやAdaなどです。これは、Delphi 2006 のバイナリ互換を実現するために採用された、いわゆる前例のないアプローチによって説明できます。Delphi 2007 リリース: DCU 互換性を損なわずに「公開」プロパティを追加する方法 Archived 2015-12-08 at the Wayback Machine

Objective-Cは SOM の最も有望な競合相手です (ただし、多言語プラットフォームとして積極的にマーケティングされているわけではありません)。また、SOM は歴史的に COM と比較されるのではなく、Objective-C と比較されるのが望ましいでしょう。Objective-C 2.0 の非脆弱なインスタンス変数により、これは積極的にサポートされているものの中で最良の代替手段です。

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

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

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

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

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

SOM は、コンポーネント オブジェクト モデル(COM)とよく比較されます。どちらも、複数の言語から使用できるライブラリ形式をサポートしています。

SOM は COM の遅延バインディングに似た言語に依存しない呼び出しメカニズムのみをサポートしているため、より堅牢であると考える人もいます。COMは、パフォーマンスは向上しますが安全性は劣る早期バインディング(カスタム インターフェイスとも呼ばれます) もサポートしています。これにより、クライアントはCと互換性のある関数テーブルを介してオブジェクトにアクセスでき、したがって C++ オブジェクトの仮想テーブルのバイナリ レイアウトと互換性があります (少なくとも Microsoft の C++ コンパイラでは)。互換性のある C++ コンパイラでは、カスタム インターフェイスを純粋仮想 C++ クラスとして定義できます。このインターフェイスは、ポインターを介して C 関数を呼び出すことができる任意の言語から呼び出すことができます。

カスタム インターフェイスのリスクは、非互換性によって未定義の動作が発生する可能性があることです。特に、カスタム インターフェイスが変更されたオブジェクトのバージョンが公開されると、クライアントがクラッシュする可能性があります。これは、脆弱な基本クラスの問題の一例です。この問題を防ぐには、COM 開発のルールとして、一度公開されたカスタム インターフェイスは変更できないようにします。オブジェクトの公開機能を追加または変更するには、追加のカスタム インターフェイスを実装します。

SOM は、遅延バインディングのみを提供することでこの問題を回避します。これにより、ランタイム リンカーがテーブルをオンザフライで再構築できるようになります。このようにして、基礎となるライブラリへの変更は、プログラムにロードされたときに解決されます。

SOM は、オブジェクト指向 (OO) 機能のサポートという点ではより堅牢です。COM は基本的にプログラミング用に C++ の縮小版を定義しますが、SOM はほぼすべての一般的な機能をサポートしています。また、多重継承、メタクラス、動的ディスパッチなどのあまり一般的ではない機能もサポートしており、これらの機能により、ほとんどの SOM/COM のようなシステムは、サポートする言語が少なくなる代わりに簡素化されています。IBM はSmalltalk (単一継承と動的ディスパッチ) とC++ (多重継承と固定ディスパッチ) の両方をサポートしたかったため、多言語サポートは IBM にとって重要でした。

注目すべき違いは継承のサポートです。COM はサポートしていません。Microsoft がこのような基本的な OO プログラミングの概念をサポートできないオブジェクト ライブラリ テクノロジを開発したことは奇妙に思われるかもしれませんが、主な理由は、ライブラリが設計時に不明な順序でロードされる場合、基本クラスがメモリ内のどこに存在するかを知ることが難しいためです。COM では、プログラマがコンパイル時に正確な基本クラスを指定する必要があるため、少なくとも他の COM ライブラリでは、途中に他の派生クラスを挿入することはできません。

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

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

Distributed Objects Everywhereなどの同様のテクノロジも、完全な継承をサポートしています。Portable Distributed Objects は、強力なバージョン管理システムによってこれらの問題を回避し、ライブラリ作成者が新しいバージョンを古いバージョンと一緒に出荷できるようにすることで、ディスク領域を犠牲にして 下位互換性を保証しました。