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
(^^)

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

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

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