[製品紹介]

Webサービスを始めとする統合と相互運用性を強化

WebLogic Server 7.0


佐々木政和
日本BEAシステムズ

2002/11/2


内容
統合および相互運用性
強化されたセキュリティの機能

運用管理の充実
パフォーマンスの向上
EJBに関する改良点
高可用性の実現
開発生産性の向上

 BEA WebLogic Server 7.0(以下、WLS 7.0)は、WLS 3.1リリース以降、4回目のメジャーバージョンアップになります。J2EE 1.3の仕様に完全準拠したほか、企業アプリケーションシステム構築のベースとなるWebアプリケーションサーバ基盤として、信頼性、拡張性、相互運用性などがさらに強化され、性能も向上しました。ここでは、WLS 7.0の新機能を以下の項目に分類して説明します。

  1. 統合および相互運用性
  2. セキュリティの強化
  3. 運用管理の充実
  4. パフォーマンスの向上
  5. EJBに関する改良点
  6. 高可用性の実現
  7. 開発生産性の向上

   統合および相互運用性

 企業アプリケーションシステムを構築する際の課題に、既存システムとの「統合」があります。企業内および企業間のさまざまな既存システムをシームレスに統合し、業務データの交換、連携を簡潔に行わなければならないという要求です。このことから、Webアプリケーションサーバは、アプリケーション開発に負担(コストおよび時間)をかけずに、既存のIT技術投資を最大限に活用する仕組みを提供する必要があります。もちろん、将来の業務拡張による統合の変更に備えた拡張性のある信頼性の高い統合方法でなければなりません。ここでは、WLS 7.0のシステム間統合および相互運用性に関してWebサービス、Microsoft環境、CORBA、EIS、メッセージング連携に分類して説明します。

Webサービスでの統合
 Webサービスは、複数の会社間あるいは部門間で疎結合型アプリケーションを構築する際に有効な手段です。WLS 7.0で提供されているWebサービス機能は、Microsoft .NETを含む主要なWebサービスと相互運用でき、Webサービスに関する必要な機能はすべて実装されているため、サードパーティ製のWebサービス製品は必要ありません。WebアプリケーションサーバにおいてWebサービスを利用する場合、クライアント側とサーバ側の2通りのパターンに分けて、それぞれの機能を説明すると分かりやすいでしょう。WLS 7.0では、クライアント開発者がWebサービスを利用するための仕組み(クライアント側)と新規または既存のJ2EEアプリケーションのビジネスコンポーネントをWebサービス層で自動的にラッピングする仕組み(サーバ側)を提供しています。それぞれ図を用いて説明します。

図1 クライアント側のWebサービスを利用する仕組み
図2 ビジネスコンポーネントをサーバ側でラッピングする仕組み

 WLS 7.0のWebサービス機能はアプリケーション開発者に次の利点を提供します。

  1. SOAP、XMLを意識せずにWebサービスのサーバ側ビジネスロジックを作成
    EJBもしくはJavaクラスを自動的にWebサービス化するAntタスクが提供されました。これにより、既存のEJBをWebサービスとしてアクセスできます。

  2. SOAPメッセージレベルで編集処理を行うためのSOAPハンドラの提供
    SOAPハンドラは、SOAPメッセージに対して直接的な処理を行うために効果的です。メッセージ内で任意にセキュリティを設定、SOAPヘッダのカスタマイズ、同じパラメータ処理のためにキャッシュの利用などに活用できます。

  3. ユーザー定義型データが定義可能
    シリアライザ/デシリアライザにおいてユーザー定義型データを変換するために、Javaデータ型からXMLスキーマ、またはXMLスキーマからJavaデータ型のマッピング情報を自動作成するAntタスクが提供されました。これにより、任意のユーザー定義型データのJava/XML間での変換処理を簡単に行うことができます。

  4. EARファイルにパッケージされたデプロイ
    Webサービス関連の必要なJavaクラスはすべてEARファイルにパッケージされるのでデプロイが容易になりました。

J2EE CA(EIS連携)
 J2EE Connector Architecture 1.0(以下、J2CA 1.0)はJ2EE 1.3におけるEAI(Enterprise Application Integration)の仕様で、アプリケーションサーバが、ERP、CRM、SCMパッケージなどの既存のアプリケーションを統合するための標準規格です。この仕様では、アプリケーションサーバとリソースアダプタ間の取り決めであるシステムコントラクト、およびアプリケーションコンポーネントとリソースアダプタ間のクライアントAPIを規定しています。WLS 6.1はJ2CA 1.0の最終版前の仕様で実装されていましたが、WLS 7.0は最終版に準拠して実装されています。WLS 7.0では、J2CA 1.0リソースアダプタのクラスローディングの変更(CLASSPATHの設定が不要)、コネクションリークの自動検出とクリーンアップ機能、コネクションの状態監視や動的な削除ができるコネクションモニタリング機能、リソースアダプタのセキュリティポリシーの設定が強化されました。これにより、堅牢な信頼性の高いリソースアダプタを開発し実行できるようになりました。

JMSメッセージングブリッジ(JMS/MOM連携)
 JMSとIBM MQSeriesなどの各種のメッセージングプロバイダ製品を容易に連携するメッセージングブリッジ機能が提供されました。JMSからMOM製品(あるいはその逆)にメッセージを送信する場合にアプリケーションプログラムがMOM製品(JMS)を意識する必要がありません。

 メッセージングブリッジはメッセージングプロバイダごとに提供されるアダプタ間(ソースデスティネーションとターゲットデスティネーション間)の通信を行います。アダプタはコネクションプール、セキュリティ管理、トランザクション管理のようなJ2EEコンテナが提供する機能と連携することができます(J2EE CA準拠)。初めに管理コンソールから、各デスティネーションとアダプタの関連付けを行います。デスティネーションごとに、デスティネーション名、アダプタのJNDI名、アダプタのクラス名、アダプタに渡すプロパティを設定します。その後、管理コンソールからメッセージングブリッジの設定を行います。この設定メニューには、ソースデスティネーション、ターゲットデスティネーション、フィルタセレクタ、QoS(Quality of Service)、非同期の使用(有無)、トランザクション使用(有無)、再接続パラメータ(異常時のフェイルオーバー対応)があります。WLSのJMS用のアダプタには、XAリソースにアクセスするためのもの、非トランザクションのものがそれぞれ用意されています。このメッセージングブリッジの機能により、ソースデスティネーションに送信されたメッセージは自動的にターゲットデスティネーションに転送されます。アプリケーションはMOM製品の違いを意識する必要はありません。なお、MQSeriesと連携するためのアダプタがリリースされています。

CORBAとの連携(RMI over IIOP)
 WebLogic ServerとCORBAの連携は、WLS 5.1以降に順次機能強化されているRMI over IIOPを通じて行われます。RMI over IIOPはIIOPプロトコルを介してJavaのリモートメソッド呼び出し(RMI)を行うプログラミングモデルで、さまざまな言語環境のCORBAクライアントから、WLS上のRMIオブジェクトをアクセスすることを目的にしています。WLS 7.0では、J2EE 1.3およびEJB 2.0の規格で新たに定義されたCORBA連携関連の仕様を実装しています。この実装および独自の付加機能として、外部ORBとのトランザクション連携、標準プロトコルによるセキュリティコンテキスト伝播、外部ORBとWLS相互のクライアント識別子の伝播、動的なIIOPスタブコード生成、WLS上でのIIOPクライアント機能が提供されています。また、OTS(Object Transaction Services)1.2、CSIv2(Common Secure Interoperability v2)がサポートされています。

   セキュリティの強化

セキュリティフレームワーク&サービスプロバイダ(プラグイン機能)
 eビジネスアプリケーションにおけるセキュリティの要求レベルはますます厳しくなっています。Webアプリケーションサーバの観点からは、最新のセキュリティ関連製品と連携すること(最新のセキュリティ技術の利用)、アプリケーションロジックからセキュリティAPIを分離すること(プログラミングと管理を分離)など、ユーザーがセキュリティ製品を自由に選択できる仕組みを提供することが必要になっています。

 WLS 7.0では、これらの課題をクリアするためにセキュリティプラグイン機能が提供されました。Javaにおける認証、認可に関するセキュリティの標準規格は、JAAS(Java Authentication and Authorization Service)に定められており、最新バージョンはJAAS 1.0です。JAASより、さらに拡張性の高いセキュリティフレームワークを提供しています。これは、各セキュリティサービスをモジュール単位に分割することにより、モジュールごとにさまざまなセキュリティ製品(ベンダに依存しない)を利用可能にするためのフレームワークです。各モジュールに必要なインターフェイスはSSPI(Security Service Provider Interface)として公開されており、ユーザーが独自に開発することも可能です(セキュリティプロバイダは、SSPIを使用して、それぞれセキュリティ関連製品を開発します)。また、独自に実装しているLDAPとサードパーティ製のLDAPを選択できます。

ロール&ポリシーの設定方法
 WLS 7.0では認可の管理面の柔軟性が向上しました。ロールの宣言、割り当て管理はWLS 6.1ではデプロイメントディスクリプタで行っておりファイル修正後にアプリケーションのリデプロイが必要でした。WLS 7.0では、これらの変更は管理コンソールを利用して行います。これにより、変更部分が動的に反映され管理効率が向上します。

   運用管理の充実

 アプリケーションシステムの規模が大きくなるほど、充実したデプロイ、運用管理機能が必要になります。管理コンソールは、ドメイン(運用管理の単位)、クラスタ(ロードバランシング、フェイルオーバーの単位)、サーバ(複数のWLSインスタンス可能)の数々のパラメータを設定したり監視したりするためのアプリケーション管理の中核となるツールです。WLS 7.0では、各種の統計情報、性能値、システム稼働情報を報告したり、デプロイ済みのコンポーネント監視、セキュリティフレームワークの設定、トランザクション管理などを行うため、またWLS 7.0新機能に関連する多くのメニューが追加されました。

サーバライフサイクル
 Webアプリケーションサーバの動作状態について新しい状態が追加されたためにサーバライフサイクルという概念が生まれました。WLS 6.1までは、停止状態(JVMが停止状態)と実行状態(デプロイされたすべてのサービスが実行中で、クライアントからの要求を受け付け、順次処理している状態)の2種類しかありませんでした。WLS 7.0では、スタンバイ状態を設定しました。この状態は、サーバの初期化作業が完了し、クライアントからの新規要求を受け付けない状態です。

ノードマネージャ
 WLS 7.0で導入されたサーバライフサイクルの拡張に伴って、管理コンソールのノードマネージャ操作メニューが大幅に拡張されました。また、weblogic.adminコマンドおよびMbeanインターフェイスを利用した操作が可能になりました。

セルフヘルスチェック
 Webアプリケーションを構成するサーバノード、各種のサブシステムの状態を監視し、その状態によってあらかじめ設定した運用を自動化する目的で、セルフヘルスチェック機能が提供されています。デフォルトではJMSサブシステム、JTAサブシステムのセルフチェックを設定でき、任意のサブシステムの登録/削除が可能です。また、ノードマネージャと組み合わせることで管理対象サーバの強制終了やリスタート制御が可能になります。

アドレス設定
 WLSインスタンスに対して、複数のネットワークアドレスおよびリスンポートを指定できるようになりました。これは、各アクセス経路のチューニング、ネットワーク冗長性のために有効です。管理コンソールで、ネットワークチャネルとネットワークアクセスポイントを設定できます。複数のサーバ構成を設定する際に効果的な運用を行うことができます。

   パフォーマンスの向上

 WLS 7.0はパフォーマンスの向上のために数々の機能を提供しています。これらはネットワーク、データベースアクセス負荷を削減することにより実現されています。次に説明する機能を効果的に利用することで、アプリケーション全体のパフォーマンスを上げることができます。

レスポンスキャッシング
 WLS 6.1以降、JSPのカスタムタグライブラリ(cacheタグ)を利用してタグで囲った中で使用される変数がメモリ上にキャッシュされる機能を提供しています。キャッシングにより不要なメッセージの通信が最小化され全体のパフォーマンスが向上します。WLS 7.0で新規に追加されたレスポンスキャッシングは、これをページ単位にキャッシングできる仕組みで、Servlet 2.3で策定されたサーブレットフィルタ機能を利用しています。JSPに設定する代わりにWebアプリケーションの定義(web.xml)でパラメータを宣言します。またメモリ不足を防止するために、メモリ要求に応じてガベージコレクタの判断でクリアされるソフト参照オブジェクト(ソフト参照)を使用しています。キャッシュのフラッシュのタイミングは、タイムアウトおよびJSPタグによって指定できます。タイムアウトは、スコープ指定(request、session、Application、cluster)、キー指定、変数ごとの指定、ユニークキーのサイズ制限をデプロイメントディスクリプタ上に、それぞれパラメータとして設定することができます。JSPタグは、アプリケーションプログラムから明示的にキャッシング情報をフラッシュしたい場合に有効です。

ブラウザでのキャッシング
 静的コンテンツデータの通信量を減らすために、ブラウザのキャシュ情報を利用する仕組みです。HTTPレスポンスヘッダ内のフィールドのタイムスタンプを自動的に比較することにより、ブラウザでキャッシュされているドキュメントを再表示する機能が提供されています。

   EJBに関する改良点

エンティティBean
 エンティティBeanに関して、WLS 6.1までのEJBコンテナはペシミスティックロック(悲観的排他ロック)のみでしたが、WLS 7.0はオプティミスティックロック(楽観的排他ロック)もサポートされるようになりました。トランザクション内でロックする時間を最小にするために、コンテナは最終的にデータを更新する時点で、ほかのユーザーが同一データを変更していないことを確認して、実際のデータ更新を行います。変更されている場合は例外を送出しロールバックします。当然、コンテナの作りは複雑になりますが、同時並行性を最大限に生かす実装により全体のパフォーマンスは向上します。

 WLS 6.1ではエンティティBeanはデータベースで排他ロックを行い、トランザクションごとにインスタンスが存在しました。しかし、コンテナ内のキャッシングを利用しないためにデータベースアクセスの頻度が多くなりました。また、ReadOnlyエンティティBeanはコンテナで排他ロックを受け並列処理ができませんでした。WLS 7.0では、デプロイメントディスクリプタに排他制御方式(Exclusive、Database、ReadOnly、Optimistic)を指定することができ、アプリケーションの要求、環境により同時アクセス制御方式を自由に選択できます。Optimisticを設定した場合、ReadOnlyエンティティBeanは、排他ロックではなく複数インスタンス制御が実現され、並列処理が可能になっています。また、データベースアクセスを減らすために、キャッシュを利用して既存のインスタンスをコピーして利用します。

図3 オプティミスティックロックとキャッシング

CMPエンティティBean
 CMPエンティティBeanのキャッシュ機能が強化されました。WLS 6.1までは、個々のエンティティBeanごとにキャッシュを設定していましたが、WLS 7.0では、同一のEARファイルに複数のエンティティBeanをパッキングすることで、実行時に1つのキャッシュを共有することが可能になりました。これにより、メモリの断片化を減らしパフォーマンスが向上します。また、EJB 2.0 CMRを利用してCMPエンティティBeanのキャッシュをさらに有効に利用するリレーションシップキャッシング機能が提供されました。現在のBeanと関連のあるBeanに対して外部結合クエリが発行され、その結果は現在のCMRフィールドに設定されたキャッシュに入ります。内部的には、SQLを用いて参照整合性が設定されているテーブルを読み込み、その結果をキャッシュに入れることで、次回以降のSQLの発行回数を抑止しています。

 さらに、バルクインサート更新機能もCMPエンティティBeanのパフォーマンスを向上させます。バッチ更新をサポートしているデータベースドライバに限定されますが、トランザクションがコミットされた時点で複数のSQL文をまとめて発行する機能です。

   高可用性の実現

 365日24時間運用のeビジネスアプリケーションシステムにおいて、計画停止(バージョンアップ、サーバ交換/増設など)を行う際にサービスを一時的にバックアップサーバで行い、作業終了後に本来のサーバに戻す操作が必要になってきます。また、異常停止(サーバ停止、ネットワーク障害、そのほかの異常)時にも、同様にサービスを停止することなくバックアップサーバに引き継ぐフェイルオーバーを実現しなければなりません。このような要求を実現するために、Webアプリケーションサーバの機能としてマイグレーション(移行)フレームワークが有効です。マイグレーションフレームワークにより、開発者は、予期しない異常時の振る舞いを詳細にプログラミングする必要がなく、統一的なアプリケーション開発(コストの軽減)を行え、フレームワークの高い信頼性と拡張性を享受できます。WLS 7.0で提供される高可用性に関するトピックスを説明します。

マイグレーションフレームワーク
 クラスタ化されたサーバ間でサービスを移行するためのフレームワークです。管理コンソール(および管理コマンド)を通じてJMS、JTAおよびMDBマイグレーション操作を行います。JDBCストア、JTAログ(トランザクションログ)がクラスタ内のすべてのサーバからアクセスできる環境であれば、各マイグレーション操作を選択し実行することができます。この機能により、あるマシンでハードウェア障害が発生した場合に、別のマシン上でJMSキューを引き継いだり、トランザクションログからトランザクションをリカバリすることができます。

JMS仮想デスティネーション
 WLS 7.0では、JMS仮想デスティネーションの概念が実装されました。管理者が単一の仮想デスティネーション(クラスタ内のJMSサーバの物理デスティネーションで構成)を設定できます。仮想デスティネーションに送信されたメッセージは、指定されたロードバランシングアルゴリズムにより実際の物理デスティネーションに送られます。クラスタ内のあるJMSサーバが異常の場合は、アクティブなJMSサーバ内のデスティネーションに送られます。

図4 仮想デスティネーション


   開発生産性の向上

 J2EEの開発は、WLS 7.0と密に統合されているサードパーティ製の各種IDEツールを利用するのが一般的です。WebサービスとJ2EEの統合開発環境としてBEA WebLogic Workshopが用意されています。そのほか、次のような開発ツールが提供されました。

BEA WebLogic Builder
 開発者がアプリケーションのパッケージング、デプロイメントディスクリプタの作成およびデプロイ作業を行う際の労力を軽減するGUIツールです。EJBのみならず、WebアプリケーションやEARレベルの定義も可能です。CMPエンティティBeanのCMRの定義も簡単に定義できます。最新機能をすぐに設定できるので開発作業の効率が格段にアップします。

Configuration Wizard
 実際のアプリケーションでは、ドメイン、クラスタ、管理サーバ、管理対象サーバの実行環境の設定作業が必要になります。Configuration Wizard機能はドメイン管理の効率アップを図るGUIツールです。config.xmlと起動シェルなどがGUIツールを通じて質問に答えるだけで簡単に作成されます。


 BEAが提供するWebアプリケーションサーバの最新版であるWLS 7.0 の新しい技術トピックスの概要を説明しました。大規模ミッションクリティカルアプリケーションシステムの要件はいろいろありますが、多数のユーザー、大量のトランザクションアクセス時における性能保証および24時間運用に耐え得る可用性(高信頼性)は特に重要な要求です。eビジネスアプリケーションが成功することは、想定以上のユーザー数、トランザクション数が発生する可能性を意味します。システム開始以降、確実に増え続けるビジネストランザクションを処理できる、高性能であり、かつ拡張性が優れた信頼性の高いプラットフォームを選定することはますます重要になり、SIプロジェクトの成功の前提条件になるでしょう。




Java Agile フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Java Agile 記事ランキング

本日 月間