|
|
このドキュメントでは、プロダクション環境に BEA AquaLogic Service Bus コンフィグレーションをデプロイする方法について説明します。以下の節では、組織で AquaLogic Service Bus をデプロイする場合の主要な概念と操作について説明します。
このドキュメントでは、AquaLogic Service Bus ソフトウェアのライフサイクルのデプロイメント段階についてのみ説明します。AquaLogic Service Bus の概要については、BEA AquaLogic Service Bus の概念とアーキテクチャを参照してください。
AquaLogic Service Bus のコンフィグレーションについては、http://edocs.beasys.co.jp/e-docs/alsb/docs25/index.html にあるドキュメントを参照してください。
AquaLogic Service Bus では、インテリジェントなメッセージ ブローカリングとサービスのモニタおよび管理を統合しているため、1 つのソフトウェア製品でサービス指向アーキテクチャ (SOA) の実装とデプロイを行うことができます。AquaLogic Service Bus のコンフィグレーションをデプロイするときは、以下の目標を考慮します。
AquaLogic Service Bus コンフィグレーションでは、常にこれらの目標を達成できます。
AquaLogic Service Bus をデプロイするときは、以下の作業の一部または全部を完了する必要があります。
統合型ソリューションを正しくデプロイするためには、デプロイメント チームに、以下の役割を果たすメンバーを加える必要があります。
一人で複数の役割を兼任することもできます。デプロイメントのすべてのシナリオに全員が等しく関わることはありませんが、正しくデプロイするためには、各担当者の参加が必要です。
デプロイメント スペシャリストは、デプロイメント作業を調整します。デプロイメント スペシャリストには、AquaLogic Service Bus 製品の機能に精通していることが要求されます。デプロイメント スペシャリストは、1 つまたは複数のサーバにさまざまな AquaLogic Service Bus 機能をコンフィグレーションしてきた経験を基に、専門知識を活かして、ESB ソリューションのデプロイメント トポロジを設計します。デプロイメント スペシャリストには、以下の分野の経験が要求されます。
WebLogic Server 管理者は、組織内の WebLogic Server デプロイメントに関する技術と操作について深い知識を持っていることが要求されます。以下の領域の経験と専門知識が要求されます。
データベース管理者は、組織内にデプロイされたデータベース システムに関する技術と操作について深い知識を持っている必要があります。以下の領域の経験と専門知識が要求されます。
この節では、デプロイメントの段階で変更可能なリソースの概要について説明します。「リソース」という用語は、このドキュメントでは主に技術的な資産を指します。セキュリティについては例外的に、セキュリティ ロールとセキュリティ ポリシーを使用して無許可のアクセスから保護する WebLogic Server エンティティのことだけを指します。
デプロイメントの段階で変更可能な主なリソースには、以下のものがあります。
この節では、AquaLogic Service Bus ソリューションのデプロイメントに最も関係する WebLogic Server リソースの一般情報について説明します。これらのリソースは WebLogic Server Administration Console で直接コンフィグレーションすることも、J2EE と WebLogic のリソース記述子を通じてコンフィグレーションすることもできます。
WebLogic Server には、多くのコンフィグレーション オプションと調整可能な設定があり、サポートされている任意の環境で AquaLogic Service Bus ソリューションをデプロイするために使うことができます。AquaLogic Service Bus のデプロイメントに最も関係する、コンフィグレーション可能な WebLogic Server 機能には、以下のものがあります。
クラスタは、単体ユニットとして管理可能なサーバのグループです。クラスタ化により、単一サーバよりもスケーラビリティの高いデプロイメント プラットフォームを構築できます。作業負荷に対する許容量を増やすために、WebLogic Server をクラスタで実行できます。クラスタ化の詳細については、「AquaLogic Service Bus クラスタについて」を参照してください。
WebLogic Java Message Service (JMS) により、Java アプリケーションでメッセージ システムを共有し、メッセージを交換 (作成、送信、受信) することができます。WebLogic JMS は、Sun Microsystems, Inc の Java Message Service Specification version 1.0.2 に準拠しています。
JMS サーバはクラスタ化が可能です。また、接続ファクトリは WebLogic Server の複数のインスタンスにデプロイできます。WebLogic JMS の詳細については、以下のトピックを参照してください。
AquaLogic Service Bus デプロイメントでは、EJB の数がシステムのスループットに影響します。システムの EJB の数は、EJB のタイプに応じて、EJB プールまたは EJB キャッシュを使用して調整できます。次の表に、EJB のタイプと関連する可変パラメータを示します。
スループットの制御の詳細については、WebLogic Server 環境の設計とコンフィグレーションに関するドキュメントの「WebLogic Server 環境の新機能と変更点」にあるリンク先の「プロダクション環境でのサーバの自動チューニング」を参照してください。
JDBC (Java Database Connectivity) は、Java アプリケーションから DBMS に格納されているデータにアクセスするために使用します。データベース接続を確立する際のオーバーヘッドを減らすために、WebLogic JDBC にはすぐに使用できる接続プールが用意されています。
JDBC 接続プールは、DBMS 接続の最適化に使用します。AquaLogic Service Bus JMS レポート プロバイダを使用している場合、JDBC 接続プールのサイズをコンフィグレーションすることで、AquaLogic Service Bus のパフォーマンスを調整できます。設定が小さすぎると、接続可能になるまでの AquaLogic Service Bus の待機時間が長くなる可能性があります。設定が大きすぎると、DBMS のパフォーマンスが低下する可能性があります。
WebLogic JDBC 接続プールの詳細については、以下を参照してください。
実行スレッドプールによって、WebLogic Server で同時に実行可能なスレッド数を制御できます。設定が小さすぎると、処理が同時に行われなくなり、デッドロックが発生する可能性が高くなります。設定値が大きすぎると、メモリが過度に消費され、スラッシングが発生する可能性が高くなります。
また、実行スレッドの数によって、受信ソケット メッセージを読み込むスレッド数 (ソケット リーダ スレッド) が決まります。デフォルトでは、この数は、実行スレッド数の 1/3 です。この数が小さすぎると、ソケットを読み込むスレッドが競合して、デッドロックが発生する可能性が高くなります。
実行スレッド プールは、予想されるスレッドの合計数を実行できる程度に設定してください。ただし、システム内のコンテキストの過度の切り替えによってパフォーマンスが低下してしまうほど高く設定しないでください。実行しているシステムをモニタし、さまざまな値を試して実行スレッド プールに最適な値を決めてください。
| 注意 : | ほとんどのプロダクション アプリケーションでは、実行スレッド カウントをデフォルト値より大きくする必要があります。一般的に使用されるスレッド カウント値は 50 です。実際のスレッド カウント値に合わせて JDBC 接続プールを調整してください。 |
スループットの制御の詳細については、WebLogic Server 環境の設計とコンフィグレーションに関するドキュメントの「WebLogic Server 環境の新機能と変更点」にあるリンク先の「プロダクション環境でのサーバの自動チューニング」を参照してください。
WebLogic J2EE コネクタ アーキテクチャ (J2EE Connector Architecture : JCA) により、J2EE プラットフォームを異機種のエンタープライズ情報システム (Enterprise Information Systems : EIS) と統合できます。WebLogic JCA は、Sun Microsystems, Inc の J2EE コネクタ仕様、バージョン 1.0 に準拠しています。
WebLogic J2EE-CA については、『WebLogic リソース アダプタ プログラマーズ ガイド』の「J2EE コネクタ アーキテクチャ」を参照してください。
AquaLogic Service Bus のコンフィグレーション リソースには、コンフィグレーションを新しいドメインにデプロイするときに変更または調整可能な環境固有の設定があります。以下の節では、コンフィグレーションのデプロイ後に再コンフィグレーションが必要なリソースについて説明します。
ビジネス サービスは、メッセージの交換先となるエンタープライズ情報サービスの AquaLogic Service Bus での定義です。プロダクション環境のビジネス サービスでは、ロード バランシングと高可用性のため、複数のエンドポイント (URL) を指定できます。ビジネス サービスにエンドポイントを追加する方法については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」にある「ビジネス サービスの表示と変更」を参照してください。既存のエンドポイントの値を更新する方法については、『AquaLogic Service Bus Console の使い方』の「Change Center の使用」にある「環境値の検索と置換」を参照してください。
プロキシ サービスとは、AquaLogic Service Bus によって WebLogic Server のローカルに実装される仲介 Web サービスの AquaLogic Service Bus での定義です。プロキシ サービスを定義する大部分のメタデータは、新しい環境にデプロイする際に変更する必要はありませんが、以下の情報の更新が必要になることがあります。
プロキシ サービスの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」を参照してください。
AquaLogic Service Bus では WSDL (Web Service Definition Language) を使用して、プロキシ サービスとビジネス サービスを記述します。WSDL は Web サービスの内容、場所、呼び出し方法の記述に使用されます。
プロキシ サービスとビジネス サービスは既存の WSDL ファイルに基づいて定義することができ、AquaLogic Service Bus Console でサービスのコンフィグレーションを完了できます。サービスの定義の基になる WSDL ファイルは、AquaLogic Service Bus のリソースとして格納されます。これらのリソースを新しい環境にデプロイする場合、リソースを更新する必要はほとんどありません。AquaLogic Service Bus では、WSDL ファイル内の URL を実行時に使用しないためです。
| 注意 : | AquaLogic Service Bus では、HTTP プロキシ サービスごとに新しい WSDL ファイルが作成されます。サービスのエンドポイントに ?wsdl を追加すると、この WSDL ファイルの内容を表示できます。たとえば、AquaLogic Service Bus Examples Server を起動すると ([スタート│プログラム│BEA Products│Examples│AquaLogic Service Bus│Start Examples Server])、 loangateway2 プロキシ サービスの WSDL を http://localhost:7021/crejws_basic_ejb/loangateway2?wsdl で表示できます。 |
スキーマとは、XML ドキュメントの有効なコンテンツを定義するドキュメントです。スキーマは、AquaLogic Service Bus で交換されるメッセージに XML 情報を追加するときに使用されます。これらのリソースを新しい環境にデプロイする場合、更新の必要はほとんどありません。
AquaLogic Service Bus では、サービスやサーバに接続するときに、サービス アカウントを使用して認証が行われます。このリソースをプロダクション環境に合わせて使用する方法については、AquaLogic Service Bus のセキュリティ ガイドを参照してください。
AquaLogic Service Bus では、プロキシ サービス プロバイダを使用して、プロキシ サービスに資格レベルの検証を提供します。次の種類のセキュリティを使用できます。
このリソースを使用環境に合わせてコンフィグレーションする方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス プロバイダ」を参照してください。
AquaLogic Service Bus では、Web サービス ポリシー (WS-Policy) を使用して、Web サービス セキュリティ ポリシーをプロキシ サービスとビジネス サービスに関連付けます。このリソースをプロダクション環境に合わせてコンフィグレーションする方法については、AquaLogic Service Bus のセキュリティ ガイドを参照してください。
これらのリソースを新しい環境にデプロイする場合、更新の必要はほとんどありません。
トランスフォーメーション マップには 2 つのデータ型の間のマッピングが記述されます。AquaLogic Service Bus は、XQuery または eXtensible Stylesheet Language Transformation (XSLT) 標準のどちらかを使用したデータ マッピングに対応しています。これらのリソースを新しい環境にデプロイする場合、更新の必要はほとんどありません。
メッセージ フォーマット言語 (MFL) は、フォーマットされたバイナリ データを XML データに変換するルールを定義する BEA 独自の言語です。MFL ドキュメントを新しい環境にデプロイする場合、更新の必要はほとんどありません。
JAR (Java ARchive) は、一連の Java クラスを含む zip ファイルです。JAR は、プログラムを構成する、コンパイル済みの Java クラスと関連メタデータの格納に使用します。JAR は Java コード要素用の呼び出し可能なプログラム ライブラリとして機能します (それぞれの要素に対して個別にバインディングを要求するのではなく、単一のコンピレーション リンクが複数要素へのアクセスを提供します)。JAR を新しい環境にデプロイする場合、更新の必要はほとんどありません。
アラート送り先リソースは、AquaLogic Service Bus からのアラート通知を受信できる受信者のリストを取り込みます。一般的なシステム モニタ コンテキストでは AquaLogic Service Bus により生成されたアラートは、限られたユーザのセットに対して非常に有用です。AquaLogic Service Bus では、指定されたコンテキストに応じて、それぞれのアラート送り先リソースに受信者のセットが含まれるよう設定できます。アラート送り先は、メッセージ フローでコンフィグレーションされたアラート アクション、および SLA アラート ルールで使用されます。アラート送り先には、1 つまたは複数の送り先のタイプ (コンソール、レポート データ ストリーム、SNMP トラップ、電子メール、JMS キュー、JMS トピック) を含めることができます。電子メールおよび JMS 送り先の場合は、送り先リソースに電子メール アドレスまたは JMS URI のリストをそれぞれ含めることができます。アラート送り先を新しい環境にデプロイする場合、更新の必要はほとんどありません。
UDDI レジストリ リソースは、AquaLogic Service Bus で使用する UDDI レジストリの情報を格納するグローバル リソースです。UDDI レジストリ リソースをコンフィグレーションすると、対応するレジストリに AquaLogic Service Bus プロキシ サービスをパブリッシュしたり、AquaLogic Service Bus プロキシ サービスで使用するビジネス サービスをそこからインポートしたりできます。USSI レジストリ リソースをコンフィグレーションするには、アクティブ セッションで作業する必要があります。UDDI レジストリ リソースを新しい環境にデプロイする場合、更新または再コンフィグレーションを行う必要があります。デプロイメントの際の UDDI レジストリ リソースの更新方法については、「グローバル リソースの移行時に従うベスト プラクティス」を参照してください。
JNDI プロバイダ リソースは、AquaLogic Service Bus で使用する JNDI プロバイダの URL (クラスタ デプロイメントの場合は URL のリスト) を記述する、JNDI プロバイダの定義です。JNDI プロバイダ リソースはグローバル リソースであり、AquaLogic Service Bus ドメインを持つプロジェクト間でで再利用できます。JNDI プロバイダが保護されている場合、JNDI プロバイダ リソースの記述には、アクセスに必要なユーザ名とパスワードも保持されます。JNDI プロバイダ リソースを新しい環境にデプロイする場合、更新または再コンフィグレーションを行う必要があります。デプロイメントの際の JNDI プロバイダ リソースの更新方法については、「グローバル リソースの移行時に従うベスト プラクティス」を参照してください。
SMTP サーバ リソースは、AquaLogic Service Bus で使用する SMTP サーバの URL とポートを記述する、SMTP サーバの定義です。SMTP サーバ リソースはグローバル リソースであり、AquaLogic Service Bus ドメインを持つプロジェクト間でで再利用できます。SMTP サーバが保護されている場合、SMTP サーバ リソースの記述には、アクセスに必要なユーザ名とパスワードも保持されます。SMTP サーバ リソースは、アラート送り先リソースおよび電子メール転送ベースのビジネス サービスのコンフィグレーションを行う際に使用されます。SMTP サーバ リソースを新しい環境にデプロイする場合、更新または再コンフィグレーションの必要があります。デプロイメントの際の SMTP サーバ リソースの更新方法については、「グローバル リソースの移行時に従うベスト プラクティス」を参照してください。
グローバル リソースには UDDI レジストリ リソース、JNDI プロバイダ リソース、および SMTP サーバ リソースがあります。これらのリソースは、通常、テスト環境では、ステージング環境やプロダクション環境とは異なる値を使用します。テスト環境からプロダクション環境にデプロイメントを移行する場合、次の方法のいずれかを使用します。
config.jar ファイルだけインポートします。アラート送り先、JNDI プロバイダ、または SMTP プロバイダを参照する config.jar ファイルにリソースが含まれている場合、インポートが完了すると、これらの参照は所定の場所に配置されます。config.jar ファイルをインポートするときに、グローバル リソースを除外します。
AquaLogic Service Bus では、JMS レポート プロバイダによるメッセージ レポート データの格納はデータベース リソースに依存します。データベースのパフォーマンスは、AquaLogic Service Bus 全体のパフォーマンスを決定する要因の 1 つです。AquaLogic Service Bus アプリケーションに関連するデータベース チューニングの要件については、BEA AquaLogic Service Bus リリース ノートを参照してください。
データベースのチューニングの詳細については、データベース ベンダのドキュメントを参照してください。
ハードウェア、オペレーティング システム、およびネットワーク リソースは、AquaLogic Service Bus パフォーマンスにとって重要な役割を果たします。デプロイメントは、BEA AquaLogic Service Bus リリース ノートに記述されたハードウェア要件およびソフトウェア要件に従う必要があります。
  
|
