おれたちは若かったんだよ。苦いものだな、若さゆえの過ちというものは。いうわけで素直に負けを認めようじゃないか。ジャーレスタファーライ!バカですか!?というわけで大激論を延々と繰り広げることになるのだが、ちょうどそのころ技術ブロゴスフィアでもREST対SOAPで賑わっていたのであった。RESTEasyのスペックリードやってんだぜ。分散コンピューティングの結論はここにあったのだ。書かれている(まあ、この文章は広告だから大げさだが、書かれていない技術的なドラマ、つまり設計やネットワークシミュレーションなんかをいろいろやってみたのは間違いないだろう)。書籍の構成2部構成となっていて、第1部はRESTとJavaプログラムのマッピングをJAX-RSを仲介として説明していく。URIがなぜ重要かというRESTの原則を説明してから、ではこれこれという(例としてはショッピングサイトっぽいものを使っている)サーバ上の処理があるとして、それをURIによって示す、つまりリソースとして設計するにはどうすれば良いか(このあたりは、特に例が複雑化するにつれて、いや、おれはそうは思えないとか、おれだったらこう考えるとか、読者が設計に参加する余地があり、そこも良い)、ではこういう設計とするとして、それをJavaのプログラムにマップするために、どのようにJAX-RSは機能するのか、リストで示した例を見てみよう。いうように、概念、概念の実例化、JavaプログラムへのJAX-RSを利用したマッピングという構成で各章を構成している。RESTの原則とは何で、それは実際にはどのように実装設計に落ちるのか、そしてJAX-RSが、「このREST」(そうでないRESTもあると思う)を実現化させるためにどのように設計されているか、そして実際のJavaのクラスにどのようにマッピングされるのかが語られている。RESTの原則に限らない。キャッシングについてはHTTPのIf-xxxヘッダの具体的な使い方の説明になる。(こういった微妙な点については後述)そのように構成された第1部に対して、第2部は実際に動くコードサンプルの動かし方とコードの読みどころの紹介となっている(チュートリアル)。すべてのサンプルはユニットテストが仕込まれている(もっとも、動作確認を目で見せる必要があるからだと思うが、System.outを使いまくるユニットテストになっているけど)。RESTEasyに組み込まれているので、いずれにしろJAX-RSの実装が必要な以上、とりあえずはRESTEasyをダウンロードして展開すれば、本書の第2部をすぐに試せるという仕組みだ。JBossのJAX-RSは避けたいのであれば、とりあえず本書を読み終えてから乗り換えれば良いと思う。JAX-RSはJAX-RSだから、同じことだ。この章立ての妙味と、部分けの現実味(コードの詳細はどうでも良い人は第1部だけ読めばよく、コード詳細も読むべき人は1部と2部を交互に読めばよい)は感心した。JAX-RSというフレームワークの設計というように、JAX-RSが、どのようにRESTの原則をJavaのコード実装にマップするかということが語られる都合上、フレームワークの特色についても深みがある説明が行われている。その結果、アノテーションとDI(単にインジェクション)、そして特には語られないが流れるインターフェイスの世界が目の前に繰り広げられることになる。実装継承はほとんど無し。フレームワーク規定のインターフェイス継承すら無い。するのか、にまで踏み込んでいる。クラス定義からはアノテーションは追い出せ。独自のインターフェイスを切り、そこにアノテーションを埋め込み、実装はそのインターフェイス(JAX-RS規程のインターフェイスではない点に注意)を実装すれば、完全なPOJOとなる(ただし、僕はそこまでPOJOにしなくとも良いと思うし、どうもBill自身もそこまでやりたければやれるよ、というスタンスのようだが)。EJB3もアノテーションとインジェクションだったが、Beanの役回りは固定的でそれはEJBの性格上どうしようもなかったのだが、JAX-RSではそのあたりも含めて、実装そのものは完全にJAX-RSとは独立できる(もちろんRESTな処理をするためのユーティリティクラスとかヘルパメソッドは外ざしで使うことになるので、importフリーにするメリットはない。そのあたりが必要となる面倒なことをしないのであればimportフリーにもできる。分散システムインフラとしてのRESTもう一点、大きな特徴だと思うのが、実際のところ、Billが想定しているRESTは、インターネットのRESTでは無いという点だ。なく、SOAのサブシステム間連携のためのインフラとしてのRESTなのだ。サンプルにはYahooあたりのWebサービスの呼び出しとかはまったく出てこない。基本はクライアントはApacheやRESTEasyが提供するHTTPクライアントクラスで、サーバはJAX-RSを動かしているJavaサーブレットコンテナだ。倒錯している?おそらく。Javaによるホモ環境の分散のためのグルーとしてRESTを意識しているというのは、常識的には倒錯だ。ヘテロ環境だからこそのHTTPではなかったっけ?どうやら、本気でRMIでもなければJava/IDLでもなく、もちろんJAX-WSでもなく、JAX-RSに賭けているのだ。(当たり前だが、JAX-RSはヘテロ環境でも使える。Billの興味はそこにはない。その意味では第1部は、一見するとインターネット上のショッピングサイトを例にしているようでいて、実体はエンタープライズなSOAを想定している。それが良くわかるのは、キャッシング戦略の章だ。ETagを駆使した楽観ロックというのは、インターネットシナリオには無理/無駄があり過ぎる。特定エンタープライズ環境だからこそ有意義だと考えられる。同様なことはメソッドの利用方法とステータスコードの利用方法にも表れている。PUTと204ががんがん出てくる)ここが分散コンピューティング実用化20年の当面の帰結だというのは、僕は賛意を覚える。2フェーズコミットは、一見良さそうな仕組みだが、実は大きく矛盾している。ネットワークが切れず、システムが落ちないのであれば、この仕組みは単なるオーバーヘッドだ。ネットワークが切れるのも、システムが落ちるのも、実は2巡目に起きるのだ。結局、ブラックボックスの中で複雑な処理が、想定外の状況で起きるため、どれだけの苦労をしてきただろうか。(余談だが、RAID5ってのも似たようなものだ。HDDが多いので障害はむしろ多い。障害が起きるときは複数台まとめて起きてファームがバグる。単なるミラーリングよりも容量が稼げて、しかも気休めになるよ、というだけに近い。と先日松田さんに訊かれて、Railsにたとえて言うと、と考えて、route、と答えた。コントローラのメソッドパラメータに対してURIのフラグメント分配もする。Railsだってよくよく考えてみれば、routeがどれだけ重要か。それはActiveRecordの重要性は当然としても、でももっとも重要なのはまずはrouteだ。いうわけで、この本はおもしろいのだが、それは表面的なところに留まらず、分散設計への踏込をぎりぎりの点で見せていないだけで、実際にはRESTを使ったエンタープライズシステムの分散設計が隠れているという点でおもしろいのだ。技術の実システムへの適用という点からわくわくさせてくれるのだった。JAX-RSあるいはRESTeasyは、非RESTfulか?の「JAX-RSは、開発者にRESTfulなサービスの*実装*方法に多くの柔軟性を与えます。ここでは、実装がキー・ワードなのです。」という言葉は、なかなか含蓄がある。猫が来て去って行った家の近くで妙に鳴いている猫がいる。近寄るとすりすりしてくるので、人に慣れている。いうか、首輪をしている。妙に薄汚れているし、異様に痩せている。捨て猫がいよいよ窮したか、あるいははぐれ猫が帰宅の途中で窮したか。しょうがないので、家に連れて帰って、とりあえず何もないのでしらす干しを洗って塩抜きして与えるとすごい勢いで食べる。この季節なのにノミもいないし不思議だが、薄汚れてはいるので、とりあえず洗う。首輪も汚いので洗ったら薄荷っぽい匂いがしてきたので、どうやら、ノミ取り薬剤を染み込ませてある首輪らしい。いうか、しつけも良いし、やはり飼い猫なのは間違いなさそうだ。結構なおばあさんっぽいから、いきなりの捨て猫とは思えず、やはりはぐれ猫らしい。したものか、と考えると、もっと食い物を寄越せというので、とりあえず妻に猫餌を買いに行かせて、居ついたときのために猫トイレと砂も買ってきてもらう。飯を食ったら落ち着いたのか、横になってぺろぺろしたり、固まってみたりいろいろしている。しばらしくして外に出せと騒ぎ出した。それともコンピュータの音がずっとしているので嫌なのか、どちらかだろう。外に出すと、あたりをいろいろ調べて、車の下にもぐって寝始めた。思うとこっち来て何か言いたそうだ。猫が何か言いたいときは飯の話だろうと思って、皿に買ってきた餌を入れ、外にだしておいたら、ぼりぼり食べて、一緒に出した水を皿から飲みまくっている。車の下にもぐって落ち着いている。次の日に見たら、皿はどちらもきれいに空になっていて、猫はどこかへ去っていた。[きっと、ある日突然に大きなつづらが置かれているかもしれませぬ。いや、小さいつづらで十分です。思ったが、結局、戻っては来なかった。メモrubytalkで話題になっているので、今頃、firewatirというものに気付いた。Ruby拡張ライブラリと、RubyのMSVCRTバージョン違いまとめRuby拡張ライブラリと、Ruby、それからRuby拡張ライブラリが依拠するDLLの3つのプレイヤーがいる場合に、Rubyが落ちる場合と落ちない場合がある。通常、まずいのは次の組み合わせだ。RubyがリンクしたMSVCRTと拡張ライブラリがリンクしたMSVCRTが異なる。これは、mallocとfreeのMSVCRTの実装による。・もしかすると、MSVCRT70以降は共通化されているかも知れないが未確認。・理屈上で確認しているのは、MSVCRT(6)とそれ以降の任意の1つとの組み合わせこれは、次の状況で発生する(追記あり)。・拡張ライブラリでマクロを利用してオブジェクトを生成する(具体的にはData_Make_Struct)。マクロなのでmallocの呼び出しは拡張ライブラリ側のMSVCRTで行う。・GCで上記オブジェクトを回収。GCのfreeなのでRuby側のMSVCRT側で行うそれに対して、拡張ライブラリが利用するサードパーティDLLはRubyオブジェクトを利用することはないので、よほど生なAPI(mallocしたオブジェクトを返すのでfreeは呼び出し側でやってくれ、というようなもので、しかもWin32APIではなくMSVCRTのmallocを利用する)が無ければ問題ない。readlineのMSVCRT(6)が、rubyとreadline.soをMSVCRT(100)で利用すると落ちるのだった。なんでだか追っかけたら、fdの問題だった。