« システム設計に求められる適性 | トップページ | 経営革新をやれるというシステム屋のうぬぼれ »

2005.05.28

XEADのXは、XMLのX

XML(eXtensible Markup Language)が鳴り物入りで登場してから7年たつが、いまだに筆者には、ちまたで言われるようなXMLの利点がもうひとつピンとこない。とくに「データがその意味とセットで保管されている」とか「データ様式の設計や変更が容易」といった「利点」がわからない。その疑問を説明した後で、XEADにXMLが組み込まれるきっかけになった、あまり意識されない別の利点を示そうと思う。読者がXMLを理解するための参考になればうれしい。

◆データがその「意味」とセットで保管されている?

XMLの特長として最初に紹介されるのが、「データがその意味とセットになって保管されているゆえに、データの検索や交換がしやすい」という点だ。たとえば、次のようなXMLデータがあったとする(ブログページ上でXMLと認識されないようにカッコやスラッシュを全角にしてある)。

<注文>
 <得意先名>サイトウ電器</得意先名>
 <得意先住所>XX市○○12-34△△ビル5F</得意先住所>
 <受注日>20050531</受注日>
 <相手先注文番号>J25443857</相手先注文番号>
 <商品明細>
  <商品名>M320</商品名>
  <数量>10</数量>
  <納期>20050601</納期>
 </商品明細>
 <商品明細>
  <商品名>T120</商品名>
  <数量>5</数量>
  <納期>20050605</納期>
 </商品明細>
</注文>

確かに、”サイトウ電器”というデータが「得意先名」という「意味」とセットになっているように見える。実際、文書全体から「得意先名が”サイトウ電器”であるような注文の一覧」を取り出すこともできるし、このデータを渡すだけで”サイトウ電器”が「得意先名」であることを受信側はただちに理解できる。

しかし、このことを以って「得意先名」を「データの意味」と言ってしまうのは正確ではないような気がする。たとえば、文書の送信側が「得意先名」と呼ぶ項目と同じ「意味」の項目を、受信側でも「得意先名」と呼んでいるとは限らない。「顧客名」とか、「客先名」などと呼んでいるかもしれない。これは「異名同義」の問題だが、「同名異義」の問題もある。たとえば、あるシステムで「納期」と表現されているデータ項目があったとして、これをXMLで受け取って、受け手側の「納期」の項目にマッピングしていたとする。ところが、どうもシステムの動きが変なので調べてみたら、「納期」の意味が、片や「希望納期」で、片や「約束納期」だったなんてことがある。データ交換を伴わなくても、単一文書内でこれらの問題が生じている可能性もある(*1)。

つまり、「得意先名」だの「納期」などというのは「データの意味」ではなく「データのラベル」にすぎない。たかだかデータのラベルをデータといっしょに送っても、異なるシステム間でデータを正しくマッピングできるようになるなんて期待はできない。けっきょくのところ、「意味」はデータの利用者全員にとっての共通なルールとして別途まとめられなければならない。その地道な作業の結果として、規定様式のXMLデータが活躍できるのであって、XMLを導入するだけでルール策定の作業がいきなり楽になるなんて話ではない。

*1.この問題に対処するため、有効な要素名やその位置づけをDTDやRELAXと呼ばれる形式であらかじめ規定しておくことも可能だ。しかしこの規定を厳密にすればするほど、データ様式のダイナミックな変更が可能というXMLのもうひとつの特長が損なわれて、RDBと比較した場合の特長が薄れる。

◆データ様式の設計や変更が容易?

また、XMLではデータ様式に自由度があり、使いながらの様式変更にも強いという説明がされることがある。たとえば上記の注文データについて、その後に客先から「商品M320の色は黒にしておいてください」と要望されたとして、アプリ上から次のように「色」の要素を伴う形(変更後1、または2)に編集することも難なくできてしまう。

(変更前)
<商品名>M320</商品名>
<数量>10</数量>
<納期>20050601</納期>

(変更後1)
<商品名>M320</商品名>
<色>黒</色>
<数量>10</数量>
<納期>20050601</納期>

(変更後2)
<商品>
 <商品ID>M320</商品ID>
 <色>黒</色>
</商品>
<数量>10</数量>
<納期>20050601</納期>

しかし、「これが可能であるゆえにXMLは便利」とも言いがたい。けっきょくのところ、そのデータを処理するすべてのアプリがそのような形式に対応できないのであれば、何の意味もないからだ。たとえば、注文データを処理する出荷指示用アプリが「色」を扱うことを想定していないのであれば、その情報はさっくりと無視されてしまう。

データ様式の変更容易性が「設計容易性」と混同されて説明されることもある。「必要に応じてデータ様式をダイナミックに変更できるので、漸進的にデータ様式を発展させられます」などと語られるが、それは企業システムがどういうものかをわかっている技術者にとっては噴飯モノだ。フリーフォーマットだろうが、XMLだろうが、データを保管したり交換したりする際には、one fact in one place の原則にしたがって事前にレイアウトを決めておかないと遅かれ早かれ悲惨なことになる。少なくとも企業の帳簿組織に載るような情報を扱うためにXMLを使うのなら、データ様式の変更容易性とは無関係に、データの正規化くらいされていないと話にならない。

言い方を換えれば、データモデリングに精通していればXML様式の設計など容易だ。じっさいXEADのコンテンツは複雑だったが1日でXMLの様式を設計できた。RDBMSでの実装を前提にしなくても、データモデリングは有用な技術なのである。

◆「無料の組込みDBMS付きの保管形式」としてのXML

XMLに関する風評についてこのような疑問はあるものの、XMLの技術そのものへの感謝の気持ちについて筆者は人後に落ちない。この気持ちを理解してもらうにはXEADの前身となったモデリングツールのことを語らねばならない。

それは筆者が8年前に、Delphiを使って最初に組んだパソコンのプログラムだった。自分の独特な図法にもとづいて描かれた設計情報を管理するために、仕事で忙殺されながらも1年半の間、毎晩2時間自宅でコツコツとプログラミングして完成させた労作だった。

そのツールは目ざましい活躍をしたものだが、何年も使っているうちに不満がたまっていった。仕様レベルの使いにくさもあったが、いちばんイライラさせられたのが、コンテンツデータの保管形式だった。Delphi付属の無償のRDBMSを使っていたのだが、なにしろ複雑な構造をとっているコンテンツなので、インデックスも合わせると100個近いファイルとして保管される。コンテンツを持ち運ぶときに、1個でもファイルが抜けると動かないのだ(フォルダごと持ち運べばいいだけのことだが、それにしてもイケてない)。それに、データソースをRDBMSに接続する手続きが面倒だったし、たまたま別バージョンのDelphiがインストールされているPCでRDBMSのバージョンが違うから動かないなんて泣くに泣けないこともあった。

後継ツールを開発しようと思い立ったとき、まず意識したのがコンテンツの保管形式の簡素化と、DBMSとバンドルさせる際のわずらわしさからの解放だった。そのような課題を考えた場合、Java+XMLは都合のいい組み合わせだった。結果的に、コンテンツは1個のファイルにまとまった。また、DBMSへの接続のややこしさがなくなったうえにバージョンにも影響されなくなった。これはDBMSがアプリに関数として組み込まれているおかげだ。xerces(ApacheのXMLパーサ)をimportして、

DOMParser parser = new DOMParser();
とやるだけで、XMLデータを処理するためのDBMSが手に入る。(厳密にはDBMSとは呼べないものかもしれないが、少なくともXEADでのDOMの位置づけとしては、そうみなしてかまわない)

いっぽう、RDBをあきらめたことで失ったものもある。まず、データアクセスの手順が複雑になった点だ。特定の要素にアクセスするためには、同じ要素名を持つ要素配列をまず手に入れてから、それらの内容を調べて望みの要素であるかどうかを確認するといった手順を踏まねばならない。しかし、これもアプリ内部で関数化してしまえばすぐに慣れるし、データをメモリに展開するタイプのパーサであるゆえの処理の高速さで十分おつりが来ている。

また、複数ユーザによる利用も断念せざるを得なかった。パーサにトランザクションとかロックのような機構がないためだ。しかし、これもあきらめがつく。シングルユーザでの利用を前提としているおかげで、ツール上でUNDO/REDOができるようになったからだ。この種の設計情報は試行錯誤的に編集されることが多いので、モデリングツールにはUNDO/REDO機能が欠かせない。もし多人数での同時更新を前提にすれば、それを組み込むことはほとんど不可能だ。

というわけで、筆者はXMLを「複雑なデータ形式を扱えて、しかもアプリにライブラリとして組込めるDBMSが無償提供されている保管形式」として大いに活用させてもらっている。もちろん、この使い方が唯一の正解などではない。XMLは各人が置かれた状況に応じて活用方法が見出されてゆく、そのような要素技術なのだと思う。XMLのXは、利用者にとって都合のいい値を受け入れてくれる変数でもある。

|

« システム設計に求められる適性 | トップページ | 経営革新をやれるというシステム屋のうぬぼれ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: XEADのXは、XMLのX:

» 外部設計書 [シアワセシステムズ]
毎月恒例の(と言っても2ヶ月ぶりの参加)名古屋SE研究所へ。 今回は外部設計書がテーマ。丁度先月末まで悪戦苦闘していたのでタイムリーな話題なのでした。 主催のExbridge社サイト上に「技術ノウハウ公...... [続きを読む]

受信: 2006.06.15 06:53

« システム設計に求められる適性 | トップページ | 経営革新をやれるというシステム屋のうぬぼれ »