Twitter的マルチインタフェースサービスと、実装基盤としてのESB
追記：長くなったので一言で言うと、以下は「Twitterみたいなの作るならESB見とくと良いかも」という話です。
マルチインタフェースサービス
Twitterが本格的に流行るかどうかは分かりませんが、Twitter的なサービス――Webサイトだけではなく携帯電話やインスタントメッセンジャー、API等様々なインタフェースを通して利用できるサービスは、これから増えていくと思います。
Web2.0の説明として頻繁に参照されるティム・オライリー氏の例の文書でも、「単一デバイスの枠を超えたソフトウェア」が要素の1つとして挙げられています。しかし1つのPCプラットフォームでも様々な種類を持つ事を勘案すると、デバイスよりはインタフェースの方が適切でしょう。という事でこのエントリではそういったサービスを、仮にマルチインタフェースサービス（以下MIS）と呼んでみます*1。
MISは、やや一般化すると次のようなサービスを指しています。
MISのアーキテクチャの特徴
MISにはユーザ環境への適応性（ユビキタス性？）、ビジネスモデル上の特徴など幾つもの側面があると思いますが、このエントリで考えてみたいのはアーキテクチャです。
一般的なWebサイトのアーキテクチャは、大雑把に言って
UIの処理 ⇔ ロジックやデータの処理 ⇔ ストレージ（主にDB）
という感じです。さて、ここに他のインタフェースを追加する場合、どうなるでしょうか？
もしこれが掲示板サービスで、携帯電話からも閲覧や投稿が出来るようにしたいという話であれば、そう難しくはなさそうです*2。UIの処理をURLや境界部分で分岐させて、携帯用のセッション管理や画面生成等を行えば大体対応できるでしょう。しかし追加したいのがインスタントメッセンジャーで、そこから何らかの操作やデータの送受信を行うという話だったら？
まずクライアントとやり取りするメッセージングサーバが必要です。ではそのサーバとWebサイトを処理するサーバはどうやって連携するか。DB連携？リアルタイム性が失われそう。サーバ間で何かのプロトコルを使う事にしたとして、おそらくデータ永続化部分は元々のWebサイト用サーバにあるでしょうから、結局サーバ間は双方向のコネクションが必要になりそうです*3。
やれやれ対応できたかなというところで、じゃあ今度はメールからの投稿を受け付けつつ、特定のデータは指定されたメールにも通知する機能を追加しましょうという話に。メールサーバからのデータプッシュを処理し、結果をメッセンジャーに投げてみる。しかしやってみて分かった事として、メールは結構巨大なデータを送付されて処理に時間がかかる場合があるので、どうもキューに入れて非同期にしたくなってきた。じゃあそこだけ非同期に、ってそれメッセージの順序は大丈夫かな？んーではまず前処理したものを永続化してから短いサイクルのバッチにしようか…と、だんだん難しくなってきました。
そして追い討ちをかけるように、メッセージングサーバは独自のタイミングで機能を閉塞できる必要が出てくるかも知れません。って事はその部分だけ独自の管理機能を追加して、うぅ…これは後でメンテできるんだろうか？
とまあ、適当にハマりシナリオを考えてみましたが、あり得ないとも言い切れない展開です。
ではそうならないよう、複数のインタフェースの追加に柔軟に対応できるアーキテクチャを考えてフレームワークっぽく作りましょう――といきなり行く前に、実はちょっとだけ横を見てみると、そんな用途にピッタリのアーキテクチャがあります。それがESB（エンタープライズ・サービス・バス）です。
MISとESBの類似性
上の例では、敢えて大変そうな感じで複数のインタフェースの追加を考えました。しかしエンタープライズ分野において、あるシステムが他のシステムやネットワークとデータをやり取りするというのは非常にポピュラーなケースです。そこで昔から色々な連携アーキテクチャや製品が提案・使用されてきており、ESBはその分野でここ数年流行っている(?)アーキテクチャの1つです。ESBの厳密な定義はたぶん存在しませんが、敢えて超ざっくり言えば「あっちこっちから入ってくるデータを変換したり処理したりあっちこっちに送ったりする為のアーキテクチャ」です（これだけだと色んなものが当てはまりそうな気もしますが、具体的なイメージは後述する図などを見て下さい）。
つまりMISは、つながる対象（インタフェース）こそだいぶ違いますが、やりたい事や論理的なアーキテクチャのレベルでは、かなりESBと類似していると言えるのです。
ESBの実装
じゃあESBの具体的な実装って何よ、という話。商用の製品は色々ありますが、（広義の）Webサービスを作るのには幾つかの点で不向きです。そこでオープンソースで見てみると、ここからは完全にJava限定の話になってしまいますが、ServiceMix、OpenESB、Muleなどが有名どころとして存在します。これらはいずれもESBのJava版仕様とも言うべきJBI(Java Business Integration)を実装したものです*4。例えばMuleのイメージとかServiceMixのサンプルを見て頂くと分かる通り、色々なサービスやプロトコルがプラグのようにバスに接続されて、そこをメッセージが飛び交うアーキテクチャになっています。まさにTwitter的なMISのアーキテクチャに使えそうに見えてきませんか？
実装例：ServiceMix
ここでもうちょっと具体的に「どのくらい使えそうか？」を探るべく、ServiceMixを見てみたいと思います。これを選んだ理由は、昔JavaOneで発表した時にServiceMix担当だったから、というだけです(w。
まずどんなインタフェースがサポートされてるのかコンポーネントのリストを見てみると、HTTP, FTP, Jabber, SOAP, JMSなどが使えますし（HTTPはJettyのcontinuationsを使えるらしいので、cometな実装もサポートできるかもしれませんね）、RSSの取得や生成、メールの送信などもサポートされています。
更に入力されたデータ（メッセージ）をどこに飛ばすかを決めるルーティングは色々な手段が選べますし、外部からそれらのコンポーネントを監視したりライフサイクルを管理、操作する手段も最初から用意されています。
こうしてみると、先のハマりシナリオで出てくるような事はほぼ考慮、サポートされています。まあそれを知ってて作ったシナリオなので我田引水っぽいですが、それでもそれなりに有用そうだと感じられるのではないでしょうか。パフォーマンスに関して言うと、もちろん直接コンポーネント同士がやり取りする場合と比べるとコンテナ処理のオーバヘッドが多少ある訳ですが、JBIは現実を踏まえた仕様としてメッセージの標準形式変換などの処理を行わないので、問題になるほどではないと思います（とはいえベンチマークがあると嬉しいですが）。また、スケーラビリティに関してはクラスタリングもサポートされています。
終わりに
先述のJavaOneの時には、エンタープライズな技術とWeb2.0的なサービスをどう合わせて見せるかでarclamp鈴木さん、ATL Systemsの北条さんと結構悩んだのですが、こうして実在のサービスをイメージしながらESBについて考えられる時代がついに来たようです（大げさ）。最初にも書いた通り、TwitterがどうなるかはともかくMIS（マルチインタフェースサービス）は増えていくと思うので、そういったサービスを作ろうという方は、言語やイメージに関わらず一度見てみると使わなくても参考になると思います。TwitterはRubyですし（メッセージサーバはErlangだそうですが）、上記の例でももっと軽い実装があり得ると思いますが、既存のよく考えられたアーキテクチャを知ればより適切な設計や実装に近づけることでしょう。
もうちょっと言うと、特別にJavaやESBを推したいとかではなく、サービスを実現する為のアーキテクチャを想像・模索する中で少々縁が薄そうな分野がつながってくるのは楽しいですし、ちょっと範囲を広げて探すと意外と面白いものもあるかも知れません、という話なのでした。一文が長くてすみません。
