ObjectSquare

[新・XMLとオブジェクト指向]


新・XMLとオブジェクト指向

連載第3回

XMLの扱い

舟守淳

(Funamori_Jun@ogis-ri.co.jp)


1. はじめに

 前回、前々回とXMLデータのリポジトリに関する話題でした。どう永続化するか、どう検索するかという話題でした。アプリケーションの階層でいえば、最下位層の話です。

 今回は視野を広げて、システム全体をとおしてのXMLデータの動きを考えてみます。その中でXMLデータとオブジェクト指向の関係について整理してみたいと思います。

 なお、原稿は今回もXMLで記述しています。ブラウザにIE5.0+MSXML3をお使いの方は、こちらでもご覧いただけます。

注) MSXML3は次の方法でインストールできます。 まず、こちらのMicrosoftサイトの、コンテンツリストから"XML Parser Beta Release, September 2000"を選択して、msxmlwr.exeをダウンロードしてください。 また、コンテンツリスト”Xmlinst.exe Installer Tool” からxmlinst.exeもダウンロードしてください。次に、ダウンロードしたmsxmlwr.exeを展開しmsxmlをインストールし、終了したらxmlinst.exeを展開し、ReadMeのとおりにmsxml3をインストールしてください。

2. XMLのカタチ

 単純にXMLデータといってもその視点によって適用方法が異なってきます。したがって、XMLをシステムに適用する際は、どこに、なぜXMLを利用するのか明確にしておく必要があります。

 まず、一般的なXMLの使いどころを考えてみましょう。

2.1. ブラウザ表示などのプレゼンテーションに利用する

 これは、データとしての意味合いよりも文章・コンテンツとしての意味を持つXMLデータです。動的にXMLデータを作成する過程においては、ビジネスオブジェクトとして存在はしているでしょうが、出来上がった(アウトプット)コンテンツとしてのXMLおよび、その変換ルールであるXSLは、いわゆるオブジェクトとは切り離して考えていいでしょう。

2.2. 外部アプリケーションなどのインターフェイスとして利用する

 かなり抽象的に書きましたが、具体的に言えば、異なるアプリケーションの統合や、BtoBでの交換データとしての利用、プロトコルそのものをXMLで記述するといった利用になります。

 この分野は、今最も注目されているところで、実際にXMLを取り巻く仕様の多くは、XMLでのデータ交換・プロトコル通信を目的として策定されています。

 これらの標準化はそれぞれの目的に合わせてXMLで会話するために、スキーマを定義して、共通の場ではそのスキーマに基づいたXMLインスタンスによる意思の疎通を行おうというものです。

 具体的な例として、最近IBMなどで発表されたWebサービスという概念があります。これは非常に面白いもので、各サイトで公開されている様々なサービスを特定のリポジトリに登録しておき、サービス要求者からの要求に対して仲介者がサービス提供者を仲介するという非常に規模の大きなサービスモデルを提供しています。ここで、使われるプロトコルなどはXMLで記述され、各サイト間ではXMLベースのプロトコルのみが行き来する世界となります。各サービスを提供する側も享受する側も規定のスキーマに沿ったXMLインスタンスを利用するだけで、あらゆるサービスを環境に依存することなく統合利用することができます。

 このようなインターフェイスとしてやり取りされるXMLを考えた場合も、各サイト(各アプリケーション)がいわばコンポーネントと化し、つなぎとしてXMLをプロトコルとして捉えるため、利用するXMLデータをオブジェクトとして意識する必要はないのでしょう。

2.3. アプリケーションの内部データとして利用する

 やはり、XMLデータとオブジェクト指向の関係を意識するのはここでしょう。

 XMLのデフォルトの文字エンコードがUnicodeであること、その利用がインターネット環境も想定していること、XMLのAPIであるDOMがJavaで多く実装されていることなどから、XMLとJavaは相性がよいといわれています。そのため、XMLを扱うツールはJavaによる実装が多く、そのため必然的にオブジェクト指向開発に結び付けることができます。

 しかし、アプリケーションはOOで分析・設計するとしても、そのデータであるXMLはどのようにOO開発に組み込まれるのでしょうか。UMLによってアプリケーションの分析・設計モデリングを行っていくわけですが、XMLデータの分析・設計モデリング、つまりスキーマ設計はどのように行うのでしょう。

 RelaxerのようにRelaxで記述されたXMLのスキーマを解釈して、それに対応するクラスを生成してくれるものもあります。このようなツールであれば、UMLのモデルの中でシームレスにXMLデータをクラスとして記述できそうです。でもこの場合、前提条件にXMLのスキーマが確定している必要があります。UMLによるモデリングからXMLスキーマを設計してはいないのです。どうしてもXMLのスキーマ在りきになってしまうのです。

 実際にXMLをデータとして利用する場合、スキーマは重要な要素になってくるのではないでしょうか。ブラウザ表示などであればWell-Formedでいいのでしょうが、アプリケーション中でのデータとしてはそうはいきません。どこにどのデータが記述されているのか明確になっていなければデータの処理のしようがありませんし、データ作成、読み込み時にデータの検証を行うことは非常に有用なことです。

 例えば、データとしてXMLインスタンスが使われるアプリケーションでWell-formedを用いた場合、外部入力や内部構築されたデータがシステム要求を満たすシンタックスである保証がありません。このため、不正なシンタックスのXMLデータがシステム内を流れる可能性があり、ランタイムエラーがデータのシンタックスとセマンティクスの2つの要因により起こりえます。これはシステム品質の低下を招き、またエラー解析の障害にもなります。したがって、システム内のXMLデータは事前にそのスキーマ定義による、検証を行うことが望ましいといえます。

 ただし、スキーマにXML SchemaやRelaxなどXMLベースのスキーマ定義を使用して、スキーマレベルでの拡張性も高めることによって、検証済XMLデータを利用しても柔軟性・拡張性を維持するといった方法もあるのではないでしょうか。

 とにもかくにも、UMLでの分析・設計モデルとXMLのスキーマ設計のマッピングルールを考慮しなければなりません。

3. 方法論はこれから?

 分析・設計時のオブジェクトとXMLデータのシームレスなリンクをどのように行うか非常に難しい問題です。XMLスキーマ設計自体も難しいのですが、それをOO分析・設計と連携させるのも一苦労なのではないでしょうか。今後、多くの経験とともに、その指針がでてくるのではないかと期待しつつ、今回はここまでにしたいと思います。

© 2000 OGIS-RI Co., Ltd.
Prev. Index Next
Prev. Index Next