イベント処理
コネクターは、イベント処理のときに、プロトコル・リスナーおよび構成済みデータ・ハンドラー
を使用して、HTTP サービス・クライアントからの要求メッセージを、コラボレーションが取り扱うことのできるビジネス・オブジェクトに変換します。プロトコル・リスナーは、イベント処理において極めて重要な役割を果たしています。
プロトコル・リスナー
HTTP 要求は、HTTP または HTTPS のトランスポートによって届きます。リスナーは、トランスポート・チャネルに
このような要求が到着するのをモニターします。プロトコル・リスナーには次の 2 種類があり、それぞれに対応するチャネルがあります。
- HTTP プロトコル・リスナー
- HTTPS プロトコル・リスナー
これらの各リスナーは、トランスポートで listen するスレッドで構成されます。クライアントから要求メッセージを受け取ると、リスナーは、プロトコル・リスナー・フレームワークにそのイベントを登録します。
プロトコル・リスナー・フレームワークは、プロトコル・リスナーを管理し、リソースが使用可能になったときに要求を処理するようにスケジューリングします。コネクター固有のプロパティーに値を設定するときに、プロトコル・リスナー・フレームワークのリスナーおよび性質を構成してください。構成可能なプロトコル・リスナー・フレームワークのプロパティーには、以下のものが含まれます。
- WorkerThreadCount プロトコル・リスナー・フレームワーク
が使用することのできるスレッドの合計数。これは、プロトコル・リスナー・フレームワークが
同時に処理できる要求の数です。
- RequestPoolSize プロトコル・リスナー・フレームワーク
に登録できる要求の最大数。この最大数を超える要求を受け取ると、新規要求は登録されなくなります。
これら 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/xml、text/plain など) の場合、ISO-8859-1 にデフォルト設定されます。
それ以外の場合、Charset は使用されません。 |
ContentType にデフォルト設定されます |
|
|
表 26 は次のことを示しています。
- プロトコル・リスナーは、以下のルールに従って、インバウンド・メッセージの Charset を判別します。
- リスナーは、HTTP メッセージの Content-Type ヘッダー値の文字セット・パラメーター
から Charset を抽出しようとします。
- Content-Type ヘッダーから Charset 値を取得できない場合、プロトコル・リスナーは、このリスナーの URLsConfiguration プロパティー値を読み取ろうとします。
- 前のステップで説明した方法で Charset 値が取得できない場合で、メッセージ・タイプ ContentType が、サブタイプの付いた text (text/xml、text/plain など) のときは、リスナーは、ISO-8859-1 のデフォルトの Charset 値を使用します。
それ以外の場合、Charset 値は使用されません。
- リスナーは、以下のルールに従って、応答メッセージの MimeType を判別します。
- 着信要求メッセージによって使用される URL の TransformationRule が構成されており、要求 ContentType が TransformationRule の ContentType と一致する場合、リスナーは TransformationRule を使用して、要求メッセージを要求ビジネス・オブジェクトに
変換するための MimeType を抽出します。リスナーは、要求された URL の URLsConfiguration プロパティーの ContentType (text/xml など) に基づいて、正確な TransformationRule 一致を見つけようとします。
- これに失敗すると、リスナーは、要求 URL で複数の ContentType (*/* など) に適用される
TransformationRule を見つけようとします。
- ここまでのすべてのステップで MimeType を判別できない場合、データ・ハンドラーを呼び出し、要求メッセージを要求ビジネス・オブジェクトに変換するために、ContentType の値が MimeType として使用されます。
- リスナーは、着信 HTTP メッセージの Content-Type ヘッダーからタイプ/サブタイプを抽出して、ContentType を判別します。
- リスナーは、着信 HTTP メッセージの Content-Type ヘッダーから、Content-Type ヘッダーを判別します。
コラボレーションを非同期に呼び出す場合、リスナーは、要求ビジネス・オブジェクトを統合ブローカーに配信し、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 は次のことを示しています。
- リスナーは、以下のルールに従って、応答メッセージの Charset を判別します。
- Charset が応答ビジネス・オブジェクトのプロトコル構成 MO に指定されている場合、その値が使用されます。
- Charset 値が応答ビジネス・オブジェクトのプロトコル構成 MO ヘッダーに
指定されていない場合、リスナーは、Charset が TLO で指定されているかどうかを検査します。
- Charset が TLO で指定されておらず、応答が要求と同じ ContentType を持つ場合、応答には、要求の Charset が使用されます。
- これまでのステップで応答の Charset 値を判別できず、メッセージ・タイプ部分の ContentType が、なんらかのサブタイプが付いた text (text/xml、text/plain など) の場合、リスナーは ISO-8859-1 のデフォルトの Charset 値を使用します。
それ以外の場合、Charset 値は使用されません。
- リスナーは、以下のルールに従って、応答メッセージの MimeType を判別します。
- TLO の MimeType 属性
- TLO の MimeType 属性がなく、要求と応答の ContentType が一致する場合、リスナーは、応答メッセージに要求の MimeType を使用します。
- それ以外の場合、リスナーは ContentType 値を MimeType として使用します。
- リスナーは、以下のルールに従って、応答メッセージの ContentType を判別します。
- Content-Type ヘッダーが応答ビジネス・オブジェクトのプロトコル構成 MO で指定されている場合、Content-Type ヘッダーのタイプ/サブタイプ部分が ContentType として使用されます。
- Content-Type ヘッダーが応答ビジネス・オブジェクトのプロトコル構成 MO で指定されていない場合、リスナーは、判別した ContentType および Charset (応答メッセージで Charset が判別した場合) を使用して、Content-Type ヘッダーを構成します。
リスナーは HTTP プロトコル構成 MO を処理します。HTTP プロトコル構成 MO で渡されるヘッダー値
が、要求応答イベントのコンテキストにおいて正しくなるようにするのは、コラボレーションの責任です。
リスナーは、以下のルールに従って、標準ヘッダーおよびカスタム・プロパティーのデータを
取り込みます。
- リスナーは、特殊な属性 (ObjectEventId など) を無視するために、HTTP プロトコル構成 MO の各項目を調べます。
- 空でない各ヘッダーが発信メッセージに置かれ、追加処理 (Content-Type ヘッダーなど) が行われます。
- 上記の方法では、リスナーは、メッセージに非標準のヘッダーを設定する場合がありますが、メッセージが論理的または文法的に正しいかどうかは検査しないことに注意してください。
- 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 プロトコル・リスナーは、以下の機能はサポートしていません。
- キャッシング: プロトコル・リスナーは、HTTP 仕様 (RFC2616) で定義されている
キャッシング機能は実行しません。
- プロキシー: プロトコル・リスナーは、HTTP 仕様 (RFC2616) で定義されている
プロキシー機能は実行しません。
- 持続接続: プロトコル・リスナーは、HTTP 仕様 (RFC2616) で定義されている
持続接続はサポートしていません。その代わりに、プロトコル・リスナーは、各 HTTP 接続の範囲を単一クライアント要求とみなし、サービス要求が完了すると、接続を閉じます。プロトコル・リスナーは、その接続を、別のサービス呼び出しに再使用しようとはしません。
- リダイレクト: プロトコル・リスナーは、リダイレクトはサポートしていません。
- 大規模ファイル転送: プロトコル・リスナーは、大規模ファイル転送には使用できません。
その代わりに、参照によって、大規模ファイルの引き渡しを行うことができます。
- 状態管理: プロトコル・リスナーは、RFC2965 に記載されている HTTP 状態管理機構はサポートして
いません。
- Cookies: プロトコル・リスナーは、Cookies はサポートしていません。
セキュア・ソケットを使用した HTTPS リスナー処理
HTTPS プロトコル・リスナー処理は HTTP プロトコル・リスナー処理のセクションで説明されているとおりですが、HTTPS ではセキュア・ソケットを使用するという点が異なります。詳しくは、SSLを参照してください。
イベントの永続性と送達
イベントの永続性は、プロトコルによって決まります。
- HTTP プロトコル・リスナー 永続性がなく、送達は保証されません
- HTTPS プロトコル・リスナー 永続性がなく、送達は保証されません
イベントの順序付け
コネクターは、任意の順序でイベントを配送することができます。
イベントのトリガー
イベント・トリガーのメカニズムは、プロトコル・リスナーの構成方法によって異なります。
- HTTP プロトコル・リスナー HTTP 接続要求の
場合、listen は ServerSocket を介して行われます。
- HTTPS プロトコル・リスナー HTTPS 接続要求の
場合、listen は ServerSocket 層を介して行われます。
注:
コネクターは、Create (作成)、Update (更新)、Retrieve (検索) または Delete (削除) の区別を行いません。これらのイベントは、すべて同じ方法で扱われます。
イベントの検出
イベントの検出は、それぞれのプロトコル・リスナーによって行われます。イベント検出のメカニズムは、トランスポート、および各リスナーごとの
コネクター固有プロパティーの構成方法に、完全に依存しています。これらのプロパティーの詳細については、コネクター固有の構成プロパティーを参照してください。
イベント状況
イベント状況はプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。
- HTTP プロトコル・リスナー HTTP は本来、非永続的で同期的なものです。したがって、イベント状況は維持されません。
- HTTPS プロトコル・リスナー HTTP は本来、非永続的で同期的なものです。したがって、イベント状況は維持されません。
イベントの検索
イベントの検索はプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。
- HTTP プロトコル・リスナー イベントの検索は、ソケットから HTTP 要求を取り出すことによって行われます。
- HTTPS プロトコル・リスナー イベントの検索は、ソケットから HTTP 要求を取り出すことによって行われます。
イベントのアーカイブ
イベントのアーカイブはプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。
- HTTP プロトコル・リスナー トランスポートが非永続的であり、同期的であるため、アーカイブは行われません。
- HTTPS プロトコル・リスナー トランスポートが非永続的であり、同期的であるため、アーカイブは行われません。
イベントのリカバリー
イベントのリカバリーはプロトコル・リスナーによって管理され、トランスポート、およびリスナーの構成方法によって異なります。
- HTTP プロトコル・リスナー トランスポートが非永続的であるため、イベント・リカバリーは行われません。
- HTTPS プロトコル・リスナー トランスポートが非永続的であるため、イベント・リカバリーは行われません。
