EJBは終わってる

EJBってパフォーマンスでないよな
それとも出る?
EJBに未来はないと思うが
否定派・賛成派共に語ってくれ

2ゲット？

>>1
どんなアプリケーションサーバー使ってるの?

>>3
JRUNっす

http://pc3.2ch.net/test/read.cgi/tech/1017240849/

アプリケーションサーバ固有の性能差ってそんなに大きいのだろうか
EJBの仕様そのものがラップの塊でオーバヘッドが大きいところに
JVMのインタープリタ実行というのが致命的なだけだと思うが
パッシベート・・笑っちゃうね
お前がメモリを無駄に使うからだろが！　JVM

>>4
JRUNのIIOPまわりのエンジンが遅いのではないでしょうか?
JRUN、どんなの使ってるのかな...
ちなみに Borland Enterprise Server だと、VisiBrokerを
使っているからとても速いんだけどね。

今 developer.java.sun.com につながりますか？

>>134
スタック取りすぎ。

>>7
でも全般的に速いとはいえないでしょ
AppServerちゃんたち

>>7
Borlandのサーバって開発ライセンスは無料じゃないの？

>>7
VisiBrokerでC/C++ CORBAできる人はEJBには見向きもしないと思われ

どうせみんな大した規模の開発してないんでしょ？
よほどの規模でない限りEJBのメリットなんてないし。（別に煽りじゃないよ）
J2EEでのサーバサイドJavaBeansとEJBの関係は、MSの技術でいうところの
COMとCOM+/MTSの関係と一緒だね。
大した規模でないならざわざわ複雑で高度なコンポーネント技術使う必要ないもんね。
兵隊の確保も難しいし。

うちの会社の他の部署の奴らがServlet+JavaBeans+JSPでWeb開発してて、
「EJBなんて必要ないよ。うちらのやってるパターン最強！」とかいってたから
試しにソース覗いてみたら、Beanコンストラクタの中でJDBCDriverをforNameして
コネクション張ってやがった。呆れるというより、「ああ、プーリングの概念を知らなくても
Webシステムって作れるんだなぁ」ってむしろ妙に感動しちゃったよ。

>>11
ライセンスが必要です。

>>12
RDBMSに接続するinterfaceに何使うの?

EJBの代わりになにを使うの？

ASP

>>13
WebLogicなら、DriverManager.getConnectionでもプール有効です。
PoolManでも、私の作成したドライバでも、DriverManager経由でマッピング
された別DBへのプーリングされたコネクションが返されます。

>>15
俺だったら
JNI + OracleだったらOCI8かな

>>13
よほどの規模でなくてもEJB使ってパフォーマンスでないのよ
どーすんのさ
煽り返しじゃないよ

>>13
貴方あまり現場の修羅場を知らないとみたが
管理系の人?

>>13
メリットはどうでもいいんすよ
パフォーマンスがあぼんなんすよ

>>14
サンキュー　ちなみにいくらぐらい?
スマン自分で調べるのだるい

>>16
COM CORBAブリッジとJNIとネイティブSQL API

>>20
EJBがパフォーマンスとのトレードオフというのは常識レベルだから、
スピードを何よりも重視する環境、ハイスペックなサーバを用意できない環境なら
そもそもEJBを選ぶこと自体に最初から問題がある。
システム要件定義と採用技術のアンマッチだな。
IIOPでネットワーク通信したり分散トランサクション管理したり、セキュリティチェック機構が
働いたりしてるんだから、速度とのトレードオフを見極めるのはEJB採用の際には必須。

>>21
バリバリの現役ですが何か？まぁ基盤系というかデプロイヤだけど。
「EJB使って修羅場」とかいってる現場を煽りスレで聞くが、おそらくそういうところは
EJBを使う使わない関係なく修羅場なんだよね、だいたいにおいて。
それを技術の責任に転嫁しているところは多いと思う。
だいたい、「EJBを使う」＝「大規模開発」なわけで、それにも関わらず
メソッドテンプレートや共通基盤、開発基盤といった環境をろくに整備もしないような
「小規模な短期Webプロジェクト」のノリで走り出しているプロジェクトも多いよ。
EJBを採用した大規模開発は、それこそメインフレーム開発と同じくらいの
覚悟で望まなきゃ。最初からある程度のリスクを追う覚悟がなければ
ミッションクリティカルなシステムは成功しないさ。

>>23
http://www.borland.co.jp/bes/bes1/sku.html より抜粋します

開発ライセンス（開発者／インストール単位）希望小売価格 \200,000
ちなみに...
Borland Enterprise Server AppServer Editionの開発ライセンスは、
JBuilder Ent版に同梱されています。

禿しくｽﾚ違いだけど、漏れはｱﾎﾟｰのWebObjects使ってるのね。
んで、こいつにはEOFっていうRDBｱｸｾｽするフレームワークがあんだけど、
これ使ったらEJBなんて不便で煩雑で使ってられなくなってしもた。
EJB使うのに、ｺﾞﾘｺﾞﾘ書かなきゃいけないような部分が予め提供されてて、
こっちはそれを使うだけ。

>>27
sunのやることは技術者思考(嗜好)なため、ユーザニーズと
乖離してることが多いね。

EJB対応の商用アプ鯖って、高額すぎるんだよね。
WOはEJB/J2EE対応もしてるけど、とりあえず\7ﾏｿちょいなので、そういう使い方もできるな。
ほんの数年前は、値段100倍だったのに。

>>25
真面目なデプロイ屋さんなんですね
EJB肯定派としての意見
ありがたく頂戴します

>>28
四マイクロのやることは、理想論ばかりで
いつもパフォーマンスを考えない

>>26
重ね重ねサンキュー
Ent版買えばテストオッケーね
ボーランドさんください!
フィルードテスト版でいいから
漏れに貸してくれればEnt用のEJBツール作るってあげるってば
だめっ?

>>13
600人月の仕事に着手しようとしているけど
ルートマネージャもJVMを信用していないぞ
この人は大規模開発の実績が多々ある
その人がJVMやEJBはあぼんしてる
もちろん漏れもあぼん
大量なDB操作には無理・仕様的に不可能・やめたほうが良い
時間の無駄・テスト時の待ち時間の無駄

だから
プラットフォーム毎のネイティブコンパイラ出してくれ
四マイクロはん

>>33
信用していない理由を書かないのに批判するな。
ルートマネージャがそう言ってるから？・・・頭悪いね。

GCJ使って、ネイティブコード出力ってできるんけ？

>>33
その JVM で大規模開発いくつもやりましたが何か?
てか、大規模ってなんだよ。3億以下なら笑うぞ。

３億以上使ってJava採用するクライアントも凄いな。

AS/400上でJVM稼働させる億単位の案件もあるだろ。
とりあえず俺もJVMは信用できねー。
アプ鯖自体がJVMで動いてたりするのも気に入らないが、
JVM監視のためにWatchDogをnative実装するのも、なんだか本末転倒な気がする。

>>34
なんでもかんでもJavaで組もうとスルヤシのほうが
よっぽど頭わりいと思うけどな

>>39
おまえが頭悪いのは分かったから

>>37
禿同
クライアントはJava厨SAにだまされているとしか
言いようがないなぁ

お客: 「どーも遅いんだけどねえ」
SE : 「JavaとEJBの仕様です。どもなりません」

>>42
そりゃしょうがない。EJBが遅いというのは事実は事実。
でも今時サーバサイドJavaが遅いなんていってると初心者扱いされちゃうぞ。

前にも書いているようにEJBを採用するなら最初からパフォーマンスは諦めろ。
パフォーマンスよりスケーラビリティを優先するようなシステムに使用すべき。
あとセキュリティとかトランザクションとかを気にしないシステムにEJB使うのは
あまり意味ないな。

> SE : 「JavaとEJBの仕様です。どもなりません」

このテのSEって、技術のせいにして、自らパフォーマンスを解決させようとする
自発性に欠けてるよね？逃げてるというか。俺の周りにもいるよ（ｗ
こういう現場に限って、外部の専門家が調べてみると、APサーバの設定値が全て
デフォルトでEJBコンテナやORBのカスタム設定してないとか、
SQLでインデックスかからないクエリー平気で流してるとかいうことがままある。

レスポンスに3分かかるEJBがあったから調査してみたらSQLでフルスキャン
してただけで、そこ直したら0.3秒になった･･･なんて話はけっこうみんなの周りにも
あるんじゃない？

>>43
だからさあ
Javaファミリが遅いのは漏れだって1995年から知ってるよ
遅いのを速くする気概のある椰子がJava鋳には皆無なのが悲しいのよ
で、解決方法でCORBA C/C++で生自作できる技術者がいないあなたの会社が
悲しいわけよ

> SE : 「JavaとEJBの仕様です。どもなりません」
だからさ、とにかくJava以外の実装でコンポーネント思考で
ミッションクリティカルで速けりゃいいんでしょ
それであなたの大好きなJavaから呼び出せれば万歳でしょ
もっとがんばってよ、新しい考え方とか出来ないのかな?
EJBの遅さ(これはあなたも認めている)については
分散Objectの内部インプリメントをJavaでやっている
ここをネイティブなコードにすれば多少は速くなるでしょう
それに分散EJB@Javaインプリメントがどんどん増えた時の事考えてよ
遅いのが積もれば動かない(とまったような)サービス提供になってしまうのでは?
分散で公開するんだから、将来的な再利用のための壮大なビジョンを含めての
設計思想を打ち出して欲しいのよ、優秀なる巨額な案件のSEさんならさあ

・・・・・・・・・・・・・・・・・・・・・
漏れはJavaだけで解決するのがどうだろうか?
って言っているわけよ
業界のために言っているつもりなんだけどね
頼むよ、優秀なるSEさん

>>44
1995 年から頭が進化していないの間違いだろ? な?
じつは Java あまり使ったことが無いだろ? な?
実に香ばしい匂いがするよ。優秀なる Sﾖ さん

>>44
>でも今時サーバサイドJavaが遅いなんていってると初心者扱いされちゃうぞ。
って書いてあるのに
>Javaファミリが遅いのは漏れだって1995年から知ってるよ
って。お前どうせJavaでAppletくらいしか作ったことないだろ？

Javaオンリーのソリューションに懐疑的（これは俺も同意だが）、
ネイティブコードﾏﾝｾｰ、CORBAの話を持ち出してくるといったあたりから察するに
死滅寸前のCORBA C/C++に従事していた人なのかな？
CORBAが流行らずにEJBが流行った理由を説明してほしいな。
VisiBrokerもOrbixもTOBrokerも、みんなAPサーバになっちゃったよね？

ところでキミはSOAPについてどう思ってる？
ApacheではXindiceとかが最近急にIIOPを破棄してSOAPにリプレースしてるけど、
EJBで遅いといってるならWebServiceはどうなるのかな？

正直言って新しい技術が古い技術より遅いのは当たり前。

>>47
ハードウェア技術者がいくらがんばってもソフトウェア技術者がそれをダメにする。

ムーアの逆定理。

Javaが遅いって今時そんなこと言ってるのは、脳みそがふるすぎです。
HotSpotVMの発想は、進化すればCコンパイラがはく静的なバイナリより
早くなるチャンスがある。現状でもまあまあいい線いっている。

Javaで性能が問題になるのは、JVMとOSとのインターフェイスの部分だ
よね。ネイティブべったりで高速化する手段をとることができないため
に性能が上がらないのは問題になってる。グラフィックスその他でｲﾛｲﾛ
APIと、各OS用ランタイムを作りまくって解決しようとしてるから、その
うちなんとかなるとおもうけど、まだちょっとつらいみたい。
クライアントサイドのUI部分についてはﾓｳｼﾊﾞﾗｸ待つしかないのかも。

バックエンドプロセスでボトルネックになるのは、サーバが分散してい
る時のサーバー間リクエスト交換の作業でそ。EJBってのは、リモート
に置かれたサーバプロセスのようなものなんだから、扱い間違えれば遅
いにきまってる。C/C++でCORBAつかったって同じでしょ。

（もう何世代かCPUが進化しないと）EJBを使うのは難しい。

SessionFacade
DataAccessObject
ValueObject

このへんのJ2EEパターンを盛り込んでいなければ、遅いのは当たり前。
このへんのパターンを留意しなきゃいけないのは、CORBAつかっても同じ。

EJBいっぱい作って1トランザクションでクライアントから総なめコール
やってる馬鹿は、とっとと引退しろ。そういう低レベルなセンス（パタ
ーンなんぞしらんでも、内部的な仕組みが分かっていればどうなるかは
容易に予想がつくはず）で、分散システム開発は無理です。

速いのを目指すのはハードの仕事。ソフトは便利を目指すべき。

サーバーが分散するようなシステムで、実行性能を実行時に解析して
その結果によってスレッドの配置を動的に決定できるような仕組みが
できて、J2EEパターンのようなことをアプリケーション開発者が気に
しないでよくなるようになったら、いいなあ。

----　常識では考えられないことをする会社、その名はＳ○ＮＹ　----

先日、Ｓ○ＮＹの製品を購入した
入っているはずの部品が一部欠品していた
電話を掛けてクレームを付けた所、宅配便で送ってくれると言う
すると、その部品を料金着払いで送って来やがった
うーむ、入ってなかったから、クレーム付けて送らせたのに
それを着払いで送ってくるとは・・・
全くもって何を考えているのやら

「着払い」は受取人が「聞いてません、発送者の勝手な行動です」と
言えば払わなくて済むのに。


---- 常識で考えられることをできない>>431。その名は名無○さん ----

>>52がいいこといった！・・・ような気がする。

ちなみに俺は必ずしもEJBﾏﾝｾｰではないよ。
ただDCOM/COM+、CORBA、EJBと分散オブジェクト技術を一通りやってきて、
今はEJBやってるってだけ。（なのでCORBAを否定するつもりはない）

SQLチューニングもそうだけど、パターンも重要だよね。
EJBが内部的にRMIしてるってのを知らないヤツが、プロパティベースで
ネットワーク上に分散しているオブジェクト同士を通信させたりしてるのを見ると
ちょっと引く。getXXXX、setXXXXの１つ１つがネットワーク経由でSerializeされて
通信しているということが分からないんだよ。

てゆうかうちの会社、プロパティというある意味古典的オブジェクト指向の概念が
そのまま分散オブジェクトの世界でも通用すると思ってる人が多いんだよね。
で、ValueObjectとかStatelessなクラスといった概念に対しては
「オブジェクティブな発想じゃない」とかいって聞く耳持たなかったり。

>>56
実行時性能と、OO的発想（と、それがもたらす管理の容易さ）は、
システムの要求できまってくる天秤の両端ですよね。
VOとかは、純粋なOO的にはアホですが、分散OOのRMI実装の方法
としては「やらないと遅くなるからしかたなく」ですね。

きく耳持たないSEなんてのは、SEじゃなくて単なるアホOOオタク
です。

>>44 が起爆剤になって良スレ化しとる…

EJBのみでなく分散オブジェクトを総括した流れになってきているかな？

>>56
ValueObjectがおかしいと言い出すアホには、
「GoFのProxyパターンでEJBプロキシを作りましょう」といって、
回避することが可能かも。
VOじゃなくて、ローカルにEJBのキャッシュを置くという発想なら、
アホにも理解できるんちゃう？コミットしたら纏めてリモートEJB
と同期するとかすればええ。IBMのDeveloperWorksの日本語Art
icleで「遊離クローンEJB」と題打ってでｵｽｽﾒしてるよ。

ところで、もうじき、同一筐体内でのコールは同一JVM上で可能になるのでは？

>>61
EJB2.3のローカルインターフェイスですね。RMI経由でのサーバアクセス
を回避するです。仕様で可能になっても、APサバが対応しないと使えません。

Weblogicあたりなら、もうつかえるかも。

>>62
へぇ？そんな計画があるんだ？勉強不足ゆえ知らんかった。
まぁ今でもローカルならGIOPにするとか工夫してるんじゃなかったっけ？

>>57
妙案！！

>>63
GIOPが何なのか知らないみたいだね。言いたい事は推測できるけど。

ローカルEJBコールの時にマーシャリングを回避するためのオプションはある。
まぁ非標準だし、注意しなければならない事もあるから、標準化しようって事じゃない？

ここの住人って遅れてない？

EJB2.1のLocal Interfaceならもう当たり前のことですが?

すんまそん厨房ですが
>>65
2.1をサポートしている主流どこのアプリケーションサーバって
どのくらいあるのですか(安定運用できるものに限る)

>>皆様
CORBAって死滅したのですか
CORBA単体でサービスを上げる製品は無くなったのですか
(VisiBrokerなど)

ローカルインタフェースってEJB 2.0じゃなかったっけ。
Weblogicのサポートについては、

http://www.beasys.co.jp/e-docs/wls/docs70/ejb/cmp.html#1116678

こんな感じですね。

今までだとEJB使うにしてもSession Bean + DAO(JDBC)って構成がよく
採用されていたけど、Session Bean ＋ Entity Bean（ローカルインタフェース）
って構成も普通にできるようになりそうですね。

>>66
CORBAは分散オブジェクト環境の基盤技術になりつつありますね。
EJBもRMI/IIOPサポート必須だし、アプリケーションサーバもCORBA
ベースのものが結構あります。

単体でのCORBAはOrbix、Visibrokerが2大勢力ですがレガシーシステムを
ラッピングする以外では直接使われなくなるんじゃないでしょうか。

Javaってプロトタイピングにしか使わないっしょ。

向河原辺りのＮが紛れ込んでるな。

>>69
プロトタイプだったらもっとちょろい言語があると思うが・・・・

4219行のJVM
ttp://homepage2.nifty.com/rohizuka/ka/pa_003_a.htm

>>72
どこかで見た URL だな
多分人形の悲鳴だと思うが。

SOAP、UDDI、WDSL関係は、ｺｺと絡むのかなあ･･･
JMSってSOAPサポートしてたよねえ？

言うだけでテストしないのもなんなんで
VisiBroker 3.3.2 CORBA C++の動作テストしてます
CBuilderでビルドしたものはなるほど簡単に動く
接続のオーバヘッドもなくレスポンスも良いですね
当たり前でしょうがこのバージョンのlibをVC++7.0ではライブラリの互換性
がなくリンクできませんでした。(CBilderの付属ですから当然です)
ちょいと利用した感触では、EJBはデプロイも大騒ぎでめんどくさい
その割にはパフォーマンス最低

これも言うだけではなんですから
少し時間をくれれば
SQL からめたコードで EJB vs CORBA(C++)の対決で
たとえば10万件程度のデータ操作のベンチ公開します

ベンチの確認前ですが
漏れはCORBA +(JNI) <->ブリッジ自作<-> COM(COM+)で逝くことに決めました
これにSQL APIを利用できるようにしてトランザクション管理と
セッション管理を独自インプリメントすればEJBを利用しなくとも
いけそうです。

>>75
EJB（というかRMIサーバ）とCORBAサーバでどういうコード動かしてる
かによるじゃん、そんなの。
あと、EJBのデプロイって面倒か？どんなAPｻﾊﾞつかってるの？
デプロイ記述は、静的にコード内部で書いていたプロパティ設定を、
動的変更可能なようにパラメータ化して外部リソースに移しただけ
のはずだが。

>これにSQL APIを利用できるようにしてトランザクション管理と
>セッション管理を独自インプリメントすればEJBを利用しなくとも
>いけそうです。
そういうのをAPIｻﾊﾞに任せて手抜きする為に存在するのがEJBの枠組み
じゃないのか？
全部そのプロジェクト専用にチューニングしたライブラリ自作したら早い
にきまってる。それに費やされるコストとの比較で単に手段を選択する
だけでそ。

全部自作したがるPGオタ馬鹿ってどこにでもいるけど、それにどういう
意味があるのか一歩引いて考えてから方針決めてるのか？

そもそもCORBAって何で流行らずに廃れたんだろうね？
速度はEJBより速いらしいし、言語非依存だし、規格自体はベンダ中立だし。
これが流行ってればそもそも（CORBAのサブセットである）EJBが普及する必然もなかったのにね？
VisiBrokerもOrbixもすっかりJ2EEサーバ化しちゃって、CCM対応を初めとするORB単体としての
バージョンアップは考えてないみたいだから。
商用ORBが無くなる時点でCORBAが復活する見込みはなくなるね。

CORBAが現に流行ってないってことは速度というメリットを打ち消すくらいの致命的なデメリットが
あったということなんでしょ？

別に煽りじゃなくって、昔CORBAをやってた者の素朴な疑問なんです。
ベンチ出されたからって、それだけじゃあEJBとCORBAの優劣にはあまり関係ない。

そもそもEJBとのベンチ取るなら、最低でも
ネーミング・サービス、オブジェクト・トランザクション・サービス、セキュリティ・サービスくらいは
経由してもらわないと比較にならないと思うんだけど、これらのサービスは使ったの？
できればEJBコンテナが機能として実装しているイベント・サービス、ライフサイクル・サービス、
エクターナリザーション・サービス、パーシステント・ステート・サービスもかましてくれると
ベストだけど。

>>77に補足するなら、
ネーミング・サービス　・・・　J2EEのJNDIに相当
オブジェクト・トランザクション・サービス　・・・　J2EEのJTS/JTAに相当
セキュリティ・サービス　・・・　分からないけどEJBコンテナにはある機能
イベント・サービス　・・・　J2EEのJMSに相当
ライフサイクル・サービス　・・・　EJBコンテナが実装する機能
エクターナリザーション・サービス　・・・　スマンこのサービス知らない
パーシステント・ステート・サービス　・・・　EJBコンテナが実装する機能
かな？よく分からないけど。

>>77
仕様決定プロセスが遅すぎ。需要があるのにきまらないと、
簡単実装でデファクトスタンダード化したものにプロトコル
全体を乗っ取られるという歴史は、昔からくり返されてます
の。

>>77
CORBAの黎明期に使っていた立場からすると、やっぱりコーディングの
ややこしさが一番でしょう。各種オブジェクトサービスにしても結局自分で
設計・コーディングしなきゃならないわけで、そのようなサービスをコンテナが
提供してくれるEJBの簡略さに比べると、やはり敷居の高さは感じます。
CCMもちょっと遅かったかもしれませんね。

でも、CORBAはインフラ技術として残っていくでしょう。ソケットプログラミング
する機会が減ったからといってTCP/IPが消えたなんて誰も言わないし:-)

>>80
誰も言わないどころか見当違いも甚だしいと思うが。
例えが悪すぎ。

>>13=>>25=>>43=>>46=>>56=>>77です。（書きすぎか？）

>>80
Uさんじゃないですか？CORBAスレでもお会いしてますね。
CORBAは俺も黎明期に使ってたので、知らない間に廃れてしまってﾋﾞｸｰﾘしたよ。
J2EEやWindowsDNAみたいなWebサイト構築と技術的に直結してないのが原因かなぁ？
とかいろいろ考えてたんだけど、正直今でもよく分からない。
思うに、J2EEのような参考実装の提供がなかったから、結局CORBAサービスの実装も
ベンダ任せになってしまって、ORB間の互換性がなくなったというところも一因のような気がする。
以上、EJBと関係ないので終了

結局、EJBへの不満って「遅い」以外に出てきてないんだよね？今のところ。
俺はデバッグのし難さや、開発ノウハウの蓄積不足がけっこう気になるところなんだけどね。
ここら辺が解決しないと、EJBが第二のCORBAになる可能性も正直あると思う。

>>82
>デバッグのし難さ
どこらへんが難しいの?

>>82
http://www.microsoft.com/japan/msdn/columns/xml.asp
>たとえば、DCE (分散コンピューティング環境) や
>CORBA は実装するのに何年もかかり、
>たった 2、3 の実装しかリリースされませんでした

>>83
ネットワーク上にコンポーネントが分散化されているからじゃない？

>>77
それは認識が違うと思う。COMは仕様である、CORBAも仕様である
基礎技術としての仕様は廃れることがない
OMGはCORBAベンダの縛りをかけなかったのが敗因だ
>>82さんがいっているORBの互換性がなくなった
COMは、各プラットフォームでの責任会社を1社に限定して
進めた、OMGはベンダに任せた
また、OMGを攻めているわけではなくてフラットな関係の中
各社独自色を高めてEJBに至ったわけ
>>80さんも言っているが、敷居が高い、難解なCORBA
優秀なIDEツールがなかった、または現状にそぐわなかった
VC++でCOM作るときは、idlも含めてプロジェクトで完全管理できるし
Wizardでスケルトンがすぐに作れた。CORBAにはこの環境がなかった
ただでさえ難しい分散コンポーネントに着手する人間を上記環境が
拒否し続けた
77さんのように短絡的に
「もうCORBAは終わり」の発想はおかしいと思う
J2EEサーバの低位層でCORBAの仕様は生きているわけだし
EJBのネーミングサービスなんかもみなCORBAのbaseを利用
しているわけでしょう
（煽りじゃないです意見交換です誤解なきよう）
あなたの意見だと、WindowsXPになったから、WindowsNT 3.51は
意味が無いと言っているように聞こえます
資産としてのカーネルソースはNT3.51あたりノcoreなやつがXPでも生き続けている
わけでしょう。あなたの考えだとまるで目先のJavaにしか思考が回らない
ように見えるけど。そういう人が多いのがJava鋳の特徴でもあるのだけど。

その他
lookup関連のサービス関係については、宿題とする

>その他
>lookup関連のサービス関係については、宿題とする

Jiniでちゅか？とうとう日の目を見る日がきたのでちゅね？ﾜｰｲ。

>>86
長文サンクス。いつものCORBA派の人かな？

>「もうCORBAは終わり」の発想はおかしいと思う

別に人によって捕らえ方は様々だと思うからあまり反論するつもりないんだけど、
少なくともCORBA 3.0が勧告されているのに対応する商用製品がない、またはかつての
ORBベンダに無視されているような現状では、やはり「終わり」だと思うよ。
2.3がもはや進化の必要がないほど完璧だというのなら話も分かるんだけどさ。
（俺はCCMにかなり興味あるんだけど、これも黙殺だし）

ただしつこいようだが俺はCORBAやってた人間だし、真っ向から批判するつもりはないよ。
ただこのスレがEJBの普及について語る場である以上、CORBAというある意味普及に失敗した
技術について語ることで、それを反面教師としてEJBにその教訓を生かす必要があると思うわけよ。

>あなたの考えだとまるで目先のJavaにしか思考が回らない
>ように見えるけど。そういう人が多いのがJava鋳の特徴でもあるのだけど。

ある意味それはCORBAがDCOMと戦っていた時代に辿ってきたのと同じ道じゃないかい？
CORBAも当時は目先のことばかり考えていたと思うけど、どうよ？
（俺の主観だけどね。COBOLとのマッピングを目指した方向性は間違っていないと思う）
分散オブジェクトは最も進化の激しい分野に１つだから、ある程度は仕方ないと思うさ。
ただ俺は別にJavaマンセーではないので、Javaが他言語（特にネイティブなC/C++）との
インターフェイスが取りづらい、ある意味閉鎖的な世界だというのは分かる。

眠いのでワケワカランこと書いているかもしれないが、こんなところ。

過剰な期待から先走って実装したりなんて話はもう大昔のことのような
気もするCORBAだけど、IT革命(死後)を推進するキーワードとしての
役目が終わったということなんじゃないの？
インフラ的な技術としてはある程度定着したんじゃないかなあ。
GnomeやBerlinなどがCORBAを使っているのをみると、
通信方式としてのCORBAは依然有用だと思うね。
仕様があれば、それを共通認識としてソフトウェアを作ることができる。
個別に一からOMGの仕様に相当する部分を決めなくてはならないのは
大きな手間だし、ひどく無駄なこと。

仕様だけあれば決してなくなることはないし、いくつかまだ製品も出ている
以上、終わったとか終わってないとか言うこと自体、マーケティング用語に
影響されている証拠だと思うけど。
もちろん流行り廃りだけで採用技術を選択しているようなエンジニアにとっては
事例の少なさ故に、より手を出しずらいものとなっていくことに異論はないけどね。
おれも大した技術なんて持ち合わせてないので、これからCORBAを採用することは
まずないとは思うが、それはまた別の話だよ。

CORBAかEJBかなんて話よりもWebServiceどうなるんだろう？ってなら分るよ。
送信データにテキストを用いて、タイプシステムフリーにするっていう発想は
インパクトあるもの（あんまりよく分かってないので間違っているだろう。藁
そもときはごめんなさい）。それにこれからの技術でもあるし。
終わった終わらないよりも、これからの技術が来るのか来ないのかの
方がまだいくらか有益だと思うね。

>（俺はCCMにかなり興味あるんだけど、これも黙殺だし）
すみませんが、CCMについてはペン今日不足でよく尻ません。逆にCCMについて提言して
いただけませんか。そしてそこから話を進める方向ではいけませんか？
>ある意味それはCORBAがDCOMと戦っていた時代に辿ってきたのと同じ道じゃないかい？
同意
このあたりは、NC, IEでの覇権争いと同等のイニシァティブの取り合いがもたらした
醜さで、我々にはどうしようもない部分でもある。
>CORBAも当時は目先のことばかり考えていたと思うけど、どうよ？
>（俺の主観だけどね。COBOLとのマッピングを目指した方向性は間違っていないと思う）
>分散オブ...
CORBAもCOMも生産的再利用を行うといった思想レベルの世界観は同一ですよね
COMの言語に依存しないが、.NETプラットフォームに反映されていますし
CORBAもしかりなわけですよね。突き詰めると、アプリケーションサーバ技術の
パックグラウンドを構成しているのは「分散コンポーネント技術」で決まるわけです。
>C/C++のインターフェイスが取りづらい、ある意味閉鎖的な世界だというのは分かる。
これは、そうでもないと思いますよ。
Sunの公式ドキュメントでも、あるケースではJNIを使うのは推奨はしてませんけど
特定なケースではJNIをやる事で既存C/C++コードが再利用できて効果が出ると言っ
ています。
　Sunの公認試験を取って先生遣ってる人達が、Write onece run anywhrerばかり呪文の
　ように言い続けて皆さん刷り込まれてしまったんだと思います。
　ようは、実装用に選定する言語でもなんでもケースバイケースで柔軟な発想を
　していきたい漏れです。
いっそのこと
有志で　仮称Japonica COMBA projectをオープンソースで立ち上げません？
日本で開発された世界標準の分散コンポーネント用ORB COMとの融合をシームレスに
行う。プラットフォームは POSIXとWin32をとりあえずサポートするのを目標にする。
なんてあたりで
もちろんEJBサイドの人にも参加してもらってJ2EE EJBと同等の機能を高速かつJavaから
実装可能なサービスとして持っていく。
って>>89レスサンクス今日は眠いのでレスは後日で勘弁してください

こんな良スレになっちまって >>1 も草葉の陰で喜んでおろう

俺もここは死滅スレだと思ってたよ（ｗ
てっきり.NET派のやつらが煽りにくるスレかと（ｗ
CCMはMICO-CCMでちょっとやった程度なのでアレだが、コンポーネント化という
方向性はいいと思う。機能もEJBより豊富だし。
取っ掛かりとしてはここかな？
http://www.ogis-ri.co.jp/otc/hiroba/technical/CCM/step1/index.html
とはいうもののここはCORBAスレではないので、これ以上話をするのも正直どうかな？
そろそろEJBの話に戻そうぜ！

EJBって、市場に流通させようとしているEJBコンポーネントが本格的すぎるよね？
財務会計とか。小規模なWebシステムでは再利用する必要もないようなものばかりじゃない？
もっとお手軽で汎用的な目的のEJBコンポーネントがフリーウエアか安価なシェアウエアで
出回れば面白いかもって思うんだけど。営業日演算EJBとか。
あ、でもそういうのは別にEJBである必要もないのか？JavaBeansで十分？

>>93
> あ、でもそういうのは別にEJBである必要もないのか？JavaBeansで十分？

そっすね。

結局さSunの高いハードを買わせるための技術なんだよ。
開発効率を20%上げるために二倍速い(5倍高い)ハードを買ってください、
となるんじゃない？ｗ
パソコン文化とはちょっと違うのさ。

>あ、でもそういうのは別にEJBである必要もないのか？JavaBeansで十分？
Sunに言わせれば、そういうところでもEJBを使ってくださいと
なるんじゃないの？

データサービス層やEIS層にアクセスしないEJBって存在価値あるのか？

みなさん
どうも長文の漏れです
しばらく休んでしまって申し訳ない
今、最新の環境を入手中です
EJB, CORBA, COMを含めて(宿題もありますね)
総合的なネタを興すための準備中です
いましばらくお待ちください

J2EE 1.4βあげ

最近のAPIは1.4用ばっかで
今のWebSphereV4じゃ使えんよ

>>100
1.3の勘違い？
ちなみにJ2EE1.3対応のWebSphereV5がやっとでたね。

やっと
Borland Enterprise Serverを入手しました
BisiBroker 4.5です
C++ Corbaの実装と、Java EJBの実装ができる環境です
しかし、Corbaの資料のないこと・・
英文マニュアルと付き合わないとだめですね

>>102
VisiBrokerですよね。
しかもVisiBroker4.5ということは、Borland Enterprise Server ではなく、
随分以前の Borland AppServer4.5 の間違いでは?

また、Borland Enterprise Server であれば、installディレクトリに
CORBAのプログラミングに関するpdfがあると思います。

>>103
亀レスですんません
テスト用を前提に
App Server
Enterprise Server
もろもろ全てお借りしますた

>また、Borland Enterprise Server であれば、installディレクトリに
>CORBAのプログラミングに関するpdfがあると思います。
情報ありがとうございます。除いてみます。

OMGにも出向いたのですが
ORBをインプリメントする資料は、やはりOMGにある仕様書しか
ないものでしょうか？無謀にもORBを自作したい希望があります。

ところで、いまさらながら.NETの XML, ATLサービスは凄いですね。
速い！ 勿論C++でのプロジェクト作成に限りますけど。

>>89
Gnomeは落ち目、Fresco/Berlinもブレークする気配が全くない。
というところで「CORBAは現役だ!」って言われても困ってしまいます。
どちらもCORBAなんか使うから人が逃げちゃうんだ、って言われてるし...。

お題目は悪くないんだけどね。使うと（使えれば）便利は便利だし。
しかし、OMG に標準化をさせると重厚長大になっていかんね。

age

Session Facadeパターンで
Session Bean ＋ Entity Bean（ローカルインタフェース）のメリットは
なんとなく分かるのだけど、Session Bean + DAO(JDBC)との違いって何？

Entity BeanだとJTS利用で、分散DBにトランザクション切れるとか、
J2EEレベルでのセキュリティフレームワークが使える
(でも、セキュリティフレームワークもSession Beanで使えれば
それでいいのかも)とかはなんとなく分かるんだけど。

パフォーマンスが悪いのはまぁ仕方がないとしても、
SQLでいうところの、UPDATE table SET hoge = 10 WHERE foo > 50
みたいなことをEntity Beanでやろうとすると、Beanインスタンスが大量に
生成されたりして大変じゃない？
Beanのライフサイクルを追いかけてみると、実のところ発行する
SQL Query数も結構多ようだし。
こんなところは、EJB QLとかで改善されるのかしら？

それとも、漏れがDQNなだけ？

お前等髪ちゃんと洗ってる？
服装もダサそうだね。
わけわからんよれよれジーンズに穴のあいた靴下。
そして、何日も着て汚れきったシャツをジーンズにタックイン。
周りの人間に馬鹿にされてるよ？

>>108
そのとおりだけど、いっていることはただの一般論。

ちなみに、UPDATE table SET hoge = 10 WHERE foo > 50
程度なら、EJB2.0のEJB QL(Homeメソッド）を使えば、
Beanインスタンスが生成されることはない。

＞ジーンズにタックイン

愛読書は FINE BOYS でつか？

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

記念カキコ(ﾟ∀ﾟ)

２チャンネルに殺人予告

　
　なにをいまさら。通知実験の方はまだ？

悪いこと書かないから関係ないよ

>>342
(・∀・)ｲｲ!!

>>806
名前や住所が表示される訳じゃないし。

IP記録で今までのようにカキコできない香具師はいくじなし

＞（電波）

ってのは受信したよってことすか、、？

>>129
そうそう。なんでも今年の風邪は高熱が出るらしくて。
って手遅れかい。まぁ再発に気をつけろってことで。

JNBなら100円送金するぞ(w

4th 120,682件
http://www.infoseek.co.jp/Titles?sv=JP&lk=noframes&rt=JG&svx=500&qt=4th
4nd 408件
http://www.infoseek.co.jp/Titles?sv=JP&lk=noframes&rt=JG&svx=500&qt=4nd

和製英語にでも登録するか(笑

正論が必ずしも正解であるとは限らない。


ンな事よりWin板やソフト板のアレを何とかしてくれ。

>>573
2chに個人情報の保護をお願いする方が間違ってると思われ
事実上IPは誰にも見れる様になるだろうね、まあその中でプロパイダの中に協力者がいる
のはごく一部だろうが、、、

自分が必要だと思っていることは、他人も必要としている場合が多い。

いらない板ＢＥＳＴ３

1　ハングル

2　半角（ピンクは全部いらん）

3　ラウンジ

>>ひろゆき

何日ぐらいログ保存するの？
　

ネタ書くのにも気を遣うようになっちゃうね

ｶｷｺ以前に窃盗で捕まる罠

いわゆる糞スレは減らないよな

むしろヤバいスレやレスをつけられなくなった連中の鬱屈した欲求が
さらなる糞スレ乱立に結びつきかねない。

外国で運用した場合は？
その国の法律には従う必要あるが、匿名の許容度が日本よりゆるければ
今のシステムのままでももっと匿名度の高いものが出来るのでは？
いくらなんでも北鮮やイスラム圏じゃないから外国へ繋ぐのが違法だとは出来ないと思いますが。

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

ひろゆきなんて嫌いだ！たらこ唇！

んじゃ、２ちゃんねら有志が出資して
ひろゆきにSPつけるか。(w
これで暴力問題は解決っと。

ていうか、２ちゃんねるに不都合な？スレはすべて
この騒ぎに便乗してスレストかかってるぞ。

vip
http://qb.2ch.net/test/read.cgi/accuse/1042162651/
ﾌﾟﾛ固定用密談ｽﾚ
http://qb.2ch.net/test/read.cgi/accuse/1040784691/
管理人のゆきひろてやつに文句あんだけど
http://qb.2ch.net/test/read.cgi/accuse/1042063528/
　　　　　ひろゆきの収入源は？　　　　　
http://qb.2ch.net/test/read.cgi/accuse/1040821353/
断固として２ｃｈとひろゆきを支持する（＠ｗ荒
http://qb.2ch.net/test/read.cgi/accuse/1040814322/

復活してちょっとうれしい今日の漏れ

漏らすバカが出るだろうというのが一番の問題なんだよ

ごめん、なんで「それを言うなら」になるのかがわからん(^_^;)
後半の批判は批判でいいと思うんだけど、書き込む人間の自己責任ってのとどう関係してるの？

http://wow.bbspink.com/test/read.cgi/feti/1039253916/

の522からなんか出てるんですけど
2ｃｈってこんなに変わるの？

レスありがとう。
俺素人だからよくわからないが
アク禁にしないのは何か理由るのかな・・？

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

1chに関してだけど。
トップダウンによるキャッチアップは効果的だとは
思うが、所詮真似事だからどこかに歪みが出て
来そうなんだよね。

ちくり裏事情なんかは、WINNY掲示板みたいなWINNY型P2Pにして、
２ちゃんからリンクして拾ってくるようにできんかな？

zD2HIsxl
厨房逝ってよし。

なんか各所で「ブラウザを立ち上げ直してください」とかいうエラーでて書き込めないって
人がいるけど、それって何をするとでるの？
俺は見たこと無い。

掲示板の書き込みを鵜呑みにするやつはもっと悲惨だよ

（＾＾）

（＾＾）

3億以上使ってJava採用するクライアントも凄いな。

今度2,30年使えるシステムという勘定なんだろうけど、
Sunが潰れたりしないだろうか。Javaより先に死んで
しまいそうなんだけど。サポートのなくなったSunにどれだけの
価値があるのかね。

Sunは潰れる前にIBMに買収されるだろ。

このスレは終わってる

保守あげ

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

EJBってリモート前提で、ネットワーク介すから、遅いのは当然。

アホ雑誌とかの、「コンポーネント(部品化)＝ＥＪＢ」を丸呑み
して、使いまわすためには、ＥＪＢ化が必要と勘違いする
香具師が多い。

実行速度より、生産性低下の弊害の方が深刻。

標準でも物理サーバごとに配布すれば、共有可能。むしろ
ほとんどの場合その方が望ましい。分散処理において初めて
ＥＪＢが必要になる。

「部品化」、「コンポーネント」、「分散処理」などの
用語の定義を明確にせずに、「コンポーネント(部品化)＝ＥＪＢ」
という宣伝は非常に危険。

現在のＥＪＢの使用範囲はイントラ内の分散処理に限定。インターネット
はＳＯＡＰの守備範囲。

test

ハァ？EJBは万能ですよ？

PostgreSQL で EJB できますか?

>>157

EJB2.0はリモートじゃなくても使えるぞ。
ＥＪＢの強みであるコンテナがトランザクションを管理するというのを忘れてないか。

俺はたいていのものはＥＪＢでトランザクション管理を行って作っているが、生産性
低下はしていない。

イントラ内というのは、その通りだがもとからそのつもりのはずだ。EJBの呼び出し
をインターネット上で行うのというのは普通想定しないだろう。

ちゃんと、EJBの勉強してから書かないと恥かくぞ。

>>159
万能はさすがに言い過ぎじゃないか？

>>160

Webで検索すると、JBoss+PostgreSQLのことが書いてあるページがあるから、でき
るんじゃないの？

このスレの内容は、大体2年くらい前に議論した覚えがある。Too Late

>>160
OracleでできてPostgreSQLでできねーわけないだろ

>>163
Oracle8/9i AS ならEJBサポートしてるけど。PostgreSQLとは分野違いだね。
Oracle9i DBには、EJBのサポートあるの？
>>160
PostgreSQL＋JBOSSならできそうだけど

>>163

Oracleの話しはしたつもりないんだけど。

>>164

DBでEJBのサポートとはどういう意味？

ん？EJBのPersistent ServiceやTransaction Service周りは、
Oracle8iDB自体で多少サポートしていたかなー、とうろ覚えの記憶で書きました。

>>160 つか、キミのいうPostgreSQLでEJBするってどういう意味？ネタ師？

や は り ネ タ 師 だ っ た か

　　　　　 へﾍ
　　　　 /〃⌒⌒ヽ
　　 　 〈〈 ノﾉﾉﾊ)）) ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 |ヽ|| ´∀｀||＜　先生！こんなのがありました！
　 　 ＿φ╂∨⊂)__ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　 ／旦／三／ ／|
　|￣￣￣￣￣|　 |＜ http://freeweb2.kakiko.com/saitama/
　|＿＿＿＿＿|

>>167,168

寝ちゃってました。

DBでサポートしているかどうかというよりは、そのＤＢ向けのJTS対応JDBCドライバ
があるかどうかということにかかっている。
ＤＢが管理するのはＤＢローカルのトランザクションであって、EJBとは直接関係ない
です。

普通はＤＢのベンダが提供していることが多いのだが、アプリケーションサーバの
ベンダが提供することもある。

WebLogicではドライバが対応していなくても、アプリケーションサーバでそれを補う
機能があるらしい。

PostgreSQLのことに関しては知らないので、最後に"?"を付けたわけです。

>>160

157が言ってるのは、コンポーネント化=EJBってのがそもそも
おかしいんじゃない、ってことじゃないの？

EJB使えばコンポーネント化できるとか、EJB使わないと
コンポーネント化できないとか、そんなん関係ないじゃん。
大体コンポーネントって言葉自体、あいまいで詐欺みたいな
もんだしね

なんでもかんでもEJB使わなきゃいけないと思い込んでる
アホな椰子は結構いる。特にあまりJ2EE実装したことない
マネージャ層に多そうだ。その一言で生産性下がったりするのにね。

EJBは生産性下がると思うよ。普通のローカルクラスで組んだほうが
テストが楽。それに世の中EJBな知識のある人はいまだに少ないので、
多人数プロジェクトに展開するには、ラップしてあげないといけない。
そうするとcFrameworkみたいに何でも実行できるEJBのガラがある
だけで、コンポーネントも糞もないような設計になる。

>>161でした。失礼・・・

>>171

cFrameworkはフレームワークであって、コンポーネントとは言わないような気
がするが。
フレームワークは枠組みであり、コンポーネントは機能のまとまりだろ。

おれが157から読み取れるのはＥＪＢはリモート環境でしか使えないということ
だったんだよ。
だから、ＥＪＢはリモートだけではないと言っている。

コンテナにデプロイしなくてはならないという点では、普通のクラスを使うよりも
手間がかかるというのは確かにある。
だが、そのあたりはant、JUnitなどでテストを自動化すれば時間がかかるという
だけで、それほど面倒なことではない。
それから、トランザクションの管理を任せられるという点ではコーディングは楽に
なる。

俺はどんなプロジェクトでもEJBを使っているが、生産性が下がるとは思えない。

>>160,>>170
はいはい了解。たしかConnector Architectureとか呼ぶ仕組ね。

わかったよ。PostgreSQL用JDBCドライバーの現状調べてここに書くなんて殊勝な事する気にはならんが。
SRAのページ見たらなんか情報あるでしょうよ。

http://homepage.mac.com/ayaya16/

>>160 書いたのは俺なんだが、名前欄に 160 と入れてる奴はどちら様で?
ちなみに PostgreSQL を DB にできる EJB コンテナってありまつか? ってのが
本意ね。

一人多重人格者様ですか。はー

>>176

すまん。今気がついた。161が160と間違えました。

>>178
もう少し丁寧に謝れ。

>>179

市ね。

>>161
cFrameworkのような、何でも実行できるコマンドパターンだと
プロパティに設定さえすれば、どんなコマンドでも実行できてしまう。
それってインタフェースが曖昧だし、最終的に色んな機能を含んだどでかい
EJBが出来上がる可能性が高い。その場合、何を持ってコンポーネントって
呼ぶの？と疑問に思ったので書いてみた。

テストについては、JUnitだけでは全然網羅できないと思うよ。
データベースや他システムとのインタフェースもJUnitでやってます？
そこまでやろうとすると費用対効果が一気に落ちてしまうよね。
JUnitではせいぜいロジックをたたいてみる程度の確認しかできなくて、
結局、開発者レベルで頻繁に動作確認する必要が思う
まあEJBラップしてれば、そんなに大変ではないのは同意なんだが。

少人数でスキルある人がそろっているプロジェクトなら、EJB＋JUnitでも
ある程度ばりばりいける可能性があるけど、未だにJava初心者だらけの
プロジェクトも多いんだよね････てか、自分が今そういう状況。
おまえら無理しないでEJB使わないでやれよと小一時間ほどry(

>>171

いろいろ検索してみると、cFramework用のコンポーネントというのがあったよ。
コンポーネントというと、ある機能の集まりというイメージがいいと思う。
例えば、オンラインショッピングでいうと会員管理、購買、決済、などの機能で
ひとつのjarファイルとしてやるのをコンポーネントと考えています。

このまとまりは人それぞれ違うと思うが、上のようなものだと思う。

それで、テストですが、データベースも他システムとのインターフェースもやる
ことありますよ。
全てにおいてJUnitでやっているわけではないが、できるだけ作るようにしてい
る。
あるプロジェクトでは全ファイルのうち３分の１がテストケースになりました。

データベースはテストデータをXMLで記述して、テストのたびにそれをセットし
て、テストが終わると削除するということをしている。
これにはDBUnitというツールを使っている。
当然、これをするには一人につきひとつのスキーマを用意する必要がある。

確かに実際、こちらは少人数でやっているからこうしているし、外注が数人入っ
ただけでもできなくなってしまいます。

それから、EJBといってもステートレスセッションBeanしか使わない。
つまり、トランザクションの管理だけを行わせているだけです。

>>171
>EJBは生産性下がると思うよ。
こーいう人、今だに居るんですね...。
EJBをちゃんと理解していない証拠です。

>183
こんな人、まだ居るんですね。
EJBの使用経験が無い証拠です。

cFrameworkの開発経験ある人います？
値段高いし、あまりメジャーじゃ無いけど。
cBankにあるようなEJBコンポーネント群を売る商売が
成り立つかどうかでEJBの状況も随分変わると思う。

>184
こんな人、まだ居るんですね。
EJBを理解せずに開発してプロジェクトをトラブらせた証拠です。

結局、最良・最強のフレームワークはどれ？
個人的にはStrutsが一番バランス取れてると思うが。
turbineは難しいし。
cFrameworkは高価だし。
JBossは使った事無い。

>187

フレームワークの対象ドメインによる。

JBossをそこに並べるのはかなりおかしいぞ。

>>187
スレ違い？

CMP EntityBeanの中から、DAO経由でSQL発行したいんだけど
普通にEntityBeanのデータソースからコネクション取得すればいいの？

>190
> EntityBeanのデータソース

意味不明。

>186
正気か？つーか、お前の会社ではEJBの理解度がそんなに高いのか？
IとかHとかEとか渡り歩いたけど、「これぞ！」ってな使われ方してるとこ見た事無い。
皆「EJBはひとつのコンポーネントだから云々」とか
「再利用性云々」って言うばっかりで、文字通り”豆知識”な連中ばっかだった。
で、>186の言う通り

＞EJBを理解せずに開発してプロジェクトをトラブらせ

てました。なんだかなあ。


日本でまともにEJB使える会社ってどこがあるだろな。
漆ステムズとか行ったらまた違うんだろうか。

>>191
意味不明。
とか言う前に
勉強しろ。

>>161
161さんの環境がうらやましい･･･

EJBにさせる価値のある仕事は、せいぜい分散とトランザクションしかないと
思ってます。が、トランザクションはJTA直接叩くことで代用できないもので
しょうか？
JTA使えば少なくとも、Connection引き回すことはなくなるので、それで
十分だと思っているのですが･･･

>>183
では理解しているあなたがわかりやすく説明してください
万人が理解できない説明＝脳内妄想
ってことを踏まえた上で。

>>192
日本以外でも、きっと同じじゃないでしょうか
Jakartaな人々がEJB嫌いなのも、多分似たような理由だと思われます
ある程度理解している人間同士でよく話題に出るのは、
「何でこのシステムにEJB使うんだよ」
てな話題だったりしますし･･･

>>171

JTAを直接使うというのはやったことありませんので、比較できないのですが、
JTAを直接たたける人と、EJBを使える人の人数ではEJBが使える人の方が
確実に多いと思うので、EJBの方がいいと思います。

「何でこのシステムにEJB使うんだよ」 という台詞はあるプロジェクトでお客に
言われたことあります。
でも、rollbackをきちんと書くことを考えると、見えないところで良い部分がある
と確信して、使いました。

それにしても、ステートレスセッションBeanだったら、普通のBeanと大差なく、
トランザクションも管理してくれるのだからすごくお得だと思うんだけど、違う
のかな？

>>195
JTA使って作るのも別に難しくないよ。単に解説とかの資料が少ないのと、
トランザクションの重要性を理解してる人が少ないからそう思うんじゃないの？

TransactionManagerはUserTransactionに少しメソッド足して
トランザクションを細かく制御できるようになってるだけだし。

適当なフレームワーク(Strutsとか)ちょこっと拡張して、JTA制御する
コードが必ず動くようにしとけば、エセCMTなら簡単に実現できるよ。

実際にはJTSを実装してるのがWebLogicなり、WebSphereなりの
アプリケーション鯖だから、EJBで作るのが現実的なんだろうけどね。
フリーでいくなら挙動不審だけど、Tomcat+Tyrexって構成もありえる。

>>1
賛否両論　語ってくれ。と言え。学がないからEJBも愚か、日本語さえも
満足に使い切れない。

>>192
> IとかHとかEとか渡り歩いたけど、
EJBは派遣社員に理解できる代物ではない。

http://homepage.mac.com/hitomi18/

JavaBeans、EJB、JSP、Servletの位置関係を、パーな俺に教えてくれないか？
どれを勉強すれば一番就職に有利とか。

あと、J2EEって上のどれなの？

>>200
Javaなんて儲からないからやめとけ。
ドライバをガリガリ書きまくるのが一番儲かる（マジ

>>202
Jiniサービスが本格的に始動おしたとき、おまいの職は失われるだろう。フッフッフ

>Jiniサービスが本格的に始動おしたとき
こんな冗談言ってないで>>200の質問に答えてやれよ

とりあえず>>200にはEJBが就職に有利とでも逝っておこうか。
ほかはおまけ。JSPとServletはEJBを習得する前にやっておくと楽。
会社によってはEJBを使わずJSPとServletだけでやっているところもある。

JavaBeans? それだけだったら就職には有利でない。
BeanというものならJSPなどでところどころで使われている。

>>205
現実を知らないのと、理解がイマイチのようだな。

>>108
個人的には108の下記書き込みはあっていると思っているのだけど、
どうなんですか？

特に参照系はEJB使う意味がないような気がします。
更新系も微妙ですな・・・

>パフォーマンスが悪いのはまぁ仕方がないとしても、
>SQLでいうところの、UPDATE table SET hoge = 10 WHERE foo > 50
>みたいなことをEntity Beanでやろうとすると、Beanインスタンスが大量に
>生成されたりして大変じゃない？

>>207
参照系をどうにかするためにEJB-QLがあるのですよ。
まあ、かなり無理がある後付け仕様だと思うけど。
SQLつかうのとどう違うのよ、ということで。

>>208
すいません。おっしゃるとおりで・・・
基本的にEntityBeanで100件更新しようとしたら、
100のEJBインスタンスができるというイメージであってます？
そしたら1万件のレコード更新しようとしたらメモリ食いすぎて話にならないと思うんですが・・・
実際どうなんですか？

>>209
サーバのメモリは６GB〜十数GB。と。

>>209
そんなもんEJBの作り方次第でしょ。
リストで抱えても何の問題もないよ。

>>210
即答するが、物理メモリでなく、VMヒープがパンク

>>209
EJBは１万件くらいで食らい尽くすようなものではないと思われます。

>>209
あのー、ガーベージコレクションって知ってます？

>>212
VMヒープの設定って、GBオーダは無理だっけ？ほんと？

>>211
EntityBeanのインスタンスってレコードごとにしか作れないのではないのですか？
EntityBeanの１インスタンス=複数レコード
にすることってできるのですか？
そうするとfindByPrimaryKeyメソッド等でぼろぼろになると思うのですがどうなんでしょうか？

素人で申し訳ありませんが、よろしくです。

>>215
参照系と更新系を分離して考えようね。

>>214
>>212 ではないが、今のところ Sun JDK 1.4 (Win/Linux)、IBM JDK
1.3 (AIX) は Maximum Heap 1.5GB が限界って所だな。試しに -Xmx???MB
で何GBまで行けるか試してみれ。

>>214
ガベージコレクタのリソース回収に期待しすぎてたら痛い目遭いそうな予感。
VMヒープがGBオーダーできるか否かは気になるところ。
ServerVMのみ可能とかあるのかな？

１つのVMに1.5GB割り当てる状況が俺には想像つかない。

>>218
期待ってなによ(ﾜﾗ
強参照チェインを消しておけば、メモリオーバーフロー起こす前に
消えてくれるでしょ。参照チェインの構造をライフサイクルにあわせて
付けはずしするだけで、別にあいまいな期待などしていませんが。

>>219
サーバー用途でVM複数立ち上げるような無駄なまねを
するより100倍ましかと。

>>219
ｱﾌｫ な素人集団 (Iβ○の何とか Biz) がクライアント 100〜500 規模の
イントラ業務を 1 台 (ホットスタンバイのみ) な構成にした時などの苦肉の
策として。100Mbps で9時-5時の入力しまくりボタン押しまくり攻撃はマジ
氏ねる。てか氏ね

>>216
更新系でも参照系でもEntityBeanクライアントでは
Finderメソッドで取得したリモート（ローカル）インタフェースを取得して
それに対して処理をするという方式は変わらないと思っているのですが、
（つまりFinderメソッドで１万件データCollectionデータが取得できたら、
　１万件のEntityBeanがメモリにロードされる。）
間違っていますか？

それとも「EntityBean：レコード=１：N」に対応させて
一気に処理させる方法とかがあるのですか？

>>222
糞な設計だね。漏れのところは氏んでない。
まあ、分散させてるわけだがよ（藁）DB鯖、Web鯖を共用でイントラ５００人
の設計する鬼畜が能無し。
クライアントはエラーが出ようが、ブラウザ戻るボタンで前画面に戻ろうが、
ボタン押しまくるもの。自分の入力を是が非でも通そうと試みる。

>>222
せめてWeb,AP,DBでサーバは分けるべきだね。
特にAPサーバには高負荷かかるし。

> （つまりFinderメソッドで１万件データCollectionデータが取得できたら、
> 　１万件のEntityBeanがメモリにロードされる。）
> 間違っていますか？

実装によるが、普通は間違っている。

そのCollectionの中身は実際にはEntityBeanを指すEJBObjectだろ。
EntityBeanインスタンスがすぐに１万件メモリにロードされるわけではない。

すまん、イントラ500人を一台で捌けないのか？

そりゃマシンのスペック、実装したシステムの重さによりけりだろうが。

人数はコネクション数やテンポラリデータを増やすのかな？
負荷は主に処理するデータ量に比例すると思うけど・・・

>>229
> 人数はコネクション数やテンポラリデータを増やすのかな？
テンポラリデータってどういう意味？

人数増加＝データ量増加

わかる？

> 人数増加＝データ量増加

利用者数が増えても扱うデータ量は増えないような・・・
増えるのは一時的に作られるデータだけでは？

>>231
DBだけ考えても人数増えたら、なにかしらのレコードは増えるが？
それでも扱うデータが増えないと言えますか？
3レコード検索と3万レコード検索ではどちらが負荷高い？考えるまでもないだろ。

以外に大規模なシステムでもDBサーバにはCPU負荷はかからない。
フロントエンドに近いサーバほど大忙し。

>>232
「なにかしらレコードが増える」その量が、
利用者数に依存するとは限らない。

>>234
あんた、エンタープライズ開発したことある？

「なにかしらレコードが増える」その量が、
エンタープライズ開発かどうかに依存するとは限らない。

もはやネタ決定。

「エンタープライズ開発だからですよ」
ってかなりヤバいな。

「>>236の発言」その量が、
このスレの発展に依存するとは限らない。

Ｊ２ＥＥネタはマジでヤバイって

結論：鯖負荷は設計次第

ちゃんと負荷の想定のところに書いとけよ
「利用者数に比例してなんかしらレコードが増える」って。
なんせエンタープライズだからな。

>>242
意味不明

エンタープライズなんてただの飾りですよ。偉い人にはそれがわからんのです。

今やってるシステムではアプリケーションサーバがかなり負荷高いな。
EJB,CORBA混合の環境。やはり利用者増加にしたがってCPU負荷も大きくなっている。
って、当たり前だが。

今やってるシステムではDBサーバの負荷が高いな。

ていうか、お前らの議論は
x * y * 8 と a * b * 7 どっちが大きい？

と、x, y, a, b が決まっていないのに話しているようなものだな。

>>244
エンタープライズって「企業」って意味。それだけ。
なにが飾りなのかと小一時間。

>>246
その負荷はCPUなのかメモリなのかディスクなのかネットワークなのか。
>>247
まったくそのとおり。

>>247
謎の計算式持ち出すな

ダイアゴン横丁に行きたいのですがどうやったら行けますか？

>>249
CPU負荷です。

>>247
あんた、エンタープライズ開発したことある？

たちの悪い香具師が粘着ぎみだな。

>>248ｶﾂﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ

>>253
あんた、エンタープライズ開発したことある？

企業を開発？

企業JAVA豆。
EJB

enterprise
【＠】エンタープライズ、エンタプライズ、【変化】《複》enterprises、【大学入試】
【名-1】企業、事業、政府支援企業
【名-2】企て、計画、仕事、活動
【名-3】進取の気性、積極性、冒険心

java
【名】《米・口語》コーヒーbean

bean
【＠】ビーン、【変化】《複》beans、
【名-1】豆
【名-2】豆の形に似たもの、頭
【名-3】小銭、つまらないもの
【名-4】基本的な事柄◆【語源】豆はごくありふれた植物であるところから
【他動】《野球》ビーンボールを投げる◆【参照】bean ball / 【用例・名-1】 Every bean has its black. : 《諺》誰でも欠点がある。

何かエンタープライズ日和だな（ｗ

>>248
＞エンタープライズって「企業」って意味。それだけ。
＞なにが飾りなのかと小一時間。

それだけ　ってことはつまり　それだけでしかない　んだから
やっぱり　飾り　なんじゃないの（ｗ

つか、大規模云々以外にもEJBのメリットとかあるんじゃないのかなとは思うけどな
漏れは使う機会がないのだが

>>260
EJB開発実績を作ることをメリットとして強要する会社もあるわけだが。

EJBがWebサービスより優れている点を語ってくれ

>>261なるほど、商売のためか。
企業｛で｜が｝開発だな。

EJBの良書って何かある？
英語わからんので洋書は×

まめ

>262

お前は、EJBもWebサービスも知らないだろ。

車と運転手どちらが優れているか語ってくれ

といっているようなものだな。

>>266
例えが曖昧。

>>267

じゃあ、こうしよう。

メソッド本体と、メソッドの呼び出し側、どちらが優れているか語ってくれ

といっているようなものだな。

>>268
それは明確に優劣が出るだろ。
コアクラスのメソッドに文句言う香具師はそんなに多くない。Javaヲタくらいだ。
殆どの香具師は呼び出す段階で馬鹿やってる。

別に例え話の上手下手なんてどうでも良いよ。

と言いつつ便乗。

電話とFAX、どちらが優れているか語ってくれ。

どう？

いや、一応、EJBとWebサービスに対応させて例えていたつもりだったのだけど....。

車(EJB) <-> 運転手(Webサービス)
メソッド本体(EJB) <-> メソッド呼び出し側(Webサービス)

要は、EJBは実装技術も含んだもの、
Webサービスは極論すれば単に他を呼び出すだけ
ということ。

>>13
EJBが大規模開発に向いている理由を教えてください。おながいします。

>>272
第一にトランザクション制御をしてくれること。
下手なプログラマに任せるよりコンテナで制御したほうが
間違いなくCommit　or Rollbackしてくれる。

第二にインスタンスの使いまわし。
キャッシュやプールの仕組みがあるから、たくさんインスタンスができても大丈夫。

第三に分散オブジェクトであること。
サーバー分けた場合の呼び出しが楽。

こんなとこですかな。

>>273
回答ありがとうございます。

私の質問の仕方が悪かったかもしれないですが、
273さんの書いた理由は大規模開発だからの理由にならないと思います。
　　　　　　　　　　　^^^^^^^^^^
JavaBeansで実装した場合に比べて、EJBを使用した場合
クラスタリングやアベイラビリティの面で違いはあるのでしょうか？

273じゃないけど

>>272

通常、大規模開発では、標準化や機能分割が厳密に要求される。
最初は面倒だが、全体では生産性・保守性が上がるため。
EJBは >>273 が書いてるようにトランザクション回りを各アプリでなく、
システム側で行っているため、大規模開発に向いている。

昔で言えばCICS上での開発のようなもの。
小規模開発でも使えるが、かえってめんどいかも。

JavaBeansは単に小さい機能単位のコンポーネント仕様だから、
EJBとはちょっと比較しにくい対象だと思うけど。
EJBはそれ自体がフレームワークだし。
サーバ上にRMIオブジェクトとしてサービスが実装されるわけで、
クライアントからすればネットワークそのものを意識する必要は無い。

確かに、規模が小さめだと面倒なだけかもしれない。
いい勉強にはなるけど。

>274
大規模開発といっても人によっていろいろ定義があると思います。

>JavaBeansで実装した場合に比べて、EJBを使用した場合
>クラスタリングやアベイラビリティの面で違いはあるのでしょうか？
EJBはAPサーバーが対応していればクラスタリングが可能です。
クラスタリングが可能なのはコンテナ上で管理されている
分散オブジェクトであということが理由の一つです。

オブジェクトのプーリングによって無駄なインスタンスの生成が減るので
可用性も向上すると考えていますが、どうでしょうか？

ただ、実装方式が違うので、全く同条件でJavaBeansと比べられるとは
思っていません。
オブジェクトプーリングなどは、Jakarta-commonsでも実現できますし。

EJBを無駄な仕組みだと思って使わないも自由。
提供される仕組みを上手く使おうというのも自由ですね。
既にある技術を上手く使いこなすほうが得策だと思いますが。
少なくとも独自の方式で実現するよりきちんとテストされている、
ベンダー製品の方が信頼性も高いと思います。

>>278
> ベンダー製品の方が信頼性も高いと思います。
そうでもないと思うぜ。ベンダー製品の良いとこなんてサポートくらいだろ。
他に良いとこないってわけじゃないけど。きっちりテストされてる保証はどこにもない。
頻繁に修正モジュール適用する場合だってある。
テストという意味では、不特定多数が関わってるオープンソースの方が信頼できない？

EJBのメリットとして分散オブジェクトがよく挙げられてますが、
実際EJBクライアントとEJBを物理的に別サーバにすることは
あまり考えられないと思っています。

Servlet+JavaBeansではクラスタリングできないのでしょうか？
もしEJBを使わないでもできるとすれば、
EJBのメリットってトランザクション管理をコンテナ任せにするしかないような気がするのですが
いかがなもんでしょうか？

>>280
＞Servlet+JavaBeansではクラスタリングできないのでしょうか？
なぜできないと思う？EJB使わないとクラスタリングが不可能なわけ？
もっと根本から理解を深めた方がいい。今のあんたは目先の技術に執着しすぎ。

>>281
結局EJBを使わなくてもクラスタリングできるんですね。
そうすると、EJBをEJBクライアントと同じマシンで動かすという前提だと、
EJBのメリットってトランザクション管理をコンテナに任せるくらいしかないというのが結論になるのでしょうか？

>>282
そうだね。終了。

　　 このレスを見た人間は十三日以内に死にます。
　　　　　　※あなたに訪れる死を回避する方法が一つだけあります。
　　　　　それはこのコピペを一時間以内に７つ、別のスレに貼り付ける事です
　　　　/＼＿＿_／ヽ　 　ヽ
　　 ／　　　　::::::::::::::::＼　つ
　 . | 　,,-‐‐　 　‐‐-､ .:::|　わ
　　|　 ､_(゜)_,:　 _(゜)_,　:::|ぁぁ
. 　 |　　　　::<　　　 　 .::|あぁ
　　 ＼　 /( [三] )ヽ ::／ああ
　　　／｀ー‐--‐‐―´＼ぁあ 　

>>283
で、そのうちEJBと似たような仕組みを自分たちでもう一回作り直すと。

>>282
結局ＥＪＢのメリットって言うのはそんなもんだ。

>279
>テストという意味では、不特定多数が関わってるオープンソースの方が信頼できない？
じゃ、JBOSS使えば良いんじゃない。

>282
だから、インスタンスもコンテナが管理してくれるんだってば。
まぁ、分かってないのなら使わないほうが良いんじゃない？

>283
同感。既にあるものを使えない人たちの悲しい性だよね。

漏れはEJB賛成派だけど、

>>287同感。既にあるものを使えない人たちの悲しい性だよね。

ってのは、どうなのかな。そんなこといったらCOBOLでいいじゃんとか
Cでいいじゃんとかになっちゃう気がする。CORBAとかもね。

既にあろうとなかろうと、メリットがあれば使うし、なければ使われないって
だけじゃないかと思うよ。

漏れがJava使い始めた頃は、それこそ「何でJava？VBでいいじゃん」って
よく言われたもんだし。

JDBCって何？PRO*Cでいいじゃん。

JBossは不特定の大勢が関わってるオープンソースとはいえないと思うが。

Resin使ったほうがいいよ

Resinってサーブレットコンテナ？
Resin＋JBoss(tomcat抜き)てな感じの構成になるのか？

http://homepage.mac.com/ayaya16/

>>288
EJBのどこに賛成してるのかを説明してから、
そういう事をいってください。

そういう説明がうまくできない人ほど、新しいものに飛びつきたがるよね

勉強すればするほど
そんなにEJBっていいのか？
逆にめんどくさくないか？
って思える

>>296
禿同

うまくいえないんだけど
プログラマとかデプロイヤとか
きちんと作業を分担できる環境（人数）で開発するのなら
EJB使ってもいいと思うけど
少ない人数で、しかもプログラマが
アプリケーションサーバ特有のことも
勉強しないといけないような現場では効率落ちると思う

EJBの開発って個々のEJBに対して
使用するDBの知識持ってるやつ
使用するAP鯖の知識持ってるやつ
デプロイヤ
Bean開発者
ってな具合に分けたほうがいい
分散処理目的よりも
そういう仕事を分けやすくするためにEJBがあるんじゃないか？とおもう

だから、開発要員そろってないのに無理にEJB使う
開発グループはおかしい

なんで、一人の開発者がAP鯖、DB固有のことまで
勉強しないといけないんだ？
CMPとか使っても（作業効率的に）結局意味ないんじゃない？
と思うのは当然

EJBはCOBOLをリプレイスするそのときのために
いまから準備しるってかんじだよな。

>>298
EJBで全ての機能使う必要ない。ってどこかに書いてあった。
少人数でロールする場合のやり方も書いてあったような。

>>300
どこに書いてありましたか
書籍でしょうか

>>301
Sunか@ITか。記憶だから信用しないでくれ。

結局この形が美しいと俺は思う
ttp://www.atmarkit.co.jp/fjava/rensai/smartj01/fig1.gif

>>303
２年前くらいに騒がれてたね。シンプルだから俺も綺麗だと思う。
Javaを始めたばかりの人が突然EJBのシステム保守したらどうなることやら・・。

J2EE、各レイヤの役割とかまでは理解が容易だけど実装しようとしたら、ちとキツイ。
漏れ理解力足りないから、理解できたころには陳腐化してるんだろーなー。。。。

>>304
2年前ですか
おれ、昔から今でもこのやり方マンセーで使いまくってますよ
もう古いんでしょうか？トホホ
でも、ほんとに綺麗なのでStrutsを使う意味がわからない
もちろんValidateなどは使うけど

この間、試しにSunのj2eesdkつかったけど
Deploytool使えばDD書かなくていいんだね
マジびっくりしたよ
WeblogicとかWebsphとかもそうなのかな？つかったことないでわからんけど

>>298
本当にそんなこと実際のプロジェクトでできると思ってんの？

>>298
おまえ学生だろ？なあ学生だろ？学生だと言え。
学生の身分で安易な発言してすんまそんでした。と言え。

学生の身分で安易な発言してすんまそんですた。と言いますた。
何かくれ。

>>307
市販のJ2EEアプリケーションサーバではふつう。

>>298
J2EE BluePrints には J2EE開発のロールが色々と挙げられている。
しかし結局、1人くらいしかいない super な開発者がほとんどの面倒を見る状況になってしまう。

1人もいないとそりゃもう悲惨。

BMPとCMPを使い分けている方居ますか？
使い分けている方に質問です。

１．使い分ける基準って言うのはあるのでしょうか？
２．CMPは基本的に１テーブル＝１エンティティBeanにしかできないのでしょうか？

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

>>313
１．使い分ける基準って言うのはあるのでしょうか？

CMPでは実現できないEntityBeanを実装する時

２．CMPは基本的に１テーブル＝１エンティティBeanにしかできないのでしょうか？

たしか、EJB1.xでは、EntityBeanに「従属オブジェクト」というものを定義する
ことにより、一つのEntityBean内で複数のテーブルを処理できたが、EJB2.0では
仕様から外れた。

>>315
>CMPでは実現できないEntityBeanを実装する時
具体的にはなんですか？

>>316

315じゃないけど。

単純に１つのbeanが1つのテーブルを表していれば良いけど、複数の結合
を表しているオブジェクトを処理する時にはＣＭＰでは難しいので、BMPを
使うとSunのBLUEPRINTSにありましたよ。

deployがわからん
ベンダーごとにばらばら。
統一せんかい

>>318
たしかに
禿同だ

>>313-317
テーブルじゃなくてレコードだろ
ココのスレだったか（？）忘れたが
↑のレスにSUM（＊）使いたがってるやついたが
CMPだと面倒だよな
BMPのほうが楽かな

>>317
それはまだCMRがないときの話でしょ。
いまはCMRができたから、それは関係ないよ。
むしろ、BMPの方がめんどくさいくらいなんじゃない？

>>319

そのとおり、レコードでした。

>>320

これも半分そのとおりで、EJB2.0がでる前のBLUEPRINTからです。
でも、EJBは持続先として、ＲＤＢに限定しているわけではないので、
BMPが必要なくなることも無いと思う。
CMRはRDBに限定されているような気がするのですが、そのあたり
詳しい人いるでしょうか。

> CMRはRDBに限定されているような気がするのですが、そのあたり
> 詳しい人いるでしょうか

仕様上は限定されてないよ。
あくまでパーシスタンスレイヤーはプラガブルという前提にのっとっている。
（現実にはRDB以外のパーシスタンスメカニズムは存在しないと思うが。
OODBベンダーは出してくると思うけど、しばらくは相手にもされないでしょ。）

>>315 >>321
知りたいのはＲＤＢを使った時に、
CMPとBMPをどのように使い分けるべきかなのです。

特に>>315さんの言っている
「>CMPでは実現できないEntityBeanを実装する時 」が具体的に何を指しているのかが、
気になります。

CMP2.0が出た今BMPは必要無しですか？

EJB-QLに「Order by」がないといってもAPサーバベンダが独自で実装しているし。

ビューにEntityBeanを対応させれば、CMPでもいいんじゃないの？

Borlandのアプリケーションサーバは、複数テーブルにEntityBeanを対応させられるらしいが。

>>324
結局BMPとCMPの使い分けは好みによるってことですかねぇ。

>>315さんの言っていた
「>CMPでは実現できないEntityBeanを実装する時 」は具体的に何を指していたんだろう・・・

age

>>315さんの言っていた
「>CMPでは実現できないEntityBeanを実装する時 」は具体的に何を指しているのですか？

おまえらEJBやるよりJavaの真髄を押えておいた方がいいよ？

>>328
Javaの真髄？なんのこと？
理由もなく意味のない書込みは止めてください。
「いいよ？」の意味もわからないし。

>>329は「EJBやったことある」と言いたいだけ。Javaなんてこれっぽっちも解っちゃいない。

148 名前： デフォルトの名無しさん 投稿日： 2001/04/19(木) 01:03

リフレクションによるメタプログラミングと、ClassLoaderの使い
こなしは、Javaの真髄の一つだと思うね。

URL指定で動的にクラスローディングできるって凄い楽だとおもう。
例えば、サーバプロセスを動作したままの状態でアップデートでき
たりする。

>>330
>>329の書込みから、どうやったら「EJBやったことある」と読めるの？
深読みしすぎなんじゃないの？

>>332
読めるんじゃない。事実は隠せないだろ？ﾌﾟ
EJBやったことあるってことは自分自身が一番知ってるはずなんじゃない？ｗ

>>333
話にならんなぁ。プ、とかｗとか言ってるところが寒いし。
まあ、くだらないしめんどくさいからもういいや。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

スマン。EJBって簡潔に説明して。

・分散
・トランザクション
・セキュリティ
・永続化
・メッセージング
を自動化する仕組み。

ちなみにこのどれも必要なければ使わないほうがいい。

>>339
自動化というよりコーディングがなくなる。
ＥＪＢを使うと、>>339のようなＡＰサーバ基盤に必要な技術を
設定ファイル（デプロイメントディスクリプタ）に書くだけで良い。

メモリリークメモリリークメモリリークメモリリークメモリリークメモリリーク
メモリリークメモリリークメモリリークメモリリークメモリリークメモリリーク
メモリリークメモリリークメモリリークメモリリークメモリリークメモリリーク

Mastering Enterprise JavaBeans
付録Aを読んだ。
169P/504Pまで読んだ。

ひさしぶりでまちがえた・・・

Mastering Enterprise JavaBeans
242P/504Pまで読んだ。

>>345
それいい本だよな。

>>345
せっかく読んでるなら、EJBが終わってないとこ語ってよ。

すでにここで語られていたようなパフォーマンスの悪さなんかは、
有名どころのアプリケーションサーバでは克服してきているし、
EJBQLのORDER BYとか動的なEJBQL構築とかも独自実装しているのもあるし、
変なオープンソースのORマッピングツール使うよりは、
EJBはよっぽど現実的（必須？）になってきていると思うのだがどうだろうか。

アホでも使えることがウリのJavaなのに
性能がいいわけでもないのにアホには使いづらいEJB
それだけで存在価値がなく終わってる

>>348
EntityBeanは、かなりまともになってきた印象。
ほぼ、CMPでいける感じ。
あいかわらずめんどっちーけどね。
動的なEJBQLってまだ標準じゃないんだっけ。

>>348
その独自実装てのが後々自分の首を絞めたりせにゃいいんだが。

Mastering Enterprise JavaBeans
276P/504Pまで読んだ。

>>346　はい。

>>347 ・・・

EJB使うと恐ろしいくらいパフォーマンスが落ちるんですが・・・
メモリの使いすぎ→Full GCの発生。
何とかなりませんか？EJBを現場で使われている皆さんどのようにしてますか？

本来、分散環境用だからな

EntityBeanは、分散環境におけるエンティティ(≒個別レコードの更新用途のもの。
上の前提を満たすならば便利なことこの上ない。
じゃなければ、他の便利な手段が一杯ある。

(自分はEJBマンセー派)

ＥＪＢは好きだね　設計がキレイにな感じがする
おまけにメッセージ駆動Ｂｅａｎも使い勝手がある

>>353
どの種類のEJBを使っているかが書いてないが、
EJBをどうしても使いたいなら、ステートレスセッションBean
だけにしておけ。
それならほとんど問題は起きない。

>>355
EntityBeanは分散環境ではなく、
ローカルインターフェースで使うのが、
一般的だと思われ。

(自分はEJB終わってる派)

>>358
う〜ん、微妙。

Javaそのものが終わってるだろ。(ｹﾞﾗ

>>353
徹底的にソースのチューニング。
さらに起動パラメータのチューニング。
さらにメモリ増設。
さらに仕様の勝手な変更。
最後は出入り禁止。

>>353　とりあえずSystem.GC()って文字列はソース中にないんだよね。

最近どこでもJava房が暴れてて、正直ウザイ

>>362
もちろんないです。

>>357
そのStatelessSessionBeanでメモリ使いすぎ問題が起きてます。

EJBってそんなものなのですか？
Servlet＋JDBCと比較するとメモリ使用量が半端じゃないのですが・・・

>>364
ステートレスセッションビーンで、メモリ使い過ぎるって、
どんなあほ鯖だよ。
晒しなさい。

SLSBは、デプロイ時にあらかじめプールしておく数を
指定できたりするけど、それが多すぎることはない?

>>364
普通は致命的なほどの差はないんだけどね。

戻り値がStringで、
　SLSB→全部連結して返している
　JDBC→レコードをfetchするごとにServletが print している
なんてことになってる、と妄想してみたり。

どうせヘッポコなコーディングしてるだけだろう
ループの中で毎回インスタンス作ってたり

>>367
ステートレスセッションビーンと関係無い堕炉。

EJBうんぬん以前のレベルのポカと見た!!
EJBコンテナの問題じゃなくてアプリケーションの問題なんじゃないの。

こんなんでましたけど。
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20031024/135886/
多分EJB開発だろうけどね。

>>370 というよりは、単にコミュニケーション不全だっただけじゃねーの（オンサイト顧客マンセー）

EJBだけというわけじゃないけど、Java関係では、パフォーマンス不足という
陥穽にはまる可能性が多いと思うが。
最近目にした「速度が出ない、という不満をよく目にするが、それはコーディング
がいたらないからだ」という記述を見て、まあそうかもしれないが、そうなりやすい
面をアプリオリに含んでいるという事だろうと。
370みたいな、出来てからパフォーマンス不足が問題になるっちゅうのは、
コミュニケーション不足というより、開発体制に問題があるだろうね。
WaterFallで、こういう新しい要素を含む開発をやれば、そうなりそうだ。

パフォーマンスが作り直しの理由なんてことねーだろ。
キャッシュするよう軽くリファクタリングすればよい。


これは、要件定義を間違えて丸投げに失敗した部長が中国のせいにして責任転換成功　と漏れは予測する

EJBを使う理由：
→作業が見積もれる。人件費が浮く。後戻り作業がなくなる。


EJBを使わない理由：
→速度があがらない。


つまり、時間の問題。すでに解決する技術が普及しつつあります。
当然ながら、発注企業は見積もれるシステムを依頼する。
ＥＪＢをつかわないと、取り残されるよ。Webの世界でしょ。

>>373
×責任転換
○責任転嫁

>>374

見事に幻想に嵌ってるな

はじまってすらいない･･･

EJBにすれば、

* 作業が見積もれる
* 人件費が浮く
* 後戻り作業がなくなる

という理屈が謎、で何故かその幻想を信じる人が少しコンピュータに詳しい人なんだよな。

素人より中途半端な知識の持ち合わせた人のほうが騙しやすい。

>>378
>素人より中途半端な知識の持ち合わせた人のほうが騙しやすい。
そ、キミのような中途半端なおバカをね(w
何でこの板はこんなにレベル低いんだ

ところでEJB-QLでORDER BYっていつ追加されるの？

2.1じゃなかったっけ？

EJB3.0早くキボンヌ

すいません。レベルの低い質問です。

Servlet＋SessionBean＋DAO（JavaBeans）でAPを作成する際に
DBCONNECT（ds.getConnection();）は
SessionBeanとDAO側のどちらでやるべきなのでしょうか？

個人的にはSessionBeanで行うべきだと思っています。

よく見るサンプルコードだと、SQL実行メソッドの際にDAO側でDB Connectしていますが、
その方式って、SessioｎBeanの１メソッドでSQL実行メソッドを３回呼んだら、
Connect/Disconnectを３回繰り返すってことですよね？
またSQL文をまたがってトランザクションを管理したい時、
Connect/Disconnectをまたがってトランザクション範囲を設定することってできるのでしょうか？
（下記のようなこと）

SessionBean　　　　　　　　　　　　　　ＤＡＯ
トランザクション開始（CMT）
ビジネスメソッド起動
　　１回目のＳＱＬメソッド起動　　　→　DB Connect
　　　　　　　　　　　　　　　　　　　　SQL発行
　　　　　　　　　　　　　　　　　　　　DB DisConnect
　　２回目のＳＱＬメソッド起動　　　→　DB Connect
　　　　　　　　　　　　　　　　　　　　SQL発行
　　　　　　　　　　　　　　　　　　　　DB DisConnect
ビジネスメソッド終了

で、トランザクション範囲がビジネスメソッドにしたい。ってことはできるのですか？

>>383
すいません。補足です。
>SQL実行メソッドの際にDAO側でDB Connectしていますが、
>その方式って、SessioｎBeanの１メソッドでSQL実行メソッドを３回呼んだら、
>Connect/Disconnectを３回繰り返すってことですよね？

これって性能的に問題ありなのでは？

>>383
可能です。XAデータソースを利用してください。

>>384
普通コネクションプールを利用するので、性能的に問題はありません。

>385
XAリソースは使う必要はないよ．
それは，2フェーズコミットが必要なとき．
今回は，Connectするのは，全部同じDBだろ？

SessionBeanのメソッドに宣言するトランザクション境界をちゃんと設定すればいいよ。

DAOはConnectionオブジェクトを取得するだけだから、
*実際に* 接続するかどうかは考えなくていいよ。

>>386
いってることは間違ってないけど、
実際ほとんどのあぷさばは、コネクションプールと
トランザクションの連携にXAConnection,XAResourceを
使っている。
JDBC Driverで提供されていない場合は、あぷさば側が
疑似XA機能を提供している。

>>387
すいません。
勉強不足で申し訳ありませんが、
DBコネクションをまたがったトランザクションができる理由を教えていただけますか？

コネクトを一旦きったら、DBMSがトランザクションを自動コミットするのではないのですか？
それともDataSourceを使ってコネクションプーリングの設定をAPサーバにしておけば、
Javaのソース上はdiscconnectしてもDBに接続されたままになっているのですか？

>>389
java.sql.Connection オブジェクトの取得方法を勘違いしているんじゃないかな。
決して DriverManager.getConnection() でデータベース接続を取得してはだめ。

次のものの区別をつけて理解しよう。
・データベース接続(Connectionオブジェクト)
・データベースのコネクションプール
・データソース
・トランザクション


J2EE環境では、DriverManager.getConnection()で取得するわけじゃなくて、
次の順序で取得する。
(1) javax.sql.DataSource を JNDI で検索
(2) DataSource#getConnection() を呼ぶ

事前にDataSourceをJNDI上に公開しておく必要がある。
DataSourceにはデータベース接続を関連付けておく。
この関連付けられた接続が、一般的にコネクションプールとして設定される。

トランザクションは、JTAというAPIで管理される。
SessionBeanのメソッドにトランザクション境界を設定しておき、
例外時のロールバックなどはJ2EEコンテナに任せるのがいちばん楽チン。

入れ子のトランザクションを作成したい場合には、
SessionBeanのメソッド内で EJBContext から UserTransaction を取得して、
UserTransaction#begin()メソッドで開始する。
もちろん、このUserTransactionオブジェクト単位で commit/rollback できる。

J2EEに関する日本語の文献も山のようにあるから、理解できるまで何度も何度も読みましょう。
このトピックに限れば、JDBC、EJB、JTA、JTS あたりを読めばいいと思う。

>>390
いれこ(Nested)のトランザクションをサポートしたあぷさばは、
ほとんどないと思われ。

コネクションプールとトランザクションの連携について書いてある
ドキュメントってJ2EEの仕様書くらいしか見たことないけど。
JTAのほうね。

>>390
コメントありがとうございます。

データベース接続は DriverManagerを使わず、DataSourceを使用して、
コネクションプーリング DataSource#getConnection() を使用しています。
トランザクションの管理はJTAを使わず、CMTでAPサーバに任せています。

上記にて

１．SessionBeanのメソッド呼出（→EJBコンテナよりトランザクション開始）
２．【DAO1】DataSource#getConnection()でコネクション取得
３．【DAO1】SQLの実行
４．【DAO1】コネクションのクローズ
５． ビジネスロジック
６．【DAO2】DataSource#getConnection()でコネクション取得
７．【DAO2】SQLの実行
８．【DAO2】コネクションのクローズ
９．SessionBeanのメソッド終了（→EJBコンテナよりトランザクション終了）

としたときに、

（次へ）

DBコネクションを２回またがったトランザクションが発生いたします。
通常コネクションクローズした際に、DBの自動Commitがきられると思っているのですが、
そのようなことは発生しないのでしょうか？

発生しないのであれば、どのような方式になっているのでしょうか？
思いつくところであれば、
（下記は個人的な予想です。）
　 「４．」の時に実はDBコネクトはしていない。DBへ接続したままにしている。

補足
>>393は392の続きです。

>>393
>通常コネクションクローズした際に、DBの自動Commitがきられると思っているのですが、
そのようなことは発生しないのでしょうか？

発生しません。

> 「４．」の時に実はDBコネクトはしていない。DBへ接続したままにしている。

同じコネクションが返されるどうかはわかりませんが、トランザクションの処理はきっちり
コンテナがやってくれます。また、コネクションプールから取得したコネクションをクローズ
してもプールに返されるだけでDBへの接続が切られるわけではありません。

sage

>>395
鯖によっても違うと思うけど
トランザクション中にcloseされた場合は、トランザクションに
関連付けられているXidをキーにしたMapに状態が
保存される。
次に、getConnection()されたときには、トランザクション中であれば、
Xidをもとにおんなじトランザクションが返されるよ。

まー，
java.sql.Connection
はあくまで，インターフェースなので，
close()メソッドをどう実装するかは，ベンダーの自由．

詳しい皆様方にお伺いしたいんですけど

ちょっと前のレスにも関係してるかも知れませんが、
同じトランザクション内で、あるCMPのインスタンスが対象とするレコードを
別のSessionBeanが書き換えたりしていいか？っていうところが
問題になっているんですけど、どなたか詳しい人、
良いのか？悪いのか教えていただけませんでしょうか？

SessionBeanA：
　-> トランザクション開始
　->　cmpAの呼び出し
　　　cmpA：
　　　　-> レコードAの作成もしくは更新
　->　SessionBeanBの呼び出し
　　　SessionBeanB：
　　　　-> レコードAの更新
　-> トランザクション終了

ある人は、OKだって言うし、ある人はダメだっていうんです。
この結果よっては、CMP使うか使わないかが決まってくるもので。

よろしくお願いします。

>>399
変な設計だねそれ。

>>400
うーん、そんなきもしなくもないけど、
でも、一つのトランザクション内で、レコードを追加して、その追加したレコードを
含めて集計するとかってしません？
今回のケースでは、レコードの追加が、CMPで、集計するのがSessionBeanだったり
することもあるんですよ。先に書いたのは、ちょっと誇張してるかもしれないけど。

あんまりないのかな？

>>401
集計って、検索だよね？Bで更新しないならアリでおけのような。
Bで更新するのは？？？と思うけど。なんでそっちの更新をcmpA
でやらないのか、と。

>>399
CMP、Session Beanそれぞれのトランザクション属性はどうなっているのでしょうか。
それぞれRequiredだったら同じトランザクション内で処理されるので問題ないと思います。
それと、CMPとSession Bean Bは、同じデータソース使うんですよね? でないと2PCを
サポートしているデータソースじゃないと問題が出ると思います。

>>400=402?
>>403
レスありがとう。ちょっと寝てしまった。

>>402
うん、おっしゃるとおり。と、漏れも思ってますが・・・。
>>403
そそそ、TXがRequiredで当然同じデータソースを利用するならOKと漏れもそう思っていた。
そのダメっていう人は、コンテナからみたトランザクションは同じだけど、
DBから見たらｃｍｐAからの接続と、SBのBからの接続は別のAppからの接続で、
トランザクションは別々に扱われるから、ダメだっていうんだよね。

例えば、cmpAのアクセスインテントで「排他ロック」で更新するような設定にしていると
SBのBが同じレコードにアクセス（参照でも）した場合、読み取りできずロック待ちになって、
結局デッドロックと同じ状況になる・・・とか。これ、同一トランザクションとDBが思ってるなら
起こり得ないことだよね？？？

この人の言っていることは本当？もしくはコンテナ依存？

あ、大前提を忘れてました。EJBは2.0ね。

>>404
トランザクションが同じなら、コネクションプールから返される
Connectionも同じだから、大丈夫。
DBからみたら、同じConnection。

このように実装しないとトランザクションを維持できないはず。
仕様書に書いてあったかどうかはもう忘れた。

>>405
おおぉ、そうだよね。そういうもんだよね。

・・・ところで、実は実際に試してみました。環境はWASの5とDB2のV8.1
cmpAのアクセスインテントは、「なんとかかんとかExclusiveLock」の設定
そしたら、そしたらなんと、

SessionBeanA：
　-> トランザクション開始
　->　cmpAの呼び出し
　　　cmpA：
　　　　-> レコードAの作成もしくは更新
　->　SessionBeanBの呼び出し
　　　SessionBeanB：
◎　　　　-> レコードAを含ようにSELECT文を実行
　-> トランザクション終了・・・してほしい

上の◎のところで、ストップ。１２０秒後トランザクションタイムアウトでやっと
戻ってくる。当然処理はロールバック。
使っているのは、同じデータソース。

どなたか、説明つく人います？
できることなら、私の勘違いとかで、>>405さんの言うことが正解であることを祈ってます。

EJBって、ホントにシステム落としたくないサービスも複雑という、
デカい基幹システムで使われるもので、
中小にはまるっきり必要の無いシロモノなんだよね。

>>407
所詮は可用性88%だろ。(嘲笑激藁
http://www.javalobby.org/nl/archive/jlnews_20031202o.html

>>406
DBじゃなく、CMPの排他ロックで引っかかってのかも。
CMPのロック設定見直したら何とかならない?

CMPじゃなくて、DataSource経由のJDBCでやるとどうかな。

後、DB2用のコネクションプールの設定だが、8.1用の
JDBC Driverではなく、7用のdb2java.zipをNative経由で
呼び出す必要があったと思う。

>>409
いろいろ、アドバイス感謝します。

それで、恐縮なんですが、
>DBじゃなく、CMPの排他ロックで引っかかってのかも。
これは、レコードの排他ロックでは無くって、CMPとなにがしかの排他ロックって
ことですか？

> 後、DB2用のコネクションプールの設定だが、8.1用の
> JDBC Driverではなく、7用のdb2java.zipをNative経由で
> 呼び出す必要があったと思う。
こ、これは、どっかにその文献ってあります？

その他の部分は、時間を見つけて試してみます。
また、報告するので、何かあったらおながいします。

RMIを使って、分散処理をするためのフレームワークが
EJBなんでしょうか？

�@Java使って、ＤＢを使ったサーバーサイドアプリケーションを作ろうとうする
�A今後の拡張性を考えると、複数のサーバーによる付加分散を考慮した設計がしたい
�Bソケットでやろうかと思ってたら、RMIなんていう便利なものがjavaにはある
�C同期をするべきモジュールと、不要なモジュールがある

ていう感じで設計すると、それはEJBになってるんでしょうか？

http://www.atmarkit.co.jp/fjava/special/ejb01/ejb01.html#ejb1
EJBの解説ページ

411で書いた事が正しければ、EJBって
ごく普通のフレームワークで
全然クソじゃないと思うんですが。

ただ、フレームワークとしては妥当でも、
敷居が高いというか、使いにくい感があるような。
一発使うだけなら、自分でRMI使って必要な機能だけ
作った方が速いような気もする。
フレームワークは何回も使うからフレームワークなんだとは思うけど、
ちょろっと解説書読めば、大体やりたい事ができるような
フレームワークが望ましいとも思う。

>>405の書いてあることはうそ。コネクションプールから返されるConnectionは同一じゃない。
404で「そのダメっていう人」って言う人が正しい。

戻ってこなくなるのはSessionBeanAのCMP更新処理でDB2の該当レコードが強排他されているから。
もしトランザクションをコミットしないで別のConnectionでSELECTを行いたいのであればWebsphereの
CMP記述の中でアイソレーションレベルを下げるしかない。

>>413
もし、同一トランザクション中に複数回取得した物理的な
コネクションが異なるなら、そのJDBC Driverは、
XAの機能をサポートしていなければならない。

XAをサポートしているなら、同一トランザクション中は、
同じXidが渡されるはずなので、異なるコネクションでも
同じトランザクションとして認識されなければならない。

今回DB2はそのような動作をしていないので、
XAの実装が不十分であるってことですか。

WASとDB2のトランザクションスコープが違っているなら
もうトランザクションの意味があまりない。

>>412
EJBで実現しようとしていることはかなり良いと思う。
ただ、実現の仕方が大袈裟でめんどくさいだけ。

単にリモート呼び出ししたいだけなら、RMIじかでも良いと思います。
ただ、負荷分散・フェールオーバー・トランザクション管理などを
やろうとすると、自作は大変。

EJBコマンドパターンを使って、ステートレスセッションビーンを
Facade的に使うのが、一番無難。
それ以上のことをやろうとすると結構はまる。

最近、
EJB == 分散処理の為のもの
っていう認識がそもそもの間違いなんじゃないかと思う。
TPモニタの代替としてJ2EEサーバを考えるとしたら、リソース管理、
トランザクション管理やセキュリティがメインであって、
EJBの分散処理ってのはスケーラビリティ確保の為の実装手段に過ぎないんじゃないのか。

分散処理がしたいんならこれからはWebサービスなんじゃないのか。

すべて１台のPCで完結するならEJBはいらないと思うんだけど
違うかな？
あるいは２度と構成を変更しないようなシステム構成ならば
RMIを使えば、複数台のマシンを連携させられる。

EJBを使うと、何が楽できるんだろうか？

ちなみに分散処理には、トランザクション管理は必須だよね。

>417
全て1台の"PC"で完結するような処理ねえ・・・。ネットワークすら必要ないな。

で、トランザクションの必要性は分散かどうかに関係ないぞ。ビジネスロジックなら必須だ。
分散環境で必要になるのは2PCだぞ。

>>417
1台のPCで完結するということは、そのPCが利用できない時間がサービスの利用停止時間に直結します。
(ブート時間とかクラッシュから復旧するまでの間とか)
その程度の可用性でよければ、サービスを提供しても何ら構わないでしょう。


サービスの可用性を高める一般的な手法は、複数ホストによるクラスタリングです。

HTTP Service 層、Application Service 層、Storage 層など、
それぞれのサービス層で必要に応じて複数のマシンを配置します。

層によっては100台で動いているかもしれません。
1台の安物PCかもしれません。

この環境の上に EJB サービスを提供しようというのだから、
複数ホストが前提になるのは当たり前です。
非分散環境(1台構成)とは、N台構成の特殊な場合でしかありません。

>>413,>>414
レスありがとうね。

>>413
だめっていう人の理論はまさにそれ。
ちなみに、EJB2からISOLATIONの設定は、直接指定できなくなったのよね。
AccessIntentってやつで指定する。

>>414
「・・・〜ならない」っていうふうに書いているのは、やっぱりEJBのSpecとかに
記述されてるんですか？

>>413-414の内容を検証するためにちょっと以下の仮定でテストをしてみました。
仮定：
　cmpAからのConnection(ConA）と、SB-BからのConnection（ConB）が、DBから見て別の
　Connection（トランザクション）であるならば、ConAで更新中のデータは、ConBからは読めない。

結果は次にかきまつ。

結果

Test1：
ｃｍｐＡのAccessIntentの設定が「wsPesimisticUpdate-WeakestLockAtEnd」で、
SB-BのSQLに付加
「WITH RS」：読み取り可能
「WITH RR」：読み取り可能

Test2：
ｃｍｐＡのAccessIntentの設定が「wsPesimisticUpdate」で、
「WITH RS」：読み取り可能
「WITH RR」：読み取り可能

Test3：
ｃｍｐＡのAccessIntentの設定が「wsPesimisticUpdate-Exclusive」で、
「WITH UR」：読み取り可能
「WITH CS」：ロック
「WITH RS」：ロック
「WITH RR」：ロック

以上のような結果となりました。
Test1、Test2の結果から、ConBはどのISOLATIONを指定しても、更新中のデータに
アクセスできるので、ConAと、ConBは同一のコネクション（トランザクション）と見れる？
ただ、Test3の結果を考えると、>>413の言っていることも正解のような気もするし。
だれか、説明の着く人いませんか？
いつもすみません。

そもそも、仮定が間違ってる？

ちなみに、
「WITH XX」は、ISOLATION LEVELの指定ね。

UR：非コミット読み取り
CS：カーソル固定
RS:読み取り固定
RR:反復可能読み取り

UR以外では、DirtyReadは発生しないということらしい。

聞いてばっかりなので、たまにはレス。
>>415
はげどう

>>416
前半は禿同。ただ、
> 分散処理がしたいんならこれからはWebサービスなんじゃないのか。
ここだけは半分同意。この話の流れの中での分散処理の定義であれば、
今のWebサービスの技術では厳しい。なぜなら、>>418も書いているけど
ビジネスロジックには、トランザクションは必須。

で、そのトランザクションや、セキュリティに関する規格があいまい（まだ、確定していない）だから。
当然、自社内の分散されたロジックを結合するのに、Webサービス（SOAPやWSDL）を利用して、
独自にトランザクションのロジックを載せればOKだし、
EAI用のツールを買うのに比べればはるかに安い（んじゃないかな？）。

激しくスレ違いの気がするけど、現時点でのWebサービスは、ブラウザをリッチクライアント
に置き換えるために使うのが最強。（と、思う）例えば↓

Javaの鯖 <- SOAP、WSDL -> .NETで作ったクライアント

>>420
EJBの仕様書確認してみた。
排他制御は、特に規定せずリソースマネージャ(DB2)に
まかせるとのこと。

JDBCの仕様書も確認したけど、同一トランザクション中に
複数回プールからコネクションを取り出したとき、
それが同一のコネクションかどうかは特に規定されていない。

ただ、XAをサポートしていないJDBC Driverの場合、
同一トランザクションなら同一コネクションを返さないと
トランザクションは維持できないけどね。

>>421の結果は、DB2の仕様ということなんでしょうね。

乙。いろいろ勉強になりました。

> 分散処理がしたいんならこれからはWebサービスなんじゃないのか。
Javaだけでやる:RMIやEJB
Java以外も使う:CORBAやSOAP
でいいんじゃない？

413が思うにXidというのは2層コミットを行う際に、トランザクションモニターが作成するトランザクションIDで、
セキュアやコミット、ロールバックを行う際にトランザクションリソースに対してトランザクションリソースが
保持するトランザクションを特定させるためのIDだと思うのですよ。
なのでトランザクションリソースの「トランザクション」とトランザクションモニターの「トランザクション」は
スコープが違うんじゃないかと。
そもそもXA手順が当初想定していたのは同一のデータを同時に複数のサイトに書き込むような冗長構成の
システムだと思うんですね。
EJBがXA手順を利用してトランザクション管理を行うことに関してはEJBの仕様として問題があるというような
記事をどこかで読んだ気がします。
そんときは理由がわかんなかったけどひょっとしたら399のような状況が発生してしまうことがあるからという
ことなのかもしれませんね。
そうするともうひとつ疑問が湧いてきました。
「EntityBeanをCMPで更新したあと同一トランザクションでそのEntityBeanを再度更新できるのは何でだ？」
キャッシュなしのパススルーの状況です。当然413的にはデッドロックですが、更新できます（あたりまえ）。
そこで今日一日考えてみたのですが、CMPの機構は414の機能を実装しているのではないかなと。
もしくは413がでたらめを言っているかです。
ここらへんはCMPの実装方式としてEJBの仕様書に書いてありそうなんですがね・・・・。ちょっと調べてみます。

仕様書にそういう記述はありませんでしたが、enlistされたXAResourceからConnectionを取り出すことはできそうです。

>>426
コネクションプールとトランザクションを連携させるには、
XADataSourceを使うのが、最も自然(J2EEで用意されている)
なので、たいていの鯖は、2PCに関係無くそのように実装
されていると思います。

CMPは、インスタンスロックの話を除けば、
素直にコネクションプール(XADataSource)を
利用しているだけだと思います。

トランザクション管理もJTAを素直に利用しているんじゃ
ないかと思います。

根っこの仕組みはシンプルなのに、EJBとして
あれだけ仕様が複雑なのは、いったい。。。

>>427
実装上は、XAConnectionから取り出したXAResourceの中には、
XAConnectionもしくはConnectionがはいっているんでしょうね。
リフレクションなしで取り出すのは難しそうだけど。

>>424,>>426
あんがとさんです。
話を振った私ですが、だんだん難しくなってきた・・・

ところで、DB側で何本接続がきているか？
トランザクションは同一なのか？などが見れれば、なんとなく解決の見えそうな・・
結果論にしかならないけんですけど。
どなたか、DB2で上記の内容を調べる方法、教えていただけませんか？

インスタンスにattachしてからdb2 list applications

もっと知りたければ application snapshot 取得。

っていうかこのくらいのコマンドも知らないでDB2運用する事自体が無謀だ。

>>431
ごもっともでございます。反省

今の実装だと、どうしてもコンテナだけじゃなくてRDBも面倒みなきゃならんのね

ORMじゃだめなの？
ORMは森を守ってるのよ。

>>434
ひろみ、ちゃんと説明したほうがよろしくってよ。
理解してないかたがいらっしゃるようですわ。

EJB厨ですがいくつか質問があります。
1.CMPは実際使えるでしょうか。複雑な結合をしたり、ストアドをたくさん
使っているようなシステムではどうでしょうか。
2.SessionBeanで処理する場合、１メソッドでトランザクションが完結
する場合、JTAは必要でしょうか。
3.以前関わったプロジェクトはEJBではありませんでしたが、トランザクション
は自分自身で管理し、１メソッド（１クラス内）で完結するように書いて
きました。他のプロジェクトでは、SQL文をファイルとして外において、
SQL文を共有していました。頻繁にアクセスされるマスターテーブルについては
メモリ内にキャッシュしていました。
EJBのトランザクションをコンテナに任せるという発想がいまいちのみ込めない
のですが、発想の転換が必要でしょうか。

JTAなんて低レベルなAPI使ってられるかよ

>>436
厨じゃないじゃん、初心者ジャン。

>>436
EJBは、メリット・デメリットをきちんと分かってないと使えない。
迷ってるくらいなら、やめたほうがいい。

CMTが理解できてないという時点でEJBは止めたほうが良いかと

。　　。。
　　　　　　　　　。ρ。　　　　　　　ううっ！出るっ！！
　　　　　　　　 ρ　　　　　　　　￣￣￣￣∨￣￣￣￣￣
　　　　　　　　 mﾄﾞﾋﾟｭｯ
　　　　　　　 C|.| /⌒⌒⌒ヽ／~￣￣￣￣ヽ
　　　　　 /⌒ヽ⌒ヽ＿__　 　|　　∴ヽ　　３　 ）
　　　　 ./　 _　　ゝ＿＿＿）（９　　　　 (｀ ´)　）←>>1
　　　　/　 丿ヽ＿__,.───|彡ヽ　―◎-◎-|
　 　 _/　)　　　　　　　　　　（　　 Y￣￣￣￣）
　　 (__／　　　　　　　　　　　＼＿＿＿＿／

>>440
あなたは最初から理解できていたのですか？
というか、おそらく今でも理解せず口先だけでしょ。

まあそうだろうな。

言い訳してないでEJB解説書の一冊でも読めよ

>>444
こういう人物って何を聞いても本読めとしか答えられないんだよな。
しかも本は特定しないし、特定したとしても概略的なもので質問に
対する答えが入っているかどうかは不明。
この人物を満足させる質問は何一つないので、この人物はいるだけ害。

ｵﾏｴﾗﾓﾅｰ
だったら質問に答えてやれよ

>>446
しょうがねぇ。>>436に答えるか。

1.CMPが使えるかどうかは案件による。複雑な結合したりストアド使ってる
ようならJDBCやそれなりのO/Rマッピングツールを使ったほうが良い。
2.CMTで十分。
3.トランザクションの管理は、コンテナに任せてそれ以外は、
これまでと同様のやり方でいったほうが堅いと思うよ。

Spring の Lightweight コンテナが EJB を駆逐する。
Spring には次の EJB の欠点が無い。

・侵略的なAPI(記述するコードがEJBに依存してしまう)
・コンテナへの依存(EJBコンテナ外では記述したコードが動作しない)
・コンフィギュレーション不可能な固定された機能
・デプロイ作業への献身
・長い起動時間

ttp://wiki.bmedianode.com/Spring/?Spring+Framework

age

>>448
まー Tapestry の HiveMind もそうだけど IoC コンテナで EJB を
ラップすることで Value Object(DTO) やビジネスデリゲが
不要になる。そもそも EJB なんかｲﾗﾈ。

IBMのCOBOLを使った基幹業務用ソフトウェア開発手法を
Sun,Javaでリプレースする目的が、EJBにはあるってうのを
なんかで読んだけど、それじゃ基幹業務アプリの開発で
Javaが使われるときは、EJBも一緒に使われてるんですか？
実際のところはどうなんでしょうか。

>>451
単に分散だったら JTA を使えばいい。異機種分散だったら JCA でいい。
EJB ・・・いるか？ SIer として EJB のほうが儲かるかもね。

分散とJTAがどう結びつくのかね?

JTAなんか使えるか!!! あんな面倒なもの! CMTでたくさんだ!

>>453
2フェーズコミットとか楽。Hibernate とかで JTA 使ったことあるか？

CMT は JTA を使っているのだが。

>>455
そうだな。JTA を使用した悪い例だな。
だから Hibernate の JTA を聞いたんだが。

Hibernateって2-phase commitできるの？使ってみようかな。
トランザクションは管理してもらわなくてもいいから2-phase
commitだけやりたいと思ってた。

>>457
Resin、Orion、JOnAS、JBoss、WebLogic、WebSphere などの
JTM 実装があるコンテナが必要だよ。
Tomcat の場合は JOTM か Tyrex があれば良い。

やっぱりコンテナが必要なのか。
スタンドアロンアプリケーションからJDBCと同じように気軽に
2-phase commit使えればいいのにねぇ。

2フェーズコミット自体気軽に使うもんではない

>455
あんなたるいAPI使ってられるかってことだろ。
ラッパーが必要だ。

>>458
英語しゃべれる人、Tomcatの中の人にJTMサポートするようにお願いして。
JTM 付いてないのってTomcatくらい？

>>460
気軽に使うと問題あるかな？

>>463
無問題。>>460 はほっといていいよ。

むしろOLTPを知らない>464をほっとくべきでは

>>465
なんで？ OLTPでこそ必要だろ？ 分散されたデータの更新に
JTA 使わんほうがいいのか？ 藻前は自力か？

JTAの善し悪しはおいといて、2PCはやめとけ。悪い事は言わん
本当に必要な時だけにしておいたほうが無難だ

>>467
実装にもよるけど、XAResourceが1つしか登録されていないなら、
1PC、複数登録されていれば、2PCに自動的に切り替わるように
なってることが多いと思うから、2PCといって使い分ける必要はないと思われ。

まともなXAの実装が少ないっていうのは事実だと思うけどね。
JTAで1つのXADataSourceを使うってのが無難かな。

トランザクションの粒度がでかすぎるんだよ
設計がまずいんだろう

>>469
アンタ頭固いんだよ。その辺の Web アプリだったら基本的に
リクエスト受けるとことレスポンス返すとこがトランザクション境界で
いいんだよ。

ロックがパフォーマンスが、とか言いたいのか？
必要なところは狭くすればいい。

まー小規模なシステムならどうでもいいんじゃないの〜〜。
小規模ならJDBCのTrxで充分な気もするけど。

>>471
JDBCでトランザクションを管理すると、
Connectionを持ちまわらなければいけないのが、
ネックだね。

>>471
大規模の末端でエラくなったつもりの自称上級者降臨。

>>472
そこで JTA ですよ。

EJBとEclipse

無くなって困るのはどっち？

>>475 EJBに事実上の代りは無いが、EclipseはSUN ONE等代りはある。
しかし、恥ずかしながらEJBは使っていないけれども、Eclipseは使っている・・・

APサーバ使う理由に挙げられる
・コネクションプーリングが使用可能
って項目、バカじゃないかと思いませんか？
自作しても他の項目に比べ明らかに負荷が軽いと思うんだけど。
自作の場合はセッション切れたときの再接続とか真面目に作れば
工数かかるにしても。
いやもうjakartaとかライブラリあるんでもちろん自作しませんが。

c-jdbcって発想が面白くない？DBクラスタをJDBCレイヤで実現するらしい。
ソフトウェアRAIDコントローラの実装がJDBC！というもの。
http://c-jdbc.objectweb.org/current/doc/

ググったら
紹介ドキュメントが日本語で用意されていたぜ。どっからリンクしてるのかわからんのだけど。
http://c-jdbc.objectweb.org/current/doc/japanese/

なぜかdoxygenドキュメントも日本語で用意されていた。
http://c-jdbc.objectweb.org/current/doc/doxygen/japanese/html/

c-jdbcはおもろいとおもう.
今後にきたいしたい.

>>476
SUN One重くて使ってらんない。
EJBは無くなっても少なくとも俺は困らない。

結局EJB使いたがるクライアントやプロマネに対して
SEがごねるときに有効なセリフは
「パフォーマンス出ませんよ」でFA？

>>481

パフォーマンス計測した結果で言っているの？

どうせスタンドアロンでやってるおこちゃまなんだろ

使いやすくラップしたEJBを使うと開発が遅くなるってどういうこと？

EJBでネットゲーのサーバ作ろうという会社がないのは、
リアルワールドではEJBは使えないっていうことの証明だな

コンサルやらSunやらがSI会社を騙そうとしているだけ

>>485
ネトゲじゃ使えないのと一般企業が使えないのとでは意味が違う
まあそうでなくても最後の一行には同意

>>485

そこまで、パフォーマンスが必要なシステムがいくつあると思っているんだ。
世の中には、いろいろなシステムがあるんだよ。

適材適所ということを考えよう。

>>487

EJBが必要なシステムの数も、そうとう微妙だと漏れ思うんよ

結局データベースのアクセス方法決めたりたまにキャッシュしたり計算したり
ってことだけで、Javaである必要が謎な場合がほとんどよ。

スクリプト言語で作る常駐プログラムで余裕で作れるし、
負荷分散といったってそんな難しいことじゃない。

ネトゲといっても日本で一番普及しているＲＯがアレだしな
だましだましで行き当たりばったりのパッチとかデグレも日常茶飯事
EJB以前の問題かと


ゲーム会社はオンラインゲームに関して勘違いしていると思われ

既存の売りきりのゲームと違って運用という言葉が必要になる
これらはむしろ業務系に見習う物もあるだろう

大規模でのみ開発コストとメンテナンスコストが安くあがるのがEJB。
２〜３年で終了しそうなサービスならEJBを使う価値は無い。

>>488

必要かと聞かれれば、EJBなんか無くても作れるというの
は当然だと思います。
システムの特徴に適した言語を使用していくということが
大切でしょう。

でも、EJBを使うことで得られる利点もあります。
なかでもトランザクションの管理は一番だと思っています。
EJBCommandパターンなんかはとても使いやすいです。
こうしておくと、コーディングするときはEJBかどうかは気に
しないでできます。

負荷分散は難しくないかもしれませんが、これだけ人材が
流動的になると、自社独自技術ではキャッチアップに時間
がかかるので効率が悪くなります。
そこで、システム開発に必要な技術を一般化することにより
どこに行ってもすぐに開発が出来るということではJ2EEの
流れは当然の流れだと思います。

>>490

やり方によっては、小規模でも使えると考えています。

>>491
パターンを使うのはよいことだけど、
しかしejbの実装使うのは面倒なことが多いよ

アプリケーション用のトランザクションを定義してそれ使ったほうがシンプルだと思う。

>>491

技術の一般化はまことに素晴らしいものだが、
問題は、

EJBに頼らなくてもできるほど、単純極まりない技術を、一般化してもらっても意味が無い。
しかもそれが再利用するためにマンドクサイことが多すぎ。
アプリケーション毎に作ったほうがどう考えても効率いい。

IDEとか、複雑な実装なら、一般化してもらう価値はものすごくあるのだけど。
Eclipseは偉いと思うよ。

>>488
非機能的な要求を満たすのはむずかしいね。

>>492,493

面倒かどうかは慣れの問題だから、とやかく言ってもしょうがないが
自分は面倒だとは思わないです。

>>492

再利用ということは世の中でよく言われているが自分はそんなことは
考えていません。
ただ、トランザクションを制御するためにコネクションを持ちまわるとい
うことがかっこ悪いと考えているだけです。

それから、EJBがやっていることはそれ程単純ではないと思います。

>>489

内部告発かしら・・・
がんがれ

>>495
トランザクションとかの管理なら、別にEJBじゃなくても
SpringやS2つかえばできるじゃん。
しかも普通のJavaのクラスで。

>>497
それどころか、Javaでなくてもネットワーク越しにオブジェクトをやりとりするライブラリは
いろんなスクリプト言語にあって、それを使えばトランザクション管理も負荷分散もさらっと
（っていうほどでもないけど、そのアプリケーションに合った規模のものを適切に）書ける。

EJBでなくてはならない訳ではないですが、

>>497

それを使うというのは良いのですが、そんなどこのものとも知れないものを
使うというのは顧客によっては許されない場合もあります。

技術的に可能かどうかと、それがプロジェクトで使用できるかどうかとは別
なものです。
EJBさえ使ってはいけないというプロジェクトもありました。

>>498

ここではjavaの話しをしているのではないでしょうか。
他の言語は関係ないと思いますよ。

>499
何かについて語るとき、他言語、他の技術と比較するのは至極当然の事だと思うが。
君がJavaしか解らないと言うのは別として。

>>499
> それを使うというのは良いのですが、そんなどこのものとも知れないものを
> 使うというのは顧客によっては許されない場合もあります。
>
> 技術的に可能かどうかと、それがプロジェクトで使用できるかどうかとは別
> なものです。
> EJBさえ使ってはいけないというプロジェクトもありました。

んじゃダメジャンEJBでも（ｗ　EJBの優位性にならないぞそれでは

>>500
そういうなよ。

>>500
んで、Cとかperlとか他のメジャーな言語で分散トランザクションを
さらっと書けるライブラリってどんなのがあったっけ？

始めに言っておきますが、EJBが絶対に良いということではあ
りません。
選択肢としてEJBはありだということが言いたいだけです。

>>500

他の言語にそのような機能があったからといって、それがEJB
とは関係ないでしょう。
それはjavaからその言語かの比較にしかなりません。
他の言語との比較になってしまえば、「EJBは終わっている」で
はなくて、「Javaは終わっている」というコンテキストでしか語れ
ないでしょう。

まあ、確かに他の言語にも詳しいということは無いのですが。

ここにいる皆さんが良ければ他の言語のライブラリの話しも良
いと思いますよ。

>>501

絶対的に優位ということではなくて、相対的に優位だとは思いま
す。
WebLogic、WebSphereなどが出しているものとSpringでは信用
が全く違うということが言いたかった訳です。

>>503
Rubyなんだけど、dRubyはどうだろう。

>>505
それ分散トランザクションじゃないよね。
>>498>>500は他のどういう技術を想定してるんだろうか。

他の言語と比較して駄目だったら取り入れればいいじゃん。
何のためのJCPですか。EJBやJTAが気に食わなければJSR上げれば?

EJBの推薦書籍教えてください。

>>506
分散トランザクションはそのアプリケーション毎に合わせたものを作るのがベスト
十分な技術基盤だよ

>>504
へんなところで改行するのは、あなたが分散オブジェクトだからですか？

>>509
それはなんか逆行してるぞ。
アプリケーションごとに最適なものを作れば良いというなら、しまいには
トランザクションさえいらんというところに行き着きそうだが。
トランザクションてのはもともとプロセス間の複雑な相互干渉を単純化
するための考え方だからな。

> トランザクションてのはもともとプロセス間の複雑な相互干渉を単純化
> するための考え方だからな。

このへんの話ってどういう文献当たればいいですかねえ
DB絡みに限定しない、少し抽象度があるのがいいんですが

>>511

EJBの（仕様の安定しない上に利用に手間もかかる、現実と合わないことが多々ある）トランザクション機能を利用しようとするか、
それともアプリケーション毎にシンプルなトランザクション機能を実装するか

後者のほうが単純化できると思うよ

自分で書くくらいならCMTでいいです

>>512

Object Transaction Serviceで検索してください。

オンライントレーディングでEJB使うとこ現れないかぎり
J2EE/EJBはいつまでたってもダメポな方式

BEA Tuxedoとかでいいじゃん

テーブル４つぐらい結合させて、外部結合や副問い合わせ、さらに
unionまでも使っているようなSQLをCMPで実現するにはどうしたら
いいのでしょうか。
教えてください。

ネタなのか釣りなのかはっきりしろ

マジです。
今まで作っていたアプリケーションをどうやってEJBに移行するか
ということです。
本に載っているサンプルでは、CMPでは一つのテーブルにしか対応して
いないのでどうしたらいいものかと思ってます。

その本をもう少し読め

VIEW作ればいいじゃん

EJB使うとトランザクションと排他理解できてない馬鹿エンジニアの書いた部分でも
あとでちょっと設定いじるだけでなんとかなる。

>>523
それイイな。てか、それだけで使う価値がある。

>>520
BMPで作ればいいんじゃないの？
セッションBeanでもいいけど

CMPは更新だけに使って、SELECTはセッションビーンから投げるようにすればいいんだよ。

すごい設計ですね

EJBってどこがダメなんだ？
コンピューターを複数台使う予定のアプリケーションを作る時
必然的にEJBみたいになっちゃうけどね。

ダメなのはEJBの中身がよくわかってないのに
EJBを使ってダメなシステムを作っちゃう人なんじゃないかと。

>>528
EJBわかってない人いるよな
RMIだけでもいいじゃんというような書きかたしているプログラムよく見かける
EJBコンテナの機能とかもっと使えよって感じ

INTERSTAGE

サーバーサイドJavaアンチパターンの典型 : Read-only Entity

RDBとのマッピングとかコンテナ依存しまくりなので
話すときはコンテナ名も明記してくり

RMIにスケーラビリティーを持たせると
それはEJBになる。

そのEJBの機能は、自前で作るのと大差ない、むしろEJBで作ると生産性低くなる場合が多いから困ってるんだよ

>>526
なるほど。
では、select for updateして、そのselect内容を元に処理を進め、
最後にそのロックした行をupdateする場合はどうしたらいいですか。

また、ストアドを使って、その中でいろいろな条件の下updateや
insertを行っている場合はどうでしょうか。

こういうときにCMPは使えるでしょうか。
またCMP以外に、セッションビーンから更新をかけたりした場合に
整合性は取れるでしょうか。

>>534

確かにEJBの使い方を知らなければ生産性が上がることが無いよね。

>>535

とりあえず、２番目以外は問題なと思うけど、基本的にEJBを使うときはストアドは使わないです。

>確かにEJBの使い方を知らなければ生産性が上がることが無いよね。

別に EJB に限った話ではないな。

>>535

>では、select for updateして、そのselect内容を元に処理を進め、
>最後にそのロックした行をupdateする場合はどうしたらいいですか。
>また、ストアドを使って、その中でいろいろな条件の下updateや
>insertを行っている場合はどうでしょうか。

JDBCとCMPを組み合わせてFOR UPDATEを利用した処理をしようとすると（だいたい）デッドロックします。
同一XAトランザクションですが別セッションになりますからね。
なので楽観的ロックの手法を利用して行います。
該当するレコードに更新カウンタカラムを作成し、そのカウンタが更新前の値と同一である場合に更新をします。
違っていればユーザーに通知をし処理を再実行してもらいます。
ただFOR UPDATEを利用して大量のレコードを更新するのであれば、やはり直接JDBCやSQLJ、ストプロを利用するのがいいと思います。
こうした複数のDBインターフェースを抽象化するためDAO、FastLaneReaderパターンなどを利用します。

>またCMP以外に、セッションビーンから更新をかけたりした場合に
>整合性は取れるでしょうか。

分離レベルを正しく設定すれば必ず整合性は取れます。
ただし、JDBCとCMPを組み合わせるのであればやはりデッドロックに注意しましょう。

同じアプリケーション内でデータアクセスの方式が複数並列するのって大丈夫?
管理しきれるもの?
どのくらいの規模のプロジェクトなのかわからないけれど

>>538
ありがとうございます。
結構ややっこしそうですね。
やっぱりセッションビーンonlyがいいかな。

すいません
EJBっていったいどういう機能があるのですか
どの工程を省略することができるのでしょうか

省略はできないよ。

>>539
更新処理はCMPで統一する手法が多いけども、大量のデータをDBから取得するときはJDBC
からオブジェクトを作成したりCachedRowSetを利用し取得する手法が一般的です。
CMPで数千行扱うのはリソースを食いすぎるので、やむをえないといったところでしょうか。
手法としては特に問題はないです。

>>540
懸命だと思います。CMPは単なるDBラッパーとして利用するにはかなり大げさな仕組みです。
つまり、勉強しないといけない仕様が山のようにあります。
セキュリティや分散を必要としないのであればJDOやHibernateなどの仕組みを利用するとよいと思います。
こちらはもっと軽量で完全にJDBCを置き換えることが可能です。
学習も容易です。

>>541

EJBは

・トランザクション
・セキュリティ
・分散
・オブジェクト永続化
・メッセージング

の処理をプログラムから分離して、アプリケーションサーバーと呼ばれるソフトウェアが別途管理するためのコンポーネント仕様です。
プログラマはこれらに関する詳細なコーディングを省略することができます。
EJBの仕様に沿って作られたアプリケーションはさまざまなベンダの提供するアプリケーションサーバで配備可能です。

省略できる工程はプログラミングとあとは保守ですかね。不具合がおきたらアプリケーションサーバーのせいにしたりします。

過去ログに車輪の再発明とかでてるけど、
Strutsやらなにやらは古タイヤの再利用くらいだとおもう。

ほしい物に似てるけどちょっと違うんだなあ。
だから車体を古タイヤに合わせて設計してみました、みたいな。

似たようなもの毎回作っちゃってもいいんじゃないの？
設計の再利用ってもう流行ってないのかな。
実装なんて再利用しようとても毎回しっくりこないんじゃない？

これ、JBossというかEJBのときにも思った。
既存の道具生かすためになんか本体側で無駄な苦労してるなあと。

見果てぬ夢ですよ
でも夢を見つづけないと飛行機もロケットもできないよ

藻舞らEJB3はどうでつか？

MetaDataは革新的だと思う。
やっと.NETに追いついた感じ。
JBOSSみたいなプラットフォームでMetaDataを利用したAOPをバリバリやりたいなぁ。

EJB3.0の概要が明らかに──「アンチEJB」 派の意見を取り込み大幅変更
ttp://itpro.nikkeibp.co.jp/free/JAV/NEWS/20040510/1/

提灯記事

別に無用にほめたりしてないから、普通の新バージョン発表記事だとおもうけど。
「こういう機能が採用される」「こういうことが期待される」
とかしか書いてないから。

必死だな。
具体的に何が変わるかも書かずに「これは期待できる」と提灯持ち。

しかも

> 従来のEJBの機能を使いこなしている例は非常に少なく，特にCMP Entity Beanによる
> データの永続化というEJBのメリットを引き出している例はほとんどない。

あれー？宣伝と違うねー。www

大幅変更か。
過去の互換性切り捨てでまた書き直しか。
ドカタの仕事が増えて良かったね。ｗ

「これは期待できる」

ﾄﾞｶﾀの仕事が

>>552
「期待できる」じゃなくて「期待が大きい」ね。
別にこういう紹介記事でこまかいことは書く必要が無いと思うし。
方向性と目玉となる機能だけあればいい。

> 特にCMP Entity Beanによるデータ の永続化というEJBのメリットを引き出している例はほとんどない。

これは笑った。うん、宣伝と違う。
ただ、その違いを改善しようとしてるんだから、とりあえず期待だけはしておく。
それにしても、ほとんどない、って言っちゃうのか。

今までEJBﾏﾝｾｰしてたやつ超笑える！だっせー

>>556
EJBのメリットはCMPだけじゃないしね。

CMPがいけてないのはみんなわかってる。だから誰も使っていない。
HibernateっぽくRDB依存のAPIを大きく公開してほしいなぁ。

VBでCOM+やってた方が10000倍マシ

せいぜい3倍ぐらいだろ？

家でミクミン２やってた方が2560倍マシ

CMPとEntityBeanを混同してるような。。。

じゃぁBMPを使うのか？
まずCMPのほうがパフォーマンスいいじゃん。

>>563
日本人？

来月から始まるプロジェクトの説明を受けてきたんですが、
SEの方いわく、
「このプロジェクトはパフォーマンス重視なので、EJBは使えません。」
などと仰ってましたが、どこもこんな感じなんですか？

>>565
うちもそうだよ。

EJB使う規模じゃない＆知識がないだけでは？
分散前提なんだしねぇ

EJBが有益なプロジェクトって日本じゃ100あるかないかぐらいだしね。

でも、sunのメインとなるプラットフォーム考えればEJBに目がいくのもわからなくもない
やつらからしたら１億以下は激安の案件だしな〜

>>569
まあ、そこもどんどん侵食されていくわけだが
ttp://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040512/1/

最近驚いた業界平均値：

　EJB系プロジェクトの総工数　３人月/画面
　うち実装工数：　　　　　　　　　 ３日月/画面

　しかも、開発プロセスは大抵、品質の悪さで定評ある
　大抵ウォーターフォール(ﾌﾟﾌﾟﾌﾟ

お客さん、ぼったくられてるよ

実装工数 みかづき

実装工数　３人日だろヴォケ

EJBかどうかとウォーターフォールかどうかの直接的な関連性はないな

VBの案件の方が個人的にウォーターフォールは多いと思ってる
結局cobol屋がほとんどVB屋いったんで同じかと
特に設計連中

＞EJBかどうかとウォーターフォールかどうかの直接的な関連性はないな

話の本筋見えてない基地外はっけん

>>575
底辺労働者に工数の話しても、通じるわけないだろ。
重要な話しても無駄無駄

>>571
経験が高かったり業務知識が多くあって斬新なものじゃなければ、ウォーターフォールのほうが品質がいい。
それに、すべてのプロセスの基本はウォーターフォールだ。
プロセスの名前に踊らされる厨みたいですね。

なかなか挑発的だな
ttp://www.amazon.co.jp/exec/obidos/ASIN/0764558315

書名表記の怪しさがいいな。

>>579
署名表記が間違っているのはは日本だけのようだが。

本家はこちら。
ttp://www.wrox.com/books/0764558315.shtml

しから、WROXの顔写真つきの表紙はどうもイヤーンな感じだな。

EJB1.1 もしくは 2.X の仕様書の日本語訳って無いんだっけ？

しかし、ウォーターフォールとまではいかないが
要らない準備に時間がかかるという意味では
EJBはウォーターフォールっぽいかもな。

繰り返し開発では、本当に必要になるとわかるまでは
EJBは使わない。

分散環境では役に立つ？

すまんが教えてくれたまい。

EJB2.0前提なんだけど、DB上Viewに対して、EntityBeanて作れるの？
もし作れるんなら、更新不可能なViewに対してもOKなのかしらん？
その場合、アクセサ（setter）は使えるの？

教えてえろい人。

更新不可能なViewのEntityに対してsetしたら、その後どうなって
欲しいの？

すまそ。
>>585

いや、そもそもsetterがあってよいのかしらん？と思ったのよ。
使いたいわけではないんだが。
>その場合、アクセサ（setter）は使えるの？
この行は忘れてくだﾁｨ

詳しいことは知らないがだれかがWebSphere用にパッチつくってないのか？

>>586
変更不可能にしたいならリモートインタフェースからsetを削除

上の方にあった、セッションBean＋Hibernateってどうなん？
CMPで開発を行ったけど、正直もうｲﾔ。

サーバーが1台完結+DBなら、Spring+Hibernateでいいんじゃないか、とやったこともないのに無責任に言ってみる。

>>589
JBossでやってる（というか、やろうとしている）んだけど、ホットデプロイがもー！全然できない！！！
どっかに参考になるサイトないかな。(hibernateのサイトと、Jbossのサイト以外ね）

>>589
EJB3.0 で Entity Bean は Hibernate ＋ JBoss AOP で XML いらずになるな。
EJB の欠点だった Data Trunsfer Object も Business Delegate も不要。

EJB2.0 は終わってる

>>591
金出してマニュアル買え。

>>593
なんとか自力できた。SARにするのね。

実際の案件で、JBoss3.2.x で Local EntityBean を CMR でリレーション
張って、使っている人いますか?

本当に終わってしまった

EJB3こなきゃ
むしろはじまってもいないという状況

ＥＪＢってそんなに難しいか？
もしかしてみんな英語読めない厨？

難しいじゃなくて役に立たないっつってんのに
わけのわからん話を持ち出すのが終わってる証拠

>>598
スレ違いだが、「英語」と言う所に反応。

毎日、それなりに英文読んでいるのだが、ごろ寝して気楽〜に読めるようにはならん。
それなりに負荷が高い。

これって、まだ修行が足らんって事？
それとも英語＝母国語で無い人間は、この程度が限界？

>>600
８歳辺りまでに英語に親しんでないと厳しいらしい。
TOEICスコアは800点以上あるが、英語モード時の脳の負荷は
高いまんまだ・・・

>>601
ショック。　
知識レベルとは違う方向で、脱力法を見つけねば・・・Thx

WebSphereでEJB開発するのに何か気の利いた説明してあるページない？

>>603
http://www63.tok2.com/home2/jd4/
とか。

でも実質EJB使わないんじゃないの？

Servlet--(CommandBean)-->Facade-->Domain-->DAO

FacadeだけSessionBeanで、
ここで
　トランザクションを切って
　Servletから投げられたCommandBeanのexecute()メソッドを実行
する。

CommandBean.execute()内で実行される、
Domain(業務ロジック)はふつうのJavaBeanで
DAOもJDBC(SQL文)直書きのJavaBean。

非同期処理をやりたい場合も、MessageDrivenBeanからFacadeに
CommandBeanを投げるようにすれば作りは同じ。

JBoss3.2.5 で CMP を使って RDB へアクセスしているのだが、
Finder メソッドを xdoclet に EJB-QL(or JBoss-QL)で

query = "SELECT OBJECT(a) FROM table as a WHERE a.id IN (?1) AND (略)"

として生成しても IN 句に指定したクエリがうまく動いてくれない
(期待するエンティティ(レコード)が挙がってこない)。

?1 にはカンマ区切りの文字列を指定(ex. 1,2,3,4)しているんだが、
何か使い方間違ってる? JBoss-QL での LIKE のノリで書いたのだけど。

他の Finder は(少なくとも必要としている範囲では)使えてる。

>>605
もうEJBなんてだいぶ前につかっただけだが、カンマ区切りの文字列じゃなくてちゃんとint型
　などでやらんといけないのじゃないの？

なるほど…ありがﾄﾝ。
LIKE で % とか指定できるのは同じ文字列だからかな。

今回は引数(?1)が可変なんだよなあ…どうしたものやら。
EJB-QL とか JBoss-QL じゃ無理なのかしらん。

>>607
　うむ、スレタイどおりのセオリーだな。

>>605
OBJECT(a)って何?とか思ったらこれがエンティティの集合になるのね。
これSELECT対象が何十何百万件とかになった場合大丈夫なわけ?
カーソルとかイテレータみたいなものと思って良いの?

ちょっとだけ調べてみた。取りあえず JBoss だと DynamicQL ってので出来た。
ejbSelect メソッドを使う方ね。ぐぐれば出てくると思う。

>>609
どうなんだろう。クエリに対する件数が膨大なのって普通にありそうだけど…。
情報お持ちの方キボンウ

>>610
コンテナ独自の機能を使ってもいいが、それではEJBのうまみも半減する。

>>611
あ、ｲｴｯｻ-。取りあえずでけただけって感じです。申し訳ない。
JBoss 拡張でなくて済むならそれがいいかと。

それとも後半の膨大な検索結果…って下りの所に掛かっているのかなあ?
だったら例があれば教えて頂ければ幸い。

EJBはおろかＪａｖａもほとんど知らない糞ＳＥなのだが、
誰か教えてください・・・

ＲＤＢのあるテーブルに３万件のレコード（カラム数約５０）から、
いろいろな条件でレコード件数を集計して
エクセル出力するアプリがあるのだが、

うちのＥＪＢだと、３万件のレコードを
select * from table　where ・・・
みなたいな感じで全部データを取ってきて、
プログラム上で条件を絞り込む処理を実装している。
これが激遅で、ユーザから叩かれ撒くっている。
ちなみに、where句に相当する処理は、超基本的なものしか使えない。
（is null とか　大小比較、グループ関数、distinct相当の機能もない・・・）

小生的には、
ＥＪＢを止めて、ＪＤＢＣで自由にＳＱＬを発行する方式のほうが
どう考えても早いと思うのだが、どうなんでしょうか・・・
例えば、
select count(*) form table where ・・・

教えてクンですまんのだが、だれか助けてくれ〜

ユーザが参照しかしないんだったら、EJBの中で、
"where句に相当する処理"をSQLのwhere句に置き換えて、
SQL発行したらええんでない。

使いかたと規模と間違えているような気がする

>614
EJB開発者にSQLを自由に発行できる仕組みがあるのかどうか聞いて見ます。
欲しいデータは件数、合計値なので、COUNT,SUM等を使えれば、１発だと思うのですが、
テーブルの全カラムのデータを取得して、アプリサーバ側でそれに相当する処理させています。
なので、バグも作り込みやすいと思っています。
ちなみに、先日の説明では、カラムを指定して取り出すこともできないと言ってました。

>615
想定ユーザは１０００〜２０００人程度、
同時アクセス数もＭＡＸ１００人程度と見ています。
ただ、数百〜数千件のデータ参照、更新処理を行うことが結構あるので、
その辺がネックになっていまつ。

これって「よくわかんないけどEJBにしてみますた」って奴？

>617
おそらく。
当時の決定経緯は良く分からないのですが、
ＥＪＢを開発してみたい、ある技術者の単なる興味から始まっています。
上司もよくわかんないけどＯＫしちゃったみたいな・・・

ＥＪＢもその彼が開発したんですが、他の人にはブラックボックスで
中身は良く分からないんです・・・

システム規模の点からも、ＪＤＢＣかＰＨＰあたり十分かと・・・

>>618
「PHPでも十分」って言ってる段階で、EJBを使うべきではないだろうに。
今からでもイチから作り直したら？？

>>616
　Hitしたコレクション数をそのまま出せばカウントになる。
　SUMはEJB-QLで使えなかったっけ？

　カラムを指定して取り出すのはejbSelectかなんかであったような気がするが。

>>619
現場はそうもいかんでしょ。まず上が許可しない。
てか悲惨な仕事やな〜

>>618
いまさらJDBCでPreparedStatementと戯れるのも、なんだかなぁ。
Hibernate使っとけ。
PHPを使う気はしなくなる。めんどくさくて。っつうか、PHPってめんどくさいよ。

「危機に瀕するJ2EE」――市場調査会社がレポート
ttp://www.itmedia.co.jp/enterprise/articles/0410/18/news056.html

危機に瀕してるのはEJBね。
SpringもHibernateもJ2EEのコンポーネント利用するわけだし。

@remote

read-onlyにEntityBean使うなよ･･･。

セキュリティ警告数の比較

Java
http://secunia.com/graph/?type=adv&period=all&prod=784
.NET
http://secunia.com/graph/?type=adv&period=all&prod=667

結論
.NETの方が安全。

穴は数よりも大きさの方が大切。

>>626
対応の早さもね
ベンダに頼らず、自前で対応できるかどうかも重要

>>616
EJBでレコードを返す、ってEntityBeanを返すってこと指してんの?

しっかりしろよ…

ありがとうXDoclet。
君はスバラシイ。

tigerに対応してくれればいうことなしん。

EJBやデータソースなどをlookup()する際にENCをつけて
lookup("java:comp/env/○○");
とする方法を教えてください。

>>632
○○の文字列で何を参照したいのかを、配布ディスクリプタで定義する
必要があると思うよ

EJB3が出たら、このスレはどうなりますか？

>>634
スレタイが変わる
【Spring/JBoss/Hibernateの】EJBは終わってる【劣化コピー】

Hibernateの作者も仕様策定に関わってるとはいえ、EJBは企業に
とって金づるなので、各企業の思惑が追加される。

　　　EJB の目的はシステム開発の効率化ではない。
　　　EJB サーバベンダーが儲けることを最大の目的として
　　　仕様が策定される。

結果的に今までの EJB と同じ道をたどることになる。

何も考えずにEJB使えといわれたときに開発者の負担が軽くなる

・・・

分散環境ならどうしてもEJBみたいな仕掛けは必要。
でも最大公約数の規約で必要な部分だけを選択すること自体に
コストがかかり過ぎ。

現実的には、StatelessSessionBeanを継承したFacadeからPOJOを
使用するパターンに落ち着いてきている。

サーバーのハードやアプリケーションサーバーを買わせたい
ベンダーとその営業の思惑や、EJBという言葉だけ使っている営業と
生半可な知識しかもたないPM/PLには、StatelessSessionBeanだけを
使おうが何しようがわかりゃしないので、コソーリHibernateで
照会時はベタベタSQL、更新時にはHQLを使って期日を守って納品。
お客さん、ユーザー、営業、製造みんなで幸せ。

EJB３いいじゃん
hibernateとSessionBeanをアノテーションで再定義しただけだけどさ

EJBって何かと統合して、内部大幅変更なんだよね？
詳細教えてｷﾎﾞﾝﾆｭ！

簡単に言えば、使うのが簡単になった。

今まで何が難しかったのか説明しる！

大幅変更で困る部分とかは無かったの？

Fucking M$ sucks!

今からEJBを使おうとする人が安心するように、変更内容教えてage

説明サイトでもＯＫ

何がって、なんかいっぱいクラス作って定義ファイル書いて、いろいろな手順を踏むのがめんどくて難しかったんじゃね？
別物だから、変更どころの話ではない、ってことで。

で、別物になって良いものになった？

xml書くのがウザかった

>>645
楽そうではある。
悪くはなってないと思う。

EntityBeansがあったからこれだけEJBが話題になったのだろうけど、
EntityBeansのせいでEJB全体の仕掛けが複雑になりすぎたように思えます。
Application Serverの機能としては分散トランザクションや負荷分散、JNDI、
IIOP、RMIなどのインフラが提供されれば十分。つまりSessionBeansが
スマートに使えれば十分だったといえます。
世の中が必要にしていたのはRDBの情報をオブジェクトにマッピングすることで
あって、オブジェクトをRDBにマップしたいわけじゃなかったのだと思う。
このミスマッチが現状のEntityBeansの問題点だろう。

>>648
>EntityBeansのせいでEJB全体の仕掛けが複雑になりすぎたように思えます
私は特に複雑とは思えませぬが。

>>649
複雑かどうかは別にして、、



やる気なくなるくらいめんどい。

ステートレスセッションBean以外ｲﾗﾈ。

てかEJB自体ｲﾗﾈ

>>649
あんなに煩雑になるものを複雑ではないと思うあなたとは、
一緒に仕事をしたくないと思う人は多いと思う。

ハードウェアがかなり頑張ってくれてるので大きな過ちに見えませんが、
EJBはじめソフトウェアはだめだめです。

そんな最先端行く俺が今携わってるのが、マンスリー100アクセス足らずの大コケシステム。

仕様ペラペラ。
EJBがちがち。
レスポンスとろとろ。
プロジェクトボウボウ。

EJB3でもなんでもこいやあああ！！

>>654
それをEJBのせいにするのは(・A ・)ｲｸﾅｲ!

失敗の理由を技術のせいにするうんこシステムはいたるところに存在する。

理由・・・難しい言葉を並べることで素人の客をうまくまるめこめ責任転嫁できるから。

そうはいっても.netなら間違いなく成功するしなー

釣れますか？

java歴4年程度なんですが、未だにEJBを使った開発したことないです。
携わったPJは最大で40人月程度ですがいつもservlet/JSPです。
EJB使うとしたら技術的にどういうときに有効ですか？
分散トランザクション、RMIなど必要に迫られた場合ですか？
sessionbeanとhttpsessionって違うんですか？(笑われるかも…)

やはり、パフォーマンス悪化などでそれほどメリットないのでしょうか？
個人的には他の大規模PJでは採用していると聞くので未練がありつつも、
周りにEJB経験者が少なく、いろいろ工数増えそうなため採用するつもりはないです。

EJB使ってもServlet/JSPなわけだが。
EJB使うときっていうのは、親会社から「このアプリサーバーを使え」って指定されたとき、とか？

>sessionbeanとhttpsessionって違うんですか？
誰か説明して。

違う。全く違う。

EJBなんて負の遺産となること必至

Stateless以外を選択したアプリは、もう既に立派な負の遺産。

それなりに見識がある技術者が参画するような大規模プロジェクトでは、
Statefulなんかはなから使ってない。Entityなんてもってのほか。

ちょうちん記事やメーカーにのせられた、なまじJava使い乙。

statelessってつまり関数呼び出しの中継なの？
調べずにカキコ

StatefulはともかくEntityをばかにするなー

Statefulはともかくちょうちん記事をばかにするなー

JavaWoldをばかにするなー

＠ITのライターをばかにするなー

分散トランザクションってみんなどうしてんの？？
TuxedoとかMQとかOpen TP1とかつかってんの？？

このスレにいるほとんどの人は「XA？何ソレ？」な人たちでしょ。
普通のWebアプリ作る程度の人たちに分散トランザクションは語れまい。

なのに分散トランザクションを売りにしてEJBを押し付けたからほとんどの人にとって使い物にならなかった。

押し付けてはいないだろ
小規模で採用するのがおかしいだけだ

MQ使ってるよー
IBMマンセー

分散じゃなくてもJTAに管理させとくのは便利だと思うが。

管理するのはJTSだろ。
JTAはAPIを指す言葉だぞ。

JTSやJTAを隠蔽するためのEJBだと思っていたのだが

>>674
トランザクション管理のために使うにしてはめんどくさすぎ。
ってことでDI+ORMなんだね。

>>675
そのツッコミはもっともだけど、JTSって一般的じゃないからね。
使い方としてJTA(TransactionManager)で行ければいいと。

＃大半のサイトはJTA管理って書いてる希ガス

>>677
トランザクションをロジックから分離できるメリットは大きいよ。
EJB使わないなら、DIでも自前でも挟み込めばいいだけ。

単体で独立したJTA-JTSな実装で安定したのがあれば
いいんだけど、今のところ知らないからなぁ。

TyrexもJOTMも一年半くらい前に試した時はヤバかった。

さすがにこの辺は商用コンテナに一日の長あり。

商用UNIX＋商用コンテナ、これが最強の法則。

結構流行をおっかけるのが好きだったんだけど
TyrexもJOTMも知らなかった
勉強しなおします。

最近よく耳にする、オーケストレーション
複雑さのメタファーとしてはうまい表現だと思う、金もかかりそうだし

>>678
トランザクションをロジックから分離するなら、それこそDI+ORMで充分なんでは？

DIは一時の流行

といいながら、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でしょ？