１章 なぜ「J2EE Without EJB」なのか？
EJBの特徴を浮き彫りにする
- DynamicProxy?が出てきたからEJBは時代遅れなのか？
→ DynamicProxy?の出現によって基底クラスを押し付ける必要が無くなった。
→ 継承ベースを前提にすることが時代遅れではないのか？
- EJBのリモート呼び出しはWebサービスに置き換わるのか？
→ EJBを使っていた箇所はいくつかWebサービスに置き換わるのでは？
→ 一つ一つの業務オブジェクトを分散的にリモート呼び出しする時代では無くなった。
→ ステートレスな分散オブジェクトですべての業務ドメインを構成することは難しい。
→ CORBAではステートフルな分散オブジェクトは作れる？
→ 可能だが、普通はそうならないように設計する。
- 作ったSFSBがある臨界点を超えると、passivate/activateが発生するが、どのAppServer?もこの処理は苦手。
→ 呼ぶときにCreate、呼び終わったらRemoveするって意味無いじゃん！
→ SFSBは技術的に未成熟だった。
→ SFSBはあまり使われていないよね。
→ （実例）ステートフルなEJBが1200個！！
→ 12台のAppServer?、それぞれに潤沢なメモリが必須。
→ 再起動時にpassivateされたメモリをactivateしようとしてまた落ちる。
→ passivateされたデータを消すバッチ作成とか。
→ SFSBだとフレームなどで同時にアクセスする場合は使えない。
→ スレッドセーフとは言っても呼ぶ側でsynchronizedをかける必要がある。
→ J2EEの仕様らしい。
→ EntityBean?はDescriptorでre-entrant指定ができる。
→ SessionBean?には無い。
→ 再入不可がお約束だけど、コンテナで管理してくれるのではなく例外を飛ばすのが仕様。
- EJBは複雑ではない。
→ docletを使えば簡単なのかもしれない。
→ コーディングに関しては簡単になるかもしれないけど、設計の複雑さは残るのでは？
→ EJBを知らなくてもそれなりに使えるようにするフレームワークが幾つかあるらしい。
→ 最右翼はC-Framework
→ EJBのコマンドパターンではなく、怪しげ！なStateHandler?を使ってる。
→ トランザクションの管理が煩雑になるのでStateHandler?は気をつけよう！
→ EJBを使って幸せになれた人は皆無？
→ 今更感もあるけどHibernate+SLSBはちょっとよかった。
→ AppServer?を提供している某社もSFSBはお勧めしないらしい。
- EJBをどうやってテストする？
→ クライアントを作りremotoからlookupしてテストする。
→ SFSBのテストはシナリオテストっぽくステートを作りながらテスト。
→ すべて手動。気合と根性（笑）
→ もともとのEJBの考えでは、流通しているテスト済みのコンポーネントを買って来て使う。
→ 実際はそうなってないよね。
→ 商売になるレベルのコンポーネントは誰が作れるの？
→ EJBコンポーネントはどこで売っている？
→ EC-ONEのC-BANK、ComponentSquare?など。
→ EC-ONEのフレームワークであるcFramework上で作成したコンポーネントを流通させようとしているのがC-Bankだと思う。
→ ヤフオクでノークレームノーリターンで売りましょう（笑）
→ POJOに業務ロジックを書いて、EJBはトランザクション制御をするだけの薄いラッパーにするやり方もある。
→ EJBは面倒なんでテストしない。
- メタデータは便利なの？
→ C#のメタデータはそれなりに便利。
→ 「継承親」が固定されるので、設計には不便。コーディングは便利。
→継承親が固定＝決まったあるクラスを継承しないと駄目。
→ ORマッピングでは便利だけど、DIコンテナでは無しかな。
→ EJB3.0はメタデータで多くの負債を負うとは？
→ 3.0以前の仕様を引きずること。
→ わざわざフルセットでサポートする必要はないのでは？
- EJBがAppServer?間で移植性が無いというのは言いすぎでは？
→ deploy部分はサーバ固有だったりする。
→ 動かすだけの移植できたとしても、使い物にならなかったりする。
→ 移植性はないと言っているのはEntityBean?の話ではないのか？
- DBとクライアントの移植は無くても、AppServer?の移植はあるのか？
→ SOLARISからPC UNIXにマシンを変更するときに、AppServer?を変えたりする。
→ AppServer?を変更できる、というウリでセールスが先行する場合がある。
→ フレームワークを作る場合は依存しないように作る。
→ 安くすませるためにJBOSSに変更したいということがあった。
J2EEには何が残るのか？
- JDOってどうですか？
→ 使っている人はいない。
→ まとまった日本語のドキュメントのあるツールがない。
→ JDOの有名なプロダクトって何？
→ Kodo JDOがそこそこ有名。
http://www.theserverside.com/news/thread.tss?thread_id=27850#133061
→ JDOの特徴は永続化先がRDBに固定されない。
→ ORMだけでタイヘンなのに無理があるんじゃないのか？
→ ODMGの影響か、永続化IFを継承しないと使えない。
→ 永続化クラスとそうでないクラスを設計レベルで区別しないといけない。
→ 継承しなくてもEnhancerがゴニョゴニョすることも可能だったよ。
→ JDO2.0からはOracleなどの主要ベンダから見放されている。
→ 多分RDBベンダがEJBをサポートして、OODBのベンダがJDOをサポートするのではないか。
- スレッドプーリングを使うためにEJBを使う必要はないよね。
→ RMIの層でもスレッドプールを賢く使うことができる。
- スレッドマネジメントとは言っても、管理するよりも再入時にエラーで返すだけ。
→ SLSBは複数の場合でもインスタンスが立ち上がるだけ。もともと簡単。
→ こういった意味で過大評価なのでは？
- Webサービスは遅い。RMIの方がいいのではないか？
→ XMLのパース処理があるから遅くなる。
→ 流れるデータがバイナリかテキストかということに影響している。
- RMIを使いたいという目的ではEJBは有効なのか？
→ まぁまぁ使えるのではないか。
→ 分散しなければならない業務要件ってそもそもあるのか？
→ パフォーマンスを出す目的というよりは、フロント側とエンド側のバージョン管理の為に使用している。
分岐路に立つJ2EE
- この節で言う分岐路とは
→ Specification-Drivenというこれまでの仕様先行型のJ2EE。
→ OpenSource?コミュニティの流れであるシンプルなJ2EE。
- 実践J2EEシステムデザインが与えた影響は？
→ 世界的に見ると大きな影響があったのでないだろうか。
→ 内容はイマイチ？よかった？
→ じゃぁどうすればよいのかというところが無いので欲求不満になる。
→ 分厚い。半分ぐらいになればよかった。
→ Rod Johnsonはクドい。EJBの愚痴を繰り返す。
→ without EJBでも同じこと言ってない？
→ EJBを使わないといけないという強迫観念を取り去ってくれた。
→ 今まではJ2EEパターンぐらいしかなかった。
→ もっと問題意識を持ちなさいという提起ではなかったのか。
- Specification-drivenは実際の開発者のボトムアップでは無くてベンダ中心で行われている？
→ 主要ベンダからのメンバーが優秀ならばよいのだけど…。
→ オープンソースの場合は優秀なものが淘汰されて残っている。
→ 実際に必要なときはまだ淘汰されきっていないことがある。
→ 委員会でザクッと仕様策定した方がスピードが早くてよいこともある。
新しい方法
簡潔さ
- アーキテクチャのリファクタリングって一般的？
→ 「リファクタリングって言葉、藻前ら使いすぎ！」とマーチンファウラーが言ってた
→ アーキテクチャが変わってしまったらリファクタリングとは違うんじゃない？
- 多くのアプリケーションは本当に一つのDBしか使わないか？
→ 裏にあるシステムはそれぞれのDBを持つこともあるが、表からみたら単一のホストとやり取り。
→ 複数のシステムでDBを持つことがあるが、個々のシステムがアクセスするという意味ではDBは一つ。
→ OLTP(online transaction processing)用とDWH(Data Warehouse)用が分かれていることはある。
→ アプリケーション内で片方が読み込み専門DBで、片方が読み書きというパターン。
→ 分散トランザクションを使うことは少ない。
→ 同一のスキーマをもつ異なるデータを入れた複数のDBを使ったシステム。
→ 本来ならばフェデレーションを使うべき。
→ あえて2フェーズコミットするよりも、大きくて早いDBサーバを用意したことが良い場合もある。
→ Oracleだとデータベースリンクで繋げると2フェーズコミットにならない？
→ 裏では2フェーズコミットになる？
→ 分散トランザクションが必要とされるケースは少ない。
→ ただし単一のDBしかなくてもJTAを使ってXAのDataSource?を使うのはJ2EEお決まりのパターン。
→ Springの場合は2つ以上のDBの場合だけJTAを使う。
→ それは間違ってるだろ、Spring！(byひがさん)
→ 一つか二つ以上かで使い分けることで逆に複雑さを増すことにならないか？
→ トランザクション管理のために新しいインタフェースを用意する意味は？
オブジェクト指向
- DTOはトリッキーなのか？
→ クライアントから何度も業務ロジックを呼び出すよりは、DTOを使った方がよい。
→ 自分がリクエストしたら、必要な結果が返ってくるだけの方が役割分担されシンプルではないのか？
→ そのデータがDTOであろうと無かろうと構わない。
→ カプセル化の考えには違反しないか？
→ DTOはデータをやり取りするためのオブジェクトなのでカプセル化は関係ない。
→ FakeObject?かもしれないが、トリッキーという程ではない。
→ Rodは完全にオブジェクト指向に沿わないとダメと考えているのでは？
→ どんなオブジェクトも振る舞いを持たないことは許されない。とか。
→ ユースケースをまたがるものはエンティティに、そうでないものはサービス層でと後述しているが、ユースケースをまたがるものってあまりないと思う。
→ クライアントが複数の業務ロジックを呼び分けて管理すよりは、DTOを使ってファサード的な作りにした方が保守性は高いのではないか？
- 永続化オブジェクトは振る舞いを持たせないといけないのか？
→ OO的な観点に立つとsetter/getterのみのオブジェクトはおかしい。
→ 現実的にはEntityオブジェクトにどんな振る舞いがあるかと考えると、殆ど無いかも。
→ 複数のEntityに関わる振る舞いを一つのEntityに実装してしまうのはちょっと違う。
→ 殆ど無いのであれば、Entityは振る舞いを持たないと考えた方が一貫性もありシンプルに感じる。
→ HibernateではEntityオブジェクトに振る舞いを持たせることができる。
→ Hibernateを使ったからといって真のOOになるわけではない。
→ EJBよりはOOに近づく。
→ DTOは振る舞いを持つ必要はない。Entityについては微妙。
- 振る舞いを持った永続化オブジェクトに対してアスペクトを適用することは可能か？
→ アスペクトは非機能要件について行うべきなので、それはやらない方がよい。
ビジネス要求第一
- この辺りのことを考えるのはアーキテクトでは？
→ それでもアプリケーションのポータビリティぐらい
→ 他の件はコストが掛かるなど、メリットが少ない
実地経験によるプロセス
- vertical sliceとは
→ 垂直方向に、機能レベルの要件を一つ満たすために必要なものを作ってゆく。
→ 機能レベルの要件以外に必要な基盤技術を調べる。
→ たぶん水平方向(horizonal slice)はアーキテクチャなどのこと。
→ 小さな要件で実際にdeployできるものを作って問題を発見しておく。
→ 開発以外にもやらなければならないことがたくさんある。
→ 結合フェーズになってハマるよりは、最初に潰しておきましょう。
→ リアルタイムUML用語っぽい？
→ 組み込まーは居ない？J2EEの読書会ですから！
→ 実践J2EEシステムデザインでもこの用語が出ているようだ。(「縦のスライス」と訳されている)
- magicってどういう意味？
→ たまたま想定外に上手くいったということ。
テスタビリティ
- テストファーストってどうなのよ？
→ テストファーストとEJBの組み合わせでは、EJBの中にロジックは一切書かない。
→ テストファーストはどれぐらい普及してるのか？
→ 全員の中で3人（全員同じチーム！）
→ 仕様を書く段階で、事前条件と事後条件を決めておく。
→ テストファーストとはちょっと違う。
→ メソッドの仕様レベル。仕様書にはテスト項目が決めてある。
→ オフショア開発で詳細設計の変わりにテスト仕様書を使って上手くいったことがある。
→ テストが用意されているコードは全体の10％というところもある。
→ JUnit初めてという人にとってはテストを書くことは習慣でない。
→ 新人さんにはテスト駆動しか知らないようにしてしまうとよいという話もある。
→ 純粋培養してしまうと新規案件にしか使えない。
→ コードカバレジを見ながら失敗しそうなところは確実にテストを書きましょうという方針。
→ テストコードを書かせるために教育コストがかかる。
→ すぐに回収できるはずなんだけどねー。
→ 既存コードのためのテストを書くのはたいへん。
→ Perlなどと比べて静的検証がしっかりしているので、テストを書かなくてもすぐ問題が起きないことが多く、書かない人が多いのではないか？
→ DBのテストスキーマ変更があった場合のテストはどうしよう？
→ その都度テストデータをメンテナンスするしかないのでは？
→ 毎週のようにスキーマ変更があるので困っている。
→ 仕様の問題。テストコードではどうにもならない。
→ データベースモデルをもう少しメタにするとか？
軽量フレームワークとコンテナ
- Seasar2とSpring使ったことある人
→ SpringもSeasr2も結構使っている人は結構いますた。
EJBを使うべきか？
- 金融系のアプリケーションにEJB向いているというのは本当か？
→ 時代が違うのでは？
→ クライアントマシンにパワーあるので、中央集約的なシステムはあまりない。
→ Rodは金融系のアプリケーションも扱っているが、詳しいというわけではないと思う。
→ 日本のメガバンクと言われるところでもEJBを使っているのは1社だけ。
→ 3大証券では2社がEJBを使っている。証券系ではこれから増えるのでは？
→ 証券系ではメインフレームからEJBにリプレースしていく流れ。
→ 銀行や証券のような膨大なトランザクションが発生するような場合でもEJBで大丈夫？
→ 予算があるから大丈夫（笑）
- Message Driven Beanはどうなのか？
→ EJBの中では簡単な方だけど、トランザクションの制御がイマイチ。
→ トランザクションの失敗で無限ループになったりすることがある。
まとめ
- S2Remotingはもうすぐ出るよ。
→ S2Axisはじきに出るけど、S2Remotingはたぶん出ない。
- MessagingについてはS2はまだ。
→ Springはテンプレートだけはある。
→ S2JMS Container For JBossという企画がある。(codename EBIYURI)
次回について
- 2章（川崎さん）
- 2〜5章までは1章の細かい話なので、このまま進めていくとどうなのか？
→ MLで進め方を検討しましょう。
- 今後は1ヶ月1回ペースで。
この議事録を読んで分からないことや、疑問に思ったこと、その他ご意見等がありましたら下記コメント欄にお願いします。匿名でも結構です。
