イベント処理

イベント処理機能をインプリメントする際の最初のステップとして、ビジネス・プロセス (コラボレーション) を Web サービスとして公開します。次に、この Web サービスを、例えば UDDI レジストリーにパブリッシュし、コラボレーションを呼び出す Web サービス・クライアントに応答するようにコネクターを構成します。

イベント処理中に、コネクターはプロトコル・リスナーと SOAP データ・ハンドラーを使用して、Web サービス・クライアントの SOAP 要求メッセージを、Web サービスとして公開されているコラボレーションで操作できるビジネス・オブジェクトに変換します。プロトコル・リスナーは、イベント処理において極めて重要な役割を果たしています。

プロトコル・リスナー

Web サービス要求は、HTTP、HTTPS、および JMS などをはじめとする、さまざまなトランスポートを介して送られてきます。Web サービス・プロトコル・リスナーは、トランスポート・チャネルにこのような要求が到着するのをモニターします。プロトコル・リスナーには次の 3 種類があり、それぞれに対応するチャネルがあります。

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

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

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

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

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

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

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

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


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

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


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

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

表 28は、インバウンド・メッセージの Charset、MimeType、ContentType、および Content-Type ヘッダーを決定する場合にリスナーが使用する規則の優先順位を要約したものです。


表 28. インバウンド・メッセージに対する SOAP/HTTP(S) プロトコル・リスナーの処理規則
優先順位 Charset MimeType ContentType Content-Type ヘッダー
1 着信 HTTP メッセージの Content-Type ヘッダー値から得られる Charset パラメーター値 このリスナーの URLsConfiguration コネクター・プロパティー値 Content-Type ヘッダー値から得られる着信 HTTP メッセージ・タイプ/サブタイプ値 着信 HTTP メッセージの Content-Type ヘッダー
2 このリスナーの URLsConfiguration プロパティー値 SOAPDHMimeType コネクター・プロパティー値

3 要求メッセージ ContentType のタイプが、任意のサブタイプ (例えば、text/xmltext/plain など) を持つ text の場合は、ISO-8859-1 にデフォルト設定されます。それ以外の場合は、charset を使用しません。 ContentType (デフォルト)

表 28 に示したように、以下を決定します。

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

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

表 29 は、応答メッセージの Charset、MimeType、ContentType、Content-Type ヘッダーを決定する際にリスナーが使用する規則の優先順位を要約したものです。


表 29. アウトバウンド同期応答メッセージに対する SOAP/HTTP(S) プロトコル・リスナーの処理規則
優先順位 Charset MimeType ContentType Content-Type ヘッダー
1 プロトコル構成 MO の Content-Type ヘッダー TLO の MimeType プロパティー プロトコル構成 MO の Content-Type ヘッダー プロトコル構成 MO の Content-Type ヘッダー
2 TLO の Charset プロパティー値 要求メッセージの MimeType。ただし要求と応答の ContentType が一致する場合のみ。 要求メッセージの ContentType ContentType および Charset を使用して、Content-Type ヘッダーを構成します。
3 要求メッセージの Charset。ただし要求と応答の ContentType が一致する場合のみ。 SOAPDHMimeType コネクター・プロパティー値

4 ContentType が text/* の場合、デフォルトは ISO-8859-1 です。それ以外の場合は、charset を使用しません。 MimeType として ContentType 値を使用します。

表 29 に示したように、以下を決定します。

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

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

注:
HTTP プロトコル構成 MO のヘッダー Connection、Trailer、 Transfer-Encoding、Content-Encoding、Content-Length、Content-MD5、 Content-Range の中からいずれを指定しても、ほとんどの場合、正しくない HTTP メッセージが作成されます。

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

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

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

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

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

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

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

SOAP/JMS プロトコル・リスナー処理

SOAP/JMS プロトコル・リスナーは、Web サービス・クライアントからの要求の JMS 宛先となる InputQueue で継続的に listen するスレッドから構成されています。RequestWaitTimeout コネクター構成プロパティーは、コネクターがシャットダウンされたかどうか確認するまでリスナーが要求を待つ時間を定義します。

図 26 は、同期操作のための SOAP/JMS プロトコル・リスナー処理を表しています。この図は JMS プロバイダー情報を示していません。

図 26. SOAP/JMS プロトコル・リスナー: 同期イベント処理


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

図 27. SOAP/JMS プロトコル・リスナー: 非同期イベント処理


注:
LookupQueueUsingJNDI 構成プロパティーが true に設定されている場合、SOAP/JMS プロトコル・リスナーは、JNDI を使用してキューを検索します。JNDI プロパティーは、コネクター・プロパティーに指定されます。詳しくは、コネクターおよび JMSおよび コネクター固有の構成プロパティーの JNDI 関連のプロパティーを参照してください。
Web サービス・クライアントは、SOAP/JMS 要求を開始するときに、SOAP/JMS リスナーが listen している InputQueue に SOAP 要求メッセージを送信します。InputQueue から SOAP 要求メッセージを受け取ると、SOAP/JMS プロトコル・リスナーは、プロトコル・リスナー・フレームワークにその要求を登録します。リソースが使用可能である限り、プロトコル・リスナー・フレームワークはその要求をスケジュールします。
注:
コネクター構成プロパティー InDoubtEvents が Reprocess に設定されている場合、プロトコル・リスナー・フレームワークは、InProgressQueue の JMS メッセージをスケジュールしてから InputQueue のメッセージをスケジュールします。

次のリスナーは、このメッセージ (本文と必要な JMS ヘッダー (JMSCorrelationID、JMSMessageID、JMSPriority、JMSExpiration、JMSDeliveryMode、 JMSReplyTo、JMSTimeStamp、JMSType)) を InProgressQueue にディスパッチします。次に、プロトコル・リスナー・フレームワークはイベントを登録します。

リスナーは、次に、InProgressQueue から JMS メッセージを読み取り、メッセージの本文および以下のヘッダーを抽出します。

JMSType には、TextMessage フォーマットまたは BytesMessage フォーマットがあります。TextMessage フォーマットの場合、リスナーは、ストリングとして抽出された Web サービス要求メッセージを使って、ストリング API 経由でデータ・ハンドラーを呼び出します。BytesMessage の場合、リスナーは、バイト・データ・ハンドラー API 経由で、バイト配列として抽出された Web サービス要求メッセージを使用して、データ・ハンドラーを起動します。

リスナーは、SOAPDHMimeType コネクター構成プロパティーを使用して、SOAP データ・ハンドラーを呼び出し、要求メッセージを SOAP 要求ビジネス・オブジェクトに変換します。変換中にエラーが発生し、JMSReplyTo JMS ヘッダーが指定されていると、リスナーは、SOAP 障害メッセージで応答し、faultcode は Client に設定され、faultstring は Cannot Parse に設定されます。障害メッセージには、これ以外の詳細はありません。

リスナーは、データ・ハンドラーによって戻される SOAP 要求ビジネス・オブジェクトのオブジェクト・レベル cw_mo_jms ASI を使用して、プロトコル構成 MO を判別します。イベント処理の場合、ASI およびプロトコル構成 MO はいずれもオプションとなるので注意してください。リスナーは、プロトコル構成 MO を検出すると、事前に抽出済みの JMS メッセージ・ヘッダーをそれに取り込みます。表 43 は、プロトコル構成 MO 属性と JMS メッセージ・ヘッダー間のマッピングを示しています。

表 30. JMS ヘッダーとプロトコル構成 MO 属性のマッピング
プロトコル構成 MO 属性 JMS ヘッダー名 説明
CorrelationID JMSCorrelationID 要求メッセージから得られる JMSCorrelationID ヘッダー
MessageId JMSMessageId 要求メッセージから得られる JMSMessageID ヘッダー
Priority JMSPriority 要求メッセージから得られる JMSPriority ヘッダー
Expiration JMSExpiration 要求メッセージから得られる JMSExpiration ヘッダー
DeliveryMode JMSDeliveryMode 要求メッセージから得られる JMSDeliveryMode ヘッダー
ReplyTo JMSReplyTo 要求メッセージから得られる JMSReplyTo ヘッダー。JMS API はこのヘッダーを JMSDestination として戻しますが、SOAP/JMS プロトコル・リスナーはキュー名を戻します。
Timestamp JMSTimestamp 要求メッセージから得られる JMSTimestamp ヘッダー
Redelivered JMSRedelivered 要求メッセージから得られる JMSRedelivered ヘッダー
Type JMSType 要求メッセージから得られる JMSType ヘッダー
Destination JMSDestination 要求メッセージから得られる JMSDestination ヘッダー

SOAP/JMS プロトコル構成 MO UserDefinedProperties 属性に 1 つ以上のカスタム・プロパティーがある場合、リスナーは、メッセージからカスタム・プロパティーの値を抽出し、UserDefinedProperties ビジネス・オブジェクトにデータを設定しようとします。 カスタム・プロパティーの詳細については、イベント処理のためのユーザー定義のプロパティーを参照してください。

TLO (非 TLO SOAP 要求ビジネス・オブジェクトの場合) が統合ブローカーによってサブスクライブされなければ、リスナーはエラーをログに記録します。要求メッセージに JMSReplyTo ヘッダーが指定されている場合は、リスナーにより SOAP 障害メッセージが作成され、JMSReplyTo キューに配置されます。faultcode は Client に設定され、faultString は Not subscribed to this message に設定されます。障害メッセージにこれ以外の詳細はありません。また、そのように構成されている場合、リスナーは、JMS ヘッダーを含めて元の JMS 要求メッセージを UnsubscribedQueue に保管します。

コラボレーションを非同期に呼び出す場合、リスナーは、要求ビジネス・オブジェクトを統合ブローカーにデリバリーします。次に、リスナーはそのメッセージを InProgressQueue から除去します。また、そのように構成されている場合、リスナーは、JMS ヘッダーを含めて元の JMS 要求メッセージを ArchiveQueue に保管します。

非同期処理中にエラーが発生し、JMSReplyTo が指定されていると、リスナーは、障害メッセージで応答します。メッセージの faultcode は Server に設定され、faultstring は Internal Error に設定されます。また、そのように構成されている場合、リスナーは、JMS ヘッダーを含めて元の JMS 要求メッセージを ErrorQueue に保管します。

同期呼び出しの場合は、リスナーは同期させてコラボレーションを呼び出します。コラボレーションは SOAP 応答ビジネス・オブジェクトを使用して応答します。リスナーは、SOAP データ・ハンドラーを呼び出して、コラボレーションによって戻された応答ビジネス・オブジェクトを SOAP/JMS 応答メッセージに変換します。リスナーは、応答メッセージを ReplyTo キュー (これは、元の要求メッセージの JMSReplyTo ヘッダーで提供されます) にデリバリーします。リスナーは、次に、データ・ハンドラーによって戻される応答メッセージを TextMessage として設定し、表 31 に示しているヘッダーを設定します。


表 31. SOAP/JMS プロトコル・リスナーによって応答メッセージに設定されるヘッダー値
JMS ヘッダー名
JMSCorrelationId 要求メッセージの JMSMessageId
JMSDeliveryMode 要求メッセージの JMSDeliveryMode
JMSPriority 要求メッセージの JMSPriority
JMSExpiration 要求メッセージの JMSExpiration
JMSRedelivered 要求メッセージの JMSRedelivered
JMSReplyTo 要求メッセージの JMSReplyTo
JMSTimestamp 要求メッセージの JMSTimestamp
JMSType 要求メッセージの JMSType

リスナーは、JMS カスタム・プロパティーが応答または障害ビジネス・オブジェクトの JMS プロトコル構成 MO UserDefinedProperties 属性に存在する場合に、その JMS カスタム・プロパティーを応答メッセージに設定します。

そのように構成されている場合、リスナーは、元の JMS メッセージ (Web サービス・クライアントからの要求) をそのヘッダーも含めて、InProgressQueue から ArchiveQueue に移動します。

エラーが発生し、JMSReplyTo が指定されていると、リスナーは、障害メッセージで応答します。また、そのように構成されている場合は、元の JMS 要求メッセージを ErrorQueue に保管します。

イベントの永続性とデリバリー

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

イベントの順序付け

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

イベントのトリガー

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

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

イベントの検出

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

イベント状況

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

イベントの検索

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

イベントのアーカイブ

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

イベントのリカバリー

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


表 32. SOAP/JMS プロトコル・リスナーによって応答メッセージに設定されるヘッダー値
InDoubtEvents 値 イベント・リカバリー処理
FailOnStartup イベントを InProgressQueue で検出すると、リスナーは、致命的エラーをログに記録し、直ちにシャットダウンします。
Reprocess イベントを InProgressQueue で検出すると、リスナーはまず最初にこれらのイベントを処理します。リスナーは、InProgressQueue で検出されたメッセージ数をトレースできます。
Ignore InProgressQueue 内のイベントは無視されます。リスナーは、InProgressQueue で検出されたイベントをトレース可能で、これらのイベントを無視します。
LogError イベントを InProgressQueue で検出すると、リスナーは、エラーをログに記録し、処理を続行します。

Copyright IBM Corp. 2004