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がやっとでたね。
■ このスレッドは過去ログ倉庫に格納されています