［XMLとオブジェクト指向］
前回は、前置きとしてXMLとオブジェクト指向がどこか関係しそうだという話をしました。ただ、トピックをいくつか羅列しただけだったので、リアリティにかけてしまったかもしれません。本格的な連載開始(?)は今回からということで、少しずつですが話を進めていきたいと思います。まずは、さまざまな本や雑誌で紹介しているXML活用事例から、XMLがシステムのどのような場所に使われているのかを見た上で、オブジェクト指向技術が適用できそうなポイントを考えてみます。
XMLシステム
XMLを適用したシステムとして第一に浮かぶのはEC/EDI、インターネットというキーワードでしょうか。WWWベースのシステムでHTTPプロトコルの上にHTMLだけではなく、XMLものせてデータのやり取りを行うというのが典型的な形態です。ここでは、XMLは２つの役割を担っています。ひとつはEDIというとおり、交換されるデータの表現形式として、もうひとつは、プレゼンテーションの基本となるデータとしての役割です。後者もサーバー側とクライアント(WWWブラウザ)との間で交換されるデータという観点では同等ですが、現在XMLが脚光を浴びている理由としてWWWとの関係は無視できないと思われるので、挙げておきます。前回も書きましたが、この原稿もXMLで記述しています。（最終的に公開するときは、さまざまなブラウザを想定しなければならないので、HTML化しています。XML版はこちらからアクセスできます。ただし、IE5.0が必要です。）
WWWブラウザや外部システムへXMLデータを渡すためには、WWWサーバー側のシステムでもXMLを取り扱う必要があります。まず、XMLドキュメントを入力、編集するためにはエディタが必要になるでしょう。すでに有償無償の多数のXMLエディタが公開されています。入力されたデータは保存しておく必要があります。いちばん簡単なのは、作成したXMLドキュメントをそのままファイルとして保存しておくということでしょう。データ量が増えてきたり、並行アクセスなどを考え始めるとDBMSによる管理も考え始めなければなりません。
入力され、保存されたXMLドキュメントをそのまま外部へ渡すだけであればこれらだけでよいかもしれません。実システムではそのようなことはまれで、さらに実行時に動的にドキュメントを再構成したり、生成したり、検索したりすることになるでしょう。そのためには、XMLドキュメントを扱うためのAPI（SAXやDOM）が必要になります。外部システムとやりとりするためにもこれらのAPIを使用する必要があります。たとえば、WWWサーバー側には独自のデータフォーマットを扱う既存システムがあるとすれば、そことのやりとりを行うために、データをXMLに変換するということもあるでしょう。すでにDBに格納されているデータを扱いたいという場合は、DBからデータを読み出してXML化するしくみも必要になります。異なるDTDを使用しているようなシステム間でデータ交換を行おうとすれば、それぞれに変換するためのしくみも必要です。
すでに多数のXML活用事例が報告されていますが、その多くはこれらいくつかのポイントで説明できそうです。たとえば、あるニュース配信ページでは、記事はすべてXMLで記述されデータベースで管理されています。これにより、記事の加工、検索を容易にできます。配信の際には、XML対応していないブラウザのため、XMLからHTMLへ変換処理をおこないます。ここには、入力、保存、データ変換処理が含まれています。
別のあるWWWサイトでは、さまざまなデータソースから集めたデータをXMLで一元管理し、カスタマのニーズに合った情報だけを配信する仕組みを提供しています。元データとなるデータソースには既存のデータベース、外部のWWWページなどがあり、そこからXMLとしてデータを取り出す仕組みが必要になります。カスタマの属性、要求から収集されたデータに対して検索処理が行われ、検索にマッチしたXMLドキュメント（やその部分）が新しいXMLドキュメントとして再構成され、配信されます。ここでは、外部リソースからのXMLドキュメント生成、XMLに対する検索、変換処理が含まれています。いわゆるCRMを実現するための一手段としての利用法といことでしょうか。
これらをまとめるとXMLのシステムにおける適用ポイントは次のようになります。
オブジェクト指向の適用ポイント
それでは、上にあげた適用ポイントのうち、オブジェクト指向が有効に適用できそうな場所を考えてみましょう。これが、XMLとオブジェクト指向技術の接点ということになるかもしれません。
プレゼンテーションの基礎としてのXMLという観点は、XMLを次世代のHTMLとみなす考え方と通じるもので、ブラウザ開発者以外の、大多数のオブジェクト指向技術者には無関係のところでしょう。WebクライアントにアプレットやVBScriptなどを組み込むのであれば、多少関係するかもしれませんが、それはXMLを処理対象データとみなすこととほぼ等しくなります。
データ交換フォーマットとしてのXML。ここは関係してきそうです。従来システム間のデータ交換といえば、必要最小限のデータをできるだけ小さなストリームとして、比較的低レベルなプロトコルでやりとりするというイメージだったかもしれません。このようなフラットなストリームでは構造を持つデータを送るのもそう簡単ではありません。XMLを使用するということになれば、構造を持ったデータを容易にやり取りすることができます。構造をもったデータをオブジェクトはオブジェクトであるとみなすことができます。
格納保存フォーマットとしてのXMLという観点でも、やはりオブジェクト指向が関わります。XMLをRDBで格納することも不可能ではありませんが、構造をもったデータの格納といえば、オブジェクト指向データベース(ODB)の出番となるでしょう。とくに、XMLではリンクを非常に柔軟に定義できます。これはオブジェクト間の関連とみなすこともできますが、やはりODBの得意とするところでしょう。一般に関連をRDBで表現しようとすると、外部キーを使用して複数テーブル間の参照を表現することになりますが、これに対する検索は結合(join)処理となり、大きなコストがかかります。
処理対象としてのデータ（変換、計算、検索）。ここにはいくつかの見方ができると思います。XMLをデータ構造と捉えた場合、基本になるのはDOMのツリー構造でしょう。ツリー構造を扱うためのアルゴリズムは、当たり前ですが、オブジェクト指向の専売特許ではありません。つまり、オブジェクト指向を持ち込まなくてもXMLを処理することは可能です。しかし、それでは、いったいどうやってプログラミングするのかを考えた場合、ここが「オブジェクトの広場」だから、というわけではありませんが、結局オブジェクト指向を持ち込むことになるでしょう。この中には多くはJavaでかかれているSAX, DOMパーサーを利用することも含まれます。
既存システムとのインタフェースとしてのXMLは、データ交換フォーマットとしてのXMLという観点と似ています。既存システムが内部（たとえば社内）ネットワーク上のレガシーシステムであれば、そこで扱われるデータをXML化するラッパが必要という話かもしれません。インタフェースをとる相手がCORBAなどの分散オブジェクトの場合はどうでしょうか？これはインタフェースをCORBAでとるのか、XMLでとるのか、それをさらに統合するのかで、問題は複雑そうです。ただ、CORBAもXMLも分散アプリケーション開発には無視できない要素ですから、これはいまのところペンディングということにして、どこかの段階で再検討をしたいと思います。
最後に 次回予告
オブジェクト指向とXMLの接点が少しは明らかになってきたでしょうか？次回からは、今月あげたXMLとオブジェクト指向技術の接点について、さらに考えを進めていきたいと考えています。
| © 1999 OGIS-RI Co., Ltd. |
|
