リリース ノート
|
 |
 |
|
BEA WebLogic Server 9.1 へようこそ。以下の節では、このリリースの新機能と変更点について説明します。
注意 : WebLogic Server はバージョン 9.0 で大幅に変更されています。これらの変更点は、以降のリリースについても適用されます。WebLogic Server 9.0 で導入された機能の詳細については、「WebLogic Server 9.0 の新機能」を参照してください。
以下の節では、WebLogic Security サービスにおける新機能について説明します。詳細については、『WebLogic Security について』を参照してください。
WebLogic Server では、XACML 認可プロバイダと XACML ロール マッピング プロバイダという 2 つの新しいセキュリティ プロバイダが用意されています。これまでのリリースの WebLogic Server では、独自のセキュリティ ポリシー言語に基づいた認可プロバイダとロール マッピング プロバイダを使用していました。これらの新しい XACML セキュリティ プロバイダは、OASIS の eXtensible Access Control Markup Language (XACML) 2.0 標準をサポートしています。これらのプロバイダは、すべての標準的な XACML 2.0 関数、属性、およびスキーマ要素を使用して、ポリシー式のインポート、エクスポート、永続化、および実行を行えます。
WebLogic Server 9.1 で作成された WebLogic Server ドメインには、デフォルトで新しい XACML プロバイダが含まれています。新しい XACML プロバイダは、WebLogic 認可プロバイダ (DefaultAuthorizer) および WebLogic ロール マッピング プロバイダ (DefaultRoleMapper) で作成されたポリシーおよびロールとの完全な互換性を備えています。既存の WebLogic Server 9.0 ドメインを 9.1 にアップグレードした場合は、サードパーティ パートナーのプロバイダや、元の WebLogic 認可プロバイダ、ロール マッピング プロバイダなど、初めに指定された認可プロバイダとロール マッピング プロバイダが引き続き使用されます。ただし、WebLogic Server 独自のプロバイダを、XACML プロバイダに置き換え、既存ポリシーのバルク インポートを実行することも選択できます。サードパーティのプロバイダを XACML プロバイダに置き換えることもできますが、そのサード パーティ プロバイダで XACML 形式でのポリシーのエクスポートができない場合、既存ポリシーのバルク インポートはできません。
Security Assertion Markup Language (SAML) の WebLogic Server 実装では、いくつかの拡張が行われています。
SAML 資格マッピング V2 プロバイダおよび SAML ID アサーション V2 プロバイダが、WebLogic Server 9.1 で新しく追加されています。SAML 資格マッピング V1 プロバイダおよび SAML ID アサーション V1 プロバイダは、非推奨になっています。V2 バージョンのものを使用してください。プロバイダのバージョン番号は V2 に上がりましたが、新しい SAML セキュリティ プロバイダでは、V1 プロバイダと同じく、SAML 1.1 標準が実装されています。
以下は、このリリースでの WebLogic JDBC の新機能です。
この機能により、データ ソースの ID ベースの接続プールが実現します。アプリケーションがデータベース接続を要求すると、WebLogic Server インスタンスは WebLogic ユーザ ID およびデータベース ID のマップに基づき、要求された DBMS の ID を備える物理的接続を選択または作成します。
『WebLogic JDBC のコンフィグレーションと管理』の「Identity-Based Connection Pooling」を参照してください。
Administration Console は、JDBC データ ソースのコンフィグレーションを簡略化するために改良されています。
WebLogic Server と一緒に、サード パーティの Sybase JConnect 6.0 (JDBC 2.0) ドライバがインストールされています。『WebLogic JDBC のコンフィグレーションと管理』の「WebLogic Server でのサードパーティ JDBC ドライバの使い方」を参照してください。
以下は、このリリースでの WebLogic Server 診断フレームワークの新機能です。
WebLogic Server では、J2EE デプロイメント仕様 API (JSR-88) で指定されているように、デプロイメント プランをサポートしています。デプロイメント プランを使うと、アプリケーション構築後に、そのアプリケーションのアーカイブに変更を加えることなく、コンフィグレーションを変更できます。
リリース 9.0 では、デプロイメント プランを使用していても、診断コンフィグレーションを変更後は、アプリケーションを再デプロイする必要がありました。
WebLogic Server 9.1 では、WLDF は「ホット スワップ」という機能をサポートしています。ホット スワップを有効化してから、デプロイメント プランと共にアプリケーションをデプロイすると、アプリケーションを再デプロイすることなく、診断インスツルメンテーションの設定を動的に更新できます。
『WebLogic 診断フレームワークのコンフィグレーションと使い方』の「Using Deployment Plans for Dynamically Controlling Instrumentation Configuration」を参照してください。
WebLogic 診断フレームワーク (WLDF) コンソール拡張は、WebLogic Server Administration Console に追加可能な拡張機能です。これにより、診断データをチャートやグラフとしてグラフィックに提示 (「ビジュアライズ」) する表示方式とツールが提供されます。『Using the WebLogic Diagnostic Framework Console Extension』を参照してください。
このリリースでは EJBGen アノテーションに以下の新しい属性が追加されました。
clusterInvalidationDisabled を、@Entity EJBGen アノテーションに追加。EJBGen は weblogic-cmp-rdbms-jar.xml ファイル内に cluster-invalidation-disabled 要素を生成できるようになりました。remoteClientTimeout を、@Entity、@Session、および @MessageDriven EJBGen アノテーションに追加。EJBGen は weblogic-ejb-jar.xml ファイル内に remote-client-timeout 要素を生成できるようになりました。
WebLogic Server 9.1 では、WebLogic Server JMS およびストア アンド フォワード サービスのコンフィグレーション、管理、可用性、およびパフォーマンスにおいて、次のような改良が行われています。
このリリースの JMS コンフィグレーションは、weblogic-jmsmd.xsd スキーマに準拠する XML ファイルによって定義されるモジュールとして格納されます。Administration Console を使用して JMS リソースをグローバルに使用可能なシステム モジュール内でコンフィグレーションする場合、単にリソース タイプに対してあらかじめ選択された対象を受け付けるのか、既存のサブデプロイメントの選択、新しいサブデプロイメントの作成のいずれかを行える詳細な対象指定ページに進むのかを選択できます。サブデプロイメントとは、JMS モジュール リソース (キュー、トピック、接続ファクトリなど) をグループ化し、サーバ リソース (JMS サーバ、サーバ インスタンス、クラスタなど) に対象指定するメカニズムです。また、モジュールレベルのサブデプロイメント管理ページも追加されており、JMS システム モジュール用のコンフィグレーション済みサブデプロイメントを管理できます。
『WebLogic JMS のコンフィグレーションと管理』の「JMS モジュールとサブデプロイメント リソースの対象指定」を参照してください。
ストア アンド フォワード サービスでは、JMS SAF 送り先のメッセージ ライフ サイクルのロギングが行えるようになりました。メッセージ ライフ サイクルのロギング機能を利用すると、管理者は JMS サーバから、メッセージの生成、消費、削除などの基本的なライフ サイクル イベントによって、JMS メッセージをより正確に把握することができます。ロギングは、長期間にわたって継続的に発生します。また、JMS サーバの実行中にリアルタイム モードで使用したり、JMS サーバの停止中にオフラインで使用したりすることも可能です。
『WebLogic ストア アンド フォワードのコンフィグレーションと管理』の「WebLogic SAF のトラブルシューティング」を参照してください。
メッセージ管理の強化により、管理者は Administration Console またはパブリックな実行時 API を使用して、恒久トピック サブスクライバおよび分散キューを管理できます。またこの機能を利用すると、恒久サブスクライバおよび分散キュー上のすべてのメッセージを表示および参照し、ほとんどのメッセージを操作することができます。これらのメッセージ管理の強化には、メッセージの参照 (ソート目的)、メッセージの操作 (移動、削除等)、メッセージのインポートとエクスポートなどがあります。
『WebLogic JMS のコンフィグレーションと管理』の「JMS メッセージの管理」を参照してください。
JMS クライアントの再接続機能を使用すると、ネットワークで障害が発生した際に JMS クライアント オブジェクトを個別に、またはまとめてリフレッシュできるようにすることで、透過的なフェイルオーバが実現されます。ネットワーク接続の失敗の原因としては、一過性のもの (ネットワーク接続の一時的な中断) と一過性でないもの (サーバのバウンスまたはネットワーク障害) が考えられます。WebLogic Server 9.1 の場合、リフレッシュ可能なクライアント オブジェクトには、ConnectionFactories、Destinations、Connections、Sessions、Producers などがあります。
たとえば、JNDI を通じてルックアップされた JMS 送り先 (キューまたはトピック) は、ネットワークで障害が発生した後、もう一度ルックアップすることなく再使用できます。この機能は、JMS クライアント JVM と、それが JNDI ルックアップの一部として接続されているリモート WebLogic Server インスタンスとの間、および JMS クライアント JVM と、クライアントがその後接続する同じクラスタ内の任意のリモート WebLogic Server インスタンスとの間でのネットワーク障害に適用されます。
『WebLogic JMS プログラマーズ ガイド』の「Automatic Failover for JMS Clients」を参照。
WebLogic Server 9.1 より前は、同期コンシューマでは各メッセージについて双方向のネットワーク呼び出しが必要でした。このモデルでは同期コンシューマは複数のメッセージを取得できず、取得できるメッセージを求めて継続的にサーバに対してポーリングを行うことになるため、ネットワーク トラフィック リソースの使用量が増えてしまいます。非同期コンシューマ モデルを使用すると、メッセージはメッセージ リスナへのパイプラインを使用して一方向に送信されます。さらに、非同期パイプラインでは、複数のメッセージを単一のネットワーク呼び出しに集約できます。
WebLogic Server 9.1 では、Administration Console または JMSClientParamsBean MBean を介してコンシューマの JMS 接続ファクトリの [同期コンシューマのプリフェッチ モード] オプションを有効化することにより、同期コンシューマが非同期コンシューマと同じ効率的な動作を利用できるようになります。非同期メッセージ パイプラインと同様に、接続ファクトリで [同期コンシューマのプリフェッチ モード] が有効化された場合、対象指定された JMS サーバは、接続ファクトリの [セッションあたりの最大メッセージ数] パラメータを使用してバッチごとのプリフェッチされたメッセージの最大数を定義し、プロアクティブに未消費のメッセージのバッチを同期メッセージ コンシューマへ送信します。
この機能を使うと、同期コンシューマでさらにメッセージを処理する準備が整った時点で、メッセージが準備され待機していることになるため、パフォーマンスが向上する可能性があります。また、この機能がなければ継続的にメッセージをポーリングしていなければならないコンシューマからの同期呼び出しが低減されることで、ネットワーク トラフィックが抑えられることも考えられます。
『WebLogic JMS プログラマーズ ガイド』の「Using the Prefetch Mode to Create a Synchronous Message Pipeline」を参照してください。
JMS 送り先の [メッセージング パフォーマンスのオプション] オプションを使用すると、送り先によるメッセージ処理をきめ細かくチューニングできます。JMS 送り先には、コンシューマへの配信用にメッセージをグループ化してバッチにすることで、自動的にパフォーマンスを最適化しようとする内部アルゴリズムが組み込まれています。メッセージ レートやその他の要因の変更に応じて、これらのアルゴリズムはバッチ サイズと配信時間を変更します。しかし、これらのアルゴリズムであらゆるメッセージング環境についてパフォーマンスを最適化することは不可能です。[メッセージング パフォーマンスのオプション] チューニング オプションでは、これらのアルゴリズムがメッセージ レートやその他の要因の変更に対してどのように反応するかを修正し、お使いのシステムのパフォーマンスをきめ細かくチューニングすることが可能です。
『WebLogic JMS のコンフィグレーションと管理』の「WebLogic JMS のチューニング」を参照してください。
SAF 送信エージェントには、JMS SAF メッセージに関する [ウィンドウ間隔] パラメータが付加されました。これは、JMS メッセージを 1 つのバッチとして転送するまでに SAF 送信エージェントが待機する最長時間 (ミリ秒単位) です。
ウィンドウ間隔は、フォワーダが既に、メッセージを到着するのと同じ速度で転送できるようになっている場合にのみ、有効となってパフォーマンスを向上させます。この場合、新しく届いたメッセージをすぐに転送するのではなく、フォワーダはさらに多くのメッセージを蓄積してそれらをバッチとして転送しようとして、休止します。その結果、バッチ サイズが大きくなって、転送スループットが向上し、全体的なシステム ディスクと CPU 使用率が低減される一方、メッセージ レイテンシが増大するおそれがあります。
SAF エージェントのパラメータの詳細については、Administration Console オンライン ヘルプの「ストア アンド フォワード エージェント : コンフィグレーション : 全般」を参照してください。
WebLogic Administration Console における、リソース アダプタのリソース アダプタ Bean、発信接続、および管理オブジェクトのプロパティをコンフィグレーションするページは、使いやすさを向上させるために拡張されています。
Administration Console オンライン ヘルプの「リソース アダプタのコンフィグレーション」を参照してください。
以下の節では、WebLogic Web サービスの新機能について説明します。
WebLogic Web Services 9.1 には、以下の新しいセキュリティ関連の JWS アノテーションが用意されています。これらのアノテーションを JWS ファイルで使用すると、アクセス制御セキュリティをコンフィグレーションし、Web サービス呼び出し時に HTTPS が要求されることを指定し、Web サービスと関連付けられるユーザを指定できます。
weblogic.jws.security.RolesAllowedweblogic.jws.security.SecurityRoleweblogic.jws.security.RolesReferencedweblogic.jws.security.SecurityRoleRefweblogic.jws.security.RunAsweblogic.jws.security.UserDataConstraintこれらのアノテーションの使用手順については「アクセス制御セキュリティのコンフィグレーション : 主な手順」を、リファレンス情報については「JWS アノテーション リファレンス」を参照してください。
クライアント アプリケーションで weblogic.wsee.connection.transport.http.HttpTransportInfo API を使用して、基本認証用にコンフィグレーションされた Web サービスの動的 WSDL にアクセスする際にユーザ名およびパスワードを指定できるようになりました。この API はまた、Web サービス呼び出し時のプロキシ サーバの指定にも使用できます。
「Setting the Username and Password When Creating the JAX-RPC Service Object」および「Using a Proxy Server When Invoking a Web Service」を参照してください。
Web サービス呼び出し時に複数のクライアントサイド WS-Policy ファイルの関連付けを行えるようになりました。これまでは 1 つしか関連付けできませんでした。
「クライアントサイド セキュリティ WS-Policy ファイルの使用」を参照してください。
デフォルトでは、WebLogic Web サービス ランタイムは常に、関連付けられたすべての WS-Policy ファイルの <KeyInfo> アサーションで指定されている X.509 証明書を検証します。しかしこのリリースでは、SAML holder-of-key アサーションの使用時にこの検証を無効化できます。
「SAML holder_of_key アサーション使用時の X.509 証明書の検証の無効化」を参照してください。
wsdlc Ant タスクには、failonerror という新しい属性が備わっています。
「wsdlc」を参照してください。
Administration Console を使用して、デプロイされた WebLogic Web サービスをテストできるようになりました。
「Web サービスのテスト」を参照してください。
以下の Web サービス機能は、WebLogic Server のリリース 9.1 以降では非推奨になっています。
以下の節では、WebLogic Tuxedo Connector の新機能について説明します。
ファイアウォールで、WTC TDomain 接続のタイムアウトが発生することがあります。ファイアウォール接続のタイムアウトが生じると、WTC と Tuxedo TDomain ゲートウェイの間の通信が停止します。しかし、ファイアウォールによって TCP ABORT イベントが生成されないことがあり、その場合、望ましくない結果がもたらされます。新しいアプリケーション キープアライブ機能を有効化すると、長期間にわたってユーザ レベルのネットワーク アクティビティが生じていない場合でも、WTC と Tuxedo TDomain ゲートウェイの間の接続が維持されます。
「WebLogic Tuxedo Connector のコンフィグレーション」の「Avoiding Hung Threads」を参照してください。
FML32 バッファ タイプのサポートが強化されたため、FML32 バッファ内に VIEW32 バッファを埋め込むことができます。またこの機能により、FML32 バッファ周辺のアプリケーション設計において、より高い柔軟性が実現しています。
この機能を利用するには、FML32 バッファ内に埋め込まれた VIEW32 を使用するようにアプリケーションを変更する必要があります。しかし、新しいコンフィグレーション属性を追加したり、既存のコンフィグレーション属性を変更したりする必要はありません。
注意 : この機能を利用しない場合は、既存のアプリケーションに変更を加える必要はありません。
『WebLogic Tuxedo Connector プログラマーズ ガイド』の「How to Get VIEW32 Data In and Out of FML32 Buffers」を参照してください。
管理者は、WTC サーバごとにサービスの中断と再開を行えます。WTC サービスを中断および再開する機能は、インポート済みのサービスについても動的に使用可能です。
『WebLogic Tuxedo Connector 管理ガイド』の「Controlling WebLogic Tuxedo Connector Connections and Services」を参照してください。
WebLogic Server には、HTTP サーブレット使用時にハングしているスレッドを回避することを可能にする、2 つの新しいクラスが用意されています。
このサーブレットを使用すると、サーブレット応答と受信要求を、別々のスレッドで処理できます。
このサーブレットを有効化するには、weblogic.servlet.FutureResponseServlet.java を拡張します。
『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「Avoiding Hung Threads」を参照してください。
Administration Console で表示した場合のエンタープライズ アプリケーションのデプロイメント プランに、そのアプリケーションのリソースの依存関係を示すページが追加されています。見つからない依存関係または未解決の依存関係があれば、赤いアイコンで強調表示されます。
Administration Console の、アプリケーションや J2EE ライブラリをデプロイおよびモニタするページで、以下のことが可能になりました。
|
|
|