リリース ノート
|
 |
 |
|
BEA WebLogic Server 9.0 へようこそ。WebLogic Server® 9.0 は、これまでにリリースされた中で最も重要な BEA のアプリケーション サーバです。このリリースは、J2EE 1.4 に完全に準拠しており、高い信頼性、継続的な稼動、スケーラビリティ、ミッションクリティカルな統合ソリューションを実現する一方で、管理・運用にかかる全体的なコストを削減するという、今日のエンタープライズ ネットワークが直面する大きな課題に正面から取り組んでいます。
現在確認されている問題と、以前に確認されて現在は解決された問題の詳細については、「WebLogic Server に関する確認済みおよび解決済みの問題」を参照してください。
以下の節では、WebLogic Server 9.0 の新機能と変更点について説明します。
WebLogic Server 9.0 は、J2EE 1.4 仕様に完全に準拠しています。このリリースでは、最新の J2EE 標準 (エンタープライズ Web サービス 1.1、JMS 1.1、JMX 1.2、JDBC 3.0、コネクタ アーキテクチャ 1.5、EJB 2.1 など) を実装および拡張して、エンタープライズ全体に比類のないサービスの質を提供します。以下の節では、主な分野での新機能をまとめています。
WebLogic Server 9.0 では、稼動中のプロダクション環境の中断を最小限にとどめながら、プロダクション システムの日常の管理を簡素化・合理化することに重点を置いています。包括的で一元的な診断サービスによって、管理者はリアルタイムに問題を特定して解決することができます。また、このサービスにサードパーティの分析ツールを統合することもできます。このリリースの WebLogic Server では、Administration Console が従来よりも拡張されて「ポータル化」されています。加えて、使用するコンフィグレーション ツールに関係なく、ドメイン コンフィグレーションの変更を管理できるように、緊密に制御された予測可能なプロセスが導入されています。新しいスクリプト ツール、簡素化されたドメイン ディレクトリ構造、モジュール形式のデプロイメント機能は、アプリケーションのコンフィグレーションとデプロイメントを自動化し、容易にするものです。
「システム管理」を参照してください。
WAN および MAN のフェイルオーバをサポートしており、データ センタの突発的な障害に対応します。WebLogic Server 9.0 では、サーバの移行やサービスの配信の自動化、ポリシー駆動型の処理、自動チューニング機能、過負荷保護機能の拡張、クラスタ間のフェイルオーバなどによって、サーバの全体的なパフォーマンスが大幅に向上しています。
「サーバの信頼性、可用性、スケーラビリティ、およびパフォーマンス」を参照してください。
Web サービスの新しい J2EE 標準では、共通の実行時環境、Java 注釈の業界標準のサポート、Web サービスの拡張機能が提供されており、開発者の柔軟性や選択肢が広がっています。Web サービス 1.1 の WebLogic Server 実装では、会話型アプリケーションでの非同期メッセージングのサポート、エンタープライズ SOA (サービス指向アーキテクチャ) 向けに設計された相互運用性機能、XML 処理の改良によって、開発者がビジネス要件の変化により効果的に対応できるようになっています。開発者は WebLogic Web サービスを活用することで、セキュアで完全に相互運用可能なエンタープライズ Web サービスを迅速に作成してデプロイし、適応させることができます。
「J2EE 標準の Web サービス」を参照してください。
WebLogic Server 9.0 は、ドメイン間の通信、エンタープライズ情報システムからの双方向のトランザクション、高可用性を目的とした送り先の自動移行、信頼性向上のためのメッセージのストア アンド フォワード、メッセージ配信順序の厳密な制御などを実装しています。また、このリリースでは、エンタープライズ アプリケーションやメッセージを大量に扱うアプリケーションの管理とパフォーマンスを改良しています。
「リソース アダプタ」を参照してください。
以下の節では、WebLogic Server 9.0 の、サーバ全体の管理に影響する新機能、拡張機能、および非推奨になった機能について説明します。
以下の節では、WebLogic Server の中核的な処理に関する主な変更と改良について説明します。
新しいライフ サイクルの状態 ADMIN によって、アプリケーションのデプロイメント、保守、およびトラブルシューティングが行いやすくなりました。ADMIN 状態の場合、WebLogic Server は動作していますが、受け付けるのは管理操作のみとなり、ユーザは、実行中のアプリケーションに影響を与えることなくサーバおよびアプリケーション レベルの管理タスクを実行できます。
『Managing Server Startup and Shutdown』の「Understanding Server Lifecycle」を参照してください。
管理者は、プロパティをワーク コンテキストとして定義すると、リモート呼び出しに明示的に含めずに、それらのプロパティを渡すことができます。ワーク コンテキストは各リモート呼び出しによって伝播されるので、呼び出されたコンポーネントは、ワーク コンテキストで定義されたプロパティを追加したり変更したりできます。同様に、呼び出し側コンポーネントはワーク コンテキストにアクセスして、新しいプロパティや更新されたプロパティを取得できます。
ワーク コンテキストによって、リモート コンポーネントとの通信が必要な、診断モニタリング、アプリケーション トランザクション、およびアプリケーションのロード バランシングが容易になります。また、サードパーティのコンポーネントに情報を提供することもできます。
ワーク コンテキストは、クライアントとサーバのどちらでも使用でき、それぞれ別々に有効にすることができます。
『WebLogic Server アプリケーションの開発』を参照してください。
ネットワーク チャネルでは、外部のネットワーク トラフィックの管理に加えて、サーバ インスタンス間のネットワーク トラフィックを管理できるようになりました。ネットワーク チャネルのコンフィグレーションと制御に関する新機能と改良点は次のとおりです。
『Configuring WebLogic Server Environments』を参照してください。
コンフィグレーション データの格納に関する以下の変更点は、中核的な機能に影響します。
config ディレクトリにある複数のファイル (config.xml を含む) に格納されます。コンフィグレーション ファイルは、ドメイン ディレクトリの下の configArchive ディレクトリに、JAR ファイルとしてアーカイブされます。以上の変更に伴い、推奨されるバックアップの手順が変わりました。『Managing Server Startup and Shutdown』の「Avoiding and Recovering From Server Failure」を参照してください。WebLogic 永続ストアは、永続性を必要とする WebLogic Server のサブシステムとサービス、特に、存続期間の短いデータ オブジェクト (JMS サーバのトランザクション メッセージなど) の作成や削除が必要なサブシステムに向けた、組み込みの高性能なストレージ ソリューションです。ドメインの各サーバ インスタンスには、コンフィグレーションの不要な、複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。サブシステムでは、特定のストアを明示的に選択する必要はなく、システムのデフォルト ストレージを使用できます。サブシステムには、JMS サーバ、Web サービス、EJB タイマー サービス、ストア アンド フォワード サービス、JTA トランザクション ログ (TLOG) などがあります。管理者は、環境に合わせて、専用のファイルベースのストアや、JDBC でアクセス可能なストアをコンフィグレーションすることもできます。
『Configuring WebLogic Server Environments』の「Using The WebLogic Persistent Store」を参照してください。
WebLogic ストア アンド フォワード (SAF) サービスを使用すると、WebLogic Server では、複数の WebLogic Server インスタンスに分散されているアプリケーション間でメッセージを確実に配信することができます。たとえば、SAF サービスを利用すると、ローカルの WebLogic Server 上で動作するアプリケーション、またはローカルの WebLogic Server に接続するアプリケーションは、リモート サーバ上の送り先にメッセージを確実に配信できます。メッセージの送信時に送り先が使用不能になっている場合、メッセージはローカルのサーバ インスタンスに永続的に保存されて、リモートの送り先が使用可能になった時点で転送されます。
WebLogic JMS では、SAF サービスを利用して、ローカルの JMS メッセージ プロデューサが、リモートの JMS キューまたはトピックにメッセージを確実に送信できるようにします。WebLogic Web サービスでは、SAF サービスに加えて、Web Services Reliable Messaging (WSRM) 標準の実装を備えています。
WebLogic ストア アンド フォワード サービスの利点と用法の詳細については、『Configuring and Managing WebLogic Store-and-Forward Service』を参照してください。
config.xml ファイルでは、JDBC リソース名、セキュリティ データ、永続ストア、XML スキーマなどのコンフィグレーション データが、WebLogic Server 9.0 ベータ版から変更されている場合があります。WebLogic Server 9.0 ベータ版を使用していた場合は、その config.xml ファイルを WebLogic Server 9.0 GA で使用できない可能性があります。
WebLogic Server Administration Console は今回のリリースで全面的に再設計されました。Administration Console は WebLogic Portal フレームワークに基づいて構築され、よりオープンで拡張しやすくなりました。その他の新機能は次のとおりです。
以降の 2 つの節では、コンソールの改良点について、さらに詳しく説明します。
WebLogic Server Administration Console はこのリリースで全面的に再設計されました。9.0 より前のリリースの Administration Console では、JSP と独自のフレームワークを使用して、ユーザ インタフェースを表示していました。現在は、JSP、WebLogic Portal フレームワーク、Apache Struts、Apache Beehive、およびその他のオープンな技術を使用しています。
Administration Console は、ポータル アプリケーションを拡張する場合と同じ方法で拡張できるようになりました。ただし、Administration Console は JSR 168 または Web Services for Remote Portlets (WSRP) をサポートしていません。内容の追加や置き換えのほかに、コンソール拡張機能では、ナビゲーション ツリーにノードを追加したり、コンソールの外観 (色やブランドの画像など) を変更したりできます。
新しいアーキテクチャは大きく異なっているため、以前のリリースの WebLogic Server で作成された WebLogic Administration Console の拡張機能は、9.0 では機能しません。以前の Administration Console 拡張機能で作成したコンテンツや JSP のロジックは再利用できる可能性がありますが、BEA では、9.0 より前の拡張機能で提供していた API や JSP タグ ライブラリをサポートしなくなります。さらに、JSP のコンテナとしてポートレットを定義する必要があります。
変更の管理に関する機能が向上したため、Administration Console、新しい WebLogic Scripting Tool、JMX、他の API のどれを使用していても、コンフィグレーションの変更をドメイン全体に、セキュアに、一貫して、予測可能な方法で配布することができます。
変更内容を保護して、他者から変更されないようにするため、Administration Console 内の「チェンジ センタ」という新しい領域では、ドメイン コンフィグレーションの変更を始める前に、Administration Console をロックするように促します。
変更を終えたら、変更内容を保存して、ドメインのすべてのサーバ インスタンスに配布します (または、変更をロールバックして、ロックを解放します)。各サーバは、その変更を適用できるかどうかを判断します。すべてのサーバが変更を適用できる場合は、各サーバが動作中のコンフィグレーション ツリーを更新して、変更が完了します。1 つまたは複数のサーバで変更を適用できない場合、その変更はどのサーバにも適用されないため、不完全で中間的な状態を避けることができます。この機能によって、WebLogic Server のコンフィグレーション情報は常に正確で、一貫性のあるものになります。
変更が、Administration Console、WebLogic Scripting Tool、コンフィグレーション マネージャ サービス、JMX API のどれを使用して行われても、WebLogic Server は同じ方法でコンフィグレーションの変更を制御します。
WebLogic Scripting Tool (WLST) は、WebLogic Server インスタンスとドメインのコンフィグレーション、WebLogic Server コンフィグレーションの変更の管理と永続化に使用する、新しいコマンドライン インタフェースです。
config.xml ファイルに永続化する WLST は Java のスクリプト インタプリタである Jython に基づいており、コマンド プロンプトから一度に 1 つずつ入力される対話形式、または、ファイル (スクリプト) で入力されるか Java コードに埋め込まれるバッチ形式で、コマンドを解釈します。スクリプト ツールは、オンライン (実行中のサーバに接続された状態) でも、オフライン (実行中のサーバに接続されていない状態) でも使用できます。
weblogic.Admin ユーティリティは 9.0 で非推奨になりました。weblogic.Admin ユーティリティと wlconfig ツールは次のように制限されます。
新しい WebLogic 診断サービスは、すべての診断機能を一元的で統一されたフレームワークに統合したものです。このフレームワークでは、診断データを標準的なフォーマットで作成、収集、分析、およびアーカイブできます。診断サービスでは、サーバやアプリケーションの実行時のパフォーマンスを効果的に表示したり制御したりできるので、障害発生時に診断を行い、問題を隔離することができます。
以下の節では、WebLogic 診断サービスの機能について、さらに説明します。
WebLogic 診断サービスでは、メトリック、データ イベント、ロギングおよびデバッグ情報が動的に表示されます。今までは公開されていなかった領域の、サーバに関する新しい診断データも公開します。
以前のリリースの WebLogic Server には、標準のサーバ ログとドメイン ログ、JDBC ログ、アクセス ログなど、独立した複数のロギング機能がありました。それぞれのログは異なる実装に依存していたため、標準のログと同じサービスや機能 (ローテーションなど) があっても、その利点が生かされていませんでした。今回、これらのロギング ソリューションが 1 つの実装に統一されて、すべてのサーバ ロギングで同じサービスの品質が提供されるようになりました。WebLogic ロギング サービスで生成されたすべてのイベントを、収集、分析、アーカイブするように、WebLogic 診断サービスをコンフィグレーションできます。
実行中の環境で、WebLogic Server やユーザが記述したアプリケーションに、診断コードを重点的に追加したり削除したりできます。特定の種類の実行時データ イベントを収集したり分析したりできます。また、状況によっては、サーバの実行中に、特定の場所でアクティブな診断アクションを変更することにより、そこで実行される診断コードの動作を動的に変更できます。
診断コンテキストは、トランザクション イベントを再構築したり、発生の時期や論理的な関係に基づいてイベントを相関させるための手段です。要求から応答までの実行スレッドをつなぎ合わせたり、診断コンテキスト内のコンテキスト情報が一定の条件を満たす場合にのみ診断情報を生成したりできます。この機能は、生成される情報の量やオーバーヘッドを、管理可能なレベルに保つものです。
多くの場合、イベントの収集は、アプリケーション フロー内にキー ポイントを指定し、そのポイントを通過するすべての要求をモニタすることで行われます。しかし、収集量を最小限に抑えたり、イベントを分離したりするために、1 つのリクエスト、または 1 つのクライアントから届くリクエストのイベントのみをキャプチャする方が望ましいこともあります。WebLogic 診断サービスでは、特定のリクエストをモニタすべきかどうかを WebLogic 診断サービスが判断できるように、そのリクエストをマーク (仕分け) することができます。WebLogic 診断サービスは、リクエストがシステムに届いたときに、前述の診断コンテキストでフラグを設定することによって、リクエストをマークします。
サーバ MBean に含まれるメトリックを収集するために、ハーベスタ コンポーネントをコンフィグレーションできます。また、WebLogic 診断サービスを使用すると、ユーザが用意したカスタム MBean からメトリックを収集できるため、独自のアプリケーションからメトリックを収集することも可能です。
WebLogic 診断サービスのサーバ イメージ キャプチャ コンポーネントは、必要に応じて、または自動的に、サーバから診断スナップショットを作成します。コンフィグレーション、ログ キャッシュ、ワーク マネージャ、JNDI 状態、収集可能データなどの、サーバの状態を表す一般的なソースだけでなく、JMS、JDBC、EJB、JNDI、その他のサーバ サブシステムをキャプチャすることもできます。
サーバが短期間に障害の発生と回復を繰り返す場合 (暴風関連の電源障害など)、システム管理者は、イメージのロックアウト期間を指定できます。それによって、サーバが同じような診断イメージを何度もキャプチャして保存し、システム リソースを不必要に消費するのを防ぐことができます。
エンタープライズ内のシステムから発生したイベントをトラップ、ルーティング、および処理するためのソフトウェアを開発してある場合、それらのカスタム アプリケーションのイベントを分析したり、システム管理者に警告する通知を自動的に生成するように、診断サービスをコンフィグレーションできます。この機能によって、より大きな環境にある従来のモニタリング フレームワークとの、緊密な統合が可能になります。
WebLogic Server をモニタするために、監視をコンフィグレーションして、特定の条件を検出したり、ロギングおよびデバッグのログ レコード、データ イベント、収集されたメトリックなどを分析することができます。監視では、Simple Mail Transfer Protocol (SMTP)、Simple Network Management Protocol (SNMP)、Java Management Extensions (JMX)、Java Message Service (JMS) などの、さまざまなタイプの通知リスナをトリガできます。
サーバとその上で動作するアプリケーションから収集されたすべてのデータは、永続的なストレージに保存されます。データ アクセサ コンポーネントを使用すると、データ イベント、ログ レコード、収集されたメトリックなど、WebLogic 診断サービスが収集した現在のデータや履歴データのすべてにアクセスできます。アーカイブされたデータには、オンライン モード (実行中のサーバ) およびオフライン モード (停止後のサーバ) でアクセスできます。
WebLogic 診断サービスは、サードパーティのモニタリングおよび分析ツールに対する、標準的な統合機能を備えています。
WebLogic 診断サービスには、BEA パートナが開発した既存の診断ツールや機能 (インスツルメンテーションなど) との互換性があります。WebLogic 診断サービスを利用すると、パートナは独自のツールを容易に統合できます。その一方で、BEA Systems が統合インタフェースの所有権を持ち、サポートやドキュメントを提供したり、サービスの品質を改良したりします。
WebLogic ロギング サービスには、以下の新しい機能とコンフィグレーション オプションがあります。
LogMBean インタフェースが改良されて、ロガーおよびハンドラに重大度レベルとフィルタを設定することにより、ロギングの出力を制御できるようになりました。
以前のバージョンの WebLogic Server では、システム管理者と開発者は、ロガーとハンドラにプログラム的なアクセスしかできませんでした。このリリースでは、MBean を使用してハンドラをコンフィグレーションできるので、最も基本的なロギング コンフィグレーションのコードを記述する必要はありません。Administration Console と WebLogic Scripting Tool (WLST) では、ロギング MBean とやりとりするためのインタフェースが提供されます。ロガーのコンフィグレーションには API のみを使用できます。
WebLogic Server は Jakarta Project Log4j をサポートしています。Administration Console で、Log4j またはデフォルトの Java ロギング実装を指定します。または、LogMBean インタフェースの LogMBean.isLog4jLoggingEnabled 属性を使用して、Log4j のロギングをコンフィグレーションできます。
Jakarta Commons Logging API は、ユーザを基底のログ実装から分離する抽象レイヤを提供しています。WebLogic Server には Commons LogFactory インタフェースの実装が用意されており、この API を使用してサーバの Logger にリクエストを発行できます。
logs ディレクトリにあります (root-directory\servers\server-name\logs\server-name.log など)。logs ディレクトリにあります。ドメイン ログ ファイルのデフォルトの名前と場所は root-directory\servers\AdminServer-name\logs\domain-name.log です。 LogFileMBean の LogFileRotationDir プロパティを設定します。『Configuring Log Files and Filtering Log Messages』を参照してください。
このリリースの WebLogic Server では、WebLogic 固有のデプロイメント記述子を使用して、Web アプリケーションとリソース アダプタのロギングの動作をコンフィグレーションできます。ロギング コンフィグレーションのデプロイメント記述子要素では、ログ ファイルの名前、場所、ローテーション ポリシーなど、LogFileMBean インタフェースでサーバ のロギングをコンフィグレーションする場合と同じような属性を定義します。
同様に、WebLogic ロギング サービスは J2EE リソース アダプタにも対応しており、ManagedConnectionFactory スコープのロギングを行えます。weblogic-ra.xml デプロイメント記述子を使用して、リソース アダプタ ログのログ ファイル名、場所、ローテーション ポリシーなどをコンフィグレーションします。
『Using WebLogic Logging Services for Application Logging』を参照してください。
WebLogic Server 9.0 では、サーバとクラスタの信頼性、可用性、スケーラビリティ、パフォーマンスが大幅に向上しています。
WebLogic Server では、クラスタに属するサーバ インスタンスとそのサーバがホストするすべてのサービスを、あるマシンから別のマシンに、自動的にまたは手動で移行することができます。この機能は、高可用性を求める環境に向けて設計されています。このサーバ移行機能は、次のような目的で使用します。
『WebLogic Server クラスタ ユーザーズ ガイド』の「Server Migration」を参照してください。
WebLogic Server 9.0 は、BEA と IBM の共同仕様 (CommonJ) の一部をサポートしています ( を参照)。特に、このリリースでは Timer and Work Manager 1.1 仕様 を実装しています (http://dev2dev.bea.com/technologies/commonj/twm/index.jsp を参照)。
Timer API は、アプリケーション サーバ内で管理されるタイマーを、アプリケーションで作成して使用するための、簡単な API を提供しています。この API は、J2SE java.util.Timer クラスの代わりとして推奨されるものです。
Work Manager API を使用すると、アプリケーションは、WebLogic Server でコンフィグレーション済みの複数のワーク マネージャを使用して、1 つのリクエストのタスクを複数の作業項目に分割し、その作業項目を割り当てて、同時に実行することができます (作業項目を同時に実行する必要のないアプリケーションでも、コンフィグレーション済みのワーク マネージャを使用することができます。それには、デプロイメント記述子でワーク マネージャを参照または作成するか、J2EE コネクタの場合は JCA API を使用します)。新しいワーク マネージャのチューニング方式の詳細については、「プロダクション環境でのサーバの自動チューニング」も参照してください。
あるクラスタのサーバ インスタンスで動作している HTTP セッションのステートを、別の WebLogic Server クラスタ内のサーバ インスタンスにレプリケートすることができます。2 つのクラスタは、同じメトロポリタン エリア ネットワーク (MAN) 内の別々の LAN にあっても、ワイド エリア ネットワーク (WAN) 内の地理的に離れた場所 (別々の都市や州) にあっても構いません。プライマリ サーバ インスタンスで障害が発生したら、同じクラスタの別のメンバーは、(別のクラスタにある) リモート インスタンスからセッション データを回復して、プライマリ クラスタでそのデータを使用することができます。プライマリで障害が発生したクラスタ内に使用可能なメンバーがない場合、リクエストは、セッションのレプリカを保持しているリモート クラスタにフェイル オーバされます。
WebLogic Server のクラスタ間セッション レプリケーション機能が役立つ 2 つの環境を以下に例示します。
『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
新しい自動チューニング機能は、時間の経過やアプリケーションごとにサービス レベルの要件が変わるプロダクション環境において、WebLogic Server をコンフィグレーションするプロセスを簡素化します。自動チューニングによって、需要のピーク時におけるデッドロックを防ぐことができます。自動チューニング機能は、WebLogic Server 環境で、さまざまなパフォーマンスや可用性の要件を持つ複数のアプリケーションをホストしている場合にも便利です。たとえば、バックエンドの在庫管理アプリケーションよりも、ユーザに対応する注文処理アプリケーションに、より多くのリソースを割り当てることができます。
新しい方式のキューを利用すると、管理者は、カスタムの実行キューをコンフィグレーション、モニタ、チューニングする際の手間や複雑さを避けて、より効率的に処理リソースを割り当てたり、パフォーマンスを管理したりできます。
WebLogic Server の主な自動チューニング機能は次のとおりです。
『Configuring WebLogic Server Environments』を参照してください。
ノード マネージャは多くの機能が拡張されて、用途が広がり使いやすくなりました。
『Managing Server Startup and Shutdown』の「Using Node Manager to Control Servers」を参照してください。
このリリースでは、クラスタ アドレスを明示的に定義することもできますが、定義しない場合、WebLogic Server はリクエストごとにクラスタ アドレスを動的に生成します。この機能によって、コンフィグレーションの手間が省け、クラスタ アドレスには、起動時のクラスタ メンバシップが正確に反映されます。『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタ アドレス」を参照してください。
新しい過負荷保護機能は、メモリ不足 (OOM) 例外や実行キューの過負荷からサーバ インスタンスを守り、サーバやクラスタの可用性を向上させます。
『Configuring WebLogic Server Environments』を参照してください。
Web サービスは J2EE 標準になったため、8.1 とくらべて 9.0 の WebLogic Web サービスには多くの変更点があります。
WebLogic Server 9.0 には Web サービスの以下の新機能があります。
8.1 と 9.0 との Web サービスの変更点や、非推奨の詳細については、「WebLogic 8.1 と 9.0 の Web サービスの相違点」を参照してください。
J2EE 1.4 では、Web Services for J2EE、バージョン 1.1 (JSR-109 の 1.1 メンテナンス バージョンである JSR-921) や Java API for XML Registries (JAX-R) などの新しい仕様と、更新された JAX-RPC および SAAJ 仕様において、Web サービスを作成するための標準の Java コンポーネント モデルを導入しています。
その結果、WebLogic Web サービスの作成に使用される 9.0 のプログラミング モデルも変更されました。このモデルでは、JDK のバージョン 5.0 で導入された新しいメタデータ注釈機能を利用しています。また、WebLogic Web サービスが動作する実行時環境は、Web Services for J2EE、バージョン 1.1 仕様をサポートしています。
weblogic.webservice.* API を含む、8.1 Web サービス ランタイム全体が非推奨になりました。代わりに、新しいプログラミング モデル (JWS ファイルとそれに付随する Ant タスク) と weblogic.wsee.* パッケージの両方を使用してください。公開されている WebLogic API の詳細なリストについては、Javadoc を参照してください。新しい 9.0 WebLogic Web サービス ランタイムの詳細については、『Programming Web Services for WebLogic Server』を参照してください。
注意 : 8.1 Web サービスのランタイムは 9.0 でもサポートされるため、8.1 WebLogic Web サービスは、変更しないでも WebLogic Server 9.0 上で引き続き実行できます。ただし、8.1 WebLogic Web サービスは非推奨になっており、今後のリリースの製品からは削除される予定です。したがって、8.1 Web サービスを 9.0 にアップグレードすることをお勧めします。「Upgrading an 8.1 Web Service to 9.0」を参照してください。
Medrec サンプル アプリケーションの Web サービスでも、バージョン 8.1 と 9.0 の間で若干の変更点があります。8.1 の Medrec アプリケーションでは weblogic.webservice.tools.wsdlp パッケージの非公開の API を使用していました。9.0 では、このパッケージは weblogic.webservice.wsdl に移動されて非推奨になりました。9.0 Medrec アプリケーションの Web サービスでは、9.0 の Web サービス ランタイムとプログラミング モデルを使用しています。
「Differences Between 8.1 and 9.0 WebLogic Web Services」を参照してください。
9.0 WebLogic Web サービスの作成に使用されるプログラミング モデルは、JDK 5.0 の新しいメタデータ注釈機能に基づいています。このモデルにおいて、Web サービスの実装は、Java Web サービス (JWS) 注釈を使用する Java ファイルになります。この JWS 注釈は、Web Services Metadata for the Java Platform 仕様 (JSR-181) で定義された標準の注釈と WebLogic 固有の注釈を組み合わせたものです。
注意 : JWS 注釈の使用は、WebLogic Web サービスを作成するための好ましいプログラミング モデルですが、Web サービスを手動で作成することもできます。その場合は、Web サービスを実装する EJB または Java クラスをプログラミングし、Web サービス デプロイメント記述子や WSDL ファイルなどの必要なコンポーネントをすべて作成します。
「Programming the JWS File」を参照してください。
Web Services for J2EE、バージョン 1.1 仕様では、Java で Web サービスを実装するための、標準的な J2EE 実行時アーキテクチャを定義しています。
「Anatomy of a WebLogic Web Service」を参照してください。
WebLogic Web サービスは、さまざまな非同期の機能をサポートしています。
WebLogic Web サービスでは、Web サービスを呼び出すときに生成されるリクエストおよび応答の SOAP メッセージの、デジタル署名と暗号化をサポートしています。この機能は、以下の OASIS 標準 1.0 Web Services Security 仕様に従っています。
メッセージ レベルのセキュリティは、WS-Policy 仕様の規定に従って、セキュリティ WS-Policy ステートメントを使用してコンフィグレーションされます。
「セキュリティのコンフィグレーション」を参照してください。
以前のリリースと同様、WebLogic Web サービスは、JAX-RPC 1.1 仕様の規定に従って、組み込みの XML スキーマ、Java、および SOAP のデータ型をサポートしており、追加のプログラミング手順を行わずに、Web サービスのオペレーションでそれらのデータ型を使用することができます。
また、Web サービスの入力パラメータや戻り値として、さまざまなユーザ定義の XML および Java データ型 (XMLBeans など) を使用できます。WebLogic Web サービス Ant タスクでは、ユーザ定義のデータ型を XML 表現と Java 表現の間で変換するのに必要なデータ バインディング コンポーネントを、自動的に生成します。
「Data Types and Data Binding」を参照してください。
WebLogic Web サービス 9.0 は、WS-Policy 仕様を実装しています。この仕様では、Web サービスのポリシーを記述して通信するための、汎用的なモデルと対応する構文が提供されています。このリリースでは、Web サービスの信頼性のあるメッセージング機能と、メッセージ レベルのセキュリティ機能をコンフィグレーションする目的にのみ、ポリシー ファイルを使用します。
セキュリティおよび信頼性のあるメッセージングをコンフィグレーションするための WS-Policy ファイルの使用方法については、それぞれ「Use of WS-Policy File for Message-Level Security Configuration」および「Use of WS-Policy Files for Reliable SOAP Message Configuration」を参照してください。
一連の Ant タスクは、JWS 注釈付きファイルを処理し、それを WebLogic 分割開発ディレクトリ環境に統合します。この開発環境は、ディレクトリ レイアウトと、Web サービスを含む J2EE アプリケーションの反復的なビルド、変更、およびデプロイメントを支援する、関連する Ant タスクで構成されます。
「Web Services Ant Task Reference」を参照してください。
WebLogic Server 9.0 の Web サービスは、さまざまな標準の Web サービス関連の Java 仕様を実装し、各種の Web サービス仕様に準拠しています。詳細なリストについては、「Standards Supported by WebLogic Web Services」を参照してください。
WebLogic Server 9.0 では、WebLogic JMS のコンフィグレーション、デプロイメント、および動的な管理に関して、大きな変更が行われています。
WebLogic JMS に関する、上記およびその他の新機能と変更点の詳細については、『Configuring and Managing WebLogic JMS』の「New and Changed JMS Features In This Release」を参照してください。
WebLogic Server 9.0 は、プロダクションでの使用に対応する新しい JMS 1.1 仕様に準拠しており、キューとトピックの両方に機能する統一された API をサポートしています。Sun Web サイトの Java JMS 技術のページ (http://java.sun.com/products/jms/) を参照してください。
WebLogic Server 9.0 の JMS コンフィグレーションは、標準の J2EE モジュールと同様に、weblogic-jmsmd.xsd スキーマに準拠する XML ファイルによって定義されたモジュールの形で格納されます。管理者は、グローバルなシステム リソースとして、J2EE アプリケーションと共にパッケージ化されるモジュール （パッケージ化されたリソース） として、またはグローバルに使用可能なスタンドアロンのモジュールとして、JMS モジュールを作成および管理できます。詳細については、「JMS および JDBC のデプロイ可能リソースのコンフィグレーション」を参照してください。
JMS リソースのモジュール形式のデプロイメントを利用すると、エンタープライズ アプリケーション ファイル (EAR ファイルなど) や JMS スタンドアロン モジュールを開いたり、JMS の手動による膨大な再コンフィグレーションを行わずに、アプリケーションと必要な JMS コンフィグレーションを、ある環境から別の環境に (たとえば、テスト環境からプロダクション環境に) 移行できます。
『Configuring and Managing WebLogic JMS』の「Understanding JMS Resource Configuration」を参照してください。
JMS ストア アンド フォワード機能は、WebLogic ストア アンド フォワード (SAF) サービス上に構築され、高可用性を備えた JMS メッセージ生成を行います。たとえば、ローカル サーバ インスタンスに接続された JMS メッセージ プロデューサは、メッセージ送信時にリモートの送り先が一時的に利用できない場合でも、リモートの JMS 送り先に確実にメッセージを転送できます。JMS ストア アンド フォワードは JMS アプリケーションからは透過的なので、JMS クライアント コードは既存の JMS API を使用して、リモートの送り先にアクセスできます。
『Configuring and Managing WebLogic Store-and-Forward』の「Understanding the Store-and-Forward Service」を参照してください。
大幅に強化された新しいメッセージ管理機能により、JMS 管理者は、Administration Console または新しいパブリックな実行時 API を使用して、実行中の JMS サーバですべてのメッセージを表示したり、ほとんどのメッセージを操作できるようになりました。このメッセージ管理機能には、トランザクション管理、恒久サブスクライバの管理、JMS クライアント接続の管理に加えて、メッセージの表示 (ソート用)、メッセージの操作 (移動や削除など)、メッセージのインポートとエクスポートなどがあります。
『Configuring and Managing WebLogic JMS』の「Monitoring JMS Statistics and Managing Messages」を参照してください。
新しい WebLogic JMS のコンフィグレーションおよび実行時 API を使用すると、管理者は、特定の JMS 送り先や 1 つのJMS サーバでホストされているすべての送り先において、メッセージの生成、挿入 (処理中のメッセージ)、消費などの処理を、プログラム上または管理上の理由で休止して再開することができます。この機能を利用すると、外部リソースに障害が発生した場合に、JMS サブシステムの動作を制御できます。
『Configuring and Managing WebLogic JMS』の「Troubleshooting WebLogic JMS」を参照してください。
メッセージのライフ サイクルとは、JMS メッセージが JMS サーバに届いた後、JMS API または JMS メッセージ管理 API を通じて、そのメッセージに順に発生する基本的なイベントを外側から見た概念です。したがって、メッセージ ライフ サイクルのロギングを利用すると、管理者は JMSサーバから、メッセージの生成、消費、削除などの基本的なライフ サイクル イベントによって、JMS メッセージの存在をより正確に把握することができます。
『Configuring and Managing WebLogic JMS』の「Troubleshooting WebLogic JMS」を参照してください。
JMS サブシステムは、デバッグ アクセスとロギングが一元化された、新しいシステム全体の WebLogic 診断サービスを使用しています。デバッグ情報と診断情報を利用しやすくなったので、問題の診断と修正が容易になりました。
メッセージの順序単位機能は、JMS メッセージ プロデューサに、順序付けされたメッセージを 1 つの単位にグループ化する機能を与えることで、JMS 1.1 仕様におけるメッセージ配信の順序付けに関する要件を超えたものになっています。この 1 つの単位は「順序単位」と呼ばれ、その単位から作成されたすべてのメッセージは、コンシューマが確認応答するか、その単位が閉じられるまで、同じコンシューマによって順番に処理されることが保証されています。たとえば、キュー内に多数のコンシューマが関わる複数のメッセージがあって、各メッセージが順序単位としてアカウント番号を持っている場合、2 つのコンシューマが同じアカウント番号を持つメッセージを同時に処理することはありません。
『WebLogic JMS プログラマーズ ガイド』の「Using Message Unit-of-Order」を参照してください。
新しいタイプの分散送り先である「共通分散送り先」によって、分散送り先アプリケーションの管理とデプロイメントが非常に簡単になりました。この機能を使用すると、管理者は送り先のメンバーを作成したり指定したりする必要がなくなります。代わりにシステムによって、JMS モジュールが割り当てられる JMS サーバ上に、必要なメンバーが均等に作成されます。この機能によって、すべての分散送り先のパラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) を一貫してコンフィグレーションできます。
『Configuring and Managing WebLogic JMS』の「Configuring Cluster WebLogic JMS Resources」を参照してください。
WebLogic JMS C API を使用すると、「C」で記述されたプログラムを JMS アプリケーションに参加させることができます。この JMS C API の実装では、Java 仮想マシン (JVM) へのアクセスに JNI を使用しています。
『WebLogic JMS プログラマーズ ガイド』の「WebLogic C API 」を参照してください。
MDB の機能が拡張されて、トランザクションによるバッチ処理 (1 つのトランザクションで複数のメッセージを処理する) がサポートされています。また、MDB と送り先が同じクラスタにあるか、別々のクラスタ/ドメインにあるかに関係なく、異なるクラスタまたはドメインのメンバー送り先にわたる分散送り先のロード バランシングが可能です。
「メッセージ駆動型 Bean の機能拡張」を参照してください。
WebLogic JMS API が拡張されて、XML メッセージの送信におけるドキュメント オブジェクト モデル (DOM) のネイティブ サポートが提供されています。この機能によって、既にDOM を使用しているアプリケーションでは、XML メッセージを送信する前に DOM を平坦化する必要がなくなるので、パフォーマンスが向上します。
『WebLogic JMS プログラマーズ ガイド』の「Sending XML Messages」を参照してください。
WebLogic Server 9.0 では JMS サブシステムでさまざまな変更が行われており、一部のクラスが削除されて、多数の MBean が非推奨になりました。非推奨になった JMS API の詳細については、『Configuring and Managing WebLogic JMS』の「New and Changed JMS Features In This Release」を参照してください。
JMS リソースをコンフィグレーションするための新しい記述子ベースのメソッドでは、Java 記述子 Bean インタフェースを使用して、デプロイ可能な JMS リソース モジュールを作成します。この基本的な変更に伴い、ほとんどの JMS コンフィグレーション MBean インタフェースは、JMSServerMBean インタフェースを除いて、非推奨になりました。
JMS モジュール リソースをコンフィグレーションするための記述子ベースのメソッドが導入されたのに伴い、JMS の実行時およびコンフィグレーション JMX MBean を検索するための JMSHelper クラスは非推奨になりました。このクラスは新しい JMSModuleHelper クラスで置き換えられました。このクラスには、JMS 実行時 MBean の検索や、特定のモジュール (JMS Interop モジュールなど) にある JMS モジュール コンフィグレーション エンティティの管理を行うためのメソッドがあります。
JMSModuleHelper Javadoc を参照してください。
JMSSessionPoolMBean (と JMSServerMBean にある関連するメソッド) および JMSConnectionConsumerMBean インタフェースは非推奨になりました。これらのインタフェースは、JMS セッション プールを自動的に作成したり、サーバ サイドで JMS コンシューマを起動したりするのに使用されていました。ConnectionConsumer および ServerSessionPool API は引き続きサポートされますが、より簡素で管理しやすく、機能の豊富なメッセージ駆動型 Bean (MDB) を使用することをお勧めします。
新しく WebLogic 永続ストアが導入されたため、JMSStoreMBean、JMSFileStoreMBean、および JMSJDBCStoreMBean は非推奨になりました。この非推奨の対象には、JMSServerMBean インタフェースにある関連する JMS ストアのメソッドも含まれています。
『Configuring WebLogic Server Environments』の「Using The WebLogic Persistent Store」を参照してください。
WebLogic Server は、J2EE 1.0 コネクタ アーキテクチャに基づいたリソース アダプタに加えて、J2EE 1.5 コネクタ アーキテクチャを完全にサポートしています。バージョン 1.0 のデプロイメント記述子は DTD ベースですが、バージョン 1.5 のデプロイメント記述子はスキーマ ベースです。以下の節では、特に説明のない限り、バージョン 1.5 アダプタの新機能について説明しています。
J2EE 1.5 コネクタ アーキテクチャは、複数の発信接続を扱うリソース アダプタをサポートしています。発信リソース アダプタを使用すると、アプリケーションは EIS システムに接続して作業を行うことができます。すべての通信はアプリケーションによって開始されます。リソース アダプタは EIS に接続するためのパッシブなライブラリとして機能し、アプリケーション スレッドのコンテキストで実行されます。『Programming WebLogic Resource Adapters』の「Understanding Resource Adapters」を参照してください。
以前のバージョンのリソース アダプタは発信メッセージングをサポートしていました。バージョン 1.5 のリソース アダプタでは、メッセージを含むトランザクションを EIS から受信できます。EIS はトランザクション コンテキストを送信し、そのコンテキストにおいて、メッセージが配信されたり、ワーク リクエストの形で作業が実行されます。メッセージ エンドポイント アプリケーション (メッセージ駆動型 Bean や他の J2EE コンポーネント) は、リソース アダプタ経由で EIS から着信メッセージを受信します。この機能によって、WebLogic Server 独自の InterposedTransactionManager は J2EE の標準インタフェースから利用できるようになったため、J2EE アプリケーションは、外部のトランザクション マネージャが制御するエンタープライズ環境に完全に参加することができます。EJB 2.1 より前のメッセージ駆動型 Bean (MDB) は Java Message Service (JMS) のメッセージングのみをサポートしていました。『Programming WebLogic Resource Adapters』の「Messaging and Transaction Inflow」を参照してください。
1.5 リソース アダプタでは、接続プロキシなしで、トランザクションの遅延登録やアイドル接続の検出を行えます。『Programming WebLogic Resource Adapters』の「Connection Management」を参照してください。
コネクタ仕様では、アプリケーション サーバに対して、EAR で定義されたリソース アダプタに、EAR の外部のアプリケーション コンポーネントがアクセスできないようにすることを求めています。ただし、WebLogic Integration には、そのようなアクセスを提供する要件があります。weblogic-ra.xml デプロイメント記述子の enable-access-outside-app 要素は、そのようなアクセスを明示的に有効にするためのコンフィグレーション パラメータです。『Programming WebLogic Resource Adapters』の「weblogic-ra.xml Schema」を参照してください。
アプリケーション サーバは、1.5 リソース アダプタにおいて、デプロイメントおよび再デプロイメントアクションの一部として、新しい start() および stop() メソッドを呼び出します。『Programming WebLogic Resource Adapters』の「Packaging and Deploying Resource Adapters」を参照してください。
新しい suspend() および resume() メソッドを使用すると、1.5 リソース アダプタでは、進行中のトランザクションが完了するまでの間、すべての着信メッセージを停止し、その後で通常の処理を再開することができます。『Programming WebLogic Resource Adapters』の「Creating and Configuring Resource Adapters」を参照してください。
J2EE 1.5 コネクタ アーキテクチャ仕様では、リソース アダプタでスレッドを作成しないように勧めています。リソース アダプタがスレッドを直接作成しないで作業を行えるように、自動チューニング機能を備えたコンフィグレーション可能なワーク マネージャを追加して、アプリケーション サーバの制御下で WorkRequests を作成できるようにしました。ワーク マネージャはコンフィグレーション可能であり、リソースの管理を行えます。『Programming WebLogic Resource Adapters』の「Messaging and Transaction Inflow」を参照してください。
weblogic-ra.xml デプロイメント記述子の要素を使用して、多数の新しいセキュリティ ID をコンフィグレーションできるようになりました。『Programming WebLogic Resource Adapters』の「Security」を参照してください。
バージョン 1.0 のリソース アダプタは、JNDI ツリーにバインドされた ConnectionFactory オブジェクトによって識別されます。バージョン 1.5 のリソース アダプタは、独立したオブジェクトとして JNDI ツリーにバインドされるので、独立したシステム リソースとして、または MDB のメッセージ ソースとして使用できるようになりました。『Programming WebLogic Resource Adapters』の「Connection Management」を参照してください。
トランザクションやセキュリティに関するすべてのプロパティ設定は、すべての発信接続ファクトリに適用されます。この機能が拡張されて、接続ファクトリごとの設定や、リソース アダプタ スコープのプロパティを利用できるようになりました。この設定には、接続ファクトリごとの資格マップもあります。『Programming WebLogic Resource Adapters』の「Security」を参照してください。
特定の ManagedConnectionFactory で、特定の発信接続または発信接続のプール全体をテストできるようになりました。プール全体のテストでは、プール内の各接続が個々にテストされます。『Programming WebLogic Resource Adapters』の「Connection Management」を参照してください。
リソース アダプタで接続プロキシを使用できるかどうかわかっている場合は、WebLogic Server 8.1 の weblogic-ra.xml にある use-connection-proxies 要素を true または false に明示的に設定することで、プロキシ テストを避けることができます。この方法は J2EE 1.0 コネクタ アーキテクチャに基づいたリソース アダプタのものですが、このリリースでもサポートされています。『Programming WebLogic Resource Adapters』の「Connection Management」を参照してください。
link-ref メカニズムは 1.0 リソース アダプタの非推奨になった機能ですが、現在のリリースでもサポートされています。この機能を使用すると、基本リソース アダプタを子のリソース アダプタから参照することができます。それによって、子は基本リソース アダプタのクラスやコンフィグレーションにアクセスできます。1.5 リソース アダプタでは、このメカニズムは、どのアプリケーションからもアクセスできるスタンドアロンのモジュールである、結合されたアプリケーションによって置き換えられました。『Programming WebLogic Resource Adapters』の「Creating and Configuring Resource Adapters」を参照してください。
外部 JNDI は、リモートの JNDI ツリーに直接接続しないでも、そのリモート ツリーにあるオブジェクトへアクセスできるようにする API です。外部 JNDI の詳細については、『WebLogic JNDI プログラマーズ ガイド』の「Setting Up Foreign JNDI」を参照してください。
以下の節では、WebLogic Server 9.0 の JDBC に関する新機能と変更点について説明します。
WebLogic JDBC に関する、上記およびその他の新機能と変更点の詳細については、『Configuring and Managing WebLogic JDBC』の「New and Changed Features in WebLogic JDBC」を参照してください。
WebLogic Server 9.0 は JDBC 3.0 仕様に準拠しています。JDBC 3.0 の機能の詳細については、Sun Web サイトの Java JDBC 技術のページ (http://java.sun.com/products/jdbc/) を参照してください。WebLogic JDBC の詳細については、『Configuring and Managing WebLogic JDBC』を参照してください。
WebLogic RowSet 実装は、新しい JDBC RowSet Implementations 仕様 (JSR-114) に準拠して拡張しています。Sun Web サイトの Java JDBC 技術のページ (http://java.sun.com/products/jdbc/) を参照してください。
WLCachedRowSets はいくつかの標準の RowSet 型を拡張しており、置き換えて使用できます。オプティミスティックな同時実行性オプションとデータ同期化オプションを設定するためのメソッドも含まれています。SharedRowSet は CachedRowSets を拡張したもので、元の CachedRowSet のデータに基づいて、他のスレッドで使用する追加の CachedRowSets を作成できます。SortedRowSets も CachedRowSets を拡張したもので、データベース管理システムに依存してソート処理を行うのではなく、CachedRowSet の行をメモリ内でソートできます。SharedRowSets と SortedRowSets は、アプリケーションで必要なデータベースの往復回数を減らすことで、パフォーマンスを向上させています。
『WebLogic JDBC プログラマーズ ガイド』の「WebLogic Server における RowSet の使い方」を参照してください。
WebLogic Server 9.0 JDBC は J2EE Management Model を定義した JSR-77 を完全にサポートしています。J2EE Management Model にアクセスして、WebLogic JDBC システム全体、メモリにロードされた JDBC ドライバ、JDBC データ ソースなどのリソースをモニタします。
『Configuring and Managing WebLogic JDBC』を参照してください。
WebLogic Server 9.0 の JDBC コンフィグレーションは、新しい weblogic-jdbc.xsd スキーマに準拠する XML ドキュメントに格納されます。9.0 より前のバージョンの管理方法と同じようなシステム モジュールとして、またはアプリケーション モジュールとして、JDBC リソースを作成および管理します。JDBC アプリケーション モジュールは、J2EE モジュールの WebLogic 固有の拡張機能であり、J2EE アプリケーションに含めて、またはスタンドアロンのモジュールとしてデプロイできます。詳細については、「JMS および JDBC のデプロイ可能リソースのコンフィグレーション」を参照してください。
WebLogic Server 9.0 で JDBC アプリケーション モジュールという新しいデプロイメント モデルをサポートするにあたり、WebLogic JDBC モジュールのスキーマを用意しました。作成する各 JDBC システム モジュールまたはアプリケーション モジュールはこのスキーマに従う必要があります。IDE や他のツールはこのスキーマに基づいて JDBC モジュールを検証できます。
WebLogic JDBC リソースの詳細については、『Configuring and Managing WebLogic JDBC』を参照してください。
JDBC リソース タイプを少なくして JDBC コンフィグレーションを簡素化し、コンフィグレーション エラーの可能性を低くしました。JDBC 接続プールをコンフィグレーションしてから、データ ソースまたはトランザクション (tx) データ ソースをコンフィグレーションして、その接続プールを指定し、JNDI ツリーにバインドさせる代わりに、接続プールを含むデータ ソースをコンフィグレーションします。
また、MultiDataSources は MultiPools に代わるものです。MultiDataSource は JNDI ツリーにバインドするために個別のデータ ソースを必要としません。Administration Console を使用する場合、MultiDataSource とそこに含まれるすべてのデータ ソースを 1 つの手順でコンフィグレーションできます。
『Configuring and Managing WebLogic JDBC』を参照してください。
以下の拡張により、JDBC のモニタと診断が容易になります。
Administration Console や JMX から、データ ソースの使用状況に関する新しい情報を利用できます。
詳細については、『Configuring and Managing WebLogic JDBC』の「Monitoring WebLogic JDBC Resources」を参照してください。
JDBC ドライバで呼び出されたメソッドのコールバックを利用すると、実行中のメソッド、送出された例外、ドライバ メソッドの実行にかかった時間など、JDBC ドライバの使用状況をモニタおよびプロファイルできます。
詳細については、『Configuring and Managing WebLogic JDBC』の「Monitoring WebLogic JDBC Resources」を参照してください。
JDBC サブシステムは、デバッグ アクセスとロギングが一元化された、新しいシステム全体の WebLogic 診断サービスを使用しています。
データ ソースで、最後のリソースのロギング (LLR) によるトランザクションの最適化を使用することができます。この機能を使用すると、1 つの非 XA リソースがグローバル トランザクションに参加できるようになり、パフォーマンスが向上して、XA と同じ ACID (原子性、一貫性、隔離性、持続性) が保証されます。
LLR によるトランザクションの最適化には、次のような利点があります。
『Configuring and Managing WebLogic JDBC』の「Understanding the Logging Last Resource Transaction Option」を参照してください。
JDBC データ ソースの資格マッピングを使用すると、WebLogic Server は、データベース接続に軽量のクライアント ID として、マップされたデータベース ユーザ ID を設定できます。それによって、特定のデータベース ユーザ ID を使用して新しい接続を作成する必要がなくなり、アプリケーションでは、接続プールのパフォーマンス上の利点を活用することができます。
『Configuring and Managing WebLogic JDBC』の「Credential Mapping for a Data Source」を参照してください。
マルチ データ ソースによって使用されるデータ ソースを、XA JDBC ドライバを使用するようにコンフィグレーションすると、グローバル トランザクションを含むアプリケーションで、マルチ データ ソースのフェイルオーバ機能を利用できます。
『Configuring and Managing WebLogic JDBC』の「XA Support in Multi Data Sources」を参照してください。
DataDirect の WebLogic Type 4 JDBC ドライバの更新によって、重要な問題が解決され、いくつかの機能も拡張されています。詳細については、『WebLogic Type 4 JDBC ドライバ ガイド』を参照してください。
WebLogic Server 9.0 から削除された機能は以下のとおりです。
WebLogic Server 9.0 で非推奨になった機能は以下のとおりです。
weblogic.jdbc.jts.driver。JTS ドライバは使用されなくなりました。データ ソースを使用してデータベース接続を取得してください。詳細については、『WebLogic JDBC プログラマーズ ガイド』の「Using WebLogic JDBC in an Application」を参照してください。weblogic.jdbc.pool.driver。プール ドライバは使用されなくなりました。データ ソースを使用してデータベース接続を取得してください。詳細については、『WebLogic JDBC プログラマーズ ガイド』の「Using WebLogic JDBC in an Application」を参照してください。weblogic.jdbc.rmi.driver。RMI ドライバは使用されなくなりました。データ ソースを使用してデータベース接続を取得してください。詳細については、『WebLogic JDBC プログラマーズ ガイド』の「Using WebLogic JDBC in an Application」を参照してください。
WebLogic Server 9.0 は、EJB 2.1 仕様に準拠しており、以下の節で説明するように、EJB のユーザビリティが多くの点で向上しています。
これらの機能の詳細については、『Programming WebLogic Server EJBs』を参照してください。
以下の節では、J2EE EJB 2.1 仕様に準拠する WebLogic Server の新機能を説明します。
EJB 2.1 に従い、WebLogic Server EJB タイマー サービスでは、特定の時刻、ある期間が経過した時点、または一定の間隔で、通知をスケジュールすることができます。
EJB 2.1 仕様に従い、WebLogic Server 9.0 では以下のエンタープライズ JavaBean クエリ言語 (EJB-QL) 関数が追加または変更されています。
WebLogic Server 9.0 は、論理メッセージ送り先をデプロイメント記述子内で宣言し、JMS キューなど実際のメッセージ送り先にマップできるという、EJB 2.1 の要件を満たしています。EJB は、論理メッセージ送り先名を使用して JNDI ルックアップを実行することにより、メッセージ送り先をルックアップできます。
WebLogic Server 9.0 は、外部 Web サービスの宣言と外部 Web サービスへのアクセス、およびステートレス セッション EJB の Web サービスとしての公開に関連する、EJB 2.1 の要件に準拠しています。これらの機能により、Web サービスにアクセスする EJB の開発および維持がしやすくなります。Java クライアントと Java 以外のクライアントのどちらも、Web サービスとしてのステートレス セッション Bean にアクセスできます。
いくつかの機能拡張により、MDB はより強力になり、使用およびサポートが容易になります。
client-id を作成できます。これにより、WebLogic Server クラスタにおいて、複数サーバのインスタンスへ恒久 MDB をデプロイしやすくなります。管理者は、EJB のキャッシュおよびプールの方法を、より詳細に制御できます。以下の機能すべての詳細については、『Programming WebLogic Server EJBs』を参照してください。
管理者は、要求が増大した場合には未使用のメモリを解放し、要求が減少した場合にはプールされたメモリを解放するよう、エンティティ キャッシュをコンフィグレーションできます。
この機能および「要求に応じるための動的なエンティティ キャッシュと EJB プール」で説明したコンフィグレーション可能なオプションにより、負荷が減少するとともに、メモリを消費し続けることなく、キャッシングとプーリングによって得られる応答時間上のメリットを利用できます。
EJB コンテナは、CacheFullException を送出する前に、より大きい負荷を維持できます。状況によっては、新しい要求がサービスを受けられるように、キャッシュ内の非アイドル状態の EJB をパッシベーションできます。
アプリケーション開発者は、weblogic.ejb.interfaces.EJBLocalObject の新しい operationsComplete メソッドで非アイドル状態の EJB インスタンスをパッシベーションできます。このメソッドは、その Bean に対するすべての処理が、現在のトランザクションについては完了していることを示します。コンテナは、パッシベーションのために Bean を評価する際に、この情報を使用します。
読み取り専用のエンティティ EJB は、クエリ レベルでキャッシュでき、任意のファインダによってキャッシュ内でアクセスできます。この機能により、データベース アクセスを回避して、パフォーマンスが向上します。
クエリのキャッシュは、EJB コンテナによって暗黙的に行われます。アプリケーション コードは必要ありません。この動作は、weblogic-ejb-jar.xml の entity-cache 要素における max-queries-in-cache 要素を使用して、Bean レベルまたはアプリケーション レベルのキャッシュについてコンフィグレーションできます。
オプティミスティックな同時実効性を使用する、コンテナ管理による永続性 (CMP) エンティティ EJB には、新しいコンフィグレーション オプションがあります。
コンテナ管理のトランザクションの自動的な再試行により、トランザクションが時々または定期的にロールバックされると予想される環境において、実行時のパフォーマンスを向上させることができます。自動的なトランザクションの再試行は、コンテナ管理のトランザクションの境界設定を使用するセッション Bean およびエンティティ Bean について、サポートされています。
EJB-QL クエリに加えて、EJB 開発者は、weblogic-cmp-jar.xml で SQL クエリを指定できるようになりました。
SQL クエリのコーディングは、EJB-QL でクエリ ロジックが表現できない場合、またはデータベース ベンダ固有のクエリが EJB-QL によってサポートされていない場合に、役立ちます。開発者は、EJB-QL と SQL の双方を組み合わせて使用することで、ほとんどのクエリについて EJB-QL の移植性というメリットを利用し、かつ EJB-QL では目的が達せられないクエリについては SQL を使用できます。
EJB コンテナは、プライマリ キーおよびその他のコンテナ管理による永続性フィールドにおいて String 型の値の末尾の空白を削除します。このようにして String 型の値を削除することにより、そうしなければ生じる可能性がある比較エラーおよびポータビリティ上の問題が回避されます。
EJB コンテナは、データベース操作のバッチ処理および順序付けの際に、コンテナ管理による永続性 (CMP) エンティティ間における対称的および循環的な関係を検出します。
旧バージョンの WebLogic Server では、対称的または循環的な関係におけるエンティティ上のバッチ データベース処理は、外部キーの制約または非 null 例外につながる可能性がありました。
以下の節では、Web アプリケーション、JSP、およびサーブレットの新機能を説明します。
<context-root> 要素は無視される点が異なります。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「Creating and Configuring Web Applications」を参照してください。session 要素には sharing-enabled 属性が追加されています。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「Using Sessions and Session Persistence」を参照してください。WebLogic Server では、Sun Microsystems のサーブレット 2.4 仕様をサポートするようになりました。これは http://java.sun.com/products/servlet/download.html#specs からダウンロードできます。サーブレット 2.4 仕様と、それより前の仕様のすべての相違点の詳細なリストについては、サーブレット 2.4 仕様を参照してください。WebLogic Server 9.0 への以下の変更点は、新しい仕様をサポートするものです。
<filter-dispatched-requests-enabled> 要素は、ディスパッチされた要求にフィルタを適用するかどうかを制御します。デフォルト値は false です。2.4 サーブレットは、(2.4 仕様に従って) 2.3 サーブレットと下位互換性があるため、2.3 記述子要素が WebLogic Server で検出された場合、<filter-dispatched-requests-enabled> 要素のデフォルトは true となります。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「weblogic.xml Schema」を参照してください。
『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「Servlet Programming Tasks」を参照してください。
WEB-INF ディレクトリは、アプリケーションのパブリック ドキュメント ツリーの一部ではありません。WEB-INF ディレクトリ内には、コンテナによってクライアントへ直接提供されるファイルはありません。ただし、WEB-INF ディレクトリのコンテンツは、ServletContext に対する getResource および getResourceAsStream メソッド呼び出しを使用するサーブレット コードから認識でき、RequestDispatcher 呼び出しを使用して公開されることがあります。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「Creating and Configuring Web Applications」を参照してください。ServletRequestListener および ServletRequestAttributeListener) は、サーブレット要求のライフ サイクルと、要求イベントが発生したときに呼び出されるメソッドにまたがって、状態を管理できます。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「Application Events and Event Listener Classes」を参照してください。WebLogic Server は、Sun Microsystems の JSP 2.0 仕様をサポートするようになりました。WebLogic Server 9.0 への以下の変更点は、新しい仕様をサポートするものです。
SimpleTag タグ ハンドラにより、従来のタグ ハンドラと比べて著しく簡素な呼び出しプロトコルが提供されます。『Programming WebLogic JSP Tag Extensions』の「Implementing the Tag Handler」を参照してください。javax.servlet.SingleThreadModel インスタンス プールがあります。WebLogic Server では、引き続き SingleThreadModel をサポートしていますが、これを使用することはお勧めしません。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「weblogic.xml Schema」を参照してください。<redirect-content-type> 要素は、このリリースでは廃止されています。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「weblogic.xml Schema」を参照してください。<redirect-content> 要素は、このリリースでは廃止されています。『Developing Web Applications, Servlets, and JSPs for WebLogic Server』の「weblogic.xml Schema」を参照してください。
以下の節では、WebLogic Server のアプリケーション開発における新機能を説明します。
WebLogic Server 9.0 における J2EE ライブラリのサポートにより、複数のアプリケーション間で J2EE モジュールが共有しやすくなります。J2EE ライブラリは、まずデプロイされ、次に J2EE アプリケーション コンテナに登録される、エンタープライズ アプリケーション (EAR) 内にパッケージ化された J2EE モジュールまたはモジュールの集合です。ライブラリがコンテナに登録された後は、そのライブラリを参照するエンタープライズ アプリケーションをデプロイできます。J2EE ライブラリを参照する、デプロイされた各エンタープライズ アプリケーションでは、その特定の EAR 内にパッケージ化されているかのように、ライブラリ モジュールを使用できます。
たとえば、ドメイン内の複数のエンタープライズ アプリケーションで使用される J2EE ライブラリとして、単一の Web アプリケーション モジュールをデプロイおよび登録できます。Web アプリケーションの更新が必要な場合は、1 つの場所でコードを修正し、J2EE ライブラリを再デプロイできます。次に、必要であれば Web アプリケーションの最新バージョンを使用するように、参照側のアプリケーションを再デプロイできます。
ライブラリの作成および J2EE アプリケーション内のライブラリの参照の詳細については、『Developing Applications for WebLogic Server』の「Creating Application Libraries and Optional Packages」を参照してください。ライブラリの登録および参照側アプリケーションのデプロイの詳細については、『Deploying Applications to WebLogic Server』の「Deploying Applications」を参照してください。
WebLogic Server は、J2EE 1.4 Specification の節 8.2「Optional Package Support」に記載のとおり、オプション パッケージをサポートしています。バージョニングについては、「Optional Package Versioning」で説明しています。オプション パッケージを使用すると、スタンドアロンのモジュールまたはエンタープライズ アプリケーションの一部のいずれかとしてデプロイされた複数の J2EE モジュールと、JAR ファイルのコンテンツを共有できます。たとえば、複数の Web アプリケーションで必要とされるサード パーティの Web アプリケーション フレームワーク クラスを、単一の JAR ファイル内にパッケージ化およびデプロイし、ドメイン内の複数のアプリケーション間で共有することが可能です。
通常、別々のエンタープライズ アプリケーション間で 1 つ以上の J2EE モジュールを共有する必要がある場合は、J2EE ライブラリ サポートを使用し、別々の J2EE モジュール間で 1 つ以上の JAR ファイルを共有する必要がある場合は、オプション パッケージを使用します。『Developing Applications for WebLogic Server』の「Creating Application Libraries and Optional Packages」および『Deploying Applications to WebLogic Server』の「Deploying Applications」を参照してください。
コンテキストの伝播により、プログラマは情報をアプリケーションと関連付けできます。情報はその後、すべての要求と共に伝えられます。さらに、下流のコンポーネントは、この情報を送り元に戻せるように、情報に対し追加または修正を行えます。コンテキストの伝播は、作業領域、作業コンテキスト、またはアプリケーション トランザクションとしても知られています。「Programming Context Propagation」を参照してください。
WebLogic 分割開発ディレクトリ環境および関連の Ant タスクでは、「Deploying Applications」に記載のとおり、デプロイメント プランおよび新しいアプリケーションのインストール ルートをサポートするようになりました。
wldeploy には、デプロイメント プランを指定する新しい引数があります。appc は、デプロイメント プランを含むアプリケーションに対してデプロイメント記述子の検証を行うように更新されています。
Avitek Medical Records サンプル アプリケーションは、EJB エンティティ リレーションシップ キャッシング、Log4j 統合、WebLogic 診断サービスによるカスタム診断ロギングとログ アクセス、JDBC RowSet、Struts SSL、DBA 認証、JMX を使用するセキュリティ レルム拡張機能、および XMLBean を実装するようになりました。
これらの機能がどのように実装されるかの詳細については、WebLogic Server コード例のドキュメントに記載の Avitek Medical Records サンプル アプリケーションに関する新機能のトピックを参照してください。このドキュメントは、WebLogic Server をインストールしたディレクトリの WL_HOME/samples/server/docs/core/index.html に置かれた、HTML ファイルの集合として提供されています。
アプリケーションを WebLogic Server の新しいリリースに移行する場合は、現行の J2EE 仕様と WebLogic Server のリリースの機能をアプリケーションで利用できるように、必ずデプロイメント記述子をアップグレードしておくことをお勧めします。この目的のために、新しく weblogic.DDConverter ツールが提供されています。
「以前のリリースの J2EE および WebLogic Server のデプロイメント記述子のアップグレード」を参照してください。
WebLogic Server の起動クラスと停止クラスは、WebLogic Server 9.0 では非推奨になりました。アプリケーション ライフサイクル イベントに応答するアプリケーションが優先されます。『Developing Applications with WebLogic Server』の「Programming Application Lifecycle Events」を参照してください。
以下の節では、WebLogic Server のアプリケーション デプロイメントに関する新機能を説明します。
J2EE 1.4 では、JSR-88 仕様により、標準 API アプリケーションのコンフィグレーションおよび対象アプリケーション サーバ環境へのデプロイメントが定義されます。WebLogic Server 9.0 は、J2EE 1.4 デプロイメント仕様に準拠するように、JSR-88 サービス プロバイダ インタフェース (SPI) プラグインおよびモデル プラグインを実装しています。基本的な JSR-88 デプロイメント ツールを、WebLogic Server プラグイン (拡張機能なし) と一緒に使用して、WebLogic Server に対し J2EE アプリケーションおよびモジュールをコンフィグレーション、デプロイ、および再デプロイできます。
WebLogic Server の新しいデプロイメント API は、JSR-88 を実装および拡張して、以下の節で説明する高度なデプロイメント機能をサポートします。ドメイン内でのアプリケーションのコンフィグレーション、デプロイ、および再デプロイには、Administration Console、weblogic.Deployer,wldeploy Ant タスク、WebLogic Scripting Tool など、すべての WebLogic Server デプロイメント ツールがデプロイメント API と関連して使用されます。デプロイメント API を使用して、ユーザ独自の WebLogic Server デプロイメント ツールを構築したり、WebLogic Server のコンフィグレーションおよびデプロイメント操作を JSR-88 対応の既存のツールと統合したりできます。
JSR-88 デプロイメント仕様の詳細については、J2EE v1.4 ドキュメントを参照してください。JSR-88 デプロイメントの機能拡張については、『Deploying WebLogic Server Applications』の「Introduction to WebLogic Server Deployment」および『WebLogic Server 9.0 API Reference』の「Programming WebLogic Deployment」を参照してください。
デプロイメントのためのアプリケーションのコンフィグレーションについては、『Deploying WebLogic Server Applications』の「Configuring Applications for Production Deployment」を参照してください。
基本的な JSR-88 のコンフィグレーション処理では、組織内における 1 つの環境から別の環境へのアプリケーション コンフィグレーションの移行はサポートしていません。WebLogic Server は、コマンドライン ツール weblogic.PlanGenerator で JSR-88 を拡張し、それによって複数ドメインへデプロイするためのデプロイメント プランへアプリケーション コンフィグレーションをエクスポートすることを可能にします。
グローバル リソース名やチューニング パラメータなど、変更の必要があると分かっている WebLogic Server デプロイメント記述子は、アプリケーションが別の環境にデプロイされる前に選択します。エクスポート処理によって、選択された記述子のプロパティのプレースホルダとして機能するデプロイメント プラン内に、変数定義が作成されます。Administration Console を通じて、デプロイヤはアプリケーション自体における実際のデプロイメント記述子ファイルを変更することなく、異なったサーバ ドメインのためのこれらの記述子プロパティに、簡単に値を割り当てられます。
『Deploying Applications to WebLogic Server 』の「Exporting an Application for Deployment to New Environments」および『Deploying Applications to WebLogic Server』の「weblogic.PlanGenerator Command Line Reference」を参照してください。
新しいアプリケーション ディレクトリ構造により、生成されたコンフィグレーション ファイルはコア アプリケーション ファイルから分離されるため、コンフィグレーション ファイルはアプリケーション自体を乱すことなく、簡単に変更または置換できます。図 1-1 に、デプロイ可能なアプリケーションまたはモジュールを格納するためのディレクトリ階層を示します。
インストール ルートを指定するだけで、簡単にアプリケーションをデプロイできます。また、Administration Console は対象サーバ上にステージングされている上記のデプロイメント用ディレクトリ構造を自動的に作成するため、デプロイメントのコンフィグレーション ファイルは、わかりやすい場所にあります。すべてのプロダクションのデプロイメントについて、このディレクトリ構造をお勧めします。
アプリケーションへの既存のクライアントに影響を及ぼすことなく、また新規のクライアント要求によるアプリケーションの利用を妨げることなく、古いバージョンのアプリケーションと一緒に、改定されたバージョンのプロダクション アプリケーションを再デプロイすることができます。WebLogic Server は、既存のクライアントが古いほうのアプリケーションを使用し続け、新しいクライアント要求が、新しいほうのアプリケーションに転送されるように、クライアント接続を自動的に管理します。旧バージョンは、現在のすべてのクライアントが作業を完了させるか、管理者が旧バージョンを明示的にアンデプロイするか、またはコンフィグレーション済みのタイムアウトに到達した場合に、アンデプロイされます。ロールバック機能により、たとえば新しいバージョンのアプリケーションで問題が検出された場合に、再デプロイメント処理を停止することができます。
プロダクション再デプロイメントはまた、テスト目的でプロダクション環境において新しいアプリケーションを隔離するために、管理モード (「クライアントを中断させないプロダクションの状態チェック」を参照) で使用することもできます。
『Deploying Applications to Weblogic Server』の「Redeploying Applications in a Production Environment」を参照してください。
プロダクション再デプロイメント方法をサポートするために、WebLogic Server はエンタープライズ アプリケーションの MANIFEST.MF ファイルで、ユニークなバージョンの文字列エントリを認識するようになりました。再デプロイメント処理が要求されると、WebLogic Server はバージョン文字列を確認して、新しいバージョンのアプリケーションをデプロイするかどうかを判断します。
『Deploying Applications to Weblogic Server』の「Redeploying Applications in a Production Environment」を参照してください。
管理モードを使用することにより、プロダクション環境にアプリケーションをデプロイ (または、「プロダクション再デプロイメントと可用性の維持」に記載のとおり、新しいバージョンのアプリケーションを再デプロイ) する一方で、アプリケーションを外部クライアント接続から隔離することが可能になりました。管理モードでは、アプリケーションへのアクセスはコンフィグレーション済みの管理チャネルに制限されます。アプリケーションの最終 (「状態」) チェックは、クライアントを中断させることなくプロダクション環境で直接実行できます。
『Deploying Applications to WebLogic Server』の「Using Production Redeployment to Update Applications」を参照してください。
WebLogic Server 9.0 の JMS および JDBC コンフィグレーションは、リソースの適切な WebLogic Server スキーマ weblogic-jmsmd.xsd または weblogic-jdbc.xsd に準拠する XML ドキュメントに格納されるようになりました。JMS および JDBC リソースは、バージョン 9.0 より前に管理されていたのと同様の方法でシステム モジュールとして、または標準 J2EE モジュールと同様にアプリケーション モジュールとして、作成および管理します。
JMS または JDBC アプリケーション モジュールは、スタンドアロンのリソースとしてデプロイ可能です。その場合リソースは、デプロイメント処理中に対象指定されたサーバまたはクラスタで、またはエンタープライズ アプリケーションの一部として、使用可能です。エンタープライズ アプリケーションの一部としてデプロイされたアプリケーション モジュールは、同梱されたアプリケーション (アプリケーション スコープのリソース) でのみ利用可能です。アプリケーション スコープのリソースを使用することにより、アプリケーションは常に、必要なリソースへ確実にアクセスでき、アプリケーションを新しい環境にデプロイする処理が簡素化されます。
システム モジュールと対照的に、アプリケーション モジュールの所有者は、モジュールをデプロイする管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。つまり、JDBC および JMS アプリケーション モジュールに対しては、管理者の制御が及ぶ範囲のほうが、より制限されています。アプリケーション モジュールをデプロイする際、管理者はモジュールで指定されていたリソース プロパティを変更できますが、リソースの追加や削除は行えません。システム モジュールは、WebLogic Administration Console を介して管理者によって作成され、必要に応じて、管理者により変更または削除可能です。
WebLogic Server 9.0 には、ドメインに JMS アプリケーション モジュールをデプロイするときに選択できる、新しい JMS サーバのデプロイメント対象が導入されています。次の表で、すべての有効なデプロイメント対象について説明し、それらにデプロイできるモジュールの種類をリストしています。
表 1 WebLogic Server 9.0 のデプロイメント対象
WebLogic Server には、以下の新しいデプロイメント ツールがあります。
weblogic.PlanGenerator―必要に応じて、アプリケーションをコンフィグレーションするために WebLogic Server のデプロイメント プランおよびデプロイメント記述子を生成します。また、デプロイメント記述子プロパティのための正式の分類を使用して、デプロイメント プラン変数へ、デプロイメント記述子プロパティをエクスポートします。『Deploying Applications to WebLogic Server』の「weblogic.PlanGenerator Command Line Reference」を参照してください。WebLogic Server 9.0 より前は、Administration Consoleで、展開されたアーカイブ ディレクトリを使用してデプロイされたアプリケーションの選択済みデプロイメント記述子を動的に編集できました。デプロイメント コンフィグレーションの変更は、アプリケーションの WebLogic Server デプロイメント記述子ファイルに対し直接永続化されていました。
WebLogic Server 9.0 の Administration Console では、アプリケーションがアーカイブ ファイルを使用してデプロイされたのか、展開されたアーカイブ ディレクトリを使用してデプロイされたのかに関係なく、任意のデプロイ済みアプリケーションまたはモジュールについて、WebLogic Server デプロイメントのコンフィグレーションを編集できます。デプロイメント コンフィグレーションへの変更は、元のデプロイメント記述子に手を加えることなく、WebLogic Server のデプロイメント プランに永続化されるようになりました。デプロイメント プランを使用することで、元のデプロイメント ファイルが保持され、J2EE 1.4 で導入された JSR-88 デプロイメント仕様に対する WebLogic Server の拡張機能が活用されます。
『Deploying Applications to WebLogic Server』の「Configuring Applications for Deployment」を参照してください。
バージョン 7.x および 8.x から非推奨になった、WebLogic Server 6.x の 1 フェーズ デプロイメント プロトコルは、WebLogic Server 9.0 ではサポートされなくなりました。本リリースでは、すべてのデプロイメントで 2 フェーズ デプロイメント プロトコルが使用されます。
weblogic.management.runtime.DeployerRuntimeMBean API は、本リリースより非推奨となりました。すべてのアプリケーション コンフィグレーションおよびデプロイメント タスクについて、新しい weblogic.deploy.api パッケージを使用します。
アプリケーション モジュールをデプロイするために代替デプロイメント記述子を使用することは、本リリースより非推奨となっています。パッケージ化されたアプリケーションの外部でカスタム コンフィグレーションを維持するには、代替デプロイメント記述子ではなく、JSR-88 方式のデプロイメント コンフィグレーションおよびデプロイメント プランを使用します。
デプロイメントにおいて単一のモジュールを再デプロイするために weblogic.Deployer -redeploy module-uri 構文を使用することは、非推奨となりました。代わりに、プロダクション再デプロイメントを使用するか、または -redeploy -targets module@target 構文を使用します。
WebLogic Server 9.0 では、以下の新しい XML 標準が実装されています。
本リリースで非推奨の XML 機能については、「非推奨の XML 機能」を参照してください。
本リリースで変更された XML 機能については、「変更された機能 : サーブレットでの XML ドキュメントの解析」を参照してください。
Streaming API for XML (StAX) とは、XML を読み書きするための双方向 API を記述する、Java Community Process 仕様です。StAX は、簡素な反復ベースの API および基底となるイベントのストリームを公開することによって、プログラマが解析を制御できるようにします。
「Using the Streaming API for XML」を参照してください。
Java API for XML Processing (JAX-P) 仕様のバージョン 1.2 には、TrAX (Transformation API for XML) に基づく XSLT フレームワークに加え、DOM Level 2 をサポートする解析 API に対するいくつかの更新と、プラガブルな実装を見つけるための改良されたスキーマが含まれます。JAXP は、XML スキーマおよび XSLT コンパイラ (XSLTC) のサポートを提供します。
「WebLogic Server を使用した XML アプリケーションの開発」を参照してください。
Java API for XML Registries (JAX-R) バージョン 1.0 では、さまざまな XML レジストリにアクセスする標準的な方法を記載しています。
「Using the Java API for XML Registries」を参照してください。
以下のWebLogic XML 機能はこのリリースで非推奨になりました。
WebLogic XML Streaming API は、このリリースの WebLogic Server ではまだアクセス可能ですが、その機能は非推奨になっています。プログラマは、代わりに StAX を使用してください。
「Using the Streaming API for XML」を参照してください。
Versions 8.1 およびそれ以前の WebLogic Server におけるデフォルトのパーサは、Apache の Xerces をベースにしたもので、パッケージ名の先頭には weblogic.apache.xerces.* が付いていました。バージョン 9.0 の WebLogic Server では、このパーサは非推奨となりました。代わりに、デフォルトのパーサは JDK 5.0 に同梱のものになっています。
「Difference In Default Parsers Between Versions 8.1 and 9.0 of WebLogic Server」を参照してください。
setAttribute メソッドおよび getAttribute メソッドを使用した、サーブレットからの XML ドキュメントの解析は、デフォルトでは機能しなくなりました。この機能を使用するには、まず WebLogic Server サーブレット フィルタをコンフィグレーションする必要があります。
「Parsing XML Documents in a Servlet」を参照してください。
WebLogic Server のインストールに対する、以下の変更点に留意してください。
|
|
|
C:_bea_weblogic90b) に登録されます。その後、ノード マネージャはそのインストール ディレクトリと関連のすべてのドメインとの通信を管理するのに使用できるようになります。 注意 : ノード マネージャをインストールしない場合は、カスタム インストールを実行して、[Install Windows Service] ウィンドウでノード マネージャ サービスを選択解除します。
WebLogic Server 9.0 のインストールの詳細については、『インストール ガイド』を参照してください。
WebLogic アップグレード ウィザードにより、WebLogic Server 7.0 または 8.1 リリースから WebLogic Server 9.0 へ、アプリケーション環境をアップグレードできます。具体的には、以下のアップグレードに、WebLogic アップグレード ウィザードを使用できます。
また、アップグレード ウィザードを使用して、バイナリ クラスのクラス互換性検査を実行し、WebLogic Server 9.0 では非推奨となっているか、または削除されている WebLogic API を特定することもできます。
WebLogic アップグレード ウィザードの詳細については、『Upgrading WebLogic Application Environments』を参照してください。
リリース 9.0 では、WebLogic Server JMX 実装に、いくつかの重要な変更点が導入されています。
これらの変更点の詳細については、『Developing Custom Management Utilities with JMX』の「New and Changed JMX Features in This Release」を参照してください。
Java Management Extensions (JMX) の WebLogic Server 実装は、1.0 から 1.2 にアップグレードされています。JMX 1.2 には、JMX コンポーネントが JVM 間で通信を行えるようにする、パブリック API の新しいグループが含まれています (JSR-160)。
JMX リモート API がパブリッシュされて、リモート JMX アクセスのための BEA 独自の API weblogic.management.MBeanHome は必要がなくなったため、非推奨になっています。
ドメイン コンフィグレーションに対する変更点はすべて、トランザクションと類似したプロセスに従うようになっています。管理サーバは、編集 MBean のグループをホストします。これらはドメインのコンフィグレーションへのすべての保留状態の変更をメモリ内で表現しています。編集 MBean の変更は、ドメイン内のサーバ インスタンスへ、明示的に分散される必要があります。変更を消費できないサーバが 1 つでもあれば、分散プロセスにおける一連の変更点すべてが、ロールバックされます。
詳細については、「ドメイン コンフィグレーションの変更の予測可能な配布」を参照してください。
JMX 仕様では、MBean をまとめるためのモデルを定めていません。ただし、WebLogic Server ドメインのコンフィグレーションは、 XML ドキュメント内で指定されるため、WebLogic Server は MBean を、XML ドキュメント構造を反映した階層モデルにまとめます。
たとえば、ドメインのコンフィグレーション ドキュメントのルートは <domain> であり、そのルートの下には、<server>、<cluster> などの子要素があります。各ドメインは、<domain> ルート要素を表す DomainMBean 型の単一の MBean を維持しています。DomainMBean 内では、JMX 属性が、<server>、<cluster> などの子要素を表す MBean へのアクセスを提供します。
管理サーバは、3 つの MBean サーバを維持しており、その各々が異なった MBean 階層へのアクセスを提供します。編集 MBean サーバはドメインの編集可能なコンフィグレーション MBean へのアクセスを提供し、ドメイン実行時 MBean サーバはドメイン内のすべての実行時 MBean および読み取り専用コンフィグレーション MBean への結合アクセスを提供し、実行時 MBean サーバは管理サーバ上の実行時および読み取り専用コンフィグレーション MBean にのみアクセスを提供します。
各管理対象サーバは、実行時 MBean サーバを維持します。これは、実行時および読み取り専用コンフィグレーション MBean のみへのアクセスを提供するものです。
JMX クライアントは、標準の javax.remote.access API を使用して、MBean サーバに登録された MBean にアクセスし、これらと対話を行います。
パブリックな WebLogic Server MBean はすべて、新しいドキュメント『WebLogic Server MBean Reference』で説明されています。各 MBean について、このドキュメントは、以下のものを説明します。
ロギング、JMS、JDBC、デプロイメントなど、多くのサブシステムが、旧 JMX インタフェースの全部または一部を非推奨にして、新しい MBean または更新された MBean で置き換えています。
詳細については、『WebLogic Server MBean Reference』を参照してください。
また、9.0 より前では、アプリケーションは weblogic.management.MBeanHome インタフェースを介して WebLogic Server MBean の型保障スタブ インタフェースにアクセスできました。9.0 以降では、MBeanHome インタフェースは非推奨となっています。この型付き API レイヤを使用する代わりに、すべての JMX アプリケーションで、標準 JMX プログラミング モデルを使用します。『WebLogic Server 9.0 API Reference』は、MBeanHome インタフェースまたはこれを通じてアクセスできるいかなる MBean についても、今後は記載しません。代わりに、この非推奨となったアクセスは、別のリファレンス ドキュメント『Type-Safe Access to WebLogic Server 9.0 MBeans』で説明されています。
型保障インタフェース (weblogic.management の下にある) をインポートするクラスがある場合は、標準 JMX プログラミング モデルを使用するように更新を行うことをお勧めします。
9.0 より前は、WebLogic Server インスタンスで MBean サーバにカスタム MBean を登録する場合、独自の MBean サーバを作成するか、weblogic.management.RemoteMBeanServer を使用して、WebLogic Server の MBean サーバに登録を行うことができました。
9.0 および JDK 1.5 以降は、WebLogic Server JVM で実行されている JMX クライアントから、以下のいずれかを行うことができます。
J2EE Management API 群を使用すると、ソフトウェア開発者は、JDBC 接続プールやデプロイされているアプリケーションなどのリソースをそれ 1 つで 検出して参照できる Java プログラムを J2EE Web アプリケーション サーバ上に作成できます。この API 群は J2EE の管理仕様の一部です。J2EE の管理仕様では、すべての J2EE Web アプリケーション サーバは標準データ モデルでリソースを記述する必要があります。
WebLogic Server 9.0 では、J2EE 管理仕様 (JSR-077) バージョン 1.0 の必要な機能を実装しています。
『Monitoring and Managing with the J2EE Management APIs』を参照してください。
以下の節では、WebLogic Security サービス における新機能について説明します。詳細については、『Understanding WebLogic Security』を参照してください。
Java Authorization Contract for Containers (JACC) 標準は、WebLogic Server が提供する EJB およびサーブレット コンテナのデプロイメントおよび認可に取って代わることができます。
JACC を WebLogic Server ドメインで使用するようにコンフィグレーションすると、EJB およびサーブレット認可の決定は、JACC フレームワーク内のクラスによって行われます。WebLogic Server 内における他の認可決定はすべて、引き続き WebLogic Security フレームワークによって行われます。
シングル サインオン (SSO) では、ユーザが一度アプリケーションにサインオンすれば、他のさまざまなアプリケーション コンポーネントに (それらが独自の認証方式を使用している場合でも) アクセスできます。このリリースの WebLogic Server は、Web ブラウザおよび HTTP クライアントの場合は Security Assertion Markup Language (SAML) の使用を通じて SSO をサポートし、Simple and Protected Negotiate (SPNEGO) の場合は Windows デスクトップをサポートします。
WebLogic Security サービスは、着信双方向 SSL、発信 SSL、アプリケーション コード、および WebLogic Web サービスについて、X509 証明書チェーンを検索および検証します。セキュリティ フレームワークは、JDK CertPath 機能を拡張および完了します。
以下の節では、このリリースで使用可能な新しいセキュリティ プロバイダについて説明します。詳細については、「Understanding WebLogic Security」を参照してください。
WebLogic Server は、SAML サイト間転送サービス (ITS)、アサーション コンシューマ サービス (ACS)、およびアサーション検索サービス (ARS) を提供します。それにより、WebLogic Server は SAML POST およびアーティファクト プロファイルをサポートできるようになります。WebLogic Server における SAML 機能で、WebLogic ドメイン間ならびに WebLogic Server と他のベンダの SAML 対応サーバ間、および単一の WebLogic ドメインにおけるアプリケーション間のシングル サインオン (SSO) が可能となります。WebLogic Server は、SAML 資格マッピングおよび SAML ID アサーション プロバイダを使用して、SSO プロファイルで使用されるアサーションを生成および消費します。このリリースの WebLogic Server では、SAML 1.1 がサポートされています。
WebLogic Web サービスでは、SAML トークン プロファイルが、 Web サービス クライアントと Web サービス サーバの両方として、サポートされています。
SAML の詳細については、http://www.oasis-open.org を参照してください。
どちらのプロバイダも、以下の SAML サブジェクト確認メソッドをサポートしています。
以下の拡張が、WebLogic のセキュリティ プロバイダに対して行われています。
weblogic.management.security.audit.ContextHandler もサポートします。カスタム監査プロバイダにも、このインタフェースを実装できます。Adjudicator.adjudicate()LoginModule.login()IdentityAsserter.assertIdentity()AuditAtnEvent()CredentialMapper.getCredentials()
WebLogic Tuxedo Connector は、以下のとおり拡張されています。
この dmadmin に類似の機能により、WebLogic Tuxedo Connector ユーザは WebLogic Server アプリケーションとリモート Tuxedo ドメインの間の個々の接続を開始および停止できます。リモートの Tuxedo ドメインへの個々の接続は、WebLogic Server アプリケーションと他の Tuxedo ドメインの間の通信に影響を与えることなく、停止できます。その後、ドメインのコンフィグレーションを修正してから、他の接続されたドメインに影響を与えることなく、接続を再確立して新しいコンフィグレーションを有効にできます。
WebLogic Tuxedo Connector では、FML32 における MBSTRING フィールドに加えて、新しい Tuxedo MBSTRING バッファ タイプをサポートするようになりました。MBSTRING のサポートは、基底となる JVM が処理できるコードセットを変換するために提供されています。この機能はまた、各種プラットフォームおよび標準で使用される、所定のエンコーディングのさまざまな名前のマッピングをサポートする、エリアス機能を提供します。
WebLogic Tuxedo Connector では、WTCRemoteTuxDomMBean および WTCLocalTuxDomMBean 定義における、カンマで区切られた構文 <nw-addr> XML タグで正しいファイルオーバ シーケンス情報を指定することによる、リンク レベルのフェイルオーバをサポートするようになりました。ネットワーク アドレスの順序によって、フェイルオーバの優先順位が決まります。
リンク レベルのフェイルオーバのセマンティックは、レイト バインディングです。つまり、MBean 作成時に、有無や可用性はチェックされません。これは、WTC コンフィグレーションの作成後、かつ TDomain セッション接続の作成前に、ユーザが DNS をマシンに追加できるようにするためです。
サーバには、Medical Record サンプル アプリケーションによって使用されるカスタム認証プロバイダの代わりとなる、DBMS プラガブル実行時認証プロバイダが同梱されるようになりました。
すべての EJB 例および EJB を使用するその他の例が、EJB 2.0 コードの EJBGen および記述子生成を使用するように変更されています。
WebLogic Server 9.0 キットに含まれない、さらなる WebLogic Server 9.0 コード例をダウンロードするには、https://wls9.projects.dev2dev.bea.com/ の WebLogic Server 9 projects を参照してください。
WebLogic Server のコンフィグレーションでサポート対象とされているものについての最新の情報は、『サポート対象のコンフィグレーション』を参照してください。
次の表に、WebLogic Server 9.0 でサポートされている J2EE およびその他の標準に関する情報を示します。
非推奨の WebLogic Server クラスのリストについては、http://e-docs.bea.com/wls/docs90/javadocs/deprecated-list.html を参照してください。
コマンドライン プロパティ -Dweblogic.ProductionModeEnabled={true | false} は、WebLogic Server 9.0 では非推奨となっています。これは、サーバがプロダクション モードで起動されるかどうかを決定するものでした。プロダクション モードへの変更方法については、Administration Console のオンライン ヘルプ で「プロダクション モードへの変更」を参照してください。
表 5 には、WebLogic Server に含まれるサード パーティの JAR ファイルをリストしています。
|
|
WebLogic Server のマニュアルは、9.0 リリース用に更新されています。
以下は、WebLogic Server 9.0 リリース用に追加されたマニュアルです。
これまでの『管理ガイド』は、以下のマニュアルに再編成されています。一部は、9.0 リリースから新しく加わったものです。
以下のマニュアルは、WebLogic Server 9.0 リリースからは存在しません。
IIOP マニュアルの多くの部分が、『Programming WebLogic RMI』に統合されています。IIOP クライアント情報は、『Programming Stand-alone Clients』に移動しました。
|
|
|