EJBは終わってる
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGそれとも出る?
EJBに未来はないと思うが
否定派・賛成派共に語ってくれ
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNGどんなアプリケーションサーバー使ってるの?
0004デフォルトの名無しさん
NGNGJRUNっす
0006デフォルトの名無しさん
NGNGEJBの仕様そのものがラップの塊でオーバヘッドが大きいところに
JVMのインタープリタ実行というのが致命的なだけだと思うが
パッシベート・・笑っちゃうね
お前がメモリを無駄に使うからだろが！ JVM
0007デフォルトの名無しさん
NGNGJRUNのIIOPまわりのエンジンが遅いのではないでしょうか?
JRUN、どんなの使ってるのかな...
ちなみに Borland Enterprise Server だと、VisiBrokerを
使っているからとても速いんだけどね。
0008デフォルトの名無しさん
NGNG0009デフォルトの名無しさん
NGNGスタック取りすぎ。
0010デフォルトの名無しさん
NGNGでも全般的に速いとはいえないでしょ
AppServerちゃんたち
0011デフォルトの名無しさん
NGNGBorlandのサーバって開発ライセンスは無料じゃないの？
0012デフォルトの名無しさん
NGNGVisiBrokerでC/C++ CORBAできる人はEJBには見向きもしないと思われ
0013デフォルトの名無しさん
NGNGよほどの規模でない限りEJBのメリットなんてないし。（別に煽りじゃないよ）
J2EEでのサーバサイドJavaBeansとEJBの関係は、MSの技術でいうところの
COMとCOM+/MTSの関係と一緒だね。
大した規模でないならざわざわ複雑で高度なコンポーネント技術使う必要ないもんね。
兵隊の確保も難しいし。
うちの会社の他の部署の奴らがServlet+JavaBeans+JSPでWeb開発してて、
「EJBなんて必要ないよ。うちらのやってるパターン最強！」とかいってたから
試しにソース覗いてみたら、Beanコンストラクタの中でJDBCDriverをforNameして
コネクション張ってやがった。呆れるというより、「ああ、プーリングの概念を知らなくても
Webシステムって作れるんだなぁ」ってむしろ妙に感動しちゃったよ。
0014デフォルトの名無しさん
NGNGライセンスが必要です。
0015デフォルトの名無しさん
NGNGRDBMSに接続するinterfaceに何使うの?
0016デフォルトの名無しさん
NGNG0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNGWebLogicなら、DriverManager.getConnectionでもプール有効です。
PoolManでも、私の作成したドライバでも、DriverManager経由でマッピング
された別DBへのプーリングされたコネクションが返されます。
0020デフォルトの名無しさん
NGNGよほどの規模でなくてもEJB使ってパフォーマンスでないのよ
どーすんのさ
煽り返しじゃないよ
0021デフォルトの名無しさん
NGNG貴方あまり現場の修羅場を知らないとみたが
管理系の人?
0022デフォルトの名無しさん
NGNGメリットはどうでもいいんすよ
パフォーマンスがあぼんなんすよ
0023デフォルトの名無しさん
NGNGサンキュー ちなみにいくらぐらい?
スマン自分で調べるのだるい
0024デフォルトの名無しさん
NGNGCOM CORBAブリッジとJNIとネイティブSQL API
002513
NGNGEJBがパフォーマンスとのトレードオフというのは常識レベルだから、
スピードを何よりも重視する環境、ハイスペックなサーバを用意できない環境なら
そもそもEJBを選ぶこと自体に最初から問題がある。
システム要件定義と採用技術のアンマッチだな。
IIOPでネットワーク通信したり分散トランサクション管理したり、セキュリティチェック機構が
働いたりしてるんだから、速度とのトレードオフを見極めるのはEJB採用の際には必須。
>>21
バリバリの現役ですが何か？まぁ基盤系というかデプロイヤだけど。
「EJB使って修羅場」とかいってる現場を煽りスレで聞くが、おそらくそういうところは
EJBを使う使わない関係なく修羅場なんだよね、だいたいにおいて。
それを技術の責任に転嫁しているところは多いと思う。
だいたい、「EJBを使う」＝「大規模開発」なわけで、それにも関わらず
メソッドテンプレートや共通基盤、開発基盤といった環境をろくに整備もしないような
「小規模な短期Webプロジェクト」のノリで走り出しているプロジェクトも多いよ。
EJBを採用した大規模開発は、それこそメインフレーム開発と同じくらいの
覚悟で望まなきゃ。最初からある程度のリスクを追う覚悟がなければ
ミッションクリティカルなシステムは成功しないさ。
0026デフォルトの名無しさん
NGNGhttp://www.borland.co.jp/bes/bes1/sku.html より抜粋します
開発ライセンス（開発者／インストール単位）希望小売価格 \200,000
ちなみに...
Borland Enterprise Server AppServer Editionの開発ライセンスは、
JBuilder Ent版に同梱されています。
0027デフォルトの名無しさん
NGNGんで、こいつにはEOFっていうRDBｱｸｾｽするフレームワークがあんだけど、
これ使ったらEJBなんて不便で煩雑で使ってられなくなってしもた。
EJB使うのに、ｺﾞﾘｺﾞﾘ書かなきゃいけないような部分が予め提供されてて、
こっちはそれを使うだけ。
002927
NGNGWOはEJB/J2EE対応もしてるけど、とりあえず\7ﾏｿちょいなので、そういう使い方もできるな。
ほんの数年前は、値段100倍だったのに。
0030デフォルトの名無しさん
NGNG真面目なデプロイ屋さんなんですね
EJB肯定派としての意見
ありがたく頂戴します
0031デフォルトの名無しさん
NGNG四マイクロのやることは、理想論ばかりで
いつもパフォーマンスを考えない
0032デフォルトの名無しさん
NGNG重ね重ねサンキュー
Ent版買えばテストオッケーね
ボーランドさんください!
フィルードテスト版でいいから
漏れに貸してくれればEnt用のEJBツール作るってあげるってば
だめっ?
0033デフォルトの名無しさん
NGNG600人月の仕事に着手しようとしているけど
ルートマネージャもJVMを信用していないぞ
この人は大規模開発の実績が多々ある
その人がJVMやEJBはあぼんしてる
もちろん漏れもあぼん
大量なDB操作には無理・仕様的に不可能・やめたほうが良い
時間の無駄・テスト時の待ち時間の無駄
だから
プラットフォーム毎のネイティブコンパイラ出してくれ
四マイクロはん
0034デフォルトの名無しさん
NGNG信用していない理由を書かないのに批判するな。
ルートマネージャがそう言ってるから？・・・頭悪いね。
0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNGその JVM で大規模開発いくつもやりましたが何か?
てか、大規模ってなんだよ。3億以下なら笑うぞ。
0037デフォルトの名無しさん
NGNG0038デフォルトの名無しさん
NGNGとりあえず俺もJVMは信用できねー。
アプ鯖自体がJVMで動いてたりするのも気に入らないが、
JVM監視のためにWatchDogをnative実装するのも、なんだか本末転倒な気がする。
0039デフォルトの名無しさん
NGNGなんでもかんでもJavaで組もうとスルヤシのほうが
よっぽど頭わりいと思うけどな
0040デフォルトの名無しさん
NGNGおまえが頭悪いのは分かったから
0041デフォルトの名無しさん
NGNG禿同
クライアントはJava厨SAにだまされているとしか
言いようがないなぁ
0042デフォルトの名無しさん
NGNGSE : 「JavaとEJBの仕様です。どもなりません」
0043デフォルトの名無しさん
NGNGそりゃしょうがない。EJBが遅いというのは事実は事実。
でも今時サーバサイドJavaが遅いなんていってると初心者扱いされちゃうぞ。
前にも書いているようにEJBを採用するなら最初からパフォーマンスは諦めろ。
パフォーマンスよりスケーラビリティを優先するようなシステムに使用すべき。
あとセキュリティとかトランザクションとかを気にしないシステムにEJB使うのは
あまり意味ないな。
> SE : 「JavaとEJBの仕様です。どもなりません」
このテのSEって、技術のせいにして、自らパフォーマンスを解決させようとする
自発性に欠けてるよね？逃げてるというか。俺の周りにもいるよ（ｗ
こういう現場に限って、外部の専門家が調べてみると、APサーバの設定値が全て
デフォルトでEJBコンテナやORBのカスタム設定してないとか、
SQLでインデックスかからないクエリー平気で流してるとかいうことがままある。
レスポンスに3分かかるEJBがあったから調査してみたらSQLでフルスキャン
してただけで、そこ直したら0.3秒になった･･･なんて話はけっこうみんなの周りにも
あるんじゃない？
0044デフォルトの名無しさん
NGNGだからさあ
Javaファミリが遅いのは漏れだって1995年から知ってるよ
遅いのを速くする気概のある椰子がJava鋳には皆無なのが悲しいのよ
で、解決方法でCORBA C/C++で生自作できる技術者がいないあなたの会社が
悲しいわけよ
> SE : 「JavaとEJBの仕様です。どもなりません」
だからさ、とにかくJava以外の実装でコンポーネント思考で
ミッションクリティカルで速けりゃいいんでしょ
それであなたの大好きなJavaから呼び出せれば万歳でしょ
もっとがんばってよ、新しい考え方とか出来ないのかな?
EJBの遅さ(これはあなたも認めている)については
分散Objectの内部インプリメントをJavaでやっている
ここをネイティブなコードにすれば多少は速くなるでしょう
それに分散EJB@Javaインプリメントがどんどん増えた時の事考えてよ
遅いのが積もれば動かない(とまったような)サービス提供になってしまうのでは?
分散で公開するんだから、将来的な再利用のための壮大なビジョンを含めての
設計思想を打ち出して欲しいのよ、優秀なる巨額な案件のSEさんならさあ
・・・・・・・・・・・・・・・・・・・・・
漏れはJavaだけで解決するのがどうだろうか?
って言っているわけよ
業界のために言っているつもりなんだけどね
頼むよ、優秀なるSEさん
0045デフォルトの名無しさん
NGNG1995 年から頭が進化していないの間違いだろ? な?
じつは Java あまり使ったことが無いだろ? な?
実に香ばしい匂いがするよ。優秀なる Sﾖ さん
004643
NGNG>でも今時サーバサイドJavaが遅いなんていってると初心者扱いされちゃうぞ。
って書いてあるのに
>Javaファミリが遅いのは漏れだって1995年から知ってるよ
って。お前どうせJavaでAppletくらいしか作ったことないだろ？
Javaオンリーのソリューションに懐疑的（これは俺も同意だが）、
ネイティブコードﾏﾝｾｰ、CORBAの話を持ち出してくるといったあたりから察するに
死滅寸前のCORBA C/C++に従事していた人なのかな？
CORBAが流行らずにEJBが流行った理由を説明してほしいな。
VisiBrokerもOrbixもTOBrokerも、みんなAPサーバになっちゃったよね？
ところでキミはSOAPについてどう思ってる？
ApacheではXindiceとかが最近急にIIOPを破棄してSOAPにリプレースしてるけど、
EJBで遅いといってるならWebServiceはどうなるのかな？
0047デフォルトの名無しさん
NGNG0048デフォルトの名無しさん
NGNGハードウェア技術者がいくらがんばってもソフトウェア技術者がそれをダメにする。
ムーアの逆定理。
0049デフォルトの名無しさん
NGNGHotSpotVMの発想は、進化すればCコンパイラがはく静的なバイナリより
早くなるチャンスがある。現状でもまあまあいい線いっている。
Javaで性能が問題になるのは、JVMとOSとのインターフェイスの部分だ
よね。ネイティブべったりで高速化する手段をとることができないため
に性能が上がらないのは問題になってる。グラフィックスその他でｲﾛｲﾛ
APIと、各OS用ランタイムを作りまくって解決しようとしてるから、その
うちなんとかなるとおもうけど、まだちょっとつらいみたい。
クライアントサイドのUI部分についてはﾓｳｼﾊﾞﾗｸ待つしかないのかも。
バックエンドプロセスでボトルネックになるのは、サーバが分散してい
る時のサーバー間リクエスト交換の作業でそ。EJBってのは、リモート
に置かれたサーバプロセスのようなものなんだから、扱い間違えれば遅
いにきまってる。C/C++でCORBAつかったって同じでしょ。
0050デフォルトの名無しさん
NGNG0051デフォルトの名無しさん
NGNGDataAccessObject
ValueObject
このへんのJ2EEパターンを盛り込んでいなければ、遅いのは当たり前。
このへんのパターンを留意しなきゃいけないのは、CORBAつかっても同じ。
EJBいっぱい作って1トランザクションでクライアントから総なめコール
やってる馬鹿は、とっとと引退しろ。そういう低レベルなセンス（パタ
ーンなんぞしらんでも、内部的な仕組みが分かっていればどうなるかは
容易に予想がつくはず）で、分散システム開発は無理です。
0052デフォルトの名無しさん
NGNG005351
NGNGその結果によってスレッドの配置を動的に決定できるような仕組みが
できて、J2EEパターンのようなことをアプリケーション開発者が気に
しないでよくなるようになったら、いいなあ。
0054デフォルトの名無しさん
NGNG先日、Ｓ○ＮＹの製品を購入した
入っているはずの部品が一部欠品していた
電話を掛けてクレームを付けた所、宅配便で送ってくれると言う
すると、その部品を料金着払いで送って来やがった
うーむ、入ってなかったから、クレーム付けて送らせたのに
それを着払いで送ってくるとは・・・
全くもって何を考えているのやら
0055デフォルトの名無しさん
NGNG言えば払わなくて済むのに。
---- 常識で考えられることをできない>>431。その名は名無○さん ----
005643
NGNGちなみに俺は必ずしもEJBﾏﾝｾｰではないよ。
ただDCOM/COM+、CORBA、EJBと分散オブジェクト技術を一通りやってきて、
今はEJBやってるってだけ。（なのでCORBAを否定するつもりはない）
SQLチューニングもそうだけど、パターンも重要だよね。
EJBが内部的にRMIしてるってのを知らないヤツが、プロパティベースで
ネットワーク上に分散しているオブジェクト同士を通信させたりしてるのを見ると
ちょっと引く。getXXXX、setXXXXの１つ１つがネットワーク経由でSerializeされて
通信しているということが分からないんだよ。
てゆうかうちの会社、プロパティというある意味古典的オブジェクト指向の概念が
そのまま分散オブジェクトの世界でも通用すると思ってる人が多いんだよね。
で、ValueObjectとかStatelessなクラスといった概念に対しては
「オブジェクティブな発想じゃない」とかいって聞く耳持たなかったり。
0057デフォルトの名無しさん
NGNG実行時性能と、OO的発想（と、それがもたらす管理の容易さ）は、
システムの要求できまってくる天秤の両端ですよね。
VOとかは、純粋なOO的にはアホですが、分散OOのRMI実装の方法
としては「やらないと遅くなるからしかたなく」ですね。
きく耳持たないSEなんてのは、SEじゃなくて単なるアホOOオタク
です。
0058デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
NGNG006057
NGNGValueObjectがおかしいと言い出すアホには、
「GoFのProxyパターンでEJBプロキシを作りましょう」といって、
回避することが可能かも。
VOじゃなくて、ローカルにEJBのキャッシュを置くという発想なら、
アホにも理解できるんちゃう？コミットしたら纏めてリモートEJB
と同期するとかすればええ。IBMのDeveloperWorksの日本語Art
icleで「遊離クローンEJB」と題打ってでｵｽｽﾒしてるよ。
0061デフォルトの名無しさん
NGNG0062デフォルトの名無しさん
NGNGEJB2.3のローカルインターフェイスですね。RMI経由でのサーバアクセス
を回避するです。仕様で可能になっても、APサバが対応しないと使えません。
Weblogicあたりなら、もうつかえるかも。
0063デフォルトの名無しさん
NGNGへぇ？そんな計画があるんだ？勉強不足ゆえ知らんかった。
まぁ今でもローカルならGIOPにするとか工夫してるんじゃなかったっけ？
>>57
妙案！！
0064デフォルトの名無しさん
NGNGGIOPが何なのか知らないみたいだね。言いたい事は推測できるけど。
ローカルEJBコールの時にマーシャリングを回避するためのオプションはある。
まぁ非標準だし、注意しなければならない事もあるから、標準化しようって事じゃない？
0065デフォルトの名無しさん
NGNGEJB2.1のLocal Interfaceならもう当たり前のことですが?
0066デフォルトの名無しさん
NGNG>>65
2.1をサポートしている主流どこのアプリケーションサーバって
どのくらいあるのですか(安定運用できるものに限る)
>>皆様
CORBAって死滅したのですか
CORBA単体でサービスを上げる製品は無くなったのですか
(VisiBrokerなど)
0067U ◆CZtFsGiu0c
NGNGWeblogicのサポートについては、
http://www.beasys.co.jp/e-docs/wls/docs70/ejb/cmp.html#1116678
こんな感じですね。
今までだとEJB使うにしてもSession Bean + DAO(JDBC)って構成がよく
採用されていたけど、Session Bean ＋ Entity Bean（ローカルインタフェース）
って構成も普通にできるようになりそうですね。
0068U ◆CZtFsGiu0c
NGNGCORBAは分散オブジェクト環境の基盤技術になりつつありますね。
EJBもRMI/IIOPサポート必須だし、アプリケーションサーバもCORBA
ベースのものが結構あります。
単体でのCORBAはOrbix、Visibrokerが2大勢力ですがレガシーシステムを
ラッピングする以外では直接使われなくなるんじゃないでしょうか。
0069デフォルトの名無しさん
NGNG0070デフォルトの名無しさん
NGNG0071デフォルトの名無しさん
NGNGプロトタイプだったらもっとちょろい言語があると思うが・・・・
0072デフォルトの名無しさん
NGNGttp://homepage2.nifty.com/rohizuka/ka/pa_003_a.htm
0073デフォルトの名無しさん
NGNGどこかで見た URL だな
多分人形の悲鳴だと思うが。
0074デフォルトの名無しさん
NGNGJMSってSOAPサポートしてたよねえ？
0075デフォルトの名無しさん
NGNGVisiBroker 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を利用しなくとも
いけそうです。
0076デフォルトの名無しさん
NGNGEJB（というかRMIサーバ）とCORBAサーバでどういうコード動かしてる
かによるじゃん、そんなの。
あと、EJBのデプロイって面倒か？どんなAPｻﾊﾞつかってるの？
デプロイ記述は、静的にコード内部で書いていたプロパティ設定を、
動的変更可能なようにパラメータ化して外部リソースに移しただけ
のはずだが。
>これにSQL APIを利用できるようにしてトランザクション管理と
>セッション管理を独自インプリメントすればEJBを利用しなくとも
>いけそうです。
そういうのをAPIｻﾊﾞに任せて手抜きする為に存在するのがEJBの枠組み
じゃないのか？
全部そのプロジェクト専用にチューニングしたライブラリ自作したら早い
にきまってる。それに費やされるコストとの比較で単に手段を選択する
だけでそ。
全部自作したがるPGオタ馬鹿ってどこにでもいるけど、それにどういう
意味があるのか一歩引いて考えてから方針決めてるのか？
0077デフォルトの名無しさん
NGNG速度はEJBより速いらしいし、言語非依存だし、規格自体はベンダ中立だし。
これが流行ってればそもそも（CORBAのサブセットである）EJBが普及する必然もなかったのにね？
VisiBrokerもOrbixもすっかりJ2EEサーバ化しちゃって、CCM対応を初めとするORB単体としての
バージョンアップは考えてないみたいだから。
商用ORBが無くなる時点でCORBAが復活する見込みはなくなるね。
CORBAが現に流行ってないってことは速度というメリットを打ち消すくらいの致命的なデメリットが
あったということなんでしょ？
別に煽りじゃなくって、昔CORBAをやってた者の素朴な疑問なんです。
ベンチ出されたからって、それだけじゃあEJBとCORBAの優劣にはあまり関係ない。
そもそもEJBとのベンチ取るなら、最低でも
ネーミング・サービス、オブジェクト・トランザクション・サービス、セキュリティ・サービスくらいは
経由してもらわないと比較にならないと思うんだけど、これらのサービスは使ったの？
できればEJBコンテナが機能として実装しているイベント・サービス、ライフサイクル・サービス、
エクターナリザーション・サービス、パーシステント・ステート・サービスもかましてくれると
ベストだけど。
0078デフォルトの名無しさん
NGNGネーミング・サービス ・・・ J2EEのJNDIに相当
オブジェクト・トランザクション・サービス ・・・ J2EEのJTS/JTAに相当
セキュリティ・サービス ・・・ 分からないけどEJBコンテナにはある機能
イベント・サービス ・・・ J2EEのJMSに相当
ライフサイクル・サービス ・・・ EJBコンテナが実装する機能
エクターナリザーション・サービス ・・・ スマンこのサービス知らない
パーシステント・ステート・サービス ・・・ EJBコンテナが実装する機能
かな？よく分からないけど。
0079デフォルトの名無しさん
NGNG仕様決定プロセスが遅すぎ。需要があるのにきまらないと、
簡単実装でデファクトスタンダード化したものにプロトコル
全体を乗っ取られるという歴史は、昔からくり返されてます
の。
0080U ◆CZtFsGiu0c
NGNGCORBAの黎明期に使っていた立場からすると、やっぱりコーディングの
ややこしさが一番でしょう。各種オブジェクトサービスにしても結局自分で
設計・コーディングしなきゃならないわけで、そのようなサービスをコンテナが
提供してくれるEJBの簡略さに比べると、やはり敷居の高さは感じます。
CCMもちょっと遅かったかもしれませんね。
でも、CORBAはインフラ技術として残っていくでしょう。ソケットプログラミング
する機会が減ったからといってTCP/IPが消えたなんて誰も言わないし:-)
0081デフォルトの名無しさん
NGNG誰も言わないどころか見当違いも甚だしいと思うが。
例えが悪すぎ。
0082デフォルトの名無しさん
NGNG>>80
Uさんじゃないですか？CORBAスレでもお会いしてますね。
CORBAは俺も黎明期に使ってたので、知らない間に廃れてしまってﾋﾞｸｰﾘしたよ。
J2EEやWindowsDNAみたいなWebサイト構築と技術的に直結してないのが原因かなぁ？
とかいろいろ考えてたんだけど、正直今でもよく分からない。
思うに、J2EEのような参考実装の提供がなかったから、結局CORBAサービスの実装も
ベンダ任せになってしまって、ORB間の互換性がなくなったというところも一因のような気がする。
以上、EJBと関係ないので終了
結局、EJBへの不満って「遅い」以外に出てきてないんだよね？今のところ。
俺はデバッグのし難さや、開発ノウハウの蓄積不足がけっこう気になるところなんだけどね。
ここら辺が解決しないと、EJBが第二のCORBAになる可能性も正直あると思う。
0083デフォルトの名無しさん
NGNG>デバッグのし難さ
どこらへんが難しいの?
0084デフォルトの名無しさん
NGNGhttp://www.microsoft.com/japan/msdn/columns/xml.asp
>たとえば、DCE (分散コンピューティング環境) や
>CORBA は実装するのに何年もかかり、
>たった 2、3 の実装しかリリースされませんでした
0085デフォルトの名無しさん
NGNGネットワーク上にコンポーネントが分散化されているからじゃない？
0086デフォルトの名無しさん
NGNGそれは認識が違うと思う。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関連のサービス関係については、宿題とする
0087デフォルトの名無しさん
NGNG>lookup関連のサービス関係については、宿題とする
Jiniでちゅか？とうとう日の目を見る日がきたのでちゅね？ﾜｰｲ。
008880
NGNG長文サンクス。いつものCORBA派の人かな？
>「もうCORBAは終わり」の発想はおかしいと思う
別に人によって捕らえ方は様々だと思うからあまり反論するつもりないんだけど、
少なくともCORBA 3.0が勧告されているのに対応する商用製品がない、またはかつての
ORBベンダに無視されているような現状では、やはり「終わり」だと思うよ。
2.3がもはや進化の必要がないほど完璧だというのなら話も分かるんだけどさ。
（俺はCCMにかなり興味あるんだけど、これも黙殺だし）
ただしつこいようだが俺はCORBAやってた人間だし、真っ向から批判するつもりはないよ。
ただこのスレがEJBの普及について語る場である以上、CORBAというある意味普及に失敗した
技術について語ることで、それを反面教師としてEJBにその教訓を生かす必要があると思うわけよ。
>あなたの考えだとまるで目先のJavaにしか思考が回らない
>ように見えるけど。そういう人が多いのがJava鋳の特徴でもあるのだけど。
ある意味それはCORBAがDCOMと戦っていた時代に辿ってきたのと同じ道じゃないかい？
CORBAも当時は目先のことばかり考えていたと思うけど、どうよ？
（俺の主観だけどね。COBOLとのマッピングを目指した方向性は間違っていないと思う）
分散オブジェクトは最も進化の激しい分野に１つだから、ある程度は仕方ないと思うさ。
ただ俺は別にJavaマンセーではないので、Javaが他言語（特にネイティブなC/C++）との
インターフェイスが取りづらい、ある意味閉鎖的な世界だというのは分かる。
眠いのでワケワカランこと書いているかもしれないが、こんなところ。
0089デフォルトの名無しさん
NGNG気もするCORBAだけど、IT革命(死後)を推進するキーワードとしての
役目が終わったということなんじゃないの？
インフラ的な技術としてはある程度定着したんじゃないかなあ。
GnomeやBerlinなどがCORBAを使っているのをみると、
通信方式としてのCORBAは依然有用だと思うね。
仕様があれば、それを共通認識としてソフトウェアを作ることができる。
個別に一からOMGの仕様に相当する部分を決めなくてはならないのは
大きな手間だし、ひどく無駄なこと。
仕様だけあれば決してなくなることはないし、いくつかまだ製品も出ている
以上、終わったとか終わってないとか言うこと自体、マーケティング用語に
影響されている証拠だと思うけど。
もちろん流行り廃りだけで採用技術を選択しているようなエンジニアにとっては
事例の少なさ故に、より手を出しずらいものとなっていくことに異論はないけどね。
おれも大した技術なんて持ち合わせてないので、これからCORBAを採用することは
まずないとは思うが、それはまた別の話だよ。
CORBAかEJBかなんて話よりもWebServiceどうなるんだろう？ってなら分るよ。
送信データにテキストを用いて、タイプシステムフリーにするっていう発想は
インパクトあるもの（あんまりよく分かってないので間違っているだろう。藁
そもときはごめんなさい）。それにこれからの技術でもあるし。
終わった終わらないよりも、これからの技術が来るのか来ないのかの
方がまだいくらか有益だと思うね。
0090デフォルトの名無しさん
NGNGすみませんが、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レスサンクス今日は眠いのでレスは後日で勘弁してください
0091デフォルトの名無しさん
NGNG009280
NGNGてっきり.NET派のやつらが煽りにくるスレかと（ｗ
CCMはMICO-CCMでちょっとやった程度なのでアレだが、コンポーネント化という
方向性はいいと思う。機能もEJBより豊富だし。
取っ掛かりとしてはここかな？
http://www.ogis-ri.co.jp/otc/hiroba/technical/CCM/step1/index.html
とはいうもののここはCORBAスレではないので、これ以上話をするのも正直どうかな？
そろそろEJBの話に戻そうぜ！
0093デフォルトの名無しさん
NGNG財務会計とか。小規模なWebシステムでは再利用する必要もないようなものばかりじゃない？
もっとお手軽で汎用的な目的のEJBコンポーネントがフリーウエアか安価なシェアウエアで
出回れば面白いかもって思うんだけど。営業日演算EJBとか。
あ、でもそういうのは別にEJBである必要もないのか？JavaBeansで十分？
0094デフォルトの名無しさん
NGNG> あ、でもそういうのは別にEJBである必要もないのか？JavaBeansで十分？
そっすね。
0095デフォルトの名無しさん
NGNG開発効率を20%上げるために二倍速い(5倍高い)ハードを買ってください、
となるんじゃない？ｗ
パソコン文化とはちょっと違うのさ。
>あ、でもそういうのは別にEJBである必要もないのか？JavaBeansで十分？
Sunに言わせれば、そういうところでもEJBを使ってくださいと
なるんじゃないの？
0096デフォルトの名無しさん
NGNG0097デフォルトの名無しさん
NGNGどうも長文の漏れです
しばらく休んでしまって申し訳ない
今、最新の環境を入手中です
EJB, CORBA, COMを含めて(宿題もありますね)
総合的なネタを興すための準備中です
いましばらくお待ちください
0098良スレ救済委員会
NGNG0099デフォルトの名無しさん
NGNG0100デフォルトの名無しさん
NGNG今のWebSphereV4じゃ使えんよ
0101デフォルトの名無しさん
NGNG1.3の勘違い？
ちなみにJ2EE1.3対応のWebSphereV5がやっとでたね。
0102デフォルトの名無しさん
NGNGBorland Enterprise Serverを入手しました
BisiBroker 4.5です
C++ Corbaの実装と、Java EJBの実装ができる環境です
しかし、Corbaの資料のないこと・・
英文マニュアルと付き合わないとだめですね
0103デフォルトの名無しさん
NGNGVisiBrokerですよね。
しかもVisiBroker4.5ということは、Borland Enterprise Server ではなく、
随分以前の Borland AppServer4.5 の間違いでは?
また、Borland Enterprise Server であれば、installディレクトリに
CORBAのプログラミングに関するpdfがあると思います。
0104デフォルトの名無しさん
NGNG亀レスですんません
テスト用を前提に
App Server
Enterprise Server
もろもろ全てお借りしますた
>また、Borland Enterprise Server であれば、installディレクトリに
>CORBAのプログラミングに関するpdfがあると思います。
情報ありがとうございます。除いてみます。
OMGにも出向いたのですが
ORBをインプリメントする資料は、やはりOMGにある仕様書しか
ないものでしょうか？無謀にもORBを自作したい希望があります。
ところで、いまさらながら.NETの XML, ATLサービスは凄いですね。
速い！ 勿論C++でのプロジェクト作成に限りますけど。
0105デフォルトの名無しさん
NGNGGnomeは落ち目、Fresco/Berlinもブレークする気配が全くない。
というところで「CORBAは現役だ!」って言われても困ってしまいます。
どちらもCORBAなんか使うから人が逃げちゃうんだ、って言われてるし...。
0106デフォルトの名無しさん
NGNGしかし、OMG に標準化をさせると重厚長大になっていかんね。
0107デフォルトの名無しさん
NGNG0108デフォルトの名無しさん
NGNGSession 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なだけ？
0109デフォルトの名無しさん
NGNG服装もダサそうだね。
わけわからんよれよれジーンズに穴のあいた靴下。
そして、何日も着て汚れきったシャツをジーンズにタックイン。
周りの人間に馬鹿にされてるよ？
0110デフォルトの名無しさん
NGNGそのとおりだけど、いっていることはただの一般論。
ちなみに、UPDATE table SET hoge = 10 WHERE foo > 50
程度なら、EJB2.0のEJB QL(Homeメソッド）を使えば、
Beanインスタンスが生成されることはない。
0111デフォルトの名無しさん
NGNG愛読書は FINE BOYS でつか？
0112IP記録実験
NGNGhttp://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を提出することがある。
0113デフォルトの名無しさん
NGNG0114デフォルトの名無しさん
NGNG0115デフォルトの名無しさん
NGNGなにをいまさら。通知実験の方はまだ？
0116デフォルトの名無しさん
NGNG0117デフォルトの名無しさん
NGNG(・∀・)ｲｲ!!
0118デフォルトの名無しさん
NGNG名前や住所が表示される訳じゃないし。
0119デフォルトの名無しさん
NGNG0120デフォルトの名無しさん
NGNGってのは受信したよってことすか、、？
0121デフォルトの名無しさん
NGNGそうそう。なんでも今年の風邪は高熱が出るらしくて。
って手遅れかい。まぁ再発に気をつけろってことで。
0122デフォルトの名無しさん
NGNG0123デフォルトの名無しさん
NGNGhttp://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
和製英語にでも登録するか(笑
0124デフォルトの名無しさん
NGNGンな事よりWin板やソフト板のアレを何とかしてくれ。
0125デフォルトの名無しさん
NGNG2chに個人情報の保護をお願いする方が間違ってると思われ
事実上IPは誰にも見れる様になるだろうね、まあその中でプロパイダの中に協力者がいる
のはごく一部だろうが、、、
0126デフォルトの名無しさん
NGNG0127デフォルトの名無しさん
NGNG1 ハングル
2 半角（ピンクは全部いらん）
3 ラウンジ
0128デフォルトの名無しさん
NGNG何日ぐらいログ保存するの？
0129デフォルトの名無しさん
NGNG0130デフォルトの名無しさん
NGNG0131デフォルトの名無しさん
NGNGむしろヤバいスレやレスをつけられなくなった連中の鬱屈した欲求が
さらなる糞スレ乱立に結びつきかねない。
0132デフォルトの名無しさん
NGNGその国の法律には従う必要あるが、匿名の許容度が日本よりゆるければ
今のシステムのままでももっと匿名度の高いものが出来るのでは？
いくらなんでも北鮮やイスラム圏じゃないから外国へ繋ぐのが違法だとは出来ないと思いますが。
0133デフォルトの名無しさん
NGNG２ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数： 139038人 発行日：2003/1/10
なにやら、連日メルマガだしてるひろゆきです。
そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。
重くなって落ちたりしてもご愛嬌ってことで。。。
んじゃ！
────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
0134デフォルトの名無しさん
NGNG0135デフォルトの名無しさん
NGNGひろゆきにSPつけるか。(w
これで暴力問題は解決っと。
0136デフォルトの名無しさん
NGNGこの騒ぎに便乗してスレストかかってるぞ。
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/
0137デフォルトの名無しさん
NGNG0138デフォルトの名無しさん
NGNG0139デフォルトの名無しさん
NGNG後半の批判は批判でいいと思うんだけど、書き込む人間の自己責任ってのとどう関係してるの？
0140デフォルトの名無しさん
NGNGの522からなんか出てるんですけど
2ｃｈってこんなに変わるの？
0141デフォルトの名無しさん
NGNG俺素人だからよくわからないが
アク禁にしないのは何か理由るのかな・・？
0142デフォルトの名無しさん
NGNG0143デフォルトの名無しさん
NGNGトップダウンによるキャッチアップは効果的だとは
思うが、所詮真似事だからどこかに歪みが出て
来そうなんだよね。
0144デフォルトの名無しさん
NGNG２ちゃんからリンクして拾ってくるようにできんかな？
0145デフォルトの名無しさん
NGNG厨房逝ってよし。
0146デフォルトの名無しさん
NGNG人がいるけど、それって何をするとでるの？
俺は見たこと無い。
0147デフォルトの名無しさん
NGNG0148山崎渉
NGNG0149山崎渉
NGNG0150デフォルトの名無しさん
NGNG0151デフォルトの名無しさん
NGNGSunが潰れたりしないだろうか。Javaより先に死んで
しまいそうなんだけど。サポートのなくなったSunにどれだけの
価値があるのかね。
0152デフォルトの名無しさん
NGNG0153デフォルトの名無しさん
NGNG0154デフォルトの名無しさん
NGNG0155山崎渉
NGNG（ ＾＾ ）＜ ぬるぽ（＾＾）
0156山崎渉
NGNG（ ＾＾ ）＜ ぬるぽ（＾＾）
0157デフォルトの名無しさん
NGNGアホ雑誌とかの、「コンポーネント(部品化)＝ＥＪＢ」を丸呑み
して、使いまわすためには、ＥＪＢ化が必要と勘違いする
香具師が多い。
実行速度より、生産性低下の弊害の方が深刻。
標準でも物理サーバごとに配布すれば、共有可能。むしろ
ほとんどの場合その方が望ましい。分散処理において初めて
ＥＪＢが必要になる。
「部品化」、「コンポーネント」、「分散処理」などの
用語の定義を明確にせずに、「コンポーネント(部品化)＝ＥＪＢ」
という宣伝は非常に危険。
現在のＥＪＢの使用範囲はイントラ内の分散処理に限定。インターネット
はＳＯＡＰの守備範囲。
0158デフォルトの名無しさん
NGNG0159デフォルトの名無しさん
NGNG0160デフォルトの名無しさん
NGNG0161デフォルトの名無しさん
NGNGEJB2.0はリモートじゃなくても使えるぞ。
ＥＪＢの強みであるコンテナがトランザクションを管理するというのを忘れてないか。
俺はたいていのものはＥＪＢでトランザクション管理を行って作っているが、生産性
低下はしていない。
イントラ内というのは、その通りだがもとからそのつもりのはずだ。EJBの呼び出し
をインターネット上で行うのというのは普通想定しないだろう。
ちゃんと、EJBの勉強してから書かないと恥かくぞ。
>>159
万能はさすがに言い過ぎじゃないか？
>>160
Webで検索すると、JBoss+PostgreSQLのことが書いてあるページがあるから、でき
るんじゃないの？
0162デフォルトの名無しさん
NGNG0163デフォルトの名無しさん
NGNGOracleでできてPostgreSQLでできねーわけないだろ
0164デフォルトの名無しさん
NGNGOracle8/9i AS ならEJBサポートしてるけど。PostgreSQLとは分野違いだね。
Oracle9i DBには、EJBのサポートあるの？
>>160
PostgreSQL＋JBOSSならできそうだけど
0166デフォルトの名無しさん
NGNGOracle8iDB自体で多少サポートしていたかなー、とうろ覚えの記憶で書きました。
0167デフォルトの名無しさん
NGNG0168デフォルトの名無しさん
NGNG0169_
NGNG/〃⌒⌒ヽ
〈〈 ノﾉﾉﾊ)）) ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|ヽ|| ´∀｀||＜ 先生！こんなのがありました！
＿φ╂∨⊂)__ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
／旦／三／ ／|
|￣￣￣￣￣| |＜ http://freeweb2.kakiko.com/saitama/
|＿＿＿＿＿|
0170160
NGNG寝ちゃってました。
DBでサポートしているかどうかというよりは、そのＤＢ向けのJTS対応JDBCドライバ
があるかどうかということにかかっている。
ＤＢが管理するのはＤＢローカルのトランザクションであって、EJBとは直接関係ない
です。
普通はＤＢのベンダが提供していることが多いのだが、アプリケーションサーバの
ベンダが提供することもある。
WebLogicではドライバが対応していなくても、アプリケーションサーバでそれを補う
機能があるらしい。
PostgreSQLのことに関しては知らないので、最後に"?"を付けたわけです。
0171デフォルトの名無しさん
NGNG157が言ってるのは、コンポーネント化=EJBってのがそもそも
おかしいんじゃない、ってことじゃないの？
EJB使えばコンポーネント化できるとか、EJB使わないと
コンポーネント化できないとか、そんなん関係ないじゃん。
大体コンポーネントって言葉自体、あいまいで詐欺みたいな
もんだしね
なんでもかんでもEJB使わなきゃいけないと思い込んでる
アホな椰子は結構いる。特にあまりJ2EE実装したことない
マネージャ層に多そうだ。その一言で生産性下がったりするのにね。
EJBは生産性下がると思うよ。普通のローカルクラスで組んだほうが
テストが楽。それに世の中EJBな知識のある人はいまだに少ないので、
多人数プロジェクトに展開するには、ラップしてあげないといけない。
そうするとcFrameworkみたいに何でも実行できるEJBのガラがある
だけで、コンポーネントも糞もないような設計になる。
0173161
NGNGcFrameworkはフレームワークであって、コンポーネントとは言わないような気
がするが。
フレームワークは枠組みであり、コンポーネントは機能のまとまりだろ。
おれが157から読み取れるのはＥＪＢはリモート環境でしか使えないということ
だったんだよ。
だから、ＥＪＢはリモートだけではないと言っている。
コンテナにデプロイしなくてはならないという点では、普通のクラスを使うよりも
手間がかかるというのは確かにある。
だが、そのあたりはant、JUnitなどでテストを自動化すれば時間がかかるという
だけで、それほど面倒なことではない。
それから、トランザクションの管理を任せられるという点ではコーディングは楽に
なる。
俺はどんなプロジェクトでもEJBを使っているが、生産性が下がるとは思えない。
0174デフォルトの名無しさん
NGNGはいはい了解。たしかConnector Architectureとか呼ぶ仕組ね。
わかったよ。PostgreSQL用JDBCドライバーの現状調べてここに書くなんて殊勝な事する気にはならんが。
SRAのページ見たらなんか情報あるでしょうよ。
0175bloom
NGNG0176デフォルトの名無しさん
NGNGちなみに PostgreSQL を DB にできる EJB コンテナってありまつか? ってのが
本意ね。
0177デフォルトの名無しさん
NGNG0178161
NGNGすまん。今気がついた。161が160と間違えました。
0179デフォルトの名無しさん
NGNGもう少し丁寧に謝れ。
0180デフォルトの名無しさん
NGNG市ね。
0181171は愚痴っぽい
NGNGcFrameworkのような、何でも実行できるコマンドパターンだと
プロパティに設定さえすれば、どんなコマンドでも実行できてしまう。
それってインタフェースが曖昧だし、最終的に色んな機能を含んだどでかい
EJBが出来上がる可能性が高い。その場合、何を持ってコンポーネントって
呼ぶの？と疑問に思ったので書いてみた。
テストについては、JUnitだけでは全然網羅できないと思うよ。
データベースや他システムとのインタフェースもJUnitでやってます？
そこまでやろうとすると費用対効果が一気に落ちてしまうよね。
JUnitではせいぜいロジックをたたいてみる程度の確認しかできなくて、
結局、開発者レベルで頻繁に動作確認する必要が思う
まあEJBラップしてれば、そんなに大変ではないのは同意なんだが。
少人数でスキルある人がそろっているプロジェクトなら、EJB＋JUnitでも
ある程度ばりばりいける可能性があるけど、未だにJava初心者だらけの
プロジェクトも多いんだよね････てか、自分が今そういう状況。
おまえら無理しないでEJB使わないでやれよと小一時間ほどry(
0182161
NGNGいろいろ検索してみると、cFramework用のコンポーネントというのがあったよ。
コンポーネントというと、ある機能の集まりというイメージがいいと思う。
例えば、オンラインショッピングでいうと会員管理、購買、決済、などの機能で
ひとつのjarファイルとしてやるのをコンポーネントと考えています。
このまとまりは人それぞれ違うと思うが、上のようなものだと思う。
それで、テストですが、データベースも他システムとのインターフェースもやる
ことありますよ。
全てにおいてJUnitでやっているわけではないが、できるだけ作るようにしてい
る。
あるプロジェクトでは全ファイルのうち３分の１がテストケースになりました。
データベースはテストデータをXMLで記述して、テストのたびにそれをセットし
て、テストが終わると削除するということをしている。
これにはDBUnitというツールを使っている。
当然、これをするには一人につきひとつのスキーマを用意する必要がある。
確かに実際、こちらは少人数でやっているからこうしているし、外注が数人入っ
ただけでもできなくなってしまいます。
それから、EJBといってもステートレスセッションBeanしか使わない。
つまり、トランザクションの管理だけを行わせているだけです。
0183デフォルトの名無しさん
NGNG>EJBは生産性下がると思うよ。
こーいう人、今だに居るんですね...。
EJBをちゃんと理解していない証拠です。
0184デフォルトの名無しさん
NGNGこんな人、まだ居るんですね。
EJBの使用経験が無い証拠です。
0185デフォルトの名無しさん
NGNG値段高いし、あまりメジャーじゃ無いけど。
cBankにあるようなEJBコンポーネント群を売る商売が
成り立つかどうかでEJBの状況も随分変わると思う。
0186デフォルトの名無しさん
NGNGこんな人、まだ居るんですね。
EJBを理解せずに開発してプロジェクトをトラブらせた証拠です。
0187デフォルトの名無しさん
NGNG個人的にはStrutsが一番バランス取れてると思うが。
turbineは難しいし。
cFrameworkは高価だし。
JBossは使った事無い。
0188デフォルトの名無しさん
NGNGフレームワークの対象ドメインによる。
JBossをそこに並べるのはかなりおかしいぞ。
0189デフォルトの名無しさん
NGNGスレ違い？
0190デフォルトの名無しさん
NGNG普通にEntityBeanのデータソースからコネクション取得すればいいの？
0191デフォルトの名無しさん
NGNG> EntityBeanのデータソース
意味不明。
0192デフォルトの名無しさん
NGNG正気か？つーか、お前の会社ではEJBの理解度がそんなに高いのか？
IとかHとかEとか渡り歩いたけど、「これぞ！」ってな使われ方してるとこ見た事無い。
皆「EJBはひとつのコンポーネントだから云々」とか
「再利用性云々」って言うばっかりで、文字通り”豆知識”な連中ばっかだった。
で、>186の言う通り
＞EJBを理解せずに開発してプロジェクトをトラブらせ
てました。なんだかなあ。
日本でまともにEJB使える会社ってどこがあるだろな。
漆ステムズとか行ったらまた違うんだろうか。
0193デフォルトの名無しさん
NGNG意味不明。
とか言う前に
勉強しろ。
0194171
NGNG161さんの環境がうらやましい･･･
EJBにさせる価値のある仕事は、せいぜい分散とトランザクションしかないと
思ってます。が、トランザクションはJTA直接叩くことで代用できないもので
しょうか？
JTA使えば少なくとも、Connection引き回すことはなくなるので、それで
十分だと思っているのですが･･･
>>183
では理解しているあなたがわかりやすく説明してください
万人が理解できない説明＝脳内妄想
ってことを踏まえた上で。
>>192
日本以外でも、きっと同じじゃないでしょうか
Jakartaな人々がEJB嫌いなのも、多分似たような理由だと思われます
ある程度理解している人間同士でよく話題に出るのは、
「何でこのシステムにEJB使うんだよ」
てな話題だったりしますし･･･
0195161
NGNGJTAを直接使うというのはやったことありませんので、比較できないのですが、
JTAを直接たたける人と、EJBを使える人の人数ではEJBが使える人の方が
確実に多いと思うので、EJBの方がいいと思います。
「何でこのシステムにEJB使うんだよ」 という台詞はあるプロジェクトでお客に
言われたことあります。
でも、rollbackをきちんと書くことを考えると、見えないところで良い部分がある
と確信して、使いました。
それにしても、ステートレスセッションBeanだったら、普通のBeanと大差なく、
トランザクションも管理してくれるのだからすごくお得だと思うんだけど、違う
のかな？
0196デフォルトの名無しさん
NGNGJTA使って作るのも別に難しくないよ。単に解説とかの資料が少ないのと、
トランザクションの重要性を理解してる人が少ないからそう思うんじゃないの？
TransactionManagerはUserTransactionに少しメソッド足して
トランザクションを細かく制御できるようになってるだけだし。
適当なフレームワーク(Strutsとか)ちょこっと拡張して、JTA制御する
コードが必ず動くようにしとけば、エセCMTなら簡単ｂﾉ実現できるよ＝B
試ﾀ際にはJTSを実装してるのがWebLogicなり、WebSphereなりの
アプリケーション鯖だから、EJBで作るのが現実的なんだろうけどね。
フリーでいくなら挙動不審だけど、Tomcat+Tyrexって構成もありえる。
0197デフォルトの名無しさん
NGNG賛否両論 語ってくれ。と言え。学がないからEJBも愚か、日本語さえも
満足に使い切れない。
0198デフォルトの名無しさん
NGNG> IとかHとかEとか渡り歩いたけど、
EJBは派遣社員に理解できる代物ではない。
0199動画直リン
NGNG0200デフォルトの名無しさん
NGNGどれを勉強すれば一番就職に有利とか。
0201デフォルトの名無しさん
NGNG0202デフォルトの名無しさん
NGNGJavaなんて儲からないからやめとけ。
ドライバをガリガリ書きまくるのが一番儲かる（マジ
0203デフォルトの名無しさん
NGNGJiniサービスが本格的に始動おしたとき、おまいの職は失われるだろう。フッフッフ
0204デフォルトの名無しさん
NGNGこんな冗談言ってないで>>200の質問に答えてやれよ
0205デフォルトの名無しさん
NGNGほかはおまけ。JSPとServletはEJBを習得する前にやっておくと楽。
会社によってはEJBを使わずJSPとServletだけでやっているところもある。
JavaBeans? それだけだったら就職には有利でない。
BeanというものならJSPなどでところどころで使われている。
0206デフォルトの名無しさん
NGNG現実を知らないのと、理解がイマイチのようだな。
0207デフォルトの名無しさん
NGNG個人的には108の下記書き込みはあっていると思っているのだけど、
どうなんですか？
特に参照系はEJB使う意味がないような気がします。
更新系も微妙ですな・・・
>パフォーマンスが悪いのはまぁ仕方がないとしても、
>SQLでいうところの、UPDATE table SET hoge = 10 WHERE foo > 50
>みたいなことをEntity Beanでやろうとすると、Beanインスタンスが大量に
>生成されたりして大変じゃない？
0208デフォルトの名無しさん
NGNG参照系をどうにかするためにEJB-QLがあるのですよ。
まあ、かなり無理がある後付け仕様だと思うけど。
SQLつかうのとどう違うのよ、ということで。
0209207
NGNGすいません。おっしゃるとおりで・・・
基本的にEntityBeanで100件更新しようとしたら、
100のEJBインスタンスができるというイメージであってます？
そしたら1万件のレコード更新しようとしたらメモリ食いすぎて話にならないと思うんですが・・・
実際どうなんですか？
0210デフォルトの名無しさん
NGNGサーバのメモリは６GB～十数GB。と。
0211デフォルトの名無しさん
NGNGそんなもんEJBの作り方次第でしょ。
リストで抱えても何の問題もないよ。
0212デフォルトの名無しさん
NGNG即答するが、物理メモリでなく、VMヒープがパンク
0213デフォルトの名無しさん
NGNGEJBは１万件くらいで食らい尽くすようなものではないと思われます。
0214デフォルトの名無しさん
NGNGあのー、ガーベージコレクションって知ってます？
>>212
VMヒープの設定って、GBオーダは無理だっけ？ほんと？
0215207
NGNGEntityBeanのインスタンスってレコードごとにしか作れないのではないのですか？
EntityBeanの１インスタンス=複数レコード
にすることってできるのですか？
そうするとfindByPrimaryKeyメソッド等でぼろぼろになると思うのですがどうなんでしょうか？
素人で申し訳ありませんが、よろしくです。
0216デフォルトの名無しさん
NGNG参照系と更新系を分離して考えようね。
0217デフォルトの名無しさん
NGNG>>212 ではないが、今のところ Sun JDK 1.4 (Win/Linux)、IBM JDK
1.3 (AIX) は Maximum Heap 1.5GB が限界って所だな。試しに -Xmx???MB
で何GBまで行けるか試してみれ。
0218デフォルトの名無しさん
NGNGガベージコレクタのリソース回収に期待しすぎてたら痛い目遭いそうな予感。
VMヒープがGBオーダーできるか否かは気になるところ。
ServerVMのみ可能とかあるのかな？
0219デフォルトの名無しさん
NGNG0220デフォルトの名無しさん
NGNG期待ってなによ(ﾜﾗ
強参照チェインを消しておけば、メモリオーバーフロー起こす前に
消えてくれるでしょ。参照チェインの構造をライフサイクルにあわせて
付けはずしするだけで、別にあいまいな期待などしていませんが。
0221デフォルトの名無しさん
NGNGサーバー用途でVM複数立ち上げるような無駄なまねを
するより100倍ましかと。
0222デフォルトの名無しさん
NGNGｱﾌｫ な素人集団 (Iβ○の何とか Biz) がクライアント 100～500 規模の
イントラ業務を 1 台 (ホットスタンバイのみ) な構成にした時などの苦肉の
策として。100Mbps で9時-5時の入力しまくりボタン押しまくり攻撃はマジ
氏ねる。てか氏ね
0223207
NGNG更新系でも参照系でもEntityBeanクライアントでは
Finderメソッドで取得したリモート（ローカル）インタフェースを取得して
それに対して処理をするという方式は変わらないと思っているのですが、
（つまりFinderメソッドで１万件データCollectionデータが取得できたら、
１万件のEntityBeanがメモリにロードされる。）
間違っていますか？
それとも「EntityBean：レコード=１：N」に対応させて
一気に処理させる方法とかがあるのですか？
0224デフォルトの名無しさん
NGNG糞な設計だね。漏れのところは氏んでない。
まあ、分散させてるわけだがよ（藁）DB鯖、Web鯖を共用でイントラ５００人
の設計する鬼畜が能無し。
クライアントはエラーが出ようが、ブラウザ戻るボタンで前画面に戻ろうが、
ボタン押しまくるもの。自分の入力を是が非でも通そうと試みる。
0225デフォルトの名無しさん
NGNGせめてWeb,AP,DBでサーバは分けるべきだね。
特にAPサーバには高負荷かかるし。
0226デフォルトの名無しさん
NGNG> １万件のEntityBeanがメモリにロードされる。）
> 間違っていますか？
実装によるが、普通は間違っている。
そのCollectionの中身は実際にはEntityBeanを指すEJBObjectだろ。
EntityBeanインスタンスがすぐに１万件メモリにロードされるわけではない。
0227デフォルトの名無しさん
NGNG0228デフォルトの名無しさん
NGNG0229デフォルトの名無しさん
NGNG負荷は主に処理するデータ量に比例すると思うけど・・・
0230デフォルトの名無しさん
NGNG> 人数はコネクション数やテンポラリデータを増やすのかな？
テンポラリデータってどういう意味？
人数増加＝データ量増加
わかる？
0231デフォルトの名無しさん
NGNG利用者数が増えても扱うデータ量は増えないような・・・
増えるのは一時的に作られるデータだけでは？
0232デフォルトの名無しさん
NGNGDBだけ考えても人数増えたら、なにかしらのレコードは増えるが？
それでも扱うデータが増えないと言えますか？
3レコード検索と3万レコード検索ではどちらが負荷高い？考えるまでもないだろ。
0233デフォルトの名無しさん
NGNGフロントエンドに近いサーバほど大忙し。
0234デフォルトの名無しさん
NGNG「なにかしらレコードが増える」その量が、
利用者数に依存するとは限らない。
0235デフォルトの名無しさん
NGNGあんた、エンタープライズ開発したことある？
0236デフォルトの名無しさん
NGNGエンタープライズ開発かどうかに依存するとは限らない。
0237デフォルトの名無しさん
NGNG0238デフォルトの名無しさん
NGNGってかなりヤバいな。
0239デフォルトの名無しさん
NGNGこのスレの発展に依存するとは限らない。
0240デフォルトの名無しさん
NGNG0241デフォルトの名無しさん
NGNG0242デフォルトの名無しさん
NGNG「利用者数に比例してなんかしらレコードが増える」って。
なんせエンタープライズだからな。
0243デフォルトの名無しさん
NGNG意味不明
0244デフォルトの名無しさん
NGNG0245デフォルトの名無しさん
NGNGEJB,CORBA混合の環境。やはり利用者増加にしたがってCPU負荷も大きくなっている。
って、当たり前だが。
0246デフォルトの名無しさん
NGNG0247デフォルトの名無しさん
NGNGx * y * 8 と a * b * 7 どっちが大きい？
と、x, y, a, b が決まっていないのに話しているようなものだな。
0248デフォルトの名無しさん
NGNGエンタープライズって「企業」って意味。それだけ。
なにが飾りなのかと小一時間。
0249デフォルトの名無しさん
NGNGその負荷はCPUなのかメモリなのかディスクなのかネットワークなのか。
>>247
まったくそのとおり。
0250デフォルトの名無しさん
NGNG謎の計算式持ち出すな
0251デフォルトの名無しさん
NGNG0252デフォルトの名無しさん
NGNGCPU負荷です。
0253デフォルトの名無しさん
NGNGあんた、エンタープライズ開発したことある？
0254デフォルトの名無しさん
NGNG0255デフォルトの名無しさん
NGNG0256デフォルトの名無しさん
NGNGあんた、エンタープライズ開発したことある？
0257デフォルトの名無しさん
NGNG0258デフォルトの名無しさん
NGNGEJB
0259デフォルトの名無しさん
NGNG【＠】エンタープライズ、エンタプライズ、【変化】《複》enterprises、【大学入試】
【名-1】企業、事業、政府支援企業
【名-2】企て、計画、仕事、活動
【名-3】進取の気性、積極性、冒険心
java
【名】《米・口語》コーヒーbean
bean
【＠】ビーン、【変化】《複》beans、
【名-1】豆
【名-2】豆の形に似たもの、頭
【名-3】小銭、つまらないもの
【名-4】基本的な事柄◆【語源】豆はごくありふれた植物であるところから
【他動】《野球》ビーンボールを投げる◆【参照】bean ball / 【用例・名-1】 Every bean has its black. : 《諺》誰でも欠点がある。
0260デフォルトの名無しさん
NGNG>>248
＞エンタープライズって「企業」って意味。それだけ。
＞なにが飾りなのかと小一時間。
それだけ ってことはつまり それだけでしかない んだから
やっぱり 飾り なんじゃないの（ｗ
つか、大規模云々以外にもEJBのメリットとかあるんじゃないのかなとは思うけどな
漏れは使う機会がないのだが
0261デフォルトの名無しさん
NGNGEJB開発実績を作ることをメリットとして強要する会社もあるわけだが。
0262デフォルトの名無しさん
NGNG0263デフォルトの名無しさん
NGNG企業｛で｜が｝開発だな。
0264デフォルトの名無しさん
NGNG英語わからんので洋書は×
0265まめ
NGNG0266デフォルトの名無しさん
NGNGお前は、EJBもWebサービスも知らないだろ。
車と運転手どちらが優れているか語ってくれ
といっているようなものだな。
0267デフォルトの名無しさん
NGNG例えが曖昧。
0268デフォルトの名無しさん
NGNGじゃあ、こうしよう。
メソッド本体と、メソッドの呼び出し側、どちらが優れているか語ってくれ
といっているようなものだな。
0269デフォルトの名無しさん
NGNGそれは明確に優劣が出るだろ。
コアクラスのメソッドに文句言う香具師はそんなに多くない。Javaヲタくらいだ。
殆どの香具師は呼び出す段階で馬鹿やってる。
0270デフォルトの名無しさん
NGNGと言いつつ便乗。
電話とFAX、どちらが優れているか語ってくれ。
どう？
0271デフォルトの名無しさん
NGNG車(EJB) <-> 運転手(Webサービス)
メソッド本体(EJB) <-> メソッド呼び出し側(Webサービス)
要は、EJBは実装技術も含んだもの、
Webサービスは極論すれば単に他を呼び出すだけ
ということ。
0272デフォルトの名無しさん
NGNGEJBが大規模開発に向いている理由を教えてください。おながいします。
0273デフォルトの名無しさん
NGNG第一にトランザクション制御をしてくれること。
下手なプログラマに任せるよりコンテナで制御したほうが
間違いなくCommit or Rollbackしてくれる。
第二にインスタンスの使いまわし。
キャッシュやプールの仕組みがあるから、たくさんインスタンスができても大丈夫。
第三に分散オブジェクトであること。
サーバー分けた場合の呼び出しが楽。
こんなとこですかな。
0274デフォルトの名無しさん
NGNG回答ありがとうございます。
私の質問の仕方が悪かったかもしれないですが、
273さんの書いた理由は大規模開発だからの理由にならないと思います。
^^^^^^^^^^
JavaBeansで実装した場合に比べて、EJBを使用した場合
クラスタリングやアベイラビリティの面で違いはあるのでしょうか？
0275デフォルトの名無しさん
NGNG>>272
通常、大規模開発では、標準化や機能分割が厳密に要求される。
最初は面倒だが、全体では生産性・保守性が上がるため。
EJBは >>273 が書いてるようにトランザクション回りを各アプリでなく、
システム側で行っているため、大規模開発に向いている。
昔で言えばCICS上での開発のようなもの。
小規模開発でも使えるが、かえってめんどいかも。
0276デフォルトの名無しさん
NGNGEJBとはちょっと比較しにくい対象だと思うけど。
EJBはそれ自体がフレームワークだし。
サーバ上にRMIオブジェクトとしてサービスが実装されるわけで、
クライアントからすればネットワークそのものを意識する必要は無い。
0277デフォルトの名無しさん
NGNGいい勉強にはなるけど。
0278デフォルトの名無しさん
NGNG大規模開発といっても人によっていろいろ定義があると思います。
>JavaBeansで実装した場合に比べて、EJBを使用した場合
>クラスタリングやアベイラビリティの面で違いはあるのでしょうか？
EJBはAPサーバーが対応していればクラスタリングが可能です。
クラスタリングが可能なのはコンテナ上で管理されている
分散オブジェクトであということが理由の一つです。
オブジェクトのプーリングによって無駄なインスタンスの生成が減るので
可用性も向上すると考えていますが、どうでしょうか？
ただ、実装方式が違うので、全く同条件でJavaBeansと比べられるとは
思っていません。
オブジェクトプーリングなどは、Jakarta-commonsでも実現できますし。
EJBを無駄な仕組みだと思って使わないも自由。
提供される仕組みを上手く使おうというのも自由ですね。
既にある技術を上手く使いこなすほうが得策だと思いますが。
少なくとも独自の方式で実現するよりきちんとテストされている、
ベンダー製品の方が信頼性も高いと思います。
0279デフォルトの名無しさん
NGNG> ベンダー製品の方が信頼性も高いと思います。
そうでもないと思うぜ。ベンダー製品の良いとこなんてサポートくらいだろ。
他に良いとこないってわけじゃないけど。きっちりテストされてる保証はどこにもない。
頻繁に修正モジュール適用する場合だってある。
テストという意味では、不特定多数が関わってるオープンソースの方が信頼できない？
0280デフォルトの名無しさん
NGNG実際EJBクライアントとEJBを物理的に別サーバにすることは
あまり考えられないと思っています。
Servlet+JavaBeansではクラスタリングできないのでしょうか？
もしEJBを使わないでもできるとすれば、
EJBのメリットってトランザクション管理をコンテナ任せにするしかないような気がするのですが
いかがなもんでしょうか？
0281デフォルトの名無しさん
NGNG＞Servlet+JavaBeansではクラスタリングできないのでしょうか？
なぜできないと思う？EJB使わないとクラスタリングが不可能なわけ？
もっと根本から理解を深めた方がいい。今のあんたは目先の技術に執着しすぎ。
0282デフォルトの名無しさん
NGNG結局EJBを使わなくてもクラスタリングできるんですね。
そうすると、EJBをEJBクライアントと同じマシンで動かすという前提だと、
EJBのメリットってトランザクション管理をコンテナに任せるくらいしかないというのが結論になるのでしょうか？
0283デフォルトの名無しさん
NGNGそうだね。終了。
0284デフォルトの名無しさん
NGNG※あなたに訪れる死を回避する方法が一つだけあります。
それはこのコピペを一時間以内に７つ、別のスレに貼り付ける事です
/＼＿＿_／ヽ ヽ
／ ::::::::::::::::＼ つ
. | ,,-‐‐ ‐‐-､ .:::| わ
| ､_(゜)_,: _(゜)_, :::|ぁぁ
. | ::< .::|あぁ
＼ /( [三] )ヽ ::／ああ
／｀ー‐--‐‐―´＼ぁあ
0285デフォルトの名無しさん
NGNGで、そのうちEJBと似たような仕組みを自分たちでもう一回作り直すと。
0286デフォルトの名無しさん
NGNG結局ＥＪＢのメリットって言うのはそんなもんだ。
0287デフォルトの名無しさん
NGNG>テストという意味では、不特定多数が関わってるオープンソースの方が信頼できない？
じゃ、JBOSS使えば良いんじゃない。
>282
だから、インスタンスもコンテナが管理してくれるんだってば。
まぁ、分かってないのなら使わないほうが良いんじゃない？
>283
同感。既にあるものを使えない人たちの悲しい性だよね。
0288デフォルトの名無しさん
NGNG>>287同感。既にあるものを使えない人たちの悲しい性だよね。
ってのは、どうなのかな。そんなこといったらCOBOLでいいじゃんとか
Cでいいじゃんとかになっちゃう気がする。CORBAとかもね。
既にあろうとなかろうと、メリットがあれば使うし、なければ使われないって
だけじゃないかと思うよ。
漏れがJava使い始めた頃は、それこそ「何でJava？VBでいいじゃん」って
よく言われたもんだし。
0289デフォルトの名無しさん
NGNG0290デフォルトの名無しさん
NGNG0291デフォルトの名無しさん
NGNG0292デフォルトの名無しさん
NGNGResin＋JBoss(tomcat抜き)てな感じの構成になるのか？
0293bloom
NGNG0294デフォルトの名無しさん
NGNGEJBのどこに賛成してるのかを説明してから、
そういう事をいってください。
0295デフォルトの名無しさん
NGNG0296デフォルトの名無しさん
NGNGそんなにEJBっていいのか？
逆にめんどくさくないか？
って思える
0297デフォルトの名無しさん
NGNG禿同
0298デフォルトの名無しさん
NGNGプログラマとかデプロイヤとか
きちんと作業を分担できる環境（人数）で開発するのなら
EJB使ってもいいと思うけど
少ない人数で、しかもプログラマが
アプリケーションサーバ特有のことも
勉強しないといけないような現場では効率落ちると思う
EJBの開発って個々のEJBに対して
使用するDBの知識持ってるやつ
使用するAP鯖の知識持ってるやつ
デプロイヤ
Bean開発者
ってな具合に分けたほうがいい
分散処理目的よりも
そういう仕事を分けやすくするためにEJBがあるんじゃないか？とおもう
だから、開発要員そろってないのに無理にEJB使う
開発グループはおかしい
なんで、一人の開発者がAP鯖、DB固有のことまで
勉強しないといけないんだ？
CMPとか使っても（作業効率的に）結局意味ないんじゃない？
と思うのは当然
0299デフォルトの名無しさん
NGNGいまから準備しるってかんじだよな。
0300デフォルトの名無しさん
NGNGEJBで全ての機能使う必要ない。ってどこかに書いてあった。
少人数でロールする場合のやり方も書いてあったような。
0301デフォルトの名無しさん
NGNGどこに書いてありましたか
書籍でしょうか
0302デフォルトの名無しさん
NGNGSunか@ITか。記憶だから信用しないでくれ。
0303デフォルトの名無しさん
NGNGttp://www.atmarkit.co.jp/fjava/rensai/smartj01/fig1.gif
0304デフォルトの名無しさん
NGNG２年前くらいに騒がれてたね。シンプルだから俺も綺麗だと思う。
Javaを始めたばかりの人が突然EJBのシステム保守したらどうなることやら・・。
0305デフォルトの名無しさん
NGNG漏れ理解力足りないから、理解できたころには陳腐化してるんだろーなー。。。。
0306デフォルトの名無しさん
NGNG2年前ですか
おれ、昔から今でもこのやり方マンセーで使いまくってますよ
もう古いんでしょうか？トホホ
でも、ほんとに綺麗なのでStrutsを使う意味がわからない
もちろんValidateなどは使うけど
0307デフォルトの名無しさん
NGNGDeploytool使えばDD書かなくていいんだね
マジびっくりしたよ
WeblogicとかWebsphとかもそうなのかな？つかったことないでわからんけど
0308デフォルトの名無しさん
NGNG本当にそんなこと実際のプロジェクトでできると思ってんの？
0309デフォルトの名無しさん
NGNGおまえ学生だろ？なあ学生だろ？学生だと言え。
学生の身分で安易な発言してすんまそんでした。と言え。
0310デフォルトの名無しさん
NGNG何かくれ。
0311デフォルトの名無しさん
NGNG市販のJ2EEアプリケーションサーバではふつう。
0312デフォルトの名無しさん
NGNGJ2EE BluePrints には J2EE開発のロールが色々と挙げられている。
しかし結局、1人くらいしかいない super な開発者がほとんどの面倒を見る状況になってしまう。
1人もいないとそりゃもう悲惨。
0313デフォルトの名無しさん
NGNG使い分けている方に質問です。
１．使い分ける基準って言うのはあるのでしょうか？
２．CMPは基本的に１テーブル＝１エンティティBeanにしかできないのでしょうか？
0314山崎渉
NGNGﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
0315デフォルトの名無しさん
NGNG１．使い分ける基準って言うのはあるのでしょうか？
CMPでは実現できないEntityBeanを実装する時
２．CMPは基本的に１テーブル＝１エンティティBeanにしかできないのでしょうか？
たしか、EJB1.xでは、EntityBeanに「従属オブジェクト」というものを定義する
ことにより、一つのEntityBean内で複数のテーブルを処理できたが、EJB2.0では
仕様から外れた。
0316デフォルトの名無しさん
NGNG>CMPでは実現できないEntityBeanを実装する時
具体的にはなんですか？
0317デフォルトの名無しさん
NGNG315じゃないけど。
単純に１つのbeanが1つのテーブルを表していれば良いけど、複数の結合
を表しているオブジェクトを処理する時にはＣＭＰでは難しいので、BMPを
使うとSunのBLUEPRINTSにありましたよ。
0318デフォルトの名無しさん
NGNGベンダーごとにばらばら。
統一せんかい
0319デフォルトの名無しさん
NGNGたしかに
禿同だ
>>313-317
テーブルじゃなくてレコードだろ
ココのスレだったか（？）忘れたが
↑のレスにSUM（＊）使いたがってるやついたが
CMPだと面倒だよな
BMPのほうが楽かな
0320デフォルトの名無しさん
NGNGそれはまだCMRがないときの話でしょ。
いまはCMRができたから、それは関係ないよ。
むしろ、BMPの方がめんどくさいくらいなんじゃない？
0321317
NGNGそのとおり、レコードでした。
>>320
これも半分そのとおりで、EJB2.0がでる前のBLUEPRINTからです。
でも、EJBは持続先として、ＲＤＢに限定しているわけではないので、
BMPが必要なくなることも無いと思う。
CMRはRDBに限定されているような気がするのですが、そのあたり
詳しい人いるでしょうか。
0322デフォルトの名無しさん
NGNG> 詳しい人いるでしょうか
仕様上は限定されてないよ。
あくまでパーシスタンスレイヤーはプラガブルという前提にのっとっている。
（現実にはRDB以外のパーシスタンスメカニズムは存在しないと思うが。
OODBベンダーは出してくると思うけど、しばらくは相手にもされないでしょ。）
0323316
NGNG知りたいのはＲＤＢを使った時に、
CMPとBMPをどのように使い分けるべきかなのです。
特に>>315さんの言っている
「>CMPでは実現できないEntityBeanを実装する時 」が具体的に何を指しているのかが、
気になります。
CMP2.0が出た今BMPは必要無しですか？
EJB-QLに「Order by」がないといってもAPサーバベンダが独自で実装しているし。
0324デフォルトの名無しさん
NGNGBorlandのアプリケーションサーバは、複数テーブルにEntityBeanを対応させられるらしいが。
0325デフォルトの名無しさん
NGNG結局BMPとCMPの使い分けは好みによるってことですかねぇ。
>>315さんの言っていた
「>CMPでは実現できないEntityBeanを実装する時 」は具体的に何を指していたんだろう・・・
0326デフォルトの名無しさん
NGNG0327デフォルトの名無しさん
NGNG「>CMPでは実現できないEntityBeanを実装する時 」は具体的に何を指しているのですか？
0328デフォルトの名無しさん
NGNG0329デフォルトの名無しさん
NGNGJavaの真髄？なんのこと？
理由もなく意味のない書込みは止めてください。
「いいよ？」の意味もわからないし。
0330デフォルトの名無しさん
NGNG0331デフォルトの名無しさん
NGNGリフレクションによるメタプログラミングと、ClassLoaderの使い
こなしは、Javaの真髄の一つだと思うね。
URL指定で動的にクラスローディングできるって凄い楽だとおもう。
例えば、サーバプロセスを動作したままの状態でアップデートでき
たりする。
0333デフォルトの名無しさん
NGNG読めるんじゃない。事実は隠せないだろ？ﾌﾟ
EJBやったことあるってことは自分自身が一番知ってるはずなんじゃない？ｗ
0334デフォルトの名無しさん
NGNG話にならんなぁ。プ、とかｗとか言ってるところが寒いし。
まあ、くだらないしめんどくさいからもういいや。
0335山崎 渉
NGNG__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
0336山崎 渉
NGNG0337山崎 渉
NGNG│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
0338デフォルトの名無しさん
NGNG0339デフォルトの名無しさん
NGNG・トランザクション
・セキュリティ
・永続化
・メッセージング
を自動化する仕組み。
0340デフォルトの名無しさん
NGNG0341デフォルトの名無しさん
NGNG自動化というよりコーディングがなくなる。
ＥＪＢを使うと、>>339のようなＡＰサーバ基盤に必要な技術を
設定ファイル（デプロイメントディスクリプタ）に書くだけで良い。
0342デフォルトの名無しさん
NGNGメモリリークメモリリークメモリリークメモリリークメモリリークメモリリーク
メモリリークメモリリークメモリリークメモリリークメモリリークメモリリーク
0343sage
NGNG付録Aを読んだ。
169P/504Pまで読んだ。
0344デフォルトの名無しさん
NGNG0345343
NGNG242P/504Pまで読んだ。
0346デフォルトの名無しさん
NGNGそれいい本だよな。
0347デフォルトの名無しさん
NGNGせっかく読んでるなら、EJBが終わってないとこ語ってよ。
0348デフォルトの名無しさん
NGNG有名どころのアプリケーションサーバでは克服してきているし、
EJBQLのORDER BYとか動的なEJBQL構築とかも独自実装しているのもあるし、
変なオープンソースのORマッピングツール使うよりは、
EJBはよっぽど現実的（必須？）になってきていると思うのだがどうだろうか。
0349デフォルトの名無しさん
NGNG性能がいいわけでもないのにアホには使いづらいEJB
それだけで存在価値がなく終わってる
0350デフォルトの名無しさん
NGNGEntityBeanは、かなりまともになってきた印象。
ほぼ、CMPでいける感じ。
あいかわらずめんどっちーけどね。
動的なEJBQLってまだ標準じゃないんだっけ。
0351デフォルトの名無しさん
NGNGその独自実装てのが後々自分の首を絞めたりせにゃいいんだが。
0353デフォルトの名無しさん
NGNGメモリの使いすぎ→Full GCの発生。
何とかなりませんか？EJBを現場で使われている皆さんどのようにしてますか？
0354デフォルトの名無しさん
NGNG0355デフォルトの名無しさん
NGNG上の前提を満たすならば便利なことこの上ない。
じゃなければ、他の便利な手段が一杯ある。
(自分はEJBマンセー派)
0356デフォルトの名無しさん
NGNGおまけにメッセージ駆動Ｂｅａｎも使い勝手がある
0357デフォルトの名無しさん
NGNGどの種類のEJBを使っているかが書いてないが、
EJBをどうしても使いたいなら、ステートレスセッションBean
だけにしておけ。
それならほとんど問題は起きない。
0358デフォルトの名無しさん
NGNGEntityBeanは分散環境ではなく、
ローカルインターフェースで使うのが、
一般的だと思われ。
(自分はEJB終わってる派)
0359デフォルトの名無しさん
NGNGう～ん、微妙。
0360デフォルトの名無しさん
NGNG0361デフォルトの名無しさん
NGNG徹底的にソースのチューニング。
さらに起動パラメータのチューニング。
さらにメモリ増設。
さらに仕様の勝手な変更。
最後は出入り禁止。
0362デフォルトの名無しさん
NGNG0363デフォルトの名無しさん
NGNG0364デフォルトの名無しさん
NGNGもちろんないです。
>>357
そのStatelessSessionBeanでメモリ使いすぎ問題が起きてます。
EJBってそんなものなのですか？
Servlet＋JDBCと比較するとメモリ使用量が半端じゃないのですが・・・
0365デフォルトの名無しさん
NGNGステートレスセッションビーンで、メモリ使い過ぎるって、
どんなあほ鯖だよ。
晒しなさい。
SLSBは、デプロイ時にあらかじめプールしておく数を
指定できたりするけど、それが多すぎることはない?
0366デフォルトの名無しさん
NGNG普通は致命的なほどの差はないんだけどね。
戻り値がStringで、
SLSB→全部連結して返している
JDBC→レコードをfetchするごとにServletが print している
なんてことになってる、と妄想してみたり。
0367デフォルトの名無しさん
NGNGループの中で毎回インスタンス作ってたり
0368デフォルトの名無しさん
NGNGステートレスセッションビーンと関係無い堕炉。
0369デフォルトの名無しさん
NGNGEJBコンテナの問題じゃなくてアプリケーションの問題なんじゃないの。
0370＋＋＋
NGNGhttp://itpro.nikkeibp.co.jp/free/NC/NEWS/20031024/135886/
多分EJB開発だろうけどね。
0371デフォルトの名無しさん
NGNG0372＋＋＋
NGNG陥穽にはまる可能性が多いと思うが。
最近目にした「速度が出ない、という不満をよく目にするが、それはコーディング
がいたらないからだ」という記述を見て、まあそうかもしれないが、そうなりやすい
面をアプリオリに含んでいるという事だろうと。
370みたいな、出来てからパフォーマンス不足が問題になるっちゅうのは、
コミュニケーション不足というより、開発体制に問題があるだろうね。
WaterFallで、こういう新しい要素を含む開発をやれば、そうなりそうだ。
0373デフォルトの名無しさん
NGNGキャッシュするよう軽くリファクタリングすればよい。
これは、要件定義を間違えて丸投げに失敗した部長が中国のせいにして責任転換成功 と漏れは予測する
0374ＥＪＢじゃないと
NGNG→作業が見積もれる。人件費が浮く。後戻り作業がなくなる。
EJBを使わない理由：
→速度があがらない。
つまり、時間の問題。すでに解決する技術が普及しつつあります。
当然ながら、発注企業は見積もれるシステムを依頼する。
ＥＪＢをつかわないと、取り残されるよ。Webの世界でしょ。
0375デフォルトの名無しさん
NGNG×責任転換
○責任転嫁
0376デフォルトの名無しさん
NGNG見事に幻想に嵌ってるな
0377デフォルトの名無しさん
NGNG0378デフォルトの名無しさん
NGNG* 作業が見積もれる
* 人件費が浮く
* 後戻り作業がなくなる
という理屈が謎、で何故かその幻想を信じる人が少しコンピュータに詳しい人なんだよな。
素人より中途半端な知識の持ち合わせた人のほうが騙しやすい。
0379デフォルトの名無しさん
NGNG>素人より中途半端な知識の持ち合わせた人のほうが騙しやすい。
そ、キミのような中途半端なおバカをね(w
何でこの板はこんなにレベル低いんだ
0380デフォルトの名無しさん
NGNG0381デフォルトの名無しさん
NGNG0382デフォルトの名無しさん
NGNG0383デフォルトの名無しさん
NGNGServlet＋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
ビジネスメソッド終了
で、トランザクション範囲がビジネスメソッドにしたい。ってことはできるのですか？
0384デフォルトの名無しさん
NGNGすいません。補足です。
>SQL実行メソッドの際にDAO側でDB Connectしていますが、
>その方式って、SessioｎBeanの１メソッドでSQL実行メソッドを３回呼んだら、
>Connect/Disconnectを３回繰り返すってことですよね？
これって性能的に問題ありなのでは？
0386デフォルトの名無しさん
NGNGXAリソースは使う必要はないよ．
それは，2フェーズコミットが必要なとき．
今回は，Connectするのは，全部同じDBだろ？
0387デフォルトの名無しさん
NGNGDAOはConnectionオブジェクトを取得するだけだから、
*実際に* 接続するかどうかは考えなくていいよ。
0388デフォルトの名無しさん
NGNGいってることは間違ってないけど、
実際ほとんどのあぷさばは、コネクションプールと
トランザクションの連携にXAConnection,XAResourceを
使っている。
JDBC Driverで提供されていない場合は、あぷさば側が
疑似XA機能を提供している。
0389383
NGNGすいません。
勉強不足で申し訳ありませんが、
DBコネクションをまたがったトランザクションができる理由を教えていただけますか？
コネクトを一旦きったら、DBMSがトランザクションを自動コミットするのではないのですか？
それともDataSourceを使ってコネクションプーリングの設定をAPサーバにしておけば、
Javaのソース上はdiscconnectしてもDBに接続されたままになっているのですか？
0390デフォルトの名無しさん
NGNGjava.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 あたりを読めばいいと思う。
0391デフォルトの名無しさん
NGNGいれこ(Nested)のトランザクションをサポートしたあぷさばは、
ほとんどないと思われ。
コネクションプールとトランザクションの連携について書いてある
ドキュメントってJ2EEの仕様書くらいしか見たことないけど。
JTAのほうね。
0392デフォルトの名無しさん
NGNGコメントありがとうございます。
データベース接続は DriverManagerを使わず、DataSourceを使用して、
コネクションプーリング DataSource#getConnection() を使用しています。
トランザクションの管理はJTAを使わず、CMTでAPサーバに任せています。
上記にて
１．SessionBeanのメソッド呼出（→EJBコンテナよりトランザクション開始）
２．【DAO1】DataSource#getConnection()でコネクション取得
３．【DAO1】SQLの実行
４．【DAO1】コネクションのクローズ
５． ビジネスロジック
６．【DAO2】DataSource#getConnection()でコネクション取得
７．【DAO2】SQLの実行
８．【DAO2】コネクションのクローズ
９．SessionBeanのメソッド終了（→EJBコンテナよりトランザクション終了）
としたときに、
（次へ）
0393デフォルトの名無しさん
NGNG通常コネクションクローズした際に、DBの自動Commitがきられると思っているのですが、
そのようなことは発生しないのでしょうか？
発生しないのであれば、どのような方式になっているのでしょうか？
思いつくところであれば、
（下記は個人的な予想です。）
「４．」の時に実はDBコネクトはしていない。DBへ接続したままにしている。
0394デフォルトの名無しさん
NGNG>>393は392の続きです。
0395U ◆CZtFsGiu0c
NGNG>通常コネクションクローズした際に、DBの自動Commitがきられると思っているのですが、
そのようなことは発生しないのでしょうか？
発生しません。
> 「４．」の時に実はDBコネクトはしていない。DBへ接続したままにしている。
同じコネクションが返されるどうかはわかりませんが、トランザクションの処理はきっちり
コンテナがやってくれます。また、コネクションプールから取得したコネクションをクローズ
してもプールに返されるだけでDBへの接続が切られるわけではありません。
0396sage
NGNG0397デフォルトの名無しさん
NGNG鯖によっても違うと思うけど
トランザクション中にcloseされた場合は、トランザクションに
関連付けられているXidをキーにしたMapに状態が
保存される。
次に、getConnection()されたときには、トランザクション中であれば、
Xidをもとにおんなじトランザクションが返されるよ。
0398デフォルトの名無しさん
NGNGjava.sql.Connection
はあくまで，インターフェースなので，
close()メソッドをどう実装するかは，ベンダーの自由．
0399デフォルトの名無しさん
NGNGちょっと前のレスにも関係してるかも知れませんが、
同じトランザクション内で、あるCMPのインスタンスが対象とするレコードを
別のSessionBeanが書き換えたりしていいか？っていうところが
問題になっているんですけど、どなたか詳しい人、
良いのか？悪いのか教えていただけませんでしょうか？
SessionBeanA：
-> トランザクション開始
-> cmpAの呼び出し
cmpA：
-> レコードAの作成もしくは更新
-> SessionBeanBの呼び出し
SessionBeanB：
-> レコードAの更新
-> トランザクション終了
ある人は、OKだって言うし、ある人はダメだっていうんです。
この結果よっては、CMP使うか使わないかが決まってくるもので。
よろしくお願いします。
0400デフォルトの名無しさん
NGNG変な設計だねそれ。
0401デフォルトの名無しさん
NGNGうーん、そんなきもしなくもないけど、
でも、一つのトランザクション内で、レコードを追加して、その追加したレコードを
含めて集計するとかってしません？
今回のケースでは、レコードの追加が、CMPで、集計するのがSessionBeanだったり
することもあるんですよ。先に書いたのは、ちょっと誇張してるかもしれないけど。
あんまりないのかな？
0402デフォルトの名無しさん
NGNG集計って、検索だよね？Bで更新しないならアリでおけのような。
Bで更新するのは？？？と思うけど。なんでそっちの更新をcmpA
でやらないのか、と。
0403U ◆CZtFsGiu0c
NGNGCMP、Session Beanそれぞれのトランザクション属性はどうなっているのでしょうか。
それぞれRequiredだったら同じトランザクション内で処理されるので問題ないと思います。
それと、CMPとSession Bean Bは、同じデータソース使うんですよね? でないと2PCを
サポートしているデータソースじゃないと問題が出ると思います。
0404399
NGNG>>403
レスありがとう。ちょっと寝てしまった。
>>402
うん、おっしゃるとおり。と、漏れも思ってますが・・・。
>>403
そそそ、TXがRequiredで当然同じデータソースを利用するならOKと漏れもそう思っていた。
そのダメっていう人は、コンテナからみたトランザクションは同じだけど、
DBから見たらｃｍｐAからの接続と、SBのBからの接続は別のAppからの接続で、
トランザクションは別々に扱われるから、ダメだっていうんだよね。
例えば、cmpAのアクセスインテントで「排他ロック」で更新するような設定にしていると
SBのBが同じレコードにアクセス（参照でも）した場合、読み取りできずロック待ちになって、
結局デッドロックと同じ状況になる・・・とか。これ、同一トランザクションとDBが思ってるなら
起こり得ないことだよね？？？
この人の言っていることは本当？もしくはコンテナ依存？
あ、大前提を忘れてました。EJBは2.0ね。
0405デフォルトの名無しさん
NGNGトランザクションが同じなら、コネクションプールから返される
Connectionも同じだから、大丈夫。
DBからみたら、同じConnection。
このように実装しないとトランザクションを維持できないはず。
仕様書に書いてあったかどうかはもう忘れた。
0406デフォルトの名無しさん
NGNGおおぉ、そうだよね。そういうもんだよね。
・・・ところで、実は実際に試してみました。環境はWASの5とDB2のV8.1
cmpAのアクセスインテントは、「なんとかかんとかExclusiveLock」の設定
そしたら、そしたらなんと、
SessionBeanA：
-> トランザクション開始
-> cmpAの呼び出し
cmpA：
-> レコードAの作成もしくは更新
-> SessionBeanBの呼び出し
SessionBeanB：
◎ -> レコードAを含ようにSELECT文を実行
-> トランザクション終了・・・してほしい
上の◎のところで、ストップ。１２０秒後トランザクションタイムアウトでやっと
戻ってくる。当然処理はロールバック。
使っているのは、同じデータソース。
どなたか、説明つく人います？
できることなら、私の勘違いとかで、>>405さんの言うことが正解であることを祈ってます。
0407デフォルトの名無しさん
NGNGデカい基幹システムで使われるもので、
中小にはまるっきり必要の無いシロモノなんだよね。
0408デフォルトの名無しさん
NGNG所詮は可用性88%だろ。(嘲笑激藁
http://www.javalobby.org/nl/archive/jlnews_20031202o.html
0409デフォルトの名無しさん
NGNGDBじゃなく、CMPの排他ロックで引っかかってのかも。
CMPのロック設定見直したら何とかならない?
CMPじゃなくて、DataSource経由のJDBCでやるとどうかな。
後、DB2用のコネクションプールの設定だが、8.1用の
JDBC Driverではなく、7用のdb2java.zipをNative経由で
呼び出す必要があったと思う。
0410406
NGNGいろいろ、アドバイス感謝します。
それで、恐縮なんですが、
>DBじゃなく、CMPの排他ロックで引っかかってのかも。
これは、レコードの排他ロックでは無くって、CMPとなにがしかの排他ロックって
ことですか？
> 後、DB2用のコネクションプールの設定だが、8.1用の
> JDBC Driverではなく、7用のdb2java.zipをNative経由で
> 呼び出す必要があったと思う。
こ、これは、どっかにその文献ってあります？
その他の部分は、時間を見つけて試してみます。
また、報告するので、何かあったらおながいします。
0411デフォルトの名無しさん
NGNGEJBなんでしょうか？
①Java使って、ＤＢを使ったサーバーサイドアプリケーションを作ろうとうする
②今後の拡張性を考えると、複数のサーバーによる付加分散を考慮した設計がしたい
③ソケットでやろうかと思ってたら、RMIなんていう便利なものがjavaにはある
④同期をするべきモジュールと、不要なモジュールがある
ていう感じで設計すると、それはEJBになってるんでしょうか？
0412411
NGNGEJBの解説ページ
411で書いた事が正しければ、EJBって
ごく普通のフレームワークで
全然クソじゃないと思うんですが。
ただ、フレームワークとしては妥当でも、
敷居が高いというか、使いにくい感があるような。
一発使うだけなら、自分でRMI使って必要な機能だけ
作った方が速いような気もする。
フレームワークは何回も使うからフレームワークなんだとは思うけど、
ちょろっと解説書読めば、大体やりたい事ができるような
フレームワークが望ましいとも思う。
0413デフォルトの名無しさん
NGNG404で「そのダメっていう人」って言う人が正しい。
戻ってこなくなるのはSessionBeanAのCMP更新処理でDB2の該当レコードが強排他されているから。
もしトランザクションをコミットしないで別のConnectionでSELECTを行いたいのであればWebsphereの
CMP記述の中でアイソレーションレベルを下げるしかない。
0414デフォルトの名無しさん
NGNGもし、同一トランザクション中に複数回取得した物理的な
コネクションが異なるなら、そのJDBC Driverは、
XAの機能をサポートしていなければならない。
XAをサポートしているなら、同一トランザクション中は、
同じXidが渡されるはずなので、異なるコネクションでも
同じトランザクションとして認識されなければならない。
今回DB2はそのような動作をしていないので、
XAの実装が不十分であるってことですか。
WASとDB2のトランザクションスコープが違っているなら
もうトランザクションの意味があまりない。
0415デフォルトの名無しさん
NGNGEJBで実現しようとしていることはかなり良いと思う。
ただ、実現の仕方が大袈裟でめんどくさいだけ。
単にリモート呼び出ししたいだけなら、RMIじかでも良いと思います。
ただ、負荷分散・フェールオーバー・トランザクション管理などを
やろうとすると、自作は大変。
EJBコマンドパターンを使って、ステートレスセッションビーンを
Facade的に使うのが、一番無難。
それ以上のことをやろうとすると結構はまる。
0416デフォルトの名無しさん
NGNGEJB == 分散処理の為のもの
っていう認識がそもそもの間違いなんじゃないかと思う。
TPモニタの代替としてJ2EEサーバを考えるとしたら、リソース管理、
トランザクション管理やセキュリティがメインであって、
EJBの分散処理ってのはスケーラビリティ確保の為の実装手段に過ぎないんじゃないのか。
分散処理がしたいんならこれからはWebサービスなんじゃないのか。
0417デフォルトの名無しさん
NGNG違うかな？
あるいは２度と構成を変更しないようなシステム構成ならば
RMIを使えば、複数台のマシンを連携させられる。
EJBを使うと、何が楽できるんだろうか？
ちなみに分散処理には、トランザクション管理は必須だよね。
0418デフォルトの名無しさん
NGNG全て1台の"PC"で完結するような処理ねえ・・・。ネットワークすら必要ないな。
で、トランザクションの必要性は分散かどうかに関係ないぞ。ビジネスロジックなら必須だ。
分散環境で必要になるのは2PCだぞ。
0419デフォルトの名無しさん
NGNG1台のPCで完結するということは、そのPCが利用できない時間がサービスの利用停止時間に直結します。
(ブート時間とかクラッシュから復旧するまでの間とか)
その程度の可用性でよければ、サービスを提供しても何ら構わないでしょう。
サービスの可用性を高める一般的な手法は、複数ホストによるクラスタリングです。
HTTP Service 層、Application Service 層、Storage 層など、
それぞれのサービス層で必要に応じて複数のマシンを配置します。
層によっては100台で動いているかもしれません。
1台の安物PCかもしれません。
この環境の上に EJB サービスを提供しようというのだから、
複数ホストが前提になるのは当たり前です。
非分散環境(1台構成)とは、N台構成の特殊な場合でしかありません。
0420404
NGNGレスありがとうね。
>>413
だめっていう人の理論はまさにそれ。
ちなみに、EJB2からISOLATIONの設定は、直接指定できなくなったのよね。
AccessIntentってやつで指定する。
>>414
「・・・～ならない」っていうふうに書いているのは、やっぱりEJBのSpecとかに
記述されてるんですか？
>>413-414の内容を検証するためにちょっと以下の仮定でテストをしてみました。
仮定：
cmpAからのConnection(ConA）と、SB-BからのConnection（ConB）が、DBから見て別の
Connection（トランザクション）であるならば、ConAで更新中のデータは、ConBからは読めない。
結果は次にかきまつ。
0421デフォルトの名無しさん
NGNGTest1：
ｃｍｐＡの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の言っていることも正解のような気もするし。
だれか、説明の着く人いませんか？
いつもすみません。
そもそも、仮定が間違ってる？
0422404
NGNG「WITH XX」は、ISOLATION LEVELの指定ね。
UR：非コミット読み取り
CS：カーソル固定
RS:読み取り固定
RR:反復可能読み取り
UR以外では、DirtyReadは発生しないということらしい。
0423404
NGNG>>415
はげどう
>>416
前半は禿同。ただ、
> 分散処理がしたいんならこれからはWebサービスなんじゃないのか。
ここだけは半分同意。この話の流れの中での分散処理の定義であれば、
今のWebサービスの技術では厳しい。なぜなら、>>418も書いているけど
ビジネスロジックには、トランザクションは必須。
で、そのトランザクションや、セキュリティに関する規格があいまい（まだ、確定していない）だから。
当然、自社内の分散されたロジックを結合するのに、Webサービス（SOAPやWSDL）を利用して、
独自にトランザクションのロジックを載せればOKだし、
EAI用のツールを買うのに比べればはるかに安い（んじゃないかな？）。
激しくスレ違いの気がするけど、現時点でのWebサービスは、ブラウザをリッチクライアント
に置き換えるために使うのが最強。（と、思う）例えば↓
Javaの鯖 <- SOAP、WSDL -> .NETで作ったクライアント
0424デフォルトの名無しさん
NGNGEJBの仕様書確認してみた。
排他制御は、特に規定せずリソースマネージャ(DB2)に
まかせるとのこと。
JDBCの仕様書も確認したけど、同一トランザクション中に
複数回プールからコネクションを取り出したとき、
それが同一のコネクションかどうかは特に規定されていない。
ただ、XAをサポートしていないJDBC Driverの場合、
同一トランザクションなら同一コネクションを返さないと
トランザクションは維持できないけどね。
>>421の結果は、DB2の仕様ということなんでしょうね。
乙。いろいろ勉強になりました。
0425デフォルトの名無しさん
NGNGJavaだけでやる:RMIやEJB
Java以外も使う:CORBAやSOAP
でいいんじゃない？
0426413
NGNGセキュアやコミット、ロールバックを行う際にトランザクションリソースに対してトランザクションリソースが
保持するトランザクションを特定させるためのIDだと思うのですよ。
なのでトランザクションリソースの「トランザクション」とトランザクションモニターの「トランザクション」は
スコープが違うんじゃないかと。
そもそもXA手順が当初想定していたのは同一のデータを同時に複数のサイトに書き込むような冗長構成の
システムだと思うんですね。
EJBがXA手順を利用してトランザクション管理を行うことに関してはEJBの仕様として問題があるというような
記事をどこかで読んだ気がします。
そんときは理由がわかんなかったけどひょっとしたら399のような状況が発生してしまうことがあるからという
ことなのかもしれませんね。
そうするともうひとつ疑問が湧いてきました。
「EntityBeanをCMPで更新したあと同一トランザクションでそのEntityBeanを再度更新できるのは何でだ？」
キャッシュなしのパススルーの状況です。当然413的にはデッドロックですが、更新できます（あたりまえ）。
そこで今日一日考えてみたのですが、CMPの機構は414の機能を実装しているのではないかなと。
もしくは413がでたらめを言っているかです。
ここらへんはCMPの実装方式としてEJBの仕様書に書いてありそうなんですがね・・・・。ちょっと調べてみます。
0427413
NGNG0428デフォルトの名無しさん
NGNGコネクションプールとトランザクションを連携させるには、
XADataSourceを使うのが、最も自然(J2EEで用意されている)
なので、たいていの鯖は、2PCに関係無くそのように実装
されていると思います。
CMPは、インスタンスロックの話を除けば、
素直にコネクションプール(XADataSource)を
利用しているだけだと思います。
トランザクション管理もJTAを素直に利用しているんじゃ
ないかと思います。
根っこの仕組みはシンプルなのに、EJBとして
あれだけ仕様が複雑なのは、いったい。。。
0429デフォルトの名無しさん
NGNG実装上は、XAConnectionから取り出したXAResourceの中には、
XAConnectionもしくはConnectionがはいっているんでしょうね。
リフレクションなしで取り出すのは難しそうだけど。
0430デフォルトの名無しさん
NGNGあんがとさんです。
話を振った私ですが、だんだん難しくなってきた・・・
ところで、DB側で何本接続がきているか？
トランザクションは同一なのか？などが見れれば、なんとなく解決の見えそうな・・
結果論にしかならないけんですけど。
どなたか、DB2で上記の内容を調べる方法、教えていただけませんか？
0431デフォルトの名無しさん
NGNGもっと知りたければ application snapshot 取得。
っていうかこのくらいのコマンドも知らないでDB2運用する事自体が無謀だ。
0432デフォルトの名無しさん
NGNGごもっともでございます。反省
0433デフォルトの名無しさん
NGNG0434デフォルトの名無しさん
NGNGORMは森を守ってるのよ。
0435デフォルトの名無しさん
NGNGひろみ、ちゃんと説明したほうがよろしくってよ。
理解してないかたがいらっしゃるようですわ。
0436デフォルトの名無しさん
NGNG1.CMPは実際使えるでしょうか。複雑な結合をしたり、ストアドをたくさん
使っているようなシステムではどうでしょうか。
2.SessionBeanで処理する場合、１メソッドでトランザクションが完結
する場合、JTAは必要でしょうか。
3.以前関わったプロジェクトはEJBではありませんでしたが、トランザクション
は自分自身で管理し、１メソッド（１クラス内）で完結するように書いて
きました。他のプロジェクトでは、SQL文をファイルとして外において、
SQL文を共有していました。頻繁にアクセスされるマスターテーブルについては
メモリ内にキャッシュしていました。
EJBのトランザクションをコンテナに任せるという発想がいまいちのみ込めない
のですが、発想の転換が必要でしょうか。
0437デフォルトの名無しさん
NGNG0438デフォルトの名無しさん
NGNG厨じゃないじゃん、初心者ジャン。
0439デフォルトの名無しさん
NGNGEJBは、メリット・デメリットをきちんと分かってないと使えない。
迷ってるくらいなら、やめたほうがいい。
0440デフォルトの名無しさん
NGNG0441デフォルトの名無しさん
NGNG。ρ。 ううっ！出るっ！！
ρ ￣￣￣￣∨￣￣￣￣￣
mﾄﾞﾋﾟｭｯ
C|.| /⌒⌒⌒ヽ／~￣￣￣￣ヽ
/⌒ヽ⌒ヽ＿__ | ∴ヽ ３ ）
./ _ ゝ＿＿＿）（９ (｀ ´) ）←>>1
/ 丿ヽ＿__,.───|彡ヽ ―◎-◎-|
_/ ) （ Y￣￣￣￣）
(__／ ＼＿＿＿＿／
0442デフォルトの名無しさん
NGNGあなたは最初から理解できていたのですか？
というか、おそらく今でも理解せず口先だけでしょ。
0443デフォルトの名無しさん
NGNG0444デフォルトの名無しさん
NGNG0445デフォルトの名無しさん
NGNGこういう人物って何を聞いても本読めとしか答えられないんだよな。
しかも本は特定しないし、特定したとしても概略的なもので質問に
対する答えが入っているかどうかは不明。
この人物を満足させる質問は何一つないので、この人物はいるだけ害。
0446デフォルトの名無しさん
NGNGだったら質問に答えてやれよ
0447デフォルトの名無しさん
NGNGしょうがねぇ。>>436に答えるか。
1.CMPが使えるかどうかは案件による。複雑な結合したりストアド使ってる
ようならJDBCやそれなりのO/Rマッピングツールを使ったほうが良い。
2.CMTで十分。
3.トランザクションの管理は、コンテナに任せてそれ以外は、
これまでと同様のやり方でいったほうが堅いと思うよ。
0448デフォルトの名無しさん
NGNGSpring には次の EJB の欠点が無い。
・侵略的なAPI(記述するコードがEJBに依存してしまう)
・コンテナへの依存(EJBコンテナ外では記述したコードが動作しない)
・コンフィギュレーション不可能な固定された機能
・デプロイ作業への献身
・長い起動時間
ttp://wiki.bmedianode.com/Spring/?Spring+Framework
0449デフォルトの名無しさん
NGNG0450デフォルトの名無しさん
NGNGまー Tapestry の HiveMind もそうだけど IoC コンテナで EJB を
ラップすることで Value Object(DTO) やビジネスデリゲが
不要になる。そもそも EJB なんかｲﾗﾈ。
0451デフォルトの名無しさん
NGNGSun,Javaでリプレースする目的が、EJBにはあるってうのを
なんかで読んだけど、それじゃ基幹業務アプリの開発で
Javaが使われるときは、EJBも一緒に使われてるんですか？
実際のところはどうなんでしょうか。
0452デフォルトの名無しさん
NGNG単に分散だったら JTA を使えばいい。異機種分散だったら JCA でいい。
EJB ・・・いるか？ SIer として EJB のほうが儲かるかもね。
0453デフォルトの名無しさん
NGNGJTAなんか使えるか!!! あんな面倒なもの! CMTでたくさんだ!
0454デフォルトの名無しさん
NGNG2フェーズコミットとか楽。Hibernate とかで JTA 使ったことあるか？
0455デフォルトの名無しさん
NGNG0456デフォルトの名無しさん
NGNGそうだな。JTA を使用した悪い例だな。
だから Hibernate の JTA を聞いたんだが。
0457デフォルトの名無しさん
NGNGトランザクションは管理してもらわなくてもいいから2-phase
commitだけやりたいと思ってた。
0458デフォルトの名無しさん
NGNGResin、Orion、JOnAS、JBoss、WebLogic、WebSphere などの
JTM 実装があるコンテナが必要だよ。
Tomcat の場合は JOTM か Tyrex があれば良い。
0459デフォルトの名無しさん
NGNGスタンドアロンアプリケーションからJDBCと同じように気軽に
2-phase commit使えればいいのにねぇ。
0460デフォルトの名無しさん
NGNG0461デフォルトの名無しさん
NGNGあんなたるいAPI使ってられるかってことだろ。
ラッパーが必要だ。
0462デフォルトの名無しさん
NGNG英語しゃべれる人、Tomcatの中の人にJTMサポートするようにお願いして。
JTM 付いてないのってTomcatくらい？
0463デフォルトの名無しさん
NGNG気軽に使うと問題あるかな？
0464デフォルトの名無しさん
NGNG無問題。>>460 はほっといていいよ。
0465デフォルトの名無しさん
NGNG0466デフォルトの名無しさん
NGNGなんで？ OLTPでこそ必要だろ？ 分散されたデータの更新に
JTA 使わんほうがいいのか？ 藻前は自力か？
0467デフォルトの名無しさん
NGNG本当に必要な時だけにしておいたほうが無難だ
0468デフォルトの名無しさん
NGNG実装にもよるけど、XAResourceが1つしか登録されていないなら、
1PC、複数登録されていれば、2PCに自動的に切り替わるように
なってることが多いと思うから、2PCといって使い分ける必要はないと思われ。
まともなXAの実装が少ないっていうのは事実だと思うけどね。
JTAで1つのXADataSourceを使うってのが無難かな。
0469デフォルトの名無しさん
NGNG設計がまずいんだろう
0470デフォルトの名無しさん
NGNGアンタ頭固いんだよ。その辺の Web アプリだったら基本的に
リクエスト受けるとことレスポンス返すとこがトランザクション境界で
いいんだよ。
ロックがパフォーマンスが、とか言いたいのか？
必要なところは狭くすればいい。
0471デフォルトの名無しさん
NGNG小規模ならJDBCのTrxで充分な気もするけど。
0472デフォルトの名無しさん
NGNGJDBCでトランザクションを管理すると、
Connectionを持ちまわらなければいけないのが、
ネックだね。
0473デフォルトの名無しさん
NGNG大規模の末端でエラくなったつもりの自称上級者降臨。
0474デフォルトの名無しさん
NGNGそこで JTA ですよ。
0475デフォルトの名無しさん
NGNG無くなって困るのはどっち？
0476デフォルトの名無しさん
NGNGしかし、恥ずかしながらEJBは使っていないけれども、Eclipseは使っている・・・
0477デフォルトの名無しさん
NGNG・コネクションプーリングが使用可能
って項目、バカじゃないかと思いませんか？
自作しても他の項目に比べ明らかに負荷が軽いと思うんだけど。
自作の場合はセッション切れたときの再接続とか真面目に作れば
工数かかるにしても。
いやもうjakartaとかライブラリあるんでもちろん自作しませんが。
0478デフォルトの名無しさん
NGNGソフトウェア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/
0479デフォルトの名無しさん
NGNG今後にきたいしたい.
0480デフォルトの名無しさん
NGNGSUN One重くて使ってらんない。
EJBは無くなっても少なくとも俺は困らない。
0481デフォルトの名無しさん
NGNGSEがごねるときに有効なセリフは
「パフォーマンス出ませんよ」でFA？
0482デフォルトの名無しさん
NGNGパフォーマンス計測した結果で言っているの？
0483デフォルトの名無しさん
NGNG0484デフォルトの名無しさん
NGNG0485デフォルトの名無しさん
NGNGリアルワールドではEJBは使えないっていうことの証明だな
コンサルやらSunやらがSI会社を騙そうとしているだけ
0486デフォルトの名無しさん
NGNGネトゲじゃ使えないのと一般企業が使えないのとでは意味が違う
まあそうでなくても最後の一行には同意
0487デフォルトの名無しさん
NGNGそこまで、パフォーマンスが必要なシステムがいくつあると思っているんだ。
世の中には、いろいろなシステムがあるんだよ。
適材適所ということを考えよう。
0488デフォルトの名無しさん
NGNGEJBが必要なシステムの数も、そうとう微妙だと漏れ思うんよ
結局データベースのアクセス方法決めたりたまにキャッシュしたり計算したり
ってことだけで、Javaである必要が謎な場合がほとんどよ。
スクリプト言語で作る常駐プログラムで余裕で作れるし、
負荷分散といったってそんな難しいことじゃない。
0489デフォルトの名無しさん
NGNGだましだましで行き当たりばったりのパッチとかデグレも日常茶飯事
EJB以前の問題かと
ゲーム会社はオンラインゲームに関して勘違いしていると思われ
既存の売りきりのゲームと違って運用という言葉が必要になる
これらはむしろ業務系に見習う物もあるだろう
0490デフォルトの名無しさん
NGNG２～３年で終了しそうなサービスならEJBを使う価値は無い。
0491デフォルトの名無しさん
NGNG必要かと聞かれれば、EJBなんか無くても作れるというの
は当然だと思います。
システムの特徴に適した言語を使用していくということが
大切でしょう。
でも、EJBを使うことで得られる利点もあります。
なかでもトランザクションの管理は一番だと思っています。
EJBCommandパターンなんかはとても使いやすいです。
こうしておくと、コーディングするときはEJBかどうかは気に
しないでできます。
負荷分散は難しくないかもしれませんが、これだけ人材が
流動的になると、自社独自技術ではキャッチアップに時間
がかかるので効率が悪くなります。
そこで、システム開発に必要な技術を一般化することにより
どこに行ってもすぐに開発が出来るということではJ2EEの
流れは当然の流れだと思います。
>>490
やり方によっては、小規模でも使えると考えています。
0492デフォルトの名無しさん
NGNGパターンを使うのはよいことだけど、
しかしejbの実装使うのは面倒なことが多いよ
アプリケーション用のトランザクションを定義してそれ使ったほうがシンプルだと思う。
0493デフォルトの名無しさん
NGNG技術の一般化はまことに素晴らしいものだが、
問題は、
EJBに頼らなくてもできるほど、単純極まりない技術を、一般化してもらっても意味が無い。
しかもそれが再利用するためにマンドクサイことが多すぎ。
アプリケーション毎に作ったほうがどう考えても効率いい。
IDEとか、複雑な実装なら、一般化してもらう価値はものすごくあるのだけど。
Eclipseは偉いと思うよ。
0494デフォルトの名無しさん
NGNG非機能的な要求を満たすのはむずかしいね。
0495デフォルトの名無しさん
NGNG面倒かどうかは慣れの問題だから、とやかく言ってもしょうがないが
自分は面倒だとは思わないです。
>>492
再利用ということは世の中でよく言われているが自分はそんなことは
考えていません。
ただ、トランザクションを制御するためにコネクションを持ちまわるとい
うことがかっこ悪いと考えているだけです。
それから、EJBがやっていることはそれ程単純ではないと思います。
0496デフォルトの名無しさん
NGNG内部告発かしら・・・
がんがれ
0497デフォルトの名無しさん
NGNGトランザクションとかの管理なら、別にEJBじゃなくても
SpringやS2つかえばできるじゃん。
しかも普通のJavaのクラスで。
0498デフォルトの名無しさん
NGNGそれどころか、Javaでなくてもネットワーク越しにオブジェクトをやりとりするライブラリは
いろんなスクリプト言語にあって、それを使えばトランザクション管理も負荷分散もさらっと
（っていうほどでもないけど、そのアプリケーションに合った規模のものを適切に）書ける。
0499495
NGNG>>497
それを使うというのは良いのですが、そんなどこのものとも知れないものを
使うというのは顧客によっては許されない場合もあります。
技術的に可能かどうかと、それがプロジェクトで使用できるかどうかとは別
なものです。
EJBさえ使ってはいけないというプロジェクトもありました。
>>498
ここではjavaの話しをしているのではないでしょうか。
他の言語は関係ないと思いますよ。
0500デフォルトの名無しさん
NGNG何かについて語るとき、他言語、他の技術と比較するのは至極当然の事だと思うが。
君がJavaしか解らないと言うのは別として。
0501デフォルトの名無しさん
NGNG> それを使うというのは良いのですが、そんなどこのものとも知れないものを
> 使うというのは顧客によっては許されない場合もあります。
>
> 技術的に可能かどうかと、それがプロジェクトで使用できるかどうかとは別
> なものです。
> EJBさえ使ってはいけないというプロジェクトもありました。
んじゃダメジャンEJBでも（ｗ EJBの優位性にならないぞそれでは
0502デフォルトの名無しさん
NGNGそういうなよ。
0503デフォルトの名無しさん
NGNGんで、Cとかperlとか他のメジャーな言語で分散トランザクションを
さらっと書けるライブラリってどんなのがあったっけ？
0504499
NGNGりません。
選択肢としてEJBはありだということが言いたいだけです。
>>500
他の言語にそのような機能があったからといって、それがEJB
とは関係ないでしょう。
それはjavaからその言語かの比較にしかなりません。
他の言語との比較になってしまえば、「EJBは終わっている」で
はなくて、「Javaは終わっている」というコンテキストでしか語れ
ないでしょう。
まあ、確かに他の言語にも詳しいということは無いのですが。
ここにいる皆さんが良ければ他の言語のライブラリの話しも良
いと思いますよ。
>>501
絶対的に優位ということではなくて、相対的に優位だとは思いま
す。
WebLogic、WebSphereなどが出しているものとSpringでは信用
が全く違うということが言いたかった訳です。
0505デフォルトの名無しさん
NGNGRubyなんだけど、dRubyはどうだろう。
0506デフォルトの名無しさん
NGNGそれ分散トランザクションじゃないよね。
>>498>>500は他のどういう技術を想定してるんだろうか。
0507デフォルトの名無しさん
NGNG何のためのJCPですか。EJBやJTAが気に食わなければJSR上げれば?
0508デフォルトの名無しさん
NGNG0509デフォルトの名無しさん
NGNG分散トランザクションはそのアプリケーション毎に合わせたものを作るのがベスト
十分な技術基盤だよ
0510デフォルトの名無しさん
NGNGへんなところで改行するのは、あなたが分散オブジェクトだからですか？
0511デフォルトの名無しさん
NGNGそれはなんか逆行してるぞ。
アプリケーションごとに最適なものを作れば良いというなら、しまいには
トランザクションさえいらんというところに行き着きそうだが。
トランザクションてのはもともとプロセス間の複雑な相互干渉を単純化
するための考え方だからな。
0512デフォルトの名無しさん
NGNG> するための考え方だからな。
このへんの話ってどういう文献当たればいいですかねえ
DB絡みに限定しない、少し抽象度があるのがいいんですが
0513デフォルトの名無しさん
NGNGEJBの（仕様の安定しない上に利用に手間もかかる、現実と合わないことが多々ある）トランザクション機能を利用しようとするか、
それともアプリケーション毎にシンプルなトランザクション機能を実装するか
後者のほうが単純化できると思うよ
0514デフォルトの名無しさん
NGNG0515デフォルトの名無しさん
NGNGObject Transaction Serviceで検索してください。
0516デフォルトの名無しさん
NGNGJ2EE/EJBはいつまでたってもダメポな方式
0517デフォルトの名無しさん
NGNG0518デフォルトの名無しさん
NGNGunionまでも使っているようなSQLをCMPで実現するにはどうしたら
いいのでしょうか。
教えてください。
0519デフォルトの名無しさん
NGNG0520デフォルトの名無しさん
NGNG今まで作っていたアプリケーションをどうやってEJBに移行するか
ということです。
本に載っているサンプルでは、CMPでは一つのテーブルにしか対応して
いないのでどうしたらいいものかと思ってます。
0521デフォルトの名無しさん
NGNG0522デフォルトの名無しさん
NGNG0523デフォルトの名無しさん
NGNGあとでちょっと設定いじるだけでなんとかなる。
0524デフォルトの名無しさん
NGNGそれイイな。てか、それだけで使う価値がある。
0525デフォルトの名無しさん
NGNGBMPで作ればいいんじゃないの？
セッションBeanでもいいけど
0526デフォルトの名無しさん
NGNG0527デフォルトの名無しさん
NGNG0528デフォルトの名無しさん
NGNGコンピューターを複数台使う予定のアプリケーションを作る時
必然的にEJBみたいになっちゃうけどね。
ダメなのはEJBの中身がよくわかってないのに
EJBを使ってダメなシステムを作っちゃう人なんじゃないかと。
0529デフォルトの名無しさん
NGNGEJBわかってない人いるよな
RMIだけでもいいじゃんというような書きかたしているプログラムよく見かける
EJBコンテナの機能とかもっと使えよって感じ
0530デフォルトの名無しさん
NGNG0531デフォルトの名無しさん
NGNG0532デフォルトの名無しさん
NGNG話すときはコンテナ名も明記してくり
0533デフォルトの名無しさん
NGNGそれはEJBになる。
0534デフォルトの名無しさん
NGNG0535デフォルトの名無しさん
NGNGなるほど。
では、select for updateして、そのselect内容を元に処理を進め、
最後にそのロックした行をupdateする場合はどうしたらいいですか。
また、ストアドを使って、その中でいろいろな条件の下updateや
insertを行っている場合はどうでしょうか。
こういうときにCMPは使えるでしょうか。
またCMP以外に、セッションビーンから更新をかけたりした場合に
整合性は取れるでしょうか。
0536デフォルトの名無しさん
NGNG確かにEJBの使い方を知らなければ生産性が上がることが無いよね。
>>535
とりあえず、２番目以外は問題なと思うけど、基本的にEJBを使うときはストアドは使わないです。
0537デフォルトの名無しさん
NGNG別に EJB に限った話ではないな。
0538デフォルトの名無しさん
NGNG>では、select for updateして、そのselect内容を元に処理を進め、
>最後にそのロックした行をupdateする場合はどうしたらいいですか。
>また、ストアドを使って、その中でいろいろな条件の下updateや
>insertを行っている場合はどうでしょうか。
JDBCとCMPを組み合わせてFOR UPDATEを利用した処理をしようとすると（だいたい）デッドロックします。
同一XAトランザクションですが別セッションになりますからね。
なので楽観的ロックの手法を利用して行います。
該当するレコードに更新カウンタカラムを作成し、そのカウンタが更新前の値と同一である場合に更新をします。
違っていればユーザーに通知をし処理を再実行してもらいます。
ただFOR UPDATEを利用して大量のレコードを更新するのであれば、やはり直接JDBCやSQLJ、ストプロを利用するのがいいと思います。
こうした複数のDBインターフェースを抽象化するためDAO、FastLaneReaderパターンなどを利用します。
>またCMP以外に、セッションビーンから更新をかけたりした場合に
>整合性は取れるでしょうか。
分離レベルを正しく設定すれば必ず整合性は取れます。
ただし、JDBCとCMPを組み合わせるのであればやはりデッドロックに注意しましょう。
0539デフォルトの名無しさん
NGNG管理しきれるもの?
どのくらいの規模のプロジェクトなのかわからないけれど
0540デフォルトの名無しさん
NGNGありがとうございます。
結構ややっこしそうですね。
やっぱりセッションビーンonlyがいいかな。
0541デフォルトの名無しさん
NGNGEJBっていったいどういう機能があるのですか
どの工程を省略することができるのでしょうか
0542デフォルトの名無しさん
NGNG0543デフォルトの名無しさん
NGNG更新処理はCMPで統一する手法が多いけども、大量のデータをDBから取得するときはJDBC
からオブジェクトを作成したりCachedRowSetを利用し取得する手法が一般的です。
CMPで数千行扱うのはリソースを食いすぎるので、やむをえないといったところでしょうか。
手法としては特に問題はないです。
>>540
懸命だと思います。CMPは単なるDBラッパーとして利用するにはかなり大げさな仕組みです。
つまり、勉強しないといけない仕様が山のようにあります。
セキュリティや分散を必要としないのであればJDOやHibernateなどの仕組みを利用するとよいと思います。
こちらはもっと軽量で完全にJDBCを置き換えることが可能です。
学習も容易です。
0544デフォルトの名無しさん
NGNGEJBは
・トランザクション
・セキュリティ
・分散
・オブジェクト永続化
・メッセージング
の処理をプログラムから分離して、アプリケーションサーバーと呼ばれるソフトウェアが別途管理するためのコンポーネント仕様です。
プログラマはこれらに関する詳細なコーディングを省略することができます。
EJBの仕様に沿って作られたアプリケーションはさまざまなベンダの提供するアプリケーションサーバで配備可能です。
省略できる工程はプログラミングとあとは保守ですかね。不具合がおきたらアプリケーションサーバーのせいにしたりします。
0545デフォルトの名無しさん
NGNGStrutsやらなにやらは古タイヤの再利用くらいだとおもう。
ほしい物に似てるけどちょっと違うんだなあ。
だから車体を古タイヤに合わせて設計してみました、みたいな。
似たようなもの毎回作っちゃってもいいんじゃないの？
設計の再利用ってもう流行ってないのかな。
実装なんて再利用しようとても毎回しっくりこないんじゃない？
これ、JBossというかEJBのときにも思った。
既存の道具生かすためになんか本体側で無駄な苦労してるなあと。
0546デフォルトの名無しさん
NGNGでも夢を見つづけないと飛行機もロケットもできないよ
0547デフォルトの名無しさん
NGNG0548デフォルトの名無しさん
NGNGやっと.NETに追いついた感じ。
JBOSSみたいなプラットフォームでMetaDataを利用したAOPをバリバリやりたいなぁ。
0549デフォルトの名無しさん
NGNGttp://itpro.nikkeibp.co.jp/free/JAV/NEWS/20040510/1/
0550デフォルトの名無しさん
NGNG0551デフォルトの名無しさん
NGNG「こういう機能が採用される」「こういうことが期待される」
とかしか書いてないから。
0552デフォルトの名無しさん
NGNG具体的に何が変わるかも書かずに「これは期待できる」と提灯持ち。
しかも
> 従来のEJBの機能を使いこなしている例は非常に少なく，特にCMP Entity Beanによる
> データの永続化というEJBのメリットを引き出している例はほとんどない。
あれー？宣伝と違うねー。www
0553デフォルトの名無しさん
NGNG過去の互換性切り捨てでまた書き直しか。
ドカタの仕事が増えて良かったね。ｗ
0554デフォルトの名無しさん
NGNGﾄﾞｶﾀの仕事が
0555デフォルトの名無しさん
NGNG「期待できる」じゃなくて「期待が大きい」ね。
別にこういう紹介記事でこまかいことは書く必要が無いと思うし。
方向性と目玉となる機能だけあればいい。
> 特にCMP Entity Beanによるデータ の永続化というEJBのメリットを引き出している例はほとんどない。
これは笑った。うん、宣伝と違う。
ただ、その違いを改善しようとしてるんだから、とりあえず期待だけはしておく。
それにしても、ほとんどない、って言っちゃうのか。
0556デフォルトの名無しさん
NGNG0557デフォルトの名無しさん
NGNGEJBのメリットはCMPだけじゃないしね。
0558デフォルトの名無しさん
NGNGHibernateっぽくRDB依存のAPIを大きく公開してほしいなぁ。
0559デフォルトの名無しさん
NGNG0560デフォルトの名無しさん
NGNG0561デフォルトの名無しさん
NGNG0562デフォルトの名無しさん
NGNG0563デフォルトの名無しさん
NGNGまずCMPのほうがパフォーマンスいいじゃん。
0564デフォルトの名無しさん
NGNG日本人？
0565デフォルトの名無しさん
NGNGSEの方いわく、
「このプロジェクトはパフォーマンス重視なので、EJBは使えません。」
などと仰ってましたが、どこもこんな感じなんですか？
0566デフォルトの名無しさん
NGNGうちもそうだよ。
0567デフォルトの名無しさん
NGNG分散前提なんだしねぇ
0568デフォルトの名無しさん
NGNG0569デフォルトの名無しさん
NGNGやつらからしたら１億以下は激安の案件だしな～
0570デフォルトの名無しさん
NGNGまあ、そこもどんどん侵食されていくわけだが
ttp://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040512/1/
0571デフォルトの名無しさん
NGNGEJB系プロジェクトの総工数 ３人月/画面
うち実装工数： ３日月/画面
しかも、開発プロセスは大抵、品質の悪さで定評ある
大抵ウォーターフォール(ﾌﾟﾌﾟﾌﾟ
お客さん、ぼったくられてるよ
0572デフォルトの名無しさん
NGNG0573デフォルトの名無しさん
NGNG0574デフォルトの名無しさん
NGNGVBの案件の方が個人的にウォーターフォールは多いと思ってる
結局cobol屋がほとんどVB屋いったんで同じかと
特に設計連中
0575デフォルトの名無しさん
NGNG話の本筋見えてない基地外はっけん
0576デフォルトの名無しさん
NGNG底辺労働者に工数の話しても、通じるわけないだろ。
重要な話しても無駄無駄
0577デフォルトの名無しさん
NGNG経験が高かったり業務知識が多くあって斬新なものじゃなければ、ウォーターフォールのほうが品質がいい。
それに、すべてのプロセスの基本はウォーターフォールだ。
プロセスの名前に踊らされる厨みたいですね。
0578デフォルトの名無しさん
NGNGttp://www.amazon.co.jp/exec/obidos/ASIN/0764558315
0579デフォルトの名無しさん
NGNG0580デフォルトの名無しさん
NGNG署名表記が間違っているのはは日本だけのようだが。
本家はこちら。
ttp://www.wrox.com/books/0764558315.shtml
しから、WROXの顔写真つきの表紙はどうもイヤーンな感じだな。
0581デフォルトの名無しさん
NGNG0582デフォルトの名無しさん
NGNG要らない準備に時間がかかるという意味では
EJBはウォーターフォールっぽいかもな。
繰り返し開発では、本当に必要になるとわかるまでは
EJBは使わない。
0583デフォルトの名無しさん
NGNG0584デフォルトの名無しさん
NGNGEJB2.0前提なんだけど、DB上Viewに対して、EntityBeanて作れるの？
もし作れるんなら、更新不可能なViewに対してもOKなのかしらん？
その場合、アクセサ（setter）は使えるの？
教えてえろい人。
0585なんもわからん人
NGNG欲しいの？
0586584
NGNG>>585
いや、そもそもsetterがあってよいのかしらん？と思ったのよ。
使いたいわけではないんだが。
>その場合、アクセサ（setter）は使えるの？
この行は忘れてくだﾁｨ
0587デフォルトの名無しさん
NGNG0588sage
NGNG変更不可能にしたいならリモートインタフェースからsetを削除
0589デフォルトの名無しさん
NGNGCMPで開発を行ったけど、正直もうｲﾔ。
0590デフォルトの名無しさん
NGNG0591デフォルトの名無しさん
NGNGJBossでやってる（というか、やろうとしている）んだけど、ホットデプロイがもー！全然できない！！！
どっかに参考になるサイトないかな。(hibernateのサイトと、Jbossのサイト以外ね）
0592デフォルトの名無しさん
NGNGEJB3.0 で Entity Bean は Hibernate ＋ JBoss AOP で XML いらずになるな。
EJB の欠点だった Data Trunsfer Object も Business Delegate も不要。
EJB2.0 は終わってる
0593デフォルトの名無しさん
NGNG金出してマニュアル買え。
0594デフォルトの名無しさん
NGNGなんとか自力できた。SARにするのね。
0595デフォルトの名無しさん
NGNG張って、使っている人いますか?
0596デフォルトの名無しさん
NGNG0597デフォルトの名無しさん
NGNGむしろはじまってもいないという状況
0598デフォルトの名無しさん
NGNGもしかしてみんな英語読めない厨？
0599デフォルトの名無しさん
NGNGわけのわからん話を持ち出すのが終わってる証拠
0600デフォルトの名無しさん
NGNGスレ違いだが、「英語」と言う所に反応。
毎日、それなりに英文読んでいるのだが、ごろ寝して気楽～に読めるようにはならん。
それなりに負荷が高い。
これって、まだ修行が足らんって事？
それとも英語＝母国語で無い人間は、この程度が限界？
0601デフォルトの名無しさん
NGNG８歳辺りまでに英語に親しんでないと厳しいらしい。
TOEICスコアは800点以上あるが、英語モード時の脳の負荷は
高いまんまだ・・・
0602デフォルトの名無しさん
NGNGショック。
知識レベルとは違う方向で、脱力法を見つけねば・・・Thx
0603デフォルトの名無しさん
NGNG0604デフォルトの名無しさん
NGNGhttp://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を投げるようにすれば作りは同じ。
0605デフォルトの名無しさん
NGNGFinder メソッドを 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 は(少なくとも必要としている範囲では)使えてる。
0606デフォルトの名無しさん
NGNGもうEJBなんてだいぶ前につかっただけだが、カンマ区切りの文字列じゃなくてちゃんとint型
などでやらんといけないのじゃないの？
0607デフォルトの名無しさん
NGNGLIKE で % とか指定できるのは同じ文字列だからかな。
今回は引数(?1)が可変なんだよなあ…どうしたものやら。
EJB-QL とか JBoss-QL じゃ無理なのかしらん。
0608デフォルトの名無しさん
NGNGうむ、スレタイどおりのセオリーだな。
0609デフォルトの名無しさん
NGNGOBJECT(a)って何?とか思ったらこれがエンティティの集合になるのね。
これSELECT対象が何十何百万件とかになった場合大丈夫なわけ?
カーソルとかイテレータみたいなものと思って良いの?
0610605=607
NGNGejbSelect メソッドを使う方ね。ぐぐれば出てくると思う。
>>609
どうなんだろう。クエリに対する件数が膨大なのって普通にありそうだけど…。
情報お持ちの方キボンウ
0611デフォルトの名無しさん
NGNGコンテナ独自の機能を使ってもいいが、それではEJBのうまみも半減する。
0612デフォルトの名無しさん
NGNGあ、ｲｴｯｻ-。取りあえずでけただけって感じです。申し訳ない。
JBoss 拡張でなくて済むならそれがいいかと。
それとも後半の膨大な検索結果…って下りの所に掛かっているのかなあ?
だったら例があれば教えて頂ければ幸い。
0613デフォルトの名無しさん
NGNG誰か教えてください・・・
ＲＤＢのあるテーブルに３万件のレコード（カラム数約５０）から、
いろいろな条件でレコード件数を集計して
エクセル出力するアプリがあるのだが、
うちのＥＪＢだと、３万件のレコードを
select * from table where ・・・
みなたいな感じで全部データを取ってきて、
プログラム上で条件を絞り込む処理を実装している。
これが激遅で、ユーザから叩かれ撒くっている。
ちなみに、where句に相当する処理は、超基本的なものしか使えない。
（is null とか 大小比較、グループ関数、distinct相当の機能もない・・・）
小生的には、
ＥＪＢを止めて、ＪＤＢＣで自由にＳＱＬを発行する方式のほうが
どう考えても早いと思うのだが、どうなんでしょうか・・・
例えば、
select count(*) form table where ・・・
教えてクンですまんのだが、だれか助けてくれ～
0614デフォルトの名無しさん
NGNG"where句に相当する処理"をSQLのwhere句に置き換えて、
SQL発行したらええんでない。
0615デフォルトの名無しさん
NGNG0616613
NGNGEJB開発者にSQLを自由に発行できる仕組みがあるのかどうか聞いて見ます。
欲しいデータは件数、合計値なので、COUNT,SUM等を使えれば、１発だと思うのですが、
テーブルの全カラムのデータを取得して、アプリサーバ側でそれに相当する処理させています。
なので、バグも作り込みやすいと思っています。
ちなみに、先日の説明では、カラムを指定して取り出すこともできないと言ってました。
>615
想定ユーザは１０００～２０００人程度、
同時アクセス数もＭＡＸ１００人程度と見ています。
ただ、数百～数千件のデータ参照、更新処理を行うことが結構あるので、
その辺がネックになっていまつ。
0617デフォルトの名無しさん
NGNG0618613
NGNGおそらく。
当時の決定経緯は良く分からないのですが、
ＥＪＢを開発してみたい、ある技術者の単なる興味から始まっています。
上司もよくわかんないけどＯＫしちゃったみたいな・・・
ＥＪＢもその彼が開発したんですが、他の人にはブラックボックスで
中身は良く分からないんです・・・
システム規模の点からも、ＪＤＢＣかＰＨＰあたり十分かと・・・
0619デフォルトの名無しさん
NGNG「PHPでも十分」って言ってる段階で、EJBを使うべきではないだろうに。
今からでもイチから作り直したら？？
0620デフォルトの名無しさん
NGNGHitしたコレクション数をそのまま出せばカウントになる。
SUMはEJB-QLで使えなかったっけ？
カラムを指定して取り出すのはejbSelectかなんかであったような気がするが。
0621デフォルトの名無しさん
NGNG現場はそうもいかんでしょ。まず上が許可しない。
てか悲惨な仕事やな～
0622デフォルトの名無しさん
NGNGいまさらJDBCでPreparedStatementと戯れるのも、なんだかなぁ。
Hibernate使っとけ。
PHPを使う気はしなくなる。めんどくさくて。っつうか、PHPってめんどくさいよ。
「危機に瀕するJ2EE」――市場調査会社がレポート
ttp://www.itmedia.co.jp/enterprise/articles/0410/18/news056.html
危機に瀕してるのはEJBね。
SpringもHibernateもJ2EEのコンポーネント利用するわけだし。
0623デフォルトの名無しさん
NGNG0624デフォルトの名無しさん
NGNG0625デフォルトの名無しさん
NGNGJava
http://secunia.com/graph/?type=adv&period=all&prod=784
.NET
http://secunia.com/graph/?type=adv&period=all&prod=667
結論
.NETの方が安全。
0626デフォルトの名無しさん
NGNG0627デフォルトの名無しさん
NGNG対応の早さもね
ベンダに頼らず、自前で対応できるかどうかも重要
0628デフォルトの名無しさん
NGNGEJBでレコードを返す、ってEntityBeanを返すってこと指してんの?
0629デフォルトの名無しさん
NGNG0630デフォルトの名無しさん
NGNG君はスバラシイ。
0631デフォルトの名無しさん
NGNG0632デフォルトの名無しさん
NGNGlookup("java:comp/env/○○");
とする方法を教えてください。
0633age
05/01/21 11:57:15○○の文字列で何を参照したいのかを、配布ディスクリプタで定義する
必要があると思うよ
0634デフォルトの名無しさん
05/01/22 02:15:400635デフォルトの名無しさん
05/01/22 13:17:37スレタイが変わる
【Spring/JBoss/Hibernateの】EJBは終わってる【劣化コピー】
Hibernateの作者も仕様策定に関わってるとはいえ、EJBは企業に
とって金づるなので、各企業の思惑が追加される。
EJB の目的はシステム開発の効率化ではない。
EJB サーバベンダーが儲けることを最大の目的として
仕様が策定される。
結果的に今までの EJB と同じ道をたどることになる。
0636デフォルトの名無しさん
05/01/22 13:23:16・・・
0637デフォルトの名無しさん
05/01/23 08:06:09でも最大公約数の規約で必要な部分だけを選択すること自体に
コストがかかり過ぎ。
現実的には、StatelessSessionBeanを継承したFacadeからPOJOを
使用するパターンに落ち着いてきている。
サーバーのハードやアプリケーションサーバーを買わせたい
ベンダーとその営業の思惑や、EJBという言葉だけ使っている営業と
生半可な知識しかもたないPM/PLには、StatelessSessionBeanだけを
使おうが何しようがわかりゃしないので、コソーリHibernateで
照会時はベタベタSQL、更新時にはHQLを使って期日を守って納品。
お客さん、ユーザー、営業、製造みんなで幸せ。
0638デフォルトの名無しさん
05/01/24 04:07:47hibernateとSessionBeanをアノテーションで再定義しただけだけどさ
0639デフォルトの名無しさん
05/01/24 10:28:23詳細教えてｷﾎﾞﾝﾆｭ！
0640デフォルトの名無しさん
05/01/24 20:38:500641デフォルトの名無しさん
05/01/25 17:31:00大幅変更で困る部分とかは無かったの？
0642デフォルトの名無しさん
05/01/25 17:42:080643デフォルトの名無しさん
05/01/25 19:26:30説明サイトでもＯＫ
0644デフォルトの名無しさん
05/01/25 19:45:29別物だから、変更どころの話ではない、ってことで。
0645デフォルトの名無しさん
05/01/28 09:32:140646デフォルトの名無しさん
05/01/28 23:35:540647デフォルトの名無しさん
05/01/29 02:14:51楽そうではある。
悪くはなってないと思う。
0648デフォルトの名無しさん
05/03/05 14:29:55EntityBeansのせいでEJB全体の仕掛けが複雑になりすぎたように思えます。
Application Serverの機能としては分散トランザクションや負荷分散、JNDI、
IIOP、RMIなどのインフラが提供されれば十分。つまりSessionBeansが
スマートに使えれば十分だったといえます。
世の中が必要にしていたのはRDBの情報をオブジェクトにマッピングすることで
あって、オブジェクトをRDBにマップしたいわけじゃなかったのだと思う。
このミスマッチが現状のEntityBeansの問題点だろう。
0649age
05/03/07 13:02:39>EntityBeansのせいでEJB全体の仕掛けが複雑になりすぎたように思えます
私は特に複雑とは思えませぬが。
0650デフォルトの名無しさん
05/03/07 20:59:08複雑かどうかは別にして、、
やる気なくなるくらいめんどい。
0651デフォルトの名無しさん
05/03/07 21:14:380652デフォルトの名無しさん
05/03/07 21:30:510653デフォルトの名無しさん
05/03/08 01:15:08あんなに煩雑になるものを複雑ではないと思うあなたとは、
一緒に仕事をしたくないと思う人は多いと思う。
0654デフォルトの名無しさん
2005/03/21(月) 09:51:29EJBはじめソフトウェアはだめだめです。
そんな最先端行く俺が今携わってるのが、マンスリー100アクセス足らずの大コケシステム。
仕様ペラペラ。
EJBがちがち。
レスポンスとろとろ。
プロジェクトボウボウ。
EJB3でもなんでもこいやあああ！！
0655デフォルトの名無しさん
2005/03/22(火) 21:07:01それをEJBのせいにするのは(・A ・)ｲｸﾅｲ!
0656デフォルトの名無しさん
2005/03/23(水) 23:05:03理由・・・難しい言葉を並べることで素人の客をうまくまるめこめ責任転嫁できるから。
0657デフォルトの名無しさん
2005/04/03(日) 11:11:240658デフォルトの名無しさん
2005/04/03(日) 13:09:570659デフォルトの名無しさん
2005/04/14(木) 00:05:40携わったPJは最大で40人月程度ですがいつもservlet/JSPです。
EJB使うとしたら技術的にどういうときに有効ですか？
分散トランザクション、RMIなど必要に迫られた場合ですか？
sessionbeanとhttpsessionって違うんですか？(笑われるかも…)
やはり、パフォーマンス悪化などでそれほどメリットないのでしょうか？
個人的には他の大規模PJでは採用していると聞くので未練がありつつも、
周りにEJB経験者が少なく、いろいろ工数増えそうなため採用するつもりはないです。
0660デフォルトの名無しさん
2005/04/14(木) 02:56:31EJB使うときっていうのは、親会社から「このアプリサーバーを使え」って指定されたとき、とか？
0661デフォルトの名無しさん
2005/04/14(木) 20:24:11誰か説明して。
0662デフォルトの名無しさん
2005/04/14(木) 20:49:140663デフォルトの名無しさん
2005/05/06(金) 11:50:170664デフォルトの名無しさん
2005/05/19(木) 00:44:43それなりに見識がある技術者が参画するような大規模プロジェクトでは、
Statefulなんかはなから使ってない。Entityなんてもってのほか。
ちょうちん記事やメーカーにのせられた、なまじJava使い乙。
0665デフォルトの名無しさん
2005/05/19(木) 06:51:44調べずにカキコ
0666デフォルトの名無しさん
2005/05/19(木) 10:03:210667デフォルトの名無しさん
2005/05/19(木) 13:36:450668デフォルトの名無しさん
2005/05/21(土) 00:26:02＠ITのライターをばかにするなー
0669デフォルトの名無しさん
2005/05/21(土) 00:39:30TuxedoとかMQとかOpen TP1とかつかってんの？？
0670デフォルトの名無しさん
2005/05/21(土) 02:09:36普通のWebアプリ作る程度の人たちに分散トランザクションは語れまい。
0671デフォルトの名無しさん
2005/05/21(土) 10:12:080672デフォルトの名無しさん
2005/05/21(土) 11:03:26小規模で採用するのがおかしいだけだ
0673デフォルトの名無しさん
2005/05/21(土) 11:19:25IBMマンセー
0674デフォルトの名無しさん
2005/05/21(土) 23:40:420675デフォルトの名無しさん
2005/05/22(日) 00:04:35JTAはAPIを指す言葉だぞ。
0676デフォルトの名無しさん
2005/05/22(日) 00:06:250677デフォルトの名無しさん
2005/05/22(日) 00:15:36トランザクション管理のために使うにしてはめんどくさすぎ。
ってことでDI+ORMなんだね。
0678674
2005/05/22(日) 14:04:15そのツッコミはもっともだけど、JTSって一般的じゃないからね。
使い方としてJTA(TransactionManager)で行ければいいと。
＃大半のサイトはJTA管理って書いてる希ガス
>>677
トランザクションをロジックから分離できるメリットは大きいよ。
EJB使わないなら、DIでも自前でも挟み込めばいいだけ。
単体で独立したJTA-JTSな実装で安定したのがあれば
いいんだけど、今のところ知らないからなぁ。
TyrexもJOTMも一年半くらい前に試した時はヤバかった。
さすがにこの辺は商用コンテナに一日の長あり。
0679デフォルトの名無しさん
2005/05/22(日) 14:27:030680デフォルトの名無しさん
2005/05/23(月) 01:24:31TyrexもJOTMも知らなかった
勉強しなおします。
0681デフォルトの名無しさん
2005/06/10(金) 18:53:59複雑さのメタファーとしてはうまい表現だと思う、金もかかりそうだし
0683デフォルトの名無しさん
2005/06/21(火) 21:51:040684デフォルトの名無しさん
2005/06/22(水) 01:08:46ま、DIはそのくらいにならないと。
0685デフォルトの名無しさん
2005/06/22(水) 16:44:17ttp://headlines.yahoo.co.jp/hl?a=20050622-00000007-cnet-sci
0686デフォルトの名無しさん
2005/06/23(木) 16:28:230687デフォルトの名無しさん
2005/06/23(木) 23:49:470688デフォルトの名無しさん
2005/06/27(月) 00:41:39ロッドジョンソン氏の「without EJB」論にも在るようにEJBそのものの存在意義ってどうよ？
ちなみに俺はロッド派。EJBはいらん
まずEJBの分散オブジェクト機能以外はすべてAOPによってPOJOでも実現できる
（例えば分散トランザクションはJTA/JTSがあれば実現できる。EJBは必要ない）
で、ここで思うのが分散オブジェクトそのものの存在意義って何？
まぁ簡単に思い浮かぶのが、負荷分散、フェイルオーバー、リモート呼び出しあたりだが
１、負荷分散なんてWeb層から水平分散で問題なし。てかその方がキャパシティプランニングも楽。
２、フェイルオーバーなんてステートレスな設計にしておけばWeb層で面倒見きれる。
３、Webサービスでリモート呼び出しは実現できる。
一部の金融系とか、分散のコスト以上の膨大な処理をしなきゃならない領域以外に必要ないだろ
Webアプリは３層に分けるのが定石だなんてもう過去の話だ。と、受け売りを言ってみるテスト
0689デフォルトの名無しさん
2005/06/27(月) 02:26:39簡単に使えて分散オブジェクトも考慮されていれば尚良しということで
EJB3には期待したい
0690デフォルトの名無しさん
2005/06/27(月) 06:26:54存在自体が間違いってのはどうかと思うけどね。
その存在がなければ、ロッドの「without EJB」論には至ってなかったろうし、ロッド自体がEJB的なものを作ってたかもしれない。
もしロッドが「without EJB」論をEJBが出現した時期に考えてたとしても、説得力のある実装は技術的に無理だし、賛同する人はいなかっただろう。
0691デフォルトの名無しさん
2005/06/27(月) 10:37:44ここだけはなんともいえんなぁ
0692デフォルトの名無しさん
2005/06/27(月) 11:05:02下流ではEJB3.0で簡易化によってその流れに抵抗している。
SOAが主流になるまでに、EJB3.0の普及がどこまで進むかが勝負の分かれ目かな．．．
0693受け売り2
2005/06/27(月) 21:49:53分散オブジェクトとか、3層構造のシステムそのものがメリットに思えないんだよね
例えばDTOパターンとか、分散で在るがゆえにオブジェクトのシリアライズやネットワーク負荷を
考慮しなくちゃいけないって言うのは本末転倒な気がする
オブジェクト指向が至上の方法とまでは分からないが、少なくともDTOっていうのはその障害を
低減する為だけに存在する、ビジネス上でも意味のないフェイクオブジェクトだし
他にもサブシステムごと、機能ごとに分散しておけば障害発生時に影響範囲を抑えられるとか言うけど
一つが落ちたら、依存性の高い他の箇所だって結局影響出て通常稼動はし難い
って考えてくと、潔く
依存性の高い処理、ないし１システムは基本的に同一VM上に配備、システム間はWebサービスで連携
とした方が分かりやすいし、相互運用性と柔軟性のある作りになると思う
J2EE6.0のJBIもこんな思想から出てきている物だろうし
0694受け売り2
2005/06/27(月) 21:56:48EJBは別に分散しなくてもローカルでも呼び出せるでしょボケ
EJB3はPOJOなんだよボケ
って意見があると思うけど
同一vm上で完結出来るなら、EJBコンテナの上でしか動かないEJBではなく
純粋なPOJO+AOPの方が可搬性に優れるって事なる
分散オブジェクトを「必須用件」として持ってしまっている事が
EJBをコンテナに縛り付けて、死に至らしめていると考える
0695デフォルトの名無しさん
2005/06/27(月) 22:13:130696デフォルトの名無しさん
2005/06/27(月) 22:32:29ベンダがサポートする "正規" の方法が必要と思う。
O/Rマッピング、トランザクションなどを考慮したもの。
0697デフォルトの名無しさん
2005/06/27(月) 23:15:40ｽﾏｿ、いっぱい書いてるけど興味ないなら流して。どうせ死にかけてたスレだし
意見を頂戴しつつ自分の考えも整理してる所
反論、異論、それでは甘いとご教授願えるならぜひ御願いします。
>696
Strutsがjavaの"正規"で無いにも関わらずこれだけ普及している事を考えると
必ずしもJ2EEコンテナベンダやツールベンダが正式にサポートしなければない事はないと思うんだが
今でこそどこのベンダもサポートしてるけど。
ただStrutsのように誰もが認めるデファクトスタンダードは必要かと思われ、だが
現時点でも Spring(+AspectJ or SpringAOP)、Hibernateの組み合わせは
十分な実力、事例、ドキュメント共にそろっていて、デファクトになりつつある
Apache族では無いが開発体制もわりとしっかりしている(っぽいし)
それぞれInterface21、Eclipse、JBossのバックアップもある(っぽいし)
O/Rマッピング、トランザクションを考慮したもの。って用件もバッチリ
0698デフォルトの名無しさん
2005/06/27(月) 23:31:08サポートなくてもそれほど心配ないんじゃない?
その点O/Rマッパはそれ自身だけ分かってれば良いわけではなく
問題が起こったときはJDBCドライバ、データベースとの切り分けも必要。
正式なサポートがある/なしが大きい意味を持つと思う。
0699デフォルトの名無しさん
2005/06/28(火) 01:47:37J2EE標準仕様なんて幻想だったけどEJB3はどうなんだろ。
ベンダーごとにデプロイメントディスクリプタの書式すら
全然異なるのが当たり前だったし。
まぁデプロイメントディスクリプタに関してはEJB3では
アノテーションが使えるからデプロイメントディスクリプタを
開発者が意識することは減りそうだけど。
J2EE仕様の策定をもちっときめ細かくしてくれれば
いくらEJBがコンテナ依存だといってもEJB3ではPOJOになることだし
ある程度可般性を維持できるはずなんだよね。
697の言う事はもっともだと思うけど
個人的にはSpring+Hibernateなどの過渡的な技術でなくて
J2EE標準仕様にもっとがんばってもらいたいなぁ。
あ、Spring+Hibernateが十分強力だってのは認めますよ。
0700デフォルトの名無しさん
2005/06/28(火) 06:29:43HibernateはJBossのORマッピングエンジンなので、EJB3でもそのまま使われるよ。
Hibernate Annotationsは、ほとんどEJB3のアノテーションだしね。
0701デフォルトの名無しさん
2005/06/28(火) 13:51:56確かに．．．
コマンドパターンの勉強にちょうどイイよね
0702デフォルトの名無しさん
2005/06/29(水) 02:55:23http://www.amazon.co.jp/exec/obidos/ASIN/4569620973/250-1090913-6566616
0703デフォルトの名無しさん
2005/06/29(水) 14:14:590704デフォルトの名無しさん
2005/06/29(水) 14:39:26HibernateはすでにJ2SEで動いてるわけで。
0705703
2005/06/29(水) 15:13:34消防の漏れに理解できるレベルに噛み砕くと
「うちは分散なんてイラネ。だからTomcatとEJB3で組みました。」
こんな時代が間もなく到来する。こう考えていいの？
0706705
2005/06/29(水) 15:23:55×「うちは分散なんてイラネ。だからTomcatとEJB3で組みました。」
○「うちは分散なんてイラネ。だからTomcatとEJB3ORMで組みました。」
0707デフォルトの名無しさん
2005/06/29(水) 19:23:34すでになってるね。
Hibernate3+Hibernate Annotationがそんな感じ。
EJB3のORマッピング部分の仕様はほとんどHibernateだし、Hibernate Annotationsのアノテーションはほとんどjavax.persistence.*
つまりEJB3のアノテーション。
0708デフォルトの名無しさん
2005/06/29(水) 19:26:13EJB3のコーディングのイメージは
http://j2ee.netbeans.org/NetBeans_EJB3.html
のデモを見ると、なんとなくわかる。めちゃくちゃ簡単そう。
0709デフォルトの名無しさん
2005/06/29(水) 19:56:560710デフォルトの名無しさん
2005/06/29(水) 23:28:09EJB3をコンテナから誘い出して利用出来るのではなくて、あくまで Hibernate3が
EJB3としても動作するよう設計されているだけだと思われ
○「うちは分散なんてイラネ。だからTomcatと、EJBと同じpersistence APIを実装したHibernateで組みました。」
かと
0711デフォルトの名無しさん
2005/06/30(木) 00:08:47EJB3のAPIを実装したらEJB3のORMじゃないの？
0712デフォルトの名無しさん
2005/06/30(木) 00:09:210713710
2005/06/30(木) 00:47:35ｽﾏｿ。早とちりしました。
persistence APIはORMのAPIを共通化しましょうって話だと認識してたんでこんがらがりました。
EJB3のCMT → persistence APIを実装したORM+分散オブジェクト
Hibernate3 → persistence APIを実装したORM
なんで「EJB3のORM = Hibernate3」って事ですね。
まぁイコールと言うとまた御幣がありそうなので「互換」が適切ですかね。
>712
EJBコンテナの外で利用する、に訂正します。どっかでそんな表現があって、カッコよかったんで真似しました。
0714デフォルトの名無しさん
2005/06/30(木) 01:28:11EJB3によってPOJOでの開発が可能になった。生産性はDIコンテナと同等レベル
↓
分散オブジェクトが気に入らなければローカルEJBで作ればよろし
↓
J2EE標準、血統書付き
↓
EJB3マンセー？
懸念点
１、DIの設定はソースコードの中ではなく外（例えばXMLファイル等）に在るべきという意見。
２、EJBコンテナへの依存。これは分散オブジェクトをサポートする以上仕方ない？
って所でOK？
EJBのAnnotation APIと互換性のあるDIコンテナとか在ったら面白いかもね
0715デフォルトの名無しさん
2005/06/30(木) 03:03:23DIの設定は外にあるべきというのが、中にあっても問題ないんじゃないの？になると思われ。
漏れには外にある必要性がわからん。
EJBコンテナの依存は、現実をみればSpringやSeasarを使えばそれらに依存するアプリになるから同じことだと思われ。
テスト用に設定をわけたいなら、テスト用にDIコンテナ使えばいいだけかと。
アプリはEJB3コンテナで動かして、テストはSpringなりSeasarでやる。
全体を見るために別ファイルにしたいのであれば、全体が見たいという要望が多ければ、全体が見れるツールが必ず現れる。
0716デフォルトの名無しさん
2005/06/30(木) 11:42:140717デフォルトの名無しさん
2005/06/30(木) 12:48:11を見る限り終わってない気がする
NetBeans4.2がいつでてくるかだな
GUI作成もすげーし
0718デフォルトの名無しさん
2005/07/01(金) 01:09:170719デフォルトの名無しさん
2005/07/01(金) 01:56:160720デフォルトの名無しさん
2005/07/01(金) 08:12:57JBuilder知らないけど、これもできるんじゃない?
0721デフォルトの名無しさん
2005/07/01(金) 15:29:450722デフォルトの名無しさん
2005/07/01(金) 15:30:280723デフォルトの名無しさん
2005/07/01(金) 15:45:03フリーのプロダクトはエディタでガリガリというのが多いが次期NetBeansのEJB対応を見る限り
ああいうのが今後のデフォなんだろうな
0724デフォルトの名無しさん
2005/07/01(金) 17:01:36生成したコード自体も複雑で、実際には生成したコードを見る必要があることもあって。
時期NBのEJB対応って、よくみると何もしてない。普通にクラスとメソッド追加しただけ。
0725デフォルトの名無しさん
2005/07/26(火) 17:05:510726デフォルトの名無しさん
2005/07/26(火) 17:13:25そういう奴はEJB使うな。
0727デフォルトの名無しさん
2005/07/26(火) 17:21:57こんなスレに即レスするなよｗ
0728デフォルトの名無しさん
2005/07/28(木) 02:22:130729デフォルトの名無しさん
2005/07/28(木) 02:49:370730デフォルトの名無しさん
2005/08/22(月) 23:57:070731デフォルトの名無しさん
2005/10/11(火) 17:06:05EJBってなんでMBean路線で
いかなかったんだろ。
(Beanにアダプタくっつけるやつ)
というかMBeanの拡張という形で
いかなかったんだろ。
ネットで調べても機能比較とかなくて
理由がわからない。
MBeanの書き方がめんどかったり
するのかな。
0732デフォルトの名無しさん
2005/10/11(火) 18:32:280733デフォルトの名無しさん
2005/10/17(月) 02:02:46■ このスレッドは過去ログ倉庫に格納されています