Mule ESB 3.2 JMX を HTTP (ブラウザ)で利用する
最近は、すっかり、メッセージングスタイルのアプリケーション開発にのめりこんでいる。
使っている道具は Mule ESB。メッセージング処理用のアプリケーションサーバー。
（ Tomcat は、 Web用のアプリケーションサーバー )
Mule ESB は、 3.x になって、アプリケーションの配置・停止がホットデプロイになり、運用が劇的に簡単になった。
EIP:Enterprise Integration Patterns のパターンを意識した実装／機能／説明が豊富になったので、EIP の実践手段としては、だいぶ進化した感じ。（現在も発展中なので、おおいに期待したい）
3.1.2 から、ログファイルが、アプリケーション単位に扱えるようになったのはありがたい。（ようやくですが）
3.2.0 で、schemaLocation ファイルで、バージョン番号のかわりに "current" が使えるようになった。これ、地味だけど、とてもありがたい改良点。
あと、前々から、実現できたいたらしいけど、私がようやく自分で設定できるようになった、Mule ESB の運用・監視ネタ。
JMX の機能を、HTTP ベースでブラウザから、利用する方法。
JVM のメモリ、スレッドの状態の把握から、Mule の各コンポーネントの動作状況の監視、起動や停止など、もりだくさんの機能が手軽にアクセス可能人になる。
以下の、単純なアプリケーションを、ホットデプロイすれば LAN 上 mule-hostname:9999 で、ベーシック認証付で、利用できるようになる。
興味がある人は、ぜひ、ためしてみてください。
この機能は、セキュリティ上、がちがち保護すべき機能なので、くれぐれも自己責任で。
( 本番環境であれば、firewall 設定で、 ip や、port の縛りが必須です )
JMX監視アプリケーションの config ファイル：
<?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:management="http://www.mulesoft.org/schema/mule/management" xsi:schemaLocation=" http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/management http://www.mulesoft.org/schema/mule/management/current/mule-management.xsd "> <!-- for JMX Console --> <management:jmx-default-config /> <!-- for Browser Access --> <management:jmx-mx4j-adaptor jmxAdaptorUrl="http://0.0.0.0:9999" login="masuda" password="toru" /> </mule>
schemaLocation の、/current/ が、3.2 からの新機能。
以前のバージョンまでは、ここに、 3.1 とか、実バージョン番号を入れていたので、Mule サーバーのバージョンアップの度に、書き換えが必要だった。
3.2 以降は、/current/ と記述しておくと、実行時に、実際の Mule ESB バージョン番号に展開されてチェックされるらしい。
Erlang で世界の見え方がかわっちゃった
「７つの言語 ７つの世界」を参考に、Erlang を体験。
いやー、ほんと、別世界。
最初の印象：
・ルールとパターンマッチングは、ご先祖様の、Prolog ゆずりだなあ。
・メッセージ・パッシングは、Smalltalk というか、オブジェクト指向の原点の雰囲気。
・ループ構造が末尾再帰っぽいのは、関数型言語。
まあ、こんなもんかな、という感じ。
ところが、
・プロセス間通信
・プロセスの監視、自動再起動
を試したら、これがびっくり。
（ Erlang のプロセスは、Unix のプロセスやスレッドとも、 Java の スレッドとも違うタイプの独自の「軽量プロセス」らしい）
プロセスをぼんぼん起動して、プロセス間で、ばんばんメッセージパッシングが、いとも簡単にできちゃうのがすごい。
もっと驚いたのは、同一サーバーや、ネットワーク上のサーバーに、ノード(Erlang ランタイム）をいくつでも、立ち上げて、簡単に通信ができちゃうところ。
erl -name 'node-name@hostname'
で、ほんと、いくらでも、立ち上がる。
そして、ノードをまたがったプロセス間通信の仕組みが、Erlang ランタイムにもともと組み込まれている。
ネットワーク上に分散したプロセス間通信と、その間のメッセージングがいとも簡単にできちゃう。
しかも、ノードをまたがった、プロセスの監視や再起動などが、組込みのモジュールで、最初から全部そろっている感じ。
とにかく「ネットワークプログラミング」だとか「プロセス間通信」だとか「並行プロセス管理」だとか、小難しいことをいっさい考えずに、たくさんのノードの分散したアプリケーションを書けちゃう感じ。
関数をまたがって、状態を持てない言語のそもそものアーキテクチャが効果絶大なんだろうなあ。
試してはいないけど、Erlang のランタイムや、プロセス管理、プロセス間通信は、めちゃくちゃ信頼性が高いらしい。
状態管理が不要になれば、並行分散処理の信頼性は格段に向上する。
C/C++ とか、 Java で、スレッドセーフにするのがたいへんなのは、状態管理がたいへんだから。
最初から状態を持たなければ、どんどん、分散並行処理しても、安全なわけだ。
Twitter のメッセージングサーバーが Erlang で書かれていたとか、RappidMQ が Erlang で実装という話を聞いたような気がするが、なるほどなあ、という感じ。
ルールベースで宣言型、かつ、非同期メッセージングの分散並行処理という、この Erlang という言語の世界は、ほんと、別世界。そしてすばらしい。
Erlang で仕事をするとか、Erlang がメジャーになるということはないとは思う。
でも、
宣言スタイル：事実とルールを宣言、パターンマッチングで処理
分散協調：非同期メッセージングで、ネットワーク上で、分散並行した多数のプロセス間で、協調処理
ほんと、すてきなアーキテクチャだと思う。
しかも、その世界を、さくっと、試せてしまうのが、Erlang 。
クラウドコンピューティングに対応したソフトウェアアーキテクチャのプラットフォームの雰囲気を、すでに Erlang で、疑似体験できている気がする。
「７つの言語 ７つの世界」の意図の通り、「異なるプログラミングパラダイムを知ることが設計能力を劇的に向上する」ということを、また実感できた。
実プロジェクトで、Mule ESB でのメッセージングアプリケーションの設計・実装の真っ最中なんだけど、そっちの設計のアイデアやスタイルに、だいぶ、影響がでそうな予感。
Smalltalk だと、メッセージパッシングが、ひとつのプログラム空間に閉じている。
Erlang では、メッセージパッシングは、多数のプロセス、多数のノード上で、さくっと実現できちゃう。
ほんと、すごい世界になったもんだと思う。
