EJBは終わってる

といいながら、DIが定着したときに知らず知らずのうちに使っている683でした、と。
ま、DIはそのくらいにならないと。

JBoss、EJB 3.0対応の「JBoss Application Server 4」などを発表
ttp://headlines.yahoo.co.jp/hl?a=20050622-00000007-cnet-sci

よし、JBossやろう

JBossは名前だダサいからやりたくない

EJBが煩雑な手順を踏まないと作れないからﾏﾝﾄﾞｸｻｲって意見が多いようだが
ロッドジョンソン氏の「without EJB」論にも在るようにEJBそのものの存在意義ってどうよ？
ちなみに俺はロッド派。EJBはいらん

まずEJBの分散オブジェクト機能以外はすべてAOPによってPOJOでも実現できる
（例えば分散トランザクションはJTA/JTSがあれば実現できる。EJBは必要ない）
で、ここで思うのが分散オブジェクトそのものの存在意義って何？
まぁ簡単に思い浮かぶのが、負荷分散、フェイルオーバー、リモート呼び出しあたりだが

１、負荷分散なんてWeb層から水平分散で問題なし。てかその方がキャパシティプランニングも楽。
２、フェイルオーバーなんてステートレスな設計にしておけばWeb層で面倒見きれる。
３、Webサービスでリモート呼び出しは実現できる。

一部の金融系とか、分散のコスト以上の膨大な処理をしなきゃならない領域以外に必要ないだろ

Webアプリは３層に分けるのが定石だなんてもう過去の話だ。と、受け売りを言ってみるテスト

確かにそのとおりだと思うけど
簡単に使えて分散オブジェクトも考慮されていれば尚良しということで
EJB3には期待したい

>>688
存在自体が間違いってのはどうかと思うけどね。
その存在がなければ、ロッドの「without EJB」論には至ってなかったろうし、ロッド自体がEJB的なものを作ってたかもしれない。
もしロッドが「without EJB」論をEJBが出現した時期に考えてたとしても、説得力のある実装は技術的に無理だし、賛同する人はいなかっただろう。

＞３、Webサービスでリモート呼び出しは実現できる。
ここだけはなんともいえんなぁ

上流的にはSOAによる分散システムの統合が主流になっていくのでEJBは廃れる可能性が高い。
下流ではEJB3.0で簡易化によってその流れに抵抗している。
SOAが主流になるまでに、EJB3.0の普及がどこまで進むかが勝負の分かれ目かな．．．

>689
分散オブジェクトとか、3層構造のシステムそのものがメリットに思えないんだよね

例えばDTOパターンとか、分散で在るがゆえにオブジェクトのシリアライズやネットワーク負荷を
考慮しなくちゃいけないって言うのは本末転倒な気がする
オブジェクト指向が至上の方法とまでは分からないが、少なくともDTOっていうのはその障害を
低減する為だけに存在する、ビジネス上でも意味のないフェイクオブジェクトだし

他にもサブシステムごと、機能ごとに分散しておけば障害発生時に影響範囲を抑えられるとか言うけど
一つが落ちたら、依存性の高い他の箇所だって結局影響出て通常稼動はし難い

って考えてくと、潔く
依存性の高い処理、ないし１システムは基本的に同一VM上に配備、システム間はWebサービスで連携
とした方が分かりやすいし、相互運用性と柔軟性のある作りになると思う
J2EE6.0のJBIもこんな思想から出てきている物だろうし

ちなみに>693の話だと
EJBは別に分散しなくてもローカルでも呼び出せるでしょボケ
EJB3はPOJOなんだよボケ
って意見があると思うけど
同一vm上で完結出来るなら、EJBコンテナの上でしか動かないEJBではなく
純粋なPOJO+AOPの方が可搬性に優れるって事なる

分散オブジェクトを「必須用件」として持ってしまっている事が
EJBをコンテナに縛り付けて、死に至らしめていると考える

(　´_ゝ`）ﾌｰﾝ

POJOでいいと思うんだけど、EJBのように
ベンダがサポートする "正規" の方法が必要と思う。
O/Rマッピング、トランザクションなどを考慮したもの。

>695
ｽﾏｿ、いっぱい書いてるけど興味ないなら流して。どうせ死にかけてたスレだし
意見を頂戴しつつ自分の考えも整理してる所
反論、異論、それでは甘いとご教授願えるならぜひ御願いします。

>696
Strutsがjavaの"正規"で無いにも関わらずこれだけ普及している事を考えると
必ずしもJ2EEコンテナベンダやツールベンダが正式にサポートしなければない事はないと思うんだが
今でこそどこのベンダもサポートしてるけど。

ただStrutsのように誰もが認めるデファクトスタンダードは必要かと思われ、だが
現時点でも Spring(+AspectJ or SpringAOP)、Hibernateの組み合わせは
十分な実力、事例、ドキュメント共にそろっていて、デファクトになりつつある
Apache族では無いが開発体制もわりとしっかりしている(っぽいし)
それぞれInterface21、Eclipse、JBossのバックアップもある(っぽいし)
O/Rマッピング、トランザクションを考慮したもの。って用件もバッチリ

Strutsはソース読むの簡単だからなぁ。
サポートなくてもそれほど心配ないんじゃない?
その点O/Rマッパはそれ自身だけ分かってれば良いわけではなく
問題が起こったときはJDBCドライバ、データベースとの切り分けも必要。
正式なサポートがある/なしが大きい意味を持つと思う。

EJB2.1まではベンダー実装による依存部分が大きくて
J2EE標準仕様なんて幻想だったけどEJB3はどうなんだろ。
ベンダーごとにデプロイメントディスクリプタの書式すら
全然異なるのが当たり前だったし。
まぁデプロイメントディスクリプタに関してはEJB3では
アノテーションが使えるからデプロイメントディスクリプタを
開発者が意識することは減りそうだけど。
J2EE仕様の策定をもちっときめ細かくしてくれれば
いくらEJBがコンテナ依存だといってもEJB3ではPOJOになることだし
ある程度可般性を維持できるはずなんだよね。
697の言う事はもっともだと思うけど
個人的にはSpring+Hibernateなどの過渡的な技術でなくて
J2EE標準仕様にもっとがんばってもらいたいなぁ。
あ、Spring+Hibernateが十分強力だってのは認めますよ。

>>699
HibernateはJBossのORマッピングエンジンなので、EJB3でもそのまま使われるよ。
Hibernate Annotationsは、ほとんどEJB3のアノテーションだしね。

>>698
確かに．．．
コマンドパターンの勉強にちょうどイイよね

この本の書評の投票にご協力ください
http://www.amazon.co.jp/exec/obidos/ASIN/4569620973/250-1090913-6566616

EJB3はJ2SEの上で動くようになる、という話は実現するの？

「EJB3のORマッピング部分は〜」という話だったはず。
HibernateはすでにJ2SEで動いてるわけで。

>>704おありがとうございます。

消防の漏れに理解できるレベルに噛み砕くと

「うちは分散なんてイラネ。だからTomcatとEJB3で組みました。」

こんな時代が間もなく到来する。こう考えていいの？

×「うちは分散なんてイラネ。だからTomcatとEJB3で組みました。」

○「うちは分散なんてイラネ。だからTomcatとEJB3ORMで組みました。」

>>705
すでになってるね。
Hibernate3+Hibernate Annotationがそんな感じ。
EJB3のORマッピング部分の仕様はほとんどHibernateだし、Hibernate Annotationsのアノテーションはほとんどjavax.persistence.*
つまりEJB3のアノテーション。

で、宣言的トランザクションが使いたければ、Springを使えばいい。
EJB3のコーディングのイメージは
http://j2ee.netbeans.org/NetBeans_EJB3.html
のデモを見ると、なんとなくわかる。めちゃくちゃ簡単そう。

うわ、すげぇ

persistence APIをHibernateが実装しているだけでしょ

EJB3をコンテナから誘い出して利用出来るのではなくて、あくまで Hibernate3が
EJB3としても動作するよう設計されているだけだと思われ

○「うちは分散なんてイラネ。だからTomcatと、EJBと同じpersistence APIを実装したHibernateで組みました。」

かと

>>710
EJB3のAPIを実装したらEJB3のORMじゃないの？

というか、コンテナから誘い出すっていうのがどういうことかよくわからん。

>711
ｽﾏｿ。早とちりしました。
persistence APIはORMのAPIを共通化しましょうって話だと認識してたんでこんがらがりました。

EJB3のCMT → persistence APIを実装したORM+分散オブジェクト
Hibernate3 → persistence APIを実装したORM

なんで「EJB3のORM = Hibernate3」って事ですね。
まぁイコールと言うとまた御幣がありそうなので「互換」が適切ですかね。

>712
EJBコンテナの外で利用する、に訂正します。どっかでそんな表現があって、カッコよかったんで真似しました。

とりあえず話整理すると、

EJB3によってPOJOでの開発が可能になった。生産性はDIコンテナと同等レベル
↓
分散オブジェクトが気に入らなければローカルEJBで作ればよろし
↓
J2EE標準、血統書付き
↓
EJB3マンセー？

懸念点
１、DIの設定はソースコードの中ではなく外（例えばXMLファイル等）に在るべきという意見。
２、EJBコンテナへの依存。これは分散オブジェクトをサポートする以上仕方ない？

って所でOK？
EJBのAnnotation APIと互換性のあるDIコンテナとか在ったら面白いかもね

>>714
DIの設定は外にあるべきというのが、中にあっても問題ないんじゃないの？になると思われ。
漏れには外にある必要性がわからん。
EJBコンテナの依存は、現実をみればSpringやSeasarを使えばそれらに依存するアプリになるから同じことだと思われ。

テスト用に設定をわけたいなら、テスト用にDIコンテナ使えばいいだけかと。
アプリはEJB3コンテナで動かして、テストはSpringなりSeasarでやる。
全体を見るために別ファイルにしたいのであれば、全体が見たいという要望が多ければ、全体が見れるツールが必ず現れる。

EJBは終わってないね

>>708
を見る限り終わってない気がする
NetBeans4.2がいつでてくるかだな
GUI作成もすげーし

EJBは終わってないというか、やっとこれから始まるって感じだな

くる〜、きっとくる〜〜〜♪

EJBを簡単に作れて使えるという点では、これまでもBEAのWorkshopで実現できてた。
JBuilder知らないけど、これもできるんじゃない?

生成されてるコードが少ないのがいいんだよ。

NetBeans4.1でEJB2なら生成できるし

元々EJBは（というかJava全般か。Beansの例もあるし）ツールでの作業が前提なんだよな
フリーのプロダクトはエディタでガリガリというのが多いが次期NetBeansのEJB対応を見る限り
ああいうのが今後のデフォなんだろうな

ツールでの作業が前提なんだけど、自分で書かないといけないコードも多かったんだよね。
生成したコード自体も複雑で、実際には生成したコードを見る必要があることもあって。

時期NBのEJB対応って、よくみると何もしてない。普通にクラスとメソッド追加しただけ。

.netのほういいね

>>725
そういう奴はEJB使うな。

おいおい
こんなスレに即レスするなよｗ

EJBが終わったら、その次は何が始まるんですか

灰の中からEJBが復活しまた始まる

画面連携とBMP連携の違いを誰か説明して！

最近EJBとJ2EE調べ始めたんだけど、
EJBってなんでMBean路線で
いかなかったんだろ。
(Beanにアダプタくっつけるやつ)
というかMBeanの拡張という形で
いかなかったんだろ。

ネットで調べても機能比較とかなくて
理由がわからない。
MBeanの書き方がめんどかったり
するのかな。

EJB3？

いや、JMXでしょ？