印刷

Articles

David Nuescheler氏がJCRとRESTについて語る

作者 Stefan Tilkov, 翻訳者 松本清一 投稿日 2008年7月10日午前12時52分

コミュニティ: Java,; SOA
トピック: JCP Standards,; REST,; Webフレームワーク
タグ: Apache Sling,; JCR

InfoQ: JCR/JSR-170(リンク)の簡単な概要を教えて頂けないでしょうか?

関連情報

InfoQ Japanはコンポーネントスクエアが運営しています

セキュアなIT基盤と付帯運用サービス”SecureOnline”

David Nuescheler (DN): ここでは、コンテンツリポジトリの機能セットについての説明に絞りたいと思います。

大まかに一つの文で表すならば、私は、常にコンテントリポジトリを「リレーショナルデータベース」と「ファイルシステム」の「2つの異なるもののそれぞれの長所」を持つものということに加え、常に私たちのアプリケーションに構築し忘れて、構築しなくてはならないものの全てであると表現します。

それには、トランザクション、スケーラビリティ、DBのクエリー、非常に巨大なファイル、ストリーミング、アクセスコントロール、階層型ファイルシステム、バージョニングのようなもの、フルテキスト検索、そして最も重要なのは、その2つのいずれもサポートしていない「データファースト」アプローチです。

JCRは、これらの機能をすべて表現しているJava APIです。

InfoQ: 今日の市場でのJCRの採用についてどのように感じていますか?

DN: 採用のときは、私はAPIについての実装者とユーザーの両方の考えが重要であると、常に感じています。

まず初めに、私は非常に多くのリポジトリがあることを知り驚きました。そしてそれが、JCRの初回リリース後のたった２年でJCR v1.0(通称JSR-170)に準拠しているのです。予想していたとおり、いくつかのリポジトリはサードパーティ製のコネクタに準拠しているものですが、主要なものは既にJCRのコンプライアンスを得ています。これには、新しくて革新的な新規のリポジトリだけでなく、主要なリポジトリベンダーのものも含んでいます。もう一つの非常に有望な事実として、既に４つのJCRのオープンソース実装が存在し、それが実装サイドからの仕様に関する強力なサポートをしていて、Javaの分野で広く採用されているものと同程度に確かなもののように感じています。

より一層重要なことは、ユーザーAPIの選択が素晴らしく、私の考えでは、一部の採用よりもはるかに重要なことであると思います。多くの点において、これは本当に皆が望んでいたリポジトリの強化を刺激するものです。一つ一つの新しいコンテンツ管理のイニシアチブは、現在は、スクラッチから「自身の」コンテンツリポジトリを別に構築する代わりに、コンテンツリポジトリを利用する準備が整っている標準ベースに頼ることができます。このことは、アプリケーション開発者にとって、プロジェクトの開始からアクセスコントロールのような機能、十分に成熟したバージョニング、全文検索に頼ることができるということです。私たちは、多くのアプリケーションが最も身近なコンテンツリポジトリの実装としてApache Jackrabbit上で構築されるのをみることができます。そして、私は、これらのありとあらゆるアプリケーションによって、おそらく、人々がJCRのないhibernateのようなもので、新たに独自のコンテンツリポジトリを構築するという事実を誇張して話すことはできないと思います。

InfoQ: あなたの雇用主であるDay社(リンク)はどうでしょうか。これを価値のあるものにしていますか?

DN: 2001年に遡り、私たちがJCRの仕様プロセスを始めたのは、業界標準がなかったからです。私たちは、まず第一に独自のコンテンツリポジトリに追いつくためにアプリケーションベンダーのことを考えました。私たちは、それを行いました。しかし、最も重要なコンテンツ全てが独自リポジトリに組み込まれてしまうため、私たちの顧客にとって満足できるものにはなりませんでした。そこで、私たちは、標準ベースの自身のコンテンツアプリケーション(Webコンテンツ管理、デジタル資産管理、ソーシャルコラボレーションソフトウェア)の全てをオープンプラットフォームで提供することを望みました。そのような標準が無かったので、私たちには、顧客に対してそれについて何かをする義務がありました。

そして、通常、オープンで標準に準拠することは、私たちのコンテンツアプリケーションにとって販売の重要な特長となります。

JCRやApache Jackrabbit関連のオープンソース活動に関与している間、私たちはCRX(リンク)というハイスケーラブルでエンタープライズにも対応できる商用完全準拠のコンテンツリポジトリを販売し始めました。

CRX は、多くの異なる手法をもった製品です。たとえば、リポジトリ内のフルセットのきめ細かなコンテンツを考慮していて、旧来のtarファイルによるトランザクション手法により永続化が行われます。それ故、ロードテストでは従来のRDBMSをおいた永続化層よりもパフォーマンスが優れています。

InfoQ: 最近、Atom(リンク)やAtomPub(リンク)についての多くの話題がありましたが、それらがJCRを廃れさせていると主張する(リンク)人もいます。これについてはどのように思われますか?

DN: 率直に言って、私は人々が何故プロトコルとAPIが競合していると思うのかを理解するのに今なお苦労しています。人々がWebDAVとJCRを比較(私は、機能の観点で比較した方がより適切であると思いますが)していた頃に、私たちは、HTTPとServlet APIの比較を思い描いていたのを思い返します。「今、私にはHTTPがあるのに、何故、Servlet APIが必要なのだろうか」というようなことを言う人はいないでしょう。プログラマが利用するAPIはプロトコルではありません。

さて、AtomやAtomPubとJCRを比較することは、機能的な観点からあまり意味のないことです。AtomやAtomPubが読み込みや書き込みを提供するのに対し、JCRは多くの異なる手法でそれを超えています(検索、ロッキング、バージョニング、アクセスコントロールなど)。技術的観点では、私は AtomやAtomPubがWebDAVのコレクション操作の代わりとして(おそらくは)より軽量であると思います。しかし、そのくらいのものです。

InfoQ: しかし、それらが持つAPI標準に関する共通の問題は、特定のプログラミング言語(この場合はJava)の解決法でありませんか? 私は、自身のコンテンツを他のプラットフォームからもアクセス可能にして欲しいのですが。

DN: 私は、それを問題とは考えません。それは、特徴です。話に出したプロトコルは「プラットフォーム中立な方法で」アクセスを可能にしますが、パーサーをラップする独自APIを作らなければならないので、残念ながら、開発者にとって全く無意味なものとなります。先に述べたように、servlet APIはJavaプラットフォームと結びついていて、HTTPとJavaプログラマーとのアクセスをしやすくしています。今、servlet APIが「共通の問題」を持つと言いましたが、それが特定の言語に束縛されるのは正しいものではありません。コンテンツリポジトリの世界では、(HTTP とServletの例と対比して)広く採用されているコンテンツリポジトリのプロトコルが欠如しています。WebDAVやAtomは、おそらく一番の候補となるでしょうが、私は、将来プロトコルレベルでのより広く採用される仕様が現れると確信しています。個人的には、良いものにどのような欠陥があるか、つまり、きちんと採用されたプロトコル仕様がAPI仕様の欠陥を考慮できるかどうかについては考えません。

加えて、JCRが.NET、PHP、Perl、JavaScriptを含む多種多様な言語環境に移植されたことも言っておきたいと思います。

InfoQ: REST(参考記事)の発案者であるRoy FieldingはDay社の主任研究員であることを前提に、RESTに関するあなたの意見はどうでしょうか?

DN: 私は従来のアプリケーション開発手法を学ぶよりも前に、Webをかなり早い頃から使い始め、それを理解するために学び、Webアーキテクチャを愛しているという意味で、私は自身が「Webの申し子」であると思っています。従って、私はアプリケーション開発者が持つ通常の問題に陥ることはなく、ステートフルアプリケーションの枠組みにWebを適用しようとしました。私は、別のところからやって来て、アプリケーションを私のWebの世界に適用させる必要がありました。

Roy に初めてあったとき、RESTについて知らず公式に言うこともない状態で、私たちが既にRestfulアーキテクチャによるアプリケーションを構築していたということを実感しました。そのときは、もっともなアーキテクチャスタイルであると感じましたが、もちろん今でもそう感じています。よって、「極度の RESTafarian」にカウントされるでしょうし、適切な時期のニックネームであれば何でも、あるいは単純に「app guy」と対比して「web guy」であると言うでしょう。もちろん、2001年のRoyの論文によるRESTのアーキテクチャスタイルの形式化は、Webコミュニティにとって重要な資産であり、その価値を一般に認められるのに時間がかかったのは驚いています。

InfoQ: そうなると仮定して、JCRはRESTにどのように関わるのでしょうか?

DN: 私の考えでは、JCRとRESTは様々な手法で関係があります。まず第一に、それらは共に情報中心で、情報の階層的なアドレス指定をサポートしています。 JCRのパスは、ファイルシステムのパスのようにURLを直感的に対応付けます。私たちが初めに行ったことの中の一つは、RESTFulな手法でJCRの APIの完全なリモート操作を提供するために、全てのJCRのAPI呼び出しをWebDAVに対応付けることでした。

これは、機能の観点からWebDAVに足並みをそろえるということを確かなものとするために重要であったばかりでなく、RESTアーキテクチャスタイルによって与えられた制約を全く違反しなかったということも明らかにしています。

Web サイトをベースとした静的なファイルシステムには、URLからファイルシステムの自然なマッピングがあります。URLを見れば、私はほとんど何がしたいのかが分かります。これは、階層的なファイルシステムからURLの自然で直感的なマッピングのためです。コンテンツリポジトリは、階層型のストアを呼び戻し、非常に直感的なマッピングを可能にします。

私の考えでは、JCRはWebセントリックで理想的な情報ストアであり、REST指向アプリケーションです。

InfoQ: Apache Sling(リンク)の簡単な概要を教えていただけないでしょうか?　何故、世間では他のJavaのWebフレームワークを必要としているのでしょうか?

DN: わざと反対の立場をとり、私はまだjavaの「web」フレームワークを経験したことがないという立場にたちます。

私は、世間がサービスを「Web」に公開するようなJavaの「アプリケーション」フレームワークで満たされていると主張するでしょう。しかし、実際には、私はそれらを「Webフレームワーク」と呼びません。

一般的に私は、必要悪としてWebのステートレスアーキテクチャを考慮しないということや、「単なる文字列」でなくそのURLにより注意を払うというフレームワークに対して欠けている部分があると思います。Slingは、本当に別の「Javaアプリケーションフレームワーク」ではなくて、それだけで試すものではありません。Slingは、単にWebの基本的な原則と制約を尊重しているだけでなく、実際に「心地よい」ものであると感じる最初の「Webフレームワーク」です。

私たちはそのようなことからWebが好きで、セッションの注入や継続によって可能な限り基本的な原則を避けようとはしませんでした。それらの最も大きな差別化要因の一つは、Slingと既存のアプリケーションフレームワークと比較して感じるのがURLとの関係です。J2EEやStrutsのようなレガシーなアプリケーションフレームワークでは、URLは主にスクリプトやコントローラー(.jsp, .php, .do)を処理したり、あるオペレーションにパラメータを渡すために使用されました。したがって、…/view.jsp?id=123465のような醜い URLで終わるのは、明らかにリソース指向ではありません。より現代的なフレームワークでは、例えばregexpベースのURLの分解により「文字列として」URLを処理し、URLをより柔軟にするきっかけとなりました。

これがよりリソース指向で、さらにRESTfulなアーキテクチャであるとするならば、決して人々を正しい方向に導いているとは言えません。彼らにより多くの選択を与えれば、ほとんどの場合は取捨選択します。または、良いデフォルトの振舞いの欠如が良くないと言いましょう。

Slingはとても変わっています。何故なら、Slingはコンテンツリポジトリを支援するもので、URLによって公開された階層的な名前空間をとても自然に対応付けた名前空間を公開します。さらに、それはURLでのフルコントロールも可能で、うまく構成された手法の中でコンテンツノードをリソースとして公開する方法を非常にはっきりとした形で提供しています。Slingは、「Web」を「Webフレームワーク」にします。

InfoQ: 正直に言うと、私は非階層的URLがRESTfulでないという議論について知らなかったということを認めなければなりません。ところで、ハイパーメディアなどの他のRESTの側面について、Slingはどうなのでしょうか?

DN: URLの階層的な側面は、本来、RESTfulとは関連の無いものです。Webサイトがまだファイルシステムだった頃は、URL /news/newsitem.htmlが、「news」フォルダ内のファイルシステムのある場所に「newsitem.html」ファイルがあるという、合理的に分かりやすいものでした。階層的なURLの対応付けがとても分かりやすかったので、アーカイブフォルダや別のニュース項目の追加はとても単純なものでした。もちろん、Webサーバーにおいては誤った対応付けをするもろもろの可能性がありますが、単純なケースではとても単純で直感的な方法で解決することができます。Slingは、URLのパスがコンテンツリポジトリのノードに対応づけられるというのがデフォルトであるというまさに同じコンセプトを採用しています。もちろん、SlingではURLの一部分あるいは全部の制御が可能ですが、単純で、直感的に理解でき、とても強力なデフォルトのマッピングを提供することが重要であり、それは実績のある、スケーラブルで、「Web」のベストプラクティスを固守するものであると思います。開発者が自身の URL空間を綿密に計画する力を与えるということは、全く有用ではありません。何故なら、それがプロジェクトが始まったときから考えるべき最初のことであるだろうし、個々の開発者は、全く異なるマッピングを考えるからです。

私が思うに、多くの場合においてSlingはRESTアーキテクチャを作る上での4つの制約全てを与えるのに十分なものです。おそらくこれが最も重要な差別化要因で、他のアプリケーションフレームワークは、時間をかけてRESTfulなアプリケーションを構築することになるでしょうが、SlingはWebアプリベースのRESTfulなリポジトリをすぐに開発するのに「しっかりとした作り」となっているので、RESTアーキテクチャを無視しにくくなっています。

InfoQ: 貴重なお時間をありがとうございます!

David Nuescheler氏は、スイスにあるDay Software社で、技術戦略と現在も続いている製品開発の責任者です。彼は、コンテンツリポジトリのJava技術APIに関する、JSR 170とJSR 283のスペックリードです。彼のグループは、コンテンツリポジトリの市場を標準化するために4年以上にわたり活動し続けています。David氏は、Apache Jackrabbitプロジェクトのコミッタであり、Apache Software Foundationの一員です。

原文はこちらです：http://www.infoq.com/articles/nuescheler-jcr-rest