ミッション・クリティカルなIT基盤
「BEA WebLogic Server 8.1J」（2）

（1）セキュリティ強化

　最近、Webサービスに関するホットな話題の1つに「セキュリティの強化」がある。Webサービス機能を実装しているアプリケーションサーバのほとんどは現在、トランスポートセキュリティ（SSLや基本認証）をサポートしており、独自にメッセージベースセキュリティ（メッセージそのものにセキュリティをかける）を実装している製品も一部登場した。

　WLS8.1Jが採用したセキュリティ技術は、BEA、マイクロソフト、IBMなどを中心とした標準化団体「OASIS」で標準化仕様を策定中のWS-Security（2002年8月バージョン）である。WS-Securityの仕様にもとづいて、SOAPメッセージにセキュリティ・メカニズムを付加することで、「XML暗号化（メッセージ本文の暗号化）」「XML署名（送り元の確認、メッセージの完全性の確認）」「ロール・ベース・セキュリティ（指定したロールを持つユーザのみWebサービス全体または一部を実行）」の機能が使用可能になった（図1）。

図1 Webサービス セキュリティ

（2）高信頼性SOAPメッセージング

　Webサービスの「疎結合」のメリット、デメリットを論じる際のテーマの1つに、「クライアント／サーバ間のメッセージの信頼性をどのように実現するか」という課題が出てくる。WLS8.1Jでは、高信頼性SOAPメッセージング機能を実装することでこの課題に対する解とした。
　
　この機能は、「クライアントからの要求をサーバに確実に1回だけ届けたい」という要件に対して、WLS8.1Jの送信側でメッセージをメッセージストアに保管し、受信側においても要求が2回以上処理されないようにメッセージID（SOAPヘッダを利用して送受信）を管理するテーブルを持つことで実現されている。アプリケーション要件により、3種類のメッセージ送信ポリシー（必ず1回のみ、少なくても1回、順番に）を選択できる。受信側のサーバ障害またはネットワーク障害が発生した場合でも、送信側のハンドラが受信側からの受諾メッセージを受信するまで再送を繰り返す（リトライ回数、間隔は設定可能）。また、送信側に障害が発生しても、ローカルのデータストアに送信メッセージが保存されているので、送信側サーバが再起動された後で、ハンドラが自動的に再送信を行う（受信側で設定した期限切れ時間に達するまで）。このような複雑なメカニズムを開発者は意識することなく、しかもアプリケーション側の開発はシンプルで、かつ高信頼性アプリケーションを容易に構築できるのである（図2）。

図2 高信頼SOAPメッセージング

　Webサービスに関するこれらの機能は、（Webサービスを利用する）企業システムを構築する際には不可欠の機能であり、WLS8.1JはエンタープライズレベルのWebサービス機能を実装した最初のアプリケーションサーバと言える。

　WLS7.0において、「JMSクラスタリング機能（分散送り先機能によるロードバランシング）」「JMSマイグレーション（障害時にJMSキューを別のJMSサーバからアクセス可能にする機能）」が実装されたが、WLS8.1Jでは、JMSに関するさまざまな条件にも耐えられるような次の機能が拡張された。

（1）期限切れメッセージ処理

　JMSキュー上に保留されている期限切れメッセージを（あらかじめ設定した）スキャン間隔（Expiration Scan Interval）でタイムリーに処理（削除、ロギング、エラー送り先に転送：選択可能）できるようになった。これにより、期限切れメッセージの処理をアプリケーションが個別に処理する手間が省け開発の生産性が高まる。

（2）再配信の順序保証

　特定のプロデューサから特定のコンシューマに配信されたすべてのメッセージは、メッセージが作成された順番で受信されることが保証されている。WLS7.0では、トランザクションロールバック、Session.recover（）の呼び出し後の再配信順序は保証されていなかった。WLS8.1では、特定の条件（単一コンシューマ、メッセージ駆動型Beansインスタンス数が1でなければならないなど）において障害発生後に再配信が行われてもメッセージの順番は保証される機能が追加された。

（3）送信ブロッキング機能

　メッセージ送信時にあらかじめ指定した送り先のリソース状況（空き容量）をチェックする機能が追加された。空き容量が十分でない場合は、送信タイムアウト時間（SendTimeout）が経過するまで、送信側がブロック（送信の優先順位ポリシー：FIFOまたはPreemptiveの指定が可能）される。この機能により、従来、送信側が（受信側の空き容量が十分になるまで）定期的にリトライしていたアプリケーションロジックが不要になり、開発の負担が減り、性能向上につながる。
　
（4）ファイルストアの書き込みポリシー

　ファイルストアを使用する場合に3つのwriteポリシーが設定可能になった。アプリケーションの要件により個々に選択できる。

• Disabled：最速、信頼性が低い
  
• Cache-Flush：デフォルト、信頼性、スケーラビリティともに高い
  
• Direct-Write：ネイティブコードで実現、性能はハードウェア、OSに依存

（1）J2EEモジュールのカスタムクラスローディング

　WLS7.0までは、アプリケーションがデプロイされた時にクラスローダの階層が自動的に作成された。EARファイルであればルートクラスローダにEJB JARファイルがロードされ、次に子供のクラスローダにそれぞれWARファイルがロードされた。WebアプリケーションはEJBを呼ぶ際に、親のクラスローダにEJBインタフェースを見つけることができ、WebアプリケーションはJARファイルを再デプロイせずに再デプロイできる。WLS8.1Jでは、アプリケーション開発者がクラスローダの階層をデプロイメントデスクリプタで定義できるようになった。これにより、細かい制御を行うことができる（図3）。

<classloader-structure>     <module-ref><module-uri>ejb1.jar</module-uri></module-ref>     <module-ref><module-uri>web3.war</module-uri></module-ref>     <classloader-structure>           <module-ref><module-uri>web1.war</module-uri></module-ref>     </classloader-structure>     <classloader-structure>         <module-ref><module-uri>ejb1.jar</module-uri></module-ref>         <module-ref><module-uri>web2.war</module-uri></module-ref>         <classloader-structure>             <module-ref><module-uri>web4.war</module-uri></module-ref>         </classloader-structure>         <classloader-structure>             <module-ref><module-uri>ejb2.jar</module-uri></module-ref>         </classloader-structure>     </classloader-structure> </classloader-structure>

図3 クラスローダデプロイメントデスクリプタ（上）とクラスローダ構成図（下）

（2）アプリケーションライフサイクル

　これは、アプリケーションのデプロイ、アンデプロイ、再デプロイのタイミングで、開発者が何らかの処理を行いたい場合に有効な機能である。WLS8.1Jは、アプリケーションライフサイクルイベントとして次のイベントを提供する。

• Prestartイベント（プリペアフェイズの始まり、アプリケーションデプロイ処理の開始状態、接続プールの確立などに利用）
  
  
• Poststartイベント（アクティブフェイズの終わり、アプリケーションデプロイ処理の終了状態、アプリケーションはデプロイされた）
  
  
• Prestopイベント（非活性化の始まり、アプリケーションアンデプロイ処理の開始状態、データベースの切断などに利用）
  
  
• Poststopイベント（削除フェイズの終わり、アプリケーションアンデプロイ処理の終了状態）

　開発者はApplicationLifecycleListner抽象クラスを継承し、クラスを作成する、つまり、preStart（）、postStart（）、preStop（）、postStop（）メソッドを実装し、application.xmlの<listner>要素にクラス名とJARのURIを指定する。別にサーバの起動時と停止時に呼び出されるmain関数を持ったクラスをそれぞれ<startup>要素もしくは<shutdown>要素にも記述することも可能である。

（3）デプロイメントモニター機能

　JMX通知およびフィルタ機能を利用してデプロイメント中の実行経過をモニタしたり、アプリケーションやモジュールレベルでの変更を知ることができるようになった。変更通知用のリスナーをApplication MBeanに登録し、フィルタ（DeploymentNotificationFilter）に通知されるべき範囲（デプロイメントに関する情報すべて、アプリケーションまたはモジュールレベルの変更通知、指定したターゲットに関連する通知のみ）を指定できるので目的に応じた情報を監視できる。Config MBeanでの登録はローカルサーバ上のアプリケーションに通知され、Admin MBeanでの登録はドメイン内のアプリケーション全体に通知される。

（4）アプリケーションクラスライブラリ

　アプリケーション内の異なるモジュール間で共有できるクラスを容易に解決するために、WLS8.1Jでは、APP-INF/libおよびAPP-INF/classesディレクトリが用意された。開発者は、APP-INF/lib の下にクラスライブラリ(.jarファイル)、APP-INF/classesに個々のクラスファイルを追加できる。アプリケーションクラスローダがこれらのクラスをローディングすることにより、すべてのアプリケーションモジュールは共有クラスにアクセスできる。

（5）代替デプロイメントデスクリプタ

　EARアプリケーションパッケージに含まれるデプロイメントデスクリプタの代替ファイルを利用できる機能が追加された。単一のEARファイルの同じモジュールをいくつかのアプリケーションタイプで使い分けしたい場合、単一のEARファイルでそれぞれレベルごとの振る舞いをさせたい場合など、weblogic.Deployerオプションの-altappd、-altwlsappddで代替デプロイメントデスクリプタを指定するだけで再デプロイせずに単一のEARに「異なる振る舞い」をさせることができる。

（1）appcツール

　WLS7.0までは、J2EEアーカイブのコンパイルと検証をejbc、jspcでそれぞれ行っていたが、WLS8.1Jでは、統一したツールappcが提供されている。appcは適切なサブシステムを呼び出し、個別のモジュールに対するアプリケーションレベルのデプロイメントデスクリプタのチェックと、モジュール全体の検証チェックをデプロイメント前に実行する。

（2）EJBの再デプロイ

　上述の「3.（1）カスタムクラスローディング」に関連するが、WLS8.1Jでは、EJBモジュールの再デプロイ機能が拡張された。これまでは、EJB実装クラスを変更した場合に、そのEJBモジュールにかかわるすべて（他の実装クラス、ユーティリティクラス）を再ロードする必要があったが、WLS8.1Jでは、クラスローダの改良により、変更したEJBモジュールだけを再ロードできようになった。再ロードの粒度を個々の実装クラスのレベルまで指定できるので、アプリケーションプログラムのバージョンアップがこれまで以上に効率良くできるようになった。

（1）管理コンソールの操作性向上

　管理コンソールは、管理者が見やすく理解しやすくなるように全面的に再デザインされた。実行時の情報に基づいて管理者がどうすべきか決定する手助けとして詳細なヘルプメッセージが提供されている。例えば、EJBのモニタ機能は、EJBごとに現在のプール情報、アクセス状況、キャッシュ統計、トランザクション統計など詳細な情報を提供する。情報は現在の値と比率として表現されるので、管理者はこの実行時情報を基にパフォーマンスチューニングのヒントを得ることができる。また、ログに書かれたメッセージ番号をクリックするだけでメッセージの詳細情報（説明、対処方法など）を簡単に見ることができるので、障害分析の大幅な効率アップにつながる。アプリケーションをデプロイする際に、（パフォーマンスチューニングに関連する）デプロイメントデスクリプタを直接編集できるので、関連するモジュールの再パッケージ化や再デプロイを効果的に行うことができる。また、WebLogic Builderを利用することで、さらに詳細にデプロイメントデスクリプタを編集できる（図4）。

図4 EJBパフォーマンスモニタリング（クリックすると拡大）

（2）BEA WebLogic JRockitとの統合

　WLS8.1Jは、SUN JDK1.4またはWebLogic JRockit8.1で動作する。JVMとしてJRockitを使用している場合、管理コンソールとJRockitの統合機能を享受できる。これは、JrockitRuntime MBeanがJRockit固有のコンソールアプリケーション管理用APIを使用して実装されているので、管理コンソール、weblogic.Adminコマンド、JMXプログラミングを通じてJRockitの物理メモリの情報、ヒープサイズ情報、GCアルゴリズム、GCの各種情報、メソッド情報、タイミング情報、スレッド情報、CPU情報など詳細な情報を取得できるためである。管理者は管理コンソールを使用して、JVMとアプリケーションサーバの稼働状況を同時に把握することができる。

（3）管理ツール

　WLSの管理単位はドメインであり、その中に複数のクラスタ環境を構築できる。これまでのweblogic.Admin管理ツールにはクラスタ単位の操作用のサブコマンドが不十分であったが、WLS8.1では、下記のように新規コマンドが追加された。

　また、MBeanに精通していない開発者または管理者が、管理コンソール以外の方法で（weblogic.AdminコマンドやJMXプログラミングに頭を悩ませず）管理コマンドを実行できるように、以下の3つのAntタスクが提供されている。

　開発者、管理者は要件により、管理コンソール、weblogic.Adminコマンド、Antタスクを選択でき、より効果的な運用管理を行うことができる。

（4）シャットダウン（停止）操作

　稼働中のサーバを停止する際に、仕掛中の処理の完了を待って終了したい（仕掛中の要求を中断したくない）要求が出てきた場合、WLS8.1Jでは、管理者は正常シャットダウンと強制シャットダウンの2タイプを選択できる。正常シャットダウンはサーバをシャットダウンする際に、仕掛中の作業があるかどうかをチェックする。トランザクション処理中、HTTPのレプリケーション処理中、JMSの処理中、MDBが一時停止中などの仕掛中の作業があれば、その作業の完了までシャットダウン処理は一時停止する。タイムアウト値を設定し超過した場合に強制シャットダウンに移行するオプションも選択できる。

（5）config.xmlの自動アーカイブ

　管理サーバは、コンフィギュレーションが変更されると、ドメインのconfig.xmlの古いコピーを自動的にアーカイブする。デフォルトでは最近バージョンを5つまで保存する。万一の障害時のリカバリに有効な機能だ。

（1）ラストエージェントコミット最適化

　最近、特に企業内の既存システムを統合して全社のデータ、プロセス統合を目的とするプロジェクトが増えている。システム分析を進める中でXAに準拠したリソースと非XAリソースを1つのトランザクションで制御する要件が出てきた。WLS8.1Jでは2フェイズコミットのラストエージェントコミット最適化手法を実装した。これは、１つ以上のXAリソースと１つの非XAリソースを同一のグローバルトランザクションとして制御する機能である。非XAリソースはローカルトランザクションのセマンティクスをサポートするリソースでなければならない。トランザクションマネージャは下記のプロトコルを実行する。

1. XAリソース参加者に対してprepare
   
2. 非XAリソース参加者をコミット
   
3. トランザクションログに1フェイズ目の完了を書き込む
   
4. XAリソース参加者に対してcommitを発行

　2フェイズ目で障害が発生した場合は、リソース間で不整合状態になる可能性があるので、アプリケーションレベルでリカバリする手順、トランザクション保証リカバリ用プログラム（Compensation Recovery）を検討する必要がある。また、WLS8.1Jのトランザクションマネージャは、XA操作を並列に処理（オプション指定）できるので、2フェイズコミットのパフォーマンスが向上した。

（2）放棄タイムアウト（Abandon timeout）

　WLS7.0までは、JTA Configuration MBeanのTimeoutSecondsでトランザクションタイムアウトを設定していた。これは、トランザクションが開始され1フェイズ目の完了（トランザクションログの書き込み）までのタイムアウト管理のために使用できる。ただし、2フェイズ目に障害が発生した場合はタイムアウトの対象にならないので、TimeoutSecondsは使用できない。このためにWLS8.1JからAbandonTimeoutSecondsが追加された。JTAサブシステムはサーバ毎にこの値（デフォルトは24時間）を経過したトランザクションをクリーンアップし、ヒューリスティックエラーをログに書き込んで関連するリソースを開放する。

（3）手動トランザクション解決

　24時間365日間無停止で動作しているアプリケーションにおいて、障害により、トランザクションコーディネータがタイムリーにトランザクションを解決できない場合に備えてトランザクションを手動でコミットまたはロールバックする機能が必要になった。WLS8.1Jでは、JTA Runtime MBeanの中に次の4つのAPIが追加された。

　管理者は、管理コンソール、管理ユーティリティから容易にこれらの操作を行うことができる。

（1）RowSetサポート

　ResultSetのJDBC2.0拡張機能であるRowSetがWLS8.1でサポートされた。RowSetがpopulateされた後、接続は開放される。キャッシュされたクエリ結果の読み込みや変更を行ったり、変更の一貫性を保証するために楽観的同時実行（Optimistic concurrency）制御が行われ、データベース側でデータが変更されていた場合には例外が送出される。

（2）JDBC接続プール

　堅牢なシステム構築を行う際に必要なJDBC接続プールに関するいくつかの拡張要求が出てきた。WLS8.1Jでは管理コンソールまたはMBeanから動的にアクセスできる下記の属性が追加された。

　WLS7.0までは、Private Key、Trusted CAはJDKのKeyStoreに保存されたが、Sever Certificateはフラットファイルであった。WLS8.1では、Server CertificateもKeyStoreに含めることができ、KeyStoreパラメータはサーバのMBean属性を使用して設定できるようになった。また、nCipher JCE（Java Cryptography Extension）およびSUN JCEをサポートしている。

　WLS7.0までは、クライアントマシン上にWLS配布キット全体（weblogic.jarおよびweblogicaux.jar）をインストールする必要があったが、WLS8.1Jでは、Thinクライアントに必要な機能だけ含む下記の.jarファイルが提供された。クライアントマシン上のWLSの容量を大きく削減できる。

（1）セキュリティ

　セキュリティ面で、BEA Tuxedo 8.1Jとの連係が強化された。WLSの組み込みLDAPの情報をTuxedo 8.1J認証サーバで使用できるので、WLS8.1JとTuxedo8.1J間でセキュリティ管理の単一ソースを作成できる。

（2）非同期呼び出し

　非同期のtpacallメソッドがサポートされた。Tuxedoサービスに要求を送信してから、スレッドプールへの呼び出しを実行したスレッドを解放できるので、大量の要求を少数のスレッドで処理できスケーラビリティが向上する。

◆

　これまで説明してきたように、WLS8.1Jで拡張された機能の中には、WLS7.0までの実際のシステム開発の現場からの要求が数多く存在する。WLS8.1Jは、単にWLS7.0に対する性能（WLS7.0より平均30％高速）および品質の向上（度重なる機能テスト、統合テスト、ユーザーサイトでのベータ版評価プロジェクトなど）を実現しただけではない。ミッションクリティカルな企業システムを構築するためのインフラストラクチャとして、アプリケーションサーバが実装すべき機能をアプリケーション開発者、運用管理者の視点に立ち徹底的に議論した中で新たに強化すべき機能を洗い出し、実装を積み重ねたメジャーバージョンアップであることを強調したい。WLS8.1Jは「現場の一線で活躍するエンジニアの声」を的確に反映した最も円熟している高信頼性、高性能のアプリケーションサーバであり、BEA WebLogic Platform8.1J（今夏出荷開始予定）のコアエンジンである。是非、WLS8.1J評価版をダウンロードして実際に体験していただければ幸いである。