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

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

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

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

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

用途

• OS / 2
• OpenDoc

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

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

IBMはSOMobjectsを完全にシャットダウンしませんでした。これらはOS / 390に移植されており、このOSでも引き続き利用できます。 IBMのWebサイトでドキュメントを読むことができます。 1996年にTandem Computers Inc.はSOMobjectsテクノロジーを取得しました。タンデムはコンパックに売却され、コンパックはヒューレットパッカードに売却されました。 NonStop DOMおよび他のいくつかのテクノロジーは最終的にNonStop CORBAに統合されましたが、NonStop製品の現在のドキュメントには、SonテクノロジーがまだNonStop製品を強化している兆候は含まれていません。

色褪せ

1990年代半ばのOS / 2の「死」により、SOM / DSOMの存在理由はほとんどなくなりました。ユーザーがデスクトップでOS / 2を実行していない場合、ユニバーサルオブジェクトライブラリはありません。 1997年、Steve JobsがAppleに戻り、CoplandやOpenDocを含む多くの開発努力を終了したとき、SOMは既にOPENSTEP OSで使用されているObjective-Cに置き換えられました（後でMac OS Xになります）。 SOM / DSOM開発は衰退し、もはや積極的に開発されていません。

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

• VisualAge C ++ for Windowsの最初のバージョンは3.5でした。 SOMをサポートする最初で最後のバージョンでした。 SOM 2.1がバンドルされており、コンパイラでSOMに直接対応しています。バージョン3.6.5以降には、SOMのトレースがありませんでした。
• SOMオブジェクトは、主にメイクファイルに依存していました。 VisualAge C ++ 4.0は.iccプロジェクトを導入し、icc.exeおよびilink.exeコマンドラインコンパイラーとリンカーを供給から削除しました。 SOM DTKサンプルをすぐにVAC ++ 4.0でビルドすることはできません。 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年末まで見つけることはほとんど不可能でした。
• 最後に、IBMはいくつかの記事と請願書にもかかわらず、SOMをオープンソース化しませんでした（Object REXXに対して行われたように）。

代替実装

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

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

歴史的に、SOMはIBMによってMicrosoftのComponent Object Model（COM）と比較されました。ただし、いくつかの観点からは、COMの場所はまったくありません。リリースからリリースへの変換の観点から見ると、COMは手続きレベルにあるため、RRBCの記事の表1（前述のリリースからリリースへのバイナリ互換性 ）にはCOM列がまったく含まれていません。代わりに、SOMは次のものと比較されています。

• コンパイルされたSmalltalk
• コンパイルされたCommon Lisp Object System（CLOS）
• ジェネリックC ++
• SGI Delta / C ++
• Sun Object Binary Interface
• Objective-C
• Java

この表のほとんどの情報は、Objective-C 2.0がいわゆる非脆弱インスタンス変数となることを除いて、最新バージョン（2015年現在）に引き続き適用可能です。 SGI Delta / C ++またはSun OBIなど、一部のソリューションは実験的でした。 1つのプログラミング言語に基づくほとんどのアプローチは、段階的に廃止されるか、同じ方法で積極的に使用されることはありませんでした。たとえば、Netscapeプラグインアプリケーションプログラミングインターフェイス（NPAPI）ブラウザープラグインは、最初はJava API（LiveConnect）を使用して作成されましたが、Java仮想マシン（JVM）は後にチェーンから除外されました。 Javaはクロスプラットフォームコンポーネントオブジェクトモデル（XPCOM）に置き換えられたと見ることができます。 Common Lisp Object System（CLOS）とSmalltalkは、LiveConnectのJavaのようなチェーンリンクとして知られていません。 Objective-Cもこの役割ではあまり知られておらず、この方法で販売されていることも知られていませんが、そのランタイムは同様のユースケースにとって最も使いやすいものの1つです。

ジェネリックC ++は、まだQtおよびKデスクトップ環境（KDE）で使用されています。 QtとKDEは、開発ツールで特別なサポートなしでバイナリ互換性を維持するために必要な取り組みを説明する点で注目に値します。

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

特別なランタイムがなければ、Delphi、Adaなど、他の多くのプログラミング言語でも同じ問題が発生します。これは、Delphi 2006バイナリ互換のDelphi 2007リリースを作成するのにかかった、 前例のないアプローチで説明できます。DCUの互換性を損なうことなく「発行済み」プロパティを追加する方法

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ランタイムコンポーネントによって公開されているクラスを封印済みとして宣言する必要があります。

COMとの比較

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

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

SOMは、さまざまなオブジェクト指向言語を完全にサポートするという点でもはるかに堅牢です。基本的なCOMは基本的にプログラムするC ++のカットダウンバージョンを定義しますが、SOMはほとんどすべての一般的な機能をサポートします。たとえば、SOMは複数の継承、メタクラス、および動的ディスパッチをサポートしています。これらの機能の一部は、ほとんどの言語では見られないため、ほとんどのSOM / COMライクシステムは、サポートする言語が少なくなりますが、よりシンプルになりました。ただし、IBMでは、Smalltalk（単一継承と動的ディスパッチ）とC ++（多重継承と固定ディスパッチ）の両方をサポートするために多大な努力を行っていたため、多言語サポートの完全な柔軟性は重要でした。

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

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

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

SOMが提供する柔軟性は、ほとんどすべての人にとって面倒な価値があると考えられていましたが、Sun MicrosystemsのDistributed Objects Everywhereなどの同様のシステムも完全な継承をサポートしていました。 NeXTのポータブル分散オブジェクトは、強力なバージョン管理システムによってこれらの問題を回避し、ライブラリ作成者が古いバージョンとともに新しいバージョンを出荷できるようにして、ディスクスペースの少ないコストでの下位互換性を保証します。

クリエイター

OS / 2用のSOM 3.0 DTKにはbin \ sc.exeが含まれています。 sc.exeには次の文字列が含まれています。

SOMObjectsカーネルツールキット

コンパイラ：Andy Martin。
ランタイム：ラリーレイパー、スコットダンフォース、マイクコナー。
バインディング：アンディ・マーティン、ラリー・レイパー、マイク・コナー。
C ++バインディング：Scott Danforth、Andy Martin。
インターフェイスリポジトリ：Larry Raper、Dave Hock。
エミッタフレームワーク：マイクコナー、リアーヌアッカー、アンディマーティン。
その他のツール：Andy Martin、Liane Acker。

sc.exeには記載されていません：

メタクラスフレームワーク：Ira R. Forman、Scott Danforth