クライアントからのリクエストは，CTMデーモンによって管理されるスケジュールキューによってスケジューリングされます。スケジュールキューは，J2EEアプリケーション（EAR）単位またはBean単位で作成されます。デフォルトのキュー名称は，J2EEアプリケーション単位の場合はJ2EEアプリケーションの名称，Bean単位の場合はBean名となります。J2EEアプリケーション単位またはBean単位でスケジュールキューを持つことで，異なるインタフェースを持つ業務処理プログラム間，またはJ2EEアプリケーションのBean間でキューを共有できます。なお，スケジュールキューで制御されるリクエストは，「EJBホームリファレンスのグローバルCORBAネーミングサービス登録名称」と「業務処理プログラムのリモートインタフェース名称」の組み合わせで管理されます。

スケジュールキューは，同じCTMデーモンに対応づけられている，次のJ2EEアプリケーション間またはBean間で共有できます。

J2EEアプリケーション間で共有する場合

• キュー名称が同じである
• 業務処理プログラムの構成が同じである（J2EEアプリケーションに含まれるEnterprise Beanが，CTMが認識する範囲で完全に一致する）

Bean間で共有する場合

• キュー名称が同じである
• Beanが同じである

同じ業務処理プログラム構成でもキュー名称が異なる場合や，同じキュー名称でも異なる業務処理プログラム構成を持つJ2EEアプリケーション間では，スケジュールキューは共有できません。

複数のJ2EEサーバ間でスケジュールキューを共有することもできます。ただし，その場合は，ユーザ指定名前空間機能を使用して，それぞれの業務処理プログラムであるEnterprise Beanに別名（Optional Name）を付与する必要があります。ユーザ指定名前空間機能については，「8.2　JNDI名前空間へのオブジェクトのバインドとルックアップ」を参照してください。別名の付与は，J2EEアプリケーションのプロパティとして設定します。J2EEアプリケーションの設定については，マニュアル「Cosminexus　システム構築ガイド」を参照してください。

参考

• デフォルトの設定でJ2EEアプリケーションをインポートすると，業務処理プログラムをルックアップするための名称が「/HITACHI_EJB/SERVERS/＜J2EEサーバ名称＞/EJB/＜J2EEアプリケーション名称＞/＜業務処理プログラムの名称＞」になります。この場合，ルックアップ名称にJ2EEサーバ名称が含まれてしまうため，J2EEサーバ間でスケジュールキューを共有できません。
• 一つのJ2EEサーバ内で複数のJ2EEアプリケーションを同一名称でインポートして，スケジュールキューを共有することはできません。

スケジュールキューを共有する場合について，J2EEアプリケーション単位での共有と，Bean単位での共有に分けて説明します。

(a)　J2EEアプリケーション単位の場合

スケジュールキューを共有すると，複数のJ2EEサーバ上のJ2EEアプリケーションで，リクエストを分散処理できます。

スケジュールキューの共有には，次のような効果があります。

• キューを共有するJ2EEアプリケーション間で同時実行スレッド数を制御できるので，特定のJ2EEアプリケーションに高い負荷が掛かった時の性能劣化を防げます。これによって，システムとしての処理性能を安定させやすくなります。
• キューを共有しているどちらかのJ2EEサーバで障害が発生した場合に，縮退運転に切り替え，キューに滞留したリクエストを障害が発生していないJ2EEサーバのJ2EEアプリケーションで処理できます。このため，業務が停止しません。

スケジュールキューを共有する例を次の図に示します。

図11-11　スケジュールキューを共有する例（J2EEアプリケーション単位）

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有している場合，共有しているキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXによって，J2EEサーバ1またはJ2EEサーバ2に処理が振り分けられます。

(b)　Bean単位の場合

スケジュールキューを共有すると，複数のJ2EEサーバ上のBeanでリクエストを分散処理できます。

スケジュールキューの共有には，次のような効果があります。

• 同一のJ2EEアプリケーション内にあるほかのBeanの影響を受けることなく，J2EEアプリケーション内のBean種別ごとにキューを分けることができます。
• キューを共有するBean間で同時実行スレッド数を制御できるので，特定のBeanに高い負荷が掛かった時の性能劣化を防げます。これによって，システムとしての処理性能を安定させやすくなります。
• キューを共有しているどちらかのJ2EEサーバで障害が発生した場合，縮退運転に切り替え，キューに滞留したリクエストを障害が発生していないJ2EEサーバ上のBeanで処理できます。このため，業務が停止しません。

スケジュールキューを共有する例を次の図に示します。

図11-12　スケジュールキューを共有する例（Bean単位）

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有している場合，共有しているキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXによって，J2EEサーバ1またはJ2EEサーバ2上のBean Aに処理が振り分けられます。

スケジュールキューを共有しない場合，異なるJ2EEサーバに同じJ2EEアプリケーションがインポートされていたり，J2EEサーバ上に同じBeanがあったりしても，リクエストはそれぞれのキューで制御され，実行されます。

スケジュールキューを共有しないと，負荷分散や縮退運転はできなくなりますが，異なるスケジュールキューでリクエストが滞留してもその影響を受けなくなるため，優先的に業務処理を進められます。

スケジュールキューを共有しない場合は，それぞれのJ2EEアプリケーションに含まれる業務処理プログラムに別名を指定しないで，それぞれ異なるルックアップ名称にします。

スケジュールキューを共有しない例を次の図に示します。

図11-13　スケジュールキューを共有しない例

EJBクライアントからのルックアップは，グローバルCORBAネーミングサービスに対して実行します。スケジュールキューを共有していない場合，指定したJ2EEアプリケーションを制御するキュー（この場合はX）のリファレンスが取得できるので，そのキューに対してcreateを実行します。そこで取得したCTMレギュレータのリファレンスに対してinvokeを実行すると，スケジュールキューXが制御しているJ2EEサーバ1に処理が振り分けられます。