InterChange Server は、コラボレーションのためのマルチスレッド化された Java ベースの実行フレームワークです。InterChange Server は、自身の Java 仮想マシン (JVM) で実行します。 InterChange Server は Windows と UNIX のシステム上で実行します。このセクションでは、InterChange Server の以下のサービスや機能について説明します。
InterChange Server は、コラボレーションの実行時に受信するすべてのビジネス・オブジェクトを永続的に保管します。これによって InterChange Server は、イベント通知や呼び出しを失うことなく、予期しない終了またはコラボレーションの障害から回復することができます。
コネクター・コントローラーは、クライアント側のコネクターと InterChange Server 間のインターフェースを指します。コネクター・コントローラーは、ビジネス・オブジェクトが IBM WebSphere InterChange Server システムを トラバースするときにその経路を定め、クライアント側のコネクターとコラボレーションのリンクおよび マッピング・プロセスの管理を行います。
コネクター・コントローラーを使用することにより、管理者は次のことを実行できます。
InterChange Server は、すべてのオブジェクトの構成情報および定義を、InterChanger Server リポジトリーという永続的ストアに保持します。このリポジトリーは、関連するデータベース内の表の集合から構成されます。 これらの表には、オブジェクト定義および構成情報が XML 文書の形式で 保管されています。
データベース接続サービスは、InterChange Server と リポジトリー間の対話を管理します。図 14 に示すように、データベース接続サービスは、JDBC (Java Database Connectivity) API を使用してリポジトリーと対話します。
InterChange Server は多数のデータベース・ベンダーをサポートしており、新たなデータベースの認証を継続します。現在サポートされているデータベースのリストについては、「システム・インストール・ガイド (Windows 版)」または「システム・インストール・ガイド (UNIX 版)」を参照してください。
IBM WebSphere InterChange Server システムの System Manager ツールを使用すると、InterChange Server でデータベース接続プールを定義できます。
ユーザー定義のデータベース接続プールによって、開発者がコラボレーションまたはマップから関連するデータベースに直接アクセスできるようになります。この機能は、次のことをサポートします。
IBM WebSphere InterChange Server システムは、InterChange Server (ICS) に高可用性 (HA) を提供するように構成できます。
Windows システムでは、HA 構成は Microsoft Cluster Server (MSCS) ソフトウェアで実行します。HA 構成には、Microsoft 認証のクラスター・サーバー・マシンが 2 台必要です。2 台のサーバーは同一の InterChange Server システム構成でセットアップされ、MSCS ソフトウェア内でクラスター・システムとして指定されます。1 台のマシンは MSCS にプライマリー (障害が発生するまでアクティブなサーバー) として構成し、もう 1 台はバックアップとして構成します。2 台のマシンは、外部プロセスがアクティブ・サーバーにアクセスするために使用する、クラスター名とクラスター IP アドレスを共有します。プライマリー・サーバーおよびバックアップ・サーバーはともに、アクティブ・サーバーが制御する共有 RAID ストレージ・システムへのアクセス権を持ちます。
ハードウェア障害が検出されると、HA 構成はクラスター・バックアップ・システム上で ICS のシャットダウン、自動マイグレーション、および ICS (ならびにサード・パーティー製ソフトウェアと HA がサポートするコネクター) の再始動を実行します。クラスター・バックアップ・サーバーはアクティブ・サーバーになり、プライマリー・サーバーのクラスター名と IP アドレスを引き継ぎます。プライマリー・サーバーの障害が修復されてフェイルバック (つまり、手動でプライマリー・サーバーに処理を戻すこと) が開始されるまで、バックアップ・サーバーがシステム処理を自動的に引き継ぎます。
HA 環境の概要については、「システム管理ガイド」を参照してください。HA 環境用に ICS を構成する方法の詳細については、「システム・インストール・ガイド」を参照してください。
いかなるアプリケーション統合ソリューションでも、データをあるアプリケーションから別のアプリケーションに移動させるときにはリスクに直面します。データがアプリケーションおよびそのデータベースの保護領域を出て、ネットワーク経由で別のアプリケーションに送られるときには、問題が発生する可能性は数多くあります。例えば、次のような問題が考えられます。
人事、給与計算、および製品別原価計算という 3 つのアプリケーションを含むコラボレーションがあるとします。各アプリケーションには、従業員給与が格納されています。図 15 に、従業員の昇給を処理するためのクロス・アプリケーション・ビジネス・ロジックをハイレベル表示で示します。
ある従業員が昇給すると、担当者が人事アプリケーションに新規給与を入力します。コラボレーションは自動的に給与計算アプリケーションの従業員給与を更新し、製品別原価計算アプリケーションのプロジェクト費用を調整します。
システム・エラーによって給与更新が製品別原価計算アプリケーションに伝達されない場合、データ不整合が生じます。従業員給与の値がアプリケーションごとに異なるので、製品原価が誤って計算されます。
従来は、入念なクロスチェックが必要でした。これを行わないと、誰かが問題に気が付くまでデータは誤ったままでした。しかし、IBM WebSphere InterChange Server システムは、エンタープライズ・データを信頼できるよう厳密に制御された高度なサービスを提供するので、コラボレーションを一種のトランザクションであるかのように実行できます。
トランザクションの特性は、アプリケーション全体でデータの整合性が重要であるコラボレーションにとって理想的であり、目的を達成できます。他のトランザクションのように、トランザクション・コラボレーションには一連のステップが含まれます。エラーが発生すると、InterChange Server はトランザクションのようにロールバックを実行して、完了した各ステップを元に戻すことができます。
ただし、コラボレーションと従来のトランザクションは、次の点で大きく異なります。
この結果、トランザクション・コラボレーションをサポートするために InterChange Server が使用する手法は、従来のトランザクションをサポートするために使用する手法とは異なります。コラボレーションに関するトランザクション・レベルは、InterChange Server がトランザクションのセマンティクスを強化する度合いを定義します。
InterChange Server 環境は、障害後のリブートに ICS が要する時間を改善する 機能、すべてのフローが回復する前に ICS で他の作業を行えるようにする機能、および失敗 したイベントの再実行依頼を制御する機能を備えています。
InterChange Server は、コラボレーションとコネクターが回復するのを待たずにブートを完了します。つまり、コラボレーションとコネクターは、InterChange Server のブート後に非同期に回復できます。これによって、コネクターとコラボレーションが回復中である一方で、System Monitor や「未解決のフローを管理」ダイアログなどの System Manager トラブルシューティング・ツールを使用できるようになります。
この機能の使用はオプションであり、コラボレーション・オブジェクト・プロパティーを使用して構成します。この機能を使用可能にすると、ICS の障害が発生すると、コラボレーションのプロセス中の作業フローの回復は、サーバーがリブートするまで据え置かれます。このため、これらのフローに関連するメモリー使用量を節約できます。サーバーのリブート後、System Manager の「未解決のフローを管理」ダイアログを使用してイベントを再実行依頼できます。
非トランザクション・コラボレーションが宛先アプリケーションに重複してイベントを送信するのを回避するため、障害の発生時に、リカバリーに自動的に転送中のすべてのサービス呼び出しを再実行依頼させたくない場合があります。この場合には、障害およびリカバリーが発生したときにコラボレーションが転送中のすべてのサービス呼び出しを持続するように、コラボレーションを構成します (サーバーの障害に先立って実行します)。InterChange Server が回復するとき、サービス呼び出しを処理していたフローは転送中状態を維持するので、「未解決のフローを管理」ダイアログを使用して個々の未解決のフローを調査したり、それらのフローを再実行依頼するときに (またはする場合には) 制御したりできます。
JMS 対応のコネクター (JMS をトランスポート機構として使用するコネクター) では、リカバリー状態でイベント・デリバリーを保証するには、次の機能が有効です。
コンテナー管理下のイベント機能は、JMS イベント・ストアを使用する JMS 対応の コネクターに対して有効です。この機能により、システム破壊やリカバリーが発生したときに、イベント・ストアとコネクター・フレームワーク間で処理が行われていたイベントが、1 度だけコネクター・フレームワークに配信されます (2 度配信されることはありません)。この機能はオプションで、コネクター・プロパティーを介して構成されます。なお、この機能は、コネクターが JMS をトランスポート機構として使用している場合にのみ 有効です。
重複イベントの除去機能は、JMS 対応のコネクターに対して有効です。この機能は、コネクターのアプリケーション固有コードに固有のイベント ID を使用することにより、デリバリー・キューへのイベントのデリバリーが重複しないようにするものです。この機能はオプションで、コネクター・プロパティーを介して構成されます。なお、この機能は、コネクターが JMS をトランスポート機構として使用している場合にのみ 有効です。