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)と連携して監査的な情報を出せるのかもしれません。

まずはものすごく大雑把に仮想的な目標を考えてみることにします．まず家の中を見回してみて，そこにあるものを仮にITシステムと見なすことにしましょう．たとえば，冷蔵庫やテレビ，本棚，洗濯機，勉強机，いす，ソファ，ステレオ，クローゼットなどです．私たちは普段あまり意識しませんが，日常生活において実に多くの道具を使っていることに気づきます．さて，これらの家財は普通，引っ越しをしたり，新たに買いそろえたときに機能的に使えるよう配置します．本棚や，勉強机は勉強部屋や書斎におくでしょうし，冷蔵庫や電子レンジは台所に配置します．もちろん，大掃除をするときには配置を換えてみたりすることもあります．

引っ越しをして荷解きが一段落した後や，大掃除をした直後には，家財は本来のもつべき役割を最大限発揮しています．たとえば，本棚には本が格納されているでしょうし，勉強机はノートや本が広げられるよう十分スペースがあります．ところが，ある程度時間が経つと，本棚に本が入らなくなったり，新たに陶芸の趣味を始めたりすると，今までは整然と本が並んでいた本棚に，本のかわりに陶芸の道具が格納されたり，勉強机の上に本が積み上げられたりと，すこしずつ本来の役割とは別の使われ方にかわっていくことがあります．場合によっては，面倒くさがって陶芸の道具さえも机の上に出しっぱなしになるかもしれませんし，家族の誰かが物を移動させたり，別のものをおき始めるかもしれません．

この状態が進むと，家財は本来の便利さを急速に失い始めます．ものがどこにあるか分からなくなったり，勉強のためのスペースが十分に確保できなくなる場合もあります．このため，ある段階を超えると大掃除の実施を強いられ，丸一日の労力が必要になります．新たに本棚を買いそろえたり，作業机を買い足すならば計画を含めもっと多くの時間が必要かもしれません．家族とスケジュールをあわせるために仕事を休む必要があるならなおさら大変でしょう．さて，そろそろ問題点と目標がなんとなく，想像できそうです．

問題点は，ある程度時間がたつと部屋が散らかってしまうことです．また，部屋自体も使いにくくなります．さらに，できれば大掃除のために休日をつぶすのもさけたいでしょう．目標はこれらの問題点を解決することです．具体的には，部屋が散らからないように維持することや，部屋自体の使いやすさを保つこと，さらには大掃除をしなくてもよくすることです．

さて，話をITシステムに戻して，問題点と目標をおさらいしましょう．企業や組織のITシステムは家の家財道具と同様に，多くのサブシステムで構成されており，それぞれの役割を担っています．ところが，新たな商品を扱うなどの新しい要件が生まれると，場合によっては予算や時間的な制約により既存のシステムでだましだまし要件を満たすように使ってしまう場合があります．この状況が続くと，サブシステムの持っていた本来の便利さは失われ，場合によっては全く使われなくなり，手動で業務が行われてしまうかもしれません．このような状況を想定するなら，目標は部屋の掃除と同様に

• サブシステムが散らからないように維持する．
• サブシステムの使いやすさを維持する．
• システム全体をできれば総入れ替えなど，大規模な修繕はしない．

といったところになるでしょうか．問題点をもう少しブレークダウンすると目標は修正されるかもしれませんが，現時点での仮想的な目標はこの3つにおいておくことにしましょう．それではまた次回．

SOAについて考えるの記事で、早速jack_sparrowさんに貴重なコメントをいただいたので、これをふまえて、SOAを考える前の準備をしておきます。SOAを訴求する上で苦労する点は、前回のエントリーで紹介した通り、利用者にとってSOAの正体があやふやでわかりにくいところです。この原因はいくつか考えられます。

• SOAの定義が語る人によってぶれる。
• しばしば、ほかの流行り言葉と組み合わせて語られる(例: Web 2.0やクラウドコンピューティング、ビジネス・プロセス・モデリング)。このため、全体の話の中でSOAがどこを占めているのかがわからない。
• にたような言葉や、関連キーワードがたくさんある(例: SCA、ESB、BPM、BAM)
• 話が抽象的である。
• メリットが具体的に想像できない。
• どのようなアクションをとってよいのか見当がつかない。

SOAミドルウエア製品を開発しているソフトウエア・ベンダーやオープンソース・コミュニティーの立場からすれば、他製品との差別化のために新たな機能や性能を付け加えることで競争を勝ち抜かねばならず、それらの新たな機能や性能といった特徴を宣伝キーワードとして取り込むことを考えます。この、新たな機能や性能といった特徴を訴求するために、既存の概念や問題点、解決方法と対比させていきます。こういった思いのもとに作られた広告やパンフレット、セミナー資料などをみると、それぞれのベンダないしコミュニティーの「訴求したいこと」がベースとなり、その一部としてSOAが語られることになりがちです。

このため、各ベンダーやコミュニティーから発信されるSOA関連情報は、ぼんやりとした核を保ちつつも、周辺の特徴はどんどんと曖昧なものになっていきます。さらに追い討ちをかけるのが、SOA + Web 2.0や、SOA + Cloud Computingなどのようなニコイチ作戦で訴求される場合で、こうなってはSOAの特徴もわからなくなれば、Web 2.0の特徴を知ることも難しくなります。ニコイチ作戦は、流行り言葉が生まれては消えやすい、IT業界では常用される方法で、造語(例: Web 3.0)と比べて本質を大きく曲げることはないものの、もともとの意味をあやふやにしてしまうことは間違いないだろうと思っています。

一方、利用者側として知りたいのは、SOAとは何なのか、とか、自分の抱えている問題についてSOAを使えばどのような解決が期待できるのか、とか、問題を解決するためにSOAではどのようなアプローチをとるのか、といったことです。上記のように、開発側と利用者側の間には訴求したいこと、知りたいことの内容でギャップがあり、特に今回のテーマSOAについて、わかりづらい、というレッテルが定着してしまったのではないかと思っています。

難しいところは、SOAは購入すればすぐに効果の出る魔法の薬ではない点です。SOAのねらいや目的を知らないまま使っていては、具体的な問題を解決することはできないでしょうし、場合によってはかえって冗長な作業を強いられSOAの導入効果が得られるどころか、非効率かしてしまう可能性もあります。
自分にとってのメリットをすぐ知りたいのは利用者として当然の主張です。とはいえ、メリットばかりを追い求めてしまうと、近視眼的な判断に陥りやすく、よりハデに広告されていたり、流行していそうなキーワードに心を奪われ、最初に興味を持ったSOAの本来の目的を見失ってしまったり、流行を追求することのみに傾倒してしまうかもしれません。

ようやくjack_sparrowさんのコメントに戻りましょう(jack_sparrowさん、知り合いということで勝手な引用ご容赦ください (^^ゞ

SOA ≒ Cloud

私の中での論理はこんな感じです。

「SOA ≒ Cloud」という認識は、SOAとCloudをよく知っている人には共感が得られる表現であるかもしれませんが、この「○○は△△の拡張だ」のような表現は、しばしば本来の意味を過度に省略しすぎていると思っています。SOAをよく知っている開発側の立場としては、このような表現はいくつかのキーワードをうまく結びつけて訴求するにあたって好都合であり、タイポグラフィーとしても収まりが良いのでこれが最高のSOA表現だと思い込んでしまう傾向があるのではないかと思っています。


たとえば、アインシュタインによる「E = mc²」という有名な式はとてもシンプルで、見栄えが良いのですが、その背後にある特殊相対性理論をきちんと理解していなければ何の役にも立たない式でもあります。SOAはアーキテクチャであり、ITシステムを設計する上での理論でもあります。今回予定している一連のエントリの目標は、岡崎のここ数年の活動のとりまとめとして、SOAというアーキテクチャを説明することです。あわよくば、SOAをうまく訴求できるキャッチコピーも考えてみることにします。そこでは、利用者として期待すべきこと、考慮しなければならないこと、開発者として注意すべきことをなるべく含めていくつもりです。とても一般的なテーマで、時間がかかるかもしれませんが、ゆっくりとみていってください (^^ゞ

今月末でSunを退職することになりますが、今までやってきたことの振り返りもかねて、一番最後まで関わっていた仕事でもあり、一番苦労したキーワードでもあるSOAについて考えてみることにします。ちょうど、岡崎にかわってその仕事を引き受けられた寺田さんも最近はブログでSOAについて解説されています。

• SOAって何？
• SOAって何？ Part2　ー　積み木作りといっしょ！！
• SOAって何？ Part 3　ー　IT基盤システムは柔軟性が必要

あと、担当していたSun Java CAPSもちょうど、米国でリリースされていたRelease 6が日本でも発表されましたのでそのメディアの反応も参考までに。

• サン日本法人、ＳＯＡ対応の新基盤ソフト (NIKKEI NET IT+PLUS)
• サン、システムの実用的な統合を可能とするSOA基盤の新版を発売 (キーマンズネット)
• サン、MDM機能を備えたSOA基盤製品「Sun Java CAPS 6」 (EnterpriseWatch)
• サン、BPMやサービス連携の機能を網羅したSOA基盤製品の最新版 (ITmedia TechTarget)
• サン、SOA基盤製品「Sun Java CAPS 6」を日本市場へ提供開始 (ソフトバンク ビジネス+IT)
• サンが「Sun Java CAPS6」を国内展開開始 (japan.internet.com)
• サン、SOA基盤スイート「Sun Java CAPS 6」の国内販売を開始 – オープンソースの成果を採り入れた製品群 (COMPUTERWORLD.jp)
• サン、SOA基盤製品「Sun Java CAPS 6」の日本での販売を開始 (マイコミジャーナル)
• サン、OSSベースのSOA基盤「Sun Java CAPS 6」国内販売開始 (OPEN TECH PRESS)

SOAを売る、という立場で一番難しいことは、利用者側にとって、SOAの正体はあやふやでわかりにくいことです。このため、たいていの場合、売り方としてはSOAと冠したプロダクトの機能をベースに、売り込みをかけようとします。これは、お客様にとってもわかりやすい内容で、それらがコスト上それが妥当なのかを判断しやすく話もスムーズに進みます。まあ、これはこれで商売として一つアリな形態だろうとおもいますが、SOA好きな自分にとってはやや不満の残るやり方です。せっかく時間もできましたし、来週にはSunの社員ではなくなり、自由な発想をもとにSOAを考えることができるようになると思います。