1 プラグインの作成を開始する前に

この章は、サーバー・プラグインを実装するかどうかを決定する際に役立ちます。また、プラグインを実装することを選択した場合に、次に実行することについても説明します。

この章の内容は、次のとおりです。

• サーバー・プラグインを実装する状況

• プラグインとサーバーとの相互作用

• 使用例

• 次に実行すること

1.1 サーバー・プラグインを実装する状況

Directory Server固有の製品機能の多くは、サーバー・プラグインに依存しています。プラグインとは、特定のディレクトリ・サービス操作の主要部分を実行するためにサーバーに登録される、関数のライブラリです。

Directory ServerのプラグインAPIでは、製品の現在のリリースには含まれていないサーバー機能を追加するインタフェースが提供されます。必要な機能が実装されていないため、サーバー機能を追加する必要がある場合、プラグインAPIによってその拡張が可能になることがあります。製品の標準機能をかわりに使用できる場合は、プラグインは作成しないでください。

1.1.1 プラグインのメンテナンス

独自のプラグインを作成すると、ソフトウェア・ソリューションが特定の製品リリースに関連付けられることに注意してください。プラグインAPIは、新機能に対応するために、リリースごとに進化することがあります。新機能を活用するためにアップグレードすることを選択すると、Directory Serverプラグインを更新することが必要になる場合があります。

クラス・ライブラリを含むヘッダー・ファイルは、ソフトウェアのAPIとインタフェースするプログラムを作成して配布する目的でのみ使用できます。また、ライブラリを使用して、ソフトウェアのプラグインAPIとインタフェースする、プログラムのプラグインを作成して配布することもできます。ヘッダー・ファイルまたはライブラリを変更することはできません。オラクル社は、ソフトウェアの将来のリリースにおけるプラグインAPIの下位互換性について、直接的にも暗黙的にも保証しません。また、オラクル社は、派生するすべてのプラグインについてアップグレードまたはエラー修正をサポートしたり提供する義務を負いません。

テクニカル・サポートの担当者は、テクニカル・サポートを提供する場合に、カスタム・プラグインをオフにした後、問題を再現することを要求します。

1.2 プラグインとサーバーとの相互作用

Directory Serverインスタンスへのすべてのクライアント・リクエストは、特定の処理順序で処理されます。正確な順序は、クライアントによって要求された操作によって異なります。ただし、全体的な順序は類似しています。プラグインでのリクエストの処理方法は、クライアントでどのようにリクエストをエンコードするかには依存しません。つまり、Directory Serverとの通信に使用されるクライアント・アクセス・プロトコルに関係なく、クライアント・リクエスト・データは、プラグインによって、基本的に同じように認識されます。

一般的に、クライアント・リクエスト処理は次のように進行します。最初に、Directory Serverフロントエンドによってリクエストがデコードされます。コア・サーバーでは、デコードされたリクエストを処理し、エントリの検索や格納などに必要なバックエンド関数をコールします。Directory Serverバックエンドの主な機能は、エントリの取得および格納です。ただし、中止されないかぎり、クライアント・リクエストには、バックエンドで開始されたレスポンスが発生します。レスポンスはフロントエンドで書式設定され、クライアントに送信されます。

次の図は、クライアント・リクエスト・データがどのようにDirectory Server内を移動するかを示しています。

図1-1 クライアント・リクエスト処理

「図1-1 クライアント・リクエスト処理」の説明

一般的に、プラグインでは、クライアント・リクエストを処理する特定のステップでDirectory Serverによってコールされる関数を登録します。プラグインには、事前操作や事後操作などの特定のタイプがあります。事前操作プラグインでは、サーバーで処理される前に受信リクエストを処理する関数を登録します。たとえば、事前操作プラグインで、コア・サーバーがクライアント・バインドの処理を開始する前にコールされるバインド前関数を登録できます。クライアントがDirectory Serverに対して認証する方法をバインド前関数で再定義できるため、外部データベースに対する認証が可能となります。事後操作プラグインでは、リクエストが処理された後にコールされる関数を登録します。たとえば、事後操作プラグインで、変更リクエストに関する情報をログに記録するためにコールされる変更後関数を登録できます。「使用例」では、他のプラグイン・タイプの例を示しています。

2つの内部操作プラグイン・タイプが、クライアント・リクエスト処理を実行するために関数がコールされるというルールの例外となります。内部操作プラグインでは、Directory Serverの内部操作に対してトリガーされる関数を実装します。内部操作は、クライアント・リクエストではなく、Directory ServerまたはDirectory Serverによってコールされた別のプラグインが開始します。内部操作データを操作する場合には、注意が必要です。

次の表に、記載されているプラグイン関数タイプがDirectory Serverによりコールされる場合についてまとめます。

表1-1 サーバー・プラグイン・タイプ

プラグイン・タイプ	いつコールされるか
エントリ・ストア/フェッチ	ディレクトリ・エントリをディレクトリ・データベースに書き込む直前、またはディレクトリ・データベースから読み取った直後 タイプ: ldbmentryfetchstore
拡張操作	LDAP v3拡張操作を処理する場合 タイプ: extendedop
内部的な事後操作	Directory Serverによって開始された操作を完了した後(この操作に対応するクライアント・リクエストが存在しない場合) タイプ: internalpostoperation
内部的な事前操作	Directory Serverによって開始された操作を実行する前(この操作に対応するクライアント・リクエストが存在しない場合) タイプ: internalpreoperation
一致ルール	検索操作のみを対象として、拡張一致フィルタに基づいて検索結果候補を検索する場合 タイプ: matchingrule
オブジェクト	登録されている関数に応じて(このタイプは汎用的で、他のタイプを登録する場合に使用されます) タイプ: object
パスワード・チェック	追加または変更するuserPassword値について厳格なチェックを実行する場合 タイプ: passwordcheck
パスワード記憶スキーム	複合化できないエンコードされたuserPassword値を格納する場合 タイプ: pwdstoragescheme
事後操作	クライアントによって要求された操作を完了した後 タイプ: postoperation
事前操作	クライアントによって要求された操作を実行する前 タイプ: preoperation

次の図は、Directory Serverにより、表1-1で説明されているいくつかのプラグイン・タイプが、処理順序内のどこでコールされるかを示しています。

図1-2 プラグイン・エントリ・ポイント

「図1-2 プラグイン・エントリ・ポイント」の説明

事後操作のリターン・コードが、Directory Serverの処理に影響を及ぼすことはありません。

プラグイン・タイプおよびプラグイン構成情報は、通常、構成エントリで静的に指定されます。

単一の共有ライブラリに複数のプラグインを含めることができますが、静的に登録されるプラグインごとに、サーバー固有の構成エントリを個別に指定する必要があります。つまり、事前操作の関数と事後操作の関数が必要である場合は、通常、2つのプラグインを作成します。その後、各プラグインをDirectory Serverに登録します。両方のプラグインを同じ共有ライブラリに含めることができます。両方のプラグインで、同じ操作や接続を通してプライベート・データの通信を行い、提供されたインタフェースを使用できます。また、他のプラグインを初期化するプラグインを1つ作成することもできます(デプロイメントにこのような構成が必要な場合)。

製品に付属のサンプル・プラグインは、すべてのプラグインを1つのライブラリに構築した後、プラグインを個別に登録するという原則に従っています。

次の図は、同じライブラリに存在する複数のプラグインを示しています。

図1-3 共有ライブラリ内の複数のプラグイン

「図1-3 共有ライブラリ内の複数のプラグイン」の説明

各プラグインには、起動時にDirectory Serverによってコールされる登録ルーチンが含まれています。登録ルーチンにより、各プラグイン関数がDirectory Serverに明示的に登録されます。

注意: プラグイン・ライブラリはDirectory Serverに関連付けられています。プラグインは、Directory Serverと同じメモリー・アドレス領域で実行されます。プラグインは、Directory Serverで使用されるデータ構造体に直接アクセスできます。結果として、プラグインによって、Directory Serverで使用されるメモリーが破損する可能性があります。このようなメモリーの破損が原因で、データベースの破損が発生することがあります。このような危険が伴うため、本番のDirectory Serverでは、テストされていないプラグインを使用しないでください。 また、Directory Serverは、複数のスレッド・プロセスとして実行されます。プラグイン用に作成するコードは、再入可能である必要があります。複数のスレッドで、エントリ・ポイントを同時にコールできます。これらのスレッドはいつでも再スケジュールできます。

1.3 使用例

ジョブに適したプラグイン・タイプは、理論というより、経験に基づいて選択します。次の表は、記載されているプラグイン・タイプの使用例を示しています。

表1-2 タイプ別のプラグイン使用例

プラグイン・タイプ	使用例
エントリ・ストア/フェッチ	プラグイン・エントリ全体のエンコードおよびデコード エントリがディスクに書き込まれるときの、各エントリの監査またはロギング
拡張操作	LDAP v3で使用できないデジタル署名などのクライアント・サービスのリクエストおよびレスポンスでの追加
内部的な事後操作	別のプラグインによって開始された内部操作の結果の監査
内部的な事前操作	別のプラグインによって開始される内部的な割込み操作
一致ルール	ディレクトリ検索での、よく似た一致を検出する拡張機能の提供
オブジェクト	他のプラグインのグループをDirectory Serverに登録するプラグインの開発
パスワード・チェック	パスワード構文の企業ポリシーに対する新規パスワードでの確認の強制
パスワード記憶スキーム	標準製品によってサポートされるいずれかのアルゴリズムにかわる、パスワード暗号化でのカスタム・アルゴリズムの使用
事後操作	特定操作の後に送信されるアラートおよびアラームの関連付け 特定のエントリについての変更の監査 操作後のクリーンアップの実行
事前操作	ディレクトリ外部でのカスタム認証方式の処理 エントリを追加または変更する前の、属性値の構文チェックの強制 リクエストへの属性の追加またはリクエストからの属性の削除 従来のアプリケーションからのリクエストを変換するための、クライアント・リクエスト・コンテンツの事前処理 リクエストを処理する前の、クライアント変更リクエストのコンテンツの承認または却下

使用例のリストは包括的ではありませんが、かわりに、ソリューションの検討に役立ちます。

1.4 次に実行すること

このドキュメントの残りの部分では、主に、特定のプラグイン・タイプの具体例を示します。

注意: プラグインの開発は、本番サーバー上ではなく、プラグイン開発専用のテスト・サーバー上で行ってください。

1.4.1 開発環境の準備

Directory Serverソフトウェアがインストール済でない場合があります。プラグインの開発中に使用するC言語用の開発ソフトウェアがインストール済でない場合があります。ここで、ソフトウェアをインストールしてください。開発ツールおよび機能するDirectory Serverがないと、ここで説明する例を使用できません。

1.4.2 プラグイン開発の概要

今回のリリースでプラグインをまだ作成したことがない場合は、第3章「Directory Serverプラグインのスタート・ガイド」を参照してください。この章は、単純なプラグインを構築して、Directory Serverに登録する場合に役立ちます。

1.4.3 既存のプラグインのアップグレード

以前のリリースのDirectory Server用に開発されたプラグインをメンテナンスする場合、変更内容は、第2章「Directory Server 5.2以上のプラグインAPIへの変更」を参照してください。

1.4.4 サンプル・プラグインの試用

複数のプラグイン・タイプの例は、製品のinstall-path/examplesで提供されており、このサンプル・プラグインの使用例について、後続の章で説明します。

1.4.5 詳細

特定のデータ構造体、関数およびパラメータ・ブロック・セマンティクスの詳細は、「プラグインAPIリファレンス」を参照してください。