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