- - PR -
EJBのメリットを教えてください
1
投稿者 | 投稿内容 |
---|---|
|
投稿日時: 2005-09-10 20:36
タイトルの通りなのですが、EJBのメリットが理解出来ない為、どなたかお
わかりになる方ご教示ください。 ちなみに私は現在以下のように認識しています。 間違っていたら合わせてご指摘頂けると助かります。 ・一般的に言われているEJBのメリットはコンポーネントの再利用という事になっているが、そもそもEntityBeanはDB設計に依存する為再利用できる状況は限られる ・グローバルトランザクションはJTAで代替可能 ・分散オブジェクトはRMIで代替可能 SessionBeanはそもそも存在理由がわかりません。 宜しくお願い致します。 |
|
投稿日時: 2005-09-10 22:55
> ・一般的に言われているEJBのメリットはコンポーネントの再利用という事になっているが、そもそもEntityBeanはDB設計に依存する為再利用できる状況は限られる
EJBが対象とするような業務的なソフトウェアコンポーネントの再利用はそもそも難しいので、これはEJBに限ったことではないです。 > ・グローバルトランザクションはJTAで代替可能 > ・分散オブジェクトはRMIで代替可能 EJBはこれらのテクノロジを統合して透過的に利用できるようにした仕様なので、代替可能なのは当然です。これらのテクノロジの詳細を理解しなくとも利用できる容易さがEJBのメリットです。 > SessionBeanはそもそも存在理由がわかりません。 これは同意見です。そもそもSessionやEntityBeanを利用すればいい話ですから。 |
|
投稿日時: 2005-09-11 01:36
EJB の分散オブジェクト技術やトランザクション機能はそのものずばり RMI や JTA を応用しているものですから「代替可能」というとちょっと違和感がありますね。
EJB といってもビジネスロジックやエンティティを表現するための作法、フレームワークですから他のあらゆる技術で代替可能です。 ただ、たとえば WebLogic なんかは独自の RMI 実装を使っていて知らずとパフォーマンスが上がったり、同じサーバ上にデプロイされている EJB の呼出しをローカル呼出(参照呼び出し)して最適化してくれたりします。 いや、それだって自分でごりごり同様の処理を実装したり、そのような機能をもったフレームワークを別途用意すれば代替可能ですが。特に考えずともベンダに任せてしまえばいいというのは楽ですね。 「標準」であることのメリットは大きいです。あらゆる IDE が、あらゆるアプリケーションサーバが対応しています。ので、いわゆるベンダロックにかかるリスクが減ります。実際すでに運用しているアプリケーションを他社製のアプリケーションに載せ替えるような例も多く見たことがあります。 なんでもごりごり自分でやって、それを保守、サポートできる技術力があって、さらにそれを楽しめる要因が揃っているのであれば Spring とかはやりの DI コンテナをつかうのも良いかと思います。 最近は DI コンテナ派からアンチ EJB 的な声も良く聞こえますが、これだけ普及しているのはそれなりのわけがあるはずです。適用に向く場面、向かない場面は色々あるとおもいますのでじっくり勉強して見極めてください。 #EJB も DI コンテナもサポートしてるサーバってのもあります http://headlines.yahoo.co.jp/hl?a=20050810-00000093-myc-sci http://www.springframework.org/node/113 |
|
投稿日時: 2005-09-11 09:41
Anthyhimeさん インギさん 早速御回答ありがとうございます。
頂グローバルトランザクションもしくは分散オブジェクトが必要な場合、もしくはMWを変更する可能性があるようなケースにおいてEJBを使用すると低レベルな実装を意識しなくても良いというメリットがあるという事と理解させて頂きました。 ※認識が間違っていたらご指摘頂けると非常に助かります。 >最近は DI コンテナ派からアンチ EJB 的な声も良く聞こえますが、これだけ普及しているのはそれなりのわけがあるはずです。適用に向く場面、向かない場面は色々あるとおもいますのでじっくり勉強して見極めてください。 上記について、良ければご教示ください。 以前参加したプロジェクトでは上記いずれのケースにも当てはまっていませんでした。 アーキテクチャの設計者がプロジェクトを離れてしまっており、なぜあえてEJBを採用したのか設計の意図を確認できなかったのですが、実装を行った感想としてはEJBを使うためのコーディングのコストが高く、POJOで実装した方が実装、単体テストの自動化の面で楽だったと思っています。 パフォーマンスについては測定していない為なんとも言えません。 上記のようなケースでもEJBを採用するメリットはあるのでしょうか? また、POJOよりEJBを採用した方が開発コストの軽減につながる方法はあるのでしょうか? 個人的に一番気になっていのは単体テストの自動化はPOJOの方が楽なのではないか、という点です。 宜しくお願いします。 |
|
投稿日時: 2005-09-11 23:11
個人的にEJB(Session Bean)のメリットとして実感があるのは、
・トランザクション管理 ・RPC(Remote Procedure Call) の2点です。 DIコンテナ(と言うかAOPですかね)の登場で、トランザクション管理はEJBの 特権ではなくなりましたが、分散環境でのコンポーネントの再利用では やはりEJBも有効な選択肢になると思います。 (XMLベースのRPCとか色々あるでしょうが) とは言うものの、DIコンテナがある今、分散環境でなければEJBを選択する理由は 無いのかなぁとも思ってます。 (Message Driven Beanは利用価値があると思いますが) あと、テストが難しいのはEJBにロジックを書きすぎなのではないでしょうか。 ビジネスロジックはあくまでもPOJOとして実装し、EJBはそのPOJOに トランザクション管理やRPCを付与するためのシン・ラッパーとして使うのが 良いと思っています。 |
|
投稿日時: 2005-09-12 00:48
設計者の発想からすると・・・
Business Logic layer Persistency Layer というサーバー側に必要な2つのレイヤーがあります。 逆に言うと、しっかり分離させなければならない設計要件です。 これらをまとめてEJBと呼ぶことにしたわけです。 さらにその中で、 Business Logic layer -- SessionBean ---- Stateless ---- Statefull -- MessageDrivenBean Persistency layer -- EntityBean ---- CMP ---- BMP ---- (Hibernate) と、性質(ユースケース)に応じて定義を変えたものを用意したわけです。 このおかげで、一々ハイレベルな問題を毎回検討しなくて良くなりました! これが一番のメリットでしょうか。 ただし、なんでもかんでもJ2EEに合うわけではないので、まずJ2EEの設計仕様に合うのかどうかを検討することが大事だと思います。20%前後のチューニングがあって、8割はハイレベルの設計で適合したら楽ですね。 |
|
投稿日時: 2005-09-12 09:05
> 上記のようなケースでもEJBを採用するメリットはあるのでしょうか?
ないと思います。EJBは複雑なテクノロジです。十分な理解なしに利用すると逆に不具合を作りこむ可能性があります。 > また、POJOよりEJBを採用した方が開発コストの軽減につながる方法はあるのでしょうか? 分散や2層コミットを行いたい場合はEJBで作成するのがコストの削減につながると思います。 > 個人的に一番気になっていのは単体テストの自動化はPOJOの方が楽なのではないか、という点です。 そうですね。そうした環境であれば、特別な理由がない限りEJBを利用するメリットはないと思います。 ただし、これだけJ2EEがエンタープライズ分野で市場を支配できたのは、EJBのおかげです。 よりハイレベルな業務(金融、政府、軍事など)では分散、2層コミット、セキュリティなどが必須となります。 J2EEはこれらの要件をかなりの品質と生産性の高さで満たすことができます。 EJBが役に立たないという結論は間違いで、機能を適用する業務を選ぶということだけです。 |
|
投稿日時: 2005-09-12 19:25
皆様
今まで「コンポーネントの再利用」というぼんやりとしか見えてなかったものがだいぶ明確になりました。 御回答ありがとうございました。 |
1