目次


WebSphere Application Server における DB2 機能の活用

Comments

謝辞
(アルファベット順に) Stefan Dessloch、Grant Hutchison、Connie Nelin、Reto Preisig、Dave Wisneski、Dan Wolfson、および Dirk Wollscheid の各氏には、初期原稿のレビューと、この論文の基礎となった技術的専門性を提供していただきました。ただし、本論文に誤りや遺漏があった場合は、すべて著者の責任によるものです。

1.はじめに

IBM e-business Application Framework (eBAF)[1] は、成功する e-business アプリケーションの構築、実行、および管理を促進します。マルチ・プラットフォーム、マルチ・ベンダーのソリューションを可能にするオープン標準に基づくモデルと、e-business アプリケーションの開発、展開、管理のための実証済みテクニック、および多様な製品ポートフォリオで構成されます。IBM の eBAF は、IBM のお客様が e-bussiness へ転換される際に業務や技術的ニーズを満たすために必要な最高のエンド・ツー・エンドのソリューション構築するために、必要とされるインフラストラクチャーを提供します。WebSphere ソフトウェア製品ファミリーは、このインフラストラクチャーの中心にあり、ツールやランタイムを含む充実した包括的 e-business 製品一式を備えています。WebSphere Application Server (WAS)[2] は、企業が既存のリソースを活用して競争力を高めることを可能にする基盤です。DB2 は eBAF にデータ・ソース基盤を提供します。WebSphere Application Server と DB2 の組み合わせの重要性はますます高まってきており、両製品の緊密な統合によって、IBM 製品にシームレスな連携と製品相互の機能活用を期待する IBM e-business ユーザーにとって魅力的なソリューションが提供されます。

シームレスな統合 WebSphere-DB2 環境を助長するために活用し得る分野は数多くあります。たとえば、正式な統合インストールおよび管理プロセスの提供、相互にフル活用した両製品合同の統合開発、合同パフォーマンス評価、正式な統合テスト計画、統合サービス・チーム、技術資料の合同計画、およびさまざまな製品や一連のサービス・フィックス間の同期化などが挙げられます。

本記事では、WebSphere Application Server、具体的には (注記のない限り) WebSphere Application Server アドバンスド版において DB2 機能を活用する数多くの方法を解説します。このセクションの残りでは、e-business アプリケーションをターゲットとした多層式の Web 対応環境について解説します。セクション 2 では、現在 WebSphere Application Server 製品で DB2 をどのように用いて活用できるかについて説明します。セクション 3 は、WebSphere Application Server において一層の機能活用を可能にするような、DB2 に対する機能拡張の可能性を提示します。最後に、セクション 4 で、WebSphere Application Server で DB2 機能を活用し得るさまざまな方法と、その他求められる機能をまとめます。

図 1: WebSphere Application Server-DB2 の統合
図 1: WebSphere Application Server-DB2 の統合
図 1: WebSphere Application Server-DB2 の統合

最高のパフォーマンス、スケーラビリティー、およびユーザビリティーを実現するために、Web アプリケーション・サーバーとデータベース・サーバーが互いの機能を活用しながらシームレスに連携する環境の提供が望まれます。総合的なパフォーマンスを改善するには、DBMS 内に存在するビジネス・ロジックやその他の構成体をミドルウェアが活用することが求められます。図 1 に、e-business をターゲットとした多層式の Web 対応環境を示しています。この図では、こういった目的のために WebSphere Application Server と DB2 をどのように統合できるかを示しています。

この環境で開発された Web 対応アプリケーションは、J2EE (Java? 2 Enterprise Edition) サーバー環境[3] のいくつかのコンポーネントを利用できます。これには、EJB (Enterprise JavaBeans) コンポーネント、サーブレット、JSP (Java Server Pages) コード、および JNDI (Java Naming and Directory Interface) 拡張のサポートが含まれます。J2EE はまた、JDBC (Java Database Connectivity) コードとトランザクション用の JTA (Java Transaction API) API のサポートを含め、DBMS への接続とアクセスもサポートします。さらに、SQLJ (SQL for Java あるいは埋め込み SQL) と XML (eXtensive Markup Language) も重要なオープン標準技術であり、e-business アプリケーションの開発時にはそれらのサポートも望まれます。WebSphere Application Server 環境内の中間層にある HTTP サーバーを、Web ブラウザー、バーベイシブ機器、PC、およびその他の第1層の装置が HTTP を使用してアクセスすることもあります。これによって (WebSphere Application Server が管理する) JSP やサーブレットが起動される場合もあります。起動された JSP やサーブレットは、JDBC、SQLJ、IBM Data Access Beans を使用して、あるいは EJB を使用して間接的に、第3層の DB2 データ・ソースをアクセスします (詳細はセクション 2 参照)。

2. 現在の WebSphere Application Server における DB2

DB2 は現在、多くの領域で WebSphere Application Server によって利用されています。図 2 にそのうちのいくつかの領域を示します。DB2 は WebSphere Application Server 管理サーバーと WebSphere Application Server Site Analyzer に対するリポジトリーとして機能します。また、サーブレットの状態情報も DB2 データベースに保管されます。DB2 は EJB セッション Bean の状態情報の保管に使用され、EJB の Bean 管理パーシスタンス (BMP) とコンテナー管理パーシスタンス (CMP) のバックエンド・ストレージとして機能します。WebSphere Application Server の接続プーリング機能も提供され、アプリケーションで活用できます[4]。

図 2: 現在の WebSphere Application Server によるDB2の使用法
図 2: 現在の WebSphere Application Server  による DB2 の使用法
図 2: 現在の WebSphere Application Server による DB2 の使用法

接続プーリングにより、パフォーマンスが向上したり、システム・リソースをより効率的に使用できる場合があります。接続プーリングを使用すると、アプリケーションは可能な接続のプールから DB2 データベースへの接続を取得できます。アプリケーションの接続が不要になると、接続プールへ戻します。DB2 はユーザー・データの保管にも使用されます。

DB2 と WebSphere Application Server 間の統合のその他の領域には、インストール、管理、構成、テスト、およびサポートがあります。DB2 と WebSphere Application Server を組み合わせたインストールおよび構成プロセスは、簡素化されています。WebSphere Application Server は DB2 の「サイレント・インストール」機能を使用して、インストール・プロセスを容易にします。また、WebSphere Application Server V3.5 には、DB2 パフォーマンス・ウィザード (DB2 V7.1 以上) を包含するパフォーマンス・ウィザードが含まれます。このウィザードは、トランザクション型の Web 照会に適切な初期値を使用して、DB2 パフォーマンス・ウィザードを起動できます。WebSphere Application Server 管理者には、データ・ソースに関連付けられた DB2 データベースをチューニングする DB2 スマートガイドを呼び出すという、データベース・チューニングの選択肢もあります。結果として、従来型の定型のセットアップと比べてパフォーマンスが向上します。

IBM トロント研究所には DB2 ソリューション・インテグレーション・センターがあり、改善された組み合わせインストールおよび構成、複数の製品にまたがる認証およびテスト、J2EE 妥当性検査、製品にまたがる顧客サポートを支援しています。たとえば、DB2 V7.1 FixPak2+ が J2EE 準拠テストの JDBC 部分に合格することを確認する共同テストが同センターで完了しました。さらに、同センターでは、WebSphere Application Server および VisualAge for Java (VAJ) を使用して、DB2 FixPak を出荷前にテストします。WebSphere Application Server の知識とスキルを備えた DB2 サポート・アナリストと共に、IBM ジョイント・カスタマーをより効果的にサポートします。このセンターは、DB2-WebSphere Application Server の最良事例を確立して検証するための手段です。テクノロジーを共有し、WebSphere Application Server のお客様がメリットを享受できるような新機能を DB2 に組み込むことにより、統合を一段とレベルアップします。

同センターは、WebSphere Application Server 環境における最新の DB2 機能の活用に重点を置いたチュートリアルも作成します。したがって、DB2-WebSphere Application Server の統合環境のための技術白書、デモンストレーション、サンプル、トレーニングを提供します。たとえば、IBM Video Central for e-Business 統合チュートリアルはその例で、電子レンタル・ビデオ・アプリケーションのための汎用 Web サービスを提供する Web ベースの企業間 (B2B) アプリケーションに基づいたサンプルとデモで構成されています[5]。

この統合環境の DB2 データ・ソースを JSP およびサーブレットからアクセスする選択肢は、いくつかあります。まず、JDBC または SQLJ をコードに直接含めることができます。これにより、JSP およびサーブレット開発者で DBMS の経験もある開発者は、特定のコードに合わせて最適化できます。しかし、このような形でデータ・ソースをアクセスするのは複雑です。さらに、高品質のコードを作成するために JSP ページ、サーブレット、および DBMS の経験をすべて備えたアプリケーション開発者を見つけるのは至難の技です。

代替として、JSP およびサーブレットは、IBM Data Access Beans を使用して開発し、DB2 サーバーをアクセスできます。Data Access Beans はバックエンド・データ・ソースのアクセスに必要なロジックをカプセル化します。Data Access Beans には JDBC 準拠のデータ・ソースへの汎用アクセスをサポートするクラス・コレクションが含まれ、標準 JDBC 呼び出しの上に機能層を提供します。これにより、データ・ソースをアクセスする Web アプリケーションの開発が容易になります。JSP とサーブレットは、リモート・メソッド起動機能で起動される EJB を使用してリモート・データ・ソースを間接的にアクセスすることもできます。Web ブラウザーに加えて、その他の種類のクライアント・アプリケーションも、リモート・メソッド起動機能によって直接 EJB を起動できます。これらのアプリケーションは、図 1 に示すとおり、JDBC や SQLJ を使用して DB2 データ・サーバーを直接アクセスする選択肢もあります。

セッション Bean とエンティティー Bean は中間層でビジネス・ロジックを実行します。どちらも、JDBC 接続を使用して、データ・アクセスをカスタマイズできます。コンテナー管理パーシスタンス (CMP) を使用して、エンティティー Bean は現在存在または定義されている DB2 の表に、展開時にマップできます。エンティティー Bean のライフ・サイクル管理については、CMP を備えたエンティティー Bean 用にデータ・アクセス・コードが自動生成され、データの作成、更新、削除ができます[6]。したがってアプリケーション開発者には透過的で、EJB サーバーによって実装されます。たとえば、Bean を作成してデータで満たすためのメソッドや、基本キーによって Bean や関連データを検出するメソッドがサポートされ、DB2 で実行される SQL ステートメントに直接マップされます。

図 3: ステートレス・セッション Bean としてのストアード・プロシージャー
図 3: ステートレス・セッション Bean としてのストアード・プロシージャー
図 3: ステートレス・セッション Bean としてのストアード・プロシージャー

多くの DB2 サーバーには、EJB を通してサーバー・アプリケーションやコンポーネントで活用できるストアード・プロシージャー (SP) およびユーザー定義関数 (UDF) があります。WebSphere Application Server-DB2 環境では、EJB は EJB サーバーの支援を受けて中間層で実行する一方で、ストアード・プロシージャーはバックエンド・データ・サーバー上で実行します。ストアード・プロシージャーを実行すると、特にストアード・プロシージャーにいくつか SQL ステートメントが含まれる場合に中間層とデータベース・サーバー間の通信が削減されるので、ストアード・プロシージャーの活用は、e-business アプリケーションのパフォーマンス改善の鍵です。また、ストアード・プロシージャーの活用では既存のストアード・プロシージャー (zSeries マシン上のストアード・プロシージャーも含む) 内のビジネス・ロジックのコードを再利用でき、開発コストと将来の保守コストも削減します。しかし、異なる層にある EJB コンポーネントおよびストアード・プロシージャーの実行のパフォーマンス低下と、データ・フロー・ロック競合、およびその他関連する課題との間でトレードオフがあります。

EJB でストアード・プロシージャーを使用すると、任意のサポート言語で書かれた既存のビジネス・ロジックを利用しながら重複コードを最小化できます。従来型アプリケーションを EJB プログラミング・モデルに変換することもできます。ストアード・プロシージャーをステートレス・セッション Bean のメソッドとしてラッピングするボトムアップ・メソッドを、図 3 に示します (プロセスの実装に関する詳細は [7] にあります)。この目的のためにステートレス・セッション Bean を使用すると、Web アプリケーション・サーバー上のリソース消費が最小化されます。Web アプリケーションで使用するために既存のストアード・プロシージャーをラッピングする EJB を作成するにあたり、IBM は開発者を支援するツールを提供します。このツールは、VisualAge for Java V3.5.3 エンタープライズ版のテクノロジー・プレビューとして提供されます。

VisualAge for Java EE 3.5.3 の EJB ストアード・プロシージャー統合ツールによって生成されたコードを使用して、ストアード・プロシージャーをステートレス・セッション Bean のメソッドとしてラッピングする方法を検証してみましょう。前提として、「getClientInfo」というメソッドを作成して CLIENTREPORT という DB2 ストアード・プロシージャーをラップすることにします。さらに、IBM の設計ではデータベース接続を確立するために WebSphere Application Server データ・ソース ("jdbc/SmapleDataSource") を使用する必要があり、メソッド自体にデータベース認証情報 (ユーザー ID とパスワード) を含めることにしたと想定します。

このような設計上の意思決定をしたうえで、EJB ストアード・プロシージャー統合ツールを使用して、次の例に示す EJB メソッド用のコードを生成できます。生成されたこのコードは IBM Data Access Beans クラスを使用していることに注意してください。これらのクラスは標準 JDBC 呼び出しを使用して DBMS をアクセスしますが、基本 JDBC を超えてストアード・プロシージャーを扱う場合に特に便利な機能レベルを提供します。追加機能の中には、ストアード・プロシージャーの全出力パラメーターと戻されたすべての結果、さらには適切なメタデータを含むことのできる直列化可能なオブジェクトのサポートがあります。ツールにより生成された各メソッドから戻された、この直列化可能なオブジェクト (com.ibm.db.CallableStatement) を次に示します。完全なサンプルを提示した後で、このコードの詳細を具体的に見て行きますます。

public com.ibm.db.CallableStatement
getClientInfo(java.lang.Integer id)
throws java.rmi.RemoteException { /**
* ストアード・プロシージャー user1.clientreport を実行します。
* メソッド生成日時:  Jun 4, 2001 7:51:31 AM
*
* ストアード・プロシージャーの各入力パラメーターはメソッド・パラメーターです
* 出力パラメーターや結果セットは CallableStatementに返されます
*
* @return com.ibm.db.CallableStatement
* @param id java.lang.Integer
*/
com.ibm.db.DatabaseConnection con = null;
com.ibm.db.StatementMetaData callSpec = null;
com.ibm.db.CallableStatement procCall = null;

try {
// DatabaseConnection オブジェクトを作成しプロパティーを設定する
con = new com.ibm.db.DatabaseConnection();
// 接続は DataSource オブジェクト経由
con.setInitialContextFactory("com.ibm.ejs.ns.jndi.CNInitialContextFactory");
con.setJndiDataSource("jdbc/SampleDataSource");

// ユーザー ID とパスワードを設定
con.setUserID("user1");
// 暗号化されたパスワードに 'true' を使用
con.setPassword("acedg0574g077361726163636f", true);

// AutoCommit プロパティー
con.setAutoCommit(false);

// StatementMetaData オブジェクトを作成してプロパティーを設定
callSpec = new com.ibm.db.StatementMetaData();
// SQL ステートメントを設定
callSpec.setSQL("{ CALL user1.clientreport (:id,:name,:email) }");

// メタデータにプロシージャー・パラメーター記述を追加
callSpec.addParameter("id", java.lang.Integer.class,
java.sql.Types.INTEGER,
java.sql.DatabaseMetaData.procedureColumnIn); callSpec.addParameter("name", java.lang.String.class,
java.sql.Types.VARCHAR,
java.sql.DatabaseMetaData.procedureColumnOut); callSpec.setParameterLength("name", 30);
callSpec.addParameter("email", java.lang.String.class,
java.sql.Types.VARCHAR,
java.sql.DatabaseMetaData.procedureColumnOut); callSpec.setParameterLength("email", 30);

// CallableStatement オブジェクトを作成してプロパティーを設定
procCall = new com.ibm.db.CallableStatement();
procCall.setMetaData(callSpec);
procCall.setConnection(con);

// ストアード・プロシージャーの入力パラメーターを設定
procCall.setParameter("id", id);

// ストアード・プロシージャーを実行
procCall.execute();

// 出力パラメータの値を取得
procCall.getParameter("name");
procCall.getParameter("email");

// CallableStatement オブジェクトを返す
return procCall; } catch (Exception e) {
throw new java.rmi.RemoteException("An exception occurred.", e); } finally {
// CallableStatement オブジェクトのリソースを解放
try {
if (procCall != null)
procCall.close(); } catch (com.ibm.db.DataException de) {}

// データベースから接続を解除
try {
if (con != null)
con.disconnect(); } catch (com.ibm.db.DataException de) {} } }

getClientInfo メソッドには、入力として Integer 値が必要です。この値はストアード・プロシージャー自体で必要とされる入力パラメーターにマップされます。EJB ストアード・プロシージャー統合ツールで生成されたすべてのメソッドと同様、サンプル・メソッドは com.ibm.db.CallableStatement オブジェクトを返します。java.rmi.RemoteExceptions をスローする場合もあります。

メソッドはいくつかの変数の宣言から始まります (これについては後述します)。try ブロックの最初のセクションには、データベース接続を確立するためのロジックが含まれます。具体的には、com.ibm.db.DatabaseConnection を作成し、このオブジェクトに関連したプロパティーを設定します。このようなプロパティーには InitialContextFactory (WebSphere Application Server アドバンスド版 3.5 に適切な値に設定されます) と WebSphere Application Server のデータ・ソースが含まれます。このメソッドを起動する任意のクライアントがこの権限の下でデータ・ソースに接続できるように、ユーザー ID とパスワードもここで設定されます。パスワードが暗号化形式で含まれていることに注意してください。最後に、このコード・ブロックは自動コミット・モードを「false」に設定します。WebSphere Application Server がコミット・プロセスをユーザーに変わって管理するので、接続にデータ・ソースを使用する際はこれが適切です。

次に、メソッドは com.ibm.db.StatementMetaData オブジェクトを作成し、これがストアード・プロシージャー呼び出しに関連した指定を管理します。再び、メソッドはオブジェクトのプロパティーを適切に設定します。これには、ストアード・プロシージャーを呼び出す SQL ステートメントの設定も含まれます。サンプルでは、SQL ステートメントはデータベースの USER1 スキーマの CLIENTREPORT プロシージャーを呼び出します。このプロシージャーには、入力パラメーターの「ID」、出力パラメーターの「NAME」と「EMAIL」という 3 つのパラメーターが関連付けられています。各パラメーターは StatementMetaData オブジェクトで説明される必要があります。後続行でそれを行っており、各パラメーターに Java および SQL の両タイプを指定するとともに、各パラメーターのモードを指定しています (入力パラメーターは procedureColumnIn、出力パラメーターは procedureColumnOut で表します)。

StatementMetaData オブジェクトを適切に定義すると、メソッドは最終的にストアード・プロシージャーの起動に使用される CollableStatement オブジェクトを作成します。このオブジェクトを作成後、作成し定義しておいた StatementMetaData オブジェクトにメタデータが設定されます。その接続は確立済みのデータベース接続に設定されます。そして入力パラメーターはメソッドの呼び出し側が渡したパラメーターにマップされます。最後に、CallableStatement が実行され、それによって DBMS がストアード・プロシージャーを起動します。

プロシージャーが起動されると、出力パラメーターが明示的に取り出されます。特に同様の方式で返された結果セットを取得する必要はないので、このステップがなぜ必要か不思議に思うかもしれません。DBMS によっては、ストアード・プロシージャーから返された結果セットから必要な値のすべてをユーザーが取り出さない限り、出力パラメーターの値を一切取得できないものもあります。このため、結果セットからの値を取り出すタイミングを制御するのはユーザーなので、CallableStatement Bean は、getParameter() メソッド経由で具体的に要求されるまで、データベースから出力パラメーターを一切取得しません。デフォルトでは、結果セット内のすべての行は、ストアード・プロシージャーが実行された後で、自動的に取り出されてキャッシュに保管されます。しかし、出力パラメーターは常に明示的に取り出され、キャッシュに保管される必要があります。

次に、メソッドは呼び出し側に CallableStatement オブジェクトを返します。この時点でこのオブジェクトは、すべての出力パラメーターと、ストアード・プロシージャーから返された結果セット、およびこのオブジェクトの正しい解析に必要なメタデータを含みます。

catch ブロックは、例外が発生すればすべて java.rmi.RemoteExceptions に変換して呼び出し側に戻します。この変換が適切なのは、EJB 1.0 準拠のセッション Beans に対してです。

finally ブロックは、メソッドによって取得された全リソースが解放されることを保証します。このようなリソースには、CallableStatement オブジェクトや DatabaseConnection オブジェクトと関連付けられたリソースがすべて含まれます。

アプリケーションは、サポートされる分散トランザクション環境を活用することもできます。これは、EJB 仕様、JTA、分散トランザクションとトランザクション・ログ、およびトランザクションと分離用の宣言型指定のサポートを通して有効になります。DB2 は随分以前から 2 相コミットや分散トランザクションをサポートしており、WebSphere Application Server から JTA 経由で分散トランザクションを全面サポートします。

DB2 の最新リリース (V7.2) で提供される JDBC ドライバーには、WebSphere Application Server でデータリンク・テクノロジーの活用を可能にする機能拡張が含まれます。データリンクは、DB2 で外部データを管理するための強力なファイル・リンクであり、DATALINK SQL データ・タイプを使用します。このテクノロジーは、参照保全性、アクセス制御、整合バックアップ/リカバリー、およびトランザクションの一貫性を含む外部ファイル管理を可能にします。データリンクはデータベースのファイル管理を容易にする一方、開発者は従来型のファイル・ベース API (つまりファイル・オープン、ファイル削除など) や SQL API を使用して、ファイル・コンテンツをアクセスできます。データリンクのファイル・システムのフィルターは、従来型のファイル・コマンドをインターセプトして許可を調べます。データリンク・ファイル・マネージャーは、DB2 データベースにリンクされた特定のデータリンク・サーバー上の全ファイルのファイル管理処理を容易にします。データリンクには、ネットワーク・トラフィックを削減し、ファイルと同等のスピード、アプリケーションの近くへのファイル分散という利点があります。データリンク・テクノロジーは、次のようなアプリケーションを含む多様なアプリケーションに魅力的なソリューションを提供します。

  • 医療アプリケーション (ファイル・システムにレントゲン写真が保管され、その関連属性はデータベースに保管されるアプリケーションなど)
  • エンターテイメント・アプリケーション (ビデオ・クリップ管理など)
  • 何百万ものファイルを管理する WWW アプリケーション。アクセス制御はデータベースによって管理されます。

e-business アプリケーションには、データベースにおいて複数のデータ表記 (Java の直列化されたオブジェクトや XML データなど) やビジネス・ロジックの実行が必要となるものがあります。開発者は SQL 構造化タイプを使用して、これらの要件を満たすためにアプリケーション固有のタイプをデータベース内に作成できます。構造化タイプは、列、表、およびオブジェクト視点の定義として使用できます。さらに、構造化タイプにメソッドを定義してアプリケーションの動作を表すこともできます。これにより、WebSphere Application Server 環境で Java クラスと EJB コンポーネントの自然なマッピングが行われます。アプリケーション開発者は変換機能を用いて、データベースの値をアプリケーション・ロジックにバインドできます。バインドには、クライアントとデータベース間のデータ転送や、データベース・サーバー上でのメッセージ実行も含めることができます。これによってデータベースのリレーショナル表に対するオブジェクト視点を作成することもできます。変換機能を使いやすくするツールを含めて、EJB メソッドのデータベースへのプッシュダウンを有効にするツールことをお勧めします (詳細は下記参照)。

アプリケーション開発者は、現在利用可能な多くの DB2 機能を WebSphere Application Server で活用できます。これには、ウィザード、スマート・ガイド、およびWebSphere Studio や VisualAge for Java、DB2 のその他のオプションが含まれます。たとえば、WebSphere Studio には、データ・アクセス・サーブレットや JSP ページを作成するデータベース・ウィザードが含まれます。WebShpere Studio は、SQL ウィザードを使用して GUI ベースで SQL ステートメントを作成します。

VisualAge for Java エンタープライズ版は、JDBC ドライバー経由の DB2 データリンクのサポートと Data Access Beans のサポートを提供します。これによりデータベース・アクセスが可能になり、さまざまなビジュアル形式からストアード・プロシージャーを起動できます。DB2 ストアード・プロシージャー・ビルダーなどの先進的データ・アクセス・ソリューションは、VisualAge for Java から、またはスタンドアロン・ツールとして使用できます。EJB オブジェクト・パーシスタンシー・マッピングは、トップダウン方式、ボトムアップ方式、あるいはその中間の方式を使用し、ツールの助けを借りて DB2 表を CMP EJB へマップします。ボトムアップ方式では、ツールを使用して既存のデータベース表を EJB エンティティーへマップできます。トップダウン方式では、スマート・ガイドを使用して EJB を作成し、関連する EJB エンティティー・オブジェクト・モデルをデータベース表へマッピングできます。中間方式では、列への EJB フィールドのマッピングや、コンポーザー (複数列から 1 つの CMP フィールド値を計算)、コンバーター (タイプ変換と 1 つの列に関すると単純計算) などにツールを使えます。さらに、EJB ライフサイクル管理用にデータ・アクセス・コードが自動生成されます。

VisualAge for Java V3.5.3 エンタープライズ版にはストアード・プロシージャーを統合するためのテクニカル・プレビュー・ツールが含まれており、ストアード・プロシージャーをセッション EJB として再利用できます。このツールは接続プーリングと JDBC 1.0 または直接データベース接続をサポートします。すべての OUT および INOUT パラメーターと、ストアード・プロシージャーから返された結果セットを 1 つの直列化されたオブジェクトにパッケージ化します。このオブジェクトはデータ解析を簡単にするメタデータを含み、クライアント側のコーディング・パターンの共通化を推進します。また、Data Access Bean テクノロジーも活用し、EJB 開発者が DBMS 認証について全面的に制御できる機能も提供します。このツールには、ネットワーク・トラフィックを一層削減するために、結果セット用に返される行数をクライアントが制限できるオプションもあります。

3. WebSphere Application Server におけるその他の DB2 機能

EJB 2.0 ドラフト仕様には新しい EJB Query Language (QL) [6] が含まれます。EJB QL はファインダーと選択メソッドを定義して、CMP を使用したエンティティー Bean のコンテナーをまたがる可搬性を推進します。目標は SQL と似た言語である EJB QL をパーシスタント・ストアのネイティブ言語にコンパイルすることです。今度の EJB 2.0 オブジェクト・モデル [6] にも、図 4b に示すように、アソシエーション/リレーションシップおよびオブジェクト・ネスティングをサポートする機能拡張が含まれます。現時点では、WebSphere Application Server 内のこれら EJB オブジェクトを DB2 リレーショナル表にマップするには、厚いマッピング層が必要です (図 4a 参照)。現在、DB2 で直接活用できるオブジェクト・リレーショナル機能はありません。CMP 設計者がパーシスタント・データのメモリー・レイアウトを最適化することによってパフォーマンスを改善する場合に、このことによって制約を受ける場合があります。たとえば、オブジェクト・リレーショナル機能の活用で改善されるパフォーマンスは、直列化されたオブジェクトとして現在の CMP 設計に保管された、ネストしたオブジェクトのパフォーマンスであったりします。

オブジェクト照会はサポートされますが、EJB 照会メソッドのデータベースへのプッシュダウンは制限されます。これはパフォーマンス改善には好ましいことです。エンティティー Bean に関連付けられたビジネス・メソッドが EJB QL 照会 [6] で使用できる場合を考えてみましょう。より良いパフォーマンスを得るには、メソッドはアプリケーション・サーバーではなく、データベース・エンジンで実行されるのが望ましいです。DB2 はこの種の EJB 照会メソッド・プッシュダウンをサポートできますが、現時点では WebSphere Application Server で活用されていません。(これらの照会メソッドは、下記の DB2 構造化タイプと関連付けられたメソッドにマップできます。)

図 4.EJB オブジェクトの DB2 へのマッピング
図 4.EJB オブジェクトの DB2 へのマッピング
図 4.EJB オブジェクトの DB2 へのマッピング

a) 現在のマッピング、b) オブジェクトの継承、リレーションシップ、ネスティング、c) 将来のマッピング

構造化タイプは概念的に Java クラスと似ており、複数の属性とメソッドを持ちます。DB2 でオブジェクトビュー、表、列の作成用に定義されます。図 4b は、表の階層、参照タイプ、および抽象データ・タイプの例を示しています。たとえば、エグゼクティブ (exec) は特定の従業員 (emp) タイプで、それはある個人 (person) です。これら役割のそれぞれには関連付けられた表があり、図はこれらの表間の関係の階層的な特性をグラフィカルに示しています。また、従業員 (emp) は部門 (dept) のメンバーでマネージャー (mgr) である場合もあります。図 4b の矢印は、さまざまな表間の参照または関連付けを示します。ユーザー定義関数 (UDF) とその他のメソッドも、これらの構造化タイプに関連付けできます。DB2 を使用してこの種の表と表階層をアクセスする例を次に示します。

create type Emp_t under Person_t as (salary Integer, dept Ref(dept_t))
create table person of Person_t (ref is oid user generated)
create table emp of Emp_t under person (dept with options scope dept).

Select e.name, e.dept->name, e.oid->getAddressString()

from emp e
where e.dept->budget > 2000000 and e.addr.city = 'San Jose'

この例では、dept は参照タイプで、部門表 (dept) と従業員表 (emp) 間の関係を表します。また、oid はオブジェクト識別子、すなわち住所表 (address) オブジェクトに対する参照です。

WebSphere Application Server でこれら DB2 オブジェクト・リレーショナル機能を開発者が活用するには、ツールによる支援が必要です。特に、図 4c に示すように、EJB オブジェクト・モデルと DB2 間のマッピング層を薄くする EJB には、特に必要です。薄いマッピング層では、照会は容易になり、照会の処理に必要な結合の数も減り、EJB メソッドは構造化タイプからの UDF やメソッドを活用してデータベース・サーバー上で実行できるため、パフォーマンス向上が助長されます。また、プログラミング・モデルの統合を促進してコード再利用を容易にし、データベース・アクセスを改善します。

DB2 Web サービスは、DB2 V7.2 の DB2 XML エクステンダー Web サイト[8] からダウンロードして入手できます。サービスは、UDDI (Universal Data Definition Interchange)[9]、SOAP (Simple Object Access Protocol)[10]、および WSDL (Web Serices Definition Language)[11] という、実際または事実上の Web サービス標準に基づいて開発されています。UDDI は利用可能なサービスのディレクトリーを含み、SOAP はサービス・プロバイダーやクライアントが必要とする通信を容易にし、WSDL はプロバイダーによるサービス登録とクライアントによるサービス関連情報の取得に使用されます。サービスには、XML の取り出しおよび保管についての XML エクステンダー・オプション、照会サービス、変更サービス (挿入、更新、削除)、およびストアード・プロシージャーが含まれます[12]。

図 5 は、XML およびストアード・プロシージャー・サービスを含め、利用可能なサービスのいくつかを図示したものです。SOAP クライアントは要求を WebSphere Application Server の SOAP ルーターに送り、ルーターは適切なサーブレットへ要求を伝え、要求を受けたサーブレットがサービスを起動します。ストアード・プロシージャーはサービス・プロバイダーおよびローカルまたはリモートの UDDI リポジトリーと通信して、ビジネス・ロジック実行の一環として情報を収集します。同様に、XML Web サービスにより、アプリケーションは XML 形式で DB2 データを保管し検索できます。

図 5: DB2 Web サービス。
図 5: DB2 Web サービス。
図 5: DB2 Web サービス。

Generic Query Invokerは DADx Invoker です。Employee 表および Dept. 表と Virtual Web Data は、データベースに保管されたデータのサンプルです。

IBM は引き続きより深いレベルで WebSphere Application Server と DB2 間の統合、活用、および緊密な整合を実現し、システム・パフォーマンス、スケーラビリティー、および操作性を改善します。

4. まとめ

IBM eBAF は、オープン標準、マルチ・プラットフォーム、マルチ・ベンダーを使用して、成功する e-business を企業が迅速に構築して稼動に移し、管理できるように設計されています。WebSphere Application Server と DB2 は、ユーザーが競争力を高めることのできる魅力的な統合基盤を集合的に提供します。この記事では、WebSphere Application Server における DB2 機能の活用を解説しました。具体的には以下の内容を解説しました。

  • インストールと管理における緊密な統合
  • 共同の統合テストおよびパフォーマンス分析
  • データ・アクセス機能
  • オブジェク・リレーショナルな活用、Web サービス、および関連ツール・オファリング

DB2 は WebSphere Application Server アドミニストレーターおよび Site Analyzer 用のリポジトリーとして使用されます。また、EJB Bean およびコンテナー管理パーシスタンス、さらにはその他のタイプのアプリケーション・データのためのバックエンド・データベースとしても使用されます。DB2 パフォーマンス・ウィザードは、WebSphere Application Server アドミニストレーター内でのデータベース・パフォーマンスのチューニングに使用できます。統合認定、テスト、J2EE 妥当性検査、顧客サポート、チュートリアル、技術白書、デモ、およびサンプルには、DB2 ソリューション・インテグレーション・センターを利用できます。効率的な統合データ・アクセスと、EJB を使用したストアード・プロシージャー活用のためのツールも提供されます。その他の機能には、DB2 XML エクステンダー、照会、更新、およびストアード・プロシージャーのための DB2 Web サービスの活用も含まれます。

WebSphere Application Server-DB2 環境は、これら機能のすべてをサポートし、Web ベースのアプリケーション開発のしやすさと簡素化されたインストールおよび構成をサポートする強力な統合ツールも備えています。緊密な統合により、これら製品はシームレスに稼動し、相互の機能を活用できます。そして、成功する e-business オファリングを構築する、競争力に優れた統合基盤が提供されます。

問い合わせ先

本論文の詳細情報については、Sandra Balor 氏 (Manager, WebSphere Database Development, IBM Silicon Valley Laboratory)まで電話 ((408) 463-3633) またはメール (sandrajb@us.ibm.com) でお問い合わせください。


特記事項
この情報は IBM の現在の意向および目標を示すものであり、お客様にお知らせすることなく変更あるいは撤回される場合があります。

本論文における IBM 製品、プログラム、またはサービスの参照が、IBM が業務を営むすべての国においてこれらの製品・プログラム・サービスを提供する意向を必ずしも示すものではありません。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=326821
ArticleTitle=WebSphere Application Server における DB2 機能の活用
publish-date=12282005