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

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

メディアにおける DDM アーキテクチャ。

分散アプリケーション

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

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

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

DDMアーキテクチャが提供する利点

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

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

歴史

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

初期の取り組み

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

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

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

しかし、ゴールデンゲートのプランナー、ジョン・ボンディは揺るぎない信念を持ち、経営陣を説得してロチェスター研究所の通常の管理範囲外に新しい部門を設立させました。これにより、事前定義されたビジネスケースを直ちに必要とする必要がなくなりました。さらに、彼はその部門の任務を分散データ管理（DDM）、特にレコード指向ファイルのサポートのみに限定しました。そして、経験豊富なソフトウェアアーキテクトのリチャード・A・デマーズを説得し、DDMアーキテクチャの定義とIBMシステムハウスへのDDMの提案という任務に加わらせました。

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

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

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

DDM レベル 1: レコード指向ファイル

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

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

リチャード・サンダースがDDMアーキテクチャチームに加わり、ローレンスとデマーズと共にSystem/36 DDMに必要な特定のメッセージを定義しました。DDMの定義が進展したことで、System/38も参加することになりました。これにより、DDMレコードファイルのサポート範囲が広がり、System/38の高度なファイルシステムの多くの要件を満たすようになりました。

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

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

DDM アーキテクチャのレベル 1 は 1986 年に正式に公開されました。この発表時に、IBM はKenneth Lawrence にOutstanding Technical Achievement Award 、Richard Sanders にOutstanding Contribution Award、 Richard Demers にOutstanding Innovation Award を授与しました。

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

DDM レベル 2: 階層ディレクトリとストリーム指向ファイル

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

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

DDM レベル 3: リレーショナル データベース サービス

1986年、IBMは4つの異なるリレーショナルデータベース（RDB）製品を発売しました。それぞれ特定のIBMオペレーティングシステム向けに構築されていました。IBMのアルマデン研究所の科学者たちは、分散型RDBのプロトタイプであるSystem/R*を開発しており、今こそ市場価値のある製品に仕上げる時だと考えていました。しかし、System/R*はRDBの研究用プロトタイプであるSystem/Rをベースとしており、IBM RDB製品に容易に追加することはできませんでした。 分散処理環境におけるRDBに関する議論については、 [ 6 ]を参照してください。

IBMサンタテレサ・プログラミング・センターのロジャー・ラインシュは、分散リレーショナル・データベース・アーキテクチャ（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の設計に携わった主要な関係者に賞が授与されました。リチャード・サンダース氏は優秀貢献賞を、ロジャー・ラインシュ氏とリチャード・デマーズ氏は優秀イノベーション賞を受賞しました。

DDM レベル 4: 追加サービス

分散ファイル管理（DFM）[ 8 ]プロジェクトは、IBMのMVSオペレーティングシステムにDDMサービスを追加し、リモートコンピュータ上のプログラムがVSAMファイルを作成、管理、アクセスできるようにするために開始されました。DFMプロジェクトのマネージャであるジョン・ハファードは、システム間でやり取りされるレコード内のデータフィールドを変換する手段をDDMアーキテクチャチームに求めました。リチャード・デマーズがこの問題の主導権を握り、DFMプロジェクトの山口耕一の支援を受けました。「データ記述と変換」を参照してください。

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

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

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

DDM レベル 5: 図書館サービス

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

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

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

DDM内部

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

DDMの仕組み

DDM処理の概要

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

  1. アプリケーションプログラムは、ローカルリソースマネージャ（LRM）が提供するプログラミングインターフェースを介して、ファイルなどのローカルリソースと対話します。ただし、必要なリソースがリモートコンピュータにある場合は、DDM が対話を仲介します。アプリケーションプログラムは LRM が提供するインターフェースを引き続き使用しますが、それらは DDM クライアントにリダイレクトされます。DDM アーキテクチャでは、リモートリソースのディレクトリをサポートしていないため、このリダイレクトがどのように行われるかは指定されていません。いくつかの DDM ファイル指向製品で使用されているリダイレクト方法の 1 つは、アプリケーションで特別なローカルファイル（ System/38 ではDDM ファイルと呼ばれます）を開くことです。このファイルは、リモートファイルの場所とアクセス情報を提供します。その後、DDM クライアントへのリダイレクトが行われます。
  2. DDMアーキテクチャは、ファイル、リレーショナルデータベース、アクセスメソッドなどのマネージャレベルのエンティティを定義します。クライアントリソースマネージャ（CRM）は、クライアントシステムのLRMで定義された機能インターフェースをポリモーフィックにサポートします。CRMの主な機能は、各機能インターフェースに対して適切な線形化されたDDMコマンドとデータオブジェクトを生成することです。（DDMメッセージを参照してください。）これらのオブジェクトは、リモートDDMサーバーのサーバーリソースマネージャ（SRM）に送信されます。ただし、実際には、DDMクライアントおよびサーバーのエージェントとコミュニケーションマネージャを経由してルーティングされます。
  3. DDMクライアントエージェントは、線形化されたコマンドをRQSDSSエンベロープに、線形化されたオブジェクトをリンクされたOBJDSSエンベロープに格納します。（DDMメッセージを参照してください。）クライアントエージェントはサーバーエージェントと連携して、CRMから受信したメッセージをSRMに送るためのパスを作成します。アプリケーションプログラムが単一のリモートリソースとのみ連携する必要がある場合、これは簡単です。ただし、アプリケーションプログラムは複数のリモートシステムに存在するさまざまな種類の複数のリソースと同時に連携することも可能です。クライアントエージェントは、すべてのケースにおいてアプリケーションプログラムを代表し、各リソースへのメッセージを個別の仮想パスにルーティングします。
  4. クライアント通信マネージャは、サーバー通信マネージャと連携して、「私が話している間にあなたが聞き、あなたが話している間に私が聞いている」という形式の会話プロトコルを実装します。IBM の SNA APPC やインターネットの TCP/IP プロトコルなど、さまざまな通信プロトコルを使用できます。
  5. サーバー通信マネージャに送信されたDDMメッセージは、メッセージで指定されたパス上のサーバーエージェントに渡され、サーバーエージェントは同じパス上のSRMにメッセージを転送します。サーバーエージェントが単一のパス上の単一のクライアントと通信している場合は、この処理は単純です。ただし、サーバーエージェントは複数のパス上の複数のクライアントと通信することもできます。
  6. サーバーリソースマネージャ（SRM）はDDMメッセージを解析し、要求を実行するために何をすべきかを決定します。SRMは、サーバーシステムの対応するローカルリソースマネージャ（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製品はホストシステムに特有の言語と手法を用いて実装されています。Object Technology InternationalはIBM PC向けにDDMのSmalltalkバージョンを開発し、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 Database 2は、DRDAに必要なDDMのサブセットのみをクライアントとサーバーでサポートします。
  • シーケンシャル ファイルからレコードをロードおよびアンロードする機能など、マネージャーの選択されたコマンドのみをサポートします。
  • 「レコードの取得」コマンドの「非アクティブなレコードを返す」パラメータなど、コマンドの選択されたパラメータをサポートします。

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

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

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

DDMメッセージ

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

これらの線形化されたオブジェクトはすべて、クライアント エージェントとサーバー エージェントが処理を調整できるようにエンベロープに入れられます。DDM アーキテクチャでは、これらのエンベロープはデータ ストリーム構造(DSS) と呼ばれます。コマンドは要求 DSS (RQSDSS) に入れられ、応答は応答 DSS (RPYDSS) に入れられ、その他のオブジェクトはオブジェクト DSS (OBJDSS) に入れられます。RQSDSS に入れることができるコマンドは 1 つだけ、RPYDSS に入れることができる応答は 1 つだけですが、レコードなどの複数のオブジェクトを 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 ファイル モデル

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

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

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

レコード指向ファイル

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

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

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

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

DDMアーキテクチャは、レコード指向ファイルを様々な方法で操作するための多様なアクセス方式も定義しています。アクセス方式とは、OPENコマンドによって作成されたファイルの使用インスタンスであり、クライアントがファイルの使用権限を持っているかどうかを判断した後、自身をファイルに接続します。アクセス方式は、CLOSEコマンドによってファイルから切断されます。

アクセスメソッドは、カーソルを用いて現在処理中のレコードを追跡します。各種SETコマンドを使用することで、カーソルをファイルの先頭または末尾、ファイル内の次または前の連続レコード、特定のキー値を持つレコード、あるいはキーの順序に従って次または前のレコードに指定することができます。

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

ストリーム指向ファイル

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

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

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

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

階層ディレクトリ

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

DDMキュー

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

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

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

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

リレーショナルデータベース

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

The Distributed Relational Database Architecture (DRDA) fits nicely into the overall DDM framework, as discussed in Object-Orientation. (However, DDM can also be viewed as a component architecture of DRDA since other specifications are also required [2]). The DDM manager-level objects supporting DRDA are named RDB (for relational database) and SQLAM (for SQL Application Manager).

Data description and conversion

Transparency is a key objective of DDM architecture. Without recompilation, it should be possible to redirect existing application programs to the data management services of a remote computer. For files, this was largely accomplished by DDM clients at the interface/functional level, but what about the data fields in a record? Complete transparency requires that client application programs be able to write and read fields as encoded by their local data management system, regardless of how any remote server encodes them, and that implies automatic data conversions.

For example, IBM mainframe computers encode floating point numbers in hexadecimal format and character data in EBCDIC, while IBM Personal computers encode them in IEEE format and ASCII. Further complexity arose because of the ways in which various programming language compilers map record fields onto strings of bits, bytes, and words in memory. Transparent conversion of a record requires detailed descriptions of both the client view and the server view of a record. Given these descriptions, the fields of the client and server views can be matched, by field name, and appropriate conversions can be performed.

The key issue is obtaining sufficiently detailed record descriptions, but record descriptions are generally specified abstractly in application programs by declaration statements defined by the programming language, with the language compiler handling encoding and mapping details. In a distributed processing environment, what is needed is a single, standardized way of describing records that is independent of all programming languages, one that can describe the wide variety of fixed and varying length record formats found in existing files.

The result was the definition of a comprehensive Data Description and Conversion architecture (DD&C),[14] based on a new, specialized programming language, A Data Language (ADL),[15] for describing client and server views of data records and for specifying conversions. Compiled ADL programs can then be called by a server to perform necessary conversions as records flowed to or from the server.

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

製品の実装

IBMのDDM製品

次の IBM 製品では、DDM アーキテクチャのさまざまなサブセットが実装されています。

  • IBM システム/370
  • システム/36
  • System/38およびその後継機種: AS/400、iSeries、Power Series
    • レコードファイルクライアントとサーバー
    • ディレクトリとストリームファイルのクライアントとサーバー
    • DRDAクライアントとサーバー
  • IBMパーソナルコンピュータ
    • PC DOS
      • Netview/PC - ディレクトリおよびストリームファイルクライアントとサーバー
      • DDM/PC - ディレクトリおよびストリーム ファイル クライアント。
      • PC サポート/36 - ディレクトリおよびストリーム ファイル クライアント。
      • PC Support/400 - ディレクトリおよびストリーム ファイル クライアント。
    • パーソナルシステム/2 - OS/2
      • PC/Support/400 - ストリームファイルとディレクトリのクライアントとサーバー
      • DRDAクライアントとサーバー
  • IBM 4680およびIBM 4690ストア システム
    • レコードファイルクライアントとサーバー
    • ディレクトリとストリームファイルのクライアントとサーバー
  • RS/6000 AIX
    • DRDAクライアントとサーバー

他社のDDM製品

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

参照

参考文献

  1. ^ a b分散データ管理アーキテクチャー レベル3: 一般情報IBM Corp. GC21-9527-02. 1990年7月.
  2. ^ a b c Demers, RA, JD Fisher, SS Gaitonde, RR Sanders (1992). 「IBMの分散データ管理アーキテクチャの内側」IBM Systems Journal . 31 (3): 459– 487. doi : 10.1147/sj.313.0459 .{{cite journal}}: CS1 maint: 複数の名前: 著者リスト (リンク)
  3. ^ Demers, RA (1988). 「SAA用分散ファイル」. IBM Systems Journal . 27 (3): 348– 361. doi : 10.1147/sj.273.0348 .
  4. ^ Deinhart, K. (1992). 「CICS環境へのSAA分散ファイルアクセス」. IBM Systems Journal . 31 (3): 516– 534. doi : 10.1147/sj.313.0516 .
  5. ^ iSeries 分散データ管理(PDF) . IBM Corp. 2001.
  6. ^ Reinsch, R. (1988). 「SAA向け分散データベース」IBM Systems Journal . 27 (3): 362– 389. doi : 10.1147/sj.273.0362 .
  7. ^分散リレーショナルデータベースアーキテクチャリファレンス. IBM Corp. SC26-4651-0. 1990.
  8. ^ 「z/OS DFSMS DFM ガイドおよびリファレンス」(PDF) 。 2022年1月21日時点のオリジナル(PDF)からアーカイブ。 2014年7月4日閲覧。
  9. ^ Goldberg, A.; Robson, D. (1983). Smalltalk-80 言語とその実装. Addison-Wesley. ISBN 0-201-11371-6。
  10. ^ 「OS/400 オブジェクト」。
  11. ^ a b分散データ管理アーキテクチャー レベル3: プログラマーズ・ガイド. IBM Corp. SC21-9529. 1990.
  12. ^分散データ管理アーキテクチャー レベル3: リファレンスIBM Corp. SC21-9526-03. 1990.
  13. ^分散データ管理アーキテクチャー レベル4: リファレンスIBM Corp. SC21-9526-05. 1990.
  14. ^ Demers, RA; Yamaguchi, K. (1992). 「データ記述と変換アーキテクチャー」. IBM Systems Journal . 31 (3): 488– 515. doi : 10.1147/sj.313.0488 .
  15. ^分散データ管理アーキテクチャー：データ言語の仕様。IBM Corp. SC21-8286。1992年。
  16. ^ 「4680 DDM ユーザーズ・ガイド」(PDF) . IBM Corp. 1991.
  17. ^ 「IBM CICS Transaction Server for z/OS V5.2は、サービス俊敏性、運用効率、クラウド対応を新たなレベルに引き上げます」。IBM 。2014年4月7日。2016年4月14日閲覧。CICS DDMは2003年12月31日をもってIBMから提供されなくなり、サポートも終了しました。CICS TSバージョン5.2以降では、CICS DDMは利用できなくなりました。
  18. ^ 「IBM z/VSE Central Functions バージョン 9.2 - z/VSE バージョン 5.2」。IBM 。2014年4月7日。2016年4月14日閲覧。CICS Distributed Data Management (DDM) のサポートは、CICS TS for VSE/ESA V1.1.1 で安定化されています。CICS TS for z/VSE の将来のリリースでは、IBM は CICS DDM のサポートを終了する予定です。
  19. ^ 「IBM CICS Transaction Server for z/VSE V2.1は将来のワークロードに対応する機能強化を提供」 IBM 2015年10月5日2016年4月14日閲覧CICS Distributed Data Management (CICS/DDM)はCICS TS for z/VSE V2.1ではサポートされていません。
「 https://en.wikipedia.org/w/index.php?title=Distributed_Data_Management_Architecture&oldid=1312665614#Stream-oriented_files」から取得