watermint.org

JBI(Java Business Integration)はJSR 208の仕様にあるとおり、単一Java VM内で動作させることを前提としています。このため、ESBを導入する必要があるような必然的に大規模なシステムでは何らかの形で分散環境のサポートが必要となります。オープンソースのJBI実装の一つであるOpen ESBの次期バージョン、Open ESB v3のJBIコアとなるProject Fujiでは先日公開されたMilestone 2よりこの分散環境サポートを取り入れ始めたようです。

どういう風に分散環境サポートを入れてきたのか興味があったのでちょっと調べてみました。Fuji Distributed JBI Design & Architecture[wiki.open-esb.java.net] のアーキテクチャ図にあるとおり、二つのNMR(いわゆるバスの部分)をProxy BindingというBinding Componentによってつなぎ合わせるようです。シンプルでいいですね。
この図でもう一つ注目したいポイントはそれらProxy BindingはGlassFishのクラスタリング管理に使われているグループ管理フレームワークShoalを使っているところです。ShoalはP2P技術JXTAをベースに作られたグループ管理フレームワークで、動的に更新されるクラスタトポロジを扱うことができます。たとえば、ノード障害などによって非活性化したノードを動的に切り離したり、新たに追加されたノードを動的にグループに加えるなどです。
Project Fuji Milestone2での注目しておきたい拡張のもう一つはFujiランタイムの再活性化(Reactivate Runtime)です。説明によればこれはJava EEアプリケーションサーバなどで一般的になっているホットデプロイのJBI版と考えれば良いようです。Java EEアプリケーションサーバではホットデプロイのためにClassLoaderごとアプリケーションを捨てて読み込み直すのが一般的なのに対し、この再活性化機能ではきちんとLife cycleイベントに基づいて活性化するのだそうです。

GlassFish ESBのマイルストーンビルドが出て少し経ちましたが、遅ればせながら入れてみました。ところで、GlassFish ESBはhttp://glassfishesb.orgというサイトがあるにもかかわらず、https://open-esb.dev.java.net/glassfishesb/にフォワードされます。http://glassfish.orgがhttps://glassfish.dev.java.netにフォワードされるのと同じテイストでしょうか。FishCATのデザインといい、GlassFishのデザインテイストは今ひとつわからないところがあります(笑)。さて、GlassFish ESBですが、ダウンロードすればNetBeans + GlassFish ESBのインストーラが実行可能になります。

このインストーラはどうやら、NetBeansインストーラと別の実装のようで、インストール先もNetBeansインストーラと別の場所がデフォルトとなっています。/Applications以下の整理整頓に気をつけている僕としては、このインストーラは気に入らないところがいくつかあります。まず、デフォルトインストール先がGlassFish ESBが /Applications/glassfish、NetBeansが /Applications/NetBeansです。これはインストール前に変更できるのでいいんですが、/Applications/servicetagというディレクトリが勝手に作られて servicetag-registry.xmlというファイルが一つおかれます。このファイルはSERVICE TAG IMPLEMENTATION FOR OPEN ESBを参照すると、どうやらSun Online Accountへの登録に関する情報を管理しているようです。作ってもいいけど、$HOME/Library以下におくか、せめて . (どっと)で始まるディレクトリ名にしてほしい。もう一つの不満は、インストールされたNetBeansのアイコンついていないこと。これは、インストールされたNetBeans.app/Contents/Resources/icon.icnsというシンボリックリンクが、

icon.icns -> NetBeans GlassFish ESB/{nb-cluster}/netbeans.icns

というように、{nb-cluster}というおそらくビルド時の変数が展開されていないことによるようです。とりあえずこの辺の話はOpen ESBのメーリングリストに投げてみたのでひょっとしたらそのうち直るかもしれません。

GlassFish ESBといっても、今のところ同時にインストールされるNetBeans側に特別変化があるような感じではなく、ちょっと違いが感じられるとすればGlassFishの管理コンソール側でしょうか。左ペインのJBIフォルダ内のコンポーネントはGlassFishに比べてかなり多めです(GlassFishはsun-http-bindingとsun-javaee-engineだけ。NetBeansのSOAサポートパッケージで入れた場合はそれに加えsun-bpel-engine、sun-xslt-engine、sun-file-bindingなどが入る)。もう一つの違いはESBというフォルダがあることです。CAPS Application Configurationとありますので、Java CAPSプロジェクトがデプロイできるようになっているんでしょう。なお、Java CAPS自体はダウンロードはできないのでSunの人に言ってもらわないと使えないようですから、実際にこのフォルダがどう生きてくるかはよくわかりません。
Sun Java Enterprise System – Get Itより。

Sun Java Composite Application Suite

Note: Currently, Sun does not offer a free download of this product. Contact your local sales for details on how to download this product.

ほかに違いで見つけたところは、Lifecycle Moduleとして、JavaEEVerifyESBというモジュールが組み込まれているところです。DescriptionではAdds Java EE verifier MBeanということなのですが用途はよくわかりません。ところで、Open ESB、GlassFish ESB、Sun ESB Suite、Java CAPSと、似たようなプロダクトがたくさんあってわかりづらいのですが、比較表がありました。

GlassFish ESBにはSAPとかSiebel、PeopleSoft向けのアダプタやSWIFTやX12、EDIFACTのようなメッセージライブラリが付いてこないという切り分けなんですね。オープンなプロトコルのみでシステム統合するならGlassFish ESBだけでよく、プロプライエタリなプロトコルも使うならSun ESB SuiteかSun Java CAPS。さて、GlassFish ESBが今後どういう風に進歩していくかですが、個人的に注目しているのはESB Consoleというインキュベーションプロジェクトです。現在のGlassFish ESBでの管理コンソールではESBの各コンポーネント・ライフサイクル程度は管理できますが、トランザクションごとの情報や、ビジネス的な視点での管理はほとんどできません。ESB Consoleはそれらの点を補うためのプロジェクトのようです。Minimal feature listを少し引用してそれぞれみていきましょう。

1. The unified ESB management console will provide all the features that are useful in the current Enterprise Manager.
2. The unified ESB management console will provide an extensible management console to allow for various management features (like BPEL management, IEP management, ETL management, HTTP BC management and more) to be plugged in with drill-down capabilities. The Web Console would consist of one core web application which will accommodate other plug-ins thus making it an extensible management console to allow various management features to be plugged-in. This will allow our customers and partners to participate in the development of it by contributing certain management features.
3. The Web Application will allow users to deploy services to a number of arbitrary server instances and to a DAS with clusters.
4. Since Java CAPS management/monitoring capability is beyond what a typical application server would provide, these web applications could either be deployed on Glassfish, or be running outside of Glassfish.
5. The Web Console will also provide an Intelligent Audit Dashboard(IAD).
6. The Web Console will allow users to view various Web service performance metrics such as average response time, Transactions per Second (TPS), error count, call count, etc.
7. The Web Console will also have charting capabilities for web service performance metrics.
8. The Web Console will provide the ability to print relevant reports as PDF files.
9. The Web Console will notify administrators when an Service Level Agreement (SLA) metrics cross specified thresholds.
10. The Web Console will provide scale-out capabilities with the ability to deploy/undeploy a service or a composite application simultaneously on several servers and manage and monitor these services running on various server instances and clusters.
11. Scaling down services like limiting the Thread pools where available on a a component basis will also be exposed so resources allocated to an engine can be limited if required.
12. The Web Console will be able to manage and monitor JMS destinations for both STCMS and Java MQ
13. External Plugins: The Web Console will be able to manage and monitor BPEL 2.0 business process instances, terminate instances, and drill down to instance level details with a BPEL Management & Monitoring plugin. Same goes for other types of Service Engines.
14. The Web Console will expose Application Configuration (to configure environment specific information), Application Variables(to configure environment specific information), and support Application Verification before deployment of Composite Applications.
15. The Web Console will provide the ability to view log activity, with the ability to define filters.
16. All features will have access control so users can be limited only to a subset of management/monitoring features if required.
17. Based on the alert message sent, users should be able to view the associated service unit that an alert came from. It should be possible since we have the service unit name and component name available in the alert message header, and we should be able to take the user to the associated service unit’s plug-in in the UI.
18. For Alert Agent configuration, the administrator has to be able to propagate configurations done for one Server to multiple servers automatically.
19. There are certain management and monitoring capabilities that are exposed through aspects/interceptors. The Web Console should expose these configurations for users to configure.

おもしろそうなところでいえば、Intelligent Audit Dashboard (IAD)でしょうか。Audit Dashboardということなので、Intelligent Event Processor (IEP)と連携して監査的な情報を出せるのかもしれません。