日々の破片

_ エンタープライジーなREST

オライリーから私が監訳（という作業を初めて経験したわけですが、それは別の物語）した、『JavaによるRESTfulシステム構築』という本が近々出ます。

JavaによるRESTfulシステム構築(Bill Burke)

この本は、実にいろいろな面からおもしろい。おもしろいので、オライリーの編集の方に翻訳して出版する価値もあれば意義もあるとお勧めしたわけで、当然、読むことをお勧めします。

さて、何がおもしろいのか。一端は後書きに書いたけど、当然、書ききれない点や後書きに書いてもしょうがない点とかは省略しているので、そのあたりを含めて紹介します。

1. 著者がBill Burke

これはおもしろい。というのは、BillはJBoss野郎なのだ。当然、CORBAからのORPC男。当然EJB。もちろんEJB3。

なぜ、そのBillが『JavaによるRESTfulシステム構築』なのか。そのあたりは前書きでいろいろ書いていて、そのあたりの葛藤がまずおもしろい。かつ、その葛藤の切実さは結構よくわかる。

こんな感じだ。

ある日、飯を食ってたら、へーいBillじゃないか、おれだよ、おれ。と呼ばれて顔を上げると、IONA時代の大先輩がにやにやしているではないか。この男は、おれの師匠で、ORPC道に引き込んだ張本人だ。

最近は何をされてるんですか？ と思わず訊くと、まじめな顔で、Bill,おれはCORBAは捨てたよ。これからはRESTだ。

えー、まじっすか？ せめてSOAPと言ってくださいよ。

やなこった。Bill。おれたちは若かったんだよ。苦いものだな、若さゆえの過ちというものは。というわけで素直に負けを認めようじゃないか。ジャーレスタファーライ！

バカですか！？

というわけで大激論を延々と繰り広げることになるのだが、ちょうどそのころ技術ブロゴスフィアでもREST対SOAPで賑わっていたのであった。

そして今おれはこの本を書いているし、JBoss RESTEasyのスペックリードやってんだぜ。

諸君、RESTだよ。分散コンピューティングの結論はここにあったのだ。

という具合に、Bill BurkeのRESTに対する否認、怒り、取引、抑鬱、受容が書かれている（まあ、この文章は広告だから大げさだが、書かれていない技術的なドラマ、つまり設計やネットワークシミュレーションなんかをいろいろやってみたのは間違いないだろう）。

2. 書籍の構成

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を使いまくるユニットテストになっているけど）。後、Maven2ね。サンプルは、JBoss RESTEasyに組み込まれているので、いずれにしろJAX-RSの実装が必要な以上、とりあえずはRESTEasyをダウンロードして展開すれば、本書の第2部をすぐに試せるという仕組みだ。もしJBossのJAX-RSは避けたいのであれば、とりあえず本書を読み終えてから乗り換えれば良いと思う。JAX-RSはJAX-RSだから、同じことだ。

この章立ての妙味と、部分けの現実味（コードの詳細はどうでも良い人は第1部だけ読めばよく、コード詳細も読むべき人は1部と2部を交互に読めばよい）は感心した。

3. JAX-RSというフレームワークの設計

というように、JAX-RSが、どのようにRESTの原則をJavaのコード実装にマップするかということが語られる都合上、フレームワークの特色についても深みがある説明が行われている。

その結果、アノテーションとDI（単にインジェクション）、そして特には語られないが流れるインターフェイスの世界が目の前に繰り広げられることになる。

実装継承はほとんど無し。フレームワーク規定のインターフェイス継承すら無い。

では、どうするのか、にまで踏み込んでいる。POJOを使え。クラス定義からはアノテーションは追い出せ。

つまり、独自のインターフェイスを切り、そこにアノテーションを埋め込み、実装はそのインターフェイス（JAX-RS規程のインターフェイスではない点に注意）を実装すれば、完全なPOJOとなる（ただし、僕はそこまでPOJOにしなくとも良いと思うし、どうもBill自身もそこまでやりたければやれるよ、というスタンスのようだが）。

EJB3もアノテーションとインジェクションだったが、Beanの役回りは固定的でそれはEJBの性格上どうしようもなかったのだが、JAX-RSではそのあたりも含めて、実装そのものは完全にJAX-RSとは独立できる（もちろんRESTな処理をするためのユーティリティクラスとかヘルパメソッドは外ざしで使うことになるので、importフリーにするメリットはない。が、そのあたりが必要となる面倒なことをしないのであればimportフリーにもできる。

4. 分散システムインフラとしての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が多いので障害はむしろ多い。そして障害が起きるときは複数台まとめて起きてファームがバグる。単なるミラーリングよりも容量が稼げて、しかも気休めになるよ、というだけに近い。もっとも、さすがに最近はファームのバグで……というのは聞かなくなったような気がするけど、最近はディスク容量あたりの単価が低くなったから単純なミラーリングしか使わなくなってきて、ミラーリングは処理が単純だからファームにもバグがないっていうだけなのかも）

複雑な障害が起きるところでは、システムはできるだけシンプルに保つべきではないか？

ところで、JAX-RSというのはどのようなフレームワークなのだろうか？ と先日松田さんに訊かれて、Railsにたとえて言うと、と考えて、route、と答えた。さらにコントローラのメソッドパラメータに対してURIのフラグメント分配もする。

でも、これが肝なのだ。Railsだってよくよく考えてみれば、routeがどれだけ重要か。それはActiveRecordの重要性は当然としても、でももっとも重要なのはまずはrouteだ。

というわけで、この本はおもしろいのだが、それは表面的なところに留まらず、分散設計への踏込をぎりぎりの点で見せていないだけで、実際にはRESTを使ったエンタープライズシステムの分散設計が隠れているという点でおもしろいのだ。つまり、技術の実システムへの適用という点からわくわくさせてくれるのだった。

JAX-RSあるいはRESTeasyは、非RESTfulか？の「JAX-RSは、開発者にRESTfulなサービスの*実装*方法に多くの柔軟性を与えます。ここでは、実装がキー・ワードなのです。」という言葉は、なかなか含蓄がある。