XML がビジネスをシームレスにつなぐ
昨年、IT 業界を最も賑わせたキーワードと言えば、間違いなく「Web 2.0」だろう。サービス面ではGoogle や動画共有サイトのYouTube、ソーシャルネットワークサービス（SNS）プロバイダのmixiなど が、また技術面ではAjax、Ruby on RailsなどがWeb 2.0の枠組みの中で語られた。
とはいえ、盛り上がったのはインターネットのコンシューマ領域であり、本誌読者の多くがかかわるエンタープライズ領域には、関係の薄い話題だったかもしれない。しかし、今年はXML が持つ"つなぐ"ための技術という側面を通じて、エンタープライズ領域にWeb 2.0技術が入ってくる年になりそうだ。一技術としてのXML は標準のデータフォーマットに過ぎないが、XML データを利用するシステムが増えれば、あらゆる領域間の連携が実現されるからだ。
ここでは、XMLの"つなぐ"能力が生み出す価値について、「新サービスの創造」「業務プロセスの最適化」「開発プロセスの革新」「標準仕様の拡充」の4つの視点で展望する（図1）。
図1 XML技術が生み出す価値
新サービスを創造するWeb 2.0
XML が支える新しいサービスの創造という意味では、Web 2.0 がまさにその典型と言えるだろう。
Web 2.0 の背後にあるXML 技術
Web 2.0 はとても分かりづらい概念であるが、「Web 2.0的なもの」の具体例を見ていくと、おぼろげながらその輪郭が見えてくる。ここでは、Web 2.0的と呼ばれる2種類のサービスを紹介する。
1つは、"集合知"を主なコンテンツとするユーザー参加型のサービスだ。集合知とは、サービス利用者から提供される知識やコンテンツ、またはその意味情報などを指す。サービスプロバイダは集合知を集約し、参照できる場をWeb 上に提供する。例えば、各社のブログやYouTube の「タグ（コンテンツ内容を表わす意味情報）付け」や、Amazon の「カスタマーレビュー（商品を購入した人たちのコメント）」、mixiをはじめとするSNS などは、このタイプのサービスである。
もう1つは、Ajax やマッシュアップに代表されるWeb アプリケーションの新技術を使ったサービスである。Google が提供するGoogle Maps などはその代表例と言えよう。
これらのサービスを、必ずしもXMLが可能にするわけではないが、基盤の技術要素の中にはXML が見え隠れする（図2）。ブログの更新情報を購読者に通知するデータは、RSSやAtomというXMLフォーマットで書かれている。「ポッドキャスト」と呼ばれる音声／画像データの配信方法では、RSSで送られてくるコンテンツの更新情報を受信すると自動的にダウンロードする。また、Webサービスのマッシュアップ（組み合わせ）に使われるRESTやAjax（後述）といった技術でもXML データが利用される。Web 2.0的サービスの実現には、XMLの普及が大きく影響しているのである。
図2 Web 2.0 を支えるXML
企業内でのWeb 2.0 技術の活用
企業におけるWeb 2.0技術の活用というと、社内でのブログ活用が挙げられよう。ブログを使って、社内のコミュニケーションの活性化と情報共有を実現するのが目的だ。すでに「イントラブログ」と呼ばれる、社内ブログの専用ツールも市場に出荷されており、主な製品として日立製作所の「BOXER」、フィードパスの「blogengine」、ドリコムの「ドリコムブログオフィス」などがある。
また、Ajax によるリッチクライアントやWeb サービスのマッシュアップは、企業内のアプリケーション統合の面からイントラネットでの採用が今後本格化する可能性が高い。これについては、次節で詳しく述べる。
SOA の実現を支えるXML
SOA（Service Oriented Architecture：サービス指向アーキテクチャ）は、システムが提供する機能を「サービス」という単位で構成し、それらを組み合わせて新しいサービスを構築するという考え方である。個々のサービスは、人が行なう業務の単位でとらえることができる。SOAシステムでは、業務プロセスをサービス単位で切り出し、標準仕様であるXML データを相互にやり取りすることで各サービスを連携させる（図3）。そのため、業務プロセスの最適な組み替えを容易にすると期待されている。
そこで大手ミドルウェアベンダは、企業内でSOA に基づく連携を可能にするツール群を「SOA プラットフォーム」として提供している。その中には、サービス間でのXML メッセージ交換を行なう基盤である「ESB（Enterprise Service Bus）」、ビジネスフローを定義してシステム連携を可能にする「BPM（Business Process Management）」といったツールが含まれるなど、機能的にもかなり充実してきている。
しかし、現実にSOA でシステムを構築するには、ツール以前に何をサービスにして、どのように提供するべきかを適切に決めることのほうがキーになる。こうしたこともあり、各ミドルウェアベンダではプラットフォーム製品だけでなく、業務プロセス設計の支援サービスも提供する動きが顕著になっている。
図3 SOA のコンセプトとそのプラットフォーム
オフィス文書がXML 形式で標準化
マイクロソフト製品の寡占状態にあるオフィスツールだが、そのデータフォーマットの標準化をめぐり、「ODF（Open Document Format）」と「Office Open XML」という2つの仕様がその影響力を争っている。ただ共通しているのは、両仕様ともXML形式であることだ（図4）。
昨年OASIS標準となったODFは、さらに国際標準の公的機関ISO標準としても認定され、普及を促進する団体ODF Allianceの動きも活発になっている。ODF 準拠のオフィススイート製品には、米サン・マイ クロシステムズが支援するオープンソースソフトの「OpenOffice.org」があるが、ほかにもジャストシステムのワープロソフト「一太郎」がいち早くODF に対応。また、Web 2.0的サービスとして提供されているGoogleの文書編集Web アプリケーション「Docs＆Spreadsheet」もODFへの対応を始めた。さらに、IBMがLotus Notesの次バージョンでODF サポートを表明するなど、支持が急速に広まっている。
これに対し、マイクロソフトは同社のオフィススイート製品の最新版「2007 Officesystem」のデータフォーマットであるOfficeOpen XMLを、欧州の標準化団体ECMAに提出。昨年、標準として認められた。さらに現在、ODF と同じくISO 標準の認定を得る動きに出ている。OASISやECMAの標準は、IT 業界の"デファクトスタンダード"としての意味合いしかないからだ。各国政府が国際的な標準化機構として認めるISOの認定は、マイクロソフトとしてはどうしても得たいところだろう。
図4 ODF vs. OpenXML
開発プロセスを変えるXML-DB
次は、XMLの"つなぐ"能力が生み出す価値を「開発プロセスの革新」という視点から見てみよう。キーテクノロジーは「XMLデータベース」（以下、XML-DB）だ。
XML-DB は、固定的なスキーマを必要とするリレーショナルデータベース（以下、RDB）と比べて、データ構造の変化に強い特性を持っている。そのため、データ構造が複雑だったり曖昧だったりするために、仕様を固定するのが難しいシステムの構築や、開発中に生じる仕様変更への素早い対応ができる（図5）。
図5 XML-DBによる変化に強いシステム構成
主要RDB もXML-DB 機能を本格装備
昨年、IBMは同社のRDB製品の最新版「DB2 9」を、"ハイブリッド型"のデータベースとして発表した。ハイブリッド型とは、RDB とXML-DB の両方のメカニズムを内蔵し、両者を区別なく扱えるものだ。XML専用データ型を持ちXQueryに対応しているという意味では、「Oracle Database10g」や「SQL Server 2005」もハイブリッド型と言えるが、DB2 9のXML-DB機能はネイティブ型に匹敵する性能を備え、検索の統合をさらに進めたものだ。
ネイティブXML-DB 製品の動きも活発だ。東芝ソリューションは「TX1 V2」で、全文検索機能とデータ連携機能を追加した。三井情報システムは、同社が販売するXML-DB 製品「NeoCore XMS」をベース に、ドキュメント管理ソリューション「DocuDyne」やコンテンツ管理ソリューション「XCMS」を発表した。サイバーテックも全文検索機能などを強化した「Cyber Luxeon Ver 2.0」を出荷した。
こうしたXML-DB のトレンドについては、後ほど詳しく述べる。
XML-DB を活用する仕様／製品も進化
今年1 月、XML-DB向けの標準問い合わせ言語「XQuery 1.0」がXPath 2.0、XSLT2.0とともについに勧告、つまりW3C（World Wide Web Consortium）の標準となった。主要なXML-DB 製品は草案レベルの 仕様に対応済みだが、今回の仕様確定によってXML-DB 製品の相互運用性が高まり、XML-DBの普及も加速するだろう。
また、XML-DB活用という面では、ジャストシステムのXML 文書エディタ「xfy」にも注目したい。xfy では、通常のXMLデータはもちろん、数式を記述するMathML やベクターグラフィックスを描くためのSVGといったXML標準ボキャブラリを使用したXML文書の表示／編集もできる。DB2 9およびOracle 10gのXML-DB機能との連携を強化したエディション「xfy Enterprise Solution」も提供されており、XML-DB に格納されたXML 文書を編集するフロントエンドツールとして、またXMLDBアプリケーションの実行環境として今後の動向が注目される。
XML 標準仕様の拡充
XMLの標準化の動向が注目され続けるのには理由がある。XML が「標準を作るための標準」だからだ。XML は新しい技術の基盤を作ることができるのである。
そこで、ここではXML の基本仕様やWeb サービスの領域で大きな影響力を持つ標準化団体「W3C」「OASIS」「WS-I」の動向を確認しておく。標準化が進展した主な仕様については、表1 をご覧いただきたい。
表1 標準化が進展した主な仕様
XML 基本仕様の標準化を担うW3C
W3CはWWWで用いられる技術の標準化を進めるための団体である。これまでXMLを筆頭に、XML SchemaやXSL（Extensible Stylesheet Language）などの基本仕様や、SOAPやWSDL（後述）といったWeb サービスの基盤となる仕様などの標準化を行なってきた。
XMLの基本仕様については、先にも述べたようにXSLT 2.0、XPath 2.0、XQuery 1.0を勧告としたほか、Web サービス関連の仕様であるWS-Addressing 1.0も勧告とした。WS-AddressingはSOAP中にWebサ ービスのアドレスを含めることで、HTTPやSMTP（Simple Mail Transfar Protocol）といったネットワークのトランスポート層に依存しない連携や、非同期的で複雑な複数のWeb サービス間の通信を実現するものだ。
XML の実業仕様を標準化するOASIS
OASIS はビジネス情報の交換にかかわる仕様などの標準化を行なう団体で、XMLの前身であるSGML（Standard Generalized Markup Language）の時代から活動している。
OASIS では、商取引のためのボキャブラリ「ebXML」や、先ほど紹介したオフィス文書向けデータフォーマットであるODFの標準化などを手がけてきた。最近では、商取引についての基本的なメッセージを定めるUBL（ Universal Business Language）2.0 や、商取引のプロセスを記述するためのebBP（ebXML Business Process Specification Schema）2.0.4を標準仕様に定めた。これらの商取引関連の仕様は、企業間取引の自動化に重要な意味を持ってくる。
Web サービスに関しては、多数の分散したWebサービスを管理するのためのWSDM（Web Services Distributed Management）1.1 が標準となった。この標準は、W3C のWS-Addressing や、OASIS 標準になっているイベント通知の仕様WS-Notification、ステートフルなWeb サービスを実現するためのWS Resource Frameworkを用いながら、多様なシステムの管理を単一のインターフェイスで行なうことを可能にする。
また、SOA のリファレンスモデルを定めたSOA-RM 1.0も標準化した。
Web サービス連携を保証するWS-I
WS-Iは、Web サービスの相互運用性を保証するための標準化を進める団体である。これまでにBasic Profile と呼ばれるWeb サービス実現のためのガイドラインを策定し、標準のWeb サービス仕様をど のように実装すべきかについて具体的な指針を示している。昨年はBasic Profile 1.2を含む数本のワーキングドラフトをリリースした。その中でWS-Addressingの使用についても定められており、異なるベンダの製品間でWeb サービスのより高度な連携が可能になる。
XMLに関する最近の動向は以上のとおりだが、以降ではその中でも今年特に大きな動きになると思われるWeb 2.0技術の企業システムへの浸透と、XML-DB の動向を詳しく見ていくことにする。
企業システムに浸透し始めたWeb 2.0
ここでは、今後企業システムでの利用が広がると予想されるWeb 2.0的な技術のうち、RESTとAjaxを取り上げたい。
RESTが変えたWebサービス
まずは、これまで行なわれてきたシステム連携技術であるWeb サービスのあり方を変えると言われるREST（Representational State Transfer）を取り上げる。RESTとは何か、RESTが何を変えるのかについて、従来のWeb サービスと比較しながら説明していこう。
普及しなかった狭義のWeb サービス
Web サービスと言ったとき、「広義のWebサービス」を指す場合と「狭義のWebサービス」を指す場合とがある。
広義のWeb サービスは、前述したSOAとほぼ同じ意味で、サービスとして公開されたプログラムにネットワーク経由でアクセスし、それらを部品として利用する形態全般を指す。XML 技術をベースとする必要はない。また、広義のWebサービスは、企業や社会全体のシステムのあるべき将来像を語るときにしばしば使われる。
それに対し、狭義のWeb サービスは、Webサービス利用のために交換されるメッセージフォーマットを定義した「SOAP（Simple Object Access Protocol）」、公開されたWeb サービスの使い方や内容を記述する「WSDL（Web Service Definition Language）」、Webサービスを探すためのディレクトリサービスを定める「UDDI（Universal Description, Discovery, and Integration）」という、XML ベースで定められた仕様群を用いて構成されるシステムの形態を言う（図6）。
狭義のWeb サービスは、主要なミドルウェア製品を使えば実装できる。ただし、企業システムの将来像としては納得できても、SOAP、WSDL、UDDIが使い物になるような場面は限られるので、宣伝されているほど広く使われていないのが現状だ。SOAPなどの仕様は機能がリッチである分、理解しなければならないこともまた多く、技術面での敷居が高かったことが、その普及を妨げている。
図6 狭義のWebサービス
RESTによるWeb サービスの新しい形
こうした、従来型のWebサービスの問題をクリアする新しいWebサービスの形態と目されているのがRESTである。RESTとは、Webアプリケーションに適用されるアーキテクチャの考え方（指針）の1つだ。RESTアーキテクチャを採用したWeb アプリケーションは、以下のような特徴を持つ（図7）。
- Webアプリケーションの機能は、HTTPのメソッド（GET、POSTなど）により呼び出される
- 外部から呼び出される機能は、一意となるようなURL（もしくはURN）が割り振られている
- すべての機能呼び出しは独立しているため、クライアント側での状態維持の必要がない
現在、Web 上ではこのREST を用いたWeb サービスの利用が増加し、あっという間にSOAPを利用する狭義のWebサービスから主役の座を奪ってしまった。
RESTでは、SOAPやWSDLといったXML ベースのプロトコルを用いるわけではないが、現在の主要なREST 型Web サービスはXML 形式のデータを返すのが一般的になっている。レスポンスをXML 形式にしているのは、Webサービスのマッシュアップによるサイト構築に好都合だからだ。
マッシュアップを改めて説明すると、すでに流通しているWeb コンテンツの部品や機能をいくつか組み合わせて、新たな価値を付与した上で新たなコンテンツとして公開することである。いわば、広義のWebサービスそのものだろう。レスポンスがXML であれば、素材提供元のサイトとは異なるレイアウトで表示するのに文書構造を変換するXSLT（XSL Transformations）のような技術が使えるし、もともと無関係なサイトから入手した複数の素材を結合するのに、個々のXML データの持つ構造がとても役に立つのだ。
図7 RESTアーキテクチャ
Web サービスの3つの形
現在、主要なWebサービス提供サイトが採用しているWebサービスの形式には、REST、SOAP、XML-RPCの3種類がある（表2）。
XML-RPC方式とは、HTTPプロトコル上でリモート環境にある処理の呼び出しを実現するための方式である。REST方式と似ているが、REST 方式がHTTP プロトコル自体を使って処理を呼び出すのに対して、XML-RPC 方式はその名のとおり、HTTP プロトコル上にXML 形式のリクエストを流して処理を呼び出す。XML-RPC方式もREST方式と同じ理由により広義のWeb サービスと呼べる。
これら3 つの形式は、サービス利用者の目的に合わせて選択すれば良い（表3）。REST はほかの方式とは異なりURL による呼び出しが可能であり、レスポンスもJSON（次節にて説明）のようなXML 以外 の形式が可能であるため、JavaScriptからの呼び出しに適している。
SOAPは唯一標準化されているWebサービス方式であるため、仕様調整が困難な企業間のデータ交換に適している。XML-RPCはSOAPと同じXMLベースの仕様だが、通信プロトコルをHTTP を前提としていることや、標準化を目的としていないためにSOAPよりもシンプルかつ軽量である。RESTよりも厳密にリクエストのデータ構造を定義したいが、SOAPを使うことでサービス利用者への敷居が高くなることは避けたいサイトで利用されている。
表2 代表的なWebサービス
表3 Webサービス方式の比較
WebアプリをリッチにするAjax
もう1 つのWeb 2.0 的技術であるAjaxは、通常のWeb ブラウザ上でリッチクライアントを実現する手段として注目されている。
Google Mapsにより広まったAjax
AjaxはAsynchronous JavaScript and XMLの略で、「XML 形式のデータをクライアントの側のJavaScript とサーバーとの間で非同期のHTTP 通信により交換する」という意味である。非同期とはWebブラウザでのページ遷移を伴わずに表示情報の更新できることを言う。この仕組みを使えば、Visual Basicなどで開発したクライアントアプリケーションに似たユーザーインターフェイスをWeb ブラウザ上で実現できるのである。このことから、Ajax はリッチクライアントを既存のインフラ上で簡単に実現するために有効な技術やアーキテクチャの総称としても使われている。
Ajax は、地図情報を提供するGoogleMaps をマッシュアップした数多くのサイトとともにインターネットに広まった。さらに、GoogleはGoogle Mapsを利用するためのJavaScript コードを自動生成する ウィザード（画面）を提供しており、開発者は生成されたコードを埋め込むだけで、地図情報を利用する機能をWebアプリケーションに追加できる。
このJavaScript コードにはAjaxの仕組みが実装されていて、Google MapsのデータベースとXML 形式でデータをやり取りする。LIST に生成されたJavaScriptコードの例を示す。生成されたJavaScriptコードでは、ページ表示のためのHTTP 通信とは非同期で、Google Mapsサーバーから必要な地図情報を取得して表示するAPI（Google Maps API）を使用している。これにより、Google Mapsを一躍有名にした、Web ブラウザ画面のリロードを伴わない広大な地図のスクロールが可能となる。
XML も非同期通信も既存のインフラ上で動く、古くからある技術であるが、Ajaxはそれらを組み合わせて、新しく質の高いユーザーインターフェイスを実現できることを示した点が何より画期的であった。
Google Mapsを埋め込むためのJavaScriptを生成するウィザード
LIST 生成されたJavaScript のコード（一部抜粋したもの）
<script type="text/javascript">
function LoadMapSearchControl() {<font color="#ff0000" size="2"> var options = {</font>
<font color="#ff0000" size="2"> zoomControl : GSmapSearchControl.ZOOM_CONTROL_ENABLE_ALL,</font>
<font color="#ff0000" size="2"> title : "ウルシステムズ株式会社",</font>
<font color="#ff0000" size="2"> url : "http://www.ulsystems.co.jp/",</font>
<font color="#ff0000" size="2"> idleMapZoom : GSmapSearchControl.ACTIVE_MAP_ZOOM,</font>
<font color="#ff0000" size="2"> activeMapZoom : GSmapSearchControl.ACTIVE_MAP_ZOOM</font>
<font color="#ff0000" size="2"> } </font>new GSmapSearchControl(
document.getElementById("mapsearch"),
"東京都中央区晴海1-8-10",
options
);
}
// arrange for this function to be called during body.onload
// event processing
GSearch.setOnLoadCallback(LoadMapSearchControl);
</script>
XMLを使わないAjaxもある
一方、Ajax によって実現できるようなリッチなクライアントは、JavaScriptとXML でなくとも実装可能である。つまり、文字どおりのAjaxである必要はない。
Web ブラウザ上で非同期通信を行なう機能を実装する手段は、JavaScript以外にもある。中でもFlashはJavaScript以上の表現力を持っており、しかも昨今ではモバイル機器上の動作環境も整備されつつあることから、リッチクライアントのプラットフォームとして注目されている。
また、Flash によるリッチクライアント開発を容易にするために、Flashの開発元である米アドビシステムズはアプリケーションフレームワーク「Flex」も提供している。Flex は、Flash を使うWeb アプリケーションをJSP（JavaServer Pages）のようにタグベースで記述可能にする。タグで記述されたページは、Flexフレームワークに含まれるコンパイラによりFlashコンテンツに変換される。これまで開発生産性などの面から業務アプリケーションには向かないとされてきたFlashだが、開発／実行環境の充実により、今後リッチクライアントにおけるデファクトスタンダードになる可能性も捨てきれないと言えるだろう。
Ajax のもう1 つの要素である、通信に使用するデータ形式もXMLでなくて良い。特に注目されているのは「JSON（JavaScript Object Notation）」である。JSON はJavaScriptと親和性の高いテキスト指向のデータ形式で、そのままJavaScriptのソースコードに埋め込んで扱える。先ほどのLISTでも、オブジェクトのデータ形式としてJSONを使っている（LISTの赤字部分）。
また、JSONはJavaScript以外にもJavaやC、Perl、Ruby など、多数のプログラミング言語がサポートしており、XML に代替できるデータ標準として認知も広がってきている。
WebサービスとAjaxの今後
ここでは、企業システムに影響を及ぼすと思われるWeb 2.0的な技術としてRESTとAjaxの技術的な側面を説明してきたが、最後に、RESTやAjaxが今後どう企業システムで展開されていくのかを考えてみよう。
現実的なWeb サービスが広がる
先ほど、Web サービスの3 つの形（REST/SOAP/XML-RPC）を紹介したが、その中でもRESTの広まりの速さは驚異的であるし、SOAPやXML-RPCはその勢いに引っ張られて利用を伸ばしてきたという印象がぬぐえない。RESTが広まった最大の要因は、だれでも簡単にWeb サービスを利用可能にする、その扱いやすさにあるだろう。Google Mapsのような魅力的なサービスがREST 形式で公開されたことにより、マッシュアップで開発した新しいサービスを提供するWeb サイトが爆発的に増加したのである。
ただし、Web サービスが本格的に利用されていくためには、より多くの有益なサービスが公開される必要がある。これまでのSOAP形式によるWeb サービス公開では、必要な技術水準が高かったために ユーザーの利用が低調で、サービス公開も活発にならないという悪循環に陥っていた。RESTの成功によって多種多様なサービスの公開が進むとともに、シンプルな連携はRESTで、もっと高度な連携が必要なときにはSOAP で、という具合に公開方法を使い分けたWeb サービスが実現されていくだろう。
そしてこの動きは、インターネットからイントラネットへと展開していくはずだ。インターネットでのRESTの成功によりWebサービスの敷居が低くなった今、企業内に埋もれているアプリケーションをWebサービスにより再生しようという提案は、以前よりも企業の経営者や情報システム担当者に受け入れられやすくなるに違いない。
企業システムにおけるAjax の利用
現在の企業システムではWebアプリケーションが主流になりつつあるため、最近言われているAjax のエンタープライズ領域への進出というのも自然な流れだ。多くの企業でAjax採用の動きが具体化するだろう。そのとき、JavaScriptとXMLの組み合わせは最適だと言えるのだろうか。
表現力という面では、現時点でJavaScriptはFlashに及ばないが、運用管理面を考えるとJavaScriptは有効だ。Flashアプリケーションを稼動させるためには、WebブラウザにFlash動作環境をプラグインする必要があるが、JavaScript はWeb ブラウザだけで良いので、情報システム管理者がクライアント端末の管理をするときに余計な手間がかからない（図8）。
また、Flashは特定の企業が仕様をコントロールしているのに対し、JavaScriptはオープンな技術なので、技術者の調達などで圧倒的に有利だ。クライアントをリッチにすることが業務効率にどの程度寄与するのかを客観的に評価するのは難しいので、情報システム部門としてはFlash採用を決断することは当面難しいだろう。
データ形式については、JSONはJavaScriptと相性が良く、仕様もXMLより単純で習得しやすい。その反面、どういった業務でどのような目的に使われるデータなのかを厳密に定義するには、XML のほうが 適している。特に企業間でのデータ交換において、あいまいさはシステム開発に大きな負担を強いる。さらに、すでに企業間データ交換の主流となっているXMLには、ほかのさまざまなデータ形式からの変換ツールが用意されている。そのため、企業内に存在するさまざまな業務データを連携するにはXML が有利である。
こうして考えてみると、AjaxがJavaScript ＋XML であることによるメリットは、今後、企業システムへAjaxの導入が進む過程で判明してくるように思われる。その一方で、Flashの持つ豊かな表現力やJSONの簡単さにメリットを感じ、積極的に利用している人々がいるのも事実である。システム構築にAjaxの適用を考えるのであれば、Ajax に何を期待するのか、もう一度考えてみる必要があるだろう。
図8 リッチクライアント実現に必要な動作環境の比較
使いどころが見えてきたXML-DB
ここ数年、次々に新しいXML-DB 製品が登場し、機能も特性もバリエーションが増してきた。本節ではXML-DB とはそもそも何であるかを改めて確認した上で、今後の本格導入にあたって押さえておくべきポイントを見ていくことにする。
XML-DBとはそもそも何か
まず、XML-DB とはどのようなデータベースであり、何ができるのか、どのような課題を抱えているのかなどについて説明しよう。
階層構造を扱う
XML-DBとは、XMLの持つ構造を活かした形でデータを格納し、それに対する操作を可能にするデータベースのことである。XML の持つ構造とは、タグを用いて表現されたデータの階層構造のことだ。XML-DBは、これをそっくりそのままデータベース化してくれる。これまでよく行なわれてきたRDB への格納方法では、RDBのリレーショナル形式（表形式）にあてはまるように、XML データを要素レベルで 分解していた。
XMLドキュメントの検索が速い
XML-DBの最大のメリットは、XMLドキュメントの検索が速いことだ。基本的に表形式であるリレーショナルデータでは階層構造をうまく表現できないため、検索性能を上げることが難しい。XML-DB は、 階層構造のデータを効率良く扱うメカニズムを備えている。
大量のXMLデータを安全に管理できる
データベースである以上、大規模なデータを安全に管理するという役割が求められる。初期の製品が普及できなかったのは、ここが不十分だったためだ。1GB 以上のデータを格納できなかったり、できてもパフォーマンスが出ないものが多かった。また、トランザクション機能が不十分なため、更新時にデータの安全性を保てないような製品まであった。
これらの問題については、最近の製品では解決済みだ。数十～数百GB規模のデータを高速で扱うことができるのは当たり前になり、トランザクション機能をはじめとする安全性にも十分な配慮がなされている。
製品選定のミニマムチェックポイント
次に、XML-DB 製品を選定する際に最低限気を付けたいポイントをいくつか挙げよう。
XML-DBの格納タイプは何か
現状のXML-DBは、XMLデータを専門に扱うことに特化した「ネイティブ型」と、RDB にXML データを扱う機能を加えリレーショナルデータと統合して扱えるようにした「ハイブリッド型」の2 つに大別で きる（図9）。「NeoCore XMS（三井物産）」「Cyber Luxeon（サイバーテック）」「TX1（東芝ソリューション）」などはネイティブ型、「Oracle Database 10g（オラクル）」「DB2 9（IBM）」「SQL Server 2005（マイクロソフト）」などはハイブリッド型である。
膨大なXML データを主に参照するような場合は、ネイティブ型のほうが向くだろう。XML データも扱うが、リレーショナル型のデータが主となるような場合であればハイブリッド型は有力な選択肢だ。 また、ネイティブ型でもハイブリッド型でもない「Shunsaku（富士通）」のようなエンジンもある。この製品は全データをサーチするタイプで、検索の高速化に用いるインデックス自体がまったく不要であるという特徴がある。
図9 3種類のデータベース
XQuery に対応しているか
XQuery は、XML データを検索するための標準の問い合わせ言語で、RDBのSQLに相当する。XQueryは製品に依存しない言語なので、XQuery対応製品のほうがエンジニアにとって習熟のハードルが低くなるほか、技術者の獲得自体も容易になる。
スキーマは必須か
XML はスキーマを使って構造を定義できるが、必ずしもスキーマを必要としないという特徴がある。スキーマのおかげで、XMLのタグの意味をコンピュータに伝え、自動処理を効率的に行なうことができる一方、常にスキーマが必要になると、XMLが持つ構造の柔軟さや扱いの手軽さを活かせなくなってしまう。そこで「ウェルフォームド（整形式）XML」と呼ばれるスキーマを持たない形式での使い方も許されている。
XML-DB を使うときに、このスキーマ定義が必須かどうかは重要なポイントだ。RDB の場合、スキーマなしに使うことは考えられないが、XML データはそれ自体が構造を持つので、スキーマがなくても処 理することができる。手軽にXML データを格納して使いたい場合は、ウェルフォームドXML対応製品のほうが良いだろう。
インデックス設定は制御できるか
XML-DB は、高速検索を実現するためにインデックス機能を備えている。インデックスを使えば、検索条件として指定された要素に素早くアクセスできる。一方で、データが変更されるとインデックスを作り直す必要があるので、更新処理が遅くなるという欠点がある。うまくインデックスを設定すれば、検索性能と更新性能とのバランスをとることができるが、そのためには対象となる製品についての深い知識が必要になる。
ネイティブ型の製品の多くは、DB 管理者の頭を悩ませることなく常に高速で安定した検索を可能にするために、全自動でインデックスを設定する機能が実装されている。ハイブリッド型の製品では、DB 管理者がインデックスを設定するのが基本だ。どちらが良いかは一概には言えないので、更新と参照のバランスを考えて決める必要がある。
今後の動向を見定めるポイント
では、XML-DBはこれからの企業内システムをどのように変えていくのだろうか。
XMLの柔軟性を活かしたシステム開発
XML は定型なデータも非定型なデータも表現できるのだが、XML-DB はどんな形のXML データに対してもRDB より効率的に扱えるわけではない。発注書や申請書など構造が完全に定まった文書をXML化すると定型的なXML 文書となるが、これらのデータ構造はスキーマで固定的に表現できるので、RDB でも十分扱える。反対に、ワープロで自由に書いた報告書、プレゼン資料、WebページなどをXML化すると非定型なXML 文書になるが、これらを単にキーワード検索したいだけであれば、「Google アプライアンス」のような文書検索ソリューションで十分だろう。
何らかの構造を持ってはいるが、それが文書全体で完全に固定されているわけではない、半定型の文書を扱う処理こそ、XML-DBを最も効果的に使える場面である（図10）。半定型文書の具体例としては、カタログなどの商品情報、提案書などの営業資料、電子カルテなどの医療にかかわる情報、設計書など製品開発に伴う資料などがある。これらは文書構造に高い自由度が必要ではあるが、共通の構造を利用した処理も求められる。
例えば、「携帯電話など新しい機能が次々に増える製品をさまざまな角度で比較検討できる電子カタログ」や、「販売した顧客や製品構成について類似する提案を見つけることのできる営業支援システム」など、必要な部分を構造化したXML データとして扱うことによって可能になるシステムやサービスは多い。このようにデータを柔軟に扱うことのできるシステムのDB は、XML-DB以外では難しいだろう。
図10 半定型文書の処理に適したXML-DB
オフィス文書の標準化の本当の意味
ODFのようなオフィス文書の標準化も、XML-DB にかかわる大きな動きである。しかし、「それはマイクロソフトOfficeの互換ソフトが増える程度の話で、文書のフォーマットなんか、エンドユーザーには関係ない」と考えている人はいないだろうか。それは大きな間違いだ。オフィス文書の標準化は、業務支援をするシステムのあり方自体を抜本的に変えるほどのインパクトがある。
皆さんはオフィススイートを使っているときに、「今、この機能だけ使えたらいいのに」と思ったことはないだろうか。例えば、Word文書の表の中でExcel シートのように計算をしてほしいとか、Excelシートの変更を修正履歴で管理してもらえれば......といった具合だ。フォーマットがオープンなものになれば、外部プログラムが簡単に作れるので、本体を軽くしておき、普段使わない機能はプラグインとして使うようなシステムの構成をとることが可能になる。
さらに、XML-DBを使えば多数のドキュメントをまとめて扱うことが可能になる（図11）。複数のWordやExcelの文書を組み合わせた文書を自動生成し、それを編集したり、数値データを含む部分だけ取り出して分析したりするなど、さまざまな応用が考えられる。文書フォーマットのXML化だけでこれらのことがすぐに実現されるわけではないが、XML ベースの標準フォーマットの採用によって、これまでには考えられなかったような業務支援システムの可能性が広がるのだ。そのとき、XML-DBがそのシステムの中核を担っていることは間違いない。
図11 標準化で広がるオフィス文書処理の可能性
本パートではXML という視点から、特にエンタープライズ領域でのシステムの変化を展望した。XMLフォーマットは多様な目的のために、さまざまな領域での利用が広がっている。このことが、XML の持つ"つなぐ"能力をより効果的に発揮する機会を作っている。
2007年にどこまで変化が進むかは分からないが、さらにその広がりが大きくなっていることだけは確かである。