すべてのバス構成での一般的な問題
すべてのタイプのサービス統合バス構成に当てはまる計画上の問題および設計上の決定があります。
サービス統合バス構成を計画する場合には、以下の点を考慮してください。
- バスで処理する必要があるメッセージのボリューム。予想されるメッセージのボリュームに基づいて、バスまたはメッセージング・エンジンのメッセージの高しきい値設定を調整する必要があります。
- メッセージング・エンジン間の通信に使用されるトランスポート・チェーン。詳しくは、トランスポート・チェーンを参照してください。
- バス・セキュリティーが必要かどうか。 バス・セキュリティーが使用可能な場合は、バス自体、およびそのバス上のすべての宛先に対するアクセスが許可されていなければなりません。 バス・セキュリティーを使用可能にすると、バスにアクセスするメッセージング・エンジンとメディエーションの認証に対して別名を定義することもできます。単一バージョンのバスには認証別名は必要ではありません。 ただし、混合バージョンのバスを作成する場合、WebSphere® Application Server バージョン 6 または バージョン 6.1 のバス・メンバーに対してエンジン間認証別名を定義して、このバス・メンバーがそれ以降のバージョンの他のバス・メンバーとの信頼を確立できるようにする必要があります。
- IBM MQ キュー・マネージャーのネーミング規則に準拠したバス名を選択する必要があります。 バスを作成した後ではバス名を変更できないため、互換性のある名前を使用した場合にのみ、将来 IBM MQ との相互運用を行うことができます。 関連するリンクにある、IBM MQ のネーミングに関する制限が記載されたトピックを参照してください。
- 同じ名前を持つ 2 つのバスは接続できないため、バスに名前を付ける場合は、名前が固有であることを確認する必要があります。
例えば、以下のいずれかの方法で、同じ名前を持つ 2 つのバスは接続できません。
- 同じ名前を持つ 2 つのバスの間でバス間のリンクを作成した場合。
- 同じ名前のバスが定義されているリモート・セルで実行しているアプリケーションからリモート・バスに接続しようとした場合。
- 同じ名前のバスを含む 2 つのセルの間でコア・グループ・ブリッジを作成した場合。
- 宛先
- 宛先の数とタイプ、メディエーション、宛先のルーティング・パス、および宛先のサービス品質を構成のために決定する必要があります。Point-to-Point メッセージングの場合は、バス宛先をキューとして定義し、 パブリッシュ/サブスクライブ・メッセージングの場合は、バス宛先をトピック・スペースとして定義します。
- point-to-point メッセージングの場合のみ、 キューのメッセージを保持する割り当て済みバス・メンバーとして 1 つのバス・メンバーを選択します。 この操作により、割り当て済みバス・メンバーのメッセージング・エンジンごとに、 自動的にキュー・ポイントが定義されます。
- 別名宛先を定義することにより、 アプリケーションと、基盤にあるターゲット・バス宛先との間に、一定レベルの 間接化を提供できます。アプリケーションと別名宛先が対話することにより、 アプリケーションを変更せずにターゲットのバス宛先を変更することができます。
- バス宛先の使用方法を決定してください。バス宛先を構成して、プロデューサーが宛先にメッセージを送信しないようにしたり、コンシューマーが宛先からメッセージを受信しないようにしたりすることができます。
- メッセージのパーシスタンス
- 宛先のメッセージの信頼性サービス品質は、パフォーマンスと、メッセージ・ストアに必要なスペース容量に密接に関連しています。信頼性のレベルを高くするほど、廃棄されるメッセージが減少するため、パフォーマンスへの影響が大きくなり、メッセージ・ストアに必要なスペースは増加します。
- メッセージ・ストア構成を計画する場合、各メッセージング・エンジンには 1 つのメッセージ・ストアがあり、 ファイル・ストアまたはデータ・ストアのいずれかにできます。ファイル・ストアとデータ・ストアの相対的な利点を参照してください。メッセージのサイズが大きいほど、メッセージ・ストアに必要なスペースは増加します。
- データ・ストアを使用する場合、データ・ストアのデフォルトのデータベース・システムは Apache Derby バージョン 10.3 です。 しかし、DB2® などの別のシステムを使用しなければならない場合があります。要件に応じて、別のデータ・ストア構成を選択できます。詳しくは、メッセージング・エンジンでデータ・ストアを使用するための構成計画を参照してください。
- アプリケーション環境
- アプリケーションは、 プロセス内呼び出しを使用するか、または、ネットワークでリモート・クライアントを使用して、 バス上のメッセージング・エンジンにクライアントとして接続されます。 リモート・クライアントは、 Java™ EE アプリケーション・クライアント環境 または Java EE アプリケーション・サーバー 環境のいずれかで実行することができます。さまざまなトランスポート・チェーンを使用できます。
- アプリケーションの接続
- メッセージング・エンジンを選択する方法、およびアプリケーションがそのエンジンに到達するために使用するメカニズムは、JMS 接続ファクトリーで構成します。アプリケーションが接続するメッセージング・エンジンと、使用するトランスポート・チェーンを決定する必要があります。接続ファクトリーについて詳しくは、デフォルトのメッセージング・プロバイダーのリソースの構成を、トランスポート・オプションについて詳しくは、トランスポート・チェーンを参照してください。
- IBM MQ クライアント・リンク
- IBM MQ クライアント・リンクによって、WebSphere Application Server バージョン 5.1 用に開発された JMS クライアントがバス上でメッセージング・リソースを使用できるようになります。 WebSphere Application Serverバージョン 5.1 は、IBM MQ キュー・マネージャーを JMS プロバイダーとして使用するため、WebSphere Application Server バージョン 5.1 クライアントは、MQ リンク・プロトコルを使用して接続します。サービス統合の IBM MQクライアント・リンクは、これらのクライアントが使用できる接続機能を提供します。
- トランザクション・ログ
- トランザクション・ログの配置場所を計画します。関連するリンクにある、トランザクションの高可用性に関するトピックを参照してください。