ここから本文です

CMS Watch : ウェブサービスとコンテンツマネジメント

2005年2月23日 掲載

トラビス・ウィシンク（CMSコンサルト）

過去1年の間に、ウェブサービスをベースとした技術の導入は、効率の高さを証明するとともに、未成熟な側面も露呈した。ウェブサービスのソリューションは、UDDIやWSDL、SOAPなどの安定したスペックをコアとして作られている（これらについてここでは詳述しないが、詳細はこのコラムを参照してほしい）。同時に、過去1年の間には、SOA（services-oriented architecture）というより一般的なコンセプトも台頭してきた。SOAでは、ウェブサービス標準やその他の類似したアプローチを利用して、コア機能を提示し活用できる。

理論上は、より多くのCMSがウェブサービス（または類似した構造）を通じて機能を提示するようになるのにつれて、CMSは、より幅広い企業のコンテンツ・ネットワーク全体の核になることができるようになる。そして、そうなるためには、CMSがより外向きなものとなって、企業向けの実践的なサービスを提供し、他のエンタプライズ・サービスとインタラクトする必要があるだろう。

CMSのコアサービス

CMSスイートの多くは、少なくとも次のサービスを提供している。

これらについて、ひとつずつ見ていこう。

1. CMSのコア機能とは、私が通常CMSエンジンと呼んでいる部分だが、一般にはアプリケーション・エンジンと呼ばれることも多い。
2. ライブラリ・サービスは、ライブラリ・カタログ・システムに似ている。このサービスを使って、一部のユーザーは、表示やチェックアウト、レビュー、メタデータの表示、コンテンツ・バージョンの記録ができるようになる。
3. ほとんどのCMS製品は、アセットに属性を適用するための分類条件を蓄積できるようになっている。その後、CMSは、特定のコンテンツ・オブジェクトに関連付けられたあらゆる条件を、メタデータとしてライブラリ・システムのなかに保存する。
4. ほとんどのCMS製品は、何らかのワークフロー・システムを備えており、コンテンツ作成者やコンテンツ・マネジャーがCMSアセットにまつわるビジネスプロセスを導入できるようになっている。
5. 検索とは、コンテンツ・マネジャーがCMSレポジトリを調査して、特定のアセットを探し出せるようにするためのメカニズムである。
6. 配信または展開機能とは、CMSが配信システムにコンテンツをプッシュする機能である。コンテンツを配信する先は、CMS製品によって、ファイルシステムだったりデータベースだったりと異なる。また、占有のキャッシュシステムにコンテンツをコピーできるCMSもある。多くのCMSは、これらのアプローチのコンビネーションを使っている。
7. 最後に、ほとんどのCMSは、コンテンツの変換ができるようになっている。これは、XMLコンテンツをHTMLに変えたり、標準的なオフィス・アプリケーションのファイルをPDFに変えたりするほか、その他さまざまな変換がある。

企業へのサービス提供

CMSサービスがウェブサービスのインターフェースを通じて他のアプリケーションに提示され得る状況を考えてみよう。

(クリックで拡大します)

上のイラストは、他のアプリケーションが利用できるメソッドのいくつかを示している。CMS内で呼び出したり、CMSレポジトリの外にあるコンテンツを利用したりするためのメソッドだ。

次のようなシナリオを考えてみてほしい。あなたの会社では常時、新製品をリリースしていて、それらはEカタログと通常チャネルの両方で販売している。製品リリースと同時に、あなたは、その製品に関連したコンテンツをさまざまなウェブページに展開しなければならない。そして、会社の製品データ・マネジメントシステムとEコマース・システムは、SOAを利用して、ある製品がリリースされるとCMSの配信サービスを起動し、特定のコンテンツをプロダクションへとプッシュする（CMSの外にある関連コンテンツもプッシュする）。このビジネスプロセスが自動化されすぎているというのであれば、ワークフロー・サービスをトリガーして承認プロセスを起動することもできる。

現在、これらのことは、ウェブサービスのインターフェースとしてAPIをパッケージに組み込んでいる比較的高度な2、3のCMS製品で可能だ。

他のサービスを利用する

では、逆のことはどうだろう。あなたの会社のCMSが他社のサービスを利用できるとしたら、どうなるのだろうか。残念ながら、これについてはあまり良い答えができない。多くのCMSパッケージは、サービスを作ることはできる半面、サービスを利用することはネイティブではできないからだ。これはCMSベンダーの傲慢さの表れかもしれないし（多くのソフトウェア・ベンダーは、自分たちの製品が顧客企業の情報インフラの中心に置かれていると思っている）、あるいは単に、顧客が今なお企業サービスを作成して配信するのに苦労しているため、あまり関心がないだけなのかもしれない。

しかしいずれにしても、この可能性は興味深い。ここで例として、CMSにダイナミックなスペルチェック・サービスを提供して、ローカルの辞書に頼らなくてもいいようにするという、比較的シンプルなケースを見てみよう。ここではGoogleが提供している実際の公共ウェブサービスを使うことにする（代わりに、自社のファイアーウォール内で動作している内部サービスで考えてみてもいい）。

スペルチェックが必要となるCMSのウェブフォームまたはテンプレート・エンジンでの作業プロセスを下記に書き出してみた。

1. ユーザーがCMSフォームを開いてコンテンツを編集している。
2. そのユーザーが、単語やフレーズをハイライトする。
3. ハイライトした部分を右クリックして、スペルチェックを選択する。
4. システムがSOAPメッセージを作成し、それをGoogleに送る。
5. Googleがスペルチェックの結果を返す。
6. ユーザーは、提案されたスペルの変更を受け入れるか拒否するかを選ぶ。

以下に早速コードを紹介しよう。これを見てめまいがする人は、その下のテキスト部分にジャンプしてくれていい。

下記に示したのは、Googleのウェブサービスが返すWSDLのサンプルだ。スペル提案サービスだけを示すために、他の機能の部分は割愛して示している。

次もやはり同じWSDLのサンプルだが、このスニペットでは、インプット／アウトプット・メッセージのフォーマットが示されている。

そしてこれは、SOAPメッセージのサンプル。このメッセージがスペル提案の機能に送られる。ここでは、「ブリトニー・スピアーズ」のスペルが正しいかどうかを調べようとしている。

もちろん、ここでは正しいスペルになっていないので、サービスは次のようなメッセージを返してくる。

Googleのスペル提案は、「Britney Spears」という提案を返してきた。

ここまでのコードは、実際のウェブサービスと、そのインプットおよびアウトプットを示している。すべてをきちんと機能させるのに、驚くほど少ない量のJavaコードで済むことが分かる。

スイートがないECM：サービスベースのアーキテクチャ

多くのECMベンダーは、顧客のECMニーズをすべて満たすために、さまざまなパッケージを提供してきた（なかには数十という製品やモジュールを提供しているベンダーもある）。しかし、こうすることによって、顧客は、ベンダーの囲い込み戦略にはまるうえ、驚くほど大量の統合作業を強いられるリスクを背負うことになる。さらに、具体的な用途によっては、その分野でベストのアプローチがほかにあるにもかかわず、あまり効果的でないモジュールから逃れられないという状況に陥るリスクすらある。

しかしSOAを使えば、この問題は解決できるだろう。幅広いECMアーキテクチャの一部として、専門テクノロジー（自社開発であれオープンソースであれ）を適用できるようになるためだ。可能なサービスセットを示した次の図を考えてみよう。

下の段から説明していくので、その順番に見てほしい。

第3階層

ここはマネジメントと設定の階層で、サービスを登録、定義、設定する。例えば、あるフォームサービスが、設定と、さらなる開発を必要としているとしよう。これを受けて開発者は、そのフォームサービスを変更し、必要であれば個人フォームに対するセキュリティも定義する。ビジネスマネジャーは、別の設定マネジャー（ここではBPELエディタ）でビジネスプロセスを定義する。このようなIDEは一般に、ビジネスマネジャーのデスクトップにインストールされ、ウェブベースのツールというよりはファット・クライアントとなる。

第2階層

これは提示の階層で、サービス自体を示している。この階層のサービスは、ベースとなっているベンダー製品を分離しながらも、ウェブサービスを介してアクセスできる機能を提示している。第2階層のサービスは、それぞれ独立して動作し、中央的なECMアプリケーション・エンジンはない。

私はここで、今までに説明していない3つの新しい機能を追加した。イメージング・サービス、アイデンティティ・サービス、そしてXフォーム実装だ。イメージング・サービスは、スキャン、変換、リサイズといった数多くのイメージ・アセット機能を可能にするサービスだ。アイデンティティ・サービスは、他のすべてのアプリケーションをサポートして、サービスへのアクセスや承認を可能とする。そしてXフォーム実装は、構造データの収集でユーザーを支援する。

ここには記述されたECM製品がひとつもないが、これらのサービスは本来的に製品であるか、製品のコンビネーションであることを強調しておきたい。サービスのなかにはPHPをベースとしたものとJavaをベースとしたものがあるが、いずれにしても互いのプラットフォーム言語は関係ない。どちらであれ、おそらくはウェブサービスのスペックを通じて（とはいえウェブサービスがすべてではないが）、外部のインタラクションに対して自らを提示しているためだ。

第1階層

ここは、アクセスまたはプレゼンテーションの階層である。ここには企業ポータル（EIP）のほか、ある種のディレクトリ・サービス（ウェブサービスにおけるUDDI）が置かれている。まず、UDDIは、特定のサービスが自らを登録して、他の内部システムおよび外部システムとのインタラクションを可能にする場所となる。EIPは、ここでは非常に有用なツールとなれる。企業ユーザーは、ポータルを介して特定なサービスにアクセスできるようになるためだ。例えば、人事部の採用担当者は、新しいマネジャーの採用プロセスを開始するために、ビジネスマネジャー・サービスにアクセスしたいと思うかもしれない。

実例

次の図は、データフローを示している。ここで示されているのは、ユーザーのほか、ユーザーとシステムのインタラクション・ポイント、そしてビジネスフローだ。ここでのモデルでは、ポータルのユーザーがさまざまなサービスとどうインタラクトし（おそらくポータルを介して）、週ごとのビジネス業務をどうこなしているかを示している。

コンテンツ提供者はまず、EIPのなかで認証手続きを取り、新しいコンテンツ・ポートレットへのアクセスを得る。新しいコンテンツ・タスクがトリガーされると、ビジネスプロセス・サービスがコンテンツ提供者に対して、コンテンツタイプ・タスクとポートレットを選択して、新しいコンテンツ・ワークフローを開始するよう促す。ユーザーはそれを受けてコンテンツタイプを選択し、次のタスクに提出する。ここでユーザーは、Eフォーム・ポートレットに進み、ユーザー情報を入力できる。ほとんどの場合、システムまたはユーザーは、暗示的または明示的なメタデータを適用でき、分類サービスを呼び出す。ユーザーがコンテンツを提出すると、BPMサービスがそのコンテンツを処理して、コンテンツ・ライフサイクルの次のタスクに進める。次のタスクは、コンテンツ提供者のマネジャーの受信箱に送られて、マネジャーのレビューを待つことになる。

お使いのCMSパッケージには、現時点でこれらのサービスがすべて提供されているかもしれない。しかし、すべてのタスクを同じように確実にこなしているだろうか。同じような数多くの機能を実行する企業アプリケーションが、ほかにもあるのではないだろうか。なぜ、巨大なワークフロー・エンジンをサポートする必要があるのか。機能の専門化を進めれば大きな利益があるかもしれない。

終わりに

ウェブサービスは、企業のコンテンツマネジメント機能を他のシステムに拡張したり、逆に他のシステムの機能を拡張したりすることによって、IT投資の見返りをさらに拡大し、企業を助けることができる。また、専門化の恩恵も受けられる可能性がある。SOAは、さまざまなシステムのベストの部分を引き出し、多くの企業が実現しているよりも明確な問題の分離を可能にする。さらに大手スイート・ベンダーへの依存状況も軽減できる可能性がある。

トラビス・ウィシンクは、ワシントンDCを拠点に独立コンサルタントとして活躍している。専門はWebLogic（J2EE）とInterwovenの開発、そしてコンテンツマネジメント全般。最近の実績としては、BEAとDocumentumの統合を担当するWebLogic Portalの主任コンサルタントを務めた。

この記事の原文「Web Services and Content Management」は、2004年7月20日、「cmswatch.com」に掲載された。

トラックバック

このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/107