分散データ管理アーキテクチャ

分散データ管理アーキテクチャ( DDM ) は、リモート コンピュータ上のデータを作成、管理、およびアクセスするためのIBMのオープンで公開されたソフトウェア アーキテクチャです。 DDM は当初、レコード指向のファイルをサポートするように設計されました。その後、階層ディレクトリ、ストリーム指向のファイル、キュー、およびシステム コマンド処理をサポートするように拡張され、さらに拡張されて IBM の分散リレーショナル データベース アーキテクチャ(DRDA)のベースとなり、最終的にはデータ記述と変換をサポートするように拡張されました。 1980 年から 1993 年にかけて定義された DDM は、必要なコンポーネント、メッセージ、およびプロトコルを指定しており、これらはすべてオブジェクト指向の原則に基づいています。 DDM 自体はソフトウェアではなく、DDM の実装はクライアント製品とサーバー製品の形をとります。 オープンアーキテクチャであるため、製品は DDM アーキテクチャのサブセットを実装でき、製品は追加の要件を満たすために DDM を拡張できます。 総合すると、DDM 製品は分散ファイル システムを実装します。

分散アプリケーションの設計者は、転送されるデータの量と頻度、およびデータ管理、セキュリティ、適時性を考慮して、アプリケーションのプログラムとデータの最適な配置を決定する必要があります。分散アプリケーションの設計には、次の 3 つのクライアント サーバー モデルがあります。

1. ファイル転送プロトコル(FTP) は、ファイル全体またはデータベース テーブルを各クライアントにコピーまたは移動し、ローカルで操作できるようにします。このモデルは、ドキュメント エディターやスプレッドシート エディターなどの高度にインタラクティブなアプリケーションに適しています。これらのアプリケーションでは、各クライアントが対応するエディターのコピーを持ち、このようなドキュメントの共有は一般に問題になりません。
2. シン クライアントアプリケーションは、アプリケーションのインターフェイスをユーザーに提示しますが、アプリケーションの計算部分は、影響を受けるファイルまたはデータベースで集中管理されます。通信は、シン クライアントとサーバー間のリモート プロシージャ コールで構成され、独自に設計されたメッセージによって、呼び出されるプロシージャ、その関連パラメータ、および返される値が指定されます。
3. ファット クライアントアプリケーションは、すべてのアプリケーション処理タスクをクライアント システム上で実行しますが、データはサーバーに集中化されるため、管理でき、承認されたクライアント アプリケーションからアクセスでき、すべてのクライアント アプリケーションが最新のデータで動作し、アプリケーションによって影響を受けるレコード、ストリーム セクション、またはデータベース テーブルのみが送信されます。クライアント アプリケーション プログラムは、集中化されたデータで動作するすべてのクライアントに配布する必要があります。

DDM アーキテクチャは当初、分散アプリケーションのファット クライアントモデルをサポートするように設計されましたが、ファイル全体の転送もサポートしています。

DDMアーキテクチャは分散アプリケーションに次のような利点を提供します。^[1]

• ローカル/リモートの透過性。アプリケーション プログラムは、ローカル データからリモート データに簡単にリダイレクトできます。リモート システムのデータにアクセスして管理する専用のプログラムは必要ありません。
• データの冗長性が低減されます。データはネットワーク内の 1 か所にのみ保存する必要があります。
• セキュリティの向上。データの冗長コピーを排除することで、ネットワーク内のデータへのアクセスを承認されたユーザーのみに制限できます。
• データの整合性。ローカル ユーザーとリモート ユーザーの同時更新は競合により失われません。
• よりタイムリーな情報。ネットワーク内の複数のコンピューターのユーザーは常に最新のデータにアクセスできます。
• より優れたリソース管理。コンピュータ ネットワークのデータ ストレージと処理リソースを最適化できます。

DDMアーキテクチャは、コンピュータネットワーク全体に分散されたデータの管理とアクセスを可能にするメッセージとプロトコルの仕様のセットです。 ^[2]

IBM のシステム ネットワーク アーキテクチャ(SNA) は、当初、ワークステーションを IBM メインフレーム コンピュータに階層的に接続できるように設計されました。当時利用可能な通信ネットワークは、メインフレームとその一連のワークステーション間の固定接続という観点で厳密に設計されており、ワークステーションはメインフレーム コンピュータの完全なソフトウェア制御下に置かれていました。メインフレーム間のその他の通信も、特定の目的のために定義されたソフトウェアによって使用される固定接続という観点で行われていました。通信ネットワークがより柔軟で動的になるにつれて、1 台のコンピュータ上のプログラムが別のコンピュータ上のプログラムを開始して対話できる、汎用的なピアツーピア通信が望ましいものになりました。

1980 年代初頭にIBM の SNA拡張プログラム間通信(APPC) アーキテクチャが定義されたとき、APPC を使用してリモート コンピュータでオペレーティング システム サービスを提供できることも明らかでした。SNA ワークグループはこのアイデアを追求し、ファイル サービス、プリンタ サービス、システム コンソール サービスなど、いくつかの分散サービスの可能性を概説しましたが、製品開発を開始することはできませんでした。APPC ソフトウェアはまだメインフレームで利用できず、さらに基本的な点として、メインフレームは依然として主にスタンドアロン システムと見なされていました。その結果、分散サービスに関する作業は SNA ワークグループによって中断されました。

IBM のミネソタ州ロチェスター開発研究所の SNA 作業グループのメンバーは、ロチェスターで製造されたミッドレンジ コンピュータ システム間で分散サービスを行うビジネス ケースが存在すると確信していました。分散ファイル サービスの原始的な形式であるDistributed Data File Facility (DDFF) は、IBM System/3、IBM System/34、およびIBM System/36ミニコンピュータを接続するために実装されていました。さらに、IBM System/36およびIBM System/38コンピュータは顧客に複数台販売されており、たとえば、会社の本社コンピュータがさまざまな倉庫にあるコンピュータと対話できるようにする必要性が明らかにありました。APPC はこれらのシステムに実装され、さまざまな顧客アプリケーションで使用されていました。その後、分散オペレーティング システム サービスのアイデアがGolden Gateプロジェクトとして復活し、その開発を正当化する試みがなされました。この試みも失敗しました。分散サービスのアイデア自体が IBM の製品プランナーにとって新しすぎたため、異機種コンピュータを相互接続するソフトウェアの価値を定量化できなかったのです。

しかし、ゴールデン ゲートのプランナーの 1 人である John Bondy は、その考えを捨てきれず、経営陣を説得して、ロチェスター研究所の通常の管理外に部門を作り、事前に定義されたビジネス ケースをすぐに必要としないようにしました。さらに、その部門のミッションを、分散データ管理(DDM)、特にレコード指向ファイルのサポートのみに限定しました。その後、経験豊富なソフトウェア アーキテクトの Richard A. Demers を説得して、DDM アーキテクチャの定義と IBM システム ハウスへの DDM のアイデアの売り込みという仕事に加わってもらいました。

この取り組みの最初の 1 年間は、IBM システム ハウスが引き続き事前のビジネス ケースを要求し、ローカル ファイル システムの制御ブロック インターフェイスと同型のメッセージ形式を主張したため、ほとんど成果がありませんでした。さらに、パーソナル コンピュータがメインフレーム コンピュータに接続された端末として使用されるようになったため、 3270 データ ストリームを単純に拡張するだけでPC からメインフレーム データにアクセスできると 主張されました。

この期間に、Demers は DDM クライアントとサーバー、それらのコンポーネント、および通信するコンピュータ間の相互作用のアーキテクチャ モデルを設計しました。さらに、Smalltalkプログラミング言語と IBM System/38 によって開拓されたオブジェクト指向の原則に基づいて、DDM メッセージの汎用形式を定義しました。このモデルにより、DDM 製品をさまざまなシステムに実装する方法が明確になりました。「DDM の仕組み」を参照してください。

1982年、System/36の計画者は、DDMレコード指向ファイルサービスには十分な市場があると確信しました。^[3]

DDM メッセージの汎用フォーマットはすでに設計されていましたが、どのような特定のメッセージを定義する必要がありますか? System/36 ファイル システムは、Fortran、COBOL、PL/I、IBM RPGなどの第 3 世代プログラミング言語 (3GL) のレコード指向のニーズを満たすように定義されていました。System/38 ファイル システムとIBM メインフレーム コンピューターの仮想記憶アクセス方式(VSAM) ファイル システムも同様です。しかし、実際の機能とインターフェースは大きく異なるため、DDM アーキテクチャーはどのような機能とインターフェースをサポートする必要がありますか? レコード指向ファイルを参照してください。

Golden Gateプロジェクトによる DDM に関する初期の作業は、分散ファイル用の国際標準であるFile Transfer Access and Management ( FTAM ) に倣ったものでしたが、非常に抽象的で、ローカル ファイル サービスにマッピングするのが困難でした。実際、これが IBM システム ハウスに受け入れられない障壁の 1 つでした。System/36 ファイル サービスを担当するシステム アーキテクトの Kenneth Lawrence は、少なくとも 1 つの IBM システムが簡単に実装できるメッセージを定義し、他のシステムが必要な変更を要求できるようにする方がよいと主張しました。当然、彼は System/36 の要件のサポートを主張しました。DDM のアイデアを他の IBM システム ハウスに売り込むことに 1 年失敗しましたが、Lawrence の主張が受け入れられました。

Richard Sanders が DDM アーキテクチャ チームに参加し、Lawrence および Demers と協力して System/36 DDM に必要な特定のメッセージを定義しました。DDM の定義が進むにつれて、System/38 も参加するようになりました。これにより、DDM レコード ファイルのサポート範囲が広がり、System/38 の高度なファイル システムの多くの要件を満たすようになりました。

ファイルは、ファイルを整理し、同時ユーザーと共有し、不正アクセスから保護するためのサービスを提供するオペレーティング システムによって提供されるコンテキスト内に存在します。 DDM のレベル 1 では、使用するファイルの完全修飾名の送信以外、リモート ファイル ディレクトリへのアクセスはサポートされていませんでした。ただし、セキュリティと共有は必須でした。 Sanders はこれらの領域の設計作業を行いました。 Sanders は、通信機能の使用に関する特定のプロトコルも定義しました。これは、DDM 会話型通信マネージャーと呼ばれるコンポーネントに組み込まれました。 当初は APPC を使用して実装されましたが、後に TCP/IP を使用して実装されました。

System/36 DDM製品の完成に伴い、ローレンスはIBM英国ハースリーパーク研究所のプログラマーと協力し、System/36 DDMサーバープログラミングの多くをIBM顧客情報管理システム（CICS）トランザクション処理環境で使用できるように適応させ、CICSをMVSとVSEメインフレームオペレーティングシステムの両方でDDMサーバーにしました。^{[4]ローレンスは、IBMノースカロライナ州キャリー研究所のプログラマーとも協力し、} IBM PC DOS用のDDMレコード指向クライアントを実装しました。

DDM アーキテクチャのレベル 1 は 1986 年に正式に公開されました。この発表の時点で、IBM はKenneth Lawrence に優秀技術功績賞、 Richard Sanders に優秀貢献賞、 Richard Demers に優秀革新賞を授与しました。

• この記事では、System/38はSystem/38とその後継製品であるIBM AS/400（System/36とSystem/38の機能を統合）、IBM iSeries、IBM Power Series ^[5]（iSeriesとIBMのRISC/UNIXベースのサーバーおよびワークステーション製品ラインであるIBM RS/6000を統合）を指すために今後使用されます。

ネットワーク環境における IBM PC と Unix オペレーティング システムの重要性が増すにつれ、IBM PC DOS を実行するIBM パーソナル コンピュータとIBM AIX (IBM の Unix バージョン)を実行するIBM RS/6000の階層ディレクトリとストリーム指向ファイルに対する DDM サポートも必要になりました。ストリーム指向ファイルを参照してください。

DDM アーキテクチャ レベル 2 は 1988 年に公開されました。ディレクトリとストリーム ファイルの DDM サポートに関するアーキテクチャ作業の大部分は、Jan Fisher と Sunil Gaitonde によって行われました。

1986 年に IBM は、それぞれ特定の IBM オペレーティング システム用に構築された 4 つの異なるリレーショナル データベース(RDB) 製品を販売しました。IBM の Almaden 研究所の科学者は、分散 RDB のプロトタイプである System/R* を開発しており、これを市場価値のある製品に変える時期が来たと感じていました。しかし、System/R* は、RDB の研究プロトタイプである System/R に基づいていたため、IBM RDB 製品に簡単に追加することはできませんでした。 分散処理環境における RDB については、 ^{[6]を参照してください。}

IBM サンタテレサ プログラミング センターの Roger Reinsch 氏は、分散リレーショナル データベース アーキテクチャ(DRDA) を定義するクロスプロダクト チームを率いていました。彼は次のメンバーを招集しました。

• 4 つの IBM RDB 製品それぞれの代表者。
• System/R*研究者のブルース・リンゼイ氏は、
• Paul Roever (IBM ジンデルフィンゲン、ドイツ研究所所属) は、Formatted Data: Object Content Architecture (FD:OCA) と呼ばれるデータ記述の仕様を開発しました。
• DDM アーキテクチャ チームの Richard Sanders と Richard Demers が、適切なモデル、メッセージ、プロトコルを定義します。

1990年に、DDMアーキテクチャレベル3とDRDA ^[7]が同時に公開されました。DDMとDRDAは両方ともIBMのシステムアプリケーションアーキテクチャ（SAA）の戦略的コンポーネントとして指定されました。DRDAはIBM RDB製品の4つすべてと他のベンダーによって実装されました。

DRDA の設計に携わった主要な参加者に賞が授与されました。リチャード・サンダース氏は優秀貢献賞を受賞し、ロジャー・ラインシュ氏とリチャード・デマーズ氏は優秀イノベーション賞を受賞しました。

分散ファイル管理(DFM) ^[8]プロジェクトは、IBM の MVS オペレーティング システムに DDM サービスを追加して、リモート コンピュータ上のプログラムがVSAMファイルを作成、管理、アクセスできるようにするために開始されました。DFM プロジェクトのマネージャである John Hufferd は、システム間を流れるレコードのデータ フィールドを変換する手段を DDM アーキテクチャ チームに求めました。この問題については、DFM プロジェクトの Koichi Yamaguchi の支援を受けながら Richard Demers が主導しました。データ記述と変換を参照してください。

次の追加サービスは、Richard Sanders、Jan Fisher、Sunil Gaitonde によってレベル 4 の DDM アーキテクチャで定義されました。

• DFM、ストレージ管理、およびユーザー定義のファイル属性の場合。
• DRDA の場合、アプリケーション主導の分散作業単位用の 2 フェーズ コミットメント制御プロトコル。
• キューは、リモート サーバーで作成、クリア、または削除できます。キュー エントリは、キューに追加されるか、キューから受信されるアプリケーション定義のレコードです。DDM キューを参照してください。
• システム コマンド プロセッサは、サーバーのホスト システムによって定義されたコマンドを実行のために送信できるマネージャーです。
• マルチタスク通信マネージャー。これにより、クライアント システムとサーバー システム間の単一の会話を使用して、複数のクライアント エージェントが対応するサーバー エージェントと通信できるようになります。
• 同期ポイント マネージャーは、複数の DDM サーバー内の論理作業単位を調整します。2 フェーズ コミットメント プロトコルにより、論理作業単位のいずれかが失敗した場合に、調整されたリソース回復が保証されます。

DDM アーキテクチャ レベル 4 は 1992 年に公開されました。

DDMレベル5のアーキテクチャ作業は、以下のサポートで構成されていました。

• メインフレームのパーティション データ セットは、内部ディレクトリと複数のメンバーで構成されるファイルであり、実質的には類似のファイルのライブラリです。
• パーソナル コンピュータライブラリ。複数のフォルダー内のファイルへのアクセスを 1 つのライブラリに統合します。
• DRDA のさらなる機能強化。

Jan Fisher は、IBM ではなく Open Group によって公開された DDM レベル 5 を担当したアーキテクトでした。その後まもなく、IBM DDM アーキテクチャ グループは解散しました。

DDMアーキテクチャは正式に定義され、高度に構造化された仕様のセットです。このセクションでは、DDMの基礎となる重要な技術的概念を紹介します。^[2]

DDM アーキテクチャは、クライアント/サーバー プロトコルを定義します。つまり、クライアントはサーバーにサービスを要求し、サーバーはローカル リソースと対話して要求されたサービスを実行し、その結果、データ、およびステータス インジケーターがクライアントに返されます。上の図は、ローカル リソースに関連する DDM クライアントとサーバーの役割を示しています。(ここではクライアントとサーバーの一般的な用語が使用されていますが、DDM アーキテクチャでは、クライアントはソース サーバーと呼ばれ、サーバーはターゲット サーバーと呼ばれます。)

1. アプリケーション プログラムは、ローカル リソース マネージャ (LRM) によって提供されるプログラミング インターフェイスを使用して、ファイルなどのローカル リソースと対話します。ただし、必要なリソースがリモート コンピュータにある場合は、対話を仲介するために DDM が使用されます。アプリケーション プログラムは、LRM によって提供されるインターフェイスを引き続き使用しますが、それらは DDM クライアントにリダイレクトされます。DDM アーキテクチャでは、リモート リソースのディレクトリがサポートされていないため、このリダイレクトがどのように行われるかは指定されていません。いくつかの DDM ファイル指向製品で使用されるリダイレクト方法の 1 つは、アプリケーションで、 System/38 によってDDM ファイルと呼ばれる、リモート ファイルの場所とアクセス情報を提供する特別なローカル ファイルを開くことです。その後、DDM クライアントへのリダイレクトが行われます。
2. DDM アーキテクチャは、ファイル、リレーショナル データベース、アクセス メソッドなどのマネージャ レベルのエンティティを定義します。クライアント リソース マネージャ (CRM) は、クライアント システムの LRM によって定義された機能インターフェイスを多態的にサポートします。その主な機能は、各機能インターフェイスに対して適切な線形化された DDM コマンドとデータ オブジェクトを生成することです (DDM メッセージを参照)。これらのオブジェクトは、リモート DDM サーバーのサーバー リソース マネージャ (SRM) に送信されます。ただし、実際には、DDM クライアントおよびサーバーのエージェントと通信マネージャを介してルーティングされます。
3. DDM クライアント エージェントは、線形化されたコマンドを RQSDSS エンベロープに、線形化されたオブジェクトをリンクされた OBJDSS エンベロープに入れます (DDM メッセージを参照)。クライアント エージェントは、サーバー エージェントと対話して、CRM から受信したメッセージを SRM に流すためのパスを作成します。アプリケーション プログラムが 1 つのリモート リソースとのみ対話する必要がある場合、これは簡単です。ただし、アプリケーション プログラムが複数のリモート システムに存在するさまざまな種類の複数のリソースと同時に対話することも可能です。クライアント エージェントは、すべての場合においてアプリケーション プログラムを表し、各リソースへの個別の仮想パスでメッセージをルーティングします。
4. クライアント通信マネージャは、サーバ通信マネージャと対話して、「私が話している間にあなたが聞いて、あなたが話している間に私が聞いて」という形式の会話プロトコルを実装します。IBM の SNA APPC やインターネットの TCP/IP プロトコルなど、さまざまな通信プロトコルを使用できます。
5. サーバー通信マネージャーに送信された DDM メッセージは、メッセージで指定されたパス上のサーバー エージェントに渡され、同じパス上の SRM に転送されます。サーバー エージェントが単一のパス上の単一のクライアントと対話している場合、これは簡単です。ただし、サーバー エージェントは複数のパス上の複数のクライアントと対話できます。
6. サーバー リソース マネージャー (SRM) は、DDM メッセージを解析し、要求を実行するために何をする必要があるかを決定します。サーバー システムの対応するローカル リソース マネージャー (LRM) の機能インターフェイスの 1 つ以上を使用する場合があります。
7. SRM は LRM からのデータとステータス インジケーターを蓄積し、適切な線形化オブジェクトと応答メッセージを生成して、サーバー エージェントに渡します。
8. サーバー エージェントは、応答とオブジェクトを RPYDSS および OBJDSS エンベロープにパッケージ化し、サーバー通信マネージャーに転送します。サーバー通信マネージャーは、応答とオブジェクトを元のコマンドと同じパスでクライアント通信マネージャーとクライアント エージェントに送信します。
9. クライアント エージェントは、それぞれの RPYDSS および OBJDSS エンベロープから応答とオブジェクトを削除し、クライアント リソース マネージャーに渡します。
10. クライアント リソース マネージャーは、返されたオブジェクトと応答メッセージを解析し、元の LRM の機能インターフェイスで期待されるとおりにマッピングして、アプリケーション プログラムに返します。

DDM アーキテクチャはオブジェクト指向です。DDM によって定義されるすべてのエンティティは、自己定義クラスオブジェクトによって定義されるオブジェクトです。システム間を流れるメッセージ、応答、およびデータは、シリアル化されたオブジェクトです。各オブジェクトは、長さを指定し、DDM コードポイントによってクラスを識別し、クラスによって定義されたデータを含みます。さらに、そのクラスは、オブジェクトが DDM クライアントまたはサーバーに存在する場合にそのインスタンスに送信できるコマンドを指定し、それによってオブジェクトを限られた一連の操作によってカプセル化します。

構造的には、DDM アーキテクチャはオブジェクトの階層レベルで構成され、各レベルはより高いレベルで出現するプロパティを示します。

• フィールドは、数値、文字、またはその他のデータ エンティティをエンコードするビットの文字列です。Field サブクラスのインスタンスは、そのクラスで実行できる操作 (整数フィールドでの算術演算など) によってカプセル化されます。
• オブジェクトは、定義された一連の操作によってカプセル化された1つ以上のフィールドで構成される自己識別エンティティです。このレベルのオブジェクトは、Smalltalkプログラミング言語のカーネルオブジェクトクラスに触発されました^[9]
  • スカラー オブジェクトは、オブジェクトのクラスによってエンコードおよび記述された単一のフィールドで構成されます。スカラー オブジェクトは、コマンド オブジェクトと応答オブジェクトのパラメーター値として使用されます。また、DDM ドキュメントのオブジェクトの長さなど、オブジェクト属性の値としても使用されます。これらのスカラー オブジェクトの値に使用されるエンコード方法は、DDM アーキテクチャによって完全に定義されます。
  • マップされたオブジェクトは、アプリケーション定義レコードのフィールドなどの 1 つ以上のフィールドで構成されます。これらのフィールドのエンコード方式と配置は、DDM アーキテクチャーでは定義されません。代わりに、アプリケーション プログラムの宣言ステートメントと、そのプログラミング言語のエンコード方式および配置方式によって定義されます。
  • コレクション オブジェクトは、コレクションのクラスによって定義されるオブジェクトのコンテナーです。コレクション オブジェクトの例としては、DDM コマンドと応答があります。
• マネージャは、オブジェクトの保存と処理のための環境を提供する自己識別エンティティです。マネージャは、そのクラスによって定義された操作によってカプセル化されます。マネージャのセットは、一緒になって、DDM クライアントまたはサーバーの全体的な処理環境を実装します。このレベルのマネージャエンティティは、System/38 オペレーティングシステムのシステムオブジェクトからヒントを得ました。^[10] DDM によって定義されたマネージャには、辞書、スーパーバイザ、エージェント、ディレクトリ、ファイル、アクセスメソッド、リレーショナルデータベース、SQL アプリケーションマネージャ、キュー、ロックマネージャ、セキュリティマネージャ、リカバリマネージャ、システムコマンドプロセッサ、通信マネージャが含まれます。
• サーバーは、分散処理環境において、クライアントまたはサーバーとしてマネージャーの保存と処理のための環境を提供する自己識別エンティティです。例としては、分散ファイルまたは分散リレーショナル データベース管理に特化したクライアントとサーバーがあります。

DDM アーキテクチャはオブジェクト指向ですが、DDM 製品はホスト システムの一般的な言語とメソッドを使用して実装されました。DDM の Smalltalk バージョンは、Object Technology Internationalによって IBM PC 用に開発され、DDM リファレンス マニュアルから適切な Smalltalk クラスが自動的に作成されました。

DDMはオープンアーキテクチャです。DDM製品はDDMアーキテクチャのサブセットを実装することができ、独自の拡張機能を作成することもできます。 ^[11]

DDM の「Exchange Server Attributes」コマンドは、クライアントがサーバーに接続されたときに最初に送信されるコマンドです。このコマンドはクライアントを識別し、クライアントが必要とするマネージャーと、サポートが必要な DDM アーキテクチャのレベルを指定します。サーバーは、自身を識別し、要求されたマネージャーをどのレベルでサポートするかを指定して応答します。一般的な規則として、レベル X の DDM マネージャーをサポートする製品は、レベル X-1 もサポートする必要があります。これにより、新しいサーバー製品が古いクライアント製品に接続されます。

DDM のサブセットは、さまざまな製品要件を満たすように実装できます。

• クライアント、サーバー、またはその両方として使用できます。たとえば、DDM/PC はクライアントのみ、CICS/DDM はサーバーのみ、System/38 DDM はクライアントとサーバーの両方です。
• レコード指向ファイル、ストリーム指向ファイル、リレーショナル データベース (DRDA の一部)、またはそれらの組み合わせなどの特定のマネージャーをサポートします。たとえば、MVS データベース 2 は、DRDA に必要な DDM のサブセットのみのクライアントおよびサーバー サポートを提供します。
• シーケンシャル ファイルからレコードをロードおよびアンロードする機能など、マネージャーの選択されたコマンドのみをサポートします。
• 「レコードの取得」コマンドの「非アクティブなレコードを返す」パラメータなど、コマンドの選択されたパラメータをサポートします。

DDMクライアントが既知のDDMサーバーに接続されている場合（System/38クライアントがSystem/38サーバーに接続されている場合など）、DDMアーキテクチャは、次のものを追加することで拡張することもできます。

• 新しい製品専門のマネージャー。
• 既存の DDM マネージャーに新しいコマンドを追加します。
• DDM コマンドまたは応答メッセージに新しいパラメータを追加します。

このような拡張機能は、DDM のオブジェクト指向フレームワーク内で定義できるため、既存の DDM メッセージ処理機能を使用できます。

DDM の純粋なオブジェクト指向実装では、クライアントとサーバー、およびそれらに含まれるすべてのマネージャーとオブジェクトがメモリ ヒープ内に存在し、ポインタ (メモリ アドレス) を使用して相互接続されます。たとえば、コマンド オブジェクトは、その各パラメーター オブジェクトを指します。ただし、コマンドをこの方法でクライアントからサーバーに転送することはできません。コマンドの同型コピーを 1 つの連続したビット文字列として作成する必要があります。ヒープ内では、コマンドはヒープ内のコマンドのサイズ、コマンドのクラスへのポインタ、およびコマンドの各パラメーター オブジェクトへのポインタで構成されます。線形化されたコマンドは、線形化されたコマンドの合計長、コマンドのクラスを識別するコード ポイント、および線形化された各パラメーター オブジェクトで構成されます。DDM アーキテクチャでは、オブジェクトの各クラスに一意のコード ポイントが割り当てられます。この単純な手法は、コマンド、レコード、応答メッセージなど、クライアントとサーバー間で転送されるすべてのオブジェクトに使用されます。

これらの線形化されたオブジェクトはすべて、クライアント エージェントとサーバー エージェントが処理を調整できるようにエンベロープに入れられます。DDM アーキテクチャでは、これらのエンベロープはデータ ストリーム構造(DSS) と呼ばれます。コマンドは要求 DSS (RQSDSS)に入れられ、応答は応答 DSS (RPYDSS)に入れられ、その他のオブジェクトはオブジェクト DSS (OBJDSS)に入れられます。RQSDSS に入れることができるコマンドは 1 つだけ、RPYDSS に入れることができる応答は 1 つだけですが、レコードなどの多くのオブジェクトを OBJDSS に入れることができます。さらに、必要な数のオブジェクトを収容するために、多くの OBJDSS を RQSDSS または PRYDSS に連鎖させることができます。DSS は、DSS の全長、DSS のタイプを識別するフラグ バイト、要求 ID、および DSS 内の線形化されたオブジェクトで構成されます。要求 ID は、RQSDSS を、Load Fileコマンドによってファイルにロードされるレコードなどのクライアントからの後続の OBJDSS に結び付けます。要求識別子は、クライアントからの RQSDSS を RPYDSS に、またはサーバーからクライアントへの OBJDSS に結び付けます。

DDMリファレンスマニュアル^{[12] [13]}は、メニュー、ヘルプ、クラスオブジェクトで構成されてい ます。DDMクラスクラスのサブクラスは、

• クラスのスーパークラス。クラスは継承階層によって定義されます。たとえば、Record File は File のサブクラスであり、File は Manager のサブクラスであり、そのデータとコマンドを継承します。クラスÇlassとそのサブクラスは、次のようなクラス コマンドとクラス変数によって自己記述されます。
• クラスを簡単に説明するタイトル。
• DDM アーキテクチャに関する進行中の作業に対するクラスのステータス。
• クラスとそのコンポーネントおよび環境を関連付ける説明テキストとグラフィック。
• クラスのインスタンスによってカプセル化されたデータ (フィールド、オブジェクト、マネージャーなど)。
• インスタンスに送信できるコマンド。

これらのオブジェクトには、テキストや仕様内の他の名前付きオブジェクトへの参照を含めることができるため、 DDM リファレンス マニュアルのページ間にハイパーテキストリンクが作成されます。メニュー ページとヘルプ ページは、DDM に関する統合チュートリアルを形成します。DDM リファレンス マニュアル レベル 3 の紙のバージョンは 1400 ページを超える分厚いもので、やや使いにくいですが、IBM 社内の通信機能を使用して対話型バージョンも作成されました。これらの通信機能は比較的低速であったため、主に IBM ロチェスター研究所内で使用されました。

DDMリファレンスマニュアルに加えて、一般情報^[1]文書ではDDMに関するエグゼクティブレベルの情報が提供され、プログラマガイド^[11]ではクライアントとサーバーを実装するプログラマ向けにDDMの概念が要約されています。

DDM アーキテクチャでは、レコード指向ファイル、ストリーム指向ファイル、階層ディレクトリの 3 つの一般的なファイル モデルが定義されています。

DDM アーキテクチャでは、リモート ファイルの管理のために次のサービスが提供されます。

• ファイルの作成、クリア、削除、
• ファイルのデータのコピー、ロード、アンロード、
• ファイルのロックとロック解除、
• ファイル属性の取得と変更、

レコード指向ファイルは、Fortran、Cobol、PL/I、RPG などの第 3 世代 (3GL) プログラミング言語のデータ入力、出力、およびストレージ要件を満たすように設計されています。各言語がこれらの機能を独自にサポートするのではなく、オペレーティング システムによって提供されるサービスに組み込まれました。

レコードとは、従業員 1 人の名前、住所、識別番号、給与などの一連の関連データ フィールドのことです。各フィールドはエンコードされ、連続したバイト列にマッピングされます。初期のコンピュータは入出力機能が限られており、通常は 80 列のパンチ カードのスタック、紙、または磁気テープでした。従業員データ レコードなどのアプリケーション レコードは、レコードごとに順次読み書きされ、バッチで処理されました。直接アクセス ストレージ デバイスが使用可能になると、プログラミング言語によって、キー フィールドの値やファイル内のレコードの位置によるアクセスなど、プログラムがレコードに 1 つずつランダムにアクセスする方法が追加されました。ファイル内のすべてのレコードは、同じ形式 (給与ファイルなど) にすることも、さまざまな形式 (イベント ログなど) にすることもできます。一部のファイルは読み取り専用で、ファイルに書き込まれたレコードは読み取りのみ可能ですが、他のファイルではレコードを更新できます。

DDM レコード指向ファイル モデルは、作成日、最終更新日、レコードのサイズ、レコードを保存できるスロットなどのファイル属性で構成されます。レコードは、ファイルのレコードを保存するために使用するメディアに応じて、固定長または可変長になります。DDM では、次の 4 種類のレコード指向ファイルが定義されています。

• レコードが連続したスロットに保存されるシーケンシャル ファイル。
• 直接ファイル。個々のレコードは、レコードのフィールドの値によって決定されるファイルのスロットに格納されます。
• キー付きファイルでは、レコードは連続したスロットに格納され、レコードに含まれるキー フィールドの値のインデックスによって二次順序が維持されます。
• 代替インデックス ファイル。キー フィールドの値の個別のインデックスは、既存の順次ファイル、直接ファイル、またはキー付きファイルに基づいています。

DDM アーキテクチャでは、レコード指向ファイルをさまざまな方法で操作するためのさまざまなアクセス メソッドも定義されています。アクセス メソッドは、OPEN コマンドによって作成されたファイルの使用例であり、クライアントがファイルの使用を許可されているかどうかを判断した後、ファイルに接続します。アクセス メソッドは、CLOSE コマンドによってファイルから切断されます。

アクセス メソッドは、カーソルを使用して現在処理中のレコードを追跡します。さまざまな SET コマンドを使用して、カーソルをファイルの先頭または末尾、ファイルの次のレコードまたは前のレコード、特定のキー値を持つレコード、またはキーの順序に従って次のレコードまたは前のレコードを指すように設定できます。

アクセス メソッドの複数のインスタンスを 1 つのファイルで同時に開くことができ、それぞれが 1 つのクライアントにサービスを提供します。更新アクセス用にファイルが開かれると、複数のクライアントが同じレコードにアクセスするときに競合が発生する可能性があります。このような競合を防ぐために、ファイル全体のロックを取得できます。また、更新用にファイルが開かれると、最初にレコードを読み取ったクライアントによってレコードのロックが取得され、そのクライアントがレコードを更新するとロックが解除されます。他のすべてのクライアントはロックが解除されるまで待機する必要があります。

ストリーム指向ファイルは、プログラムがアプリケーション データを自由にマップできる単一のバイト シーケンスで構成されます。ストリーム ファイルは、UnixおよびUnix 系オペレーティング システムとWindowsでサポートされている主要なファイル モデルです。DDM は、単一のストリーム ファイル モデルと単一のストリーム アクセス メソッドを定義します。

DDM ストリーム ファイル モデルは、作成日、ストリームのサイズ、および連続したバイト ストリームなどのファイル属性で構成されます。ストリームには、ストリーム アクセス メソッドを使用してアクセスできます。アプリケーション プログラムは、データがレコードで構成されていても、ストリームの一部にデータを書き込みます。アプリケーション プログラムは、ストリーム内のデータ項目の場所を任意の方法で追跡します。たとえば、ドキュメント ファイルのデータ ストリームは、Microsoft Wordなどのテキスト処理プログラムによって定義され、スプレッドシート ファイルのデータ ストリームは、 Microsoft Excelなどのプログラムによって定義されます。

ストリーム アクセス メソッドは、単一のクライアントによるストリーム ファイルの使用例です。カーソルは、クライアントが使用しているサブストリームの現在のバイトの位置を追跡します。さまざまな SET コマンドを使用して、カーソルをファイルの先頭または末尾、ファイル内の特定の位置、または現在の位置からの正または負のオフセットを指すように設定できます。

ストリーム アクセス メソッドの複数のインスタンスを 1 つのファイルで同時に開くことができ、それぞれが 1 つのクライアントにサービスを提供します。ファイルが「更新」アクセス用に開かれている場合、同じサブストリームが複数のクライアントによってアクセスされると競合が発生する可能性があります。このような競合を防ぐために、ファイル全体のロックを取得できます。また、ファイルが更新用に開かれている場合、最初にファイルを「読み取る」クライアントによってサブストリームのロックが取得され、そのクライアントがファイルを「更新」するとロックが解除されます。他のすべてのクライアントはロックが解除されるまで待機する必要があります。

階層ディレクトリは、各レコードが名前と場所を関連付けているファイルです。階層は、ディレクトリ レコードが別のディレクトリの名前と場所を識別するときに発生します。DDM クライアントおよびサーバー製品を使用すると、プログラムはリモート コンピュータ内のディレクトリを作成、削除、および名前変更できます。また、リモート ディレクトリのファイル属性を一覧表示したり変更したりすることもできます。ディレクトリ内のレコードは、DDM ディレクトリ アクセス メソッドを使用して順番に読み取ることができます。ディレクトリ レコードによって識別されるファイルは、名前を変更したり、コピーしたり、別のディレクトリに移動したりできます。

キューは、レコードを使用してプログラム間で一般的に短期間の通信を可能にする通信メカニズムです。DDM キューは単一のシステムに存在しますが、複数のシステム上のプログラムからアクセスできます。個別の作成コマンドを使用してターゲット システム上に作成できる DDM キューのサブクラスは 3 つあります。

• 先入れ先出しキュー、キューに入れるプログラムとキューから外すプログラム間の非同期パイプ。
• 後入先出キュー、プッシュダウン スタック。
• キー付きキューは、選択したエントリをキー値によってデキューできるファンアウト メカニズムです。

DDM キュー モデルは、キューの作成日、キューに格納できるレコード数、レコードの長さなどのキュー属性で構成されます。キュー内のレコードは、固定長または可変長にすることができます。

DDM ファイル モデルとは異なり、キューでアクセス メソッドを開く必要はありません。プログラムは、キューのクラスによって決定されるとおり、キューにレコードを追加したり、キューからレコードを受け取ったりできます。また、プログラムは、キューからレコードをクリアしたり、キューでの操作を停止したり、キューの属性をリストしたり、キューの属性を変更したりすることもできます。プログラムは、他のプログラムとの競合を防ぐために、キューまたはキュー内の個々のレコードをロックすることもできます。他のすべてのクライアントは、ロックが解除されるまで待機する必要があります。

リレーショナル データベース( RDB ) は、データ テーブルの作成、管理、クエリ、更新、インデックス作成、および相互関係をサポートする構造化クエリ言語(SQL) の実装です。対話型ユーザーまたはプログラムは、RDB に SQL ステートメントを発行し、応答としてデータ テーブルとステータス インジケーターを受け取ることができます。ただし、SQL ステートメントはコンパイルされ、パッケージとして RDB に格納され、パッケージ名で呼び出されることもあります。これは、複雑で高頻度のクエリを発行するアプリケーション プログラムを効率的に操作するために重要です。アクセスするテーブルがリモート システムにある場合は特に重要です。

分散リレーショナルデータベースアーキテクチャ（DRDA）は、オブジェクト指向で説明されているように、全体的なDDMフレームワークにうまく適合します。（ただし、他の仕様も必要なため、DDMはDRDAのコンポーネントアーキテクチャと見なすこともできます^[2]）。DRDAをサポートするDDMマネージャーレベルのオブジェクトは、RDB（リレーショナルデータベース）およびSQLAM（SQLアプリケーションマネージャー）と呼ばれます。

透過性は、DDM アーキテクチャの重要な目的です。再コンパイルせずに、既存のアプリケーション プログラムをリモート コンピューターのデータ管理サービスにリダイレクトできる必要があります。ファイルの場合、これは主に DDM クライアントによってインターフェイス/機能レベルで実現されていますが、レコード内のデータ フィールドについてはどうでしょうか。完全な透過性を実現するには、リモート サーバーがどのようにフィールドをエンコードしているかに関係なく、クライアント アプリケーション プログラムがローカル データ管理システムによってエンコードされたフィールドを書き込み、読み取ることができる必要があります。つまり、自動データ変換が必要になります。

たとえば、IBM メインフレーム コンピュータは浮動小数点数を16 進形式で、文字データをEBCDICでエンコードしますが、IBM パーソナル コンピュータはIEEE形式とASCIIでエンコードします。さまざまなプログラミング言語コンパイラがレコード フィールドをメモリ内のビット、バイト、およびワードの文字列にマップする方法によって、さらに複雑になりました。レコードの透過的な変換には、レコードのクライアント ビューとサーバー ビューの両方の詳細な記述が必要です。これらの記述があれば、クライアント ビューとサーバー ビューのフィールドをフィールド名で一致させ、適切な変換を実行できます。

重要な問題は、十分に詳細なレコード記述を取得することですが、レコード記述は一般に、プログラミング言語で定義された宣言文によってアプリケーション プログラム内で抽象的に指定され、言語コンパイラがエンコードとマッピングの詳細を処理します。分散処理環境では、すべてのプログラミング言語に依存しない、既存のファイルにあるさまざまな固定長および可変長のレコード形式を記述できる、レコードを記述する単一の標準化された方法が必要です。

その結果、データレコードのクライアントとサーバーのビューを記述し、変換を指定するための新しい特殊なプログラミング言語であるAデータ言語（ADL）[15]に基づく包括的なデータ記述および変換アーキテクチャ（ DD ^＆ C） [ ^14]が定義されました。コンパイルされたADLプログラムは、サーバーからレコードが流れたりサーバーからレコードが流れたりするときに必要な変換を実行するためにサーバーによって呼び出されます。

DD&Cアーキテクチャはさらに進んで、プログラミング言語の宣言文をADLに、またはADLから自動的に変換し、あるプログラミング言語から別のプログラミング言語に変換する手段を定義しました。この機能は、その複雑さとコストのため実装されませんでした。しかし、ADLコンパイラが作成され、利用可能な場合はADLプログラムが呼び出され、DFMとIBM 4680ストアシステムによって変換が実行されます。^[16]ただし、アプリケーションプログラマはADLプログラムを手動で記述する必要があります。

次の IBM 製品は、DDM アーキテクチャのさまざまなサブセットを実装しました。

• IBM システム/370
  • MVS (MVS/SP、MVS/ESA)
    • データベース 2 - DRDA クライアントとサーバー
    • CICS - CICSトランザクション処理環境内のレコードファイルサーバー。CICS for z/OS V5.2以降では廃止されました。^[17]
  • VM (オペレーティング システム) (VM/SP、VM/ESA)
    • SQL/DS - DRDA クライアントとサーバー
  • DOS/VSE
    • CICS - CICSトランザクション処理環境内のレコードファイルサーバー。CICS for z/VSE V2.1以降では廃止されました。^{[18] [19]}
  • オペレーティングシステム
    • 分散ファイル管理 - レコードファイルサーバー
    • データベース 2 - DRDA クライアントとサーバー
• システム/36
  • システムサポートプログラム- レコードファイルクライアントとサーバー
• System/38およびその後継製品: AS/400、iSeries、Power Series
  • レコードファイルクライアントとサーバー
  • ディレクトリとストリームファイルのクライアントとサーバー
  • DRDAクライアントとサーバー
• IBM パーソナルコンピュータ
  • PCDOS の場合
    • Netview/PC - ディレクトリおよびストリーム ファイル クライアントとサーバー
    • DDM/PC - ディレクトリおよびストリーム ファイル クライアント。
    • PC サポート/36 - ディレクトリおよびストリーム ファイル クライアント。
    • PC Support/400 - ディレクトリおよびストリーム ファイル クライアント。
  • パーソナルシステム/2 - OS/2
    • PC/Support/400 - ストリームファイルとディレクトリのクライアントとサーバー
    • DRDAクライアントとサーバー
• IBM 4680およびIBM 4690ストア システム
  • レコードファイルクライアントとサーバー
  • ディレクトリとストリームファイルのクライアントとサーバー
• RS/6000 オペレーティングシステム
  • DRDAクライアントとサーバー

DRDA を実装した製品の完全なリストについては、オープン ソース DRDA 製品識別子テーブルを参照してください。

• レコード指向ファイルシステム