Webアプリケーションで異種データに対処する

C. M. Saracco, DBMS and Web Application Server Integration, EMC

C. M. Saraccoは、IBMシリコンバレー研究所に勤務するシニア・ソフトウェア・エンジニアです。カリフォルニア大学サンタクルーズ校の公開講座でソフトウェア・テクノロジーの講師を務めた経験もあり、北米、南米、ヨーロッパ、中東の各地でさまざまなテクノロジーをテーマに講演活動を行っています。


developerWorks
        プロフェッショナル著者レベル

2002年 8月 22日

はじめに

企業が増収と業務効率の改善を目指して努力を続けているなか、IT管理者は重要なビジネス・データにアクセスし、統合し、それに基づいて行動するよりよい方法の追求に余念がありません。しかし、その課題が容易なものであることはまれです。というのも、このようなデータは各種システムを越えて分散し、さまざまなフォーマットで保管されていることが多いからです。さらに、このようなデータにはビジネス・パートナーが所有するものや、アプリケーション、Webサービス、Java™ Enterprise Edition(J2EE)サーバー・サイド・コンポーネントなどによって動的に生成されるものもあります。

この膨大なデータを統合し、処理することは、多くのIT企業にとって大きな問題となっています。特に、ソフトウェアの開発サイクルがきわめて短いことが多いWebベースの環境においては深刻な問題と言えます。そうした環境では通常、Webアプリケーション・サーバー層に重要なビジネス・ロジックが置かれます。このビジネス・ロジックは、Enterprise JavaBeans™(EJB)、Webサービス、サーブレットなどの再使用可能ソフトウェア・コンポーネントに実装されることが多く、各種リモート・システムによって保管または生成される広範なデータを最終的に処理する必要があります。これを透過的かつ確実に行えないと、これらの中間層サーバーの有効性が制限されるばかりか、それらに基づいて作成されたアプリケーションの機能が制限されることにもなります。

連合データベース管理システム(DBMS)は、Web設計者にとって、本質的に異なるデータに対処する上で助けとなります。連合DBMSは、さまざまなフォーマットで保管(または生成)された分散データの単一サイト・イメージを提供します。また、Webプログラマーにとっては、このようなデータにアクセスするための共通インターフェースとなります。さらに、リモート・データに関する統計を維持し、それらの統計を使用してデータ・アクセスをグローバルに最適化することが可能な拡張カタログを特長とする優れた連合DBMSもあります。

そのため、連合DBMSは情報を迅速かつ効率的に統合するのに役立ち、複数のソースからのデータへの接続、アクセス、結合、フィルター操作、変換に関連するコンポーネント開発者の負担の多くを軽減します。この記事では、Webアプリケーション・サーバーから連合データへのアクセスに関連する、主なテクノロジーについて考察します。さらに、Webコンポーネント開発者が、広範なデータに透過的にアクセスするJ2EEコンポーネントやWebサービスを構築するために、連合DBMSの1つであるDB2 V8(Linux版、UNIX-版、およびWindows版)の構成手法について考察します。次回以降の記事では、連合データベースに対するコンテナー管理による永続性を備えたSession Bean、Webサービス、Entity Beanの開発に伴う設計およびプログラミングの問題を掘り下げます。『連合データにアクセスするWebコンポーネントの構築』では、連合データを処理するSession EJBおよびWebサービス作成のための設計要件について概説しています。『連合データにまたがるエンティティーEJBの構築』では、連合データにわたるEntity EJBの作成方法について考察しています。


主なテクノロジーの概要

連合DBMSがWebアプリケーション開発者にとって役立つかどうかを判断するには、さきほど説明した環境を構成するテクノロジーについて理解することが重要です。主なテクノロジーとしては、連合DBMSWebアプリケーション・サーバーEJBWebサービスがあります。ここでは、それらのテクノロジーについてそれぞれ簡単に考察します。詳細については、「参考文献」で紹介している資料をご覧ください。

連合DBMS

IBM DB2(Linux版、UNIX版、およびWindows版)などの連合DBMSは、複数のデータ・ソースにわたる仮想データベースを提供します。これらのデータ・ソースは、稼働するハードウェアやオペレーティング・システム・プラットフォームが異なっていても、販売元のベンダーが異なっていても、使用するアプリケーション・プログラミング・インターフェース(様々なSQLダイアレクトを含む)が異なっていてもかまいません。これらの違いは連合DBMSによって隠されるため、プログラマーは他の方法よりも高い抽象レベルでデータ・ソースを扱うことができます。たとえば、表(またはファイルなど、その他のデータ・オブジェクト)のニックネームによって、ロケーション透過性が提供されるため、プログラマーは目的のデータが存在する場所を正確に知る必要がなくなります。また、機能補償によってさまざまなデータ・ソース間の違いを隠し、ネイティブでサポートされない機能をシミュレートすることができます。さらに、マルチサイト結合やマルチサイト合併によって、複数のソースからのデータの統合が容易になります。

連合DBMSテクノロジーが市場に登場したのは1990年代のことです。製品としては、次世代ゲートウェイ、データ・アクセス・ミドルウェア、マルチデータベース・サーバーなど、さまざまな名称で呼ばれていました。このテクノロジーのIBM初の市販製品はDataJoinerRでした。これは当初、別個の製品として販売されましたが、その後、機能拡張が図られ、DB2 V8に統合されました。DB2は、先ほど説明した機能に加えて「ラッパー」アーキテクチャーをサポートしており、プログラマーは選択したデータ・ソースのみにアクセスするように連合DBMSをカスタマイズできます。IBMでは、連合DBMSとさまざまなリレーショナルおよび非リレーショナル・データ・ソースとのインターフェースを実現する各種DB2用ラッパーを用意しています。リレーショナル・データ・ソースには、DB2ファミリーの全製品、MicrosoftR SQL Server、Oracle、Sybase、InformixRなどが含まれます。サポートされるデータ・ソースと使用可能なラッパーの全リストについては、DB2 V8ベータ・ライブラリーをダウンロードし、「Federated Systems」に関する資料をご覧ください。DB2 V8ライブラリーならびにDB2 V8製品は、DB2ホーム・ページ(http://www.ibm.com/jp/software/data/download/)のリンクからダウンロードできます。

図1に、連合DBMSサーバー・アーキテクチャーの例を示します。JDBCアプリケーションは、異なるプラットフォーム上の3種類のデータ・ソースにアクセスするように構成された連合DB2サーバーに接続します。これによって、JDBCアプリケーションがこれらのデータ・ソースのいくつか、または全部をまとめて透過的に扱うことが可能となります。さらに、これらのデータ・ソースにまたがるビューを作成することも可能なため、読み取り専用アプリケーションのデータ統合の問題が単純化されます。

図1. 3種類のリモートDBMSにアクセスするように構成された連合DBMS環境の例

Federated DBMS

もちろん、DB2は表、ビュー、索引など、自らのローカル・データ・オブジェクトを保管し、管理することができます。DB2のオプティマイザーは、本質的に異なり物理的に分散した環境を考慮し、照会ごとに効率的なデータ・アクセス方法を選択できるように設計されています。ラッパーを作成する際にコスト見積もり情報を提供することで、オプティマイザーがカスタム・データ・ソースを処理するときに効率的な選択を行えるようにすることができます。ただし、この記事の執筆時点では、2フェーズ・コミット処理はサポートされていません。したがって、プログラマーは、複数のデータ・ソースからのデータの挿入、更新、または削除を1回のトランザクションで行わないようにする必要があります。

Webアプリケーション・サーバー

Webアプリケーション・サーバーは、企業がサーバー・サイド・ビジネス・ロジックを管理し、配置するのに役立ちます。このロジックは、一般にJavaで作成され、多層からなるインターネット、イントラネット、およびエクストラネット・アプリケーションをサポートするのに不可欠です。このロジックのインプリメントには、アプリケーションのニーズに応じてさまざまなテクノロジーを利用できます。テクノロジーの例としては、Java Server Pages™(JSP)、Javaサーブレット、EJB、Webサービスなどがあります。これらのテクノロジーの一部については、このあとで説明します。

図2は、Webアプリケーション・サーバー環境の例です。中間層サーバーは、さまざまなリモート・クライアントからの要求を管理できます。中間層には、HTTP Webサーバー(IBM HTTP Serverなど)に加えて、Webアプリケーション・サーバー(IBM WebSphere Application Server Advanced Editionなど)もインストールされています。アプリケーション・サーバーは、EJBやWebサービスなど、クライアント・アプリケーションを支えるのに必要な機能を実行するさまざまなテクノロジーをサポートしています。それらの機能の中には、さまざまなベンダーのローカル・データ・ソースまたはリモート・データ・ソースへのアクセスがあります(ただし、図にはローカル・データ・ソースへのアクセスのみを示しています)。

図2. ローカルのDBMSとともに構成したWebアプリケーション・サーバーのインストール例
図2. ローカルのDBMSとともに構成したWebアプリケーション・サーバーのインストール例

Webアプリケーション・サーバーには、ローカル・データまたはリモート・データへの効率的なアクセスをサポートするためのさまざまな手法が採用されています。たとえば、コネクション・プーリングはリソースを節約し、データ・ソースに対して新規接続を作成する(その後、接続を終了する)ことによるオーバーヘッドがソフトウェア・コンポーネントに繰り返し生じることを防止できます。EJBの場合、トランザクション属性と分離レベルを適切に設定することによって同時データ・アクセスを改善することができ、場合によってはデッドロックを最小限に抑えることも可能です。

連合DBMSテクノロジーは、Webアプリケーション・サーバーが提供する標準のデータベース・サポートを補完することができます。連合DBMSテクノロジーを利用すれば、複数のデータ・ソースにわたる結合や合併は、1つのSQLステートメントを記述するだけというシンプルなものになります。これは、各データ・ソースに個別に接続し、それぞれのネイティブAPIを使用して必要なデータを抽出し、データのフィルター操作、ソート、統合を手動で行う従来の方法と比べてかなりの改善です。従来の方法は複雑で、誤りを犯しやすいだけでなく、高いパフォーマンスを確保できる見込みがほとんどありません。しかも、このようなシナリオでは、ソフトウェア開発者はグローバルな最適化の問題に手作業で対処せざるを得ず、リモート・データに関する重要な統計を維持するグローバル・カタログの恩恵を受けることができません。

連合DBMSは、複数のソースにまたがるデータへの透過的かつ効率的なアクセスを実現するだけでなく、物理的に保存されるものも動的に生成されるものも含めて、アプリケーション・サーバーがネイティブではサポートしていないリモート・データにも対応できるようにWebアプリケーション・サーバーの「守備範囲」を拡張することができます。

Enterprise JavaBeans(EJB)

EJBは、コードの再使用を促進することを目的とするサーバー・サイド・ソフトウェアJavaコンポーネントで、トランザクション管理、セキュリティー、永続性など、実動アプリケーションにとって重要な機能を標準でサポートしています。Javaクライアント・アプリケーションは、IIOP(Internet Inter-Orb Protocol)によるリモート・メソッド呼び出し(RMI)を使用して直接EJBにアクセスできます。それに対して、Webクライアントは間接的にEJBにアクセスします。つまり、まずHTTPを使用してHTTPサーバーと通信し、そのHTTPサーバーが、EJBにアクセスするサーブレット、JSP、またはWebサービスを呼び出します。図3に両方のアプローチを示します。

図3. HTTPベースのクライアントと「従来型」のJavaアプリケーションのいずれもEJBを使用可能

EJBは、Webアプリケーション・サーバー上で動作するコンテナー内に配置されます。ここではEJBコンテナーの役割について詳しく取り上げませんが、注目すべき点はこれらのコンテナーが永続性をサポートできるということです。ある種のEJBは、ターゲット・データ・ソースへのアクセスのインプリメントと管理にコンテナーを利用します。これは、EJB開発者にとって、データ・アクセス・ルーチンを作成する必要がなくなるだけでなく、作成したBeanのDBMS間の移植性を高めるのにも役立ちます。連合データに対してそうしたBeanを作成する方法、またそのようにするのが有利な場合についての説明は次回以降の記事に回し、今回はEJBの概要についての説明を続けます。

EJB 1.1仕様では、本質的に一時的なものであるSession EJBと、永続的であるEntity EJBという2種類のBeanを定義しています。Session Bean自体はステートレスとステートフルのどちらにもすることができるため、Session Beanの開発者は、サポートされるDBMSに対する読み取り/書き込みアクセスにJDBCを利用できます。実際に、多くのSession Beanは何らかのデータベース操作やトランザクション処理を行う目的で作成されます。ただし、Session Beanに関連するデータはすべて一時的なものとみなされるため、コンテナーが自動的に永続性をサポートすることはありません。それに対して、Entity EJBは、永続データを保有するものとみなされます。開発者は、(Bean管理による永続性を介して)この永続性を各自で管理することも、(コンテナー管理による永続性を介して)この責任をコンテナーに委譲することもできます。

EJBは、タイプごとにEJB開発者に課せられるコーディングの要件が異なります。これは、クライアントが利用できる最低限のサービスがある程度異なるということです。EJBのさまざまなタイプについての詳細、また連合データに及ぶSession BeanおよびEntity Beanの作成方法については、次回以降の記事で取り上げます。

Webサービス

Webサービスは比較的新しいテクノロジーですが、Webサービス対応製品は、IBM、Microsoft、Oracle、Sun Microsystemsをはじめとする主要ベンダーからすでに発表または出荷されています。Webサービスを扱ったことがない方も、その基本概念は聞き覚えのあるものであるはずです。

Webサービスは、アプリケーションまたは他のWebサービスがプログラムに基づいてインターネットを介して呼び出すことができる一連のビジネス機能です。したがって、Webサービスは分散コンピューティングを容易にするだけでなく、相互運用性を促進するように設計されています。HTTP、Extensible Markup Language(XML)、Simple Object Access Protocol(SOAP)、Webサービス定義言語(WSDL)、Universal Description, Discovery and Integration(UDDI)をはじめとするさまざまな基本テクノロジーが、Webサービスを支えるのに重要な役割を果たしています。Webサービス・プロバイダーはWebサービスを公開し、クライアントがSOAP over HTTPを使用してこれらのサービスにアクセスできるようにします。クライアントの要求があると、Webサービスはビジネス機能を呼び出し、通常はクライアントに応答を返します。Webサービス自体は、リポジトリー(UDDIレジストリーなど)またはWebサービス・プロバイダーのサーバーに保管されたWSDL文書によって記述されます。Webサービス記述を適切なリポジトリーに保管することによって、関心のある顧客がその存在を発見し、場合によってはWebサービス・プロバイダーにとって新しいビジネスが生まれる可能性も出てきます。

Webサービスの開発によく利用されるプログラミング言語はJavaです。したがって、DBMSデータに頻繁にアクセスする必要があるWebサービスは、JDBCを利用します。連合データベース・テクノロジーを利用してそうしたWebサービスを作成する方法については、次回以降の記事で取り上げます。


WebSphereとDB2連合テクノロジーのアーキテクチャー例

読者の皆さんは、どのように構成すればDB2の連合テクノロジーとWebSphere製品が連携できるのかそろそろ知りたいとお考えのことと思います。考えられるインストール・オプションは1つではありませんが、ここでは著者自身が社内プロジェクトで使用した構成について説明します。開発プラットフォームとして使用したのはWindows NTR 4.0ワークステーションです。このマシンで、DB2 V7.2(FixPak 6適用済み)のクライアント・ソフトウェアとともに、WebSphere Studio Application Developer Integration Edition(WSADIE)4.1を稼働しました。WSADIEは、Java IDE(統合開発環境)を備え、WebSphere Application Server 4.0.2のシングル・サーバー版を含んでいるため、連合データにアクセスするように作成したEJBおよびWebサービスのテスト・ベッドとして使用しました。

DB2 V8のインスタンスは、リモートのAIX 4.3.3サーバーに置きました。この作業ではプリベータ・レベルの各種ドライバーを使用しましたが、これらのドライバーがサポートする機能はすでにDB2 V8のオープン・ベータの一部となっています。DB2サーバーは、リモートのOracle、Sybase、Microsoft SQL Server DBMS内のデータにアクセスできる連合DBMSとして機能するように構成しました。DB2は、DB2 for OS/390™、z/OS™、Informix®など、他のデータ・ソースへのアクセスをサポートしていますので、使用した3種類以上のデータ・ソースに関係する連合データベース環境を構築することはもちろん可能です。ソフトウェアの前提条件と構成プロセスは、関係するデータ・ソースによって異なるため、ここでは詳しく説明しませんが、作業環境のセットアップに必要な事項の概要がつかめるように基本的な手順だけを概説します。詳細については、DB2 V8ベータのマニュアルをご覧ください。

DB2クライアントとDB2サーバーの構成

DB2クライアントがリモートDB2サーバーに接続できるようにするに当たって、まず基本的なネットワーク接続が機能することを確認します。通信ネットワークとしてはTCP/IPを使用し、使用するサービス名とポート番号を指定するエントリーを各システムのservicesファイルに追加しました。

DB2サーバーの構成に当たっては、SVCENAMEおよびFEDERATEDのプロパティーを設定し、データベース・マネージャー構成を更新しました。ローカルに作成したDB2データベース(この環境ではrdjdb)に接続した後、アクセスしたいデータ・ソース(Oracle、Sybase、およびMicrosoft SQL Serverの各DBMSの1つのインスタンス)ごとに、必要なラッパー・オブジェクト、サーバー・オブジェクト、およびユーザー・マッピングを作成しました。以下の例に、この作成に使用したスクリプト・ファイルに含まれるコマンドを示します。イタリックで示した項目は、筆者の環境に固有のものです。

db2 update dbm cfg using svcenamemyID authentication server 
db2 update dbm cfg using federated yes db2 connect reset
db2stop
db2start 
db2 connect tordjdb user user1 using pass1word

db2 create wrapper net8 options (DB2_FENCED 'N')

db2 create server oracle8 type oracle version 8.1.5 wrapper net8 authorization 
  oracleuser1    password oraclepwd options (node'oracle8.world', password 'Y', 
  pushdown 'Y')

db2 create user mapping for user1server oracle8 options ( REMOTE_AUTHID 
oracleuser1', REMOTE_PASSWORD'oraclepwd' )
. . .

DB2クライアントの構成には、DB2クライアント構成アシスタント(Client Configuration Assistant)を使用するか、あるいはDB2コマンド行プロセッサーからステートメントを発行します。この場合は後者の方法を採り、DB2サーバーが属するリモート・ノード(この例ではblackcat.ibm.com)を確認するステートメントと、使用するリモート連合データベースの論理データベース名(djdb)を指定するステートメントを発行しました。どちらの方法でクライアントを構成するにせよ、連合環境に依存するJavaアプリケーションまたはコンポーネントの開発に際しては、構成をテストして基本的な接続が機能することを確認した方がよいでしょう。

以下に、クライアント構成を完成するために使用したスクリプトの概要を示します。先ほどと同様に、イタリックで示したテキストは筆者の環境に固有のインプットです。

db2 catalog tcpip node <i>fednode</i> remote <i>blackcat.ibm.com</i> server <i>myID</i> 
db2 catalog database <i>rdjdb</i> as djdb at node <i>fednode</i> 
db2 terminate 
db2stop 
db2start 
db2 connect to <i>djdb</i> user <i>user1</i> using <i>pass1word</i>

透過的なデータ・アクセスの実現

透過的なデータ・アクセスを実現するための最後のステップとして、アクセスしたいリモート・データに対してニックネームを作成しました。これには少なくとも2つの方法があります。既存のリモート・データの場合、CREATE NICKNAMEステートメントを使用して、リモート・オブジェクト(Oracleデータベース内に格納されている表など)をDB2が理解できるニックネームにマッピングします。そうすると、アプリケーションは、(SET PASSTHRUステートメントを使用して)Oracleシステムに手動で接続して表を直接参照するのではなく、ニックネームを参照して該当するOracle表内のデータにアクセスできるようになります。以下は、連合データベースに接続し、リモートOracleシステム内に存在する「budget」表に対して「budget」というニックネームを作成する場合の例です。

db2 connect to djdb user user1 using pass1word
db2 create nickname budget for oracle8.oracleuser1.budget

一方、リモート・リレーショナルDBMS上に新規データ・オブジェクトを作成して、それらをニックネームにマッピングする必要がある場合、たいていはDB2のデータ定義言語(DDL)透過性機能を使用するのが最も簡単です。そうすることで、作成する必要があるSQLステートメントの数が最小限に抑えられます。CREATE TABLE ... WITH OPTIONSステートメントを発行すると、リモート・データ・ソースへの表の作成と、この表に対応するDB2ニックネームの作成という2つのタスクを行うことができます。以下は、リモートOracleシステムに「project」表を作成し、それに対応するニックネーム「project」をDB2連合データベース内に作成する場合の例です。

db2 connect to djdb user user1 using pass1word 
db2 create table project ( 
ID int primary key not null, 
name varchar(30), 
managerID varchar(10)) 
options (remote_server 'oracle8', remote_schema 'oracleuser1')

Java IDEとWebアプリケーション・サーバーの構成

中間層サーバー・コンポーネントを作成するのに必ずJava統合開発環境(IDE)を使用しなければならないというわけではありませんが、プロセスのスピードアップと簡素化が図れることは確かです。先ほど述べたように、IBM WSADIE 4.1をインストールしましたが、これにはWebSphere Application Serverのテスト用のバージョンが含まれています。前のセクションで概説した作業が完了していれば、後はほとんど何もせずに、WSADIEと組み込み版WebSphereがDB2連合データを扱えるようにすることができます。

WSADIEでサーバー・サイドJavaコンポーネントやWebサービスを開発する場合、プロジェクトに関連するJavaビルド・パスにdb2java.zipファイルの場所が含まれていることを確認してください。このファイルは、DB2のインストール先の\javaサブディレクトリーの中にあります。たとえば、DB2がc:\sqllibディレクトリーにインストールされている場合には、WSADIEプロジェクトのJavaビルド・パスにc:\sqllib\java\db2java.zipを指定する必要があります。

また、連合サポート用に構成したDB2データベースにマッピングするDataSourceオブジェクトを、WebSphere環境内に作成する必要がある場合もあります。DataSourceオブジェクトはJDBC仕様の一部で、WASではコネクション・プーリングに使用されます。DataSourceの作成は簡単で、WSADIEに含まれるWebSphereテスト環境とWebSphereのスタンドアロン版のどちらにも、DataSourceを作成することができるグラフィカル・ツールが用意されています。その際、ターゲット・データ・ソースに対する名前、ユーザーID、およびパスワードを指定する必要があります。この環境では、JDBC URL「jdbc:db2:djdb」に対してjdbc/FederatedというDataSourceを定義し、ユーザーIDはuser1、パスワードはpass1wordにそれぞれ設定しました。DataSourceの詳細と使用例については、次回以降の記事で取り上げます。


配置を成功させるためのヒント

これまでの説明で、連合DBMSテクノロジーがWebアプリケーション開発環境にもたらす利点について、だいたいおわかりいただけたかと思います。また、セットアップに通常必要な事柄も理解いただけたものと思います。WSADIE、WebSphere、および連合DBMSテクノロジーの組み合わせを魅力的に感じた方は、使用する環境でこれらのテクノロジーの配置を成功させるため、いくつかの方法について検討するとよいでしょう。以下に検討すべきヒントを示します。

  • すべてのソフトウェア・テクノロジーを統合する前に、アーキテクチャーのサブコンポーネントが正しく機能していることを確認します。たとえば、WSADIEまたはWebSphere Application Serverを使用してDB2を統合する前に、必要なすべてのバックエンド・データ・ソースに対してDB2環境が適切に構成されていることを確認してください。これは、インストール関連の問題のデバッグに役立ちます。
  • 使用する製品に対して用意されている問題診断ツールに慣れるよう努めます。特に、デバッグの際はなるべく早い段階で障害の発生源を特定するように心がけてください。たとえば、データベース・アクセス・アクティビティーに障害が発生した場合、該当するSQLステートメントを突き止めて、DB2連合データベースに接続されたDB2コマンド行プロセッサーからそのステートメントを実行すると、原因を絞り込みやすくなります。
  • 使用する製品に対して用意されているパフォーマンス・モニタリングとパフォーマンス・チューニング機能を理解します。データベース関連のアクティビティーが遅すぎるように思われる場合は、データベース管理者に協力を求めてください。適切な索引の追加やカタログ統計(グローバルな最適化のためにDB2が保持する情報を含む)の更新などのアクティビティーは、パフォーマンスにかなり大きく影響する可能性があります。
  • 作業を支援するためにリモート・リレーショナル・データ・ソースに新規データ・オブジェクトを作成する必要がある場合は、DB2のDDL透過性機能の使用を検討します。これによって時間を削減し、作業を簡素化することができます。

参考になるWebサイト

謝辞

このプロジェクトを技術的に支援してくれたVander Alves、Jordan Barnes、Dirk Wollscheidに感謝します。


参考文献

  • Charles J. BontempoおよびC. M. Saracco共著、「Data Access Middleware: Seeking Out the Middle Ground」、InfoDB、Volume 9 Number 4、August 1995(http://www.middlewarespectra.com/abstracts/5_96_07.htmから注文できます)
  • Charles J. BontempoおよびC. M. Saracco共著、Database Management: Principles and Products、Prentice Hall、1995、ISBN 0-13-380189-6(特に第9章をご覧ください)
  • Graham Glass著、「The Web services (r)evolution」、(IBM developerWorks(http://www.ibm.com/developerworks)に掲載の連載記事)
  • Laura Haas およびEileen Lin共著、IBM Federated Database Technology、DB2 Developer Domain(IBM 連合データベース・テクノロジー、2002年3月)
  • Richard Monson-Haefal著、Enterprise JavaBeans、O'Reilly and Associates、1999、ISBN 1-55860-519-3
  • Micks Purnell著、Fundamentals of IBM DB2 Federated Server and Relational Connect (IBM DB2連合サーバーとリレーショナル・コネクトの基礎(PDF形式/371KB)、2002年6月)
  • M. Tork RothおよびP. Schwarz共著:「Don't scrap it, wrap it! a wrapper architecture for legacy sources」、Proceeding of the 23th VLDB Conference、Athens、Greece、1997 (http://citeseer.nj.nec.com/roth97wrapper.htmlからダウンロードできます)
  • C. M. Saracco著、An Introduction to Data Access Middleware、IBM Corp.、Technical Report STL 03.529、October 1993
  • C. M. Saracco著、Universal Database Management: A Guide to Object/Relational Technology、Morgan Kaufmann、1998、ISBN 1-55860-519-3(特に第9章をご覧ください)
  • Jeffery C. Schlimmer編集、Web Service Description Requirements、Working Draft、W3C(最新のドラフトは、http://www.w3.org/TR/ws-desc-reqsからアクセスできます)
  • Seth White他共著、JDBC API Tutorial and Reference、Second Edition、Addison-Wesley、1999、ISBN 0-201-43328-1

学ぶために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=323093
ArticleTitle=Webアプリケーションで異種データに対処する
publish-date=08222002