|
|
このドキュメントでは、プロダクション環境に BEA WebLogic® Integration 10.2 ソリューションをデプロイする方法について説明します。以下の節では、組織で WebLogic Integration (WLI) ソリューションをデプロイする場合の主要な概念と操作について説明します。
| 注意 : | このドキュメントでは、WLI アプリケーションのソフトウェア ライフサイクルのデプロイメント フェーズについてのみ説明します。BEA WebLogic Platform アプリケーションのソフトウェア ライフサイクルにおけるデプロイメントに関する詳細については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。 |
WLI アプリケーションのビルド、コンフィグレーション、デプロイに使用できるサンプル ソースおよびユーティリティについては、WLI の「ソリューション サンプル」および PO Sample を参照してください。
| 注意 : | コード サンプルおよびユーティリティは dev2dev に掲載されていますが、BEA のサポート対象外です。 |
WLI は、新しいアプリケーションの開発、既存システムへの開発アプリケーションの統合、ビジネス プロセスの合理化、およびトレーディング パートナとの連携に使用できる機能を備えた、統一プラットフォームです。
WLI ソリューションをデプロイする場合、以下の目標を考慮します。
WLI のデプロイメントでは、以下の作業の一部または全部を完了する必要があります。
WebLogic Platform アプリケーションのデプロイメント タスクの詳細な一覧については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。
統合型ソリューションを正しくデプロイするためには、デプロイメント チームに、以下の役割を果たすメンバーを加える必要があります。
一人で複数の役割を兼任することもできます。デプロイメントのすべてのシナリオに全員が等しく関わることはありませんが、正しくデプロイするためには、各担当者の参加が必要です。
デプロイメント スペシャリストは、デプロイメント作業を調整します。デプロイメント スペシャリストには、WLI の機能に精通していることが要求されます。デプロイメント スペシャリストは、1 つまたは複数のサーバにさまざまな WLI 機能をコンフィグレーションしてきた経験を基に、専門知識を生かして、統合型ソリューションのデプロイメント トポロジを設計します。デプロイメント スペシャリストには、以下の分野の経験が要求されます。
WebLogic Server 管理者は、組織内の WebLogic Server デプロイメントに関する技術と操作について深い知識を持っていることが要求されます。ハードウェアとプラットフォームの知識を持ち、WebLogic Server のインストール、コンフィグレーション、モニタ、セキュリティ、パフォーマンス チューニング、トラブルシューティングなど、WebLogic Server デプロイメントのすべての管理作業に対する経験が要求されます。
データベース管理者は、組織内にデプロイされたデータベース システムに関する技術と操作について深い知識を持っている必要があります。データベース管理者には、以下の分野の知識が要求されます。
この節では、デプロイメントの段階で変更可能なリソースの概要を示します。
| 注意 : | 「リソース」という用語は、このドキュメントでは、主に技術的な資産を指します。「WebLogic Integration セキュリティの使用」では、例外的に、セキュリティ ロールとセキュリティ ポリシーを使用して、無許可のアクセスから保護する基底の WebLogic Server エンティティのことのみを指します。 |
この節では、WLI ソリューションのデプロイメントに深く関係する WebLogic Server リソースの一般情報を示します。これらのリソースは、WebLogic Server Administration Console や EJB デプロイメント記述子を使用してコンフィグレーションできます。
WebLogic Server には、多くのコンフィグレーション オプションと調整可能な設定があり、サポートされている任意の環境で WLI ソリューションをデプロイするために使うことができます。以下の節では、WLI のデプロイメントに最も関係する WebLogic Server のコンフィグレーション可能な機能について説明します。
作業負荷に対する許容量を増やすには、WebLogic Server をクラスタ環境で実行します。クラスタは、単体のユニットとして管理できるサーバのグループです。クラスタ化により、単一サーバよりもスケーラビリティの高いデプロイメント プラットフォームを構築できます。
クラスタ化の詳細については、「WebLogic Integration クラスタについて」を参照してください。
WebLogic Java Message Service (JMS) により、Java アプリケーションでメッセージ システムを共有し、メッセージを交換 (作成、送信、受信) することができます。WebLogic JMS は、Sun Microsystems, Inc の Java Message Service Specification version 1.0.2 に準拠しています。
JMS サーバはクラスタ化が可能です。また、接続ファクトリは WebLogic Server の複数のインスタンスにデプロイできます。さらに、「プロセス アプリケーション リソース」に示すように、JMS イベントの送り先をコンフィグレーションすることで、ワークフローの通知とメッセージを処理できます。
WebLogic JMS の詳細については、以下のトピックを参照してください。
WLI のデプロイメントでは、EJB の数がシステムのスループットに影響します。EJB プールまたは EJB キャッシュにより、システムに含まれる EJB の数を EJB のタイプに応じて調整できます。次の表では、EJB のタイプと関連する可変パラメータを示します。
EJB をコンフィグレーションしてスループットを制御する詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic Server EJB のチューニング」を参照してください。
JDBC (Java Database Connectivity) は、Java アプリケーションから SQL データベース内のデータにアクセスするために使用します。データベース接続を確立する際のオーバーヘッドを減らすために、WebLogic JDBC には接続プールが用意されており、すぐに使える DBMS への接続のストックとして利用できます。
JDBC 接続プールは、DBMS 接続の最適化に使用します。JDBC 接続プールのサイズをコンフィグレーションすることにより、WLI のパフォーマンスをチューニングできます。設定が小さすぎると、接続可能になるまでの WLI の待機時間が長くなります。設定が大きすぎると、DBMS のパフォーマンスが低下します。
WebLogic JDBC の詳細については、『WebLogic JDBC プログラマーズ ガイド』を参照してください。
実行スレッドプールによって、WebLogic Server で同時に実行可能なスレッド数を制御できます。設定が小さすぎると、処理が同時に行われなくなり、さらにデッドロックの発生する危険性が高くなります。設定が大きすぎると、メモリを過度に消費し、スラッシングが発生する可能性が高くなります。
また、実行スレッドの数によって、受信ソケット メッセージを読み込むスレッド数 (ソケット リーダー スレッド) が決まります。デフォルトでは、この数は実行スレッド数の 1/3 です。この数が小さすぎると、ソケットを読み込むスレッドが競合したり、デッドロックの原因となったりします。
実行スレッド プールは、予想されるスレッドの合計数を実行できる程度に設定してください。ただし、システム内のコンテキストの過度の切り替えによってパフォーマンスが低下してしまうほど高く設定しないでください。実行しているシステムをモニタし、さまざまな値を試して実行スレッド プールに最適な値を決めてください。
| 注意 : | ほとんどのプロダクション アプリケーションでは、実行スレッド カウントをデフォルト値より大きくする必要があります。一般的に使用されるスレッド カウント値は 50 です。実際のスレッド カウント値に合わせて JDBC 接続プールを調整してください。 |
実行スレッド プールをコンフィグレーションする方法の詳細については、『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 リソース アダプタ プログラマーズ ガイド』を参照してください。
プロセス アプリケーションは、EAR ファイルに保存されます。デプロイメント用の EAR ファイルをコンパイルするには、『BEA Workshop ユーザーズ ガイド』の説明に従って、Workshop アプリケーションをコンパイルする際の標準的な手順を使用します。
EAR ファイルは、複数の Web アプリケーションと共有のクラス ファイルで構成されています。生成されたスキーマ ファイルは、共有のクラス ファイルに組み込まれます。各 Web アプリケーションは IDE ワークスペースのプロジェクトに対応します (図 1-1 を参照)。
各 Web アプリケーションは、以下の要素で構成されています。
受信 JMS キューでは、最適化された内部フォーマットがメッセージに使用されます。これらは、WLI および WebLogic Platform のコンポーネント (プロセス コントロール、メッセージ ブローカ、バッファリングされたメッセージ機能など) によって暗黙的に使用されるためのものです。
| 注意 : | これらの入力キューは、アプリケーションで直接使用するためのものではありません。アプリケーションで直接使用することができる JMS キューを探す場合は、Workshop SOAP/JMS プロトコルまたは WLI JMS イベント ジェネレータを検討してください。 |
| 注意 : | SOAP/JMS プロトコルの詳細については、『BEA Workshop ユーザーズ ガイド』を参照してください。 |
| 注意 : | JMS イベント ジェネレータの詳細については、『WebLogic Integration Administration Console の使用』の「イベント ジェネレータ」を参照してください。 |
これは、プロセス定義で例外要素をディスパッチするのに使用されます。
図 1-2 は、プロセス Web アプリケーションのコンポーネントを示しています。
非同期ディスパッチャでは、ステートレス プロセスとステートフル プロセスで異なる対話形式を取ります。図 1-3 は、非同期ディスパッチャとステートレス プロセス間の対話の例を示しています。
図 1-4 は、非同期ディスパッチャとステートフル プロセス間の対話の例を示しています。
プロセス コントロールは、RMI、または最適化されたデータ フォーマットを使用した JMS のいずれかによって、メッセージをあるプロセスから別のプロセスに直接送信できます。RMI または JMS を使用するときには、WebLogic Server のロード バランシングの通常のルールが適用されます。一般にメッセージは、WebLogic Server ロード バランシングのサーバ親和性によってクラスタ内の 1 つのサーバに保存されます。
メモリ内のディスパッチャ テーブルによって、実行時にメッセージを送信するプロセス コントロールに必要な詳細情報を確認できます。このディスパッチャ テーブルは、アプリケーションがデプロイまたは再デプロイされると自動的に更新されます。
プロセス呼び出しの動作は、同期ディスパッチャと非同期ディスパッチのどちらで使用するかにより異なります。
図 1-5 は、同期ディスパッチでのプロセス コントロールの動作を示しています。
図 1-6 は、非同期ディスパッチでのプロセス コントロールの動作を示しています。
同期クライアント プロセスは、非同期プロセスと対話することもできます。
| 注意 : | 以下の専用の実行スレッド プールを作成することで、このコンフィグレーションのパフォーマンスを最適化できます。 |
| 注意 : | アプリケーションおよびトラッキング レベルの要件に適合するスレッド プール サイズを選択します。 |
| 注意 : | これらのプールを作成しない場合、デフォルト スレッド プールによってスレッドが消費されます。 |
このコンフィグレーションの詳細については、『ビジネス プロセス構築ガイド』の「同期/非同期のビジネス プロセスの構築」を参照してください。
実装例については、WLI の『ソリューション サンプル』を参照してください。
メッセージ ブローカのパブリッシュ コントロールまたはイベント ジェネレータを介してメッセージ ブローカでメッセージがパブリッシュされるたびに、次のアクションが実行されます。
メッセージ ブローカでは、プロセス コントロールと同じ JMS 非同期キューが使用されます。メッセージがキューに入ると、プロセス コントロールを使用して送信された場合と同じコードが適用されます。
メッセージ ブローカ コントロールによるパブリッシュの詳細については、図 1-7 を参照してください。
WLI には、多くのネイティブ イベント ジェネレータがあります。
JMS イベント ジェネレータは、メッセージ駆動型 Bean プールとしてパッケージ化します。クラスタ内の任意の台数の管理対象サーバを対象とすることができます。一般的に、物理的な JMS 送り先を使用する場合は 1 台の管理対象サーバ、分散送り先を使用する場合はクラスタを対象とします。
これらのイベント ジェネレータは、発行されるイベントをポーリングします。イベントを発行するには、各イベント ジェネレータを、メッセージ駆動型 Bean プールとしてパッケージ化し、特定の JMS キューでコンフィグレーションします。メッセージは、poll-interval の送信時刻に、イベント ジェネレータから関連するキューに送信されます。キューは、同一タイプ (ファイル、電子メールなど) のイベント ジェネレータ間で共有され、セレクタによってキュー内のメッセージが共有されます。
ポーリング イベント ジェネレータの対象を指定する方法は、表 1-2 に示すように、関連するキューを所有する JMS サーバの対象がどのように指定されているかによって異なります。
ポーリング イベント ジェネレータはポーリング中に競合するため、クラスタの 1 台の管理対象サーバでのみアクティブになるように制限されます。イベント ジェネレータが移行可能なキューに関連付けられているときは、ポーリング イベント ジェネレータの対象がクラスタであっても、そのイベント ジェネレータは、移行可能な JMS サーバを含む単一サーバ上でのみアクティブになります。
| 注意 : | WLI では、単一サーバを対象とするポーリング イベント ジェネレータがサポートされます。ただし、このコンフィグレーションは高可用性を必要とするアプリケーションには適しません。 |
HTTP イベント ジェネレータは、HTTP リクエストを受け取り、内容のタイプを調べ、メッセージをメッセージ ブローカ チャネルにパブリッシュするサーブレットです。
MQSeries イベント ジェネレータは、WebSphere MQ キューのメッセージをポーリングし、メッセージ (メタデータとしての MQMD ヘッダとメッセージのペイロード) をメッセージ ブローカ チャネルにパブリッシュします。コンテンツのフィルタ処理、およびその他の処理条件は、イベント ジェネレータのチャネル ルールで指定します。
HTTP と MQSeries のイベント ジェネレータはどちらも、単一の管理対象サーバまたはクラスタを対象に指定できます。
RDBMS イベント ジェネレータは、データベース テーブルをポーリングして、追加、削除、または更新された行を確認し、結果をメッセージ ブローカ チャネルにパブリッシュします。また、このイベント ジェネレータを使用すると、データベース テーブルにカスタム クエリを実行し、メッセージ ブローカ チャネルに結果をパブリッシュすることもできます。
詳細については、『WebLogic Integration Administration Console の使用』の「イベント ジェネレータ」を参照してください。
イベント ジェネレータのサスペンド状態は、サーバ再起動時には保持されません。サーバ再起動時にイベント ジェネレータがサスペンド状態にある場合、イベント ジェネレータはサスペンドされたままになり、イベントが処理されません。イベント ジェネレータを再起動するには、WebLogic Integration Administration Console でイベント ジェネレータを [実行中] に設定します。
詳細については、『WebLogic Integration Administration Console の使用』の「イベント ジェネレータ」を参照してください。
Trading Partner Integration (TPI) は、RosettaNet (バージョン 1.1 と 2.0) と ebXML (バージョン 1.0 と 2.0) の実装によりピアツーピア ビジネス プロトコルのフレームワークを提供します。
| 注意 : | Trading Partner Integration は以前は B2B と呼ばれていました。一部のリソース名には、以前のリリースの WLI から引き継がれた略語が使用されています。現在、Trading Partner Integration リソースには名前の一部として B2B が含まれています。 |
WLI をクラスタ化されたドメインにデプロイする場合、管理サーバのリソースを除き、すべての Trading Partner Integration のリソースをクラスタに平均的にデプロイする必要があります。Trading Partner Integration リソースの対象としてドメイン内のすべてのクラスタ サーバを指定すると、アプリケーションの高可用性、スケーラビリティ、およびパフォーマンスの向上を実現できます。
Trading Partner Integration のリソースとクラスタ化に関する詳細については、「クラスタ デプロイメントの設計」を参照してください。
Trading Partner Integration の負荷に対応するためのコンフィグレーションが可能なリソースの詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」を参照してください。
トレーディング パートナ管理リポジトリは、Trading Partner Integration の重要な要素です。このリポジトリとすべての Trading Partner Integration でのデータベース処理は、cgPool という名前の JDBCPool を使用した cgDataSource という名前の JDBCTxDataSource で実行されます。
| 注意 : | トレーディング パートナ管理リポジトリ用のデータベースを、同時アクセス機能を使用するようにコンフィグレーションすることができます。特定のデータベースに関する問題の詳細については、WebLogic Integration 10.2 の『リリース ノート』を参照してください。 |
トレーディング パートナ管理リポジトリからのデータは、サーバの起動時にキャッシュされます。これにより、このリソースへのアクセスが減少することでパフォーマンスが向上します。クラスタ化環境では、トレーディング パートナ管理リポジトリのデータは、管理サーバと各管理対象サーバにキャッシュされます。このキャッシュは、図 1-8 の方法で同期化されます。
WebLogic Integration Administration Console では、トレーディング パートナ管理リポジトリの更新、インポート、削除を行えます。WebLogic Integration Administration Console を使用してこれらの操作を行う方法については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」を参照してください。
Trading Partner Integration は、WLI-B2B Startup EJB によるサーバ起動時に初期化されます。
| 警告 : | WLI-B2B Startup EJB では、initial-beans-in-pool の値が 1 に設定されています。この値を変更すると、Trading Partner Integration が起動しなくなることがあります。 |
実行時には、Trading Partner Integration の送受信のメッセージが、別々のパスで配信されます。次の節では、送信と受信のビジネス メッセージのパスとプロセスのフローについて説明します。
図 1-9 は、送信ビジネス メッセージのパスを示しています。
図 1-9 は、以下のプロセス フローを表します。
wli.internal.b2b.rosettanetencoder.queue および wli.internal.b2b.ebxmlencoder.queue があります。wli.internal.msgtracking.queue に送信されます。WLI メッセージ トラッキングのメッセージ駆動型 Bean がこのキューをリスンします。WebLogic Integration Administration Console のトレーディング パートナ管理モジュールで設定されたトラッキング レベルに基づいて、各種メッセージ トラッキング テーブルが更新されます。
WebLogic Integration Administration Console を使用してトラッキング レベルを設定する方法については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」を参照してください。
図 1-10 は、受信ビジネス メッセージのパスを示しています。
B2BdefaultWebApp/WEB-INF/web.xml で指定した TPI Transport Servlet Filter によって受信されます。TPI Transport Servlet Filter によって URL がチェックされ、受信要求が TPI URL/要求かどうかが判定されます。送り先が Trading Partner Integration でない場合、メッセージは他のフィルタに送られ、最終的な送り先に送られます。b2b.war にパッケージ化されます。 wli.internal.msgtracking.queue に送信されます。WLI メッセージ トラッキングのメッセージ駆動型 Bean がこのキューをリスンします。WebLogic Integration Administration Console のトレーディング パートナ管理モジュールで設定されたトラッキング レベルに基づいて、各種メッセージ トラッキング テーブルが更新されます。
WebLogic Integration Administration Console を使用してトラッキング レベルを設定する方法については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」を参照してください。
WLI では、データベース リソースを広範囲に活用することで、実行時オペレーションを処理し、アプリケーション データの恒久性を維持します。データベースのパフォーマンスは、全般的な WLI のパフォーマンスの主要因になります。
WLI アプリケーションに関連するデータベースのチューニング要件については、「データベースの準備」および「可用性の維持」に記載されているデータベース固有の注意事項を参照してください。
データベースのチューニングの詳細については、データベース ベンダのドキュメントを参照してください。
ハードウェア、オペレーティング システム、およびネットワーク リソースは、WLI パフォーマンスにとって重要な役割を果たします。デプロイメントは、WebLogic Integration 10.2 の『リリース ノート』に記載されたハードウェアとソフトウェアの要件に準拠する必要があります。
デプロイメント用の WLI アプリケーションをコンフィグレーションするためにデプロイメント プランを使用できます。
デプロイメント プランは省略可能な XML ドキュメントであり、デプロイメント用の WLI アプリケーションを特定の WebLogic Server 環境に向けてコンフィグレーションする際に使用します。デプロイメント プランを使用することによって、デプロイメント記述子に定義されているプロパティ値をオーバーライドしたり、デプロイメント記述子に明示的に定義されていないプロパティ値を定義することができます。
詳細については、「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」の以下の節を参照してください。
また、PlanGenerator ツールを使用すると、デプロイメント コンフィグレーションの一部をデプロイメント プランにエクスポートすることができます。詳細については、「weblogic.PlanGenerator コマンドライン リファレンス」を参照してください。
  
|