ECM業界の主要プレーヤ達が共同で策定した新しい規格、Content Management Interoperability Service （CMIS）についての概要説明をしていきます
9月10日にIBM、EMC、Microsoftという現在ECMの世界でも特に強い影響力を持っている3社が共同開発した仕様「Content Management Interoperability Service（CMIS）」をOASISへ提出予定であるという発表がありました。この3社が協力した、というだけでもECMという分野の中では非常に大きなインパクトを持ちますが（IBMはFilenetを、EMCはDocumentumを買収して製品ラインナップを整えています）、さらにAlfresco、Open Text、Oracle、SAPの4社が合流し、メジャーどころすべてが関与した本格的な業界標準ともいうべき仕様になっています。
直訳すると、「コンテンツ管理相互運用サービス」、つまり、異なるコンテンツ管理システム（ECM製品）の間での相互運用を可能にするための規格です。「ECMの世界の（RDBMSで言うところの）SQLを作る」という野心的な試みと言えるでしょう。
具体的にはRESTとSOAPで呼び出すことができるメソッドの名前と仕様を共有化していく、というアプローチをとっています。したがって、この仕様で定められた名前のメソッドを呼び出す形でリモートからECMリポジトリの機能へアクセスする、というアーキテクチャで構築されたアプリケーションは、背後にたてるリポジトリの土台が他のECM製品になってもそのまま動作させることができる、ということになります。
本稿では3回にわけてこのCMISの仕様の概要を紹介していきたいと思います。第1回の今回は仕様の概要を、第2回ではそこで前提となっているデータモデルについて、第3回では実際にサービスとして規程されている各メソッドについての説明をしていく予定です。
まず、この野心的な取り組みの第一歩として今回のバージョン0.5のカバー範囲がどこまでなのか、という定義から仕様書はスタートしています。この仕様のユースケースを例示していくというスタイルで、ECM製品の基本機能を活用する「コアECMサービス」、それらECM製品の上にアプリケーションを構築することで実現する「ECMベースアプリケーション（原語ではECM Applicationですが）」、加えて今回対象としなかったユースケースのサンプルとしての「スコープ外」という3つのカテゴリが提示されています。
「コアECMサービス」の枠では、コンテンツ生成コラボレーション、ポータル構築、マッシュアップの3つのユースケースが挙げられています。コンテンツ生成の場としてのECMリポジトリ、企業ポータルの構成要素（時として基盤として活用されるECM製品もありますが）としてのECMリポジトリ、マッシュアップ対象としてのコンテンツ（あるいはコンテンツ断片）提供元としてのECMリポジトリ、といった形で、現代的なECMリポジトリの活用方法が一通りカバーされていると言えるでしょう。
次に、「ECMベースアプリケーション」のカテゴリ。自動アーカイブ、ヴァーチャル（合成）文書、eディスカバリーの3つが提示されています。コンテンツと属性情報のハンドリングというECMの基本サービスを適切に組み合わせることで、個別に実現可能な機能ですが製品によって実現方法に差があったり、あるいは標準機能として提供されていなかったりする領域ですので、ECMベースのアプリケーションという切り口で整理するのは非常に理に適っているのではないかと思います。
最後に「スコープ外」と識別されたユースケース群ですが、レコードマネジメント、デジタルアセットマネジメント、Webコンテンツマネジメント、購読管理の4つです。非常に注目度が高い領域ではあるのですが、今回は直接のスコープからは外されています。上述2つのカテゴリに含まれていたユースケース群と比べると若干粒度が大きいソリューションレベルのアイテムが並んでいます。
また、実際に整備するAPIの範囲についても幾つかの領域をスコープ外にするという形で対象領域を定義づけています。具体的には、システム管理と設定、セキュリティ、認証、アクセス権、ローカライズ、5つがスコープ外となっています。これらの操作を行うためのメソッドというのは今回のバージョン0.5のAPIセットの中には含まれていません。複雑であり仕様策定が困難であったことはもちろんですが、やはり製品毎の差が大きすぎるということもこうした作業範囲の絞り込みが実施された背景にはあるのではないかと思います。
まとめますと、今回のスコープは、ECMの基本的なサービスを共通基盤上で提供していくということが大きな目的としてあり、実際に提供されるAPIはコンテンツやメタデータの物理的な操作に直結したものが中心である、ということになります。
次回は、リポジトリ、文書、フォルダ、関連、ポリシ、といったこの仕様上で識別されている各種モデルの詳細に入っていこうと思います。
（文責 Ishii Akinori ITC）
9月10日にIBM、EMC、Microsoftという現在ECMの世界でも特に強い影響力を持っている3社が共同開発した仕様「Content Management Interoperability Service（CMIS）」をOASISへ提出予定であるという発表がありました。この3社が協力した、というだけでもECMという分野の中では非常に大きなインパクトを持ちますが（IBMはFilenetを、EMCはDocumentumを買収して製品ラインナップを整えています）、さらにAlfresco、Open Text、Oracle、SAPの4社が合流し、メジャーどころすべてが関与した本格的な業界標準ともいうべき仕様になっています。
直訳すると、「コンテンツ管理相互運用サービス」、つまり、異なるコンテンツ管理システム（ECM製品）の間での相互運用を可能にするための規格です。「ECMの世界の（RDBMSで言うところの）SQLを作る」という野心的な試みと言えるでしょう。
具体的にはRESTとSOAPで呼び出すことができるメソッドの名前と仕様を共有化していく、というアプローチをとっています。したがって、この仕様で定められた名前のメソッドを呼び出す形でリモートからECMリポジトリの機能へアクセスする、というアーキテクチャで構築されたアプリケーションは、背後にたてるリポジトリの土台が他のECM製品になってもそのまま動作させることができる、ということになります。
本稿では3回にわけてこのCMISの仕様の概要を紹介していきたいと思います。第1回の今回は仕様の概要を、第2回ではそこで前提となっているデータモデルについて、第3回では実際にサービスとして規程されている各メソッドについての説明をしていく予定です。
まず、この野心的な取り組みの第一歩として今回のバージョン0.5のカバー範囲がどこまでなのか、という定義から仕様書はスタートしています。この仕様のユースケースを例示していくというスタイルで、ECM製品の基本機能を活用する「コアECMサービス」、それらECM製品の上にアプリケーションを構築することで実現する「ECMベースアプリケーション（原語ではECM Applicationですが）」、加えて今回対象としなかったユースケースのサンプルとしての「スコープ外」という3つのカテゴリが提示されています。
「コアECMサービス」の枠では、コンテンツ生成コラボレーション、ポータル構築、マッシュアップの3つのユースケースが挙げられています。コンテンツ生成の場としてのECMリポジトリ、企業ポータルの構成要素（時として基盤として活用されるECM製品もありますが）としてのECMリポジトリ、マッシュアップ対象としてのコンテンツ（あるいはコンテンツ断片）提供元としてのECMリポジトリ、といった形で、現代的なECMリポジトリの活用方法が一通りカバーされていると言えるでしょう。
次に、「ECMベースアプリケーション」のカテゴリ。自動アーカイブ、ヴァーチャル（合成）文書、eディスカバリーの3つが提示されています。コンテンツと属性情報のハンドリングというECMの基本サービスを適切に組み合わせることで、個別に実現可能な機能ですが製品によって実現方法に差があったり、あるいは標準機能として提供されていなかったりする領域ですので、ECMベースのアプリケーションという切り口で整理するのは非常に理に適っているのではないかと思います。
最後に「スコープ外」と識別されたユースケース群ですが、レコードマネジメント、デジタルアセットマネジメント、Webコンテンツマネジメント、購読管理の4つです。非常に注目度が高い領域ではあるのですが、今回は直接のスコープからは外されています。上述2つのカテゴリに含まれていたユースケース群と比べると若干粒度が大きいソリューションレベルのアイテムが並んでいます。
また、実際に整備するAPIの範囲についても幾つかの領域をスコープ外にするという形で対象領域を定義づけています。具体的には、システム管理と設定、セキュリティ、認証、アクセス権、ローカライズ、5つがスコープ外となっています。これらの操作を行うためのメソッドというのは今回のバージョン0.5のAPIセットの中には含まれていません。複雑であり仕様策定が困難であったことはもちろんですが、やはり製品毎の差が大きすぎるということもこうした作業範囲の絞り込みが実施された背景にはあるのではないかと思います。
まとめますと、今回のスコープは、ECMの基本的なサービスを共通基盤上で提供していくということが大きな目的としてあり、実際に提供されるAPIはコンテンツやメタデータの物理的な操作に直結したものが中心である、ということになります。
次回は、リポジトリ、文書、フォルダ、関連、ポリシ、といったこの仕様上で識別されている各種モデルの詳細に入っていこうと思います。
（文責 Ishii Akinori ITC）
最近のコメント