WebSphere Application Server Network Deployment, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

管理者用の新機能

このトピックでは、実動サーバー環境をカスタマイズ、管理、モニター、および調整するユーザーに対する、 新機能または変更された機能について主に説明します。 また、アプリケーションのデプロイおよび操作を行うユーザーにも対応しています。

システム管理、モニター、および調整に関する最も大きな改良点および変更を以下にまとめます。

非推奨のフィーチャーと除去されたフィーチャー では、 このリリースまたは将来のリリースで差し替えまたは廃止されるフィーチャーについて説明しています。

マイグレーションを容易にするためのインクリメンタル・セル・アップグレード

マイグレーションの説明

セルによって構成される基本ノードをマイグレーションする前に、V5.x のデプロイメント・マネージャーを バージョン 6.1 にマイグレーションします。Network Deployment ノードは、セル内のすべてのノードを管理できるよう、 常にセル内で最新のリリース・レベルおよび修正レベルである必要があります。バージョン 6.1 の場合、 デプロイメント・マネージャーには、バージョン 6.1 およびバージョン 5.x ノードの両方を管理する機能があります。 これにより、一度に 1 つのノードずつ、セルを新規リリースにアップグレードすることができ、セル内で稼働中のアプリケーションへの影響を最小限にすることができます。

デプロイメント・マネージャーのインクリメンタル・マイグレーションについて詳しくは、Network Deployment バージョン 5.x からバージョン 6.0.x デプロイメント・マネージャーへのマイグレーション を参照してください。 管理対象ノードのインクリメンタル・マイグレーションについて詳しくは、バージョン 5.x 管理対象ノードからバージョン 6.0.x 管理対象ノードへのマイグレーション を参照してください。

混合セル・アップグレードの完了後の、パフォーマンスの改善

混合リリース・セル内のクラスター・メンバーに バージョン 6.1 クラスターおよび 5.0 から 5.1.0 の旧バージョンが含まれている場合は、 オブジェクト・リクエスト・ブローカー (ORB) カスタム・プロパティーが存在するため、注意する必要があります。 混合リリース・セルを バージョン 6.1 および V5.1.1 サーバーで実行する場合は、 この注記を無視できます。

該当する場合、マイグレーション・プログラムはクラスター内の 6.0.x デプロイメント・マネージャー、ノード・エージェント、およびサーバー上で ORB のカスタム・プロパティーを自動的に設定します。 セル全体を バージョン 6.1 に移行したあとで、プロパティーをリセットし、 パフォーマンスを改善することができます。

この com.ibm.websphere.ObjectIDVersionCompatibility 設定について詳しくは、オブジェクト・リクエスト・ブローカーのカスタム・プロパティー を参照してください。

追加のガイダンスについては、バージョン 5.x 管理対象ノードからバージョン 6.0.x 管理対象ノードへのマイグレーション を 参照してください。

間接的な方法でバージョン 5.x ノードを バージョン 6.1 セルに追加および除去できる

バージョン 5.x ノードを バージョン 6.1 セルに追加することはできません。 ただし、最初にノードを バージョン 6.1 にアップグレードしてから バージョン 6.1 セルにノードを追加することによって、同じ結果を得ることができます。

バージョン 6.1 セル内のバージョン 5.x ノードをセルから除去することはできません。次のいずれかの方法でも同じ結果が得られます。
  • ノードを 6.0.x にアップグレードしてから removeNode を実行します。または、
  • ノードをアンインストールしてから、dmgr で cleanupNode を実行します。
サーバーの管理

WebSphere Application Server バージョン 6.1 では、 セル内のノードの一部をアップグレードし、それ以外は旧リリース・レベルのままにしておくことができるようになりました。 つまり、一定期間、現行リリースのサーバーと新リリースが稼働するサーバーを、 同じセル内で管理することができます。 この混合環境では、旧リリース・レベルのサーバーでできることに制限があります。 詳しくは、アプリケーション・サーバーの作成 を参照してください。

クラスターおよびクラスター・メンバーの作成にも制限があります。

詳しくは、クラスターの作成 を参照してください。

既存の 5.x サーバーおよびクラスターは拡張できるが、いくつかの制約事項がある

制約事項: 既存の混合セル環境と、新規に作成された混合セル環境の間には、違いがあります。 既存の混合セル環境では、デプロイメント・マネージャー・プロファイルは V6.0.2 より前に作成されています。 新規に作成された混合セル環境では、 デプロイメント・マネージャー・プロファイルは V6.0.2 PTF 以降を適用した後に作成されています。 既存の混合セル環境の場合、 V5.x サーバーの作成に必要なデフォルトのサーバー・テンプレートは使用できません。 管理者は既存の V5.x サーバーから新規の V5.x サーバー・テンプレートを作成する必要があります。 このテンプレートを使用して、新規の V5.x アプリケーション・サーバー、 または新規クラスターの最初のクラスター・メンバーを作成できます。

サポートされるシナリオは、次のとおりです。
  • 既存の 5.x アプリケーション・サーバーおよび JMS サーバーは引き続き機能します。
  • 任意のバージョン・レベルでのサーバーの除去。
  • 6.0.x メンバーが既にクラスターに含まれている場合、クラスターへの新規 6.0.x メンバーの追加。
  • 5.x メンバーが既にクラスターに含まれている場合、クラスターへの新規 5.x メンバーの追加。
  • 最初のクラスター・メンバーとして 5.x サーバーを使用した、新規クラスターの作成。
  • 5.x サーバーのクラスターへの変換。
  • 新規 5.x アプリケーション・サーバーの作成。
以下はサポートされません。
  • 新規 5.x JMS サーバーの作成。
  • 6.x メンバーがまだクラスターに含まれていない場合、クラスターへの新規 6.x メンバーの追加。
  • 5.x メンバーがまだクラスターに含まれていない場合、クラスターへの新規 5.x メンバーの追加。

バージョン 6.1 JMS 機能では、JMS サーバーは不要です。 詳しくは、メッセージング・セクションを参照してください。

ノードはバージョンおよび機能を認識します。

オペレーティング・システム・プラットフォームおよび製品フィーチャーなどのノードに関する情報は、 プロパティーの形で構成リポジトリーで保守されます。 製品フィーチャーがノードにインストールされると、新規プロパティー設定が追加されます。

管理者はノードの機能を照会できます。詳しくは、管理対象オブジェクト・メタデータ を参照してください。

6.0.x 構成ファイルは 5.x ノードで使用できるように変換される

Websphere Application Server マスター構成リポジトリーには、セル内のすべてのノードの構成文書が保管されます。 バージョン 6.1 形式で保管されている構成ファイルは、 セル内のバージョン 5.x ノードが使用できるように、バージョン 5.x 形式に変換されます。

詳細については、構成文書 を参照してください。

ノードを バージョン 6.1にアップグレードした後、バックアップ構成を作成します

backupConfig ツールを使用して、ノードのバックアップ構成を作成するとします。 ノードのアップグレード後は、restoreConfig コマンドを使用して構成を復元できません。

アップグレードされたノードの復元に使用できるように、アップグレード後にバックアップを作成することを推奨します。

6.0.x 管理を使用して、5.x および 6.0.x アプリケーションを変更することができる

すべてのアプリケーションは、モジュールの再インストール、編集、または新規ターゲットへの再マップを通して更新できます。 モジュールの再マップ時に、バージョン 6.1 モジュールの新規ターゲットが、 バージョン 5.x ターゲットではない場合があります。

バージョン 6.1 クライアントからアプリケーションを編集する場合は、 すべての編集機能は、すべてのアプリケーションのバージョンで使用できます。 バージョン 5.x クライアントから バージョン 6.1 アプリケーションを編集する場合は、以下の機能は使用できません。
  • メッセージの宛先参照の Enterprise Bean へのマップ
  • J2CObjects の JNDI 名へのバインディング
  • J2CActivation の宛先 JNDI 名へのバインディング
管理クライアントには関連設定のみが表示され、設定はノード・バージョンに対して検証される

ノード、ノード・エージェント、またはサーバーのプロパティーを表示すると、管理コンソールはオブジェクトが常駐するノードのバージョンを認識し、このバージョンに対して有効なプロパティーのみを表示します。

wsadmin スクリプト・クライアントも、構成オブジェクトが常駐するノードのバージョンを認識します。 このバージョンに対して有効でないプロパティーを表示または変更しようとすると、例外がスローされます。 推奨されないプロパティーを表示または変更しようとすると、警告が記録されます。

提供される JDBC プロバイダーおよび DataSource テンプレートは 6.0.x レベルである

WebSphere Application Server でサポートされるデータベース・ベンダーのデータ・アクセス・オブジェクトの作成を簡素化するために、一連の JDBC プロバイダーおよび DataSource テンプレートが用意されています。これらのテンプレートは、管理コンソールから、または createUsingTemplate コマンドを使用して wsadmin から、JDBC プロバイダーおよび DataSource オブジェクトを作成する場合に使用します。使用可能なテンプレートは、デプロイメント・マネージャーのバージョンに基づきます。 バージョン 6.1 テンプレート・ファイルのすべてのテンプレートが、 以前のノード・レベルでサポートされているわけではありません。 新規 JDBC プロバイダーおよび DataSources をバージョン 5.x ノードで作成する場合は、使用しているテンプレートが、ノードの WebSphere Application Server リリース・レベルでサポートされていることを確認してください。

スクリプト内の構成 ID を永続化しないようにする

ObjectName で許可されているフォーマットが変更されたため、バージョン 6.1 の構成 ID には、 バージョン 5.x で「:」が使用されていた場所に「|」が挿入されています。 この変更は、wsadmin クライアントの出力に反映されます。

例えば、バージョン 5.x クライアントの出力を次に示します。
wsadmin>  $AdminConfig list Cell
DefaultCellNetwork(cells/DefaultCellNetwork:cell.xml#Cell_1)
以下は、バージョン 6.1 クライアントからの出力です。
wsadmin>  $AdminConfig list Cell
DefaultCellNetwork(cells/DefaultCellNetwork|cell.xml#Cell_1)

構成 ID は動的に生成されるため、区切り文字の変更は問題になりません。 ただし、構成 ID を永続化しないようにする必要があります。

バージョン 5.x クライアントが「:」を含む構成 ID を渡すと、 この構成 ID は、上方互換性を保つために、 JMX ランタイムにより「|」が含まれる構成 ID に自動的に変換されます。 同様に、後方互換性のために逆の変換も実行されます。

推奨されない、または無効な属性を認識する

タイプは、バージョン 5.x よりも多くの属性を組み込めるように、バージョン 6.1に拡張されていることがあります。 「$AdminConfig attributes type」コマンドは、バージョン固有ではありません。 このコマンドは、新規属性がバージョン 5.x ノードで使用できない場合でも、そのタイプに対応する、バージョン 6.1 で使用可能なすべての属性をリストします。

JMX 管理プログラムはバージョン 5.x および バージョン 6.1 間で相互運用できる

バージョン 6.1 は JMX 1.2 をインプリメントしますが、バージョン 5.x は JMX 1.1 をインプリメントします。JMX 仕様の発展により、 javax.management.ObjectName などの JMX オブジェクトのシリアライゼーション・フォーマットは、 2 つの仕様間で異なります。

バージョン 6.1 JMX ランタイムは、 通信している相手クライアントのバージョンを識別できるように拡張されています。 バージョン 6.0 JMX ランタイムは、これらの非互換性のシリアライズされたフォーマットで適切な変換を行うため、 違うバージョンのランタイムでも相互通信できます。 また、バージョン 5.x 管理クライアントから バージョン 6.1 デプロイメント・マネージャー、 ノード、またはサーバーを呼び出せるようになります。 同様に、バージョン 6.1 管理クライアントからバージョン 5.x ノードまたはサーバーを呼び出すことができます。

バージョン 6.1 の新規 JMX クラスのインスタンスをバージョン 5.x に戻すことはできません。通常は、特定の例外によって問題が通知されます。 また、バージョン 6.1 およびバージョン 5.x 管理プログラムで、 異なる例外が表示されることもあります。

詳細については、Java Management Extensions インターオペラビリティー を参照してください。

より容易でより多くの標準アプリケーション・デプロイメントおよび管理

J2EE アプリケーション内の外部クラス依存関係を指定

インストール済みオプション・パッケージにより、クラス・パスで明示的に指定しなくても、アプリケーションで .jar ファイル内のクラスを使用できるようになります。インストール済みオプション・パッケージは、アプリケーションのマニフェスト・ファイル内で共用ライブラリー .jar ファイルを 1 つ以上宣言します。アプリケーションがサーバーまたはクラスターにインストールされている場合は、共用ライブラリーで表されるクラスがアプリケーションのクラス・ローダーにロードされ、 そのクラスがアプリケーションで使用できるようになります。

インストール済みオプション・パッケージは、アプリケーション・サーバーの既存の共用ライブラリー機能を拡張します。 バージョン 6.1 より前は、 管理者が共用ライブラリーをアプリケーションまたはサーバーに関連付ける必要がありました。 インストール済みオプション・パッケージによって、 管理者はマニフェスト・ファイルにリストされたインストール済みオプション・パッケージのエレメントで、 共用ライブラリーに対するアプリケーションのマニフェスト・ファイルの依存関係を宣言でき、 自動的にアプリケーションと共用ライブラリーを関連付けることができます。 アプリケーション・インストール中に、共用ライブラリー .jar ファイルがアプリケーション・クラス・ローダーのクラス・パスに追加されます。

WebSphere Application Server で使用されるインストール済みオプション・パッケージは Java 2 Platform, Enterprise Edition (J2EE) 仕様、バージョン 1.4 (http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf を参照) のセクション 8.2 に記載されています。

WebSphere Application Server は共用ライブラリー .jar ファイルおよびアプリケーション .ear ファイル内のマニフェスト・ファイル manifest.mf の使用をサポートします。 WebSphere Application Server は、インストール済みオプション・パッケージの Java 2 Platform Standard Edition (J2SE) 仕様をサポートしません。

J2SE 仕様 (http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.html) で使用されるインストール済みオプション・パッケージのセマンティクスは、主にアプレット環境で機能します。 製品は、マニフェスト・ファイル内のアプレット固有のタグを無視します。

インストール済みオプショナル・パッケージ を参照してください。

クラス・ローダー・ビューアーが追加されます クラス・ローダーは、クラス・ファイルを検出し、ロードします。デプロイされたアプリケーションを正常に稼働させるには、アプリケーションおよびそのモジュールに影響するクラス・ローダーは、アプリケーションが必要とするファイルおよびリソースを検索できるよう構成される必要があります。クラス・ローダーでの問題の診断は、複雑で面倒な場合があります。 バージョン 6.0.2 およびそれ以降のバージョンでは、より迅速に問題を診断して修正できるように、 管理コンソール Class Loader Viewer が提供されています。 クラス・ローダーおよびそれぞれのクラス・ローダーによってロードされているクラスを検査するには、Class Loader Viewer を使用します。
[バージョン 6.0.2] 制約事項: クラス・ローダー・ビューアーは、AMD 64 ビット・プラットフォームを含む J9 Java 仮想マシンでは使用できません。

クラス・ローダーのトラブルシューティング を参照してください。

単純化された EAR ファイル構成

以前は、ユーザーはアプリケーションのデプロイと、必要な構成のセットアップを 2 つの異なるステップで実行していました。 このリリースでは、付属の Application Server Toolkit (AST) により、データ・ソースなどの必要な構成をアプリケーションの一部として定義できます。 デプロイメント時に、組み込まれた構成データを処理するように選択して、アプリケーションに必要な構成を自動的にセットアップすることができます。

アプリケーションのアセンブル を参照してください。

コンソール・ウィザードによる、デプロイ済みアプリケーションおよびモジュールの更新の単純化
バージョン 6.1 には、 デプロイされたアプリケーションまたはモジュールを次の方法で更新できる管理コンソール・ウィザードが導入されています。
  • アプリケーション全体を置換します (.ear ファイル)。
  • 単一モジュールを置換、追加、または除去します (.war、EJB .jar、またはコネクター .rar ファイル)。
  • 単一ファイルを置換、追加、または除去します。
  • 圧縮ファイルをアップロードして、複数のファイルを置換、追加、および/または除去します。

アプリケーションが実行中に更新されると、WebSphere Application Server は自動的にアプリケーションを停止するか、または関連するコンポーネントのみを必要に応じてを停止し、 アプリケーション・ロジックを更新して、停止されたアプリケーションまたはそのコンポーネントを再始動します。

前のバージョンの WebSphere Application Server はアプリケーション全体の置換のみをサポートし、どんな変更を行う場合でも常にアプリケーション全体を停止して、再始動していました。

J2EE アプリケーションの更新 アプリケーション更新の準備設定 アプリケーション・ファイルの更新方法 、 およびAdminApp オブジェクトのコマンド を参照してください。

クラスターにデプロイされたアプリケーションに対する容易な更新

新規アクションの Rollout Update は、クラスターを介して複数のクラスター・メンバーにインストールされたアプリケーションを順番に更新します。 アプリケーションのファイルまたは構成の更新後、管理コンソールのエンタープライズ・アプリケーション・ページのロールアウト更新オプションを使用し、アプリケーションがインストールされているクラスターのすべてのクラスター・メンバーにアプリケーションの更新済みファイルまたは構成をインストールします。

Rollout Update により、各クラスター・メンバーに対し、 順々に次の操作が実行されます。
  • 更新済みのアプリケーション構成を保管します。
  • 指定されたノードのすべてのクラスター・メンバーを停止します。
  • 構成を同期化することによって、ノードでアプリケーションを更新します
  • このノード上の停止されたクラスター・メンバーを再始動します。
アプリケーションが複数のノードにわたって広がる 1 つ以上のクラスター上にデプロイされる場合は、 「更新のロールアウト」を使用します。 このアクションにより、単一のクラスター・メンバーが要求を処理できない時間間隔が可能な限り短くなります。処理中の IIOP トランザクションは、クラスター・メンバーが停止する前に完了します。やり取りされている途中の HTTP トランザクションおよび JMS トランザクションは、クラスター・メンバーの停止中に失われます。 クラスターのないアプリケーション・サーバーの場合、代わりに「更新」を使用してから、ノードの保管と同期を行います。 スタンドアロンのアプリケーション・サーバーの場合、単純に更新および保管します。

エンタープライズ・アプリケーション・コレクション およびJ2EE アプリケーションの更新 を参照してください。

JSR-88 デプロイメントのサポート

J2EE Deployment API Specification (JSR-88) を使用して、WebSphere Application Server が提供するアプリケーション・サーバー上に J2EE モジュールをインストールできます。JSR-88 では標準 API が定義されており、 これによって J2EE 製品プラットフォームへの J2EE アプリケーションおよびスタンドアロンのモジュールのデプロイメントが可能になります。WebSphere Application Server は、JSR-88 API をインプリメントする J2EE 1.4 仕様に準拠するプラットフォームです。

JSR-88 は、ツール・プロバイダーとプラットフォームの間の規約を定義します。 JSR-88 により、複数のベンダーのツールを使用して、任意の J2EE 製品プラットフォーム上で アプリケーションを構成、デプロイ、および管理できるようにします。ツール・プロバイダーは通常 、J2EE アプリケーション・モジュールの開発およびアセンブリー用に ソフトウェア・ツールおよび統合開発環境を提供します。J2EE プラットフォームは、J2EE アプリケーションをデプロイ、アンデプロイ、開始、停止、または管理するためのアプリケーション管理機能を提供します。

アプリケーションの管理に使用する JSR-88 および API については、http://java.sun.com/j2ee/tools/deployment/ をご覧ください。J2EE Deployment Specification バージョン 1.1 は、http://java.sun.com/j2ee/tools/deployment/reference/docs/index.html から、J2EE 1.4 Application Server Developer Release の一部として入手可能です。

JSR-88 を使用した J2EE モジュールのインストール DConfigBeans を使用したモジュールのカスタマイズ 、および アプリケーション・ファイルの更新方法 も参照してください。

システム・アプリケーション

システム・アプリケーションは、管理コンソールやファイル転送アプリケーションなど、WebSphere Application Server 製品の中心となる J2EE エンタープライズ・アプリケーションです。 システム・アプリケーションはコンソール・エンタープライズ・アプリケーション・ページのインストール済みアプリケーションのリストには表示されません。これは、ユーザーが誤ってシステム・アプリケーションを停止、更新、または除去しないようにするためです。

システム・アプリケーションは WebSphere Application Server 製品にとって重要な部分なので、製品をインストールするときにデプロイされ、製品フィックスまたはアップグレードを実行した場合のみ更新されます。 ユーザーは、J2EE バインディングまたは J2EE 拡張子など、システム・アプリケーションのメタデータを変更することはできません。 変更を必要とするメタデータは、製品フィックスまたはアップグレードによって更新される必要があります。

詳しくは、システム・アプリケーション を参照してください。

混合環境へのデプロイメント

5.x ノードにインストールされたアプリケーションは、6.0.x ノードにインストール可能

バージョン 5.x 互換アプリケーション (バージョン 5.x システムにインストール可能なアプリケーション) は、任意のサーバーまたはクラスターにインストールできます。 インストールを開始するクライアントは、バージョン 5.x の環境、または バージョン 6.1 の環境の、いずれかのクライアントです。

インストール可能な J2EE モジュールのバージョン を参照してください。

新規 6.0.x 機能を使用するアプリケーションは、5.x ノードではサポートされない

バージョン 6.1 アプリケーションは、バージョン 6.1 サーバー、または バージョン 6.1 サーバーのみを含むクラスターにのみインストールできます。 インストールは、バージョン 6.1 システム内で起動された wsadmin クライアントなど、バージョン 6.1 環境内から開始する必要があります。

バージョン 6.1 アプリケーションは、特定の基準 (インストール可能な J2EE モジュールのバージョン を参照) に準拠するアプリケーションです。

6.0.x 管理を使用して、5.x および 6.0.x アプリケーションを変更可能

すべてのアプリケーションは、モジュールの再インストール、編集、または新規ターゲットへの再マップを通して更新できます。 モジュールの再マップ時に、バージョン 6.1 モジュールの新規ターゲットが、 バージョン 5.x ターゲットではない場合があります。 バージョン 6.1 クライアントからアプリケーションを編集する場合は、 すべての編集機能は、すべてのアプリケーションのバージョンで使用できます。

バージョン 5.x クライアントから バージョン 6.1 アプリケーションを編集する場合は、バージョン 6.1 ランタイムによって排他的に提供される機能は使用できません。 追加された拡張機能は、以下のとおりです。
  • メッセージの宛先参照の Enterprise Bean へのマップ
  • J2CObjects の JNDI 名へのバインディング
  • J2CActivation の宛先 JNDI 名へのバインディング

改良されたリソース管理

デフォルトのメッセージング・プロバイダー

デフォルトのメッセージング・プロバイダーは WebSphere Application Server の一部としてインストールおよび実行されるため、さらなる管理は不要です。

デフォルトのメッセージング・プロバイダーは WebSphere Application Server の一部としてインストールおよび実行され、サービス統合テクノロジーに基づいています。デフォルトのメッセージング・プロバイダーは JMS 1.1 のドメインに依存しないインターフェース (場合によっては「統合」または「共通」インターフェースともいう) をサポートします。 これにより、アプリケーションで point-to-point およびパブリッシュ/サブスクライブ・メッセージング両方に対して、 同一の一般的なインターフェースを使用することができます。また、同じトランザクション内で Point-to-Point とパブリッシュ/サブスクライブの両方のメッセージングを使用可能にします。JMS 1.1 を使用する場合は、新規アプリケーションにこの方法を使用することを推奨します。 ドメイン固有のキュー・インターフェースを使用するように開発されたアプリケーションとの後方互換性のために、 ドメイン固有のインターフェースがサポートされています (JMS 1.1 仕様のセクション 1.5 を参照)。

詳しくは、インフォメーション・センターで以下を検索してください。
デフォルトのメッセージング・プロバイダーの使用
5.x および 6.0.x ノードでは、ほとんどのリソース・プロバイダーを使用できます。
次の J2EE リソースをアプリケーションで使用する場合、 バージョン 5.x および 6.0 ノードを含むすべての有効範囲で、すべての機能を使用できます。
  • JDBC プロバイダー
  • 汎用 JMS プロバイダー
  • WebSphere 組み込みの JMS プロバイダー
  • WebSphere MQ JMS プロバイダー
  • メール・プロバイダー
  • リソース環境プロバイダー
  • URL プロバイダー

汎用 JMS プロバイダーはセルの有効範囲で使用でき、 後方互換性を保つために 6.0 ノードで使用できます。6.0 ノードでは、WebSphere のデフォルト・メッセージング・プロバイダーを使用することが推奨されています。

次の J2EE リソースは、バージョン 5.0.x ノードでは幾つかの制限があります。
  • リソース・アダプター

    リソース・アダプター構成のフォーマットは、J2EE 1.4 の JCA 1.5 に対応するように、大幅に変更されています。JCA 1.5 と JCA 1.0 の両方のリソース・アダプターをセル有効範囲で定義できます。ただし、バージョン 5.x ノードでは JCA 1.5 アダプターを使用できません。6.0 ノードおよびサーバーの場合、JCA 1.5 と JCA 1.0 の両方のリソースを定義できます。 バージョン 5.x ノードおよびサーバーの場合、JCA 1.0 リソース・アダプターのみを定義できます。

  • WebSphere のデフォルト・メッセージ・プロバイダー

    WebSphere のデフォルト・メッセージ・プロバイダーは 6.0 の新機能です。この定義は 6.0.x および 5.x ノードを含むセル有効範囲で作成できますが、バージョン 5.x ノードでは使用できなくなる予定です。 定義は任意の 6.0 ノードまたはサーバーに作成できますが、バージョン 5.x ノードまたはサーバーには作成できません。

SOAP コネクターは 5.x および 6.0.x ノード間で相互運用できるが、RMI コネクターは相互運用できない

クロス・リリース・コネクターの相互運用は現在、SOAP コネクターでのみサポートされています。RMI コネクターでは、サポートされていません。バージョン 5.x wsadmin クライアントでは、6.0 デプロイメント・マネージャーに接続する場合、SOAP コネクターのみを使用できます。6.0 wsadmin クライアントでは、 バージョン 5.x ノード・エージェントまたはアプリケーション・サーバーに接続する場合、SOAP コネクターのみを使用できます。

拡張管理インフラストラクチャー

Java Management Extensions (JMX 1.2)

マイグレーションについて詳しくは、Java Management Extensions V1.0 の Java Management Extensions V1.2 への マイグレーション を参照してください。

J2EE Management Specification (JSR 77)

Java Management Extensions (JMX) アーキテクチャーの管理レイヤーは、分散サービス仕様 (JSR-077) のインプリメンテーションを使用します。 これはまだ Java 2 Platform, Enterprise Edition (J2EE) 仕様の一部ではありません。管理レイヤーは、外部管理アプリケーションが、プロトコル、API などにおいて、下のレイヤーと対話する方法を定義します。 詳しくは、Java Management Extensions (JMX) を参照してください。

J2EE Deployment (JSR 88)

J2EE Deployment API Specification (JSR-88) を使用して、WebSphere Application Server が提供するアプリケーション・サーバー上に J2EE モジュールをインストールできます。JSR-88 では標準 API が定義されており、 これによって J2EE 製品プラットフォームへの J2EE アプリケーションおよびスタンドアロンのモジュールのデプロイメントが可能になります。WebSphere Application Server は、JSR-88 API をインプリメントする J2EE 1.4 仕様に準拠するプラットフォームです。

JSR-88 は、ツール・プロバイダーとプラットフォームの間の規約を定義します。 JSR-88 により、複数のベンダーのツールを使用して、任意の J2EE 製品プラットフォーム上で アプリケーションを構成、デプロイ、および管理できるようにします。ツール・プロバイダーは通常 、J2EE アプリケーション・モジュールの開発およびアセンブリー用に ソフトウェア・ツールおよび統合開発環境を提供します。J2EE プラットフォームは、J2EE アプリケーションをデプロイ、アンデプロイ、開始、停止、または管理するためのアプリケーション管理機能を提供します。

アプリケーションの管理に使用する JSR-88 および API については、http://java.sun.com/j2ee/tools/deployment/ をご覧ください。J2EE Deployment Specification バージョン 1.1 は、http://java.sun.com/j2ee/tools/deployment/reference/docs/index.html から、J2EE 1.4 Application Server Developer Release の一部として入手可能です。

JSR-88 を使用した J2EE モジュールのインストール DConfigBeans を使用したモジュールのカスタマイズ 、および アプリケーション・ファイルの更新方法 も参照してください。

J2EE コネクター・アーキテクチャー (JCA 1.5)

バージョン 6.1 は、インバウンド・リソース・アダプターなどの新機能を提供する J2EE コネクター・アーキテクチャー (JCA) バージョン 1.5 仕様をサポートしています。

詳しくは、リソース・アダプター を参照してください。

組み込みメッセージングの改良された統合

組み込みメッセージングおよびその他のメッセージング・オプションについて詳しくは、WebSphere Application Server によるメッセージングの学習 を参照してください。

改良された管理クライアント

管理コマンド・セットの拡張

wsadmin の AdminTask スクリプト・オブジェクトにより、 管理タスクの自動化が容易になっています。 管理関連タスクの多くは、この新規機能を使用してインプリメントされています。この機能は、対話式実行をサポートし、多くの個別のスクリプト・コマンドを単一のタスク指向コマンドと結合します。

さまざまな AdminTask コマンドが、サーバー管理、クラスター管理、リソース管理などの重要な管理シナリオ用にインプリメントされています。 AdminTask コマンドは、わかりやすい、タスク指向のさまざまな wsadmin コマンドを提供します。 AdminTask コマンドは、コンソールのウィザードと同様に、幾つかの複雑な管理タスクを複数のステップで実行することができます。 AdminTask コマンドは機能領域に基づいてグループ化されます。

詳しくは、AdminTask オブジェクトのコマンド を参照してください。

管理コマンドの改良されたヘルプ

AdminTask コマンドおよびコマンド・グループの詳細なヘルプ情報は、各種 AdminTask ヘルプ・コマンドを使用して入手できます。 すべての AdminTask コマンドは対話式モードで実行できるため、ユーザーは対話式の段階的な操作が可能です。 実行が終了すると、対応する AdminTask コマンドが生成され、AdminTask コマンド構文を学習することができます。

変更された管理コンソール・ポート番号
管理コンソール・ポート番号が変更されています。
http://hostname:9090/admin                    // 古いアドレス
http://hostname:9060/ibm/console              // 新規アドレス

管理コンソールの使用 を参照してください。

改良されたインストールおよび構成

管理者はコマンドを特定のプロファイルに対応させる必要がある

単一マシンで稼働する複数のアプリケーション・サーバー・インスタンスのシステム管理者は、次の変更点に注意する必要があります。 システム管理コマンドはプロファイル固有になりました。 前のリリースでは、コマンドは製品インストール・ルートの bin ディレクトリーから実行されました。 現在、コマンドは特定の プロファイル/bin ディレクトリーから実行する必要があります。 例えば、始動するアプリケーション・サーバーを識別するには、-profileName パラメーターを使用する必要があります。

プロファイルに対応する各種方法については、デプロイメント・マネージャー・プロファイルの作成 を参照してください。

プロファイルはエクスポートできる

プロファイル間で構成を伝搬するには、プロファイルを構成アーカイブにエクスポートして、それを別のプロファイルにインポートします。このメカニズムは、同じインストール・システムのプロファイル間、または異なるインストール・システムのプロファイル間で機能します。 ただし、このメカニズムには、未統合のプロファイルに対してのみ機能するという制限があります。

詳しくは、サーバー構成ファイルの使用 を参照してください。

プロファイルの個別アップグレード

同じシステム・ファイルを共用するプロファイルは、 個別にアップグレード (またはロールバック) できます。 バージョン 6.1 バイナリー・イメージは別の位置にインストールされるため、 各バージョン 5 プロファイルは個別にアップグレードすることができます。

ディレクトリー構造の変更

特定のアプリケーション・サーバー・ランタイム環境に関連するファイルは、ワード profiles および特定のプロファイル名を含むディレクトリー・パス内にあります。

製品インストール・ルートが IBM を含むように変更されていることにも注意してください (インストーラーの新機能 を参照)。

モニターおよびパフォーマンス調整の改良

アプリケーションおよびサーバーの開始速度の改良

2 つの新規設定により、サーバー始動時に自動的に開始するように構成されたアプリケーションの開始速度を微調整できます。 新規の開始ウェイト 設定を使用すると、サーバー始動時にアプリケーションを開始する順番を指定できます。 新規のバックグラウンド・アプリケーション 設定を使用すると、サーバーの始動前にアプリケーションを完全に初期化する必要があるかどうか、またはアプリケーションを待機しないでサーバーが処理を継続できるかどうかを指定できます。

詳しくは、J2EE アプリケーションの構成 を参照してください。

アプリケーション・フローのモニターの改良

要求メトリックを使用すると、WebSphere Application Server を通して各トランザクションの応答時間をトレースできます。 これにより、非同期 Bean、Web サービス、メッセージング・リソースなど、さらに多数の計測が可能になります (要求メトリックのパフォーマンス・データ を参照)。

使用可能にする計測をより詳細に選択することができます。 例えば、Web コンテナーおよび JMS の計測データのみが必要な場合は、管理コンソールでこれらのデータを選択し、選択したコンポーネントに関する詳細な計測データのみを生成します。 エッジ・トランザクションは、インスツルメンテーションを指定されていないその他のコンポーネントのために、トレースされます。 追加情報については、要求メトリックで収集できるデータ を 参照してください。

フィルターを使用して、データを記録するトランザクションを決定することができます。 現在、要求メトリックには Web サービスおよびメッセージ・リソース用のフィルターが含まれています (要求メトリックで収集できるデータ を参照)。

要求メトリックは現在 IPv6 アドレッシングをサポートしています。 IPv6 専用アドレスを持つクライアントから要求が送信された場合、 フィルタリングは IPv6 アドレスに基づいて実行されます。 さらに、サーバーが IPV6 アドレスを優先的に使用する場合は、要求メトリックによって生成された相関関係子でも同じようになります。

PMI の改良

WebSphere Application Server 全体の正常性のモニターを可能にする Performance Monitoring Infrastructure (PMI) が、現在すぐに使用できる状態になっています。これらのモニター API は、J2EE 1.4 Performance Data Framework の仕様に従います。統計は定義済みの統計セットを使用して使用可能にしたり、カスタム・オプションを使用して選択することができます。 カスタム・オプションを使用すると、統計を個別に使用可能および使用不可にすることができます。 メッセージングなどの新規の追加 PMI 統計が用意されています。PMI カスタム API を使用して、独自の統計を追加することもできます。

Performance Monitoring Infrastructure (PMI) を参照してください。

システム正常性に関するデータへのアクセスの簡易化

Tivoli Performance Viewer を使用すると、PMI データをグラフィカルに、かつ図表を使用して表示できます。 このツールが管理コンソールに統合され、モニター・ソリューションが容易に、アクセスしやすく、かつ軽量になりました。

Tivoli Performance Viewer (TPV) を使用したパフォーマンスのモニター を参照してください。

HTTP、エッジ、およびアプリケーション・サービス提供機能

Single Point of Failure を除去するための HA マネージャー

Single Point of Failure を除去するには、新規の HA マネージャー機能を使用します。 HA マネージャーは、専用サーバーでなく、使用可能なアプリケーション・サーバー上で主要サービスを実行します。 このマネージャーは、NAS などのフォールト・トレラント・ストレージ・テクノロジーを利用して、高可用性構成のコストおよび複雑さを大幅に削減します。 また、重要なサービスに対するホット・スタンバイおよびピア・フェイルオーバーも提供します。

HA マネージャーは、アプリケーション・サーバー環境をモニターし、コア・グループに含まれる アプリケーション・サーバー・コンポーネントのピアツーピア・フェイルオーバーを提供します。 アプリケーション・サーバー・コンポーネントに障害が発生すると、HA マネージャーは障害のあるサーバーで実行中の不確実な作業を引き継ぎます。 このアクションにより、アプリケーション・サーバーのアップタイムは大幅に向上します。 慎重に計画された環境では、アプリケーション・サーバーの可用性の予測値が 99.999% に達することがあります。

HA マネージャーで管理される環境のすべてのコンポーネントは、コア・グループのメンバーです。 バージョン 6.1 には、製品のインストール時に作成されるデフォルトのコア・グループがあります。 新規サーバー・インスタンスが作成されると、これらのインスタンスがこのデフォルト・コア・グループに自動的に追加されます。 別のコア・グループを作成することもできます。 ただし、ほとんどの環境では、通常、1 つのコア・グループで十分間に合います。具体的な理由がないかぎり、別のコア・グループを追加しないでください。 環境内にコア・グループが複数存在する場合は、アクセス・ポイント・グループを使用して、コア・グループ間の相互通信を許可します。 通信するコア・グループは、同じセルにある場合も、別のセルにある場合もあります。

すべてのコンポーネントに共通のネットワーク・サービス

新規チャネル・フレームワーク・モデルには、IBM サービス統合テクノロジー、WebSphere Secure Caching Proxy、HA マネージャー・コア・グループ・ブリッジ・サービスなど、 すべてのコンポーネントに共通のネットワーキング・サービスが組み込まれています。 このモデルは、アプリケーション・サーバー環境内での入出力操作に使用するネットワーク・プロトコル・スタックまたはトランスポート・チェーンで構成されます。 トランスポート・チェーンは、1 つ以上のタイプのチャネルで構成されていて、 そのそれぞれが異なるタイプの I/O プロトコル (TCP、DCS、または HTTP など) をサポートしています。 ネットワーク・ポートは、チェーン内のすべてのチャネルで共用できます。 チャネル・フレームワーク機能は、そのポートに着信する要求を、 処理のために適切な I/O プロトコル・チャネルに自動的に配分します。

コア・グループ・トランスポート を参照してください。

複製構成の単純化

新規の高可用性フレームワークに基づく、新規タイプの複製ドメインがあります。 データ複製ドメインを使用すると、ローカル、リモート、および代替のレプリケーターを構成する必要がなくなります。 前バージョンの WebSphere Application Server で作成された複製ドメインは、すべてマルチブローカー・ドメインです。 既存のマルチブローカー・ドメインは引き続き機能しますが、デプロイメント・マネージャーをアップグレードしたあとに、管理コンソールにデータ複製ドメインのみを作成することができます。 パフォーマンスを改良し、構成を容易にするには、既存のマルチブローカー・ドメインをすべて新規のデータ複製ドメインにマイグレーションしてください。

詳しくは、マルチブローカー複製ドメインからデータ複製ドメインへのサーバーのマイグレーション を参照してください。

サーバー・クラスターの管理境界の定義

製品には、サーバー・クラスターを形成する場合の境界を定義するオプション機能 (ノード・グループと呼ばれる) が統合されています。 ノード・グループを使用すると、リソース、およびこれらのリソースを使用するアプリケーションを、セル内の異なる区画にまとめることができます。 アプリケーション・インストール・プロセス中に、オプションのリソース・スコープ検証を使用可能にして、アクセス不可能な Java 2 Platform, Enterprise Edition (J2EE) リソースがアプリケーションに割り当てられているかどうかが通知されるようにします。

詳しくは、ノード・グループ を参照してください。

作成を容易にするための新規サーバー・テンプレート

このリリースでは、サーバー管理機能が大幅に拡張されています。 このリリースには、サーバー・テンプレート機能が導入されています。カスタマーは、既存のサーバー構成に基づいてカスタマイズされたサーバー・テンプレートを作成し、これらを使用して新規サーバーを作成することができます。 これにより、カスタマーは、同じセル内でサーバー構成を容易に伝播させることができます。 さらに、カスタマーはサーバー構成を構成アーカイブにエクスポートしてから、別のセルにアーカイブをインポートすることにより、セル境界を越えてサーバー構成を伝播することができます。

詳細については、サーバー・テンプレートの作成 を参照してください。

2 つの新規サーバー・タイプは、Generic Server および Web Server です。汎用サーバーは、 汎用 Java または Java 以外のサーバー・プロセスを指しますが、Web サーバーは、IBM または IBM 以外の Web サーバーを指します。

アプリケーション・サーバー・コンソールからの Web サーバーの管理

Web サーバー・モデルの定義を使用すると、Web サーバー構成を管理コンソールから管理できます。

管理コンソールからの Web サーバー・プラグインの構成

サポートされる Web サーバーからアプリケーション・サーバーに HTTP 要求を転送するのに使用される Web サーバー・プラグインは、 現在は管理コンソールから構成できます。 以前は、構成の変更が必要な場合、これらのプラグインの構成ファイルを手動で編集する必要がありました。




関連概念
このリリースの新機能
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:13:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc_newadministrator.html