Web屋のネタ帳

要するに「Java内部でのデータの持ち回り方法」としてのJAXBにちょっと期待してみたいという話であって、タイトルは単なる思いつきである。

むかーし、Strutsに触っていてアクションフォームBeansの存在意義に疑問を感じたことがある。

public final class HogehogeForm extends ActionForm {
  private String name;
  public void setName(String name) {this.name=name;}
  public String getName() {return name;}
}

こんな感じのやつをいちいち手で書かなければならないこと＆アクションフォームにはロジックを埋め込んではいけないということが腹立たしかった。まあそのほうがセキュリティ上も良いとかいろいろ理由はあるのだが、それにしても納得いかない感はあった。なんか、めんどくさいやん。

DynaActionFormと呼ばれるものが使えるようになった頃にはこの手間は少し軽減されたらしい。 そもそもEclipseなどの開発ツールによる、Javaクラス内のプロパティに対するsetter/getterメソッドを自動生成してくれるような補完機能もめずらしくなくなってきたこともあり、単調なコードをゴリゴリ書く作業もちょっとは減った。

しかし、しばらくたつと今度はO/Rマッピングツールも組み合わせてどうのこうのというのが流行（？）になり、struts-config.xmlのややこしさにもまだ慣れきってないうちからさらにhibernate-mappingのXMLだとかを書けだのそれ用の永続化クラスを書けだのそれってStrutsのアクションフォームとどう違うのよ？兼用できないの？え？無理ぽい？そうですか（涙）。みたいな感じで冗長なコーディング作業がさらに増えそうにしか感じなかった。

他のフレームワークに浮気しようかとか思っても、たとえばSeaser系列のO/RマッピングツールであるところのS2DAOなんかでも、DTOと呼ばれる、プロパティとそのsetter/getterだけを備えた単純なコードをいっぱい作らなければならず、使ってる方法/技術の名前が変わっただけで本質的にあまり変わってないようにしか見えなかった。いやまあ、JavaBeansってそういうもんだからしょうがないんじゃんと言ってしまえばそれまでだが。

しばらくJavaフレームワークの話から遠ざかっていたら、最近、WEB+DB PRESS Vol.38に、コードジェネレータを作ろうとかアクションフォームとDTOの詰め替え処理が面倒だとかいう記事が載っていて、やっぱりそういう話になるよなあなんて思ってた。

そうこうしている間に、まったく別な方面で、「HTMLじゃなくてXMLで情報を出すのになんかいい方法ないかな？ほら、最近流行のWeb-APIってやつでさ」みたいな話からJAXBに行き当たった。 JAXBとは、XMLデータを入出力するためのコードをJavaで書く際のコードジェネレータみたいなものである。

ためしにと思って、アマゾンの商品データのXML定義ファイル（XSD形式）を、JAXBが提供するxjcコンパイラなるものに食わせてみたら、getProductname()/setProductname()のようにXMLのタグと属性のひとつひとつに対するsetter/getterメソッドを含むすべてのソースコードを自動生成してくれたではないか！！それを画面上で見た瞬間に、 Javaアプリ内でのデータ層/AP層/プレゼン層の3層間での情報のうまいやりとり方法に悩んでいたことを思い出した。

もしかして、お前じゃないか？JAXB！？

なにしろXMLだ。strutsとかseaserとか将来的にどう転ぶかわからないようなフレームワーク技術に依存した技術ではない。strutsとXMLを比べてどうのこうのというのも変な話だが、実感として標準により近い技術のほうが安心感があるに決まってる。

PCのブラウザ向けにHTML出力するのは当然のこと、携帯向けもよろしくねもちろん3キャリア対応でねとか、PDF形式の帳票出せるようにしたいからよろしくとか、最近流行のWeb-APIでXML形式もお願いね、とかなんだとか、とにかくプレゼン層でやりたいことは増える一方だ。

だからこそ、情報はとりあえずXML出力で統一するから、、XSLTでHTMLに変換するなり、PDF出力はXSL-FOするなり、Web-APIぽく提供したければそのままXMLで出すなりJSONに変換するなり、とにかくデザインの手段は好きなようにしてね、みたいな流れになるのは必然じゃないだろうか。

だとすれば、XMLの定義ファイル＝XSD＝は当然つくらざるを得ないしその作業に抵抗はない。そしてJAXBはその定義ファイルを読んで理解しsetter/getter群を一手に引き受けて書いてくれるという。なんだかすごくしっくりくる。おまけにJava6以降ではJAXBは標準技術扱い（って言うのかしらんが）だと言う。こうなってくると、少なくともAP層とプレゼン層の情報のやりとりの技術はJAXB（とXML）で決まりとすら思えてくる（というのはオーバーかな）。

とか考えていたら、hyperjaxb2なるプロジェクトを見つけた。やはり筆者程度で思いつくアイデアならとうの昔に思いついて具体化に着手している先人はいるものだ。つまりAP層にあるJAXBオブジェクトとDB層とを直接マッピングしようというhybernateの拡張（？）の技術らしい。この流れもまた必然に感じる。

しかし、さらに掘り下げると、【レポート】Java SE 7の「プロパティ」が見えてきた - setter/getterのないJavaへ (1) Java SE 7の新文法「プロパティ」とは(マイコミジャーナルと 2007/5)という記事まで行き当たってしまい、JAXBはもちろんすべては過渡的な技術に過ぎないのかと思うと気が遠くなってきたので酒飲んで寝ることにする。

追記：
ところで、例えば楽天のAPIをはじめ、国内企業のAPIサービスの多くが、そのXSDなりDTDなりの定義ファイルを公開してない。っていうか作ってない/作る意味がわかってないんじゃないかという疑いすらある。ちゃんと作って公開しようよ。 上で書いたようにアマゾンみたいに。こういう技術のための定義ファイルなんだから。