Javaコンテンツリポジトリが好調だ。最初のバージョンであるJSR-170(サイト・英語)が順調であるなか、JCR APIの第2バージョンがJSR-283(サイト・英語)として公開レビューのためにリリースされた。（JSR-170の実装である）Jackrabbit(サイト・英語)は今やトップレベルのApacheプロジェクトで、オブジェクト／コンテント・マッピングツール(サイト・英語)を手に入れるところであり、そしてコンテント管理システム(サイト・英語)の枠を超え、たとえばJBoss RulesのBRMS(サイト・英語)におけるビジネスルールのパーシステントストアやMaven 2 repositoryにおけるartifactory(サイト・英語)のように、他の開発活動を補う役割を果たす(source)ようになっている。
JSR-283は以下の方法でJCR 1.0を改良することを目的としている。
- アクセス制御とノードタイプの管理
- メタ情報および多言語化など、新しい標準ノードタイプによる相互運用性の向上
- コンテントモデリング拡張機能
- フェデレーション（連携）、クロスリポジトリおよびクロスワークスペース機能
- 現在のクエリ言語の積極的な開発、バージョン管理およびオブザベーション(監視機能)
- リモーティングおよびクライアント／サーバープロトコル・マッピング
InfoQはDavid Nuescheler氏と話をする機会を得た。氏は、Day Softwareの最高技術責任者であり、Javaコンテンツリポジトリに関するJSR 283とJSR 170の仕様、API第2バージョンの公開レビューをリードしている。実装者によるJCRの導入に関して、氏はこのように述べている。
両側のAPIの導入は、私の期待以上でした。コンテンツリポジトリの実装側に関しては、おそらく20～30くらい実装されているでしょう。
特筆すべき点だと思うところは、すでにJCRがオープンソースで4つ別々に実装されていることで、それらはこのような短い時間内におけるV1.0標準の素晴らしい成果であり、こんなに早く導入されたJSRを私は他に記憶していません。
そして、（アプリケーション）開発者側の導入に関しては、このように述べた。
さらに重要なことに、もう一方のAPIであるアプリケーション側については、JCRを使うプロジェクトや製品が途方もなく勢いを増すのを見てきました。その氷山の一角でもjackrabbit wiki [http://wiki.apache.org/jackrabbit/JcrLinks]のリストに残しておこうとしていますが、把握するのは困難です。
確かにこの点において、JCRは他のどんなコンテンツレポジトリ技術より成長しています。個々のアプリケーション開発者数の点では、今日すでに他のどんなプロプライエタリ(独自仕様)のコンテンツリポジトリAPIより多くなっているようです。
どんなアプリケーションがJavaコンテンツレポジトリを使うのに都合が良いか、特にリレーショナルデータベースの使用と対比した場合について質問したところ、このように述べた。
コンテンツリポジトリが、DM、DAM、WCM、SCMなどの“コンテント管理システム”のみに利用されるというのは、私はよくある誤解だと呼びたいと思います。JCRがウェブベースのCMSにとって理想的なストレージレイヤーであるばかりではなく、他のほとんどのアプリケーションにとっても理想的なストレージであることを理解するのは重要なことだと思います。
私の考えでは、バージョン管理、きめ細かいアクセス制御、フルテキスト検索、大きなバイナリファイル、およびコンテンツリポジトリが公開するその他すべてのサービスを利用することを望むほとんどすべての最新のアプリケーションにとって、コンテンツリポジトリは理想的なストレージです。
個人的には、自分のアプリケーションではJDBCインターフェースよりも機能豊富なJCRインターフェースの方をいつも使いたいと思いますが、それは私が非常にJCRに馴染んでいるからでしょう。
今までJCRを使ったことのない人には、（いわゆる）わかりやすいアプリケーションを選ぶように勧めるようにしています。バージョン管理、アクセス制御、階層構造といったコンテンツリポジトリの付加サービス機能を利用するようなアプリケーションが、それにあたるでしょう。
JCR 2.0の全体的な課題について次のように話した。
よく使われるECM の実践方法にさらに沿うように、大手ECMベンダーと共に本当に多大な努力をJSR-283に注いできましたので、ベンダーがもっと仕様に準拠しやすくなりました。
Davidはまた、JCR 2.0の機能の中から個人的な“ベスト10”をリストアップした。
- SQLの拡張サポートなどを中心としたクエリの拡張。具体的にはJOINです。また、より簡単な“クエリウィザード“を可能にするクエリオブジェクトモデル用Javaバインディングを取り入れました。そして最後に大事なのが、”Prepared“クエリです。
- すでにJCR V1.0で定められた仕様の反省にとどまらないアクセス制御管理。
- JCRリポジトリの最上位にあるレコード管理アプリケーションを規格化された方法にできるリテンションポリシーおよびホールドサポート。
- 直線的なバージョン管理のみサポートする、シンプルなバージョン管理。“ベースライン”および“アクティビティ(業務)”などの構成管理の領域を完全にカバーする、拡張バージョン管理。
- コンテントを簡単に処理エンジンに引き込むことができるライフサイクル管理。
- アプリケーションがリポジトリと共にノードタイプを登録して管理できる、標準ノードタイプの登録機能。
- 共通メタデータ関連のアプリケーションの相互運用性を強化する新しいプロパティタイプと新しいノードタイプ。
- リポジトリ内のワークスペースの作成と削除ができるワークスペース管理。
- コンテンツリポジトリのワークスペースの階層がさらに暗黙的なネットワークになる共有可能ノード。
- オフライン／ポーリングアプリケーションが、最後にチェックした後にコンテンツリポジトリに何が起こったか調べることができるジャーナリングオブザベーション（更新記録の監視）。
詳細については、JSR-283の公開レビューや、Davidの著書「Simple Rules for Blissful Content Modeling（至福のコンテントモデリングのための簡単な法則）(source)」を読むことができる。また、InfoQのJavaコンテンツリポジトリ(サイト)のニュースで随時お伝えしていく予定である。
原文はこちらです：http://www.infoq.com/news/2007/07/java-content-repository-2
（原文は2007年7月18日にリリースされました）