スタラジ反省会
うーみゅ，なかなか厳しいご意見もあるようで．．． 2chよりS/N比が低いとは．．． 心より恥じる．
っていうかですね，今回のイベントのタイトルは「スタロジでスタラジOFF」なんですよね．少なくともWikiではそうなっています．つまりですね，これはあくまでもOFF会を中継しようというものなんですよ．OFF会なのですからS/N比が低くても当たり前というか，アドホックで行き当たりばったりの雑談を楽しんで頂く以上のことを期待されても困るというか，S/N比が重要なら事前に準備万端整えたパネルディスカッション風にすればいいわけですが，そんなもん楽しいか？ って感じもあるわけです．
とはいえ，反省すべき点が多々あるのは事実．まずは自分の心構えというか，参加者としての意識が低かったと思います．せっかく中継会場にいたにもかかわらず，自分もリスナーのつもりになっていたいう感じなんですね．自分が何か情報を発信しようという意識は正直全然なくて，はぶさんやひがさんの話を一等席で聞きたくて参加しただけという感じなのです．
それから，反応が鈍いというのも反省材料ですかね．鈍いというか遅いというか．今回も，はぶさんが全体の9割方一人で喋っていたと思うのですが(^^; それというのもですね，はぶさんって反応が速いのですよ．お題を出されたときに，即自分の意見を表現することが出来る人なんですね．自分が頭の中でもやもやっと考えをまとめようとしている間にはぶさんは次々と熱のこもった持論を展開していくわけです．そのスピードに追従できない．これっておそらく，普段からどれだけいろいろなことを考えているかの違いなんだろうなぁ．急に考えようとしたって無理で，普段からいろいろなことを考えて，自分の意見をまとめておかなければ，LIVEの主役にはなれないのでしょう．
という自分の側の問題を棚上げした上で，次回(あるのか？)に向けて提案をさせて頂きましょう．今回の場合，テーブルにマイクを固定して，だれでも喋れば音声が流れるようになっていました．これは早い者勝ち，つまりCSMA-CD方式なんですが，これだと常にはぶさん一人勝ちになってしまうのは目に見えているので，次回はトークンリング方式にしてはいかがでしょうか？ つまりマイクを1本にして，進行係がお題を示して隣の人にマイクを渡す，意見があれば喋って次の人にマイクを渡す．．． みたいな．これだと，同時にいろいろな人が喋ったりテーブル上の雑音を拾うこともなくて，リスナーに優しいのではないかと思います．席順を工夫すれば，自分みたいに反応の鈍いタイプにも考える時間が出来そうだし．
他にもいくつか反省材料が．
チャットの方にもLIVE実況をしようと書き込みをしてみたのですが，リスナーの皆様に音声が届くまでかなりのタイムラグがあるということを何度指摘されても忘れてしまい，まるで未来からの書き込みみたいになってしまったようです．LIVEの醍醐味を損ねてしまい申し訳ありませんでした．
それからもうひとつ，いまだコンタクトしたことのないizuさんが中継をお聞きになるということで，
レイカーズFINAL進出だぜ！ ざまーみろ！！
と，ご挨拶したかったのですが，機会をうかがっているうちにタイミングを逃してしまいました．無念だ．
スタラジ補足 ビジネスロジック
チャットからの質問で，「ビジネスロジックはサービス層に置くか，エンティティ層に置くか？」といった感じの質問がありました．答えられるような立場ではありませんが．．．
ここで言うビジネスロジックとはどういうものなのか？ を考えることが大切だと思います．ビジネスロジックを一つの大きな固まりだと考えると，「どちらに置くか？」という二者択一的な問題だと考えてしまいがちです．そうではなくて，ビジネスロジックも実際には様々な要素に分解することが出来ると思うのです．といっても私自身，確固たるモデルを持っているわけではありません．試行錯誤が全然足りていないので．
とりあえず，「UMLによるビジネスモデリング (isbn:479731382x)」をスタート地点として考えることが出来るのではないかと思っています．この書籍には，ビジネスモデルのメタモデルというのが提示されています．ビジネスモデルという言葉も使われ方の幅が広い用語ですが，ここで言うビジネスモデルはビジネスプロセス+リソースという感じのもので，それを構成する要素とその関係を図示してくれているのです．
そのうちいわゆるビジネスロジックとひとまとめにされていそうなものをピックアップすると．．．
- プロセス(Process)
- 状態変化(State Change)
- ルール(Rule)
- 制約的(Constraint)
- 派生的(Derivation)
- 存在的Existence)
これらについてさらに粒度もいろいろあり，それがまた階層的な関係(コンポジットパターンみたいな)を作り上げるのではないかと思っています．
そのうち細粒度のもの，特に特定のエンティティに閉じたものであればエンティティ層に配置するでしょうし，プロセスのようにより粒度の大きなものはサービス層に配置することになるでしょう．
という感じで，同書はいろいろと想像力を刺激してくれて，悪くないと思います．
おっと，LIVEで喋った以上の内容を書いてないぞ．これじゃ補足じゃないじゃん．無念だ．
スタラジ補足 EJB
スタラジで意外なくらいにEJBが話題になってびっくり．Spring + Hibernateになるとかいう噂のEJB3.0が相当期待されているようです．
でもですね，そのSpring + Hibernateなものって本当にEJBなんですかね？ 全然別物じゃん！？ って思っちゃいます．そもそものEJBとあまりにかけ離れているように感じるからです．
それは，EJBというものがどんなものかという認識に違いがあるからかもしれません．ということで私がEJBというものをどう認識しているかを書いてみるテスト．これはあくまでも個人的な思いこみなのでそこんとこよろしくです．
EJBを使っている人によると，EJBを使うメリットは宣言的トランザクションが使えることらしいです．確かにそれは魅力的．なんですが，それはEJBにとっておまけみたいなものに過ぎないと思います．EJBの本質は，
分散オブジェクト の コンポーネント
だと「私は」思っています．
EJBの壮大な野望は，「ビジネスコンポーネント」をかつてのVBX/OCXのように流通させることにあったのではないでしょうか．ここでいう「ビジネスコンポーネント」は，かなり粒度の大きなコンポーネントで，もしかしたらERPの○○モジュールみたいな感じでしょうか？ というのも，EJBの策定にも大きく関わったであろうCORBAな人達がそのような考えを示していたからで，それは例えば「ビジネスコンポーネントファクトリ (isbn:4798100935)」で窺い知ることが出来ます．個人的には，この頃に「ビジネスコンポーネント」として話題になっていたアイディアには共感できませんでした．まったく現実的ではないと思えたからです．
このテーマの多くはCORBAの人達から出てきていたのですが，実はCORBAの使い方にもいろいろあります．書籍などのサンプルでよく出てくるのは，ドメインモデルのオブジェクトをそのまま分散オブジェクトとして実装するような方法で，特に銀行(Bank)と口座(Account)の例を見かけることが多いですね．その場合，口座の数だけ分散オブジェクトと作ることになるわけで，CORBA2.3(だったかな？)2.2(だったらしい，id:shot6さん，どうもです)で導入されたPOA(Portable Object Adapter)はそのような実装を効率的に行うためのものだったりします．
しかしですね，CORBAでそのような実装をした場合，かなりの確率でパフォーマンスの問題にぶち当たったはず．いくら昔と比べてネットワークが速くなったとはいえ，それでも遅いことに変わりはないのです．結局の所，分散というかリモートなオブジェクトというのは，粒度を大きくしてインスタンスとインタフェースの数を減らさないと実用にはならないと思うのです．今では，それはセッションファサードとしてよく知られているわけですが．
話を「ビジネスコンポーネント」に戻すと，これは「細粒度の分散オブジェクト」を「大粒度のコンポーネント」にパッケージングするという，なんとも非現実的な代物という風に私の目には映りました．
EJBは，この「ビジネスコンポーネント」を目指して考案された仕様であるように思います．エンティティビーンなどという分散かつ永続的なオブジェクトの存在がその根拠．最初から使い物になるわけがないのです．
それでもEJBは注目と期待を集め続けてきたようですが，多くの人が必要としたのは「ビジネスコンポーネント」を実現する技術としてのEJBではなく，単に宣言的トランザクションやO/Rマッピングを使いたかっただけというのが現実のようです．不幸にも，それらを実現する最も身近な存在がたまたまEJBだった，というだけのこと．EJBもそれに応えるためにLocalインタフェースを導入したりしていますが．．． 生まれの悪さ(複雑！ 面倒！)はどうしようもありません．
しかし，もはやEJBを使わなくてもDIConとHibernateなどを組み合わせれば，宣言的なトランザクションやO/Rマッピングを手にすることが出来るのです．素晴らしい．
それではEJBに残されているのは何か？ 「分散」と言うことなんですが，前述のようにこれの現実的な使い方はファサードとしての使い方です．このファサードを突き詰めていくと，きわめて汎化されたエントリポイントに成り下がっていきます．そのようなファサードは，改めてEJBとして実装しなくても，もっと手軽に利用することが出来ます．それはServletです．
かつてCORBAなどの分散オブジェクトが期待されていた頃は，まだHTTPを用いたWEBベースの技術がここまで普及(進歩)するとは考えられませんでした．「分散」オブジェクトを使うシチュエーションというのは，ちょっと前によく耳にした3層C/Sのような世界だったのです．
しかし，時代はすっかり変わってしまいました．現在では企業内のシステムでもWEBベースの技術で構築することが一般的だと思います．HTTPを使ってサーバ側と連携するRIAもいろいろな選択肢がありますし，SOAPもあったりします．
ということで，Servlet + DICon + Hibernate でEJBは不要，EJBはすでに死んでいる！ というのが私の結論です．これ，本音としては自分でもちょっと短絡的かなと思っていたりするのですが，たいていの場合EJBを使わなければならない理由はもはやないと思います．
そんなわけで，正直EJB3.0もどうでもいいです．DIConはもはや必須だし，HibernateのようなO/Rマッピングツールもいいでしょう．でも，それがEJBとして仕様化される必要はないはず．ましてやDIConを標準化するのなら，それはJ2EEじゃなくてJ2SEにあってもいいと思うのです．
ところで，この日記ではSpring FrameworkやHibernateの入門記をやっているわけですが，その原点が実はEJBだったりします．かつてNIFTYのFRPOGPRO OO会議室で，仕様書を読みながらEJB入門記を書いたことがあるのです(サンプルはもちろんカウンタ)．EJB1.0がリリースされた年，Java2(JDK1.2)がリリースされた頃だったので，1998年の終わり頃でしょうか．BEAに買収された直後のWebLogicのバージョンは3.xだったかな．NIFTYとはいえ，それなりに公開された場所にEJBのことをまとめて書いたのは日本ではかなり早かったと思っています(JavaWorldにEJB特集が出たのは翌年の春でした)．
その時入門記に書いたのはSessionBeanまでで，そのあとEntityBeanについて書くつもりだったのですが，仕様書を読んでいるうちに興味をなくしたことを覚えています．(^^;
そうなんです，私にとってEJBは，98年にはもう死んだのです．合掌．
