Netty 3.1.0が最近、JBossコミュニティにてリリースされた。Nettyはクライサント/サーバのネットワークアプリケーションを書く際のもう一つの選択肢となる。Netty自体はこう説明されている
非同期イベント駆動ネットワークアプリケーションで、メンテナンス性のあるハイパフォーマンスでハイスケーラビリティなプロトコルサーバとクライアントを短期間での開発するためのツールです。言い換えると、 Nettyはプロトコルサーバとクライアントのようなネットワークアプリケーションを迅速で簡単に開発できるNIOクライアントサーバフレームワークといえます。そしてTCP、UDPソケットサーバのようなネットワークプログラミングを非常に単純にして、整理された見通しのよいものにします。
Nettyの分類としては、Apache MinaとGrizzlyと同じになる。この最新版リリースでは多くの機能とパフォーマンスとAPIのユーザビリティの改善が対応されている。いくつかの機能は以下のとおりである
- より簡単なラージデータストリーミング(サンプル)
- より信頼性の高いOutOfMemoryError予防
- 新トランスポート
- OIOとNIOベースのUDPトランスポート
- In-VMトランスポート
- HTTPトンネリング
- Google Protocol Buffers連携
- JBoss Microcontainer、OSGi、Guiceと Spring連携
HTTPトンネリング機能は高い要望のあった機能のひとつで、リリースノートに簡単にまとまっている。
HTTPトンネリングトランスポ－ト(org.jboss.netty.channel.socket.http内)は、どんな既存のソケットアプリケーションでもHTTP上でプロキシされるのを可能にしたソケットトランスポートです。このトランスポートは特に、既存アプリケーションの変更をせずにファイアウォールをバイパスしたい時に有用です。どのように機能しているかというと、次のような感じになります。
HttpTunnelingClientSocketChannel --> HTTPフレンドリーファイアウォール --> サーブレットコンテナ (例 Tomcat、Jetty) --> HttpTunnelingServlet --> 独自サーバアプリケーション
もちろん、ネットワークアプリケーションを開発する上でのフレームワークの最終的な重要な選定基準はパフォーマンスとスケーラビリティになるでしょう。Nettyチームはパフォーマンスに関する情報をサイト上で公開している。また、Apache Minaサイトでもパフォーマンスの情報が確認できる。最後に、Nicholas Hagen氏はブログに Mina、Grizzlyもしくは Nettyから選ぶ過程をシリーズとして書いている。最終的にはNettyを選んだが次のような文章で締めくくられている。
結局、私はMinaやGrizzlyではなくNettyをパフォーマンス、メモリ、機能面で選びました。みなさんもご自分の要求にどのライブラリがフィットするのか、自分自身の手で分析してみるといいでしょう。
次バージョンであるNetty 3.2.0はコミュニティ下で閲覧可能で編集可能でもあるロードマップにそって開発中である。