昨日は日本のJBOSSユーザーズグループ(Japan JBUG)の
キックオフ飲み会がありました。今回の前にも集まりが
あって、そちらも参加したかったのですが、仕事の都合
で行けなかったので、今回を楽しみにしていました。
日頃JBOSS関連記事で勉強させていただいている方々と
直接お会いすることができ、大変有意義な時間でした。
実案件でのJBOSS利用の話も多く、Swing GUIをクライ
アントにしている例や金融系のかなりクリティカルな
場面で活用されている例などのお話も聴けました。
個人的にはJBOSS APはもちろんですが、JEMS全体に
期待を寄せています。JBOSS APを中心にしてJBOSS
AOP、jBPM、JBOSS Portalなどの周辺プロダクトが
豊富に揃っていますが、いずれもJBOSS APとは独立
させて用いることもできます。顧客毎の運用環境に
柔軟に対応できる基盤という意味でもJEMSのこうし
た構成は便利だと考えています。
JEMSの中でも最近個人的に注目しているのはjBPMと
Seamです。グループウェアやCMSにはワークフロー
の機能がもちろんありますが、いずれの場合も申請
フローや承認フロー向けにガチガチに作られていて
顧客の業務フローをそこに載せようとすると、多大
なカスタマイズコストが掛かってしまうパターンが
数多くありました。業務フローを載せることのでき
るシンプルでコンパクトなワークフローエンジンが
あったらいいなぁと思い、自作を考えていたところ
にちょうどjBPMが登場し、「おおっ、コレだ！」と
思いました。jBPMはとてもコンパクトなので、クラ
イアントサイドでのユーザー毎の業務フローの実行
(複数のアプリに同じ内容を入力しているような手
間をサーバーサイドではなく、クライアントサイド
で複数アプリにデータを流してあげるなど) といっ
たことも可能なのではないかと考えています。
一方のSeamについてはJSFとEJBの繋ぎという意味で
サービスを提供する企業のWebサイトに使えるのでは
ないかと思っています。以前にJSFのベータ版とEJB
2.xでプロトタイプを作ってみたのですが、JSF側の
Backing BeanとEJBのDTOの間でデータの受け渡しを
しなければならず、とても冗長に感じていました。
SeamではEJB3.0のEntityクラスをBacking Beanと
して扱えるのでこの点が劇的に改善されることが期待
できます。当然、Session Beanの中からBacking
Beanを参照したりもできるのですが、その際には
アノテーションを用いたインジェクション的なコード
になります。Seamは異なるコンテキスト同士をシーム
レスに繋いで、開発者からコンテキストの違いを隠蔽
してくれるものだと理解していますが、コンテキスト
を気にせずオブジェクトの参照を注入できるという
観点からすればJSFとEJBの間に限らず、DIコンテナ間
を繋ぐものという形で発展していくのかも知れません。
今後、勉強会なども開催されるということですので、
いろいろと勉強していきたいと思っています(^^)
先日の懇親会では商用APサーバーとJBOSSとの比較に
ついても興味深いお話がありました。顧客側がSIer
に対してシステム構成を細かく指示するUSと違い、
日本は丸ごとお任せのパターンが多いのが実情です。
そうすると、商用APの方が安心感があるような気も
するのですが、SIerの立場からすれば中身がいじれ
ないので、いざという時に自分自身で即時の対処が
できないという問題も生じてきます。また商用APの
中には他社のプロダクトをOEMしている場合もあり、
OEM元の方では既にバグフィックスされているのに
それを組み込むことは保証されず、かなり先の製品
アップデートを待つしかないということもあります。
ボク自身、商用AP上での製品開発をしていたことが
ありましたが、問題の箇所はわかっているのに手を
入れることができず歯がゆい思いをした経験があり
ました。勿論商用APにも良い点はたくさんあるので
一概には論じられませんが、「お任せの傾向がある
からこそ、逆にJBOSSのようなオープンソースの方
がお客様にタイムリーなサービスと安心を与えられ
るのでは？」という見方も今後は重要なポイントに
なってくるのではないかと感じました。
