skip to main |
skip to sidebar
Seasarのメーリングリストを見ていたら次のような記事を見つけた。
Axis2自体に問題があるようなので、
DTOの入れ子の確認は、まだ先になりそうです。
2年前に参加したXMLコンソーシアムのTravelXML接続検証プロジェクトでは、AxisではDTOの入れ子に問題があったので、わざわざCastorを使って、Axis＋Castorという組み合わせでやった。あのときはWSDL2Javaを使っても、複雑なDTOの入れ子を作成できなかったのだ。そんな苦い経験があってReflexを作ることになったのだが、それがAxis2となった現在でも改善されていないとは・・。インターオペラビリティを考えるならば、データバインディングにはもっと力を入れるべきだし、それができないなら、やはりSOAP通信というオペレーションだけに特化した方がいい。しかし子要素を配列で渡すかなあ・・普通はListでしょ。こんな話を聞くと、規約をもっと重視すべきだと思う。
現在、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)の３つでサイズはなんと350kbytes。たったこれだけで、Xerces、Castor、あるいはAXISのバインディング機能を実現できてしまうのだ。CastorやXMLBeanを使ってきて、今まで何やってたんだろうと思う。それから、XMLのJavaコーディングでありながら、Xercesにクラスパスを通さないのは実に気分がいいものである。
COMETが熱いらしい。とにかく煽られるので、自分を抑えるのに苦労している今日この頃だ。これには、あまり深入りしてはならないと、自分の感性は訴えているのだが、本当はやりたいらしい。さて、その仕組みはもうご存知の方も多いと思うが、一度サーバにリクエストを投げて予約しておき、サーバはそれを一旦保留、サーバ側で何かイベントがあった際に「返答」するというものである。奉仕人(server)のくせに自分の都合で客(client)に要求することが、実質的にできてしまう技術である。今までは、クライアントからポーリングをして、客(client)が奉仕人(server)の様子をときどきチェックする必要があった。別にこれでも十分だと思うが、COMETのよい点は、クライアントからの頻繁なアクセスがなくても、サーバからあたかもコールしているかのように動作することだ。ポーリングよりトラフィックを減らせることになるかも、というのがメリットだと個人的には思っている。でも実際にはサーバのリクスト数が数万は軽く突破したなどの報告もあるので、本当に有効かどうかはよくわからない。コネクション数の増大はJETTY６のContinuationsを使えばなんとかなりそうだが、実際はよく分かっていない。それとは別に、ネットワークの間にPROXYなどがあった場合に、コネクションタイムアウトしたらどうなるのだろうとか、課題も多そうだ。タイムアウトを避けるためにポーリングしたりして・・・・。意味ないYO! そういえば、JETTY6をReflexに載せる予定だった。COMET対応は避けられないかなあ。
あの、Don Fergusonが来日するらしい。来週、iSUC@札幌で講演するらしいが、これほどの大物にしては地味すぎるなあ。いったいどういうこと？まあ、話が聞ける人は幸運な人ということで。彼の話は、たぶんWEB2.0で惹き付けておいて、SCAで締めるという感じになるんじゃないかな。SCAはとっつきにくいかもしれないので、参加者は、以下の本を読んでおくといいと思う。それから、IBMがなぜこれほどまでにSCAにこだわるのか、要するに彼がこだわっているからなのだが、そのはっきりとした理由をもし聞ける人は聞いてほしい。
このブログのように、Bloggerは自分のサイトに置くことができるので、ドメイン名を変更することなく使えて便利なのだが、カテゴリー分けができなかったり、トラックバック機能がなかったりと、当然あるものと思っていた機能がないのでちょっととまどった。しかし、それらはTagClickとか、HaloScanとか外部サービスのマッシュアップでできるのね。かなりびっくり。ReflexでBLOGを作る前にBloggerをさわっておいてよかったかも。
本当はReflexでBLOG化したかったんだけど、いつになるか分からないので、Bloggerの助けを借りることにした。
