ＥＪＢの真相

Enterprise JavaBeans（ＥＪＢ）について情報ください。

雑誌等での取り上げられ方（利用推進傾向）と
実際に利用したことある者（巨大プロジェクトのみ利用推奨）の意見に
食い違いがあり、ＥＪＢの真相を捉えられない状況だ。

ＥＪＢ利用によって成功したプロジェクト・失敗したプロジェクト等を
教えて貰い、真相究明と行きたい。
実際はどうなの？

>>1
ズザー

4層以上のC/Sなんて、技術者のオナニーでしかないでしょ。

オナニースレ

EJBを使うという感覚よりはAPサーバのツールを使うという感覚だよなあ。

>>3
いやマジで 4 階層くらいにしなきゃ収拾つかんシステムもあるよ。
ﾏﾝｾｰじゃないけど。

アプリ鯖の、標準規格

しゃなくて、分散トランザクション鯖の拡販と、ＲＤＢ負け組の敗者復活戦が狙い

>>1
おまえは何が知りたい？
実際に利用した者が巨大プロジェクトのみ利用推奨と言ってるんだから
そういうことにしとけよ。安易に雑誌は信じるなボケ。
中小規模のサービスでEJBを使用せにゃならん理由なんてねぇだろ。
EJBコンテナ自体のコスト、人員（スキル）、開発難易度、中小規模の
プロジェクトにゃとてもじゃないが採用できんよ。
だいたいコンポーネントとしての再利用つっても、個別案件に対する
カスタマイズの手間は避けられないじゃない？
新規でも既存のソースの修正でもコンポーネントのカスタマイズでも、
中小規模のシステムならたいして手間はかわらんて。

雑誌は業界の営業活動をやりやすくするためのもん
ＯＯで、とか、ＥＪＢで、とか、コンポーネントで
とかいう言葉だけでだまされる馬鹿なお客をつくるための記事だよ

J2EEをHotSpot Clientで動かすアフォは氏んでください

>>11
ダメなの？サーバはどうせメモリ沢山乗っけてるんだろうから、
最新のHPClientVMが一番速いんじゃないの？
それとも、HotSpot技術のバグの話？

実際のところどっちが速いんだろう

>>11
もしかしてIBMのClassicVM使えっていう話け？

最新版のVMは-serverの方が速い。(GUI除く)

おちがないぞ

実際誰も使ってないから判断のしようがない。

>>15
http://pc.2ch.net/test/read.cgi/tech/1012728608/253

>>17
昨晩困ってたんですが、

ＥＪＢ使って成功したプロジェクトって無いの？

成功って何だよ。
EJB で動いているシステムならいくらでもあるぞ。

>20
うそをつけ。いくらもないね。J2EEとかいって、ServletとJSPしか使ってないだろうが。白状しろ。

>>21
ｾｼｮｰﾝBeanはけっこう使ってるよん。
でもｴﾝﾃｨﾃｨBeanはほとんど使わない．．．。
CMPなどもってのほか．．．。(;´Д`)

いくらは言い過ぎたかも。俺が知ってるだけで銀行 2 社。商社4 (6?) 社
ある。いずれも Web サービスのバック用で。

セッションBeanはパフォーマンスのペナルティがあると聞きましたが、本当ですか？

>>22
そういう形態でのＥＪＢを使ったメリットとは何ですか？
ＥＪＢである必要が余り感じられないんだが。

>>24
SessionBeanでパフォーマンスはそれほど問題にはならないのでは？
パフォーマンスでダメなのはｴﾝﾁﾁBean。

>>25
EJBを使ってみたかっただけと（以下略 ってのもｶﾅｰﾘあるけど、
アクセスコントロールを再発明せずに済んでよかった部分もあるよん。

おまえ１人が使いこなせても他が使いこなせれば意味がない
そしてだれが買うんだ。APPSERVER？
いくらするとおもってんだ

>>28
それはタダ

>>28
今どきEJBぐらい使えて当然だと思うが。

と煽ってみる。

巨大って、どれくらいなの？

オレのは最大で27cmになるけど巨大かな?

>>32
ともっちにたべさせやれ。

２８＞＞ばか？
WEBSPHEREいくらするか知ってるの？
おまえの言ってるのはJEEのおまけサーバだろ

jboss・・・

>>34は>>29宛てではないようだ。

Linuxでjboss動かしてんだけど、
バックグラウンドで動いているjbossを停止させるには、
今のところ関連するプロセスを一つづつ潰してくしかないですか？

J２EEのおまけサーバのようにコマンドラインオプションで
停止させるようなことはできないですよね？

自分でスクリプトなり書くか...

HPのアプリケーションサーバ、無料になったじゃん。

ホント？

無料になってからもうすぐ3ヶ月になりますよ
http://www.jpn.hp.com/software/hp-as/down/index.html

英語よめない
だれが使いこなせる？

無料にしなきゃ誰も使ってくれないもんな、J2EE。。。。（ｗ

俺のやってる規模だと使ってもStrutsかCocoonですねえ。
自慢にならんが。

Strutsはフレームワーク？
サーバじゃないような

あーサーバじゃないです。EJBと縁がないと言いたかっただけ。

で、オレの27cmは巨大なのか?

27cmの足なんていくらでもいるぞ

>>48
チンコが27cmなんですが・・・

>>49
オレのは30cmあるけど、巨大かな?

おれは鼻はデカイんだけど10cm、、、泣
手もデカいんだけどあんま関係ないみたい。

オレのはサイズそんなに大きくはないが、黒くて立派です。

黒くて立派で未使用です

ボクのは黒くはないです。
どちらかといえば白いですが、立派だと思います。

　　　　　　　　∩
　＼　　　　　 (　)　　　　　　　　 　 　 　 　 ∩　　　　　　　　 ／
　　 　 　 　 　 | |　　　　　　　　　　 　 　 (ヨ　）
　　　　　(　｀Д)|　　　　　　　　　　　　　　　＼ (Д´　)
　　　　　/⌒ 　 |　 　 ＼ 　 男祭り　　／　　 (　　⌒ヽ
＿　 　 <　く＼　＼　　　＼　　　　　／　　　　ﾉ　).ﾉ＼＼＿__
　　　　　＼( ﾖ　､ つ　　　　　　　　　　　　　⊂　　）　　＼ 　 ）　─
　　　　　　 ／ ／/　　　　 ヽ(`Д´)ﾉ　　　　　ω　＼　 　 ￣
　　　　　／ ／ ./　　　　　　 ( ∩ )　　　　　　　ヽ＼ ＼
　／　　（　￣） ￣）.　　　　 ／ω＼　　　　　（￣（￣　 ）　　＼

ひだりのやつがいちばんグレートだ・・・
微妙に反ってるし

漏れの物は良い物だって、爺ちゃん言われてたけど、
あんまり使ってないんだよ。

真中のモナーが最高だな

モナーじゃねーな

２７cmや３０cmのチンコではＥＪＢは必要なし。
ちんちんがズボンからはみ出して、
ネクタイになる場合にのみ使用すること。

>60
ﾜﾗﾀ

>>31
俺も大規模プロジェクトがどれくらいな規模を言うのか良く分らないが
「アプリケーションサーバーをクラスタリングして使用しないといけないような
規模」を指すらしい。曖昧でｽﾏｿ。
「巨大」はちょっと大袈裟だったかも。

とりあえず、チンコの大きさではない。

> アプリケーションサーバーをクラスタリング
あー、だいたいイメージわきました。どうもです。

>>1は巨根ではないということですか。

>>1 は粗珍ってことさ。

>>1は童貞ですか。

>>1のティムポは黒くはないな。

オレのはビンビンだよ。

メリット

* サーバが落ちても復旧を可能にする機能がついている
* アプリケーションサーバ側に負荷分散機能があれば、それをノーリスクで（プログラミングの中で意識することなく）使える
* 一つのパッケージにするので分かりやすい

開発もそんなに難しくないしね。
ある程度は単なる Singleton オブジェクトとして、開発終盤でEJBに
マッピングすることもそんなに難しくない。XPでいうところのインフラ
の問題も解決しやすいと思う。

>>69
こういうメリットって実際に使用した人じゃないと聞けない意見だね。ｱﾘｶﾞﾄ。
デメリットは何ですか？

>>70

意味もなく使いたがる人が多いことかな・・・。
単純なケースでわざわざ EJB 作るのはムダだと思うよ。
スクリプト言語で十分。

「まず最初に EJB 環境整えなきゃ・・・」といって、延々と EJB 環境、
XML 環境つくっちゃって、インフラの問題を引き起こす。

（技術者にプライオリティを渡したら最期、止まらないから・・・）

Java を使うほど複雑なケースでも、最初から EJB 環境を作る必要も
無いはずで、簡単なオブジェクトを作るところからスタートすればいいのに。

あーだこーだど技術的なところに萌えてしまわないように注意することが大事。

>>71
痛いよ。

耳が。

>>72

書いているボクも耳痛いですがね。（そりゃ新しい技術使いたいし、
もしいいっていうなら Ruby 使いたい！）

実体験でも、XP本とか読んでても、どんなことでもプライオリティは
顧客に決めてもらうのがベストだと思うよ。

おそらくEJBつかうメリットは
（１）規模が大きい（ECサイト）
（２）複雑なトランザクションがある
などが考えられるが

他にある？

>>74
(3)包茎でも使える。

>（１）規模が大きい（ECサイト）
>（２）複雑なトランザクションがある

この二つとも意味が分かんない。具体的にはどういうこと？

規模が大きいとは?
アイテム数が多い・同時処理数が多い

ちんぽが大きい。

あーーーーーーーーーーーーーーーーーーーーーーーーーーー
あーーーーーーーーーーーーーーーーーーーー
あーーーーーーーーー
あーー

77>>掲示板など作るのにEJBは大げさということで

EC サイトだの、トランザクションだの、わけわかんない言葉つかわないで
欲しいな、、、。

要するににネットショップだろ。

複雑なトランザクションとかいって、要するにリモートオブジェクトが使えて、
その間でのメッセージのやりとりの方法が決められているってこった。

そんなのは別に、EJB が優れているポイントでも何でもないと思うんだけど。

トランザクションを知らんのか…

ネットショップって言葉あまり聞かないけどな。 (w

トランザクションに関しての知識・理解が無いのね・・・

大規模 ≒ 社会的重要度が高い ≒ お金いっぱいかかる ≒ (負荷が大きい + フルタイムで稼働)

みたいなのがEJB向けなのかな。

負荷が高いなら、なおさらEJBを使わずに軽くすべきだと思うが･･･

>>85
いいこと言った。

つまりEJBは使い道がないと

負荷が大きいから EJB 使わなくても専用鯖や負荷分散が必要になってくる
システムという意味だろ。負荷の度合いが違うよ。

トランザクション管理を隠蔽されたレベルでやってくれるところに意味があるわけで、トランザクションを知らないといっている人には、逆にお勧めだと思うけど。
フリーのAppServerを使って、納品した人いる？

tomacat+postgresqlまでだな。
jbossはちょっと怖い。

トランザクションを知らずに EJB 使いこなせるか?
まぁコーダーレベルという話だろうが、ｱﾌｫな SE が鵜呑みにすると
いけないので一応ツッコミ。

EJBだと負荷が増えてきてからボトルネックになってるBeanを別マシンに移動とか
複数台に分けて分散とかしても、EJBコンテナまかせでいーから楽チン。



ってくらいの感触だが、実際に運用するとどーなんだろ？

J2EE付属の鯖(j2ee)って運用に使えないの？

>>93
J2SDKEEの鯖は、負荷分散機構が付いていないし、
速度や負荷のチューニングもなされていないと思う。

>>94
アリガ�d。

だから、各メーカーがこぞってAppServer作ってるのね。

J2EEのツールって使いこなせても実戦であまり役に立たないよなあ･･･

Jakarta って EJB 対応アプリケーションサーバ作らないのかな…

>>95
だからAppServerベンダーはEJBマンセーとなる。
この辺りが現場としては困りもの。

んで、TOMCATが増殖する、と。
オープンソースﾏﾝｾｰって事で。

ECサイトって言葉も知らんのね・・・
ネットショップって言葉ははじめて聞いた。

んー、「平たく言えよしゃらくせぇ」っていうんなら、まぁ理解はできる。共感はしないけど。
でも、「トランザクション？ECサイト？ ハァ？」 ってんならちょっと痛いかな。

>>100-101
(´-`).｡ｏＯ（まだ彼はこのスレに潜んでるのかな・・・）

>>94
最近の賢い負荷分散装置は、ユーザーコネクションの維持（最初に
接続したサーバに振り分けてくれるってことね）も してくれる。
だもんで、EJBを使用すると言われる規模のプロジェクトでも、
EJBを使う必然性が無くなってしまうのではないかな。

>>103
ビジネスロジックを全てのサーバーに実装するってこと？
それで何か問題あったりしないのかな？
あと、その賢い負荷分散装置は各サーバーの状態をどんな風に
監視してるんだろ。

負荷分散装置＝レイヤー４スイッチ のことね。
CookieとかURL中の、パラメータの値を使って、セッションを識別して、同じサーバに処理を割り振るらしいよ。

サーバの負荷状態取得方法については、なんかRFCにも出てるみたいですけど、どうなんでしょね>>設定担当されてる方

>>100
そっかもねー。ご自身で必要性をご検討された上で、必要ないとおっしゃるのなら、
貴方の御用途では要らないのでしょうねー。

↑>>100 でなくて >>103 の間違い

>>104
＞ビジネスロジックを全てのサーバーに実装するってこと？
そうなりますね。
1台で動かしていたAppサーバを単純に複数台用意して、作成したプロ
グラム全部を単純にコピーして、DB接続数を単純に頭割りにして、管理を
その負荷分散装置にお任せするって感じですかね。
115氏が説明してくださっていますが 負荷は、装置内で管理している
各サーバのセッション数 や、ハートビートにより取得した各サーバの
負荷率 が元になっていると説明を受けました。
もちろん、この装置に頼れるかは用途や規模によるわけですが、以前は
数台のAppサーバを立てるだけでもセッション管理用のバックエンドを
用意する必要があったわけで。で、ハードにより解決できるのであれば、
AppSvrSoftware, プログラマ とも要求使用を下げることができるわけで。

本当に必要なプロジェクトでは使い続けられるのでしょうが、以前ほどは
選択されないのではないかと思います。＞ EJB

>>107
セッション間の状態が独立してるようなアプリケーションなら
いけるかもね。他の状態に依存してるような場合は依然として
EJBだとも言えるけど。

>>107
たしかに、javax.servlet.http.HttpSession で対処できないものは
EJBで対応することになりますね。

> たしかに、javax.servlet.http.HttpSession で対処できないもの

例えば、どういうもの？

> 例えば、どういうもの？

自分では、よく判らないのですが……。
108氏には自信がありそうでしたので、謙虚に答えてみました。
間違っても、皮肉や当て擦りだとは解釈しないでくださいね。

EJBつかうと、
OOが活きるんだよね。

EJBつかうと、
チンコがイキルンダヨネ。

>>107
EJB使う使わないに関わらずサーバが複数あるときはスティッキーロードバランシングが主流なんですかねえ。
スティッキー使わないとするとcookieかhiddenかDBか…

商用APサーバ買う人の大半はDBコネクションプーリングだけが目当てだったりして。
DBコネクションプーリングなんて簡単に実装できるのに。
なんならオラクルのJDBCドライバのOracleConnectionCacheImplクラス使うとか。

ベタだがiPlanetWebServer(Sun＋Netscape)＋Oracleがベストチョイスなのでは？
iPlanetWebServer(iWS)てのはtomcatに仮想ホストとフェールオーバーと認証用
LDAPサーバー接続機能がついたような代物だが。

>>114
コネクションプーリングって、コネクションインスタンスを
起動時に一定数作っておいて使いまわすってこと？

そんなのだけのために数百万も払う馬鹿がいるの？すごい、馬鹿だ。

バカにはそれ以外の機能は使えない

さらにフレームワークは「JATO」で。
２ｃｈ的には萌えないかも知れんが。

>>115
まぁ、貧乏人に莫迦な選択肢はできないってこと。数百万の裏にあるものが
見えないなら仕事やめたら？

とりあえずage

>>118
ごめん、言ってることがさっぱり分からない。

>>120
うん、>>118 は >>114-116 の流れが読めないおば加算。
徹夜明けのオネボーさんかな？
>>115 が言っているのは「もっと他の機能もあるのにつかわないのはﾊﾞｶだ」でしょ