この仮想パネルでは、 InfoQ.com (Floyd Marinesce) の編集者たちとODBMS.org (Roberto V. Zicari) が、永続化ソリューションをリードするアーキテクトのグループに対し、Javaコミュニティにおける永続化技術の現在の状態について、彼らの見解を伺いました。
パネリスト:
- Mike Keith: JPA 1.0 仕様策定者の一人であり、Oracle TopLinkとJava永続化技術のアーキテクト
- Ted Neward: 独立系コンサルタントで、ORMと永続化のトピックについて良くブログを書いている
- Carl Rosenberger: オープンソースの組み込み型オブジェクトデータベース、db4objectsのリード・アーキテクト
- Craig Russell: Java Data Objects (JDO) JSRのスペックリードであり、Glassfish以前のSunのアプリケーションサーバにおいて、エンティティビーンエンジンのアーキテクトを努めていた人物
質問:
- 我々は未だに"インピーダンスミスマッチ問題"を抱えているのでしょうか？(source)
- 新しいプロジェクトにとって、永続化技術には様々な選択肢がありますが、あなたはそれらをどのように位置づけていますか？現在業界で使われているもの、と言う観点からお答えください。(source)
- こうした既存のソリューションの賛否について、あなたの意見をお聞かせください。(source)
- "オブジェクトを永続化する"と言う事に関して、オブジェクトとリレーショナルをマップすることが適切なソリューションだと信じていますか？その理由は？(source)
- "オブジェクトを永続化する"と言う事に関して、リレーショナルデータベースこそが適切なソリューションだと信じていますか？その理由は？(source)
- "オブジェクトを永続化する"と言う事に関して、オブジェクトデータベースこそが適切なソリューションだと信じていますか？その理由は？(source)
- オブジェクト永続化の分野において、これから12ヶ月の間に新しく研究開発が行われるとしたら何を期待しますか？(source)
- もしあなたが全能で、ここ10年間に置けるテクノロジー採用に影響を及ぼしていたとしたら、今日の典型的なプロジェクトは永続化メカニズムとして何を使っているでしょうか？その理由は？(source)
- このトピックに関して、最後に何かありますか？(source)
Q1: 我々は未だに"インピーダンスミスマッチ問題"を抱えているのでしょうか？
Mike Keith: リレーショナルデータモデルからの読み出しや書き込みにオブジェクトモデルが用いられる限り、インピーダンスミスマッチは存在します。このミスマッチを解決するための戦略も、技術も、ツールも存在しない場合にそれは問題となり、結果として複雑な設計やひどいパフォーマンス悪化を引き起こします。こうした状況を引き起こすシナリオは常に存在します。それは単純に、ミスマッチの性質そのものが理由です。技術とツールは大いに助けとなり、非常に多くのアプリケーションが抱えるニーズを満たしてくれます。しかしそれは、水をワインに変える（不可能を可能にする）ようなものではありません。
Ted Neward: もちろんです。私たちが、一時的にせよ長期的にせよ異なるデータの'形'を持ち続ける限り - 一時的なデータはオブジェクトの形で保持し、それをリレーショナルデータストア内で長期的に保持する、と言う現在のジレンマのように - インピーダンスミスマッチ問題を持ち続けることになるでしょう。オブジェクトをリレーショナルに、オブジェクトを階層構造/XMLに、階層構造をリレーショナルに・・・などは全てインピーダンスミスマッチの問題であり、全て同じように基本的な問題に直面します: 丸いものを、四角や三角の穴に無理矢理押し込むと言った問題です。一つの解決策としては、こうした異なる'形'を私たちのツールに組み込んでしまうことです。例えば、「集合」をプログラミング言語のファーストクラスな概念として追加すれば、データストア内で集合を取り扱うのが楽になります。しかしそれこそが、我々がこれまでも行い続けていたことです。
Carl Rosenberger: いいえ。ただしあなたがリレーショナルデータベースと縁を切ることができないのであれば別です。では、特定の二つの言語を用いた観点から見てみましょう。JavaとSQLです:
Java では、小さくて単純、そして簡潔な、理解が容易なメソッドを書くのに関しては非常に生産的です。リレーショナルデータベースにはナビゲーションという概念がなく、データベース外で何かを行うためには、テーブルスキーマを知っている必要があります。「ある従業員の、ボスがもらっている給料を知りたい」と思ったらどうするか、想像してみてください。Javaと自動補完機能付きのIDEを使うなら、あなたは以下のようなコードを数秒で書くことができます。:
employee.department().manager().salary();
SQLを使うなら、同じ処理を行うのに以下のようなSQL文を考えださねばなりません。数分を必要とするでしょう...
SELECT e2.salary FROM
employee e1, employee e2, department,
WHERE
e1.id = current_employee_id
AND
e1.department = department.id
AND
department.manager = e2.id
... さらにこの文法が正しいこと、そして従業員テーブルに対する二つの参照を混同しないことを保証できるでしょうか？
アプリケーションを記述するのにJavaとSQLを両方使わなければならないとしたら、二つの全く異なる言語間のインターフェースのために、開発の時間、品質、効率、パフォーマンスを犠牲にすることになるでしょう。
二つの全く異なるコードベースを保守するためのオーバーヘッドは、必要とされる作業量を二倍以上にし、リファクタリングとアジャイルプロセスを不可能にします。
オブジェクトデータベースを用いれば、いついかなる時でもオブジェクト技術を使うことができるため、そこにはインピーダンスミスマッチが存在しません。
Craig Russell: それはあなたの業務ドメインとあなたの言語に依存しています。もしあなたがC++で作業していて、ドメインのモデリングのために多重継承を利用（悪用）しているとしたら、リレーショナルデータベースにドメインオブジェクトを保存するのは依然として多くの作業を必要とするでしょう。
もっとも重要なことは、データベースに既に存在しているものを表現するためにJavaドメインオブジェクトを使うのか、それともJavaドメインオブジェクトを保存するためにデータベースを使うのか、と言うことです。前者の状況では、ほとんどのリレーショナルスキーマをJavaドメインオブジェクトでうまく表現できます。Javaドメインオブジェクトをリレーショナルデータベースに保存しようとするのであれば、ミスマッチが起きる機会がより多くなります。
こうした場合は、インピーダンスミスマッチが起きる分野が少し残っています。例えば、コレクションをモデリングするのは、リレーショナルスキーマでは困難です。ODMGでは、Javaのコレクションと論理的には等価なBagをモデリングしました。Javaコレクションフレームワークでは、Bagの正しいセマンティクスを持つ具象クラスは存在しません。最も近いのはArrayListですが、この型を永続化する際には、追加の情報を人工的に生成する必要があります（オブジェクトの重複を取り扱うには、データベースに人工的なカラムを作るか、プライマリキーを持たないテーブルを用います）。
インピーダンスミスマッチが生じる他の分野は「継承」です。実際の多くのリレーショナルスキーマでは、識別用のカラムを含めるようにし、行の間でサブクラスの型を見分けるために利用します。しかしやはりリレーショナルスキーマは、Javaの継承概念とは正確にはマッチしません。このテクニックは、現存するO/Rマッピングソリューションの多くよりも前から存在していました。
Q2: 新しいプロジェクトにとって、永続化技術には様々な選択肢がありますが、あなたはそれらをどのように位置づけていますか？現在業界で使われているもの、と言う観点からお答えください。
Mike Keith: 前提として、非常に多くのプロジェクトがデータストアとしてRDBを必要としていると仮定します。すると、永続化に対する人々の要求はだいたい1?3のカテゴリに集約されます。どこに分類すべきか微妙なケースや、わずかな例外は常に存在しますが、Javaオブジェクトの永続化を行っている現在主流のアプリケーションは、ほとんどがこの3カテゴリにマッチすると思われます。:
- JDBC - 多くの開発者は、様々な理由から、依然としてJDBCに依存しています。恐らく彼らはマッピング層を必要としないか、好きではないか、単に雇い主が許してくれないのでしょう。どんな理由にせよ、JDBCは依然として選択肢として生き残ります。適切な方法で使用するか。正当な理由を持って利用するなら、いくつかのアプリケーションにはぴったりフィットするでしょう。
- 軽量なカスタムフレームワーク - SQLを手作業で書く必要のある人々は、その上に薄い層を置くことで、コードの可読性と保守性を向上できると言うことをときどき発見します。こうしたアプリケーションにとっては、単純なJDBCフレームワークや、自分たちの開発手法とコーディングプラクティスに最適化された、自家製のソリューションでも機能的には十分です。
- ORM - オブジェクト・リレーショナルマッピングツールはメタデータモデルを含んでおり、いかにしてオブジェクトの状態を保存するか、そしてデータベースから読み出すかが記述されています。ORMテクノロジーでハッピーになっている人々はたくさんいますし、彼らは自分たちのニーズを満たすために、ORMテクノロジーを使います。Java Persistence API (JPA)は、非エンタープライズJava環境でも、Java EE環境でも動作する、スタンドアローンのORM APIです。
SOA の人気が上昇するにつれ、XMLの受け口に対して単にJavaオブジェクトを送りつける必要がある、と言うアプリケーションも増えてきました。結局のところ受信側は、Webサービスのポートか、BPELプロセスか、遅延処理のためのキューという形式を取ります。オブジェクトをXMLにマップすると言う機能は、JAXBやSDOと言った標準によって提供されています。さらにEclipse Persistence Serviceのように、こうした標準を全て実装した上で機能追加を行ったものも存在します。
Ted Neward: 非常に多くの選択肢があり、それぞれが利点と欠点を持っています。Mikeはコアとなる選択肢を三つに要約するという素晴らしい仕事をしました。私はそれに少し付け加えたいと思います:
- ストアドプロシージャは、あらゆる保存／検索のロジック（そしてときどき、データ中心のビジネスロジック）を、データベース内の実行可能なコードとして置きます。Java、C++、C#、Rubyなどで書かれたあらゆるアプリケーションが、ロジックを集中化させがちなのと同様です。しばしばストアドプロシージャは、ストレートなJDBC/call-level-interfaceアプローチと組み合わせたり、O/Rマッピンングアプローチと組み合わせて、プロシージャの呼び出しや結果の取得を単純化されます。
- オブジェクトデータベース（OODBMS）は、実際のオブジェクト自身をデータベースに保存します。Carlが詳しく説明するものです。
当然ながら、上で述べたアプローチには様々なハイブリッドなアプローチが存在しますが、ほとんどはこうして分類できます。
Carl Rosenberger: 人々がデータベースについて語るとき、彼らは通常多くの異なるユーザやアプリケーション、プログラミング言語によって使われる大規模データベースを意味します。こうしたレガシーなデータベースに対しては、今後長きにわたってSQLが使われていくでしょう。
近い将来、我々は50億の携帯電話と、わずか20億のPCを持ちます。デバイス上のアプリケーション（そしてデバイス上にデータベースが乗ります！）向けの市場は、PC上の市場を超えて成長するでしょう。
デバイス上データベースに共通するのは:
- 一つのプログラミング言語しか扱わない
- DBアクセスをチューニングするDBAが存在しない
- ユーザがデバイスに対して、アドホックな問い合わせを手でタイプすることはない
デバイス上のアプリケーションがオブジェクト指向言語で書かれるとしたら、リレーショナルデータベースやSQLを使う理由があるのでしょうか？
私はそうは思いません。
Microsoftは、LINQを非常に強く喧伝しています: 彼らはSQLから脱却し、データベースアクセスに対して、プログラミング言語としての全体的な概念を打ち出しています。
これは新しいプロジェクトにとっての未来像です。その理由は単に、それが開発とコードの保守に対するもっとも効果的な方法だからです。
LINQの採用により、関数型言語の概念は、データベースへの問い合わせにおける主要な標準として受け入れられるでしょう。
私自身のオブジェクトデータベース自身にも関連して、私は非常に喜ばしく思っています。私たちにとって嬉しいのは: LINQは通常のC#メソッド呼び出しをクエリ内で使用できる、つまり（オブジェクトの）ナビゲーションを行うことができるのです。オブジェクトデータベースは、RAMにおけるオブジェクトの表現と非常に近い形でオブジェクトを物理的に保存します。そのため、オブジェクトデータベースはリレーショナルデータベースよりもLINQを最適化できるのです。（例えば）オブジェクトデータベースがナビゲーションのために直でポインタを使用できる場合でも、リレーショナルデータベースではジョインのために二つのインデックスを見に行く必要があります。
LINQはオブジェクトデータベースベンダにとっての夢です。オブジェクトデータベースの問い合わせに関する標準がいきなり登場しただけではなく、あらゆるリレーショナルシステムを上回るパフォーマンスを実現するのがいとも簡単なのです。
JavaにLINQのような標準が現れるのを非常に期待しています。Native Queriesを通じて、我々は非常によく似たアプローチを提供しています。100%プレインなJavaを用いて、データベースクエリを生成することができるのです。
我々の製品が強みを発揮している分野の中から、業界の需要が最も強い分野を挙げてみましょう:
- メモリ使用量を抑えながら高いパフォーマンスを必要とする、リソースに制約のあるデバイス向けのアプリケーション
- 多くの属性を持ち、なおかつ/もしくは、深い継承階層を持つような、複雑なクラスからなるアプリケーション
- クラスが頻繁にリファクタリングされ、RDBとそのマッピングを保守するのが悪夢のようなアプリケーション
- 非常に素早く市場に投入する必要のあるアプリケーション
- Eclipse RCP、JavaFX、Silverlightなどのテクノロジーで書かれた、リッチクライアントアプリケーション
最もハッピーな顧客がこうした分野にいることから、今日のオブジェクトデータベースがその利点を最大限発揮できるのはここだと結論づけています。
Craig Russell: ユビキタスなJDBCプログラミングモデルは、JavaとSQLに関しては最も抽象度が低いレベルです。JDBCを使うと、最大限のコントロールを行うことができ、ドライバやデータベースの全機能を利用することができます。しかしそれは最も取り扱いが困難で、それ自体を抽象化することもできません。
リソースプールを実装したライブラリを使えば、追加のコードを書くことなくパフォーマンスを向上させられることには、多くのプログラマが気づいています。しかし、SQLを正しく取り扱うのはやはり困難です。さらに、PreparedStatementやResultSetの取り扱いにもやはり骨が折れます。
高いレベルのツールとしてはiBATISなどがあります。iBATISは、PreparedStatementやResultSetを扱うための単調な仕事の多くを不要にします。しかし、依然としてデータベースに強く依存したSQLの記述を必要とする上、マッピングされたドメインオブジェクトを利用する必要があります。
私が知っている中で、Javaにおける最も高いレベルのツールとしては、O/Rマッピングソリューションです。 Enterprise Java BeansのCMPや、JPOX、OpenJPA、Hibernate、TopLink、Cayenneなどを挙げることができます。Java Persistence APIとJDOはJCP標準であり、こうしたソリューションの多くで実装されています。こうしたツールは非常に高いレベルのオートメーションを実現します。Javaドメインオブジェクトからデータベーススキーマを生成するのと同様、データベーススキーマからJavaドメインクラスを作成することの両方が可能です。
Java言語の外に目を向けると、GrailsとRuby on Railsがあります。非常に高い機能と、さらにWebフレームワークも提供しており、Webサーバとのやり取りを手で組み立てる、と言った退屈な作業からプログラマを解放してくれます。
Q3: こうした既存のソリューションについての賛否について、あなたはどんな意見をお持ちですか？
Mike Keith: これは分厚い本を書ける類の質問です。そして、「いつ、どこで、どのソリューションを使うべきか」と言う議論には、恐らく終わりがありません。私個人の意見を簡潔に述べさせていただくなら、それらには個々に得意分野があり、すべてのアプリケーションに対して最適な選択肢となりうるようなソリューションは存在しないと言うことです。私の望みとしては、ソリューションを選択する前に、アプリケーションのリソースのうち30%程度をそれに割く計画を立てる、と言った多少の下準備をしていただきたいと言うことです。
Ted Neward: この答えは非常に長くなりますし、今ここで私が述べる答えよりも遥かに複雑です。
Carl Rosenberger: オブジェクト指向を実践することによる、重要な利点の一つとして、長い期間にわたる保守のコストが軽減されると言うものがあります。もしオブジェクトデータベースを使用したとしたら、データモデル（クラスやその他のもの）や、それと対話するすべてのコードにまで、この利点を拡大することができます。
オブジェクトデータベースを使用することで、あらゆるコードを一つのプログラミング言語で書けるようになります。近代的なIDEを使えば、リファクタリングは最大限自動化されます。.
オブジェクトデータベースを使用することで、データベースと対話するすべてのコードを含め、コードをコンパイル時に100%チェックできます。
仮想マシンがRAM上で行うのと全く同じ方法で、オブジェクトデータベースはオブジェクトの参照を取り扱うことができるので（インデックス付けされたタプルではなく、一方向のポインタを使う）、オブジェクトデータベースはリレーショナルデータベースよりも遥かに速いです。
ネイティブに組み込まれたオブジェクトデータベースは、アプリケーションと同じVM内で動作します。そのため、データベース内に深く立ち入ったプロファイリングや、ボトルネックとなっているユースケースのチューニングを行うことができます。これは、マシンのパフォーマンスとメモリが制限されているような携帯電話やハンドヘルドデバイス上で組み込んで使用する際、完璧な選択肢となります。
SQLは理解が容易です。長い歴史があるため、成熟したSQLデータベースの選択肢がありますし、SQLシステムを書き、チューニングし、問い合わせを行うための成熟したツールも数多くあります。
SQLは、アドホックな問い合わせと、アドホックなデータ集積については、広く受け入れられている標準です。
Craig Russell: 一般的には、より高いレベルの抽象化が進めば、アプリケーションを書き、デプロイするのが速くなります。
しかしいくつかのアプリケーションでは、データベースのパフォーマンスを最大限享受するために、直接SQLを使用する必要があります。
従って、あなたはデータベース固有のSQL方言を深く理解する必要はあります。しかしほとんどのツールは、ほとんどの作業を高い抽象度の上で行うことができます。SQLにダイブする必要があるのは、いざと言うときだけです。
Q4: "オブジェクトを永続化する"と言う事に関して、オブジェクトとリレーショナルをマップすることが適切なソリューションだと信じているか？その理由は？
Mike Keith: O/Rマッピング技術は、大多数の企業データがRDB内に格納され、そしてオブジェクト指向のパラダイムがアプリケーション開発の規範となっている世界において、単に現実的、かつ必要とされているものです。こうした現実を踏まえると、実際の質問は「オブジェクト永続化の問題をどう解決するか」ではありません。「Javaで書かれたアプリケーションが、RDBからデータを取得したり保存しなければならない。こうした問題は、アプリケーション開発のシナリオにおけるだいたい97%が抱えている。この問題をいかにして解決するか」と言うものになります。今まで現れたソリューションの中では、O/Rマッピングは最も柔軟で実践的です。これは果たして適切なのでしょうか？確かなのは、多くの人々がそれを使うのに成功していることです。これは普遍的で最高のソリューションなのでしょうか？私にとって間違いないのは、「いろんな人にそれを聞いてみれば、それに異を唱える人もいる」と言うことです。
Ted Neward: O/Rマッピングソリューションは、パフォーマンス、そしてRDBへのアクセスにおいて、生産性と開発の容易性に意欲的な開発者にとっては、役に立つものだと考えています。不幸なのは、非常に多くの場合、パフォーマンスや堅固なリレーショナルモデル、接続可能性を犠牲にすることは、プロジェクトにとって - 開発者が考えるよりも - 受け入れられない、と言う結論を見いだしてしまうことです。そういった場合、O/Rマッピングをより"リレーショナルフレンドリー"な何かに置き換えるのは時既に遅く、簡単ではないのが普通です。そうした場合は大規模なリファクタリング、もしくは書き換えが必要となります。
Carl Rosenberger: O/Rマッパーは次善の策です。SQLを手で書くと言う作業を、ある程度まで減らすのに役立ちます。
次善策は、相応のコストなしにはあり得ません。O/Rマッピングツールが理想的でない状況を三つあげることができます。:
- パフォーマンス
O/Rマッピングツールはアプリケーションを遅くします。オブジェクト指向のビジネスロジックを実行するために、オブジェクトがすべてメモリに読み出される必要があります。 - 複雑さ
O/Rマッパーは、オブジェクトをキャッシュし、変換すると言う副作用を発生させます。開発者は、並列処理を行った場合にO/Rマッピングツールがどう振る舞うかを理解するのに、時間を空費します。 - 設計の制限
O/R マッピングツールのおかげで、オブジェクト指向プログラミング言語が提供するすべての構成概念を利用することができません。なぜなら、すべての構成概念がリレーショナルな世界と同等ではないからです。O/Rマッピングツールをうまく扱うためには、アプリケーションクラスを設計する際、常にトレードオフが存在します。
次善の策が問題を根本から解決することはありません。それらは、真のソリューションが見つかるまでの中間的なステップでしかありません。
Craig Russell: データベースを中心的なデータ資源として扱う必要と、開発者のニーズのバランスをとると言う点では、多くのアプリケーションにとってORMは完璧なツールです。これがほぼ明確なのは、データベーススキーマが注意深くコントロールされ、管理されていると言う場合です。それとは正反対なのは、Javaクラスを書き、それらからスキーマを生成することで、データベーススキーマをアプリケーションプログラマがコントロールすると言う場合です。この場合に危険なのは、アプリケーションがうまく動作しないであろうこと、そして正しいスキーマを生成させるためにドメインクラスを再設計するのは難しく、データの移行が必ず問題になると言うことです。
Q5: "オブジェクトを永続化する"と言う事に関して、リレーショナルデータベースこそが適切なソリューションだと信じているか？その理由は？
Mike Keith: RDBは本来ならその答えではありませんが、そこには疑問が生じます。全く未知のアプリケーションを開発している新興企業でもなければ、アプリケーションはRDBからデータを取得する必要に迫られることになるでしょう。実際は、ほとんどの新興企業がRDBをストレージとして使用しています。その理由は、技術の成熟度と、スケーラビリティや信頼性の実績です。疑問となるのは、ビジネスロジックをJavaのようなオブジェクト指向言語で書きながらも、リレーショナルデータベース内のデータに対してどのようにアクセスするか？と言うことです。
Ted Neward: 私が考えるに、それが適切かどうかと言う質問は的外れだと言うことです - 近代的なITインフラは様々な理由から、エンタープライズ規模のデータをRDBに保存することを期待し、必要としています。そして開発者は、オブジェクトをRDBのデータとするための方法を見いだす必要があるのです。しかし、ユーザインターフェースから直接それを行う必要はそれほどありません。中間的なオブジェクトデータベースを置き、バッチ的、もしくは定期的にリレーショナルストアを更新するようにすれば、開発生産性を大幅に向上できる可能性があります。
Carl Rosenberger: いいえ。インピーダンスミスマッチは問題であり、ソリューションではありません。
Craig Russell: JavaとDBをつなぐツールとしては「イエス」です。
Q6: "オブジェクトを永続化する"と言う事に関して、オブジェクトデータベースこそが適切なソリューションだと信じているか？その理由は？
Mike Keith: オブジェクトデータベースは、20世紀におけるベータマックスに似ています。非常にうまく物事をこなしますが、広く受け入れられはしませんでした。（オブジェクトデータベースは）主流から取り残されてはいますが、その理由は、「それらがひどい」とか「使うのが難しい」とか「遅い」などではありません（いくつかの製品を除けば）。企業は様々な異種アプリケーションを抱えており、そうした企業のニーズを満たすものではなかった、と言うのがその理由です。ITアプリケーションは、機能とそれを構築しているテクノロジーの双方で、連続的に進化しています。しかし、それらがアクセスするデータはほとんど同じです。データはあらゆるテクノロジーとアプリケーションから簡単にアクセスできる必要があり、リレーショナルデータベースはその要求を満たしてはいますが、オブジェクトデータベースはそうではありませんでした。
Ted Neward: もちろんです。ただし、OODBMSに格納されたデータが、オブジェクト指向ではないテクノロジーからも直接アクセスされる必要がないのであれば。これはオブジェクトデータベースが持つ最も大きな欠点です。
Carl Rosenberger: もちろんです。どこに問題がありますか？オブジェクトデータベースでは、あらゆるオブジェクトをたった一行のコードで保存することができます。テーブルとマッピングを保守するための、追加作業は全く存在しません。データの問い合わせは、プログラミング言語の本質的な部分です。オブジェクトデータベースとの対話を行うコードはタイプセーフで、コンパイル時にチェックが行われ、ほかのコードと同じように自動的なリファクタリングを行うこともできます。
Craig Russell: オブジェクトデータベースの市場は、それにアクセスするのに使用されるプログラミングモデルよりも、アプリケーションのドメインに関わってきます。オブジェクトデータベースの理論的根拠の大半は、特定のドメインモデルと仕事量におけるシステムのパフォーマンスです。きわめて要件の厳しいアプリケーションでは、オブジェクトデータベースはリレーショナルシステムのパフォーマンスを一桁上回るかもしれません。こうした場合問題となるのは、データの問い合わせやレポート生成を行うツール、イベントの伝播、ほかのデータベースとの同期、そしてフェールセーフなオペレーションなど、どちらかというとオブジェクトデータベースを取り巻くツールです。
Q7: オブジェクト永続化の分野において、これから12ヶ月の間に、新しく研究開発が行われることを望むことは何か？
Mike Keith: データは驚くほど長い期間生き残り続けます。データが生き残ることにおける一つの問題は、プロプライエタリなストレージのスキーマ - その多くはリレーショナルデータベースが一般的になる前に作成されたものです -に、未だにデータアクセスする必要があることです。それらをどう取り扱わねばならないかを、システムインテグレータに聞いてご覧なさい。あなたが予想するよりもずっと長い議論になることでしょう。
その上で、XMLはグローバルなデータ言語としてユビキタスな存在となりました。そのため、結局のところ現代におけるサービス指向のオブジェクトは通常、オブジェクトからXML、そしてリレーショナルな形式へと形を変えるか、洗練されていないカスタムのデータストアへと記録する必要があります。来年以降の研究は、こうした問題を解決するためのものになるでしょう。しかも、こうした過程の各ステップにおいて、開発者を満足させるような方法でなくてはなりません。それはおそらく、一つの永続化技術がそれらすべてを統治すると言うものではないでしょう。一貫しており、統合されており、すべてのレベルでニーズを満たすような、永続化ソリューションの統一された集合となるのを期待しています。
Ted Neward: リレーショナルと集合論を統合し、プログラミング言語へと導入することです。
Carl Rosenberger:
(1) オブジェクト指向と関数型言語のマージist comprehensionによって、集合に対してパワフルな作業を行えると言う概念から、私は関数型言語を好んでいます。（一方）オブジェクトは、状態を表現するためには最高の方法だと信じてもいます。
私の考えでは、プログラミング言語の輝かしい未来は、関数型のコンセプトとオブジェクト指向をマージすることにあると思っています。ScalaとLINQは、正しい方向へと向かう偉大なステップです。
データベースのインデックスとは違って、list comprehensionを解析して実行するのに、難しい理論は必要ありません。概念的には、これはdb4oのネイティブクエリと非常によく似ています。もし我々のコミュニティの誰かがやらないのであれば、私たちはこれをScalaのlist comprehensionで試してみたいと思います。
(2) 新しい並列処理のコンセプトハードウェア開発のトレンドはマルチコアに向かおうとしており、並列性を扱うために、プログラミング言語は新しいコンセプトを必要としています。
ソフトウェア・トランザクショナル・メモリとアクタは、主流のプログラミング言語において採用されるであろう、偉大な二つのアプローチです。これらのアプローチはどちらも、データベース処理とうまく統合する方法を考える価値があります。
(3) 状態の管理オブジェクト指向では、私たちは状態をクライアント上の分散されたシステム内で保持しています: オブジェクトです。
私は、「クライアント上のオブジェクトが、サーバ上にコミットされた状態とどう同期を維持するのか」と言う問題についてデータベースに関する小さな調査を行ったところ、驚きを禁じ得ませんでした。
リレーショナルデータベースは「隔離された読み取り」と「ロック」と言う概念を提供していますが、それらは現実の問題に対処していないのです。それらはまるで、クライアント上には状態が存在しないかのように動作するのです。これは、インピーダンスミスマッチのもう一つの側面です。
並行処理の世界では、ロックを信じることはできません。
この問題を根本的に解決するためのよりよい方法は、クライアントに対しても状態変更を（サーバから）プッシュするか、特定の時点に置いて一貫性を持つ、オブジェクトのバージョンを導入することだと私は考えています。
両方のアプローチを試してみて、どういう場合にどちらのアプローチがなぜ優れているのか、その基準を探ってみるのはとても興味深いと思います。
Craig Russell: ツールとアプリケーション生成です。特に、生成されたフロントエンドのスクリプトコードとの統合は、オブジェクトの永続化と言う点で欠点が残っています。
Q8: もしあなたが全能で、ここ10年間に置けるテクノロジー採用に影響を及ぼしていたとしたら、今日の典型的なプロジェクトは永続化メカニズムとして何を使っているでしょうか？その理由は？
Mike Keith: 8年間にわたる苦痛から世界を救うために、EJBをPOJOモデルで作ったでしょう。また、それがSmalltalkとともに動作するようにしたことでしょう ;-)
Ted Neward: 私がプロジェクトのソリューションに対して影響を与えることはなかったでしょう。"機能に準じたテクノロジーから、ニーズに準じたプロジェクトへ"。（訳注: Tedはプロジェクトのニーズを満たす側の人間であり、ソリューションプロバイダではない、と言うこと）
Carl Rosenberger: 過ぎたことではなく、未来を見ていきましょう: db4objectsが、次の10年間においていくらか影響をもたらせる幸運なポジションにいることを私は望んでいます。今日の新しい携帯電話やデバイスプロジェクト（Android ! ）は、今まではそうでないとしても、（これからは）オブジェクトデータベース技術を使うべきです。
私は大規模なエンタープライズデータベースについては専門家ではありませんが、グリッドデータベースが効果的かどうかは疑いを持っています。なぜなら、今日の成熟した大規模データベースエンジンはCやC++で書かれており、これらの言語は分散処理や並行処理に対する高レベルの概念を提供していないため、こうしたシステムの保守や改善は非常に退屈であり、非効率に違いないと私は信じています。
おそらく、優秀なわずかの人たちにとっては、素早くコストを回収できる程度の妥当な努力で、世界で一番速くて巨大なデータベースを書くことが依然として可能なのでしょう。私が全能だったとしたら、こうしたプロジェクトをさらに進んだ段階の挑戦に向かわせていたと思います。おそらく、最近登場した並列処理の概念がもう少し成熟するまで待たなければならないのは確かですが。
リレーションは、以下のようなことを定義していません:
- 一貫性の始まりと終わり
- タプルのマスターコピーを誰が所有しているのか
- データをクラスタ内でどのように分散するか
- プリフェッチがどのような意味を持つか
- データをどうやって物理的にクラスター化するか
たいてい私は、プログラミング言語に盛り込まれたあらゆる知恵から、そのコンセプトの利点を知り、それをデータベースへと変換して考えます。
理論的な立場からは、最終的にはオブジェクトデータベースを採用することが、巨大なエンタープライズデータベースとしてもおそらく意味があります。データベースにアクセスするあらゆるエンタープライズアプリケーションが、互換性のあるオブジェクト指向言語で書かれていたら、です。
世界規模ですべてのエンタープライズアプリケーション間で共有できるような、共通のオブジェクト指向ドメインモデルの存在こそが理想です。
実際には、私はこうしたことを10年以上前から考えてきました。もし私が全能だったとしたら、あらゆる人がそうしたモデルを現在使っていたことでしょう。・・・そして、オブジェクトデータベースこそが、あらゆるアプリケーションにとって最も自然な永続化ソリューションであることに、何の疑問も挟まれなかったことでしょう。
Craig Russell: 今日の典型的なプロジェクトは、ワールドクラスのIDEと、オブジェクト永続化レイヤのためのプラグインをあわせて使用していることでしょう。そのレイヤでは、リレーショナル／オブジェクトデータベースのどちらでもオブジェクトのストレージとして用いることができるのです。
そうしたIDEは、高度にインタラクティブな見た目と、ユーザインターフェースのためのJavaScriptコードを含む、完全なWebフレームワークのコードを生成することができます。
Java VMは、クラスのジェネリックな命令を許容します。その目的は、変更管理と、ベンダ特有のバイトコード変換を回避するためです。実行時のパフォーマンスツールは、直接的な人での介入なしに、アプリケーションのチューニングを動的に行っていたことでしょう。
Q9: このトピックに関して、最後に何かありますか？
Mike Keith: オブジェクトの永続化に関して興味深いのは、人々がそれに関して情熱を燃やしているか、と言うことです。人々は、永続化について少し話すだけで耳をそばだて、一触即発の状態になるようです。コミュニティフォーラムが休止状態なら、永続化に関するちょっと批評的な見解を投稿するだけで、終わりのないコメントの嵐を得ることができます。
その原因はおそらく、永続化の問題がアプリケーションのパフォーマンスに対して劇的な影響を与えるから、もしくは単に永続化が途方もなく興味深いからでしょう。しかし私は、永続化の領域で18年にわたり勉強と仕事に従事していますが、未だに時間を費やす価値のあることだと感じています。アプリケーションにおける永続化の側面に注意を払わない開発者は、非常に危険だと言うことは、誰もが同意してくれると思います。
参加者としてご招待いただき、ありがとうございました。
Ted Neward: ご招待いただきありがとうございました。
Carl Rosenberger: 私は生体工学を信じています: 自然界が問題を解決する方法から、私たちは多くを学ぶことができます。自然界が知識をどのように組織化するかを見てみましょう: 高度に効率的なコミュニケーション技術を常に向上させている、冗長でゆっくりとした多数のシステム（人間のこと）を使っています。各ノードはあらゆるノードと会話することができ、会話接続の方向と強度は、現在必要とされているものにあわせて調節されます。
もし我々がこれを将来モデル化するとしたら、数々の失敗から様々なものを身につけた、スマートなグリッドコンピューティングとなることでしょうし、同じことがデータベースにも言えます。
前述したような共通ドメインモデルで、現在これに当てはまるのはどのようなものでしょうか？私は考えました。・・・そして気づきました。人間は、比較的長きにわたって安定した、共通のオブジェクト指向ドメインモデルを持っていたのです: 自然言語です。
なぜなら自然言語は非常に長くにわたって使われているため、我々は1000年前に書かれた文字を読み、理解することができるからです。
古いギリシャ語が、O/Rマッパーを使って書かれていないのは非常にラッキーでした。進化は、ゆっくりとした継続的なプロセスです。最終的には、最も優れたコンセプトが勝つのです。
参加者としてご招待いただき、ありがとうございました。
Craig Russell: 参加者としてご招待いただき、ありがとうございました。
著者について
Mike Keith
Mike Keithはオブジェクト指向と分散システムについて15年以上にわたり講師、調査、実践経験を積んできており、オブジェクトの永続化に関する専門家です。Mike KeithはEJB 3.0 (JSR 220) のスペックリードの一人で、Java EE 5 エキスパートグループ (JSR 244) のメンバーです。彼はまた、JPAのリファレンス本としては筆頭とも言える、Pro EJB 3の共著者でもあります。「Java Persistence API and...」の部分は、この段落の最初の文章がミスによりコピペされたと思われるので省略 -Shumpei 08/03/30 16:37 彼は現在Oracle TopLinkとOracle OC4Jコンテナのアーキテクトであるとともに、世界中の数多くのカンファレンスやイベントにおいて、人気のあるスピーカです。
Ted Neward
Ted Newardは、カリフォルニア州サクラメントにおける独立系のソフトウェア開発アーキテクト／指導者です。彼は数多くの著書を手がけており、 "Server-Based Java Programming" (Manning)、近日刊行予定の"Effective Enterprise Java" (Addison-Wesley) 、そしてDavid StutzやGeoff Shillingとの共著"SSCLI Essentials" (OReilly) 、同じくPeter DraytonやBen Albahariとの共著で"C# In a Nutshell" (OReilly) などがあります。
Tedはフリーでダウンロードできる技術的なホワイトペーパー(source)を持っています。また彼のブログはneward.net/ted/weblog(source)で、気の向くままにテクニカルな話題について語っています。彼はJSR 175（J2SE 1.5におけるカスタムメタデータについてのJava Community Process仕様)を手がけながら、C#チームにおいてもMicrosoft MVP (Most Valuable Professional:最も価値のあるプロフェッショナル）でもあります。彼はまた、DevelopMentor(サイト・英語)の講師も務めており、Javaと.NETカリキュラムの両方を教え、執筆しています。そして現在彼は、エンタープライズ.NETのアーキテクチャや問題に関するコミュニティポータル、TheServerSide.NET(サイト・英語)のチーフエディタとして働いています。
Carl Rosenberger
Carl Rosenbergerはdb4objects社のチーフソフトウェアアーキテクトであり、db4oデータベースエンジンのリードプログラマーです。 Rosenbergerは、オブジェクト指向ソフトウェア開発者のニーズを満たす、シンプルで使いやすいオブジェクトデータベースが必要だと感じ、 2000年にdb4oの開発を開始しました。彼は2002年にdb4oを商用製品として最初に提供し、2004年には100,000以上のダウンロード数と100近くの顧客が製品を検証し、契約を結びました。同年、基盤組織としてdb4objects社を創立しました。db4objects社を創立する前、RosenbergerはAPSISソフトウェアとLawconsult社のチーフソフトウェアアーキテクトでした。彼はEJB 3エキスパートグループ (JSR 220) のメンバーであり、オブジェクトの問い合わせを行うAPIにフォーカスしています。
Craig Russell
Craig Russellは、Sun Microsystems社におけるシニアスタッフエンジニアです。彼はJava Data Objects (JSR 12と243) のスペックリードであり、Apache JDO (db.apache.org/jdo)においてTCKに関するチームのリーダーを務めています。彼はJ2EE参照実装におけるContainer Managed Persistenceコンポーネントと、Sun Java System Application Serverのアーキテクトです。Craig RussellはApache Software Foundationのメンバーで、Apache OpenJPAプロジェクトの管理委員会議長でもあります。さらにApache Incubatorプロジェクトのメンバーでもあり、Apacheに新規プロジェクトをもたらす責務を負っています。
原文はこちらです：http://www.infoq.com/articles/java-object-persistence-panel