現在、Reflex Resource MapperというXML/JSON⇔JavaBeanのバインディングツールをsourceforge.jpにUpしている。これは、StAXのようなPull型で高速なパーサxppをもつXStreamをベースにしている。XStreamについてはこちらが分かりやすいので参照いただきたい。(超簡単Java Object-XML Mapper "XStream")
JavaとXMLのバインディングツールは別段、めずらしいものではない。すでにXMLBeansやCastorなど有名なものが出揃っており、JAXPのような標準的なAPIもある。これらと何が違うのか。
Resource Mapperで私が最も強調したいのは、「きれいなXMLを扱える」ということだ。
本来、XMLは可読性をもつデータ定義言語として考えられたものだった。だが、自動バインディングツールを介すと、お世辞にも綺麗とはいえないXMLが出来てくる。バインディングツールでは、やみくもに自動化できればいいというものではない。変換後においても可読性を維持しつつ、開発者がモデリングしたときの構造が崩れないように、うまくバインディングする必要がある。
私もCastorを愛用していた一人だったが、出力されたXMLに冗長な部分が多くなり鼻につくようになったので、自分でバインディングツールを作ろうと決心した。そのバインディングツールでは、XMLのスキーマ定義から連想されるJavaBeanを作成するだけで、スキーマ定義に合ったXMLを扱えるようしたかった。基にしたXStreamには十分といえるシリアライザー/デシリアライザーの機能はない。Castorなどは、目的の形のXMLを得るために、XSDからJavaBeanを自動生成できるが、XStreamでは手で作成したJavaBeanの構造からXMLを作ることしかできない。とても不便であったXStreamを、Reflexは規約に則ってJavaBeanを作成することで、自由に目的のXMLが得られるようにした。いわゆるCoC(Convention Over Configuration)という考え方で、XMLスキーマからJavaBeanを連想しながら作成することができるようにした。
(Reflexにおいても、Reflex表現という簡易的なスキーマ言語を作成することで自動的にJavaBeanを生成できる。さらに、Reflex表現の作成は、Reflex Entity Editorを用いることで、グラフを見ながら直感的に作成していける。詳細はこちらを参照いただきたい=>Reflex Entity Editor)
サンプルを見ていただくと分かるが、このModelBeanはいくつかのBeanをList構造に定義して階層を表現しており、図に示すXML構造とJavaBeanとで同じ構造をしている。XSDは特に必要なく、JavaBeanの構造だけで、あらゆるXMLを表現できる。例えば、既存のXMLスキーマはもちろん、RSSやATOMなどのフィード、さらにSOAP通信であっても可能である。
ところで、先日、AXISとの通信テストを実際にやってみた。うまく通信させることができたのだが、HTTPヘッダにSOAPAction : ""を追加する必要があった。SOAPAction なる残骸を考慮しないと通信できないとは・・イタイ話である。
また、小さく軽い(ライトウェイトである)ことも特長の一つである。jarファイルはxpp(100k)とXstream(241k)とReflex(27k)の3つでサイズはなんと350kbytes。たったこれだけで、Xerces、Castor、あるいはAXISのバインディング機能を実現できてしまうのだ。CastorやXMLBeanを使ってきて、今まで何やってたんだろうと思う。それから、XMLのJavaコーディングでありながら、Xercesにクラスパスを通さないのは実に気分がいいものである。
0 件のコメント:
コメントを投稿