|
|
BEA WebLogic Server 9.2 へようこそ。以下の節では、このリリースの WebLogic Server™ の新機能と変更点について説明します。
| 注意 : | WebLogic Server はリリース 9.0 で大幅に変更されています。これらの変更点は、以降のリリースについても適用されます。 |
このリリースの WebLogic セキュリティの新機能は以下のとおりです。
WebLogic Server Administration Console で作成できるものよりも複雑なセキュリティ ロールまたはポリシーを作成する必要がある場合、または、セキュリティ ロールおよびポリシーを標準の言語で表現する必要がある場合は、ロールおよびポリシーを XML ドキュメントで作成し、WebLogic Scripting Tool を使用してセキュリティ レルムに追加することができます。以下の要件に注意してください。
weblogic.management.security.authorization.PolicyStoreMBean インタフェースを実装する別のプロバイダを使用する必要がある。weblogic.management.security.authorization.PolicyStoreMBean インタフェースを実装する別のプロバイダを使用する必要がある。
XACML ロールおよびポリシーの作成とレルムへの追加の詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』の「XACML ドキュメントによる WebLogic リソースの保護」を参照してください。
MBean サーバに登録されている WebLogic Server MBean を保護するために、WebLogic Server ではデフォルトのセキュリティ ロールおよびポリシーを提供しています。WebLogic Server 9.2 より前では、WebLogic Server MBean のデフォルトのポリシーを変更することはできませんでした。このリリースでは、WebLogic Server Administration Console を使用して、デフォルトのアクセス パーミッションを変更できます。たとえば、特定のアプリケーション用のロールを作成して、そのアプリケーションに関連付けられている MBean インスタンスに特定のロールのみがアクセスできるようにすることが可能です。Administration Console オンライン ヘルプの「JMX ポリシーの作成」を参照してください。
XACML 2.0 に基づいてカスタムのロールおよびポリシーを作成し、WebLogic Scripting Tool を使用してセキュリティ レルムに追加することもできます。「カスタムの XACML ロールおよびポリシーのサポート」を参照してください。
WebLogic Server MBean サーバでカスタム MBean を登録すると、ロールやポリシーを WebLogic Security サービスとともに使用することで MBean を保護できます。以下の制限に注意してください。
Type=value」キー プロパティが含まれている必要がある。weblogic.management.security.authorization.PolicyStoreMBean インタフェースを実装する別のプロバイダを使用する必要がある。weblogic.management.security.authorization.PolicyStoreMBean インタフェースを実装する別のプロバイダを使用する必要がある。
XACML ロールおよびポリシーの作成とレルムへの追加の詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』の「カスタム MBean のロールまたはポリシーの作成」を参照してください。
WebLogic Server には、以下の認可、裁決、およびロール マッピング プロバイダ SSPI インタフェースのバルク アクセス バージョンがあります。
バルク アクセス SSPI インタフェースを使用すると、認可、裁決、およびロール マッピング プロバイダにおいて、1 回の呼び出しで複数の判定リクエストを取得できます。これまでのように、たとえば「for」ループで複数の呼び出しを実行する必要はありません。この機能によって、プロバイダ実装は内部的なパフォーマンスの最適化を利用できるようになります。たとえば、渡された多数の Resource オブジェクトが同じポリシーで保護されていることを検出し、同じ決定結果を生成する機能などです。
追加情報については、『WebLogic セキュリティ プロバイダの開発』の「認可プロバイダ」、「裁決プロバイダ」、および「ロール マッピング プロバイダ」を参照してください。
WebLogic Server には、JMX (MBean) デフォルト ポリシーおよび WebService アノテーションのポリシー コンシューマと、WebService アノテーションのロール コンシューマが実装されています。このリリースの WebLogic Server に含まれている SSPI を使用すると、認可プロバイダおよびロール マッピング プロバイダでポリシーおよびロールのコレクションを取得できます。
PolicyConsumer および RoleConsumer SSPI は省略可能です。ポリシーまたはロールのコレクションを消費するためには、この SSPI を実装する認可プロバイダおよびロール マッピング プロバイダのみが呼び出されます。
SSPI では、初期のポリシー コレクションおよびロール コレクションの配信と、更新後のポリシー コレクションおよびロール コレクションの配信の両方がサポートされます。
認可プロバイダをカスタマイズしてポリシー コレクションの配信をサポートするには、以下の 3 つのインタフェースを実装する必要があります。
カスタム ロール マッピング プロバイダでロール コレクションの配信をサポートするには、以下の 3 つのインタフェースを実装する必要があります。
追加情報については、『WebLogic セキュリティ プロバイダの開発』の「ポリシー コンシューマ SSPI」および「ロール コンシューマ SSPI」を参照してください。
以前のリリースでは、Administration Console 拡張を使用し、タグ ライブラリ ファイルのパス名を指定してサードパーティの JSP タグ ライブラリをインポートすることができました。次に例を示します。<%@ taglib uri="/WEB-INF/beehive-netui-tags-template.tld" prefix="beehive-template" %>
このリリースでは、Administration Console 拡張で、インストールされている WebLogic Server からサードパーティの JSP タグ ライブラリを使用する場合は、定義済みの絶対 URI を使用してタグ ライブラリを指定する必要があります。次に例を示します。<%@ taglib uri="http://beehive.apache.org/netui/tags-template-1.0" prefix="beehive-template" %>
Administration Console の web.xml ファイルでは、これらの URI を、インストールされている WebLogic Server 内部のタグ ライブラリにマップします。このマッピング機能によって、ユーザが JSP を変更しないでも、タグ ライブラリのインストール ディレクトリが認識されます。
Apache Struts、Apache Beehive、または JSTL タグ ライブラリをインポートするために古いパス名構文を使用している Administration Console 拡張では、すべてのパス名を新しい URI に更新する必要があります。
WebLogic Server コンソール拡張タグ ライブラリ (console-html.tld) の URI は /WEB-INF/console-html.tld のままで変わりません。
『Administration Console の拡張』の「JSP タグ ライブラリ」を参照してください。
このリリースの JDBC および JTA の新機能は以下のとおりです。
この機能によって、Oracle Real Application Clusters (RAC) などの環境では、マルチ データ ソースの対象指定を解除して再デプロイすることなく、RAC ノードと対応するデータ ソースを追加および削除できるようになります。『WebLogic JDBC のコンフィグレーションと管理』の「マルチ データ ソースの機能」を参照してください。
この機能によって、ロギング ラスト リソース (LLR) トランザクションの最適化では、フェイルオーバ後にトランザクション回復サービスの移行を利用できるようになります。『WebLogic JTA プログラマーズ ガイド』の「LLR のフェイルオーバに関する考慮事項」を参照してください。
新しいデータ ソース制御によって、Administration Console からデータ ソースの個々のインスタンスを手動で起動できるようになりました。『WebLogic JDBC のコンフィグレーションと管理』の「データ ソースの起動」を参照してください。
BEA WebLogic Type 4 JDBC MS SQL Server ドライバは Microsoft SQL Server 2005 データベース管理システムをサポートします。『WebLogic Type 4 JDBC ドライバ ガイド』の「サポートされる SQL Server データベースのバージョン」を参照してください。
WebLogic 診断フレームワーク (WLDF) と WLDF コンソール拡張の両方に新機能があります。
新しい標準のアプリケーション スコープ モニタである HttpSessionDebug を使用すると、HTTP セッション オブジェクトを検査できます。
WebLogic Server 9.2 では、WebLogic Server JMS、メッセージング ブリッジ、およびストア アンド フォワード サービスにおける以下の改良点があります。
9.0 で導入された WebLogic ストア アンド フォワード (SAF) サービスによって、WebLogic Server は、WebLogic Server クラスタ、ドメイン、およびサーバ インスタンスにわたって分散されているサーバ サイドの JMS アプリケーションに、JMS メッセージを確実に配信できるようになりました。リリース 9.2 では、JMS SAF クライアントがストア アンド フォワード メカニズムを備えています。このメカニズムでは、(ネットワーク接続の障害などが原因で) JMS クライアントが一時的に送り先にアクセスできない場合でも、スタンドアロンの JMS クライアントはサーバサイドの JMS 送り先にメッセージを確実に送信できます。サーバとの接続が切断されている間、JMS SAF クライアントによって送信されたメッセージはクライアント上でローカルに格納され、クライアントが再接続するときに、サーバ サイドの JMS 送り先に転送されます。
『スタンドアロン クライアント プログラマーズ ガイド』の「JMS SAF クライアントによる確実なメッセージ送信」を参照してください。
サーバまたはネットワークの障害が発生した場合、一部の JMS クライアント オブジェクトは透過的にフェイルオーバして、使用可能であれば別のサーバ インスタンスを使用します。リリース 9.1 以降では、既存のクライアント コードを手動でコンフィグレーションまたは変更しなくても、WebLogic JMS メッセージ プロデューサ アプリケーションは、使用可能なサーバ インスタンスへ自動的に再接続しようとします。リリース 9.2 では、Administration Console または WebLogic JMS API を利用して、使用可能なサーバ インスタンスに自動的に再接続するように WebLogic JMS メッセージ コンシューマ アプリケーションをコンフィグレーションできます。
『WebLogic JMS プログラマーズ ガイド』の「JMS クライアントの自動フェイルオーバ」を参照してください。
WebLogic Server 9.0 では、単位内のメッセージを一度に 1 つずつ配信することでメッセージをグループ化する、メッセージ順序単位機能が導入されました。ただし、多くのアプリケーションは、より限定的なグループの定義を必要としています。そのため、リリース 9.2 では作業単位機能を導入しました。この機能では、アプリケーションが JMS メッセージを送信すると、その一部がグループとして識別され、コンシューマはそれらのメッセージをグループとして処理できるようになります。たとえば、アプリケーションでは、メッセージが 1 つの単位として処理されるように、1 つのクライアントに中断せずに配信する必要のあるメッセージの集合を指定することができます。
『WebLogic JMS プログラマーズ ガイド』の「作業単位メッセージ グループの使用」を参照してください。
WebLogic ストア管理ユーティリティを使用すると、WebLogic ストアのトラブルシューティングを行ったり、データを抽出したりできます。ストア管理の最も一般的な使用例は、サイズを減らすためにファイル ストアを圧縮する場合や、トラブルシューティングを目的としてファイル ストアまたは JDBC ストアの内容を XML ファイルにダンプする場合です。このユーティリティは Java コマンドラインまたは WLST から実行できます。
『WebLogic Server 環境のコンフィグレーション』の「永続ストアの管理」を参照してください。
一方向メッセージ送信を使用すると、一般的な非永続メッセージングのパフォーマンスが大幅に改善される可能性があります。接続ファクトリで [一方向送信モード] オプションを有効にすると、関連付けられたプロデューサは、ターゲット送り先のホスト JMS サーバからの応答を内部的に待機せずに、メッセージを送信できます。キュー センダおよびトピック パブリッシャに一方向送信を許可したり、この機能をトピック パブリッシャのみに制限したりできます。一方向ウィンドウ サイズをコンフィグレーションして、追加の一方向送信を続行する前に、プロデューサを制御するために双方向メッセージが必要になる時期を決定することもできます。
『WebLogic Server パフォーマンス チューニング ガイド』の「一方向メッセージ送信による非永続メッセージングのパフォーマンスの向上」を参照してください。
JMSXDeliveryCount は、メッセージの配信試行回数を指定するシステム生成のプロパティです。1 回目の試行が 1、2 回目の試行が 2 (以降同様) になります。WebLogic Server では、可能な限り配信回数を永続化することで、サーバの再起動後に配信回数が 1 にリセットされないようにしています。詳細については、『WebLogic JMS プログラマーズ ガイド』の「メッセージ プロパティ フィールド」を参照してください。
BEA WebLogic Server 5.1 は廃止されて、サポートされなくなりました。WebLogic Server 5.1 と相互運用するために使用されるメッセージング ブリッジ アダプタは、このリリースで非推奨となり、次のメジャー リリースでは削除されます。「サポート対象のコンフィグレーション」の「WebLogic Server 5.1 の製品ライフサイクル情報」を参照してください。
Web サービスには、以下の節で説明する新機能と変更点があります。
バージョン 9.2 の WebLogic Web サービスには、Web Services Secure Conversation Language (WS-SecureConversation、2005 年 2 月) 仕様の実装が含まれています。
WebLogic Server 8.1 で実装された WS-Security 1.0 仕様では、基本的なメカニズムが提供されており、さらに、セキュアなメッセージング セマンティクスを複数のメッセージ交換に対して定義できます。WS-SecureConversation 仕様では、セキュリティ コンテキストの確立と共有や、セッション キーの派生を可能にする拡張が定義されています。より効率的なキーや新しい形式のキーを交換できるようになるため、交換の全体的なパフォーマンスやセキュリティの向上につながります。
『WebLogic Web サービス プログラマーズ ガイド』の既存の節「メッセージレベルのセキュリティ (デジタル署名と暗号化) のコンフィグレーション」を参照してください。WS-SecureConversation の情報と手順が含まれるように改訂されました。
コールバックは、何らかのイベントが発生したことを Web サービスのクライアントに通知します。たとえば、クライアントの要求に対する結果が準備できたことを通知したり、クライアントの要求を遂行できないことを通知したりできます。
『WebLogic Web サービス プログラマーズ ガイド』の「コールバックによるクライアントへのイベントの通知」を参照してください。
WebLogic Web サービスは、SOAP 1.1 に加えて SOAP 1.2 をサポートします。Web サービスの SOAP メッセージで SOAP 1.2 を使用することを指定するには、@weblogic.jws.Binding JWS アノテーションを使用します。
『WebLogic Web サービス プログラマーズ ガイド』の「@weblogic.jws.Binding」を参照してください。
JWS ファイルで複数の @WLXXXTransport アノテーションを指定して、または jwsc Ant タスクの複数の <WLXXXTransport> 子要素を指定することで、さまざまな転送方式 (HTTP、HTTPS、または JMS) を使用して Web サービスが呼び出されるようにすることができます。WebLogic Server 9.2 より前では、1 つの Web サービスにつき 1 つの転送方式のみを指定できました。
『WebLogic Web サービス プログラマーズ ガイド』の「jwsc」および「JWS アノテーション リファレンス」を参照してください。
新しい @weblogic.jws.StreamAttachments JWS アノテーションを使用すると、添付ファイルを含む着信 SOAP メッセージを読み込むときに、メッセージ全体をメモリに読み込むというデフォルトの動作ではなく、Web サービスがストリーミング API を使用することを指定できます。この機能によって、特に大きな SOAP メッセージを扱う Web サービスのパフォーマンスが向上します。
『WebLogic Web サービス プログラマーズ ガイド』の「SOAP 添付ファイルのストリーミング」を参照してください。
Administration Console を使用して、デプロイ済み Web サービスの動的 WSDL で WebLogic Server がパブリッシュするサーバ アドレス (プロトコルおよびホスト情報) をコンフィグレーションできるようになりました。サーバ アドレスは、WSDL で特定の Web サービス ポートの <address> 要素によって指定される、URL の最初の部分です (http://myhost:7101 など)。
『WebLogic Web サービス プログラマーズ ガイド』の「動的な WSDL で指定されたサーバ アドレスのコンフィグレーション」を参照してください。
WebLogic Administration Console に含まれる Web サービス テスト クライアントを使用すると、クライアント コードを記述しないでも Web サービスをテストできます。
Administration Console オンライン ヘルプの「Web サービスのテスト」を参照してください。
バージョン 9.2 の WebLogic Web サービスには、新しい API WSSecurityInfo があります。この API を使用すると、SOAP メッセージのセキュリティ ヘッダを表示できます。この情報には、SOAP メッセージのデジタル署名または暗号化された部分と、提示されたユーザ名およびパスワードが含まれています。
「BEA WebLogic Server 9.2 API Reference」の「WSSecurityInfo」を参照してください。
以下の JWS アノテーションがこのリリースで新しく追加されました。
@weblogic.jws.Binding@weblogic.jws.Callback@weblogic.jws.CallbackMethod@weblogic.jws.CallbackService@weblogic.jws.ReliabilityErrorHandler@weblogic.jws.StreamAttachments@weblogic.jws.Types@weblogic.jws.security.CallbackRolesAllowed@weblogic.jws.soap.SOAPBinding
既存の @weblogic.jws.Transactional JWS アノテーションには timeout という新しい属性があります。既存の @weblogic.jws.WLJmsTransport アノテーションには connectionFactory という新しい属性があります。
『WebLogic Web サービス プログラマーズ ガイド』の「JWS アノテーション リファレンス」を参照してください。
以下の節で説明するように、主に 8.1 WebLogic Workshop Web サービスのアップグレードをサポートするため、WebLogic Web サービス Ant タスクが更新されました。
JWS ファイルをデプロイ可能な Web サービスにコンパイルするために使用される jwsc Ant タスクは、以下のように変更されました。
jwsc タスクは、JWS ファイルから Web アプリケーション WAR ファイルを生成してパッケージ化する。ただし、唯一の例外として、JWS ファイルが明示的に javax.ejb.SessionBean を実装している場合、Ant タスクは Web サービスを EJB JAR ファイルに生成およびパッケージ化します。WebLogic Server 9.2 より前では、特定の種類の JWS ファイルを処理するときに、jwsc Ant が EJB を生成することがありました。<FileSet> タスクを使用できる。jwsc Ant タスクには以下の新しい子要素がある。<module> - 2 つ以上の JWS ファイル (<jws> 要素で指定) を 1 つのモジュール (Web アプリケーション WAR ファイルなど) にグループ化します。<module> の下で <jws> 要素をグループ化しない場合、jwsc は JWS ファイルごとに個別の Web アプリケーション WAR ファイルを生成します。<clientgen> - jwsc Ant タスクがコンパイルする JWS ファイル内で呼び出される Web サービスの、クライアントサイドの JAX-RPC スタブを生成します。<jwsfileset> - jwsc がコンパイル対象の JWS ファイルを検索する 1 つまたは複数のディレクトリを指定します。<descriptor> - 新しいファイルを生成する代わりに、jwsc Ant タスクが情報を追加する既存の web.xml または weblogic.xml ファイルを指定します。jwsc Ant タスクには以下の新しい属性がある。
『WebLogic Web サービス プログラマーズ ガイド』の「jwsc」を参照してください。
clientgen Ant タスクは以下のように変更されました。
『WebLogic Web サービス プログラマーズ ガイド』の「clientgen」を参照してください。
『WebLogic Web サービス プログラマーズ ガイド』の「wsdlc」を参照してください。
このリリースにおける Web サービスの追加の変更点は以下のとおりです。
java.util.Collection や java.util.List などのコレクション データ型をサポートする。Apache XMLBeans (パッケージ org.apache.xmlbeans) データ型もサポートされます。サポートされるデータ型の完全なリストについては、『WebLogic Web サービス プログラマーズ ガイド』の「データ型とデータ バインディング」を参照してください。jwsc および wsdlc Ant タスクは、<xsd:any> および <xsd:anyType> XML スキーマ データ型を両方ともサポートする。@weblogic.jws.ReliabilityErrorHandler アノテーションを使用すると、信頼性のある Web サービスにエラー処理を追加できる。WebserviceTimestampMBean には新しいプロパティ ClockSkew がある。
以下の Web サービス機能はこのリリースで非推奨になりました。
@weblogic.jws.WLHttpsTransport アノテーションおよび jwsc Ant タスクの <WLHttpsTransport> 要素。
代わりに、@weblogic.jws.WLHttpTransport アノテーションまたは <WLHttpTransport> 要素を使用してください。これらは HTTP および HTTPS プロトコルを両方ともサポートするようになったためです。クライアント アプリケーションに HTTPS プロトコルのみを使用して Web サービスにアクセスさせるには、JWS ファイルで @weblogic.jws.security.UserDataConstraint JWS アノテーションも指定する必要があります。
WebserviceTimestampMBean の ClockPrecision および LaxPrecision プロパティが非推奨になった。代わりに新しい ClockSkew プロパティを使用してください。weblogic.webservice.async.KernelFeederImpl.ExecuteTask インタフェースは WebLogic Server から削除された。wsdlc Ant タスクの srcBindingName 属性。代わりに srcServiceName または srcPortName を使用してください。weblogic.xml.crypto.wss および weblogic.xml.crypto.wss.provider パッケージ内のクラスとメソッドは次に示します。weblogic.xml.crypto.wss.SecurityTokenContextHandler クラスweblogic.xml.crypto.wss.provider.SecurityToken の java.lang.Object getCredential() メソッド weblogic.xml.crypto.wss.provider.SecurityToken の java.security.Key getSecretKey() メソッド weblogic.xml.crypto.wss.provider.SecurityToken の java.security.PrivateKey getPrivateKey() メソッド weblogic.xml.crypto.wss.provider.SecurityToken の java.security.PublicKey getPublicKey() メソッド weblogic.xml.crypto.wss.provider.SecurityToken の void setId(java.lang.String) メソッド
WebLogic FilteringClassLoader を使用すると、デプロイメント記述子をコンフィグレーションすることで、システム クラスローダを使用してロードされるのではなく、常にアプリケーションからロードされるパッケージを明示的に指定できます。『WebLogic Server アプリケーションの開発』の「フィルタリング クラスローダの使用」を参照してください。
移行とクラスタ化に関連する以下の機能がこのリリースで追加されました。
| 注意 : | サーバの移行は、どのプラットフォームでもサポートされているわけではありません。詳細については、『WebLogic Platform 9.2 でサポート対象のコンフィグレーション』の「サーバの移行のサポート」を参照してください。 |
このリリースでは、HP-UX プラットフォーム コンフィグレーションでのサーバの移行がサポートされています。
シングルトン サービスの自動的な移行機能によって、シングルトン サービスの自動的な状態モニタと移行が可能になります。シングルトン サービスとは、クラスタの内部で動作し、常に 1 つのサーバ上でのみ使用可能になる、ユーザ定義のサービスです。
移行可能サービスが何らかの理由 (たとえば、サービス コード内のバグ、サーバの障害、ネットワークの障害など) で失敗したり使用できなくなった場合、そのサービスは現在の場所で非アクティブ化されて、新しいサーバ上でアクティブ化されます。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「シングルトン サービスの自動移行」を参照してください。
データベースでは、サーバ移行時に使用されるリース情報を格納する必要はなくなりました。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「サーバおよびサービスの移行について」を参照してください。
ジョブ スケジューラ機能は、クラスタ化環境で使用できる commonj.timer API の実装です。ジョブ スケジューラを使用すると、クラスタ全体のタイマーに、クラスタ内の各サーバを含む他の JVM を認識させることができます。そのため、ロード バランシングやフェイルオーバを実行できます。ジョブ スケジューラの使用の詳細については、『Timer and Work Manager API (CommonJ) プログラマーズ ガイド』の「ジョブ スケジューラの使用」を参照してください。
Web アプリケーション、サーブレット、および JSP には、以下の節で説明する新機能と変更点があります。
標準の共有 J2EE アプリケーションをアプリケーション ライブラリとして WebLogic Server にデプロイできるのと同様に、標準の Web アプリケーションを Web アプリケーション ライブラリとして WebLogic Server にデプロイし、他の Web アプリケーションがこれらのライブラリを参照できるようにすることが可能です。これらの Web アプリケーション ライブラリを Web アプリケーションで参照する方法については、『WebLogic Server アプリケーションの開発』の「Web アプリケーションにおける Web アプリケーション ライブラリの使用」を参照してください。
3 つの JSF (JavaServer™ Faces) および JSTL (JSP™ Standard Tag Library) パッケージが Web アプリケーション ライブラリとして WebLogic Server にバンドルされています。これらのライブラリは、JSF または JSTL 機能を使用する標準の Web アプリケーションから参照できます。
リリース 9.2 では、以下の 3 つのパッケージを Web アプリケーション ライブラリとして使用できます。
汎用プロキシ サーブレットを使用する場合、KeyStore 初期化パラメータを定義すると、独自の ID 証明書およびキーで双方向 SSL を使用できます。詳細については、以下のマニュアルを参照してください。
Servlet 2.4 仕様では、Web アプリケーションで使用する認証方法 (基本、フォーム、その他) を定義できます。WebLogic Server 9.2 は auth-method セキュリティ モジュールを提供しています。このモジュールを使用すると、複数の認証方法を (カンマ区切りのリストとして) 定義できるため、コンテナはフォールバック メカニズムを提供できます。認証は、auth-method リストで値が定義されている順序で試行されます。
『WebLogic Security プログラマーズ ガイド』の「認証方法に対するフォールバック メカニズムの提供」を参照してください。
一般的に、WebLogic Server が着信する HTTP リクエストを処理すると、応答は即座にクライアントに返されます。そのような接続は、同じスレッドによって同期的に処理されます。しかし、一部の HTTP リクエストでは、より長い処理時間が必要となることがあります。これらのリクエストの同期的な処理では、そのリクエストが処理されて応答が送信されるまで待機が行われ、スレッドが保持されます。この状況を回避するため、WebLogic Server では、着信するリクエストを処理するスレッドから応答を切り離すことによって、HTTP リクエストを非同期に処理する、2 つのクラスが用意されています。
『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「HTTP サーブレットの将来的応答モデル」を参照してください。
weblogic.http.session.maxConcurrentRequest プロパティが追加され、セッションに対する同時リクエストの数を制限できるようになりました。特定のセッションに対する同時リクエストの数が指定した値を超えると、サーブレット コンテナによるリクエストの拒否が開始されます。このプロパティは、デフォルトでは -1 に設定されており、サーブレット コンテナによる制限は課されていません。
FileServlet の docHome パラメータは非推奨になりました。代わりに仮想ディレクトリを使用してください。
WebLogic Server では、次の 2 つのバージョンの Spring Framework を使用するアプリケーションのデプロイメントと使用をサポートしています。
詳細については、「Spring アプリケーション リファレンス」を参照してください。
WebLogic Tuxedo Connector には、以下の節で説明する新機能と変更点があります。
Tuxedo キュー ブリッジは WebLogic Tuxedo Connector の一部であり、Tuxedo アプリケーション環境と通信する WebLogic Server アプリケーションのために双方向 JMS インタフェースを提供します。環境間でのメッセージングの転送は、クライアント アプリケーションに代わってサービスを呼び出すために使用される、テキスト、バイト、または XML データ ストリームを含む JMS ベースのメッセージで構成されます。
動的コンフィグレーションがサポートされるようになりました。WTC がアクティブ化され、Tuxedo キュー ブリッジが非アクティブ化されている場合、以下のような追加と変更が可能です。
WTC キュー ブリッジの詳細については、『WebLogic Tuxedo Connector 管理ガイド』の「Tuxedo キュー ブリッジのコンフィグレーション方法」を参照してください。
このリリースでは、WTC パフォーマンスが以下のように向上されています。
『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic Tuxedo Connector のチューニング」を参照してください。
weblogic.apache.xerces.* クラスは、WebLogic Server のリリース 9.1 以降では非推奨になりました。
すべての weblogic.apache.* パッケージ内のクラスはすべて、WebLogic Server リリース 9.2 以降では非推奨になりました。
BEA 独自のクラスを使用する代わりに、http://xerces.apache.org/xerces-j/ からダウンロードできる同等の org.apache.* クラスを使用します。これらのクラスは、com.sun.org.apache.* パッケージ内の JDK にも入っています。
このリリースの WebLogic Server は以下の標準をサポートしています。
  
|
