10gリリース2（10.1.2）
B25067-01
 目次 |
 索引 |
| Oracle Application Server Reports Services レポートWeb公開ガイド 10gリリース2（10.1.2） B25067-01 |
|
この章では、関連するOracle Reportsコンポーネントのアーキテクチャを、レポート公開コンポーネントOracleAS Reports Servicesとともに説明します。また、レポート実行時処理の概要についても説明し、Reports Server環境設定時の考慮事項も示します。
この章には、次の項があります。
OracleAS Reports Servicesは、Oracle Application Serverのレポート公開コンポーネントです。これは、質の高い運用レポートを作成する企業レポート・サービスで、動的にあらゆるデータを取得し、あらゆるフォーマットに成形し、そしてあらゆる宛先へ配布します。OracleAS Reports Servicesを使用すると、Webベースの環境と非Webベースの環境の両方での公開が可能です。
拡張性に優れ柔軟性の高いアーキテクチャを備えるOracleAS Reports Servicesは、レポート生成エンジンを同一のサーバーおよび複数のサーバーに分散し、自動的に管理します。また、同様のリクエストが発行された際に再利用できるよう、レポート出力をキャッシュします。このサービスは、JSP、Javaサーブレット、WebサービスおよびCGI（下位互換性を確保するために維持）を使用する標準のWeb環境と統合されます。また、ローカルとリモートの両アプリケーション・サーバーでのレポート実行、およびレポート実行用に複数層アーキテクチャの実装が可能です。
OracleAS Reports Servicesを、JSP、Javaサーブレット、WebサービスまたはCGI（下位互換性を確保するために維持）と組み合せると、Webブラウザで標準的なURL構文を使用して、任意のプラットフォーム上でレポートを実行できます。サーブレットを実装する場合は、応答が速く、管理が簡単なインプロセス・サーバーを使用できます。インプロセス・サーバーを使用すると、プロセス間の通信コストが削減され、結果的に応答時間が短縮されます。
OracleAS Reports Servicesは、すべてのジョブ・リクエストを1つのジョブ・キューに入れてレポートを実行するようクライアント・リクエストを操作します。いずれかのサーバーのエンジンが使用可能になると、キューで待機している次のジョブが実行されます。キューのジョブ数が増えると、サーバーはエンジンをサーバー構成で指定した最大数まで増やすことができます。同様に、エンジンは、指定したアイドル時間（第3章「OracleAS Reports Servicesの構成」を参照）を超えた場合、自動的に停止します。
OracleAS Reports Servicesは、実行中のジョブ、実行予定のジョブ、完了したジョブ、失敗したジョブなど、サーバーに送信されたすべてのジョブを追跡します。showjobsコマンド（rwservletを介したWeb）、Webサービスのインタフェース、Oracle Enterprise Manager 10gのOracleAS Reports Servicesページ、Reports Queue Manager（Windows）およびReports Queue Viewer（UNIX）を使用すると、ジョブのスケジューリング、キューイング、開始、終了およびエラーの時刻情報のほか、ジョブ出力やレポートの最終ステータスに関する情報を表示できます。
OracleAS Reports Servicesのジョブ情報は永続的です。したがって、Reports Serverを停止した後に再起動すると、スケジュールされたジョブだけでなく、すべてのジョブが回復します1。
Web環境で使用する場合、OracleAS Reports Servicesのアーキテクチャは次の4つの階層で構成されます。
非Web環境で使用する場合は、次の3つの階層で構成されます（Webサーバーが不要になります）。
これらの層の構成方法は、すべての階層を同一マシン上に設定する方法や各階層をすべて別のマシン上に設定する方法などがあります。また、複数のマシンに複数のWebサーバーをインストールしたり、複数のマシンに複数のアプリケーション・サーバーをインストールすることもできます。サンプル・トポロジの詳細は、Oracle Application Serverのインストレーション・ガイドを参照してください。
Webサーバーを複数のマシンにインストールすると、複数のOracle Application Serverインスタンスをクラスタ化してロード・バランシングを行い、可用性の高いフェイルセーフ環境を実現できます。ロード・バランシングの詳細は、Oracle Application Serverのインストレーション・ガイドを参照してください。エンタープライズ・デプロイメント・アーキテクチャと高可用性の詳細は、『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』および『Oracle Application Server高可用性ガイド』を参照してください。
OracleAS Reports Servicesは、イベント・ベースのレポートを提供します。この方法では、データベース・イベントを使用して、レポート生成を実行します。たとえば、収益レベルが特定の水位標を上回った（下回った）という変更を通知するイベントを定義できます。データベースでこの変更（イベント）が発生すると、レポートが自動的に生成されます。詳細は、第17章「イベント・ドリブンによる公開の使用方法」を参照してください。
OracleAS Reports Servicesには、XMLを使用して、レポート配布用の独自の構成を定義する配布モジュールが付属しています。必要なXMLファイルをランタイム・コマンドラインまたはURLからコールしてレポートを1つ生成すれば、多様な出力と宛先の処理がサーバーにより実行されます。処理時間が大幅に短縮され、構成変更はすべてXMLファイル内で処理できます。詳細は、第15章「拡張配布の作成」を参照してください。
図1-1は、稼動中のOracleAS Reports Services環境のコンポーネントを示しています。これには次のものが含まれます。
rwservlet）は、Webサーバーのサーブレット・エンジン内で実行されるOracleAS Reports Servicesのコンポーネントです。Reports Servletは、HTTP ServerとReports Serverとの間で情報を変換および配布します。Reports Servletは、次のコンポーネントで構成されています。
rw:です。その他の接頭辞を持つその他のカスタム・タグが存在することもあります。
rwcgi）は、WebサーバーとReports Serverとの間で情報を変換および配布するWebサーバーのコンポーネントです。これにより、レポートをWebブラウザから動的に実行できます。
rwserver）はクライアント・リクエストを処理します。この処理では、クライアント・リクエストを、認証と許可の確認、スケジューリング、キャッシュ、および配布（カスタムまたはプラッガブル・デスティネーションへの配布）など、各種サービスに割り当てます。また、Reports Serverは、要求されたレポートを生成するランタイム・エンジンを起動したり、生成されたレポートをReports Serverキャッシュから取り出したり、ジョブの準備が完了したことをクライアントに通知したりします。
またOracle Reportsブリッジは、サブネットにわたってReports Serverを検出する機能を提供します。Oracle Reportsブリッジは、サブネットをまたいだReports ServerおよびReportsクライアント間でブロードキャストされるパケットのゲートウェイとして機能します。図1-1には、ブリッジのメカニズムは示されていません。詳細は、第1.4.1.2項「複数のサブネットにわたるサーバーの検出」を参照してください。
OracleAS Reports Servicesの各種コンポーネントがレポートの実行プロセスで果たす役割は、次のとおりです。
rwclientなど）を使用してサーバーに接続し、レポートを要求します。
rwservletまたはrwcgiにリダイレクトされます。これらはすべてOracle HTTP Serverに接続されています。JSPとrwservletのリクエストは、mod_oc4jにリダイレクトされます（JSPとして実行されるジョブでは、mod_oc4jはOJSPを使用してJSPをサーブレットに変換します）。rwcgiリクエストは、CGIコンポーネントにリダイレクトされます。URLには、ランタイム・パラメータまたはcgicmd.dat内のランタイム・パラメータ構成セクションを参照するキーワードを含めることができます。両方を含めることもできますが、URLで明示的に指定されているパラメータがcgicmd.datの関連キーワード・セクションに存在していてはなりません。
rwclientは、Reports Serverに直接リダイレクトされます。コマンドラインには、ランタイム・パラメータを指定できます。ランタイム・パラメータが多数ある場合には、rwclientコマンドとパラメータ文字列を含むバッチ・ファイルまたはシェル・スクリプトを作成できます。
rwservlet（または下位互換性を確保するためにのみ維持されるrwcgi）コンポーネントは、WebサーバーまたはJ2EEコンテナ（OC4Jなど）とReports Serverとの間で情報を次のように変換および配布します。
rwservletを使用したサーバー・リクエストは、インプロセス・サーバーで実行されるか、スタンドアロンのReports Serverプロセス（推奨）として実行されます。どちらであるかは、サーブレットの構成ファイル（ORACLE_HOME¥reports¥conf¥rwservlet.properties）で指定されます。インプロセス・サーバーは、スタンドアロンのReports Serverとは異なり、クライアントからのリクエストに応答して自動的に起動するため、メンテナンスが軽減されます。インプロセス・サーバーを使用すると、プロセス間の通信が削減されます。一方、スタンドアロン・サーバーは、OC4Jインスタンスからサーバー・プロセスを切り離すことで、rwservletの外部のプロセスをより高度に制御します。インプロセス・サーバーとデフォルトのネーミングの指定については、第3.4.10項「インプロセス・サーバーの指定」および第3.4.11項「インプロセス・サーバーの識別」を参照してください。
rwcgiを使用したサーバー・リクエストは、スタンドアロン・サーバーにリダイレクトされます。
リクエストにTOLERANCEオプションが含まれる場合は、Reports Serverがキャッシュをチェックして、そのリクエストを満たす既存の出力があるかどうかを判別します。キャッシュ内にリクエストを満たす出力があった場合、サーバーはレポートの再実行よりも、その出力を返すことを優先して行います。
|
注意
Reports Serverに送るどのジョブ・リクエストにも、 |
リクエストが現在実行中のジョブと同じ場合、そのリクエストは、レポートを再実行せずに現在のジョブの出力を再利用します。
これらの条件が満たされない場合は、次のように処理が実行されます。
cgicmd.datファイルのキーワード・セクション（URLリクエストのみ）で指定されたランタイム・パラメータに従って、キャッシュにアクセスし、出力するレポートを送ります。
また、イベント・ドリブンの公開を使用してレポートを作成することもできます。イベント・ドリブンの公開では、クライアントはエンド・ユーザーではなくデータベースです。イベントは、Event-Driven Publishing APIで定義されます。イベントは、Event-Driven Publishing APIをコールするデータベース・トリガー、アドバンスト・キューイング・アプリケーションまたはPL/SQLパッケージを起動して、ジョブをReports Serverに送ります。イベント・ドリブンの公開の詳細は、第17章「イベント・ドリブンによる公開の使用方法」を参照してください。
Oracle Workflowからのレポートの実行については、第3.8項「Oracle ReportsとOracle Workflowの通信の構成」を参照してください。詳細は、OTN（http://www.oracle.com/technology/products/reports/features/workflow）にあるホワイト・ペーパー『Integrating Oracle Workflow with Oracle Reports』を参照してください。
Oracle9i ReportsおよびOracle Reports 10gリリース1（9.0.4）は、Borland社のVisiBrokerのosagent実行可能ファイルを使用して、ネットワーク内のReports Serverを動的に検出します。
Oracle Reports 10gリリース2（10.1.2）では、Borland社のVisiBrokerではなく、業界標準であるSun社のJava Developer's Kit Object Request Broker（JDK ORB）が使用されます。これによって、複数のサブネットにわたるクライアントからのReports Serverリクエストのサポートが提供され、サブネット内および複数のサブネットで、動的なReports Serverの検出のためのブロードキャスト・メカニズムが使用されます。
Oracle Reports 10gリリース2（10.1.2）では、特別な設定を必要としないビルトイン・ブロードキャスト・メカニズムを使用してReports Serverを動的に検出できます。Sun社のJDK ORBで提供されるCommon Object Service（COS）ネーミング・サービスorbdを使用してReports Serverを検出することもできます。
この項では、Reports Serverを検出する次の2つの方法について説明します。
Oracle Reports 10gリリース2（10.1.2）には、JDK ORB実装を診断する
注意
rwdiag実行可能ファイルも導入されています。rwdiagは、以前のVisiBroker実装で使用可能であったosfindにかわる機能として使用できます。これにより、実行中のORBアプリケーションに関する情報や、ORB関連のネットワーク・トラフィックを記録するためのオプションが提供されます。rwdiagの詳細は、付録E「Reports Server とブリッジの診断ユーティリティ」を参照してください。
ブロードキャスト・メカニズムを使用すると、1つのサブネット内または複数のサブネットにわたってReports Serverを検出できます。
Oracle Reports 10gリリース2（10.1.2）のデフォルトのブロードキャスト・メカニズムでは、ホスト・マシンをネットワーク内に配置する必要があります。ホスト・マシンがネットワーク内にない（つまり、スタンドアロンである）場合、ビルトイン・ブロードキャスト・メカニズムは機能しません。したがって、OracleAS Reports Servicesは使用できません。特に、Oracle ReportsクライアントでReports Serverを検出したり、Reports Serverと通信したりすることはできません。ネットーワークの定義には、Virtual Private Network（VPN）は含まれないことに注意してください。つまり、ホスト・マシンがVPNを介してネットワークに接続している場合でも、Oracle ReportsクライアントでReports Serverを検出したり、Reports Serverと通信したりすることはできません。
そのため、ネットワークに接続していないスタンドアロンのホスト・マシンにインストールする場合、またはVPNを介してネットワークに接続している場合は、第3.3項「Reports Server検出メカニズムの構成」を参照してブロードキャスト・メカニズムをオフにし、かわりにネーミング・サービスをオンにします。
注意
サブネット内で、クライアントは接続先のReports Serverの名前を指定したパケットをブロードキャストします。指定された名前のReports Serverがネットワーク上にある場合は、レスポンスが返されます。次に、クライアントはレスポンスを返したReports Serverに接続して、レポート・リクエストを実行します。
rep_serverという名前のサーバーに対してレポート・リクエストを実行する例を次に示します。各手順の番号は図1-2の番号に対応しています。
Oracle Reportsでは、セキュアでない複数のサブネットを接続するブリッジ・メカニズムが提供されます。あるサブネットで実行されているOracle Reportsブリッジが別のサブネットで実行されているOracle Reportsブリッジに接続して、Reports Serverの参照を取得します。構成の詳細は、第3.3.2項「ブリッジの構成要素（bridgeconf.dtd）」を参照してください。
rep_serverという名前のサーバーに対してレポート・リクエストを実行する例を次に示します。各手順の番号は図1-3の番号に対応しています。
JDKで提供されるCommon Object Service（COS）ネーミング・サービスを使用して、同じサブネット内のReports Serverにアクセスしたり、セキュアでないサブネットにわたってReports Serverにアクセスしたりすることもできます。ネーミング・サービスを構成するには、第3.3.1項「ネットワークの構成要素（rwnetworkconf.dtd）」を参照してください。
rep_serverという名前のサーバーに対してレポート・リクエストを実行する例を次に示します。各手順の番号は図1-4の番号に対応しています。
OracleAS Reports Servicesの設定方法は、システムへの要求事項に応じて大きく異なります。OracleAS Reports Servicesを設定する前に、要求事項に基づいていくつかの決定を行う必要があります。事前にそのような決定を行うと、設定プロセスは非常に簡単になります。
次の各項では、これらの決定事項について説明します。
OracleAS Reports Servicesは、Webベースのリクエストと非Webベースのリクエストの両方を受け入れるよう構成できます。
Webベースの場合、WebブラウザでURLをクリックするか入力することでレポートを実行できます。URLに従って、レポート出力はブラウザに返されるか、プリンタなど指定された宛先に送信されます。ユーザーがブラウザからレポートを起動できるようにするには、Reports Servlet、JSPまたはReports CGIのいずれかのコンポーネントをWebサーバーで使用します。これらのコンポーネントのうちのいずれかとOracleAS Reports Servicesが通信し、Webクライアントからのレポート・リクエストの処理を可能にするには、そのコンポーネントがWebサーバー上に置かれている必要があります。
非Webベースの場合、各ユーザー・マシンにインストールされているrwclient実行可能ファイルを使用して、ジョブ・リクエストを送信できます。
構成の観点から見た、Webリクエストと非Webリクエストの有効化の重要な相違点は、次のとおりです。
Webベースにすると、クライアントのメンテナンス・コストが削減されるため、最も費用効果が高くなります。ただし、非Webリクエストの実行が必要な場合もあります。OracleAS Reports Servicesは、単一の実行環境でWebリクエストと非Webリクエストの両方の実装をサポートします。
OracleAS Reports ServicesをWeb環境で使用するには、サーブレット、JSP、またはCGIを実装する必要があります。rwservlet（Reports Servlet）、Reports WebサービスまたはReports JSPを選択することを強くお薦めします。これは、Reports CGIではリクエストごとに新規プロセスが内部的に起動されるためです。起動された各プロセスによってJVMが初期化されます。そのため、多数のレポート・リクエストを実行する場合はパフォーマンスが低下します。一方、Reports ServletはOC4Jインスタンスにデプロイされており、サーブレットの機能を利用するため、Reports CGIよりも高いパフォーマンスを提供します。
Reports ServletとReports JSPのどちらを選択するかについては、さらに考慮が必要です。JSPのみを実装すると、Web配信に適したレイアウト（Oracle Reports Web Layout）を公開できます。サーブレットを使用すると、ペーパー・レイアウトをレポート公開ソリューションに含めることができ、OracleAS Reports Servicesの配布機能を最大限に活用できます。
JSPファイルにはWebレイアウトとペーパー・レイアウトの両方を含めることができるため、Reports Servletを使用してもJSPファイルも使用できます。JSPに格納されているレポートを実行するときは、サーブレットをURLで指定し、JSPをコマンドライン・オプションreport=myreport.jspでコールします。この場合、レポート出力はペーパー・レイアウトに基づいて作成されます。
レポート実行の詳細は、第13章「レポート・リクエストの実行」を参照してください。
OracleAS Reports Servicesは、Webサーバーと同じマシン上に置くことも、異なるマシン上に置くこともできます。どちらも長所と短所があります。
たとえば、OracleAS Reports ServicesとWebサーバーを同じマシンに置くと、マシンのメモリーとディスク領域の消費量が増えますが、ネットワークの通信量は減少します。これは、Webサーバーとアプリケーション・サーバー間でやり取りするリクエストがネットワークを経由せず、受信リクエストのみがネットワークを経由するためです。
インプロセス・サーバーを使用している場合（Reports Servletを実装している場合のみ使用可能）、シングル・マシンのパフォーマンス上の利点がさらに高まります。インプロセス・サーバーは、OracleAS Reports Servicesのコンポーネント間の通信をより高速化および効率化するので、処理時間が短縮されます。Reports Servletを使用せずにレポートを配布する場合を除き、インプロセス・サーバーを使用することをお薦めします。
一方、シングルマシン構成を使用している場合に、そのマシンに障害が発生すると、すべてが失敗します。
Webサーバーとアプリケーション・サーバーが別々のマシンに置かれている場合、ネットワークの通信量が増大しますが、CPU、ディスク領域、利用可能なメモリーなど、システム・リソースが増えるという利点もあります。マルチマシン構成の場合も、インプロセス・サーバーがあると、OracleAS Reports Servicesのコンポーネント間の通信が高速化されるので、パフォーマンスが向上します。
また、Webサーバーとアプリケーション・サーバーをそれぞれ複数のマシンに置くという方法もあります。この方法には追加構成が必要ですが、Webサーバーのロード・バランシングが可能になります。
環境切替え機能を使用すると、言語などの環境設定が異なる複数のReports Engineを同じReports Serverで起動できます。動的な環境切替えの詳細は、第3.2.2項「動的な環境切替え」を参照してください。
この項では、高可用性環境の選択における次の側面について説明します。
Oracle Application Serverは、分散トポロジに配置可能な様々なコンポーネントで構成されています。Oracle Application Serverでは、高可用性を実現するための基礎となるパラダイムとしてクラスタリングを使用しています。クラスタリングでは、Oracle Application Serverの各種コンポーネントが一定の組合せで結合され、スケーラブルな統合機能を提供するとともに、個々のコンポーネントのいずれかで障害が発生した場合に備えて冗長性を提供します。
このマニュアルを読み進める前に、『Oracle Application Server概要』を通読して、Oracle Application Serverの様々なコンポーネントに関する知識を得ておくことをお薦めします。高可用性を実現する複数のソリューションと技法を導入することにより、次の目標を達成できます。
高可用性システムは、冗長性を確保するためにそのサブシステムを必要とします。『Oracle Application Server高可用性ガイド』に記載されている手順とソリューションを使用すると、Oracle Application Serverのすべてのコンポーネントを冗長に配置できます。コンポーネントは、そのタイプに応じて、アクティブ/アクティブ構成で配置することもアクティブ/パッシブ構成で配置することもできます。
アクティブ/アクティブ構成では、コンポーネントの複数のインスタンスがクライアント・リクエストを同時に処理します。あるインスタンスで障害が発生した場合、そのインスタンスが処理していたリクエストをアクティブな別のインスタンスで実行できます。このインスタンスの障害とフェイルオーバーは、クライアントに対して透過的です。通常、アクティブ/アクティブ構成は、コンポーネントのインスタンスをまとめてクラスタリングすることによって実現します。
アクティブ/パッシブ構成では、通常、リクエストはコンポーネントの1つのインスタンスによって処理されます。そのコンポーネントで障害が発生すると、別のインスタンスがアクティブ化されて、リクエストのワークロードに応答します。
Oracle Application Serverコンポーネントに属するローカルまたは分散ソフトウェア・プロセスは、集中的なプロセス管理システムによって管理されます。このプロセス管理システムでは、プロセスの障害を検出して、プロセスが複数のマシンに分散している場合でもプロセスを再起動できます。このシステムを使用すると、プロセスの障害と再起動を定義するパラメータ値（ハートビートの回数など）をカスタマイズできます。プロセス管理システムを実装しているプロセスは、それぞれシャドウ・プロセスを備えており、冗長性を実現しています。
システムのコンポーネントをまとめてクラスタリングすることにより、クライアント側は、これらのコンポーネントを機能的に1つのエンティティと見なすことができます。クラスタにより、コンポーネントのスケーラビリティ、可用性および管理性が向上します。
Oracle Application Serverコンポーネントでは、複数のクラスタ・タイプを使用できます。これらのクラスタを作成および構成する手順は、『Oracle Application Server高可用性ガイド』で詳しく説明しています。『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』には、クラスタ環境の設定に関する情報も含まれています。
ステートフル・クライアント・リクエストでは、これらのリクエストを処理しているプロセスに障害が発生した場合、Oracle Application Serverは、リクエストのステートフル・フェイルオーバーを有効にするためにクライアント状態をレプリケートできます。J2EEリクエストでは、使用する方法に応じて、J2EEアプリケーションのクライアント状態を宣言的にレプリケートすることも、プログラムによってレプリケートすることもできます。その他の大部分のコンポーネントでは、Cookieを使用した状態ベースのルーティングを使用できます。
多くの場合、クライアントはサーバー上のサービスに接続し、その接続を再利用します。サーバー上のサービスのいずれかを実装しているプロセスを再起動すると、接続の再確立が必要になることがあります。
Oracle Application Serverコンポーネントでは、再利用の接続に失敗すると、失敗の状態がシステムの他の部分に伝播する前に再接続が試行されます。これにより、接続の失敗をクライアントから透過的にすることができます。
Oracle Application Serverは、システム状態をバックアップして障害からのリカバリに使用する機能を備えています。状況によっては、コンポーネントまたはシステムの障害を修復できないこともあります。Oracle Application ServerのBackup and Recovery Toolを使用すると、システムを一定の間隔でバックアップして、修復不可能な障害が発生したときにバックアップをリストアできます。
HTTPリスナーとJ2EEコンテナに固有の問題では、ランタイム構成管理システムを使用して、これらのコンポーネントに簡単にチェックポイントを設定できます。さらに、構成エラーを元に戻す操作も可能です。
重要なアプリケーションをホストしているOracle Application Serverサイトが物理的に存在する場所で、自然災害や物理的な障害が発生することもあります。『Oracle Application Server高可用性ガイド』では、こうした障害からリカバリするためのソリューションについて説明しています。このソリューションは、サイト間リカバリ・ソリューションです。このソリューションでは、Oracle Application Serverのサイト全体の状態をバックアップして、そのサイトから物理的に離れている別のサイトにリカバリすることができます。
Oracle Application Serverには多数の高可用性の機能が備えられているため、特定のサーバーやコンポーネントに障害が発生しても、その中間層での稼動を継続することができます。Oracle Application Serverの高可用性の機能を使用することを強くお薦めします。
Oracle Application Serverの高可用性の機能を活用して、OracleAS Reports Servicesでは、インフラストラクチャの依存性が損なわれると、次のアクションが実行されます。
|
 Copyright © 2003, 2005 Oracle. All Rights Reserved. |
|