5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

EJBは終わってる

1 :デフォルトの名無しさん:02/11/05 16:30
EJBってパフォーマンスでないよな
それとも出る?
EJBに未来はないと思うが
否定派・賛成派共に語ってくれ


2 :デフォルトの名無しさん:02/11/05 16:42
2ゲット?

3 :デフォルトの名無しさん:02/11/05 16:43
>>1
どんなアプリケーションサーバー使ってるの?

4 :デフォルトの名無しさん:02/11/05 16:50
>>3
JRUNっす

5 :デフォルトの名無しさん:02/11/05 16:52
http://pc3.2ch.net/test/read.cgi/tech/1017240849/

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


7 :デフォルトの名無しさん:02/11/05 16:58
>>4
JRUNのIIOPまわりのエンジンが遅いのではないでしょうか?
JRUN、どんなの使ってるのかな...
ちなみに Borland Enterprise Server だと、VisiBrokerを
使っているからとても速いんだけどね。

8 :デフォルトの名無しさん:02/11/05 17:18
今 developer.java.sun.com につながりますか?

9 :デフォルトの名無しさん:02/11/05 17:36
>>134
スタック取りすぎ。

10 :デフォルトの名無しさん:02/11/05 22:07
>>7
でも全般的に速いとはいえないでしょ
AppServerちゃんたち


11 :デフォルトの名無しさん:02/11/05 22:08
>>7
Borlandのサーバって開発ライセンスは無料じゃないの?


12 :デフォルトの名無しさん:02/11/05 22:12
>>7
VisiBrokerでC/C++ CORBAできる人はEJBには見向きもしないと思われ


13 :デフォルトの名無しさん:02/11/05 22:21
どうせみんな大した規模の開発してないんでしょ?
よほどの規模でない限りEJBのメリットなんてないし。(別に煽りじゃないよ)
J2EEでのサーバサイドJavaBeansとEJBの関係は、MSの技術でいうところの
COMとCOM+/MTSの関係と一緒だね。
大した規模でないならざわざわ複雑で高度なコンポーネント技術使う必要ないもんね。
兵隊の確保も難しいし。

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



14 :デフォルトの名無しさん:02/11/05 23:17
>>11
ライセンスが必要です。

15 :デフォルトの名無しさん:02/11/05 23:19
>>12
RDBMSに接続するinterfaceに何使うの?

16 :デフォルトの名無しさん:02/11/05 23:22
EJBの代わりになにを使うの?

17 :デフォルトの名無しさん:02/11/05 23:35
ASP

18 :デフォルトの名無しさん:02/11/05 23:38
>>13
WebLogicなら、DriverManager.getConnectionでもプール有効です。
PoolManでも、私の作成したドライバでも、DriverManager経由でマッピング
された別DBへのプーリングされたコネクションが返されます。

19 :548:02/11/05 23:53
>>15
俺だったら
JNI + OracleだったらOCI8かな


20 :デフォルトの名無しさん:02/11/05 23:54
>>13
よほどの規模でなくてもEJB使ってパフォーマンスでないのよ
どーすんのさ
煽り返しじゃないよ


21 :デフォルトの名無しさん:02/11/05 23:55
>>13
貴方あまり現場の修羅場を知らないとみたが
管理系の人?


22 :デフォルトの名無しさん:02/11/05 23:58
>>13
メリットはどうでもいいんすよ
パフォーマンスがあぼんなんすよ


23 :デフォルトの名無しさん:02/11/05 23:59
>>14
サンキュー ちなみにいくらぐらい?
スマン自分で調べるのだるい


24 :デフォルトの名無しさん:02/11/06 00:02
>>16
COM CORBAブリッジとJNIとネイティブSQL API



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

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



26 :デフォルトの名無しさん:02/11/06 09:59
>>23
http://www.borland.co.jp/bes/bes1/sku.html より抜粋します

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

27 :デフォルトの名無しさん:02/11/06 10:07
禿しくスレ違いだけど、漏れはアポーのWebObjects使ってるのね。
んで、こいつにはEOFっていうRDBアクセスするフレームワークがあんだけど、
これ使ったらEJBなんて不便で煩雑で使ってられなくなってしもた。
EJB使うのに、ゴリゴリ書かなきゃいけないような部分が予め提供されてて、
こっちはそれを使うだけ。

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

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

30 :デフォルトの名無しさん:02/11/06 13:18
>>25
真面目なデプロイ屋さんなんですね
EJB肯定派としての意見
ありがたく頂戴します





31 :デフォルトの名無しさん:02/11/06 13:20
>>28
四マイクロのやることは、理想論ばかりで
いつもパフォーマンスを考えない


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


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

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


34 :デフォルトの名無しさん:02/11/06 14:37
>>33
信用していない理由を書かないのに批判するな。
ルートマネージャがそう言ってるから?・・・頭悪いね。

35 :デフォルトの名無しさん:02/11/06 16:31
GCJ使って、ネイティブコード出力ってできるんけ?

36 :デフォルトの名無しさん:02/11/06 16:54
>>33
その JVM で大規模開発いくつもやりましたが何か?
てか、大規模ってなんだよ。3億以下なら笑うぞ。

37 :デフォルトの名無しさん:02/11/06 16:56
3億以上使ってJava採用するクライアントも凄いな。

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

39 :デフォルトの名無しさん:02/11/06 17:31
>>34
なんでもかんでもJavaで組もうとスルヤシのほうが
よっぽど頭わりいと思うけどな


40 :デフォルトの名無しさん:02/11/06 17:54
>>39
おまえが頭悪いのは分かったから

41 :デフォルトの名無しさん:02/11/06 21:55
>>37
禿同
クライアントはJava厨SAにだまされているとしか
言いようがないなぁ


42 :デフォルトの名無しさん:02/11/06 21:57
お客: 「どーも遅いんだけどねえ」
SE : 「JavaとEJBの仕様です。どもなりません」

43 :デフォルトの名無しさん:02/11/06 23:21
>>42
そりゃしょうがない。EJBが遅いというのは事実は事実。
でも今時サーバサイドJavaが遅いなんていってると初心者扱いされちゃうぞ。

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

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

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

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



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

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

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



45 :デフォルトの名無しさん:02/11/07 10:37
>>44
1995 年から頭が進化していないの間違いだろ? な?
じつは Java あまり使ったことが無いだろ? な?
実に香ばしい匂いがするよ。優秀なる Sヨ さん

46 :43:02/11/07 21:46
>>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 :デフォルトの名無しさん:02/11/07 21:50
正直言って新しい技術が古い技術より遅いのは当たり前。

48 :デフォルトの名無しさん:02/11/07 21:55
>>47
ハードウェア技術者がいくらがんばってもソフトウェア技術者がそれをダメにする。

ムーアの逆定理。

49 :デフォルトの名無しさん:02/11/07 22:07
Javaが遅いって今時そんなこと言ってるのは、脳みそがふるすぎです。
HotSpotVMの発想は、進化すればCコンパイラがはく静的なバイナリより
早くなるチャンスがある。現状でもまあまあいい線いっている。

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

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

50 :デフォルトの名無しさん:02/11/07 22:14
(もう何世代かCPUが進化しないと)EJBを使うのは難しい。

51 :デフォルトの名無しさん:02/11/07 22:17
SessionFacade
DataAccessObject
ValueObject

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

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

52 :デフォルトの名無しさん:02/11/07 22:19
速いのを目指すのはハードの仕事。ソフトは便利を目指すべき。

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

54 :デフォルトの名無しさん:02/11/07 22:32
---- 常識では考えられないことをする会社、その名はS○NY ----

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


55 :デフォルトの名無しさん:02/11/07 22:38
「着払い」は受取人が「聞いてません、発送者の勝手な行動です」と
言えば払わなくて済むのに。


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


56 :43:02/11/07 22:39
>>52がいいこといった!・・・ような気がする。

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

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

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



57 :デフォルトの名無しさん:02/11/07 22:44
>>56
実行時性能と、OO的発想(と、それがもたらす管理の容易さ)は、
システムの要求できまってくる天秤の両端ですよね。
VOとかは、純粋なOO的にはアホですが、分散OOのRMI実装の方法
としては「やらないと遅くなるからしかたなく」ですね。

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

58 :デフォルトの名無しさん:02/11/07 22:50
>>44 が起爆剤になって良スレ化しとる…

59 :デフォルトの名無しさん:02/11/07 22:56
EJBのみでなく分散オブジェクトを総括した流れになってきているかな?


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

61 :デフォルトの名無しさん:02/11/07 22:58
ところで、もうじき、同一筐体内でのコールは同一JVM上で可能になるのでは?

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

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

63 :デフォルトの名無しさん:02/11/07 23:07
>>62
へぇ?そんな計画があるんだ?勉強不足ゆえ知らんかった。
まぁ今でもローカルならGIOPにするとか工夫してるんじゃなかったっけ?

>>57
妙案!!



64 :デフォルトの名無しさん:02/11/08 10:38
>>63
GIOPが何なのか知らないみたいだね。言いたい事は推測できるけど。

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

65 :デフォルトの名無しさん:02/11/08 23:26
ここの住人って遅れてない?

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

66 :デフォルトの名無しさん:02/11/09 09:14
すんまそん厨房ですが
>>65
2.1をサポートしている主流どこのアプリケーションサーバって
どのくらいあるのですか(安定運用できるものに限る)

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


67 :U ◆CZtFsGiu0c :02/11/09 09:17
ローカルインタフェースって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(ローカルインタフェース)
って構成も普通にできるようになりそうですね。

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

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


69 :デフォルトの名無しさん:02/11/09 10:21
Javaってプロトタイピングにしか使わないっしょ。

70 :デフォルトの名無しさん:02/11/09 10:54
向河原辺りのNが紛れ込んでるな。

71 :デフォルトの名無しさん:02/11/10 01:08
>>69
プロトタイプだったらもっとちょろい言語があると思うが・・・・

72 :デフォルトの名無しさん:02/11/10 01:22
4219行のJVM
ttp://homepage2.nifty.com/rohizuka/ka/pa_003_a.htm


73 :デフォルトの名無しさん:02/11/10 01:40
>>72
どこかで見た URL だな
多分人形の悲鳴だと思うが。

74 :デフォルトの名無しさん:02/11/10 02:14
SOAP、UDDI、WDSL関係は、ココと絡むのかなあ・・・
JMSってSOAPサポートしてたよねえ?

75 :デフォルトの名無しさん:02/11/10 11:13
言うだけでテストしないのもなんなんで
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を利用しなくとも
いけそうです。

76 :デフォルトの名無しさん:02/11/10 22:20
>>75
EJB(というかRMIサーバ)とCORBAサーバでどういうコード動かしてる
かによるじゃん、そんなの。
あと、EJBのデプロイって面倒か?どんなAPサバつかってるの?
デプロイ記述は、静的にコード内部で書いていたプロパティ設定を、
動的変更可能なようにパラメータ化して外部リソースに移しただけ
のはずだが。

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

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

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

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

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

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



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



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


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

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


81 :デフォルトの名無しさん:02/11/11 00:21
>>80
誰も言わないどころか見当違いも甚だしいと思うが。
例えが悪すぎ。


82 :デフォルトの名無しさん:02/11/11 00:34
>>13=>>25=>>43=>>46=>>56=>>77です。(書きすぎか?)

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

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




83 :デフォルトの名無しさん:02/11/11 15:11
>>82
>デバッグのし難さ
どこらへんが難しいの?

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

85 :デフォルトの名無しさん:02/11/11 20:34
>>83
ネットワーク上にコンポーネントが分散化されているからじゃない?


86 :デフォルトの名無しさん:02/11/11 22:22
>>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関連のサービス関係については、宿題とする

87 :デフォルトの名無しさん:02/11/11 23:00
>その他
>lookup関連のサービス関係については、宿題とする

Jiniでちゅか?とうとう日の目を見る日がきたのでちゅね?ワーイ。




88 :80:02/11/11 23:28
>>86
長文サンクス。いつものCORBA派の人かな?

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

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

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

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

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

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



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

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

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

90 :デフォルトの名無しさん:02/11/12 01:19
>(俺は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レスサンクス今日は眠いのでレスは後日で勘弁してください


91 :デフォルトの名無しさん:02/11/12 02:20
こんな良スレになっちまって >>1 も草葉の陰で喜んでおろう

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


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



94 :デフォルトの名無しさん:02/11/13 02:03
>>93
> あ、でもそういうのは別にEJBである必要もないのか?JavaBeansで十分?

そっすね。

95 :デフォルトの名無しさん:02/11/13 02:10
結局さSunの高いハードを買わせるための技術なんだよ。
開発効率を20%上げるために二倍速い(5倍高い)ハードを買ってください、
となるんじゃない?w
パソコン文化とはちょっと違うのさ。

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

96 :デフォルトの名無しさん:02/11/13 13:04
データサービス層やEIS層にアクセスしないEJBって存在価値あるのか?


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


98 :良スレ救済委員会:02/11/24 07:19



99 :デフォルトの名無しさん:02/11/24 18:31
J2EE 1.4βあげ

100 :デフォルトの名無しさん:02/11/24 21:00
最近のAPIは1.4用ばっかで
今のWebSphereV4じゃ使えんよ

101 :デフォルトの名無しさん:02/11/24 23:00
>>100
1.3の勘違い?
ちなみにJ2EE1.3対応のWebSphereV5がやっとでたね。

102 :デフォルトの名無しさん:02/11/29 22:51
やっと
Borland Enterprise Serverを入手しました
BisiBroker 4.5です
C++ Corbaの実装と、Java EJBの実装ができる環境です
しかし、Corbaの資料のないこと・・
英文マニュアルと付き合わないとだめですね



103 :デフォルトの名無しさん:02/12/01 01:11
>>102
VisiBrokerですよね。
しかもVisiBroker4.5ということは、Borland Enterprise Server ではなく、
随分以前の Borland AppServer4.5 の間違いでは?

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

104 :デフォルトの名無しさん:02/12/05 17:49
>>103
亀レスですんません
テスト用を前提に
App Server
Enterprise Server
もろもろ全てお借りしますた

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

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

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





105 :デフォルトの名無しさん:02/12/20 14:26
>>89
Gnomeは落ち目、Fresco/Berlinもブレークする気配が全くない。
というところで「CORBAは現役だ!」って言われても困ってしまいます。
どちらもCORBAなんか使うから人が逃げちゃうんだ、って言われてるし...。


106 :デフォルトの名無しさん:02/12/20 22:08
お題目は悪くないんだけどね。使うと(使えれば)便利は便利だし。
しかし、OMG に標準化をさせると重厚長大になっていかんね。

107 :デフォルトの名無しさん:03/01/04 19:36
age

108 :デフォルトの名無しさん:03/01/05 18:29
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なだけ?

109 :デフォルトの名無しさん:03/01/05 18:35
お前等髪ちゃんと洗ってる?
服装もダサそうだね。
わけわからんよれよれジーンズに穴のあいた靴下。
そして、何日も着て汚れきったシャツをジーンズにタックイン。
周りの人間に馬鹿にされてるよ?


110 :デフォルトの名無しさん:03/01/06 20:06
>>108
そのとおりだけど、いっていることはただの一般論。

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

111 :デフォルトの名無しさん:03/01/06 20:09
>ジーンズにタックイン

愛読書は FINE BOYS でつか?

112 :IP記録実験:03/01/08 21:45
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を提出することがある。

113 :デフォルトの名無しさん:03/01/09 02:31
記念カキコ(゚∀゚)

114 :デフォルトの名無しさん:03/01/09 03:15
2チャンネルに殺人予告


115 :デフォルトの名無しさん:03/01/09 03:57
 
 なにをいまさら。通知実験の方はまだ?

116 :デフォルトの名無しさん:03/01/09 13:11
悪いこと書かないから関係ないよ

117 :デフォルトの名無しさん:03/01/09 14:54
>>342
(・∀・)イイ!!

118 :デフォルトの名無しさん:03/01/09 23:16
>>806
名前や住所が表示される訳じゃないし。

119 :デフォルトの名無しさん:03/01/10 01:06
IP記録で今までのようにカキコできない香具師はいくじなし

120 :デフォルトの名無しさん:03/01/10 09:43
>(電波)

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

121 :デフォルトの名無しさん:03/01/10 10:23
>>129
そうそう。なんでも今年の風邪は高熱が出るらしくて。
って手遅れかい。まぁ再発に気をつけろってことで。

122 :デフォルトの名無しさん:03/01/10 10:55
JNBなら100円送金するぞ(w

123 :デフォルトの名無しさん:03/01/10 11:39
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

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


124 :デフォルトの名無しさん:03/01/10 12:07
正論が必ずしも正解であるとは限らない。


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

125 :デフォルトの名無しさん:03/01/10 13:00
>>573
2chに個人情報の保護をお願いする方が間違ってると思われ
事実上IPは誰にも見れる様になるだろうね、まあその中でプロパイダの中に協力者がいる
のはごく一部だろうが、、、

126 :デフォルトの名無しさん:03/01/10 15:23
自分が必要だと思っていることは、他人も必要としている場合が多い。

127 :デフォルトの名無しさん:03/01/10 16:50
いらない板BEST3

1 ハングル

2 半角(ピンクは全部いらん)

3 ラウンジ

128 :デフォルトの名無しさん:03/01/10 23:11
>>ひろゆき

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

129 :デフォルトの名無しさん:03/01/10 23:15
ネタ書くのにも気を遣うようになっちゃうね

130 :デフォルトの名無しさん:03/01/11 00:35
カキコ以前に窃盗で捕まる罠

131 :デフォルトの名無しさん:03/01/11 00:41
いわゆる糞スレは減らないよな

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

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

133 :デフォルトの名無しさん:03/01/11 10:37
======2==C==H======================================================

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

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

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

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

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

んじゃ!

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

134 :デフォルトの名無しさん:03/01/11 11:28
ひろゆきなんて嫌いだ!たらこ唇!

135 :デフォルトの名無しさん:03/01/11 13:34
んじゃ、2ちゃんねら有志が出資して
ひろゆきにSPつけるか。(w
これで暴力問題は解決っと。

136 :デフォルトの名無しさん:03/01/11 16:20
ていうか、2ちゃんねるに不都合な?スレはすべて
この騒ぎに便乗してスレストかかってるぞ。

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/
断固として2chとひろゆきを支持する(@w荒
http://qb.2ch.net/test/read.cgi/accuse/1040814322/

137 :デフォルトの名無しさん:03/01/11 16:26
復活してちょっとうれしい今日の漏れ

138 :デフォルトの名無しさん:03/01/12 00:29
漏らすバカが出るだろうというのが一番の問題なんだよ

139 :デフォルトの名無しさん:03/01/12 00:40
ごめん、なんで「それを言うなら」になるのかがわからん(^_^;)
後半の批判は批判でいいと思うんだけど、書き込む人間の自己責任ってのとどう関係してるの?

140 :デフォルトの名無しさん:03/01/12 03:16
http://wow.bbspink.com/test/read.cgi/feti/1039253916/

の522からなんか出てるんですけど
2chってこんなに変わるの?

141 :デフォルトの名無しさん:03/01/12 03:18
レスありがとう。
俺素人だからよくわからないが
アク禁にしないのは何か理由るのかな・・?

142 :デフォルトの名無しさん:03/01/12 10:49
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

143 :デフォルトの名無しさん:03/01/12 10:50
1chに関してだけど。
トップダウンによるキャッチアップは効果的だとは
思うが、所詮真似事だからどこかに歪みが出て
来そうなんだよね。

144 :デフォルトの名無しさん:03/01/12 21:23
ちくり裏事情なんかは、WINNY掲示板みたいなWINNY型P2Pにして、
2ちゃんからリンクして拾ってくるようにできんかな?

145 :デフォルトの名無しさん:03/01/12 21:27
zD2HIsxl
厨房逝ってよし。

146 :デフォルトの名無しさん:03/01/12 21:37
なんか各所で「ブラウザを立ち上げ直してください」とかいうエラーでて書き込めないって
人がいるけど、それって何をするとでるの?
俺は見たこと無い。

147 :デフォルトの名無しさん:03/01/13 23:28
掲示板の書き込みを鵜呑みにするやつはもっと悲惨だよ

148 :山崎渉:03/01/15 18:13
(^^)

149 :山崎渉:03/01/23 22:12
(^^)

150 :デフォルトの名無しさん:03/02/27 11:54
3億以上使ってJava採用するクライアントも凄いな。

151 :デフォルトの名無しさん:03/02/27 12:18
今度2,30年使えるシステムという勘定なんだろうけど、
Sunが潰れたりしないだろうか。Javaより先に死んで
しまいそうなんだけど。サポートのなくなったSunにどれだけの
価値があるのかね。

152 :デフォルトの名無しさん:03/02/28 23:41
Sunは潰れる前にIBMに買収されるだろ。


153 :デフォルトの名無しさん:03/03/08 20:51
このスレは終わってる

154 :デフォルトの名無しさん:03/04/18 00:51
保守あげ

155 :山崎渉:03/04/20 03:11
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

156 :山崎渉:03/04/20 03:45
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

157 :デフォルトの名無しさん:03/04/20 22:18
EJBってリモート前提で、ネットワーク介すから、遅いのは当然。

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

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

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

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

現在のEJBの使用範囲はイントラ内の分散処理に限定。インターネット
はSOAPの守備範囲。

158 :デフォルトの名無しさん:03/04/20 22:20
test

159 :デフォルトの名無しさん:03/04/20 22:21
ハァ?EJBは万能ですよ?

160 :デフォルトの名無しさん:03/04/20 23:22
PostgreSQL で EJB できますか?

161 :デフォルトの名無しさん:03/04/21 01:12
>>157

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

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

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

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

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

>>160

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

162 :デフォルトの名無しさん:03/04/21 01:17
このスレの内容は、大体2年くらい前に議論した覚えがある。Too Late

163 :デフォルトの名無しさん:03/04/21 01:18
>>160
OracleでできてPostgreSQLでできねーわけないだろ

164 :デフォルトの名無しさん:03/04/21 01:30
>>163
Oracle8/9i AS ならEJBサポートしてるけど。PostgreSQLとは分野違いだね。
Oracle9i DBには、EJBのサポートあるの?
>>160
PostgreSQL+JBOSSならできそうだけど

165 :160:03/04/21 01:44
>>163

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

>>164

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

166 :デフォルトの名無しさん:03/04/21 02:22
ん?EJBのPersistent ServiceやTransaction Service周りは、
Oracle8iDB自体で多少サポートしていたかなー、とうろ覚えの記憶で書きました。


167 :デフォルトの名無しさん:03/04/21 02:24
>>160 つか、キミのいうPostgreSQLでEJBするってどういう意味?ネタ師?



168 :デフォルトの名無しさん:03/04/21 02:34
や は り ネ タ 師 だ っ た か


169 :_:03/04/21 02:36
      へヘ
     /〃⌒⌒ヽ
     〈〈 ノノノハ))) / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
      |ヽ|| ´∀`||< 先生!こんなのがありました!
    _φ╂∨⊂)__ \______________
  /旦/三/ /|
 | ̄ ̄ ̄ ̄ ̄|  |< http://freeweb2.kakiko.com/saitama/
 |_____|


170 :160:03/04/21 06:20
>>167,168

寝ちゃってました。

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

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

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

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

171 :デフォルトの名無しさん:03/04/21 23:39
>>160

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

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

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

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



172 :171:03/04/21 23:40
>>161でした。失礼・・・

173 :161:03/04/22 01:49
>>171

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

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

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

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

174 :デフォルトの名無しさん:03/04/22 01:59
>>160,>>170
はいはい了解。たしかConnector Architectureとか呼ぶ仕組ね。

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


175 :bloom:03/04/22 02:05
http://homepage.mac.com/ayaya16/

176 :デフォルトの名無しさん:03/04/22 02:21
>>160 書いたのは俺なんだが、名前欄に 160 と入れてる奴はどちら様で?
ちなみに PostgreSQL を DB にできる EJB コンテナってありまつか? ってのが
本意ね。

177 :デフォルトの名無しさん:03/04/22 02:35
一人多重人格者様ですか。はー


178 :161:03/04/22 02:38
>>176

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

179 :デフォルトの名無しさん:03/04/22 02:39
>>178
もう少し丁寧に謝れ。

180 :デフォルトの名無しさん:03/04/22 20:58
>>179

市ね。

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

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

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



182 :161:03/04/23 00:57
>>171

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

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

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

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

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

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

183 :デフォルトの名無しさん:03/04/26 14:05
>>171
>EJBは生産性下がると思うよ。
こーいう人、今だに居るんですね...。
EJBをちゃんと理解していない証拠です。

184 :デフォルトの名無しさん:03/04/26 21:57
>183
こんな人、まだ居るんですね。
EJBの使用経験が無い証拠です。

185 :デフォルトの名無しさん:03/04/26 23:39
cFrameworkの開発経験ある人います?
値段高いし、あまりメジャーじゃ無いけど。
cBankにあるようなEJBコンポーネント群を売る商売が
成り立つかどうかでEJBの状況も随分変わると思う。


186 :デフォルトの名無しさん:03/04/26 23:59
>184
こんな人、まだ居るんですね。
EJBを理解せずに開発してプロジェクトをトラブらせた証拠です。

187 :デフォルトの名無しさん:03/04/27 23:35
結局、最良・最強のフレームワークはどれ?
個人的にはStrutsが一番バランス取れてると思うが。
turbineは難しいし。
cFrameworkは高価だし。
JBossは使った事無い。


188 :デフォルトの名無しさん:03/04/28 00:21
>187

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

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

189 :デフォルトの名無しさん:03/04/28 01:34
>>187
スレ違い?

190 :デフォルトの名無しさん:03/04/28 01:51
CMP EntityBeanの中から、DAO経由でSQL発行したいんだけど
普通にEntityBeanのデータソースからコネクション取得すればいいの?


191 :デフォルトの名無しさん:03/04/28 02:07
>190
> EntityBeanのデータソース

意味不明。


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

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

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


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

193 :デフォルトの名無しさん:03/04/28 04:55
>>191
意味不明。
とか言う前に
勉強しろ。

194 :171:03/04/29 13:57
>>161
161さんの環境がうらやましい・・・

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

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

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



195 :161:03/04/30 02:24
>>171

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

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

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

196 :デフォルトの名無しさん:03/04/30 13:56
>>195
JTA使って作るのも別に難しくないよ。単に解説とかの資料が少ないのと、
トランザクションの重要性を理解してる人が少ないからそう思うんじゃないの?

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

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

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

197 :デフォルトの名無しさん:03/05/08 05:09
>>1
賛否両論 語ってくれ。と言え。学がないからEJBも愚か、日本語さえも
満足に使い切れない。

198 :デフォルトの名無しさん:03/05/08 05:12
>>192
> IとかHとかEとか渡り歩いたけど、
EJBは派遣社員に理解できる代物ではない。

199 :動画直リン:03/05/08 05:13
http://homepage.mac.com/hitomi18/

200 :デフォルトの名無しさん:03/05/08 05:57
JavaBeans、EJB、JSP、Servletの位置関係を、パーな俺に教えてくれないか?
どれを勉強すれば一番就職に有利とか。

201 :デフォルトの名無しさん:03/05/08 06:07
あと、J2EEって上のどれなの?

202 :デフォルトの名無しさん:03/05/08 06:14
>>200
Javaなんて儲からないからやめとけ。
ドライバをガリガリ書きまくるのが一番儲かる(マジ

203 :デフォルトの名無しさん:03/05/08 09:45
>>202
Jiniサービスが本格的に始動おしたとき、おまいの職は失われるだろう。フッフッフ

204 :デフォルトの名無しさん:03/05/08 12:26
>Jiniサービスが本格的に始動おしたとき
こんな冗談言ってないで>>200の質問に答えてやれよ

205 :デフォルトの名無しさん:03/05/08 13:03
とりあえず>>200にはEJBが就職に有利とでも逝っておこうか。
ほかはおまけ。JSPとServletはEJBを習得する前にやっておくと楽。
会社によってはEJBを使わずJSPとServletだけでやっているところもある。

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

206 :デフォルトの名無しさん:03/05/09 00:03
>>205
現実を知らないのと、理解がイマイチのようだな。

207 :デフォルトの名無しさん:03/05/09 02:19
>>108
個人的には108の下記書き込みはあっていると思っているのだけど、
どうなんですか?

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

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


208 :デフォルトの名無しさん:03/05/09 02:31
>>207
参照系をどうにかするためにEJB-QLがあるのですよ。
まあ、かなり無理がある後付け仕様だと思うけど。
SQLつかうのとどう違うのよ、ということで。

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


210 :デフォルトの名無しさん:03/05/09 02:44
>>209
サーバのメモリは6GB〜十数GB。と。

211 :デフォルトの名無しさん:03/05/09 02:45
>>209
そんなもんEJBの作り方次第でしょ。
リストで抱えても何の問題もないよ。

212 :デフォルトの名無しさん:03/05/09 02:46
>>210
即答するが、物理メモリでなく、VMヒープがパンク

213 :デフォルトの名無しさん:03/05/09 02:48
>>209
EJBは1万件くらいで食らい尽くすようなものではないと思われます。


214 :デフォルトの名無しさん:03/05/09 02:48
>>209
あのー、ガーベージコレクションって知ってます?

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

215 :207:03/05/09 02:48
>>211
EntityBeanのインスタンスってレコードごとにしか作れないのではないのですか?
EntityBeanの1インスタンス=複数レコード
にすることってできるのですか?
そうするとfindByPrimaryKeyメソッド等でぼろぼろになると思うのですがどうなんでしょうか?

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

216 :デフォルトの名無しさん:03/05/09 02:50
>>215
参照系と更新系を分離して考えようね。

217 :デフォルトの名無しさん:03/05/09 03:02
>>214
>>212 ではないが、今のところ Sun JDK 1.4 (Win/Linux)、IBM JDK
1.3 (AIX) は Maximum Heap 1.5GB が限界って所だな。試しに -Xmx???MB
で何GBまで行けるか試してみれ。

218 :デフォルトの名無しさん:03/05/09 03:03
>>214
ガベージコレクタのリソース回収に期待しすぎてたら痛い目遭いそうな予感。
VMヒープがGBオーダーできるか否かは気になるところ。
ServerVMのみ可能とかあるのかな?



219 :デフォルトの名無しさん:03/05/09 03:06
1つのVMに1.5GB割り当てる状況が俺には想像つかない。

220 :デフォルトの名無しさん:03/05/09 03:06
>>218
期待ってなによ(ワラ
強参照チェインを消しておけば、メモリオーバーフロー起こす前に
消えてくれるでしょ。参照チェインの構造をライフサイクルにあわせて
付けはずしするだけで、別にあいまいな期待などしていませんが。

221 :デフォルトの名無しさん:03/05/09 03:07
>>219
サーバー用途でVM複数立ち上げるような無駄なまねを
するより100倍ましかと。

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

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

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


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

225 :デフォルトの名無しさん:03/05/10 18:44
>>222
せめてWeb,AP,DBでサーバは分けるべきだね。
特にAPサーバには高負荷かかるし。

226 :デフォルトの名無しさん:03/05/11 00:17
> (つまりFinderメソッドで1万件データCollectionデータが取得できたら、
>  1万件のEntityBeanがメモリにロードされる。)
> 間違っていますか?

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

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

227 :デフォルトの名無しさん:03/05/11 00:47
すまん、イントラ500人を一台で捌けないのか?

228 :デフォルトの名無しさん:03/05/11 00:51
そりゃマシンのスペック、実装したシステムの重さによりけりだろうが。


229 :デフォルトの名無しさん:03/05/11 00:59
人数はコネクション数やテンポラリデータを増やすのかな?
負荷は主に処理するデータ量に比例すると思うけど・・・

230 :デフォルトの名無しさん:03/05/11 01:12
>>229
> 人数はコネクション数やテンポラリデータを増やすのかな?
テンポラリデータってどういう意味?

人数増加=データ量増加

わかる?

231 :デフォルトの名無しさん:03/05/11 01:15
> 人数増加=データ量増加

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

232 :デフォルトの名無しさん:03/05/11 01:26
>>231
DBだけ考えても人数増えたら、なにかしらのレコードは増えるが?
それでも扱うデータが増えないと言えますか?
3レコード検索と3万レコード検索ではどちらが負荷高い?考えるまでもないだろ。


233 :デフォルトの名無しさん:03/05/11 01:31
以外に大規模なシステムでもDBサーバにはCPU負荷はかからない。
フロントエンドに近いサーバほど大忙し。


234 :デフォルトの名無しさん:03/05/11 01:34
>>232
「なにかしらレコードが増える」その量が、
利用者数に依存するとは限らない。

235 :デフォルトの名無しさん:03/05/11 01:37
>>234
あんた、エンタープライズ開発したことある?

236 :デフォルトの名無しさん:03/05/11 01:40
「なにかしらレコードが増える」その量が、
エンタープライズ開発かどうかに依存するとは限らない。

237 :デフォルトの名無しさん:03/05/11 01:43
もはやネタ決定。

238 :デフォルトの名無しさん:03/05/11 01:44
「エンタープライズ開発だからですよ」
ってかなりヤバいな。

239 :デフォルトの名無しさん:03/05/11 01:44
>>236の発言」その量が、
このスレの発展に依存するとは限らない。

240 :デフォルトの名無しさん:03/05/11 01:46
J2EEネタはマジでヤバイって

241 :デフォルトの名無しさん:03/05/11 01:47
結論:鯖負荷は設計次第

242 :デフォルトの名無しさん:03/05/11 01:49
ちゃんと負荷の想定のところに書いとけよ
「利用者数に比例してなんかしらレコードが増える」って。
なんせエンタープライズだからな。

243 :デフォルトの名無しさん:03/05/11 01:50
>>242
意味不明

244 :デフォルトの名無しさん:03/05/11 01:58
エンタープライズなんてただの飾りですよ。偉い人にはそれがわからんのです。

245 :デフォルトの名無しさん:03/05/11 01:58
今やってるシステムではアプリケーションサーバがかなり負荷高いな。
EJB,CORBA混合の環境。やはり利用者増加にしたがってCPU負荷も大きくなっている。
って、当たり前だが。

246 :デフォルトの名無しさん:03/05/11 02:04
今やってるシステムではDBサーバの負荷が高いな。


247 :デフォルトの名無しさん:03/05/11 02:05
ていうか、お前らの議論は
x * y * 8 と a * b * 7 どっちが大きい?

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

248 :デフォルトの名無しさん:03/05/11 02:07
>>244
エンタープライズって「企業」って意味。それだけ。
なにが飾りなのかと小一時間。

249 :デフォルトの名無しさん:03/05/11 02:07
>>246
その負荷はCPUなのかメモリなのかディスクなのかネットワークなのか。
>>247
まったくそのとおり。

250 :デフォルトの名無しさん:03/05/11 02:08
>>247
謎の計算式持ち出すな

251 :デフォルトの名無しさん:03/05/11 02:23
ダイアゴン横丁に行きたいのですがどうやったら行けますか?


252 :デフォルトの名無しさん:03/05/11 02:24
>>249
CPU負荷です。

253 :デフォルトの名無しさん:03/05/11 02:34
>>247
あんた、エンタープライズ開発したことある?

254 :デフォルトの名無しさん:03/05/11 02:37
たちの悪い香具師が粘着ぎみだな。

255 :デフォルトの名無しさん:03/05/11 02:37
>>248カツタニマジレスカコワルイ

256 :デフォルトの名無しさん:03/05/11 02:38
>>253
あんた、エンタープライズ開発したことある?

257 :デフォルトの名無しさん:03/05/11 03:17
企業を開発?

258 :デフォルトの名無しさん:03/05/11 03:27
企業JAVA豆。
EJB

259 :デフォルトの名無しさん:03/05/11 03:48
enterprise
【@】エンタープライズ、エンタプライズ、【変化】《複》enterprises、【大学入試】
【名-1】企業、事業、政府支援企業
【名-2】企て、計画、仕事、活動
【名-3】進取の気性、積極性、冒険心

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

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


260 :デフォルトの名無しさん:03/05/11 03:54
何かエンタープライズ日和だな(w

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

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

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

261 :デフォルトの名無しさん:03/05/11 04:00
>>260
EJB開発実績を作ることをメリットとして強要する会社もあるわけだが。


262 :デフォルトの名無しさん:03/05/11 04:16
EJBがWebサービスより優れている点を語ってくれ

263 :デフォルトの名無しさん:03/05/11 04:19
>>261なるほど、商売のためか。
企業{で|が}開発だな。

264 :デフォルトの名無しさん:03/05/11 04:33
EJBの良書って何かある?
英語わからんので洋書は×

265 :まめ:03/05/11 05:38
まめ

266 :デフォルトの名無しさん:03/05/11 18:54
>262

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

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

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

267 :デフォルトの名無しさん:03/05/11 19:00
>>266
例えが曖昧。

268 :デフォルトの名無しさん:03/05/11 19:16
>>267

じゃあ、こうしよう。

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

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

269 :デフォルトの名無しさん:03/05/17 00:47
>>268
それは明確に優劣が出るだろ。
コアクラスのメソッドに文句言う香具師はそんなに多くない。Javaヲタくらいだ。
殆どの香具師は呼び出す段階で馬鹿やってる。


270 :デフォルトの名無しさん:03/05/17 11:47
別に例え話の上手下手なんてどうでも良いよ。

と言いつつ便乗。

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

どう?

271 :デフォルトの名無しさん:03/05/17 12:56
いや、一応、EJBとWebサービスに対応させて例えていたつもりだったのだけど....。

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

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

272 :デフォルトの名無しさん:03/05/19 23:22
>>13
EJBが大規模開発に向いている理由を教えてください。おながいします。

273 :デフォルトの名無しさん:03/05/20 00:02
>>272
第一にトランザクション制御をしてくれること。
下手なプログラマに任せるよりコンテナで制御したほうが
間違いなくCommit or Rollbackしてくれる。

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

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

こんなとこですかな。


274 :デフォルトの名無しさん:03/05/20 00:54
>>273
回答ありがとうございます。

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

275 :デフォルトの名無しさん:03/05/20 01:12
273じゃないけど

>>272

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

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


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


277 :デフォルトの名無しさん:03/05/20 01:22
確かに、規模が小さめだと面倒なだけかもしれない。
いい勉強にはなるけど。

278 :デフォルトの名無しさん:03/05/20 01:24
>274
大規模開発といっても人によっていろいろ定義があると思います。

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

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

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

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


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


280 :デフォルトの名無しさん:03/05/20 01:47
EJBのメリットとして分散オブジェクトがよく挙げられてますが、
実際EJBクライアントとEJBを物理的に別サーバにすることは
あまり考えられないと思っています。

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


281 :デフォルトの名無しさん:03/05/20 02:05
>>280
>Servlet+JavaBeansではクラスタリングできないのでしょうか?
なぜできないと思う?EJB使わないとクラスタリングが不可能なわけ?
もっと根本から理解を深めた方がいい。今のあんたは目先の技術に執着しすぎ。



282 :デフォルトの名無しさん:03/05/20 03:23
>>281
結局EJBを使わなくてもクラスタリングできるんですね。
そうすると、EJBをEJBクライアントと同じマシンで動かすという前提だと、
EJBのメリットってトランザクション管理をコンテナに任せるくらいしかないというのが結論になるのでしょうか?


283 :デフォルトの名無しさん:03/05/20 04:24
>>282
そうだね。終了。

284 :デフォルトの名無しさん:03/05/20 12:49
   このレスを見た人間は十三日以内に死にます。
      ※あなたに訪れる死を回避する方法が一つだけあります。
     それはこのコピペを一時間以内に7つ、別のスレに貼り付ける事です
    /\___/ヽ   ヽ
   /    ::::::::::::::::\ つ
  . |  ,,-‐‐   ‐‐-、 .:::| わ
  |  、_(゜)_,:  _(゜)_, :::|ぁぁ
.   |    ::<      .::|あぁ
   \  /( [三] )ヽ ::/ああ
   /`ー‐--‐‐―´\ぁあ  


285 :デフォルトの名無しさん:03/05/20 12:59
>>283
で、そのうちEJBと似たような仕組みを自分たちでもう一回作り直すと。

286 :デフォルトの名無しさん:03/05/20 23:54
>>282
結局EJBのメリットって言うのはそんなもんだ。


287 :デフォルトの名無しさん:03/05/20 23:56
>279
>テストという意味では、不特定多数が関わってるオープンソースの方が信頼できない?
じゃ、JBOSS使えば良いんじゃない。

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

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


288 :デフォルトの名無しさん:03/05/21 00:17
漏れはEJB賛成派だけど、

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

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

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

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

289 :デフォルトの名無しさん:03/05/21 00:59
JDBCって何?PRO*Cでいいじゃん。

290 :デフォルトの名無しさん:03/05/21 02:57
JBossは不特定の大勢が関わってるオープンソースとはいえないと思うが。

291 :デフォルトの名無しさん:03/05/21 03:00
Resin使ったほうがいいよ

292 :デフォルトの名無しさん:03/05/21 03:06
Resinってサーブレットコンテナ?
Resin+JBoss(tomcat抜き)てな感じの構成になるのか?

293 :bloom:03/05/21 03:11
http://homepage.mac.com/ayaya16/

294 :デフォルトの名無しさん:03/05/26 03:10
>>288
EJBのどこに賛成してるのかを説明してから、
そういう事をいってください。



295 :デフォルトの名無しさん:03/05/26 03:46
そういう説明がうまくできない人ほど、新しいものに飛びつきたがるよね

296 :デフォルトの名無しさん:03/05/26 04:01
勉強すればするほど
そんなにEJBっていいのか?
逆にめんどくさくないか?
って思える

297 :デフォルトの名無しさん:03/05/26 04:37
>>296
禿同

298 :デフォルトの名無しさん:03/05/26 04:55
うまくいえないんだけど
プログラマとかデプロイヤとか
きちんと作業を分担できる環境(人数)で開発するのなら
EJB使ってもいいと思うけど
少ない人数で、しかもプログラマが
アプリケーションサーバ特有のことも
勉強しないといけないような現場では効率落ちると思う

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

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

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



299 :デフォルトの名無しさん:03/05/26 04:55
EJBはCOBOLをリプレイスするそのときのために
いまから準備しるってかんじだよな。

300 :デフォルトの名無しさん:03/05/26 05:00
>>298
EJBで全ての機能使う必要ない。ってどこかに書いてあった。
少人数でロールする場合のやり方も書いてあったような。


301 :デフォルトの名無しさん:03/05/26 05:07
>>300
どこに書いてありましたか
書籍でしょうか

302 :デフォルトの名無しさん:03/05/26 05:14
>>301
Sunか@ITか。記憶だから信用しないでくれ。

303 :デフォルトの名無しさん:03/05/26 05:25
結局この形が美しいと俺は思う
ttp://www.atmarkit.co.jp/fjava/rensai/smartj01/fig1.gif

304 :デフォルトの名無しさん:03/05/26 05:35
>>303
2年前くらいに騒がれてたね。シンプルだから俺も綺麗だと思う。
Javaを始めたばかりの人が突然EJBのシステム保守したらどうなることやら・・。


305 :デフォルトの名無しさん:03/05/26 05:38
J2EE、各レイヤの役割とかまでは理解が容易だけど実装しようとしたら、ちとキツイ。
漏れ理解力足りないから、理解できたころには陳腐化してるんだろーなー。。。。

306 :デフォルトの名無しさん:03/05/26 05:46
>>304
2年前ですか
おれ、昔から今でもこのやり方マンセーで使いまくってますよ
もう古いんでしょうか?トホホ
でも、ほんとに綺麗なのでStrutsを使う意味がわからない
もちろんValidateなどは使うけど


307 :デフォルトの名無しさん:03/05/26 05:49
この間、試しにSunのj2eesdkつかったけど
Deploytool使えばDD書かなくていいんだね
マジびっくりしたよ
WeblogicとかWebsphとかもそうなのかな?つかったことないでわからんけど

308 :デフォルトの名無しさん:03/05/26 21:23
>>298
本当にそんなこと実際のプロジェクトでできると思ってんの?

309 :デフォルトの名無しさん:03/05/26 22:36
>>298
おまえ学生だろ?なあ学生だろ?学生だと言え。
学生の身分で安易な発言してすんまそんでした。と言え。

310 :デフォルトの名無しさん:03/05/26 23:12
学生の身分で安易な発言してすんまそんですた。と言いますた。
何かくれ。

311 :デフォルトの名無しさん:03/05/26 23:58
>>307
市販のJ2EEアプリケーションサーバではふつう。

312 :デフォルトの名無しさん:03/05/27 22:44
>>298
J2EE BluePrints には J2EE開発のロールが色々と挙げられている。
しかし結局、1人くらいしかいない super な開発者がほとんどの面倒を見る状況になってしまう。

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

313 :デフォルトの名無しさん:03/05/27 22:57
BMPとCMPを使い分けている方居ますか?
使い分けている方に質問です。

1.使い分ける基準って言うのはあるのでしょうか?
2.CMPは基本的に1テーブル=1エンティティBeanにしかできないのでしょうか?


314 :山崎渉:03/05/28 12:35
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

315 :デフォルトの名無しさん:03/05/28 17:57
>>313
1.使い分ける基準って言うのはあるのでしょうか?

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

2.CMPは基本的に1テーブル=1エンティティBeanにしかできないのでしょうか?

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




316 :デフォルトの名無しさん:03/05/28 23:35
>>315
>CMPでは実現できないEntityBeanを実装する時
具体的にはなんですか?



317 :デフォルトの名無しさん:03/05/29 02:04
>>316

315じゃないけど。

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

318 :デフォルトの名無しさん:03/05/29 03:43
deployがわからん
ベンダーごとにばらばら。
統一せんかい

319 :デフォルトの名無しさん:03/05/29 05:23
>>318
たしかに
禿同だ

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

320 :デフォルトの名無しさん:03/05/29 22:24
>>317
それはまだCMRがないときの話でしょ。
いまはCMRができたから、それは関係ないよ。
むしろ、BMPの方がめんどくさいくらいなんじゃない?

321 :317:03/05/29 23:25
>>319

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

>>320

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

322 :デフォルトの名無しさん:03/05/29 23:34
> CMRはRDBに限定されているような気がするのですが、そのあたり
> 詳しい人いるでしょうか

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


323 :316:03/05/29 23:59
>>315 >>321
知りたいのはRDBを使った時に、
CMPとBMPをどのように使い分けるべきかなのです。

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

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

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

324 :デフォルトの名無しさん:03/05/30 01:54
ビューにEntityBeanを対応させれば、CMPでもいいんじゃないの?

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



325 :デフォルトの名無しさん:03/05/30 03:34
>>324
結局BMPとCMPの使い分けは好みによるってことですかねぇ。

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



326 :デフォルトの名無しさん:03/05/31 13:32
age

327 :デフォルトの名無しさん:03/06/01 21:43
>>315さんの言っていた
「>CMPでは実現できないEntityBeanを実装する時 」は具体的に何を指しているのですか?


328 :デフォルトの名無しさん:03/06/01 23:59
おまえらEJBやるよりJavaの真髄を押えておいた方がいいよ?

329 :デフォルトの名無しさん:03/06/02 00:14
>>328
Javaの真髄?なんのこと?
理由もなく意味のない書込みは止めてください。
「いいよ?」の意味もわからないし。


330 :デフォルトの名無しさん:03/06/02 00:17
>>329は「EJBやったことある」と言いたいだけ。Javaなんてこれっぽっちも解っちゃいない。

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

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

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

332 :デフォルトの名無しさん:03/06/02 00:42
>>330
>>329の書込みから、どうやったら「EJBやったことある」と読めるの?
深読みしすぎなんじゃないの?


333 :デフォルトの名無しさん:03/06/02 00:57
>>332
読めるんじゃない。事実は隠せないだろ?プ
EJBやったことあるってことは自分自身が一番知ってるはずなんじゃない?w


334 :デフォルトの名無しさん:03/06/02 01:46
>>333
話にならんなぁ。プ、とかwとか言ってるところが寒いし。
まあ、くだらないしめんどくさいからもういいや。

335 :山崎 渉:03/07/15 15:22

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

336 :山崎 渉:03/08/02 02:40
(^^)

337 :山崎 渉:03/08/15 17:23
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

99 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)