WebOTX Manual V10.4 (第4版) 目次を表示 |
4. WebOTX V7.1の変更点 |
WebOTX V7.1の変更点について、その概要について説明します。
| 製品全般 | アプリケーション実行環境 | 運用管理・運用ツール | 開発環境 | 拡張製品 | 旧バージョンでの変更点 |
4.1. 製品全般 |
製品名称
WebOTX V7から、「WebOTX」という名称をブランド名に位置付けました。 これにより、製品名称が「WebOTX <製品名>」のように変更されます。 製品名称に変更があるものについて、旧バージョンとの比較表を以下に示します。
V7の新名称 | V6以前の旧称 |
---|---|
アプリケーションサーバ | |
WebOTX Application Server Web Edition | WebOTX Web Edition |
WebOTX Application Server Standard-J Edition | WebOTX Standard-J Edition |
WebOTX Application Server Standard Edition | WebOTX Standard Edition |
WebOTX Application Server Enterprise Edition | WebOTX Enterprise Edition |
新名称では、「WebOTX」とエディション名の間に「Application Server」が挿入されます。 | |
拡張製品 | |
WebOTX Developer | WebOTX開発環境 |
WebOTX Administrator | WebOTX運用環境 |
WebOTX Cluster | WebOTXクラスタ環境 |
WebOTX Download Server | WebOTXダウンローダ |
WebOTX OLF/TP Adapter | WebOTX OLF/TPアダプタ |
WebOTX VIS Connector | WebOTX VISコネクタ実行環境 |
WebOTX WebAP JSP | WebOTX WebAP JSP 実行環境 |
WebOTX WebAP JSP Developer | WebOTX WebAP JSP 開発環境 |
WebOTX Connector Developer | WebOTX コネクタ開発環境 |
WebOTX Print Kit | WebOTX印刷キット |
ライセンス | |
CU License | 追加CU |
複数CPU・コアを搭載するマシンに対するライセンス計算方法
いくつかのWebOTX製品には、インストール対象のマシンに搭載されるCPU数に応じて追加のCUライセンスを登録するものがあります。 WebOTXでは、1個のマイクロプロセッサの中に2つ以上のプロセッサを集積した、マルチコアCPUの場合は、1個のコアを1CPUとしてカウントします。
WebOTX V7では、マルチコアCPUに対してカウント方法を変更しました。
マルチコアCPUの場合でも、1CPUとして計算します。
Standard-J Editionでは、コア数とは関係なく、単純にプロセッサ・パッケージの個数だけでライセンス数を計算することになります。
WebOTX Application Server Standard/Enterprise Editionや、その他の拡張製品に該当します。
1個のプロセッサ・パッケージに4個のコアを搭載している「クアッドコア」については、1/2として計算します。
例えば、クアッドコアCPUを1個搭載したマシンの場合、「2 = 4 * (1/2)」となり、2CPUと見なします。 なお、シングルコアとデュアルコアの搭載マシンに関しては、従来どおりの計算方法となります。
インストール選択
インストーラの選択構成が一部、旧バージョンから変更になっています。ご注意してください。
JMS
WebOTX AS Standard-J、Standard、Enterprise Editionにおいて、JMSが必須インストールに変わりました。
WebOTX Developer (旧 WebOTX開発環境)
WebOTX Developerは、提供する開発機能により2つにインストーラが別れました。
WebOTX Developer (with Developer's Studio) は、J2EEアプリケーションの開発に利用できるIDE機能(Developer's Studio)と各種プラグイン機能をインストールします。 また、テスト用サーバをインストールすることで、J2EEアプリケーションの開発/配備/実行(デバッグ)までを一貫して実行できます。 Windows(x86)環境でのみインストール可能です。
WebOTX Developer (for CORBA Application) は、CORBAアプリケーションの開発を行うために必要なヘッダ、ライブラリ、およびデバッグ用のDLLファイルをインストールします。 また、Microsoft Visual BasicクライアントアプリケーションやJMSアプリケーションの開発に必要なファイルもインストールします。
このように、用途によって2つのインストーラが存在しますが、1つのWebOTX Developerライセンスで両方を共通に使用できます。 J2EEとCORBAのアプリケーションを1つのマシンで開発するために両方をインストールする場合は、1つのライセンスキーを双方で利用できます。
4.2. アプリケーション実行環境 |
4.2.1. CORBA通信基盤 (Object Broker) |
Web Editionにおけるサービス起動の抑止
JNDIサーバでは、Object Brokerの名前サーバを必要としないアクセス方式をサポートしました。その結果、Web Editionでは、Object Brokerサービスを起動する必要がなくなりました。このため、インストール時に生成されるドメインでは、Object Brokerのoadや名前サーバなどのサービスを起動しないように変更しました。
4.2.2. Webサーバ |
4.2.2.1. V7.11での変更点 |
Apache HTTP Server 1.3.39/2.0.61 をバンドル
Apache HTTP Server の最新バージョンである
Apache HTTP Server 1.3.39/2.0.61 をバンドルしています。
詳細については、次を参照してください。
Apache HTTP Server
mod_ssl 2.8.30/2.0.61 をバンドル
上記 Apache HTTP Server に対応したバージョンである mod_ssl 2.8.30 (Apache 1.3.39用)/2.0.61(Apache 2.0.61用) をバンドルしています。
OpenSSL 0.9.8g をバンドル
OpenSSL ライブラリの最新バージョンである OpenSSL 0.9.8g をバンドルしています。
運用管理ツール/コマンドから定義情報の更新をサポート
WebOTX 統合運用管理ツール/運用管理コマンドから、Webサーバの定義情報の
更新処理をサポートしました。
これにより、Webサーバの定義情報ファイル(httpd.conf)をエディタで直接編集する
ことなく、WebOTX 統合運用管理ツール/運用管理コマンドから、
ポート番号の変更等の Webサーバの定義情報の更新処理が可能となります。
4.2.2.2. V7.1での変更点 |
Apache 2.0 の機能強化
64ビットOSとなる、HP-UX(IPF)、および Linux(x64) プラットフォームにおいて、WebOTX Webサーバ 2.0 をインストール選択した場合は、インストールされる Apache 2.0 モジュールが64ビットバイナリへ変更されました。
利用者が新しく組み込むモジュール (mod_xx など) は、64ビット用でコンパイルさている必要があります。
その他に、IPv6 のサポートと、Apacheで提供されている各種モジュールをバンドルします。
なお、WebOTX Webサーバ 1.3 をインストール選択したきに配置される Apache 1.3 モジュールについては、従来どおり 64ビットOSでも 32ビットバイナリがインストールされます。
4.2.3. Transactionサービス |
起動プロセス数削減による起動停止時間の短縮・メモリ使用量削減
Transactionサービスを動作させるために起動していたプロセスの数を削減しました。 1ドメインあたり最大で3プロセス削減しています。
WebOTX V6.5で提供するTransactionサービスの構成は下図のようになっています。 トランザクションのリカバリ処理を行うためのプロセスであるRCS(Recovery Coordination Server)がアプリケーションの種類によって3つ起動します(設定により起動しないようにすることは可能)。 さらにこれらRCSの状態監視を行うプロセス(RCD)が1つ起動するため、1ドメインあたり最大で4つのプロセスを起動しておりメモリ使用量が比較的大きくなっていました。 また、状態監視の手順が複雑なため性能面でも課題がありました。
上記の課題を克服すべく、WebOTX V7 ではプロセス構成を変更しました。 従来RCDの機能と、RCSの機能(Java AP用・クライアントトランザクション管理用の2種類)を運用管理エージェント内で動かすように変更しています。(*)
これによって、Transactionサービスの起動時間、および停止時間を前バージョンと比べて約半分に短縮しました。 また、Transactionサービス単体で消費するメモリ使用量についても前バージョンと比べて50%程度削減しています。
(*) RCS(C++ AP用)プロセスは従来どおりです。
4.2.4. EJBコンテナ |
Beanプールの設定項目の整理(Standard/Enterprise Edition)
Standard/Enterprise Editionでは、ステートレスセッションBeanおよび、メッセージドリブンBeanで使用されるBeanプールの設定項目が、プロセスグループのスレッド数と連動するようになりました。 これにより、EJBコンテナのプール設定項目はなくなりました。
既定値では、「通常プールサイズ」「最大プールサイズ」はスレッド数と同じ値です。 「プールサイズ変更量」はスレッド数の1/4(端数切り上げ)となります。 個別に設定したい場合は、WebOTX固有の配備記述子XMLファイルに記述してください。
4.2.5. TPモニタ |
Linux版のNative POSIXスレッド対応
V6.5以前のLinux版では、TPモニタ上で動作するプロセスがLinuxスレッドで動作していましたが、V7.1からはNative POSIXスレッドで動作するようになりました。
V7.1で新しく対応したLinux x64版も、同様にNative POSIXスレッドで動作します。
JavaシステムプロパティによるプロセスID利用
Standard/Enterprise Editionではマルチプロセスでサーバアプリケーションを動作させることができますが、各プロセスのプロセスIDを以下のJavaシステムプロパティから利用できるようになりました。
-Djp.co.nec.WebOTX.ProcessID
モジュール未配備時のプロセスグループ起動
モジュールを配備していない状態でも、プロセスグループが起動するようになりました。
V6.5以前は、プロセスグループ起動時にモジュールが配備されていないと、起動できませんでした。
コネクション切断メッセージのトレースレベル見直し
V6.5以前は、CreateServerObject()
が呼ばれてから、ReleaseServerObject()
が呼ばれる前にクライアントアプリケーションとのコネクションが切断された場合に、以下のログをエラーレベルで出力していました。
TerminalFail called.
Disconnecting terminal(IIOPLISTENER[数字]).
Disconnecting terminal(IIOPLISTENER[数字])(finished)
実際にはコネクションが切断されても異常とはいえないケースが多く、V7.1では(1)(3)のトレースレベルを7に、(2)のトレースレベルを6に変更しています。 デフォルトのトレースレベル設定(レベル5)では出力されなくなりました。
名前サーバ登録および削除時コールバックオペレーションの廃止
CORBAアプリケーションのオブジェクトリファレンスの名前サーバ登録、および、削除時コールバックオペレーションである、BindHooks
クラス(C++の場合はWOHooks
クラス)のサポートを廃止しました。
名前サーバに任意の名前でオブジェクトリファレンスを登録する際は、運用管理コマンド「otxadmin bind-ior
」を使用して下さい。
プロセスグループのバージョンが6または5の場合は、引き続き使用できます。
プロセス再起動関連の既定値変更
「プロセス障害時の再起動回数」の既定値を50から5に変更しました。 また、「プロセスを正常と仮定する間隔」の既定値を-1から3600に変更しました。
この変更により、3600秒間プロセスが異常終了しなかった場合、「プロセス障害時の再起動回数」は5にリセットされます。
Java VMの標準エラー出力先について
V7.11より、Java VMの本体部分が出力する標準エラー出力が、標準出力に向けられるようになりました。
プロセスグループの属性「標準出力出力先」または「エラー出力出力先」の設定を、既定値の「トレースに統合する」から「出力しない」に明示的に変更している場合にのみ影響があります。
既定値設定では、どちらもトレースに統合されるため、影響はありません。
Java VMの本体部分が出力するスタックトレースは、標準出力に出力されるため、こちらも影響はありません。
Java VM上で動作するアプリケーションの標準エラー出力に対しても影響はなく、従来どおりに動作します。
4.3. 運用管理・運用ツール |
4.3.1. 運用管理コマンド otxadmin |
4.3.1.1. V7.11での変更点 |
otxadmin コマンド拡張
set コマンドで指定するオペランド名に "*" 文字によるワイルドカード文字が指定できるようになりました。
4.3.2. JMX運用基盤 |
domain.xml暗号化
ドメインのコンフィグレーション情報を格納するdomain.xmlファイルにおいて、ファイル中に含まれるパスワード情報等の重要データがデフォルトで暗号化されるようになりました。
ドメイン起動時のバックアップ対象変更
ドメイン起動後に行われるバックアップの対象が変更になりました。デフォルトでは、ドメインのconfig(Enterprise Service Busの場合はjbiも対象)以下をバックアップの対象とします。設定を変更することにより、V6と同様にドメインの各種設定リソースファイルを対象とすることもできます。
バックアップのタイムアウト機能
ドメイン起動時に行われるバックアップに対し、タイムアウトが設定できるようになりました。タイムアウト時間を変更する際は、以下のシステムプロパティを設定してください。デフォルトのタイムアウト時間は20分です。
com.nec.webotx.admin.backupTimeoutSeconds=<タイムアウト時間>(単位:秒)
MEJBアプリケーションのデフォルト無効化
ドメインに対してMEJB(Management EJB)アプリケーションをデフォルトで配備しないよう変更しています。
MEJBアプリケーションをドメインに配備するためには、以下のファイル名を変更します。
変更後、ドメイン再起動時にMEJBアプリケーションが自動的にドメインに配備されます。
4.3.3. TPモニタ・マネージャ |
共有コンポーネント配備機能の改善
共有コンポーネント配備時に、共有コンポーネントを全てのモジュールで使用するか、指定できるようになりました。
また、CORBAモジュール配備時に、使用する共有コンポーネントの設定を行えるようになりました。
初期値の変更
以下の属性の初期値を変更しました。
4.3.4. 運用管理アシスタント |
属性表記の変更
以下の属性の表記を変更しました。
ログメッセージの変更
「OTX20220001」及び「OTX20220011」のメッセージ内容が変更されています。
4.3.5. 配備サービス |
domain.xmlの変更
アーカイブから配備したのか、ディレクトリから配備したのかという情報を、ドメインの構成情報ファイルであるdomain.xmlに記述するようにしました。 この情報を記述するために、domain.xmlの<applications>の子要素に属性directory-deployedを追加しました。
4.4. 開発環境 |
4.4.1. Developer's Studio |
運用管理
これまではテスト用サーバの運用管理をするための機能でしたが、WebOTX Administratorと組み合わせることで、Developer's Studio上でリモートホストの運用管理も可能となりました。
BPELエディタ
BPELエディタの定義画面を大幅に強化しました。連携しているプロセス要素の矢印表示、視覚的に分かりやすいプロセス表示、XPath式の入力支援機能の提供により、さらに簡単にBPELプロセスが定義できます。
JDK1.5サポート
WebOTX Developer (with Developer's Studio)にて、新規にJDK 1.5をサポートします。
4.5. 拡張製品 |
4.5.1. Enterprise Service Bus |
XSLT Service Engine
独自に開発したXSLTプロセッサである、 CHDL(ContentHandler Description Language)を利用するように変更しました。これにより変換速度の向上を実現しています。
XAトランザクション対応(JMS Binding Component)
JMS Binding Componentでは、WebOTX JMSとのメッセージ送受信において、2フェーズコミット(JTAのトランザクション制御)をサポートしました。これにより、ESBを介したJMSメッセージの送受信結果に一貫性を保障し、高い信頼性を提供します。
4.5.2. Process Conductor |
WS-BPEL 2.0正式仕様対応
OASISで策定されたWS-BPEL 2.0正式仕様をフルサポートしました。
ビジネスプロセス実行の簡易化
送受信などのビジネスプロセス設定をプロセス定義ファイル(BPARファイル)に含めることができるようになりました。 これにより、プロセス定義登録後の送受信設定操作が不要となり、定義登録後ただちにビジネスプロセスの実行が可能となりました。
ビジネスプロセス実行機能の信頼性・耐障害性向上
WebOTX Process Conductor V7.1の障害による停止からの復旧時、 障害発生時に実行していたビジネスプロセスを継続して実行可能となりました。 また、他のWebサービスを呼び出す際に通信障害が発生した場合、呼び出しアクティビティにてfaultを発生させるようにしました。 これにより、ユーザはビジネスプロセス上で通信障害を検知し対処できるようになりました。
ビジネスプロセスの同時実行数設定機能
ビジネスプロセス定義毎に、同時に実行可能なプロセス数の上限を設定する機能を追加しました。 これにより、大量のビジネスプロセス実行が要求された場合にリソース不足による障害が回避可能となりました。
4.A. 旧バージョンでの変更点 |
旧バージョンに関するものは、以下を参照してください。