|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.4 (第4版) 目次を表示 |
| 4. V6.2の変更点 |
WebOTX V6.2の変更点について、その概要について説明します。
| 4.1. Webサーバ (Apache HTTP Serverベース) |
Apache HTTP Server 1.3.33/2.0.54 をバンドル
Apache HTTP Serverの最新バージョン Apache HTTP Server 1.3.33/2.0.54 をバンドルしています。
詳細については、次を参照してください。
・Apache HTTP Server
mod_ssl 2.8.22/2.0.54 をバンドル
上記 Apache HTTP Serverに対応したバージョンである mod_ssl 2.8.22(Apache 1.3.33用)/2.0.54(Apache 2.0.54用)をバンドルしています。
| 4.2. Webコンテナ |
WebOTX Web Server 2.0 連携時にドメインを再起動が不要
WebOTX Web Server 2.0（Apache HTTP Server 2.0）と連携している時、新しく配備した Webアプリケーションに アクセスするためにドメインを再起動する必要がなくなりました。配備直後からアクセス可能です。
| 4.3. EJBコンテナ |
配備処理中のRMICコンパイル時間
配備時にサーバ内の配備サービスが行う、EJBのリモート・ホームとコンポーネントのインタフェースへのRMICコンパイルは、デフォルト・タイムアウト時間を1インタフェースに付き40秒から600秒に拡張しました。
| 4.4. 運用管理 |
管理単位について
WebOTX V6では、WebOTXシステムではなくドメイン単位で管理します。WebOTXシステムはドメインが管理するプロセスとなり、WebOTXシステムの管理はドメイン管理の一環として行われることになります。ドメインの起動によってWebOTXシステムは起動し、ドメインの停止によってWebOTXシステムは停止します。ただしドメインは動作させたままシステムだけを停止することは可能です。
WebOTX V5で複数のWebOTXシステムを作成していた場合は、V6で複数ドメインを作成することになります。
管理方法や制御ファイルが変わってしまうため、WebOTX V5で作成したシステムをそのまま移行することはできません。新たにドメイン作成から行う必要があります。
システムを構築、運用するための詳細手順についてはWebOTXマニュアル運用ガイドをご覧ください。
ログインについて
管理方法が変わり、V6ではJMXによる運用管理となりました。よってログイン操作もこれまでとは異なりJMX仕様に従ったログイン操作となります。 運用管理ツールを起動してログインする際、V6では、ドメイン名、ホスト名、ポート番号、ユーザ名、パスワード、プロトコルを設定して接続することになります。ドメイン名、ポート番号、ユーザ名、パスワードはドメイン作成時に指定した値を指定します。
動作プロセスについて
管理方法が変わり、V6ではJMXによる運用管理となりました。よって動作プロセスも大きく変わっています。 V6で動作するプロセスについては、[ リファレンス > プロセス一覧 ] をご覧ください。
WebOTXシステム配下のツリー表示について
WebOTX V5とV6では運用管理ツールから見たシステム配下の表示が大きく変わりました。以下にその差異について説明します。
共有コンポーネントの設定について
V5ではプロセスグループ単位で使用する共有コンポーネントの定義を行なっていましたがV6ではコンポーネント単位で定義を行なうようになりました。
CORBAアプリケーションの配備について
V5ではCORBAアプリケーションを配備する場合、モジュールファイルおよびifファイルを個別に指定していましたが、V6ではCORBAコンポーネントパッケージ(cpk)にパッケージ化して配備を行ないます。運用管理ツールやコマンドからCORBAアプリケーションの配備を行なうときはパッケージファイルを指定することになります。なおパッケージ化は統合運用管理ツールでGUIを用いて行なえるほか、パッケージをを行なうための専用コマンド(makecpk)を提供しています。
共有コンポーネントの配備について
V5では共有コンポーネントを配備する場合、モジュールファイルおよびifファイルを個別に指定していましたが、V6では共有コンポーネントパッケージ(spk)にパッケージ化して配備を行ないます。運用管理ツールやコマンドから共有コンポーネントの配備を行なうときはパッケージファイルを指定することになります。なおパッケージ化は統合運用管理ツールでGUIを用いて行なえるほか、パッケージをを行なうための専用コマンド(makecpk)を提供しています。
システム上限設定について
V5ではシステムモデルに応じて各システム上限値が規定されましたが、V6では新たなシステム上限設定を設けています。上限値設定時にはこれらの値も含めて設定するようにしてください。
プロパティの設定
V5運用管理ツールでは、メニューからプロパティを開いて設定を行っていましたが、V6統合運用管理ツールでは、右側に表示された情報を参照・編集することが可能です。各プロパティに関してはタブを切り替えてご確認ください。なお各プロパティの具体的なV5との機能差異については運用管理におけるプロパティの変更点を参照ください。
運用管理コマンドについて
V6統合運用管理ツールから行うことができる各操作は、コマンドラインからの実行も可能です。ただし、WebOTX V5のwoadmcomコマンドは使用できません。なお各コマンドの具体的なV5との機能差異については運用管理におけるコマンドの変更点を参照ください。
ログについて
V6では、ログの体系を大幅に見直しています。log4jをベースにしており、通常のlog4jと同様な設定が可能です。 それに伴い、V5までの運用ログである以下の3つは出力されなくなりました。
サーバアプリケーションからwebotx.logに出力されていたログは、webotx_admlistener.logに出力されます。
システムトレース(<プロセスグループ名>_sys.<プロセスID>.log)が追加されました。
このログにはプロセス起動時の情報やCORBAアプリケーションで検出したエラーの情報が出力されます。
ファイルサイズ上限を超える出力があると、.bakという拡張子をつけて退避されます。
APログ、システムトレース、リカバリプロセス用ログの出力先は<WebOTXインストールディレクトリ>/domains/<domain名>/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>配下となり、ログ出力先及びログ名の変更は出来ません。
使用していないログは<WebOTXインストールディレクトリ>/domains/<domain名>/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>/saveディレクトリに退避されます。退避するとき、ログ名に数字8桁が追加されます。
メッセージ出力抑止
イベントログ、syslogに出力していた以下のメッセージの出力を抑止し、 出力先をWebOTXのログに変更しました。
| 4.5. 配備ツール |
Standard / Enterprise Editionへのアプリケーション配備
本バージョンからStandard / Enterprise Editionの実行環境に対応しました。 これにより、対象のサーバがこのエディションである場合に、配備先ターゲットとしてアプリケーション・グループとプロセス・グループを選択できます。
WebOTX V5以前では、配備ツールから直接配備操作できるターゲットがアプリケーション・グループのみでした。
ドメインの削除操作
「ドメインの追加」メニューでツリーに追加したドメインノードを削除できるように操作を改善しました。
ログインダイアログの省略操作
ドメインへの接続、または配備のたびにユーザ名、パスワード、配備先ドメインの確認と修正を行うダイアログが表示されていましたが、初回ログインの時にのみに省略できるオプションを追加しました。
強制再配備オプション
すでにドメインに配備されているコンポーネントと同名のものを同ドメインに配備しようとすると、再配備処理が行われます。 この時、毎回確認ダイアログが表示されていましたが、次回からの確認を省略して強制的に再配備を行うオプションを加えました。
JNDIアンバインド・オプション
通常の配備解除操作では、EJBのリモート・ホーム・インタフェースのリファレンスがJNDIサーバからアンバインドされます。 今回、アンバインドを行わないオプションを追加しました。
これは、同一EJBコンポーネントが複数ドメインに配備されていて、それらがクラスタ化された環境の場合に 1 つのコンポーネントを切り離す場合に利用します。
| 4.6. JMS |
Standard/Enterprise Editionへの対応
JMSの非同期受信を利用するコンシューマアプリケーションはJ2EEアプリケーションのMDBで構築することが一般的ですが、CORBAアプリケーションとして構築することも可能です。CORBAアプリケーションの場合、CORBAのクライアントアプリケーションからのCORBA呼び出しについてはユーザロジックを信頼性の高いTPモニタのスレッド上で処理されるため、障害時のリカバリや統計情報の採取などを行うことができます。さらにJMSの非同期呼び出し（onMessage）についても、設定によりTPモニタのスレッド上で処理させることが可能です。
Topicのマルチコンシューマ負荷分散
TPモニタ上でMDBや非同期受信を行うCORBAアプリケーションをプロセス多重で動作させるとJMSのコンシューマもそれに連動して多重化されます。これらの多重化されたコンシューマ群をひとつのグループとみなし、メッセージの配信を分散させる機能をTopicについてもサポートします。
JMXによる運用操作性向上
WebOTXの運用管理コマンド、統合運用管理ツールによるJMSの運用操作性を向上しています。JMSサーバの単独での起動停止や、JMSサーバ、物理的送信先、JMSリソースに関する設定を動的に行うことが可能です。
| 4.7. OLF/TPアダプタ |
JCA 1.5に対応
JCA（J2EE Connector Architecture）Ver.1.5に対応しました。
非同期受信に関してもJCA1.5準拠の方式に対応しました。
jms MessageListenerを使用するかcci MessageListenerを使用するか
選択することができます。
着信接続対応
非同期受信を行う際、EISからの着信接続に対応しました。
| 4.8. TPモニタ |
独自にスレッドを生成する場合について(Javaのみ)
WebOTX V5までは、Javaプロセス停止時にJavaの明示的な停止処理を行いませんでした。 Javaの停止処理は、生成された全てのスレッド(メインスレッド以外)が停止するのを待ち合わせてしまうため、サーバAPで独自スレッドを生成した場合にプロセスが停止しない問題が発生する可能性があったためです。 しかしJavaの停止処理を行わない場合、Javaプロファイルの採取などができなくなってしまう問題があったため、WebOTXV6からはこれを呼び出すように変更しました。 そのため、独自にスレッドを生成しているようなサーバAPが登録されている場合に、プロセスがなかなか停止しない可能性があります。 そのような場合は、プロセスグループの設定の「コマンドライン引数」に以下の値を設定することで回避できます。
ただし、このオプションを設定しますとJavaプロファイルの機能が利用できなくなりますのでご了承ください。
共有プロパティの解放処理について(C++のみ)
共有プロパティを使用する時、共有プロパティの削除API(WOPropertyGroup::DeleteProperty)
を呼び出しても、実際には共有メモリが削除されない問題がWebOTX V5まではありました。
V5では、オプションを用意して回避できるようにしていましたが、V6からはデフォルトで共有メモリを削除するようにしました。
もしこれによって問題が発生するような場合には、プロセスグループの設定の「環境変数」に以下の値を設定することで共有メモリを実際に削除しないV5以前と同様の動作にすることができます。
なお、旧互換のプロセスグループの場合は共有メモリを実際に削除しないV5以前と同様の動作がデフォルトになります。
プロセスグループの設定の「環境変数」に以下の値を設定することで、共有メモリを実際に削除する動作にすることができます。
旧バージョンの運用管理ツール・コマンドについて
WebOTX V6以降の運用管理ツール、コマンドではWebOTX V5の運用操作は行なえません。 また、V5の運用管理ツール、コマンドではWebOTX V6以降の運用操作は行なえません。