InterChange Server 環境において、データ・フロー (1 つのアプリケーション またはエンティティーから別のアプリケーションまたはエンティティーへのデータの移動 および処理) には次のすべてが 含まれます。
データ・フローは、パブリッシュ・アンド・サブスクライブ対話またはサービス呼び出し対話のどちらかの対話によって開始されます。どちらの対話も、コラボレーションのビジネス・プロセスの実行を開始するトリガーを提供します。次に、コラボレーションは要求/応答対話という 3 つ目の対話を使用して、宛先とのデータ交換を終了します。
コネクターとコラボレーションは、パブリッシュ・アンド・サブスクライブ対話を使用して、アプリケーション・イベントに関する情報を処理するために IBM WebSphere InterChange Server に移動させます。
パブリッシュ・アンド・サブスクライブ対話では、コラボレーションがアプリケーション動作を表す特定タイプのトリガー・イベントのためのビジネス・オブジェクト (例えば Employee.Create) を受信して起動されると、ビジネス・プロセスを開始します。 ビジネス・オブジェクトの名前 (Employee) は、ビジネス・エンティティーのタイプを表します。動詞 (Create) は そのエンティティーに対して実行された操作を表します。つまり、Employee.Create イベントは従業員エンティティーの作成を報告します。
パブリッシュ・アンド・サブスクライブ対話によって、トリガー・イベントは次のようにしてコラボレーションに到達します。
イベントは、使用するコネクターによって、非同期または同期でコラボレーションにパブリッシュされます。また、コラボレーションの長期存続ビジネス・プロセス機能を使用可能にしているときは、コラボレーションは着信イベントが定義済みマッチング基準を満たしている場合に そのイベントを待ち状態で保持できます。
コラボレーションは、直接呼び出しがアクセス・クライアントによって送信され、サーバー・アクセス・インターフェースで受信されて、そのコラボレーションにビジネス・オブジェクトとして送信されると起動するように設計できます。 InterChange Server 環境では、サーバー・アクセス・インターフェース経由で コラボレーションに送信された呼び出しはアクセス要求と呼ばれます。アクセス要求は、外部ソースまたは InterChange Server 環境内に構成されたソースから発信されます。
アクセス要求対話は、同期通信が重要な場合に役立ちます。例えば、顧客担当者が Web ブラウザーを使用してインターネット経由で在庫状況情報を要求するような場合です。
コラボレーションは、トリガー・ビジネス・オブジェクトを受信して起動されるとデータの処理を開始します。トリガー・ビジネス・オブジェクトは、アクセス要求またはイベント通知のいずれかの結果で生成されます。コラボレーションが起動されると、バインドされたコネクターに要求を送信したり応答を受信したりできます。
コラボレーションは、それ自体の要求 (サービス呼び出し要求と呼ばれます) を 汎用ビジネス・オブジェクトの形式で作成します。
コネクターは、汎用ビジネス・オブジェクトを特定のアプリケーションで理解されるデータ・エンティティーまたはコネクターが設計されたものと同じデータ・フォーマットに変換します。
コラボレーションがコネクターから受信する応答 (サービス呼び出し応答と呼ばれます) は、ビジネス・データ (検索要求の場合) または状況報告 (成功または不成功) を含んだビジネス・オブジェクトです。
図 5 は、パブリッシュ・アンド・サブスクライブ対話によって開始され、要求/応答対話によって完了するビジネス・プロセスを簡単に示しています。(この簡易図では、コネクター・コントローラーとコネクター・エージェントが単体として表されています。また、ローカル・ネットワーク上のアプリケーション用コネクターとインターネット・ファイアウォールの外部にあるアプリケーション用コネクターを区別していません。) この例は、顧客サービス担当者が 1 つのケースの作業を終えると自動的に送り状が生成される、分散ビジネス・プロセスを示しています。この例で、仮想の Service Billing コラボレーションは、コネクターを使用してビジネス・データを 3 つの異なるアプリケーションに変換しています。
図 5. パブリッシュ・アンド・サブスクライブ対話、要求/応答対話
図 5 には、次のビジネス・プロセスの 順序を示します。
サイトでは、コラボレーションとコネクターが結合する度合いを調整できます。例えば、コラボレーションが 24 時間体制で実行している場合に、アプリケーションと通信するコネクターに要求を送信する時間を午前 12 時から午前 2 時の間に限定できます。コラボレーションは、応答を必要とすることなく要求を送信し、応答を受信すると単にその応答を処理するように設計および構成できます。
また、長期存続ビジネス・プロセスでコラボレーションを使用可能にしているときは、コラボレーションは、タイムアウト値 (応答による保管された処理フローの再開が可能な期間) とともに 要求のフロー・コンテキストを保存したり、要求を送信したりできます。
図 6 は、アプリケーション間 (Web サーバーおよびブラウザーなど、他のエンティティー) でデータをやり取りするための一般的なアクセス要求対話、パブリッシュ・アンド・サブスクライブ対話、および要求/応答対話で使用される、IBM WebSphere InterChange Server システム・コンポーネントのハイレベル表示を示しています。
データはハブにある InterChange Server を通るフロー内を移動し、ローカル・ネットワーク上のアプリケーション、インターネット・ファイアウォールの外側のコネクター・エージェントとともに構成されたアプリケーション、および Web サーバーやブラウザーなどの外部エンティティーと交換されます。
フローは、アクセス要求やイベント、またはあらゆるタイプの外部および内部プロセスによって開始されます。フローが開始されると、コラボレーションは要求/応答対話を使用して、ローカルやリモートのアプリケーションまたは他のエンティティーとのビジネス・プロセスを完了します。
このダイアグラムで、1 つのコネクターはアプリケーション・イベントをパブリッシュし、もう 1 つのコネクターはコラボレーションと宛先 Web サーバー間の要求/応答対話を行っている状態が示されています。この図は、可能な構成の一例にすぎません。ほとんどのコネクターは、イベントのパブリッシュとコラボレーション要求への応答の両方を実行するように構成できます。
このダイアグラムには示されていませんが、インターネット上でデータを交換するために、コネクターがローカルに構成されたテクノロジー・サーバー (TPI サーバーや E メール・サーバーなど) と対話する構成も可能です。
また、コネクター・エージェントとそれに関連するアプリケーションはローカルに設置する必要がありません。リモート・エージェント・テクノロジーを使用することによって、リモート URL ロケーションにあるコネクター・エージェントは、イベントのパブリッシュ とコラボレーション要求への応答の両方を実行できます。
図 7 は、可能ないくつかのデータ・パス上で交換されるデータのタイプを示しています。
数字は、データ・パスの特定の順序を 1 つのみ示しています。この例では、外部 Web ブラウザーからサーバー・アクセス・インターフェースを経由し てコラボレーションに到達し、コラボレーションのビジネス・プロセスの 完了後、外部 Web サーバーに送信されます。
図 7 のサンプルでは、次の処理が行われます。
また別のシナリオでは、コラボレーションがテクノロジー・コネクターではなくアプリケーション・コネクターにビジネス・オブジェクトを送信する場合があります。アプリケーションはローカルに置くことができますが、リモート・エージェント・テクノロジーが使用されている場合には、アプリケーションとそのコネクター・エージェントはハブから離してインターネット上に置くことができます。