コネクターの要求処理機能を使用して、コラボレーションから HTTP サービスを呼び出すことができます。コネクターおよびその要求処理コンポーネント (プロトコル・ハンドラー・フレームワークおよびプロトコル・ハンドラー) を構成する必要があります。
コネクターは、実行時にビジネス・オブジェクトの形でコラボレーションから要求を受け取ります。 ビジネス・オブジェクト (要求、およびオプションとして、応答および障害のビジネス・オブジェクト) は、HTTP サービスを使用するように構成されたコラボレーション によって発行される TLO に含まれます。TLO およびその子ビジネス・オブジェクトには、処理モード (同期または非同期) を指定する属性および ASI、データ・ハンドラー MIME タイプ、使用するプロトコル・ハンドラーの種類、およびターゲットのアドレスが入っています。プロトコル・ハンドラーは、この情報を使用して、データ・ハンドラーのインスタンスを呼び出し、要求ビジネス・オブジェクトを要求メッセージに変換し、ターゲット HTTP サービスを呼び出します。同期モードの場合、プロトコル・ハンドラーは、データ・ハンドラーを再度呼び出し、応答メッセージを応答ビジネス・オブジェクトに変換して、これをコラボレーションに返送します。
コネクターは、要求メッセージに対する応答として、リモート側の取引先から次のいずれかを受け取ることができます。
プロトコル・ハンドラーは、要求処理において重要な役割を果たしています。
コラボレーションは、HTTP または HTTPS のトランスポートによって、HTTP サービスを呼び出します。コネクターは、1 つのプロトコル・ハンドラー (HTTP および HTTPS の サービスを呼び出す HTTP-HTTPS プロトコル・ハンドラー) と対応するチャネルを持っています。
プロトコル・ハンドラー・フレームワークはプロトコル・ハンドラーを管理し、起動時にプロトコル・ハンドラーをロードします。コネクターが要求ビジネス・オブジェクトを受け取ると、要求スレッド (それぞれのコラボレーション要求は、独自のスレッドで送られてきます) は、プロトコル・ハンドラー・フレームワークを呼び出して、要求を処理します。
プロトコル・ハンドラー・フレームワークは、TLOs Handler 属性 ASI を読み取り、使用するプロトコル・ハンドラーを決定します。 一連のルールを適用して (HTTP-HTTPS プロトコル・ハンドラー処理を参照)、プロトコル・ハンドラーはデータ・ハンドラーを呼び出し、要求ビジネス・オブジェクトを要求メッセージ に変換します。プロトコル・ハンドラーは、要求メッセージをトランスポート (HTTP(S)) メッセージにパッケージします。
次に、プロトコル・ハンドラーは、要求ビジネス・オブジェクトのプロトコル構成 MO の Destination 属性を読み取り、ターゲット・アドレスを判別します。プロトコル・ハンドラーは、次に、要求メッセージを使用してターゲット HTTP サービスを呼び出します。
プロトコル・ハンドラーは、ws_mode TLO ASI を読み取り、処理モードが同期または非同期のいずれであるかを判別します。この ASI が asynch に設定されていると、プロトコル・ハンドラー処理は完了します。このように設定されていない場合、プロトコル・ハンドラーは応答メッセージを待ちます。応答メッセージが到着すると、プロトコル・ハンドラーは、プロトコル・ヘッダーとペイロードを抽出します。次にデータ・ハンドラー (MimeType TLO 属性によって指示される) を呼び出して、メッセージを応答または障害ビジネス・オブジェクトに変換します。プロトコル・ハンドラーは、プロトコル構成 MO を再度使用して、プロトコル・ヘッダーをビジネス・オブジェクトに設定します。プロトコル・ハンドラーは、次に、応答または障害ビジネス・オブジェクトをコラボレーションに戻します。
コネクターの構成によっては、1 つまたは複数のプロトコル・ハンドラーが コネクターにプラグされている場合があります。コネクター固有のプロパティーを指定することにより、プロトコル・ハンドラーを構成することができます。
HTTP-HTTPS プロトコル・ハンドラーは、このセクションに記載している点を除き、プロトコル処理で説明しているように動作します。図 16 は、同期操作のための HTTP-HTTPS プロトコル・ハンドラーを表しています。
図 17 は、非同期要求処理のための HTTP-HTTPS プロトコル・ハンドラーを表しています。
HTTP-HTTPS プロトコル・ハンドラーは、要求ビジネス・オブジェクトのオブジェクト・レベル ASI (cw_mo_http) を使用して、プロトコル構成 MO を決定します。HTTP-HTTPS プロトコル・ハンドラーは、HTTP プロトコル構成 MO の Destination 属性を読み取り、ターゲット HTTP サービスの URL を決定します。URL が欠落している、あるいは不完全であれば、プロトコル・ハンドラーはサービス呼び出しで失敗します。 HTTP プロトコル構成 MO とその属性の詳細については、要求処理のための HTTP プロトコル構成 MOを参照してください。
HTTP-HTTPS プロトコル・ハンドラーは、データ・ハンドラーによって戻される要求メッセージを使用して、HTTP サービスを呼び出します。HTTP プロキシー・コネクターの構成プロパティーが指定されている場合、HTTP-HTTPS プロトコル・ハンドラーは、それに応じた振る舞いをします。応答が戻されると、HTTP-HTTPS プロトコル・ハンドラーはそれを読み取ります。
表 28 は、HTTP-HTTPS プロトコル・ハンドラーが、発信要求メッセージの Charset、MimeType、ContentType、Content-Type ヘッダーを判別するときに 使用するルールの優先順位の要約です。
優先順位の順序 | Charset | MimeType | ContentType | Content-Type ヘッダー |
1 | プロトコル構成 MO の Content-Type ヘッダー | TLO 属性の MimeType プロパティー | プロトコル構成 MO の Content-Type ヘッダー | プロトコル構成 MO の Content-Type ヘッダー |
2 | TLO 属性の Charset プロパティー | ContentType にデフォルト設定される | ||
3 | ContentType が text/* の場合、ISO-8859-1 にデフォルト設定される。 それ以外の場合、Charset は使用されません。 |
表 28 は次のことを示しています。
ContentType | デフォルトの Charset |
text/* | ISO-8859-1
詳細については、RFC2616 を参照してください。 |
application/* | デフォルトはなし |
その他すべて | デフォルトはなし |
表 30 は、ハンドラーが、応答メッセージの Charset、MimeType、ContentType、および Content-Type ヘッダーを判別するときに 使用するルールの優先順位の要約です。
優先順位の順序 | Charset | MimeType | ContentType | Content-Type ヘッダー |
1 | 着信 HTTP メッセージの Content-Type ヘッダー値の Charset パラメーター値 | 要求ビジネス・オブジェクトのプロトコル構成 MO の MessageTransformationMap 子ビジネス・オブジェクト | Content-Type ヘッダー値の、着信 HTTP メッセージのタイプ/サブタイプの値 | 着信 HTTP メッセージの Content-Type ヘッダー |
2 | 要求ビジネス・オブジェクトのプロトコル構成 MO の MessageTransformationMap 子ビジネス・オブジェクト | 要求メッセージの MimeType。ただし、要求と応答の ContentType が一致する場合のみ。 | ||
3 | 要求メッセージの Charset。ただし、要求と応答の ContentType が一致する場合のみ。 | TLO の MimeType プロパティー | ||
4 | TLO の Charset プロパティー | ContentType にデフォルト設定される | ||
5 | Content-Type が text/* の場合、ISO-8859-1 にデフォルト設定される。それ以外の場合、Charset は使用されません。 |
表 30 は次のことを示しています。
ハンドラーは HTTP プロトコル構成 MO を処理します。HTTP プロトコル構成 MO で渡されるヘッダー値 が、要求応答イベントのコンテキストにおいて正しくなるようにするのは、コラボレーションの責任です。 ハンドラーは、以下のルールに従って、標準ヘッダーおよびカスタム・プロパティーのデータを 取り込みます。