XMLフロンティア探訪
第3回 Relaxer：XMLがJava開発を変える

Relaxerとは、XMLで定義したデータ構造をそのままJavaで扱えるクラスを生成してくれるツールだ。Javaから簡単にXMLを操作できるようになる。このRelaxerの新機能としてjdbcオプションが付加された。これを利用すると、XML、Java、SQLの3つが非常にシームレスに扱える。いままで誰も経験しなかった、新しいプログラム開発スタイルが登場しようとしている。（編集局）

川俣 晶
Advanced IT School 学長
2001/7/31

今回の主な内容
XMLからJavaを生成するツール
なぜXMLを扱うJavaプログラムがすっきりしないか
jdbcオプションのインパクト
XMLとJavaとSQLのかけ橋
普通の開発工程でも利用価値は高い
変わるプログラム開発スタイル
21世紀はデータ定義という工程が独立する

■XMLからJavaを生成するツール

　今回のテーマとして取り上げる「Relaxer」は、幾つもの意味できわめて興味深いプログラムだ。理論的な側面での面白さと同時に、開発の現場でも便利に使えるツールである。XMLの新しいスキーマ言語であるRELAXを強力に活用するツールであると同時に、Javaの開発スタイルをパワーアップさせるという側面も持つ。1つのカテゴリには収まりきらない、ともいえる。

　Relaxerをひと言で表現すると、RELAXのスキーマ定義を読み込んで、そのスキーマに適合するXML文書を扱うJavaプログラムのスケルトンを生成するツールである。XML文書を扱うにはSAXやDOMという標準APIがあるが、構造が極めてXML寄りであるため、XMLの要素を1つ扱うときにJavaの変数を扱うように簡単には記述できず、いちいち要素の内容を取得する回りくどいコードを記述しなければならない。しかし、Relaxerを使うと、XML文書の構造に相当するJavaのクラスが定義され、要素の内容はメンバー変数として参照可能になる。その結果、XML文書を扱うJavaプログラムの開発期間が短くなり、ソースコードの分かりやすさが向上する。

作者の浅海氏自身が主催するRelaxerのWebサイト。ダウンロードはもちろん、関連ドキュメントなどが読める

　しかも、作者の浅海智晴さんは、Relaxerのソースコードを公開したうえで、無料で使えるようにしてくれている。ライセンス上、若干の義務は発生するが、ほとんどのソフトでは問題にならないだろう。XMLを扱うJavaプログラマーならすぐに試してみよう。

　さて、ここで疑問を感じる人もいるだろう。そんな都合の良いことが起こるのだろうか？ Relaxerを使うだけで、開発期間が短くなったり、ソースコードが見やすくなったりするなどという都合の良いことは、そう簡単に起こるのだろうか？ 結論からいえば、これは実際に起こっている事実である。なぜRelaxerが、それほど素晴らしい成果を出せるのかを理解するには、その裏返しとして、なぜXMLを扱うJavaプログラムがすっきり記述できないか、その理由を知る必要がある。

■なぜXMLを扱うJavaプログラムがすっきりしないか

　XMLはテキストベースのマークアップ言語の一種である。すべての情報は文字を基準に考え、全体の構造はツリー構造になる。それに対して、Javaはオブジェクト指向言語であるためクラスを基本に考え、整数型や実数型も言語仕様に含まれる。もちろん、Javaは汎用プログラム言語なので、これだけの差があっても、XML文書を処理するプログラムを記述することはできる。しかし、Java固有のクラスや整数型などを扱うのに比べれば、プログラミングが回りくどくなるのはやむを得ない。これを解決するには、XML文書の内容を、Javaのオブジェクトに変換してしまえばよい。だが、変換機能をいちいちプログラマが記述すると、かえって余計な手間が発生してしまう。

　では、変換機能を自動生成するというアイデアはどうか。これはそのままでは実現できない。なぜなら、XMLにはJavaのデータ型に相当する情報が定義されていないからだ。つまり、ある要素の内容が整数型なのか文字列型なのかを指定する機能が、いままでのXML文書の型定義に使われていたDTDには含まれていない、ということである。

　そこでXMLのスキーマ言語という存在の重要性が浮上する。RELAXやXML SchemaなどのXMLのスキーマ言語には、強力なデータ型の指定機能が存在する。これらのデータ型の中には、そのままJavaに対応させることができるものも多い。つまり、XMLのスキーマ言語としてRELAXが登場したことにより、構造が整合しなかったXMLとJavaの間を取り持つ変換機能の自動生成が可能になったわけである。

　つまり、Relaxerを実現させるにはXMLのスキーマ言語の存在が不可欠であり、それ以前は作ろうとしても作ることができなかった。RELAXの応用ソフト第1号とでもいうべきRelaxerが、初めてその機能を実現したことは、ある意味で必然的な成り行きといえる。

　さてRelaxerは非常に画期的なソフトなのだが、ここまで説明してきたことは、今回のテーマにとっては前座にすぎない。今回はその先の話題を取り上げたいのである。

■jdbcオプションのインパクト

　Relaxerの0.14βより追加された新機能として、jdbcオプションというものがある。jdbcとはJavaのデータベースアクセス用のAPIであるJDBCのことを意味する。つまり、このオプションを使用することで、JDBCを用いたデータベースへのインターフェイスが自動的に生成できる。

　こう書くと、なんのこっちゃ？ と思う人も多いと思う。XMLとJavaを結び付けるRelaxerがデータベースに対応するというのは、どういうことなのだろうか？

　Relaxerのjdbcオプションは、RELAXのスキーマ定義からJavaのクラスを生成するように、RELAXのスキーマ定義からSQL文を生成する。より正確には、SQL文を含むJavaソースコードを生成する。これにより、短いJavaプログラムを書き足すだけで、XML文書をデータベースに格納し、格納したデータをSQLを用いて検索することができる。もちろんRelaxerだから、XML文書とJavaオブジェクト、データベースとJavaオブジェクトの間でやりとりするコードも生成できる。

　つまり、通信回線を通して送る場合はXML文書、内部処理はJavaのオブジェクト、保存や検索はデータベースという、現在考えられる理想的なバランスのシステム構築の基盤部分を、Relaxerのjdbcオプションは自動生成してくれるというわけである。

　具体的にいえば、例えば価格を表現するために、XML文書として<price>9800</price>と表現し、Javaクラス内では、int price;とし、データベース内には整数値として、CREATE TABLE 〜 ("price" INTEGER) 〜 のように生成される。これらの定義はすべて、たった1個のRELAXスキーマの<elementRule role="price" type="integer"/>といった記述から生成されるので、単純に手間が減るというだけでなく、自動的に整合する内容が生成される。担当者によって、整数か実数かで解釈が違うということも起きない。まさに夢のような機能だ。

■XMLとJavaとSQLのかけ橋

　jdbcオプションはまだ生まれたばかりなので、多くの現場の修羅場を体験しなければ、実用性についての結論は出せないだろう。だが、これがうまく機能するなら、ソフトウェア開発の革命だ。コストの低減、開発期間の短縮、さらには信頼性の向上も期待できるだろう。

　ここで、Relaxer付属のjdbcオプションサンプルソースを紹介しよう。まず下記は、RELAXのデータ定義の抜粋である。

　<elementRule label="record">
　  <tag/>
　  <sequence>
　    <element name="id" type="token" sql:primary="true"/>
　    <element name="name" type="string" sql:unique="true"/>
　    <element name="phone" type="token" sql:notNull="false"/>
　    <element name="balance" type="int"/>
　  </sequence>
　</elementRule> 
RELAXで、XML文書の構造を定義する

　そして下記が、上記の定義から生成されたJavaソースコードの中から、テーブルを作成するメソッドcreateTableの部分を抜粋したものだ。このメソッドは完全にRelaxerが作り出したもので、だれか人間のプログラマーが書いたものではない。

　/**
　* Create a table.
　*
　* @exception SQLException
　*/
　public void createTable() throws SQLException {
　  Statement st = conn_.createStatement();
　  st.execute(
　    "CREATE TABLE \"" + tableName_ + "\" (\"id\" VARCHAR(32) PRIMARY KEY,\"name\" VARCHAR(128) UNIQUE,\"phone\" VARCHAR(32) NOT NULL,\"balance\" INTEGER NOT NULL)"
　  );
　}
Relaxerのjdbcオプションを利用すると、RELAXで定義されたデータ構造に沿ったSQL文が生成される

■普通の開発工程でも利用価値は高い

　ここで少しだけ話を本筋から外そう。あるエピソードを紹介したいと思う。

　私の知人に、Javaの魅力に取りつかれて、エリートコースを蹴ってJavaの道に進んだ男がいる。ある日彼がこういったのである。「Relaxerはすごい！」と。彼が開発を請け負っていたのは、よくあるWebベースのシステムであるらしい。Javaを使ってサーバ側で処理するシステムだが、別にXMLを使わねばならない必然性はまったくないものだ。それでもRelaxerを利用することによって、開発がぐっと楽になったという。

　つまり、システムが保存する各種データを扱う部分を、Relaxerを使って開発したところ、短期間で高度なものがで出来上がったというのだ。もちろん、データの保存ファイルは、XML文書として保存されるのだが、それはシステムの要件ではない。だれかからXMLを使えと要求されたわけでもない。知人が個人的にXMLを使ってみたかった、というのが理由といえば理由だろう。しかしこの場合、XMLにしなければならない必然性がないシステムであっても、XMLを採用してRelaxerを導入することで、明らかにソフトウェア開発は楽になったのだ。しかも、XML文書であればXML宣言でencodigを明示することで、どんなエンコーディングでも読み取らせることができる。そのため、このシステムは管理運用も楽になったという。

　この話から読み取れることは何だろうか。それは、XMLとRelaxerの位置付けとして、XMLシステムの開発を容易にするためのものであることが分かった、というだけでは、いま見た可能性のすべてを語ったことにならない。実は、XMLとは関係ないシステム開発でも、Relaxerの導入はシステム開発を容易にする効力が生まれるのである。運用上、別にXMLでやらなくてよいものであっても、XMLにすると決めればRelaxerを使うことができ、システム開発が楽になる。

　実際に、このような、XMLに関係ないRelaxerユーザーという層が生まれつつあるのは歴然とした事実といってよいだろう。彼らにとって、XMLは空気や水のように、自然に存在するものであり、いちいちXMLを採用するかどうかを吟味したりはしないだろう。それはRelaxerを採用することによって、自動的に付いてくるものなのである。

■変わるプログラム開発スタイル

　Relaxerのjdbcオプションの存在は、このような「XMLに関係ないRelaxerユーザー」を大幅に拡大するだろう。なぜなら、データベースは、現在の業務用システムの中核に位置する主要ソフトの1つでありながら、通常のプログラム言語との相性が必ずしも良くなかったからだ。例えば、データベース上にテーブルを1つ作るにしても、データベース側のスキーマと、プログラム言語側のデータ定義を別々に書かされることも多かった。

　しかし、Relaxerのjdbcオプションを用いれば、RELAXスキーマで書いた<elementRule role="cost" type="integer"/>といった記述から、データベースを扱う基本的なコードはすべて生成され、データベースの内容を扱う場合でも、Javaのオブジェクト内にレコードの内容を呼び出して、int型の変数としてアクセスすることができる。つまり、jdbcオプションは、XMLとは関係なく、SQLとJavaのギャップを埋めてくれる。これにより、SQLが埋め込まれた分かりにくいJavaソースとオサラバして、Javaらしいソースコードでデータベースを扱うことが可能となる。もちろん、Relaxerだから、XML文書も扱えるのはいうまでもない。

　RelaxerがXMLとJavaを結び付けたことが革命なら、これは、プログラム開発の大革命だ。パラダイムシフトといってもよい。

　では逆に考えてみよう。これだけの成果を出せるRelaxerの本質とはいったい何だろうか。Relaxerが扱うのは、データではない。かといってプログラムでもない。プログラムの一部を生成してくれるが、プログラムで利用できるパーツや定義を生成するのであって、決してプログラム全体を作るツールとはいえない。強いていうなら、Relaxerが扱うのは、「データの定義」だ。つまり、RELAXスキーマが記述するものが、まさに「データの定義」であり、RELAXスキーマをJavaやSQLに変換するものがRelaxerだということができる。

■21世紀はデータ定義という工程が独立する

　どうして、データの定義を変換するというアイデアがこれまで使われてこなかったのだろうか。その理由は分からない。ただ1ついえることは、これまでデータの定義はプログラム言語やデータベース言語の一部として定義されていて、純粋なデータの定義だけを行う言語はなかったということである。そのため、変換するといっても、全体を変換することは考えられても、データ構造だけを扱うことを考えることはあまりなかったのではないだろうか。

　しかし、XMLの時代が到来するのと同時に、XMLとは独立した「XML用スキーマ言語」というカテゴリが生まれた。その背景には、XMLではデータ定義を含まない整形式という新しい表現スタイルがある。このスタイルを活用するには、スキーマ言語はXMLから独立し、純粋にデータ構造だけを定義する存在に特化しなければならなかった。だが、その特徴は、XMLのスキーマ言語をXML以外のために使うという新しい世界を切り開いたのである。

　ここまできてしまった以上後戻りはできない。もう、データの定義は、プログラミングやデータベース設計の1つの工程という時代は終わる。データの定義は、データの定義という独立した工程になるだろう。そして、データの定義が記述できれば、そこから、プログラム言語やデータベースで使用する定義を自動的に生成することができるのである。もちろん、このような手法が、従来型の開発手法よりも、より短期間で信頼性があることはいうまでもない。われわれは、20世紀的な開発スタイルとは一線を画した21世紀的な開発スタイルの世界に足を踏み入れようとしているのかもしれない。

「連載 XMLフロンティア探訪」


XML & SOA フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

HTML5＋UX 記事ランキング

本日月間
＠IT