aegif CTO blog

ようやく策定されたECMのための共通言語 CMIS（2/3） （Insight Now!より転載）

少し間があいてしまいましたが、CMIS（Content Management Interoperability Service）の内容紹介を続けたいと思います。前稿では、CMISがどのような利用のシーンを前提として策定されているのか、という話題を中心にご紹介しました。本稿では続くメソッドレベルでのAPIの解説の前提知識となるデータモデルについてご説明します。

CMISではいわゆるフルスペックのECM製品で取り扱われるオブジェクト群のすべてが規格化されているわけではありません。たとえば追加開発用のインターフェースに使われるトランジェント（永続化対象外）なエンティティや、ユーザプロファイルのような管理目的のエンティティ、ヴァーチャル文書やビジネスプロセスそして購読などの付加価値的な機能であつかわれるエンティティもスコープ外になっています。それでも、データの格納先として求められるリポジトリの構成要素については一通り網羅されていますし、その構成要素間の複雑な関係性も表現できるようになっています。まずは最上位の概念である"リポジトリ"からはじめて、4つの基本オブジェクトタイプを説明します。個々の構成要素である"文書""フォルダ"、その関係性を表現する"関連"、標準的なサービス（アクセス制限など）を表現する"ポリシ”の4つがCMISにおける基本オブジェクトタイプです。それからさらに追加のオブジェクトタイプの定義方法を紹介するまでを本稿の範囲としたいと思います。

リポジトリ

ECM製品毎にリポジトリの実装方法は様々です。したがって、CMISにおいては最上位概念であるリポジトリについてもすべての機能を網羅することを求めてはいません。例えば以下に挙げる機能は"オプショナルな"ものとして取り扱われます。また、当該リポジトリがこれらの機能をサポートしているかどうかは、getRepositoryInfoサービスによって通知されなければなりません。 ・文書（あるいはフォルダに格納可能なその他のオブジェクト）を複数のフォルダに格納する機能。マルチファイリング。 ・文書（あるいはフォルダに格納可能なその他のオブジェクト）をどのフォルダにも格納しないまま保持する機能。アンファイリング。 ・文書の特定のバージョン（群）だけをフォルダに格納する機能。バージョン指定ファイリング。 ・チェックアウトされた文書のワーキングコピーを更新する機能。ワーキングコピー編集。 ・最新版ではない文書もスコープに含めた検索機能。全バージョン検索。 ・チェックアウトされた文書のワーキングコピーもスコープに含めた検索機能。ワーキングコピー検索。 ・検索クエリのサポート。「なし」「メタデータのみ」「全文検索のみ」「両方」 ・クエリにおけるジョインのサポート。「なし」「インナージョインのみ」「インナージョインおよびアウタージョイン」 ・全文検索サポート。「なし」「全文検索のみ」「全文検索と属性情報の組み合わせ」

これら機能のサポート状況だけでなくgetRepositoryInfoサービスからは関連するその他のリポジトリへのリンクを得ることもできるようになっています（規格上はMAYと表現）。CMISにおいてはリポジトリは単一のものではなく、いくつものリポジトリが併存する状況が前提となっています。getRepositoriesサービスによってアクセスの対象となりえるリポジトリの一覧が取得できます。上記の関連する他のリポジトリの一覧というのは、そのサブセットになります。また、getRepositoryInfoサービス以外でもgetTypesサービスやgetTypeDefinitionを利用してリポジトリについての情報を取得することもできます。

基本オブジェクトタイプ

CMISの基本オブジェクトタイプは、文書・フォルダ・関連・ポリシの4つです。文書はリポジトリに格納されるもっとも基本的な構成要素です。フォルダは文書をはじめとする「格納可能なオブジェクト」の集合のコンテナです。関連は2つの独立したオブジェクト（インスタンス）を繋ぐ関係性を定義します。ポリシは1つ以上の「コントロール可能なオブジェクト」に「適用」される管理目的のポリシを表現します。文書とフォルダとポリシの3つは独立したオブジェクトとして位置づけられているため、関連の対象となります。

また、各オブジェクトはオブジェクトIDというユニークな識別子を持ちます。このIDはタイプによらずリポジトリ内でユニークであることが保証されていなければなりません。また、必須ではありませんが、このIDは「永続的」であることが望ましいとされています。（永続的とは、すくなくともそのオブジェクトのライフスパンが終わるまでの間は不変である、ということを意味します。そのオブジェクトが消滅した後で同一のIDが新しい別のオブジェクトにアサインされる可能性については特に規定されていません）。さらに内部的なIDだけでなく、URIを割り振ることもできます（これも必須ではありません。MAYと表現されています）。ただし、URI自体の検証や外部接続性等々についての細かい規定はCMISの対象外となります。

各オブジェクトには属性が定義されます。属性は必ず名前をもちますが、厳密な順番付けは必要としません。（ただし、同一リポジトリの同一クラスの属性のセットについては常に一貫した順番で取得できることが求められています）属性には、String（文字列 xsd:string）・Decimal（小数 xsd:decimal）・Integer（整数 xsd:integer）・Boolean（真偽値 xsd:boolean）・DateTime（日付 xsd:dateTime）・URI（URI xsd:URI）などの型が用意されています。また、ID（xsd:string）とXML（xs:any）とHTML（xs:any）という3つ独自の属性型も定義されています。IDがxsd:idではないことに注意してください。XMLとHTMLはそれぞれのマークアップ言語の断片を格納します。

文書

リポジトリの最も基本的な構成要素です。格納可能で独立したオブジェクトです。他の基本オブジェクト型とは違い、いわゆるファイルの実体にあたるContentStreamをもっています。ContentStreamはバイナリのデータ列で、その最大長はリポジトリの実装に依存します（特に規定はありません）。また、各ContentStreamにはMIMEタイプが設定されます。ContentStream自体には名前はつかず、文書オブジェクトを経由することになります。

CMISではContentStreamに対するCRUD操作のサービスも定義されています。setContentStreamサービスは文書オブジェクトに対して新しいContentStreamを割り当てる、あるいは既存のContentStreamを置き換えるという操作を行います。getContentStreamでは対象の文書オブジェクトのContentStreamを取得します。削除はdeleteContentStreamサービスです。さらに、編集後の文書をチェックインするcheckInサービスによってもContentStreamは更新されます。以上が、ContentStreamを直接操作することになるメソッドのすべてです。属性取得のgetPropertiesや検索クエリ経由ではContentStreamそのものを取得することはできません。また、setContentStreamやdeleteContentStreamの操作はそのContentStreamを保持している文書オブジェクトそのものについての更新行為とみなされるため最終更新日を保管する属性LastModificationDateの値も更新されます。

フォルダ

フォルダは他のオブジェクト（主に文書オブジェクトとサブフォルダになるフォルダオブジェクト）をリポジトリの階層構造を構成する基本要素です。それ自身も格納可能なオブジェクトであり、独立したオブジェクトでもあります。文書オブジェクトとは異なり、ContentStreamを持ちませんしバージョン管理の対象にもなりません。フォルダは親となるそのフォルダ自身を格納しているフォルダと、子となる「格納可能なオブジェクト」の集合から構成されます。

CMISのフォルダには他の基本オブジェクトにはない2つの制約がかけられています。1つは「全体のルートであるRoot Folder以外のフォルダオブジェクトは、必ずただ1つの親フォルダを持つ」、もう1つは「循環する包含関係は成立しない。自分自身を子孫にもつフォルダは作成できない」というものです。この2つからの帰結として、フォルダオブジェクトはリポジトリ内にツリー構造を構築することになります。（この制約は他の格納可能なオブジェクトには設定されていません。マルチファイリングが可能なリポジトリでは、複数のフォルダに格納される文書が存在しえますし、アンファイリングをサポートするリポジトリにはどのフォルダにも格納されない文書というものがありえます）

格納するオブジェクトのタイプに制限をかけることも可能です。フォルダオブジェクトにはAllowedChildObjectTypeIDsという復数の値を持ちうる属性が定義されており、そこに格納を許可する格納可能なオブジェクトのタイプの集合をセットします。この属性が設定されていない場合はすべての格納可能なオブジェクトのタイプが許可されたことになります。（オブジェクトタイプによる格納制限の機能をもたないリポジトリ製品の場合はこの値を設定しないことで整合をとります）

フォルダオブジェクトに対してもCRUD操作のメソッドが提供されています。オブジェクトをフォルダに格納するaddObjectToFolderサービス。フォルダからオブジェクトを取り除くremoveObjectサービス。オブジェクトの移動をさせるmoveObjectサービス。ツリー構造毎取り除くdeleteTreeサービス（アンファイリングのサポートがあれば取り除かれたサブツリーを保持されるが、そうでない場合は予め格納されているオブジェクトを削除する必要がある）。フォルダ構造のナビゲートして各種ノードの情報を取得するためのgetChildren、getDescendants、getFolderParent、getObjectParentなどのサービスがあります。ツリー構造のトラバースが深さ優先か幅優先かはリポジトリ製品の実装に依存します。ページング機能についても特に規定はありません。

フォルダの階層構造によるパスは"/"区切りで表現されます。また、文書オブジェクト自体はパス表現を持ちません。

関連

関連は、独立したオブジェクトではなく、ContentStreamを持たず、バージョン管理もされず、クエリの対象外で、格納可能でもありませんが、コントロール可能なオブジェクトです。つまり、関連の関連はつくれず、フォルダに格納されることもありませんが、ポリシの適用は受ける可能性があります。関連は、文書・フォルダ・ポリシなどの独立したオブジェクトを2つ、ソースオブジェクトとターゲットオブジェクトとして指定する形でそれらの関係性を表現するオブジェクトとして作成されます。関連は対象のオブジェクトを「汚染しません」。対象のオブジェクトに対して関連を設定したり、その関連の状態を変更しても、それらのオブジェクト自体が更新されたとはみなされません。（結果としてLastModificationDateの値も変わりません）

1つのオブジェクトに複数の関連を設定することもできますし、同じソースオブジェクトとターゲットオブジェクトの間に別の関連をさらに設定することも可能です。関連づけされているオブジェクトが削除された場合に関連を自動削除するかどうかについてはリポジトリの実装依存となります。また、関連自体にもタイプ付けが可能であり、アプリケーション独自の属性が割り当てられる可能性があります。

関連についてもベーシックなCRUD操作のサービスが提供されます。生成はcreateRelationshipサービスで行い、削除にはdeleteObjectサービスを使います。関連独自の操作としてはgetRelationshipsサービスを使って対象のオブジェクトに設定されている関連のセットを取り出すという方法も提供されています。

ポリシ

ポリシはアクセスコントロールリストや有効期限管理などの管理的な操作に関する情報を表現するオブジェクトです。しかし管理的な操作の詳細定義はCMISのスコープ外であるため、ここでは基本的なモデルだけが定義されています。詳細の機能はリポジトリ製品に依存しますが、このポリシオブジェクトを使うことでそれぞれの機能を識別するための文字列をハンドリングすることができるようになっています。

ポリシオブジェクトの生成、管理だけでなく、個々のオブジェクトにそれらのポリシを適用するための仕組みも定義されています。ポリシを適用できるオブジェクトを、「コントロール可能なオブジェクト」と呼びます。ポリシとそれらのオブジェクトの関係は多対多です。1つのポリシを複数のオブジェクトに適用することも、1つのオブジェクトに複数のポリシを適用することもできます。ポリシの適用は関連の設定と異なり対象のオブジェクトの状態を変更します。

ポリシのCRUD操作についても基本的なサービスが提供されています。createPolicyサービスで作成し、deleteObjectサービスで削除できます。独自の操作としてはポリシの適用を行うapplyPolicyサービス、適用済みのポリシを取り外すremovePolicyサービス、適用されているポリシのリストを取得するgetAppliedPoliciesサービスなどがあります。

（文責 Ishii Akinori ITC）

ECM製品の基本的な仕組み（Insight Nowより転載）

技術的な面からECM、EDMSの製品のアーキテクチャを簡単にご紹介することで、実際にそれらのシステムでどういうことができるのか（技術的な意味では、それらのシステムの内部でどういうことがおきているのか）をご紹介したいと思います。

　前稿では今現在ECM（企業向けコンテンツ管理）製品と呼ばれている製品が、かつて電子的文書管理システムEDMSと呼ばれていた製品群の系譜にあり、SOAのニーズに対応する正統進化形であるというお話をさせて頂きました。本稿では、技術的な面からECM、EDMSの製品のアーキテクチャを簡単にご紹介することで、実際にそれらのシステムでどういうことができるのか（技術的な意味では、それらのシステムの内部でどういうことがおきているのか）をご紹介したいと思います。

　今回も、電子的文書管理システムEDMSの初期製品群に多く見られたアーキテクチャから順を追って現在のECM製品のアーキテクチャまでをご紹介するという形で、EDMSからECMへの流れに沿ってご説明します。

　
初期EDMS

　当時はクライアントサーバ型のアプリケーションが全盛であったため、基本的な構造はそれにならったものになっています。各クライアントPCには専用の EDMSクライアントソフトウェアを導入する必要がありました。この方式は、すべての文書のやりとりをクライアントソフトウェアのレイヤで押さえることができるため、アクセス制御や操作記録の取得のためには有利でした。しかし、ソリューション実現のために必要な追加開発も、ある程度の部分は「クライアントソフトウエアの改修」という形で行わざるを得なかったため、保守性という意味では多くの課題を抱えていました。また、サーバ側ですが、基本的には文書の実体を保存するファイルシステムと文書の付帯情報（属性、メタデータ）を保存するデータベースの 2つのコンポーネントをラッピングした作りになっていることがわかります。データベースに属性情報専用の記憶領域を用意することで、標準ファイルシステムが持つ属性の制限（所有者、最終更新日など）に捕らわれず各文書とそれを利用する業務に必要な各種付帯情報を一括管理できる、というのが以後ECMまで続く一連のコンセプトの根幹をなしているアイデアです。この属性情報を操作することで、文書のステータス管理やワークフローなどの複雑な機能が実現されてきました。

　
後期EDMS

　このタイプは初期型EDMSが近年のIT環境の変化の中で成熟していった結果であると言えます。やはり、インターネットの影響は大きく、Webアプリケーションとしてクライアントインストールを要求しないモデルの製品が増えてきました。これにより初期のEDMSの最大の問題点であった保守性は、それなりに向上したと言えそうです。また、他の業務システムとの連携に対するニーズも高まる一方であったため、各種の「ブリッジ」「コネクタ」と言われるオプション製品が各EDMSベンダから発表されました。これらの連携ソリューションは製品設計のターゲットに近い利用形態であれば非常に強力なものとなりえましたが、連携対象とEDMS製品の双方に対するバージョン依存や利用事例の少なさからくるソフトウェアの品質の問題で広く普及するには至らなかったようです。また、これは初期の頃からも言われていたことですが、「ホワイトカラーの業務時間の80％が情報の探索に消費されている！」というスローガン（？）のもと、コンプライアンス向上だけでなく業務効率向上に繋がる機能が強く求められました。インターネットの世界での検索エンジンの台頭とあわせて各EDMS製品に実効的な全文検索エンジンが搭載されたのもこの世代の製品群の特徴と言えそうです。これ以降、前述のファイルシステムとリレーショナルデータベースに加えて全文検索エンジンもこれらの製品の柱となる要素の一つに数えられるようになりました。

　
ECM

　最後に現代の製品群のアーキテクチャをご紹介したいと思います。ご覧の通りその実態は後期EDMSとほとんど変わるところがありません。つまり、誤解を恐れずに言い切ってしまえば、EDMSからECMへの進化の過程にこれといって大きな技術的なブレークスルーは存在しなかった、ということの証左でもあるかと思います。それでも、文書からコンテンツ（＝企業内の全ての非定型データ）と対象を広く捉え直しより広い範囲で単一のリポジトリを活用するモデルを提示したことと、それをSOAを背景とした標準的な手法で統合するという方法を実現したことのインパクトはそれなりに意味があるものだと思います。

　上記の「後者のSOAを背景にして」の部分は前稿からの筆者の主張でありますが、「文書からコンテンツ」のところに関しては込み入った議論がありますので、次稿にて所謂CMSとここでいうECMの違いという形でもう一度ご説明したいと思います。

SOA時代のファイル（情報）管理基盤 ECMとは （Insight Nowより転載）

　ECM - 企業向けコンテンツ管理というキーワードは、ERPやCRMなどと並ぶ"ITに関するコンセプトとそれを実現するための製品群を示す言葉"として、ここ数年で急速に市民権を得たものの一つであると言えます。本稿ではECMを、SOA時代のファイル（情報）管理基盤、と位置づけ、その狙いや求められる機能などについて概説していきたいと思います。

　ECM - Enterprise Content Management、企業向けコンテンツ管理というキーワードは、ERPやCRMなどと並ぶ"ITに関するコンセプトとそれを実現するための製品群を示す言葉"として、ここ数年で急速に市民権を得たものの一つであると言えます。そのコンセプトを一文で表現するのであれば、「企業内のコンテンツを統一的なプラットフォームに集約し管理精度を向上させる」といったところでしょうか。AIIM（Association for Information and Image Management）という米国の団体では「ECM(Enterprise Content Management)とは、企業内全域に渡って、「コンテンツ」を、獲得capture・管理manage・保持store・保管preserve・配布deliverするための、技術やツールや手法のことである」という言い方をしています。

　本稿ではECMを、SOA時代のファイル（情報）管理基盤、と位置づけ、その狙いや求められる機能などについて概説していきたいと思います。

　まず、先ほどの表現における「企業内のコンテンツを」の部分から、考えてみましょう。ここでいう"コンテンツ"とは「企業内にある非定型データ」を意味しています。従来の業務システムで取り扱われるデータがRDBMSなどに格納される定型データであるのに対し、実際に企業内に存在する情報の大部分は実はWordやExcelなどのオフィスツールで作成された文書や電子メールなどの非定型データであると言われています。この非定型データを如何に効率良く管理していくか、というのが今後大きなテーマとなっていくだろう、というのがコンセプトとしてのECMの出発点です。

　次にそのコンセプトを実現するソフトウェアとしてのECM製品に必要な機能について解説したいと思います。非定型データ、という抽象的な言い回しを持ち出すまでもなく、文書というものはずっと以前から企業内に存在していましたし、その管理が大きな経営課題であることもよく知られていました。文書管理システム、電子的文書管理と言われるソリューションにはすでに数十年の歴史があります。ECMはそれらの議論の延長線上にあるものであり、ECM製品と呼ばれるソフトウェアは基本的にかつて文書管理システムと呼ばれたパッケージの機能を継承したものだと言えます。そのため、以下にご紹介する機能の多くが文書管理システムが伝統的に備えてきた機能でもあります。

「柔軟なアクセス管理機能」通常のOSレベルの読み書き権限よりも数段細やかな設定ができる製品が多いです。文書ファイル本体に対する読み書き権限とそのファイルの属性への読み書き権限を個別に与えたり、新規ファイルの作成はできるが既存のファイルは編集できないという権限や、逆に既存のファイルの編集はできるが新規ファイルの作成はできないという権限を設定することができます。また、文書毎のステータスに応じてアクセス権限設定を変更するという機能を持つものもあります。

「バージョン管理機能」各文書の過去バージョンを全てリポジトリ上に保存しておく機能です。操作ミス等による作業途中バージョンの散逸を防ぐだけでなく、コンテンツの編集経緯を共有できるというメリットもあります。

「チェックアウト・チェックイン機能」リポジトリ内のコンテンツを編集する際に他のユーザと同時書き込みを行ってしまうリスクを回避するために、あらかじめロックをかける機構です。チェックアウトの処理を実行すると、リポジトリ内の別の場所、もしくはユーザのローカルに「ワーキングコピー」と呼ばれるファイルが生成されます。そのファイルを編集した後でチェックインすることによりリポジトリ内のコンテンツのバージョンが更新されます。チェックアウトされている間、リポジトリ内のコンテンツ本体は編集不可の状態になります。

「独自属性の定義機能」業務上の要請により企業内の文書には様々な付帯情報が割り当てられています。どのような属性情報を持たせるかは文書の種類によって異なるため、多くの製品にユーザが独自に属性情報を定義する機能が備わっています。文書の種類によってアクセス権を変更する、などのコントロールを持たせることもあります。この文書の種別の特定と、管理すべき属性情報の定義は、文書管理やECMの導入プロジェクトの中でも特に重要なステップとなります。

「ワークフロー機能」各ユーザに対して「編集」「レビュー」「承認」などのタスクを依頼し、その流れを管理する機能です。予め定義された業務の流れに従って各タスクが実行されるため業務遂行の精度向上が期待できます。また、各ユーザは自分に割り当てられたタスクの一覧を常に確認できるようになります。専用の所謂ワークフローツールと違い、原則的には社内にある文書全てを同様の業務フローの遡上に載せることができるというのが、文書管理システム（あるいはECM）でワークフローを実現することのメリットであると言われています。

「監査証跡機能」リポジトリ内の各コンテンツに対して、いつ誰がどのような操作を行ったのか、を記録していく機能です。操作ログがコンテンツ管理に保管されていく形式が一般的であるようです。内部統制、コンプライアンスなどの文脈によって注目度が高まっている機能です。伝統的な文書管理システムの多くは高価なパッケージ製品であったため、強制力のあるコンプライアンスの法的要件をもつ金融業界や製薬業界での稼働事例が多く、この監査証跡機能も必須機能と認識されてきました。

　さて、ここまで挙げた各機能は、かつて文書管理システムと呼ばれていた現在のECM製品の祖先にあたるソフトウェアにもすでに備わっていたものばかりです。「コンテンツ」という用語の定義もすでにご紹介しましたので、管理対象が文書からコンテンツへとより抽象化されたのがECM製品である、という解釈をされている方もいらっしゃるかもしれません。それはそれで正しい見方であるとも言えるのですが、本稿においては表題にもあります通り、SOAの文脈を絡めた視点を提示したいと思います。

　SOA的な視座からシステム設計を考える時、そこにファイル単位の情報を保管あるいは流通させるのであれば、それらの情報の管理手法や管理精度に対してもある程度抽象的なインターフェースを提示し、他のコンポーネントとの連携方法を捉える必要があります。そこで要求される機能は、伝統的な文書管理システムが培ってきた上記の各種機能とほぼ同じものです。今までの文書管理システムは、中央集権的なリポジトリに各種文書を集約することで、各ユーザが適切な手法で文書を活用できるような基盤を提供していく、ということをしてきたわけですが、SOAの文脈においては人間のユーザだけでなく他のシステムも同様にこのリポジトリの恩恵にあずかるように方向付けていくことが求められている、というわけです。それを実現しているのが、現在のECM製品群であるといえるでしょう。（文書管理システムと他システムの連携ということ自体は以前からも積極的に行われてきたことですが、連携の方法がサービスという粒度で捉えられ、また標準的なプロトコルによって実行されるというところが相違点になると思われます）

　単純にECM製品と呼ばれるソフトウェアを導入し、重要文書から順に格納していくという方針でもコンテンツの管理精度を向上させることは可能です。しかし、本当にECMを効果的に導入しようと考えた場合は、現在あるいは将来の各ユーザと各連携対象システムのニーズに柔軟に対応できるような計画をたてて行く必要があります。基盤として活用されたときに最も効果を発揮する、という性質があるため、計画段階から慎重に導入製品を選定する必要もあるでしょう。

　次稿以降では、ECM製品の基本的な仕組み（物理的な構成要素）やWebコンテンツ管理のためのCMSと呼ばれる製品群との相違、オープンソースで実現するECMなどの話題に触れていきたいと思います。ECM導入計画の立案や製品選定などのご参考にしていただくことを目標に、順次記事をアップロードしていく予定です。