[http://www.aegif.jp/event/seminar090514](http://www.aegif.jp/event/seminar090514)
こんにちは。aegif 技術担当役員の石井です。
この場では事後の報告ということになってしまいましたが、先月14日にAlfresco Software社CEOのJohn Powell氏を招いてセミナを開催しました。
JohnさんのプレゼンはAlfrescoの近況報告のようなもので、各国の事例や最新の統計などを説明する内容でした。他にもアイ・ティ・フロンティアさんとレッドハットさんからもそれぞれ講演を頂いたので、その内容を簡単に振り返りたいと思います。
まずは、アイ・ティ・フロンティアさんから。AlfrescoをベースとしたSaaS型ECMサービス、OluOlu Cabinetのご紹介でした。OluOluというのは「快適な」という意味をもつハワイ語だそうです。今回ご紹介頂いた、OluOlu CabinetはOluOluという企業向けのSaaSによるサービス体系の一部を担うECMサービスという位置づけになります。このOluOlu CabinetのバックエンドにAlfrescoが利用されているわけです。
単なるAlfrescoのホスティングではなく、アイ・ティ・フロンティアさんでは、業務指向のテンプレートに加えて幾つかソフトウェア的な強化を行っています。なかでもインパクトが強そうなものが2点ほどあって、1つは、Flexベースのリッチクライアントです。OluOlu CabinetだけでなくOluOluのサービス全体に対するダッシュボードとして用意されたもののようです。もう1つは、ワークフローデザインのためのGUIです。Alfrescoのワークフロー定義は基本的にXMLファイルを直接編集する形で作成します。（jBPMワークベンチを使えばステップの流れ自体はGUIで作成することができますが、JavaScriptなどを埋め込みなどに対応していないため結局は直接編集が必要になるというケースが散見されます）。OluOlu Cabinetでは基本的なワークフローであれば管理者用のクライアントアプリケーションから直接編集できるようになっています。ワークフローに着目してECMの導入を検討されている方にとっては非常に魅力的なのではないでしょうか。これらの機能のスクリーンショットも、OluOluのサイトで見ることができます。[https://www.oluolu-itfrontier.com/web/oluolu/service/cabinet](https://www.oluolu-itfrontier.com/web/oluolu/service/cabinet)
次にレッドハットさんから「JBoss 活用事例の紹介と最新製品ロードマップ」という題の講演をいただきました。Linux界隈のミドルウェアビジネスの現状や今後の展望などが非常にわかりやすくまとめられていました。やはり印象的だったのは、Redhat、JBossという我々からみれば非常に大きなブランドを掲げてビジネスをされている人でも、日本での展開やオープンソースソフトウェアを活用したサービスのビジネスという意味では、まだまだ市場へのアピールが足りていない、と感じられているように思えたことです。レッドハット社の人が、自分の会社のビジネスを新奇性があるメッセージとして語り、またそれを新鮮なプレゼンとして受け取ることができるというのは私にとって非常に意外な体験でした。
最後に主催者である弊社から私が、オープンソースソフトウェアを活用したTCO削減についてお話をさせて頂きました。非常に大雑把に内容を要約しますと、ものを安く買う（TCOの話ですので）方法は、買う内容が決まっている状況では基本的に「仕入れ先を一本化してボリュームディスカウントを得る」か「複数の仕入れ先候補に相見積もりを出させてディスカウント提案を引き出す」のどちらかしかない。しかも前者の場合でも、定期的な契約の見直しスキームなどロックインによる値のつり上げを防止する策がなければ長期的なメリットがでない。という通常のコスト削減プロジェクトの議論をオープンソースのメリットの説明にかぶらせたような話をさせて頂きました。
弊社主催のセミナというのはこれが初めてで、運営その他の点についてもいろいろと至らない点があったと思いますが、参加してくださった皆様、講演をしていただいたパートナ企業の皆様、本当にありがとうございました。アンケートの結果を見ても、概ね成功であったと言って良いのではないかと考えています。また機会があればよろしくお願いします。
��文責 Ishii Akinori ITC）
2009年6月19日金曜日
2009年6月18日木曜日
Blog再開（？）
大変ご無沙汰しております。aegif 技術担当役員の石井です。
前回も「大変ご無沙汰しております。」で、書き始めていましたが、またも3ヶ月あまりも間があいてしまいました。
その間にも、Alfresco社の社長を招いてのセミナーを開催したり、弊社のメンバーがAlternative Blogを始めたり、といろいろな動きがありました。
今後はもう少し情報発信の量を増やしていきたいと思います。（いつも同じようなことを書いているような気がしますが）
��文責 Ishii Akinori ITC）
前回も「大変ご無沙汰しております。」で、書き始めていましたが、またも3ヶ月あまりも間があいてしまいました。
その間にも、Alfresco社の社長を招いてのセミナーを開催したり、弊社のメンバーがAlternative Blogを始めたり、といろいろな動きがありました。
今後はもう少し情報発信の量を増やしていきたいと思います。（いつも同じようなことを書いているような気がしますが）
��文責 Ishii Akinori ITC）
2009年6月17日水曜日
ようやく策定されたECMのための共通言語 CMIS（3/3） （Insight Now!より転載）
2/3を公開してからかなり時間がたってしまいました。申し訳ありません。
#実は1度にまとめて書いているので、単純なアップロード作業のミスなのですが・・・
リポジトリのモデルや基本となるオブジェクトタイプについてはすでにご説明しているので、本稿では独自のオブジェクトタイプの実装に関する規程と、各オブジェクトに対する操作をとりまとめたサービスについてご紹介したいと思います。
カスタムオブジェクトタイプ
オブジェクトタイプは属性の組み合わせによって定義されます。CMISにおけるオブジェクトは強い型付けがなされ、未定義の属性をインスタンスレベルで後から追加するという仕組みはありません。（JCRにおけるResidual属性、WebDAVにおけるDead属性にあたるものはサポートされません。定義にない属性が検出された場合は例外として扱います）
オブジェクトタイプ自体のユニークネスを確保するため、システムからユニークな識別子をタイプIDとして割り当てます。また、オブジェクトタイプの定義にも継承による階層構造を利用できます。継承の仕組みは以下のルールに従います。
・ルートタイプは親タイプをもたない。ルートでないタイプは必ず1つだけ親タイプを持つ。
・オブジェクトタイプは（それ自体オブジェクト型のものを含む）属性の集合として定義される。属性のオブジェクト型には継承機能は適用されない。
・サブタイプには親タイプで定義されている属性がすべて適用される。何かの理由で親の属性の一部を継承したくない場合は、定義ではなく値を未設定とする。
・クエリにタイプ名を使った場合は子孫タイプのすべてが対象となる。
・ルートタイプは基本オブジェクトタイプである文書・フォルダ・関連・ポリシの4つのみ。
さらにすべてのオブジェクトタイプに共通する属性がいくつか定義されています。
・ObjectTypeId オブジェクトタイプの識別子。リポジトリ内でユニークでなければならない。
・ObjectTypeQueryName SQLクエリ内でのテーブル名。
・ObjectTypeDisplayName アプリケーションに表示される名前。
・ParentTypeId 親タイプのID。
・RootTypeQueryName ルートタイプのテーブル名。
・Description アプリケーションによるタイプの説明。使いかたなど。
・Creatable 当該オブジェクトタイプのオブジェクトを新規作成可能かどうかを判別するフラグ。
・Queryable クエリで使えるかどうかを判別するフラグ。関連クラスには適用できない。
・Controllable ポリシを適用可能かどうか判別するフラグ。
・IncludeInSuperTypeQuery 親タイプを指定したクエリの対象とするかを判別するフラグ。
文書タイプのサブタイプを定義するために、追加で以下が定義されています。
・Fileable フォルダに格納できるかどうかを判別するフラグ。関連の場合はFalse。
・Versionable バージョン管理の対象かどうかを判別するフラグ。
・ContentStreamAllowed ContentStreamを持てるかどうかを表現する。"持てない""持てる""必須"の3段階。
関連タイプ向けにも追加で以下が定義されています。
・AllowedSourceTypes ソースオブジェクトとして許可されるタイプのID。
・AllowedTargetTypes ターゲットオブジェクトとして許可されるタイプのID。
さらにカスタムの属性を定義するために、各属性項目自体が持つ属性の規定があります。
・PropertyName 属性の名前。SQLクエリのカラム名としても利用。
・PropertyId リポジトリ内でユニークなID。
・DisplayName アプリケーションで表示される名前。
・Description アプリケーションによる属性の説明。使いかたなど。
・IsInherited 親タイプですでに定義されていたかどうか。
・PropertyType 属性値のタイプ。
・Cardinality 単一の値を持つか、複数の値を持つか。
・Choices オプショナルの属性で、アプリケーションが値選択式のUIを利用できるようにする。
・OpenChoice Choices利用時に自由記入を可能にする。
・Required 必須項目にする。
・DefaultValue デフォルト値を設定。
・Updatability 属性値の変更可能性。「読み取り専用」「変更可」「チェックアウト時変更可」の3つがある。
・Queryable クエリに利用できるかどうか。
・Orderable 整列可能かどうか。
・Precision 小数値向け。精度。
・MinValue 整数値向け。最小値。
・MaxValue 整数値向け。最大値。
・MaximumLength 文字列向け。最大長。
・SchemaURI XML属性向け。スキーマのURI。
・Encoding XML属性向け。エンコーディング情報。
以上の項目を組み合わせて新しいオブジェクトタイプを作成することができます。
クエリ
CMISで定義されているクエリ文法はSQL-92を下敷きにしたものになっています。また、データ操作については特に規定されておらず、読み取り専用の「リレーショナルビュー」という位置づけのものになります。
コンテンツリポジトリの情報を組み合わせたヴァーチャルなテーブルを想定し、そこへのSELECT文による問い合わせを行うためのルールが整備されている、という状況です。具体的には、オブジェクトタイプ（とその派生タイプ）毎にテーブルが作成され、行は個別のオブジェクトを、列は属性を表現する形になります。（値がセットされていなかったり、継承を受けていない属性の値はNULLになります）
基本的には属性値のテーブルになるので、ContentStream自体への直接的なアクセス手段はこのCMIS SQLの枠組みでは定義されていません。Object IDを取得したあとでメソッド経由でアクセスすることになります。
演算子や複数の値を持ち得る属性と単一の値しかない属性の違いによる振る舞いの違いについて仕様書上には幾つかの言及があるのですが、ここでは割愛させて頂くとして、4つほど特徴的な構文（述語、関数）があるのでそれらについてだけ簡単に紹介したいと思います。
・CONTAINS（[識別子],<検索文字列>） 全文検索による条件づけ。
・SCORE（） 全文検索によるスコアの取得。
・IN_FOLDER（[識別子],<フォルダのID>） 対象フォルダに格納されている、という条件を表現。
・IN_TREE（[識別子],<フォルダのID>） 対象フォルダもしくはそのサブ（子孫）フォルダに格納されている、という条件を表現。
サービス
・共通サービス要素
特にメソッドは定義されず、例外などが整備されています。例えば以下の例外はCMISサービス全体で共有され、各サービスともに発生させる可能性があります。
InvalidArgmentException 引数が不正
ConstraintViolationException 制約が満たされていない
ObjectNotFoundException オブジェクトが見つからない
PermissionDeniedException 権限が不十分
OperationNotSupportedException オペレーションがサポート（許可）されていない
RuntimeException （随時発生）
その他特定のサービスからしかあがらないような例外も定義されています。
ContentAlreadyExistsException 作成しようとした文書がすでに存在している
FilterNotValidExeption プロパティフィルタの条件にあわない（属性値を取得するメソッドは、対象属性を制限する"プロパティフィルタ”という文字列を受け取ることがあります。プロパティフィルタの実体はワイルドカードである*か属性名をカンマで繋げた文字列です）
StorageException 容量不足などのストレージエラー
StreamNotSupportedException 対象のタイプはContentStreamをサポートしていない
UpdateConfilctException 更新の失敗（ロックをせずに複数ユーザの更新が重複しそうになった場合など）
VersioningException 版管理上の不整合（対象がすでに最新版でなくなっているなど）
・リポジトリサービス
getRepositories 対象サービスエンドポイントのアクセス可能なリポジトリのリストを取得
getRepositoryInfo リポジトリの情報を取得。名前、URI、対応している機能など
getTypes リポジトリ内に定義されているオブジェクトタイプの一覧を取得
getTypeDefinition 個別のオブジェクトタイプの定義を取得
・ナビゲーションサービス
getDescendants リポジトリのツリー上子孫となるオブジェクトの一覧を取得
getChildren ツリー上直下の子となるオブジェクトの一覧を取得
getFolderParent 格納されているフォルダを取得。オプションによって祖先フォルダすべての一覧も取得可能
getObjectObjectParents 対象オブジェクトを格納しているフォルダの一覧を取得（マルチファイリング）
getCheckedoutDocuments チェックアウトされている文書の一覧を取得
・オブジェクトサービス
createDocument 文書を作成
createFolder フォルダを作成
createRelationship 関連を作成
createPolicy ポリシを作成
getAllowableActions 対象オブジェクトに対して実行可能なCMISサービスコールの一覧を取得
getProperties 属性の一覧を取得
getContentStream ContentStream（ファイル実体）を取得
updateProperties 属性を更新
moveObject オブジェクトを（リポジトリのツリー上で）移動
deleteObject オブジェクトを削除
deleteTree サブツリーごとオブジェクトを削除
setContentStream ContentStreamを割当
deleteContentStream ContentStreamを削除
・マルチファイリングサービス
addObjectToFolder 対象オブジェクトをさらに別のフォルダに格納
removeObjectFromFolder フォルダから対象オブジェクトを削除（撤回）
・ディスカバリサービス
query CMIS SQLの実行
・バージョン管理サービス
checkOut チェックアウト
cancelCheckOut チェックアウトの取り消し
checkIn チェックイン
getPropertiesOfLatestVersion 最新バージョンの属性一覧を取得
getAllVersions すべてのバージョンを取得
deleteAllVersions すべてのバージョンを削除
・関連サービス
getRelationships 関連の一覧の取得
・ポリシサービス
applyPolicy ポリシの適用
removePolicy ポリシの削除
getAppliedPolicies 適用済みポリシ一覧の取得
機会があれば次は実際にCMISを使った開発の簡単なチュートリアルなどを紹介したいと思います。
��文責 Ishii Akinori ITC）
#実は1度にまとめて書いているので、単純なアップロード作業のミスなのですが・・・
リポジトリのモデルや基本となるオブジェクトタイプについてはすでにご説明しているので、本稿では独自のオブジェクトタイプの実装に関する規程と、各オブジェクトに対する操作をとりまとめたサービスについてご紹介したいと思います。
カスタムオブジェクトタイプ
オブジェクトタイプは属性の組み合わせによって定義されます。CMISにおけるオブジェクトは強い型付けがなされ、未定義の属性をインスタンスレベルで後から追加するという仕組みはありません。（JCRにおけるResidual属性、WebDAVにおけるDead属性にあたるものはサポートされません。定義にない属性が検出された場合は例外として扱います）
オブジェクトタイプ自体のユニークネスを確保するため、システムからユニークな識別子をタイプIDとして割り当てます。また、オブジェクトタイプの定義にも継承による階層構造を利用できます。継承の仕組みは以下のルールに従います。
・ルートタイプは親タイプをもたない。ルートでないタイプは必ず1つだけ親タイプを持つ。
・オブジェクトタイプは（それ自体オブジェクト型のものを含む）属性の集合として定義される。属性のオブジェクト型には継承機能は適用されない。
・サブタイプには親タイプで定義されている属性がすべて適用される。何かの理由で親の属性の一部を継承したくない場合は、定義ではなく値を未設定とする。
・クエリにタイプ名を使った場合は子孫タイプのすべてが対象となる。
・ルートタイプは基本オブジェクトタイプである文書・フォルダ・関連・ポリシの4つのみ。
さらにすべてのオブジェクトタイプに共通する属性がいくつか定義されています。
・ObjectTypeId オブジェクトタイプの識別子。リポジトリ内でユニークでなければならない。
・ObjectTypeQueryName SQLクエリ内でのテーブル名。
・ObjectTypeDisplayName アプリケーションに表示される名前。
・ParentTypeId 親タイプのID。
・RootTypeQueryName ルートタイプのテーブル名。
・Description アプリケーションによるタイプの説明。使いかたなど。
・Creatable 当該オブジェクトタイプのオブジェクトを新規作成可能かどうかを判別するフラグ。
・Queryable クエリで使えるかどうかを判別するフラグ。関連クラスには適用できない。
・Controllable ポリシを適用可能かどうか判別するフラグ。
・IncludeInSuperTypeQuery 親タイプを指定したクエリの対象とするかを判別するフラグ。
文書タイプのサブタイプを定義するために、追加で以下が定義されています。
・Fileable フォルダに格納できるかどうかを判別するフラグ。関連の場合はFalse。
・Versionable バージョン管理の対象かどうかを判別するフラグ。
・ContentStreamAllowed ContentStreamを持てるかどうかを表現する。"持てない""持てる""必須"の3段階。
関連タイプ向けにも追加で以下が定義されています。
・AllowedSourceTypes ソースオブジェクトとして許可されるタイプのID。
・AllowedTargetTypes ターゲットオブジェクトとして許可されるタイプのID。
さらにカスタムの属性を定義するために、各属性項目自体が持つ属性の規定があります。
・PropertyName 属性の名前。SQLクエリのカラム名としても利用。
・PropertyId リポジトリ内でユニークなID。
・DisplayName アプリケーションで表示される名前。
・Description アプリケーションによる属性の説明。使いかたなど。
・IsInherited 親タイプですでに定義されていたかどうか。
・PropertyType 属性値のタイプ。
・Cardinality 単一の値を持つか、複数の値を持つか。
・Choices オプショナルの属性で、アプリケーションが値選択式のUIを利用できるようにする。
・OpenChoice Choices利用時に自由記入を可能にする。
・Required 必須項目にする。
・DefaultValue デフォルト値を設定。
・Updatability 属性値の変更可能性。「読み取り専用」「変更可」「チェックアウト時変更可」の3つがある。
・Queryable クエリに利用できるかどうか。
・Orderable 整列可能かどうか。
・Precision 小数値向け。精度。
・MinValue 整数値向け。最小値。
・MaxValue 整数値向け。最大値。
・MaximumLength 文字列向け。最大長。
・SchemaURI XML属性向け。スキーマのURI。
・Encoding XML属性向け。エンコーディング情報。
以上の項目を組み合わせて新しいオブジェクトタイプを作成することができます。
クエリ
CMISで定義されているクエリ文法はSQL-92を下敷きにしたものになっています。また、データ操作については特に規定されておらず、読み取り専用の「リレーショナルビュー」という位置づけのものになります。
コンテンツリポジトリの情報を組み合わせたヴァーチャルなテーブルを想定し、そこへのSELECT文による問い合わせを行うためのルールが整備されている、という状況です。具体的には、オブジェクトタイプ（とその派生タイプ）毎にテーブルが作成され、行は個別のオブジェクトを、列は属性を表現する形になります。（値がセットされていなかったり、継承を受けていない属性の値はNULLになります）
基本的には属性値のテーブルになるので、ContentStream自体への直接的なアクセス手段はこのCMIS SQLの枠組みでは定義されていません。Object IDを取得したあとでメソッド経由でアクセスすることになります。
演算子や複数の値を持ち得る属性と単一の値しかない属性の違いによる振る舞いの違いについて仕様書上には幾つかの言及があるのですが、ここでは割愛させて頂くとして、4つほど特徴的な構文（述語、関数）があるのでそれらについてだけ簡単に紹介したいと思います。
・CONTAINS（[識別子],<検索文字列>） 全文検索による条件づけ。
・SCORE（） 全文検索によるスコアの取得。
・IN_FOLDER（[識別子],<フォルダのID>） 対象フォルダに格納されている、という条件を表現。
・IN_TREE（[識別子],<フォルダのID>） 対象フォルダもしくはそのサブ（子孫）フォルダに格納されている、という条件を表現。
サービス
・共通サービス要素
特にメソッドは定義されず、例外などが整備されています。例えば以下の例外はCMISサービス全体で共有され、各サービスともに発生させる可能性があります。
InvalidArgmentException 引数が不正
ConstraintViolationException 制約が満たされていない
ObjectNotFoundException オブジェクトが見つからない
PermissionDeniedException 権限が不十分
OperationNotSupportedException オペレーションがサポート（許可）されていない
RuntimeException （随時発生）
その他特定のサービスからしかあがらないような例外も定義されています。
ContentAlreadyExistsException 作成しようとした文書がすでに存在している
FilterNotValidExeption プロパティフィルタの条件にあわない（属性値を取得するメソッドは、対象属性を制限する"プロパティフィルタ”という文字列を受け取ることがあります。プロパティフィルタの実体はワイルドカードである*か属性名をカンマで繋げた文字列です）
StorageException 容量不足などのストレージエラー
StreamNotSupportedException 対象のタイプはContentStreamをサポートしていない
UpdateConfilctException 更新の失敗（ロックをせずに複数ユーザの更新が重複しそうになった場合など）
VersioningException 版管理上の不整合（対象がすでに最新版でなくなっているなど）
・リポジトリサービス
getRepositories 対象サービスエンドポイントのアクセス可能なリポジトリのリストを取得
getRepositoryInfo リポジトリの情報を取得。名前、URI、対応している機能など
getTypes リポジトリ内に定義されているオブジェクトタイプの一覧を取得
getTypeDefinition 個別のオブジェクトタイプの定義を取得
・ナビゲーションサービス
getDescendants リポジトリのツリー上子孫となるオブジェクトの一覧を取得
getChildren ツリー上直下の子となるオブジェクトの一覧を取得
getFolderParent 格納されているフォルダを取得。オプションによって祖先フォルダすべての一覧も取得可能
getObjectObjectParents 対象オブジェクトを格納しているフォルダの一覧を取得（マルチファイリング）
getCheckedoutDocuments チェックアウトされている文書の一覧を取得
・オブジェクトサービス
createDocument 文書を作成
createFolder フォルダを作成
createRelationship 関連を作成
createPolicy ポリシを作成
getAllowableActions 対象オブジェクトに対して実行可能なCMISサービスコールの一覧を取得
getProperties 属性の一覧を取得
getContentStream ContentStream（ファイル実体）を取得
updateProperties 属性を更新
moveObject オブジェクトを（リポジトリのツリー上で）移動
deleteObject オブジェクトを削除
deleteTree サブツリーごとオブジェクトを削除
setContentStream ContentStreamを割当
deleteContentStream ContentStreamを削除
・マルチファイリングサービス
addObjectToFolder 対象オブジェクトをさらに別のフォルダに格納
removeObjectFromFolder フォルダから対象オブジェクトを削除（撤回）
・ディスカバリサービス
query CMIS SQLの実行
・バージョン管理サービス
checkOut チェックアウト
cancelCheckOut チェックアウトの取り消し
checkIn チェックイン
getPropertiesOfLatestVersion 最新バージョンの属性一覧を取得
getAllVersions すべてのバージョンを取得
deleteAllVersions すべてのバージョンを削除
・関連サービス
getRelationships 関連の一覧の取得
・ポリシサービス
applyPolicy ポリシの適用
removePolicy ポリシの削除
getAppliedPolicies 適用済みポリシ一覧の取得
機会があれば次は実際にCMISを使った開発の簡単なチュートリアルなどを紹介したいと思います。
��文責 Ishii Akinori ITC）
2009年3月25日水曜日
Alfresco Share向けランゲージパックの公開
AlfrescoForge: Japanese Language Pack: Project Info — [sourceName]：
大変ご無沙汰しております。aegif 技術担当役員の石井です。
Alfrescoもバージョン3.0を数え、積極的な機能強化が行われてきています。
最近ですとMicrosoft Sharepointのエミュレーション機能が注目されていますが、Alfresco社自体が提供しているAlfrescoベースのコラボレーションツール、Alfresco Shareについてのご質問などを頂く機会も増えてきました。Surf Platformについての関心も高まってきているのかもしれません。
ところで、このAlfresco Shareは実は現時点では多言語化対応がされていません。Alfresco社のエンジニアとのやりとりの中で次のバージョン（3.1）では多言語対応するという話がでてきてはいるのですが、現状では英語用のメッセージファイルを上書することでしかメッセージの日本語化が行えない状況にあります。また、日本語化されたファイル自体もAlfresco本体のランゲージパックと違い、複数箇所への配置が必要になります。
昨晩、このShare用の日本語メッセージファイルををAlfresco日本語化プロジェクトのサイトにアップしました。（そしてたった今、さらなる修正版で差し替えました）
このランゲージパックにはシェルスクリプトが同梱されていますので、それを使ってメッセージファイルの差し替えもできるようになっています。まだまだ、こなれない部分もありますが、これによって日本語環境でもShareの評価をしていただけるのではないかと思います。
��文責 Ishii Akinori ITC）
大変ご無沙汰しております。aegif 技術担当役員の石井です。
Alfrescoもバージョン3.0を数え、積極的な機能強化が行われてきています。
最近ですとMicrosoft Sharepointのエミュレーション機能が注目されていますが、Alfresco社自体が提供しているAlfrescoベースのコラボレーションツール、Alfresco Shareについてのご質問などを頂く機会も増えてきました。Surf Platformについての関心も高まってきているのかもしれません。
ところで、このAlfresco Shareは実は現時点では多言語化対応がされていません。Alfresco社のエンジニアとのやりとりの中で次のバージョン（3.1）では多言語対応するという話がでてきてはいるのですが、現状では英語用のメッセージファイルを上書することでしかメッセージの日本語化が行えない状況にあります。また、日本語化されたファイル自体もAlfresco本体のランゲージパックと違い、複数箇所への配置が必要になります。
昨晩、このShare用の日本語メッセージファイルををAlfresco日本語化プロジェクトのサイトにアップしました。（そしてたった今、さらなる修正版で差し替えました）
このランゲージパックにはシェルスクリプトが同梱されていますので、それを使ってメッセージファイルの差し替えもできるようになっています。まだまだ、こなれない部分もありますが、これによって日本語環境でもShareの評価をしていただけるのではないかと思います。
��文責 Ishii Akinori ITC）
2008年11月8日土曜日
Alfresco Enterprise 3.0 Delivers Collaboration at Dramatically Lower Cost than Proprietary Alternatives
Alfresco Enterprise 3.0 Delivers Collaboration at Dramatically Lower Cost than Proprietary Alternatives — alfresco.com：
こんにちは。aegif技術担当役員の石井です。
いよいよAlfrescoのEnterprise版もメジャーバージョンアップとなりました。数ヶ月前からLabs（旧Community版）としては利用可能な状態でしたが、各所に強力な機能強化が施され、Alfrescoにとって戦略的に重要なバージョンになっています。さっそく日本語のランゲージパックも更新しForgeサイトで公開してあります。（毎度のことで恐縮なのですが、配布されているAlfresco本体のパッケージには最新の日本語ランゲージパックは同梱されていません）
本リリースの機能強化の中でも特に重要な点をご紹介しますと、
・Sharepointライクな（と敢えて言ってしまっても良いでしょう）コラボレーション環境を実現するオルタナティブクライアントであるAlfresco Shareの同梱
・テンプレートとスクリプト言語を組み合わせて軽快な追加開発を実現するSurfフレームワークの提供
・ECMの世界の共通言語となることを期待されている新規格CMISに準拠したAPIの提供
などがあげられるかと思います。
追加開発の容易性を伸ばすとともに、コラボレーション環境としての機能充実が図られています。単純な文書管理よりも広い範囲のニーズにより手軽に対応していくことが可能になっています。
��文責 Ishii Akinori ITC）
こんにちは。aegif技術担当役員の石井です。
いよいよAlfrescoのEnterprise版もメジャーバージョンアップとなりました。数ヶ月前からLabs（旧Community版）としては利用可能な状態でしたが、各所に強力な機能強化が施され、Alfrescoにとって戦略的に重要なバージョンになっています。さっそく日本語のランゲージパックも更新しForgeサイトで公開してあります。（毎度のことで恐縮なのですが、配布されているAlfresco本体のパッケージには最新の日本語ランゲージパックは同梱されていません）
本リリースの機能強化の中でも特に重要な点をご紹介しますと、
・Sharepointライクな（と敢えて言ってしまっても良いでしょう）コラボレーション環境を実現するオルタナティブクライアントであるAlfresco Shareの同梱
・テンプレートとスクリプト言語を組み合わせて軽快な追加開発を実現するSurfフレームワークの提供
・ECMの世界の共通言語となることを期待されている新規格CMISに準拠したAPIの提供
などがあげられるかと思います。
追加開発の容易性を伸ばすとともに、コラボレーション環境としての機能充実が図られています。単純な文書管理よりも広い範囲のニーズにより手軽に対応していくことが可能になっています。
��文責 Ishii Akinori ITC）
ようやく策定された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）
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のための共通言語 CMIS（1/3） （Insight Now!より転載）
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）
登録:
投稿 (Atom)