イベント処理

コネクターは、イベント処理のときに、プロトコル・リスナーおよび構成済みデータ・ハンドラー を使用して、HTTP サービス・クライアントからの要求メッセージを、コラボレーションが取り扱うことのできるビジネス・オブジェクトに変換します。プロトコル・リスナーは、イベント処理において極めて重要な役割を果たしています。

プロトコル・リスナー

HTTP 要求は、HTTP または HTTPS のトランスポートによって届きます。リスナーは、トランスポート・チャネルに このような要求が到着するのをモニターします。プロトコル・リスナーには次の 2 種類があり、それぞれに対応するチャネルがあります。

これらの各リスナーは、トランスポートで listen するスレッドで構成されます。クライアントから要求メッセージを受け取ると、リスナーは、プロトコル・リスナー・フレームワークにそのイベントを登録します。

プロトコル・リスナー・フレームワークは、プロトコル・リスナーを管理し、リソースが使用可能になったときに要求を処理するようにスケジューリングします。コネクター固有のプロパティーに値を設定するときに、プロトコル・リスナー・フレームワークのリスナーおよび性質を構成してください。構成可能なプロトコル・リスナー・フレームワークのプロパティーには、以下のものが含まれます。

これら 2 種類のコネクター固有のプロパティーは、プロトコル・リスナーが際限なくイベントを発生させて コネクターをふさいでしまわないように、メモリー割り振りを制御します。この割り振りアルゴリズムは、「コネクターは、WorkerThreadCount + RequestPoolSize に等しいイベントの合計数を常に受信できる」というものです。ここでは、WorkerThreadCount 数の要求を並行して処理できます。

追加のプロトコル・リスナーをプロトコル・リスナー・フレームワークに接続することができます。詳しくは、複数のプロトコル・リスナーの作成および コネクター固有の構成プロパティーを参照してください。

HTTP および HTTPS プロトコル・リスナー処理

HTTP(S) プロトコル・リスナーは、クライアントの HTTP(S) 要求について継続的に listen するスレッドから構成されています。リスナー・スレッドは、コネクター固有の構成 (リスナー) プロパティー Host および Port で指定されているホストとポートをバインドします。別の構成プロパティー (RequestWaitTimeout) は、コネクターがシャットダウンされたかどうか確認するまでリスナーが要求を待つインターバルを定義します。

図 14 は、同期操作のための HTTP プロトコル・リスナー処理を表しています。

図 14. HTTP プロトコル・リスナー: 同期イベント処理

図 15 は、非同期操作のための HTTP プロトコル・リスナー処理を表しています。

図 15. HTTP プロトコル・リスナー: 非同期イベント処理

クライアントは、HTTP または HTTPS 要求を開始する場合、要求メッセージを HTTP または HTTPS リスナーに通知します。プロトコル・リスナー URL を呼び出すためには、クライアントは HTTP POST メソッドを使用する必要があります。

HTTP(S) 要求が到着すると、リスナーは、要求をプロトコル・リスナー・フレームワークに登録し、リソースが使用可能になったときにイベントを処理するようにスケジュールします。リスナーは、次に、要求からプロトコル・ヘッダーとペイロードを抽出します。

表 26 は、リスナーが、インバウンド・メッセージの Charset、MimeType、ContentType、Content-Type ヘッダーを判別するときに 使用するルールの優先順位の要約です。

表 26. HTTP(s) プロトコル・リスナーによる、インバウンド・メッセージの処理ルール
優先順位の順序 Charset MimeType ContentType Content-Type ヘッダー
1 着信 HTTP メッセージの Content-Type ヘッダー値の Charset パラメーター値 このリスナーの URLsConfiguration コネクター・プロパティー値 Content-Type ヘッダー値の、着信 HTTP メッセージのタイプ/サブタイプの値 着信 HTTP メッセージの Content-Type ヘッダー
2 このリスナーの URLsConfiguration プロパティー値
3 要求メッセージのタイプ ContentType がサブタイプの付いた text (text/xmltext/plain など) の場合、ISO-8859-1 にデフォルト設定されます。 それ以外の場合、Charset は使用されません。 ContentType にデフォルト設定されます

表 26 は次のことを示しています。

コラボレーションを非同期に呼び出す場合、リスナーは、要求ビジネス・オブジェクトを統合ブローカーに配信し、HTTP 状況コード 202 Accepted でクライアントに応答します。これでリスナー処理が完結します。

同期呼び出しの場合は、リスナーは同期させてコラボレーションを呼び出します。コラボレーションは応答ビジネス・オブジェクトを使用して応答します。

表 27 は、リスナーが、応答メッセージの Charset、MimeType、ContentType、Content-Type ヘッダーを判別するときに 使用するルールの優先順位の要約です。

表 27. HTTP(s) プロトコル・リスナーによる、アウトバウンド同期応答メッセージの処理ルール
優先順位の順序 Charset MimeType ContentType Content-Type ヘッダー
1 Protocol ConfigMO Content-Type ヘッダー TLO の MimeType プロパティー Protocol ConfigMO Content-Type ヘッダー Protocol ConfigMO Content-Type ヘッダー
2 TLO の Charset プロパティー値 要求メッセージの MimeType。ただし、要求と応答の ContentType が一致する場合のみ。 要求メッセージの ContentType ContentType および Charset を使用して、Content-Type ヘッダーを構成
3 要求メッセージの Charset。ただし、要求と応答の ContentType が一致する場合のみ。 ContentType 値を MimeType として使用
4 ContentType が text/* の場合、ISO-8859-1 にデフォルト設定される。 それ以外の場合、Charset は使用されません。

表 27 は次のことを示しています。

リスナーは HTTP プロトコル構成 MO を処理します。HTTP プロトコル構成 MO で渡されるヘッダー値 が、要求応答イベントのコンテキストにおいて正しくなるようにするのは、コラボレーションの責任です。 リスナーは、以下のルールに従って、標準ヘッダーおよびカスタム・プロパティーのデータを 取り込みます。

  1. リスナーは、特殊な属性 (ObjectEventId など) を無視するために、HTTP プロトコル構成 MO の各項目を調べます。
  2. 空でない各ヘッダーが発信メッセージに置かれ、追加処理 (Content-Type ヘッダーなど) が行われます。
  3. 上記の方法では、リスナーは、メッセージに非標準のヘッダーを設定する場合がありますが、メッセージが論理的または文法的に正しいかどうかは検査しないことに注意してください。
  4. HTTP プロトコル構成 MO の UserDefinedProperties 属性に 1 つ以上のカスタム・プロパティーが ある場合、リスナーは、それらを Entity Headers Section (最後のヘッダー・セクション) に追加します。カスタム・プロパティーの詳細については、イベント処理のユーザー定義プロパティーを参照してください。

注:
HTTP プロトコル構成 MO で、Connection、Trailer、Transfer-Encoding、 Content-Encoding、Content-Length、Content-MD5、Content-Range のいずれかのヘッダーを指定すると、誤った HTTP メッセージになる可能性が非常に高くなります。

リスナーは、次に、データ・ハンドラーを呼び出して、コラボレーションによって戻された応答ビジネス・オブジェクトを応答メッセージに変換します。

リスナーは、応答メッセージをクライアントに配信し、200 OK HTTP 状況コードを組み込みます。コラボレーションにより障害ビジネス・オブジェクトが戻された場合は、障害メッセージに変換されます。この障害メッセージは、500 Internal Server Error HTTP コードと共にクライアントに配信されます。

リスナーは、次に、接続を閉じ、イベントを処理したスレッドは使用可能になります。

HTTP プロトコル・リスナーのサポートされていない処理機能

HTTP プロトコル・リスナーは、以下の機能はサポートしていません。

セキュア・ソケットを使用した HTTPS リスナー処理

HTTPS プロトコル・リスナー処理は HTTP プロトコル・リスナー処理のセクションで説明されているとおりですが、HTTPS ではセキュア・ソケットを使用するという点が異なります。詳しくは、SSLを参照してください。

イベントの永続性と送達

イベントの永続性は、プロトコルによって決まります。

イベントの順序付け

コネクターは、任意の順序でイベントを配送することができます。

イベントのトリガー

イベント・トリガーのメカニズムは、プロトコル・リスナーの構成方法によって異なります。

注:
コネクターは、Create (作成)、Update (更新)、Retrieve (検索) または Delete (削除) の区別を行いません。これらのイベントは、すべて同じ方法で扱われます。

イベントの検出

イベントの検出は、それぞれのプロトコル・リスナーによって行われます。イベント検出のメカニズムは、トランスポート、および各リスナーごとの コネクター固有プロパティーの構成方法に、完全に依存しています。これらのプロパティーの詳細については、コネクター固有の構成プロパティーを参照してください。

イベント状況

イベント状況はプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。

イベントの検索

イベントの検索はプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。

イベントのアーカイブ

イベントのアーカイブはプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。

イベントのリカバリー

イベントのリカバリーはプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。

Copyright IBM Corp. 2004, 2005