03/02/17 00:55
∧＿∧
（ ´∀｀）＜ ぬるぽ
25:デフォルトの名無しさん
03/02/17 00:58
>>24
∧＿∧
（ ´∀｀）＜ ぬるぽぬるぽってうるせぇんだよ。
26:デフォルトの名無しさん
03/02/17 01:02
>>23
それは
URLﾘﾝｸ(www.mamezou.net)
のコピペっぽい。
27:デフォルトの名無しさん
03/02/17 01:04
>>23
CORBAが入ってないのが気になる
28:デフォルトの名無しさん
03/02/17 01:07
>>26
コピペって書いてあるが・・・
29:デフォルトの名無しさん
03/02/17 01:24
>>28 わかってるっ!
30:デフォルトの名無しさん
03/02/17 01:52
>>17
大規模システムには下記のような機能が求められます。
（もっとあるかもしれないけど）
■スケーラビリティ
■高可用性
■高信頼性
.NETはあまり知らないけど、J2EE準拠で作れば、上記は満足するのではないですかいのう。
31:デフォルトの名無しさん
03/02/17 02:03
>>30
アプリケーションサーバにバグが無ければね。
32:デフォルトの名無しさん
03/02/17 02:10
>>27
この際ＣＯＲＢＡは関係ないでしょ。
>>23
COM+とEJBが対応する技術って言うのは疑問ですな。
33:デフォルトの名無しさん
03/02/17 02:20
あとASPとServletが対応するのもちと怖い。
気をつけないとスパゲッティになるんじゃないの？
34:デフォルトの名無しさん
03/02/17 02:24
ObjectSpacesって、Javaのどのテクノロジと対応するんだろう……？
35:デフォルトの名無しさん
03/02/17 02:38
JDO
36:デフォルトの名無しさん
03/02/17 19:28
.NetにはJ2EEのMVCアーキテクチャのようなものがあるのですか?
37:デフォルトの名無しさん
03/02/17 19:48
J2EEネタを振るのはまずい
38:デフォルトの名無しさん
03/02/17 20:55
>>NetにはJ2EEのMVCアーキテクチャのようなものがあるのですか?
ありません。詳しくはＮＥＴ版ＰＥＴＳＨＯＰをみてくれ
39:デフォルトの名無しさん
03/02/17 21:46
>>37
２ｃｈってj2eeネタはウケが悪いけどどうしてよ？
40:デフォルトの名無しさん
03/02/17 21:49
MVCも可能だが、.NET版で使ったデザイン パターンのほうが優れているし
パフォーマンスも良いと。
URLﾘﾝｸ(www.microsoft.com)
41:デフォルトの名無しさん
03/02/17 22:40
>>40
と、ゲイツたんは主張しております
42:デフォルトの名無しさん
03/02/17 23:18
>>39
単なるアホアンチがJ2EEを妬んでいるだけ。
ま、ほっとけ。
このスレはJ2EEと.NetのスレなんだしJ2EEの話しないとね。
43:デフォルトの名無しさん
03/02/17 23:30
>>39
J2EEネタまじでわからん厨が嫌がってるだけだよ。
他のスレ見りゃ、J2EEの話題なんて普通に流れてるよ。
44:デフォルトの名無しさん
03/02/17 23:46
プロフェッショナルEJBって本どうよ？
45:デフォルトの名無しさん
03/02/18 00:43
>>40
拡張性を大幅削減し、JavaPetstoreよりソース量が１／６に縮小。
ストアドプロシジャを使ってパフォーマンスの向上。
.NET版PetShopにはＭＳの必死さが伝わってくるよ。
>>36
MVCモデルに近いものとしては、「ASP.NET Web Solution Guide
～ Multi UI Web Application 編」ってのが、参考になるんだが、
View部分の充実さと比べると、コントローラ部分が余りにも貧弱。
まだまだこれからの技術といった感は拭えない
46:デフォルトの名無しさん
03/02/18 00:45
>>45後半
MVCじゃなくDocumentView の会社だからじゃないですか？
47:デフォルトの名無しさん
03/02/18 00:46
>>44
赤いやつね。
いいよ。コードが満載で具体的だが、ちゃんと網羅すべき点は抑えてある。
48:デフォルトの名無しさん
03/02/18 00:47
>>44 最近出た本だよね。これからJava厨目指す人にはいい本なんじゃないかな。
＃読んだ方の御意見ぷりーず
49:デフォルトの名無しさん
03/02/18 01:45
Servlet、JSP、Axisはちょっとは理解したつもりだが
EJBって何なのか、マジわからん。これは何？
昔.NET vs EJBとかいう記事よく見かけたから
てっきりEJBがJavaのWEBサービス技術だと勘違いしたよ
EJBって何？何のやくにたつの？
やたら難しいが・・
50:デフォルトの名無しさん
03/02/18 01:53
>>49
よく言われてるのは、
トランザクション管理とリモート呼び出しが自動化
（ＥＪＢコンテナがやってくれる）されることだと思う。
逆にこれを使わないとほとんどメリットは無い。
コンポーネント化がうんぬんとか言ってるけど。
実際できんの？って感じです。
実際ＥＪＢを使うのは壁が高すぎるし、めんどくさい。
素直にServlet＋JDBCで十分な気がする。
参照系じゃメモリばっか食って使えないと言う話。
あ、MDBはまたちょっと違うけど。
51:デフォルトの名無しさん
03/02/18 02:18
ふーん。。EJBってのやっぱりservletの拡張技術って感じと捕らえていいんですかね？
WEBサービスとは何の関係もないですよね？
52:デフォルトの名無しさん
03/02/18 02:24
>>50
実際に使ったことないからそういうこと言っているんだね。
参照系といっても、データベースの中身を全部持ってくる訳
じゃないんだから、メモリなんて問題になることはそれほど
無い。
むしろ、CPUの方が問題が出てくる。
トランザクションの管理を自動化できるということだけでも
導入する価値はあると思うのだが。
53:デフォルトの名無しさん
03/02/18 02:35
COM+で何年も前から実現してたことだね。(ﾌﾟ
54:デフォルトの名無しさん
03/02/18 02:48
>>53
使われなければ意味が無い。
55:デフォルトの名無しさん
03/02/18 02:52
>>51
ServletとEJBはまた別もんだよ。
Webサービスとは直接関係ないと思う。
WEBサービスはSLSBで実装するらしいと言う話も聞いたことあるけど。
>>52
ごめん。メモリを食うのはEntityBeanの話。
１万件のデータを持ってくるとしたら１万件のEntityBeanインスタンスが
必要になるでしょ。ここまで来るとメモリは無視できないと思うよ。
参照系だけならSLSB＋JDBCで十分でしょう。
完全な最新データが必要って言うなら話は別かもしれないけど。
なんかスレ違いになってきた気もしますが・・・
56:デフォルトの名無しさん
03/02/18 02:53
COM+のトランザクション・マネージャって、何を使ってるのだろう。
あと、COM+のトランザクション機能って、EJBと同時代の技術じゃなかっただろうか。
57:デフォルトの名無しさん
03/02/18 03:24
だいたいXML WEBサービスって言う名前がｶｺ悪い。
58:デフォルトの名無しさん
03/02/18 03:26
XML WEBサービスという名前がｶｺわるい
59:デフォルトの名無しさん
03/02/18 07:54
やっぱ、ＥＪＢだろ！？
60:デフォルトの名無しさん
03/02/18 14:32
EJBはソース内に直接SELECT文を無駄に書かなくても良いというのが利点ですね。
61:デフォルトの名無しさん
03/02/18 15:18
ボーランドが.NETプログラムでEJBを使えるようにするらしいよ。
62:デフォルトの名無しさん
03/02/18 23:26
ＥＪＢつーかアプ鯖重過ぎ。
63:デフォルトの名無しさん
03/02/19 01:06
結局ＷＥＢサービスって、
Ｍ＄が参加したＣＯＲＢＡ見たいなもんだと思ってよろしいか？
64:デフォルトの名無しさん
03/02/19 01:10
>>55
>ごめん。メモリを食うのはEntityBeanの話。
>１万件のデータを持ってくるとしたら１万件のEntityBeanインスタンスが
>必要になるでしょ。
うそつけ。バカ
65:デフォルトの名無しさん
03/02/19 01:14
>>64
>>55は効率の悪いプログラミングをしていると言うことでよろしいか?
66:デフォルトの名無しさん
03/02/19 01:20
>>65
オブジェクトリファレンスとBeanインスタンスはちがう
67:デフォルトの名無しさん
03/02/19 01:22
>>64、65
効率悪いも何もEntityBeanはそういうもんだっぺ。
１レコード＝EntityBean１インスタンスに対応するんだったら
１万件HITするFinderメソッド切ったらそのとおりじゃん！
selectメソッドつっても結局複数Columnのデータが必要なら、
結局EntityBeanインスタンスが必要になるんじゃないの？
68:デフォルトの名無しさん
03/02/19 01:27
糞アーキテクチャの見本だな。MSはそんな糞の真似しないよ。
69:デフォルトの名無しさん
03/02/19 01:32
1レコード=EntityBean1インスタンスにするのは、EJB初心者向け
実装指導の時だけですが…
70:デフォルトの名無しさん
03/02/19 01:37
>>69
EntityBeanって「1レコード=EntityBean1インスタンス」なんじゃないの？
それ以外に作れんの？
71:デフォルトの名無しさん
03/02/19 01:38
JNDIってなんなの？
72:デフォルトの名無しさん
03/02/19 01:43
>>71
登録対象が何でもありのDNSみたいなもん。
73:デフォルトの名無しさん
03/02/19 01:45
大規模だと.NET使えない理由を分かりやすく教えれ。
>>71
LDAP
74:デフォルトの名無しさん
03/02/19 01:47
>>70
CMP2.0 CMR。
75:デフォルトの名無しさん
03/02/19 01:48
>>73
64bit版CLRがないから。
76:デフォルトの名無しさん
03/02/19 01:49
>>74
それでも結局インスタンスつくるんじゃないの？
77:デフォルトの名無しさん
03/02/19 01:49
>>73
NTServerしか使えない。.NETよりもNTServerに問題あり。
78:デフォルトの名無しさん
03/02/19 01:55
Solaris版は無理だとしても、HP-UX版のCLRってでないんかな？
79:デフォルトの名無しさん
03/02/19 01:58
SourceForgeでプロジェクトでもあげますか。
Solaris版CLR、Linux版CLR、HP-UX版CLR(できたらSDKも)開発。
80:デフォルトの名無しさん
03/02/19 02:01
>>79
もう MONO ってプロジェクトがあるって。
といっても途中でさじを投げて Wine っつー Win エミュ使うことになった
らしいが。
81:デフォルトの名無しさん
03/02/19 02:03
>>80
Blackdownのようにはいきませんか。(あれはあれで不幸でしたが)
MSの仕様が不透明だからですかねえ…
82:デフォルトの名無しさん
03/02/19 02:13
>>70
結局「１レコード＝１EntityBeanインスタンス」で良いか？
83:デフォルトの名無しさん
03/02/19 02:16
>>81
コアライブラリの中で Win の API を直接呼んでたらしい
84:デフォルトの名無しさん
03/02/19 02:16
>>82
PK1つで取ってくるデータの固まり全て＝1レコードということなら、
そうかねえ。
85:デフォルトの名無しさん
03/02/19 02:20
>>83
ﾜﾗﾀ。
さすがMS。Operaの件といい、思想の変化が全くないですね。
86:デフォルトの名無しさん
03/02/19 02:36
>>84
ＰＫ１つでとってくるデータの塊って何？
テーブルＡとテーブルＢが１対他の関係だとして、
テーブルＡの１レコード＋テーブルＢの対応する外部キーのＮレコード取得している状態？
テーブルＡ、Ｂに対してEntityBeanをマッピングしたら
インスタンス数 ＝
テーブルＡに対応しているEntityBeanインスタンス×１
テーブルＢに対応しているEntityBeanインスタンス×Ｎ
でしょ。
塊すべて１レコードとは違うでしょ？
結局「１レコード＝１EntityBeanインスタンス」では無いの？
87:デフォルトの名無しさん
03/02/19 02:38
間違えた
１対他 → １対Ｎ
です。
88:デフォルトの名無しさん
03/02/19 02:44
>>86
どちらの実装も可能なのではないのかね。
89:デフォルトの名無しさん
03/02/19 02:45
>>67-68
効率よくする方法自分で考えて自作しろよ。
ある情報、検索するにあたって検索エンジンで1万件ヒットすることがわかっていたとして
検索を1万件のデータをその場ですべてアップロードするような馬鹿な設計をするか?
Googleでも検索結果が10000件になったとしてもそれらすべてを
一つのページに表示するという馬鹿なことをするか?
１0～100件程度ずつ表示するだろ。
自動絞込み検索アルゴリズムを作ってBeanを分割統治することくらい考えろよ。
それにこの情報がもし画像だとしたらその実体をいちいちBeanの中にいれるアフォなことするか?
参照だけを入れて容量を節約するだろ。
それに一度取り出したBeanをブラウザに表示させるときも、
表示しない部分のBeanはいつまでもメモリ上に保持するなんて馬鹿なことするか?
使わなくなったオブジェクトにはnullを入れるか破棄するのが常識だろ。
それでも足りないなら圧縮できるなら圧縮し直列化して一時保存かさらにDBに保存するとかView表を作るとか考えろよ。
>>68もAPIのせいにしないでアルゴリズムと設計方法を考え直すくらいのことしろよ。
90:デフォルトの名無しさん
03/02/19 02:48
>>88
どちらの実装もってどれとどれを指してるですか？
スマソ。
結局おいらが言いたいことは
どう実装しようがEntityBean使ったら、
「１レコード＝１EntityBeanインスタンス」になるでしょということです。
なんか思いっきりすれ違いでうざいかな？
91:デフォルトの名無しさん
03/02/19 02:48
>>89
設計知らない派遣コーダーにそんな話しても無駄
92:90
03/02/19 02:51
>>89
言ってることはごもっともだけど、
おいらが言いたいことは設計うんぬんの話ではなくて
EntityBean使ったら、 取得したレコード分「EntityBeanインスタンス」が作られるっちゅー話です。
分かりづらくて申し訳ない。
93:デフォルトの名無しさん
03/02/19 03:06
>>89
結局はEntityBeanは大量なデータを扱うのには不向きであるという
ことだ。
EJBのもともとの発想はパフォーマンスよりも、いかに分かり易い
プログラムにするかということだから仕方ない。
94:デフォルトの名無しさん
03/02/19 03:06
思いっきりスレが伸びてると思ったら・・・
>>90 質問の続きは、「EJB(初心者歓迎)」でどうぞ
ｽﾚﾘﾝｸ(tech板)
95:デフォルトの名無しさん
03/02/19 03:11
>>93
おい、それで>>89の言いたいことを理解したつもりか?
EntityBeanが大量のデータを扱うには不向きだからといってEJB
を否定するか?
効率的なクエリーの設計にも気を配らない香具師には向いていないだろう。
一つのインスタンスを複数のインスタンスに分割統治する方法も知らないか、使わない者にも不向きだろうな。
96:デフォルトの名無しさん
03/02/19 03:11
あるところでは有名な丸山某教授のセミナー資料に
「J2EEはプラットフォームを選ばない → でも(開発)言語はJava」
「.NETは(開発)言語を選ばない → でもOSはWindows」
とあった。
結構本質ついた説明かも。
97:デフォルトの名無しさん
03/02/19 03:21
.NETは言語もプラットフォームも選びません。
98:93
03/02/19 03:22
>>95
否定はしていないよ。
ただ、向き不向きがあるということだ。
その言語の長所を理解して使っていこうということだよ。
99:デフォルトの名無しさん
03/02/19 03:25
>>67
最低線で
「1レコード＝１ValueObject」 (EntityBeanでなく単なるオブジェクト)
ちょっと工夫すると
「Nレコード＝1ValuesObject」
100:デフォルトの名無しさん
03/02/19 03:25
>>95
世の中には、リモートのEJBの1属性のget/setを鬼のように呼びまくって
挙句の果てに遅いのをAPｻﾊﾞのせいにするアホが大勢いますからねえ･･･
ええ、うちの会社にもいますよ…
そんでもって、J2EEもどきを自分で作ってますよ…
もうアホかと、馬鹿かと(以下略
101:デフォルトの名無しさん
03/02/19 03:26
たとえばCMP Beanとか使ったら間違いなく
問い合わせの結果セットの１レコード = Beanの1インスタンス
になっちゃいます。
イメージ的にバックエンドのDBのサブセット的な
「データベース」になります。だからLOBデータなんて
持たせたら大変です。
まあEntityBeanを使うだけがEJBじゃないんで、
別にSessionBeanからJDBC生で実行したって
かまわないですし。性能用件が重要であれば、
そのような開発も選択すべき。
イメージ的にEntityBeanならOLTPぽいもの、
意思決定支援やらBI/DWHやらバッチ的なこと
するならJDBCゴリゴリ、ビジネスロジックだけ
SessionBeanみたいな「いまのところはそういう選択」
になるかな。
ただ、このあとどのような新仕様がJ2EE/EJBに
出現するかどうかだけど。
102:デフォルトの名無しさん
03/02/19 03:29
> 97
M$がWin以外のサーバプラットフォームと開発環境一式を
リファレンス実装でもいいから提供するなら信用しますが？
103:デフォルトの名無しさん
03/02/19 03:29
まあ、>>67は「J2EEパターン」でも読みなさい、ってこった。
104:デフォルトの名無しさん
03/02/19 03:30
>>101
ただのJavaクラスのこと、Beanて呼んでる？
ならおっけ。
あと、View + Stored Procedure + JDBC バリバリの開発は、あんま興味ないな(単なる本音
105:デフォルトの名無しさん
03/02/19 03:31
>>97
> .NETは言語もプラットフォームも選びません。
うそつけｳﾞｫｹﾅｽが。
Javaですら完全に実現していないものを.Netが実現できるわけねーだろｳﾞｫｹ
106:デフォルトの名無しさん
03/02/19 03:33
>>104
プロジェクトの規模によっては、それもありですな。
高いAPｻﾊﾞ使ってEJBするのはオーバーヘッドがでかいだけで
イミガナイ、にもかかわらずEJBしているプロジェクトって
のもあるのかねえ。
107:デフォルトの名無しさん
03/02/19 03:35
Oracle の BC4J とかどうよ？
108:デフォルトの名無しさん
03/02/19 03:36
>>106
つまり、EJB否定派って感じですか (にこにこ
109:デフォルトの名無しさん
03/02/19 03:37
パターンとかそんなもんいちいち勉強しなければならないからJ2EEは普及しないんだYO！
VB.NETﾏﾝｾｰ
110:デフォルトの名無しさん
03/02/19 03:39
>>109
プラットホームが変わろうとも、J2EEパターンと同類の留意事項
を気にしなければ、分散アプリケーションはマトモに作れません。
銀の弾丸を信じるアホはイッテヨシ。
111:デフォルトの名無しさん
03/02/19 03:43
>>108
プロジェクトが成功する手法をとりましょう、というだけの話しだが。
VBでやるのが適切な仕事なら、VB使いますよ。嫌だけど。
112:63
03/02/19 03:43
>>103
読んでるっつーの！
だから設計の話をしてるんじゃないんだってば。
EJBでのプロジェクトはやってないけど、
EntityBeanのメリットって更新系にあると思う。
だからおいらは参照系にはEntityBeanは使わず、
SLSB＋DAO＋VO（EJBデザインパターンではDTO）でやるでしょう。
113:デフォルトの名無しさん
03/02/19 03:44
> 107
BC4Jは一応フレームワークの部類だけど、
データを扱う「普通の」BeanをDBとO-Rマッピングして
JSP/Servletで扱うイメージ。
EJB対応するには、そのBeanをうにゃうにゃする
感じ(ここはセミナーの説明を聞いただけで実際に検証
してないので怪しい)
114:デフォルトの名無しさん
03/02/19 03:45
要はJ2EEに失敗を認めたのがJ2EEパターンだろ？
こうしないとまともなものは作れませんよ、と。
115:デフォルトの名無しさん
03/02/19 03:45
DB 設計と同じく、EJB 設計にもいろいろと宗教があることがわかりますた
116:デフォルトの名無しさん
03/02/19 03:46
>>114
言い様だね ﾜﾛﾀ
117:デフォルトの名無しさん
03/02/19 03:46
>>114
J2EEパターンはGoFなどのデザインパターンに似てる?
118:63
03/02/19 03:47
まあ、良きしろ悪きにしろ
J2EE → 選択肢が多い
.NET → 選択肢が無い
って感じではないでしょうか？
.NETはフレームワークの選択の余地も無いでしょ？
119:デフォルトの名無しさん
03/02/19 03:47
>>109
はぁ? VB.NETだぁ? C#じゃねぇのか?
.NETがJ2EEより普及していないことも知らんのか。
継承できるVB.NET使えんならパターンくらい覚えろや。
継承できないVBしか使い慣れてないからJ2EEを妬みたいのか?
120:デフォルトの名無しさん
03/02/19 03:48
> 111
そう、トータルで検討しましょうということ。
ただ、事情によってEJBでよろしく！といってくる
依頼元があるかぎり、場合によってはデスマーチに
なったりするのです。それがよくお見受けする
営業と開発部隊の確執になったりするのです。
121:デフォルトの名無しさん
03/02/19 03:48
.NETパターンなるものは存在しないね。
フレームワークが完璧だから余計なパターンなど必要ない。
122:デフォルトの名無しさん
03/02/19 03:50
>>121
そのフレームワークもWin32 APIみたいなもんじゃ使い物にﾅﾗﾈ
123:デフォルトの名無しさん
03/02/19 03:50
>>114
元を正せば、ネット越しのTCP/IP送受信は遅いという、アプリ側ではどう
にもならないボトルネックが存在する状況で、少しでも早いシステムを作
る為のﾎｳﾎｳ論としては、ああいったパターンが必要になるのは当然の話し
だと思うが。
分散システムを作ったことがある奴なら、そういう発言にはならんと思う
なあ(ﾆﾔﾆﾔ
124:63
03/02/19 03:50
>>117
パターンは良く３つあると言われてます。
デザインパターン
アナリシスパターン
アーキテクチャパターン
GoF→デザインパターン
J2EEパターン→アーキテクチャパターン
他にもアンチパターンとかありますが。
125:デフォルトの名無しさん
03/02/19 03:51
>>117
似てないよ。ボトルネック回避のための苦肉の策なので、OO的には
全く綺麗ではありません。
126:デフォルトの名無しさん
03/02/19 03:51
>>124
アナリシスパターンってどういうの?
127:デフォルトの名無しさん
03/02/19 03:52
URLﾘﾝｸ(sagatoku.fc2web.com)
あなたの探し物こちらで見つかります
128:デフォルトの名無しさん
03/02/19 03:52
要はCOM+でとっくに確立してた手法をアホJava厨が仰々しく「パターン」とか名付けたんだろ？
129:117
03/02/19 03:53
>>126
さすがにそういうのはネットで調べた方が早いと思う...。
130:63
03/02/19 03:54
>>126
簡単に言うと
デザインパターン → 設計パターン
アナリシスパターン → 分析パターン
アーキテクチャパターン → その名のとおり
詳細は有名な人が書いた「アナリシスパターン」と言う本をみてくだされ。
おいらは読んでないです。
131:デフォルトの名無しさん
03/02/19 03:55
>>128
COM+? あんな糞APIの塊が確立だぁ?
アホ.NET厨のお前はJavaを妬んでM$製品に依存してるだけだろ
132:デフォルトの名無しさん
03/02/19 03:56
EJBは所詮1998年のMTSレベルのアーキテクチャだしね。
133:デフォルトの名無しさん
03/02/19 03:56
大体ASPでWebアプリ作るとスパゲッティになってメンテしにくいだろ
134:デフォルトの名無しさん
03/02/19 03:57
>>113
BC4Jって、Swingとか使ったファット・クライアントで、
画面操作に連動したDB参照/更新を、
SQL書かずに自動化したり、RADツールで自動生成するための
フレームワークだと思った。
ORマッピングの出来は良さそうなんで、
EJBっぽい応用を試してみた人はいないのかな？
＃パフォーマンス悪そうだけど
135:デフォルトの名無しさん
03/02/19 03:57
>>133
ASP.NETですべて解決しました。
136:デフォルトの名無しさん
03/02/19 03:57
で、最近あった .NET の案件はどんなんよ?
137:デフォルトの名無しさん
03/02/19 03:58
>>128
J2EEパターンなる名前がついているのは、作ったのがSunの社員だからな(ﾜﾗ
MSがつくってたらDCOMパターンだったかモナ～。
個人的には、分散システム構造パターンとか、そんな感じの汎用的な名前で
こういうのがあるといいと思うけど。この名前だと、J2EE専用だと勘違いし
てまうよね。
138:デフォルトの名無しさん
03/02/19 03:58
J2EEもVB.NETに追い抜かされて大変だな
139:デフォルトの名無しさん
03/02/19 03:59
>>132
EJB1.0 (1998) ＝ MTS
140:デフォルトの名無しさん
03/02/19 04:00
>>135
アフォ、全然解決してねーだろ。
コントローラも腐ってビューだけ便利そうなおもちゃか?
141:デフォルトの名無しさん
03/02/19 04:00
EJBってCOM+と同じことをどうしてもSolarisでも実現したかったから無理矢理作ったんだよね？
142:63
03/02/19 04:01
誰か>>63にも意見をﾖﾛｼｸ
143:デフォルトの名無しさん
03/02/19 04:01
>>138 残念ながらあなたが妄想しているVB.NETにはJ2EEを追い抜く機能は全然ありません。
144:デフォルトの名無しさん
03/02/19 04:02
>>136 チビ企業限定
145:デフォルトの名無しさん
03/02/19 04:02
>>141
COM+って、CORBA＋分散トランザクション を、
MSの専売特許という形でどうしても実現したかったから、無理矢理作ったんだよね？
146:デフォルトの名無しさん
03/02/19 04:03
ADO.NETみたいにコネクションレスのアーキテクチャでないと柔軟性がなくて駄目だね。
147:デフォルトの名無しさん
03/02/19 04:04
>>63
CORBAの失敗(M$を取り込めず、M$が暴走した)を教訓としてるとは思うけど、
CORBAほど重くならないように、相互互換性のみに焦点を当てて、実装方法は勝手にせい、
というスタンスだと思う。
148:デフォルトの名無しさん
03/02/19 04:05
>>132
で、M$の最新のアーキテクチャはどんなアーキテクチャなんだい?
あんたの話によればEJBより凄いらしいな。
149:デフォルトの名無しさん
03/02/19 04:05
>>146
ほぅ、面白そうなお話だね。語ってもらいましょうか(藁
150:デフォルトの名無しさん
03/02/19 04:06
>>146
JDBCだけではで問題があるからEJBを選んでいるというのに
お前は何もわかってないな。
151:63
03/02/19 04:06
.NETって単にWINDOWS DNAとかいう
わけ分からん統一感のない技術がWEBサービスに対応しただけでしょ。
しかもJVMパクッてCLR上で動かすのはいいけど、WINDOWSのみって。
サーバも出てないし。またサービスパックの嵐になりそうだし。
152:デフォルトの名無しさん
03/02/19 04:06
VB の延長で「わーい .NET だー」っていう勘違いプロジェクトならあるけどな…
分散システムで作ってるのは J2EE か CORBA(C/C++) しか知らないし他に聞かない。
153:デフォルトの名無しさん
03/02/19 04:07
> 134
そう、サーバサイドだけでなく全部に適用する開発環境/フレームワークで
話の流れ上、データの扱いに関してEntityBeanとの違いを
言いたかったのであのような説明になったのれす。
基本的にDB屋さんなんで、Viewのことはあまり気にしてないっす
154:63
03/02/19 04:07
>>147
なるほど。そんな感じします。
155:デフォルトの名無しさん
03/02/19 04:09
.NETに無知なアホが必死にJ2EEの話してて面白いな。(藁
156:デフォルトの名無しさん
03/02/19 04:10
いっぱい相手してもらってよかったな。
157:デフォルトの名無しさん
03/02/19 04:10
>>132
Microsoft Transaction Server (MTS)なんて
大袈裟なM$独自の用語で説明してM$独自仕様と比較されてもね。
158:デフォルトの名無しさん
03/02/19 04:11
>>155
J2EEに無知なアホが必死に.NETの話してて面白いな。(藁
159:デフォルトの名無しさん
03/02/19 04:11
.NET ＝ J2EE ＋ Webサービス
160:デフォルトの名無しさん
03/02/19 04:12
WSDPの話出てこないな(ﾜﾗい
161:デフォルトの名無しさん
03/02/19 04:12
だから.NETがJ2EEより優れてるところをJ2EEユーザに分かるように教えてくれ。
抽象的過ぎて分からん。
162:デフォルトの名無しさん
03/02/19 04:12
>>159
J2EE ＝ .NET － Webサービス
163:デフォルトの名無しさん
03/02/19 04:12
JWSDPやAXISの話でてこないな(ﾜﾗい
164:デフォルトの名無しさん
03/02/19 04:13
>>161
Microsoftなところ
165:デフォルトの名無しさん
03/02/19 04:13
.NET 2.0 ＝ J2EE 1.4
166:デフォルトの名無しさん
03/02/19 04:13
J2EEってJMSでSOAP通信含んでなかったっけ？
167:デフォルトの名無しさん
03/02/19 04:15
お前らさあ、Sun自身がこんなもん使えねーとか言ってるものをよく喜んで使えるな。
おめでたいというか。
168:デフォルトの名無しさん
03/02/19 04:15
>>165
どちらもまだ商品が出ていない
169:デフォルトの名無しさん
03/02/19 04:15
Webサービス＝J2EE － .NET
170:デフォルトの名無しさん
03/02/19 04:16
Windows DNA って、商品出ないうちに廃止になったんだっけ？
Windows .NET Server って、商品出ないうちに廃止になったんだっけ？
171:デフォルトの名無しさん
03/02/19 04:17
>>170
名称が廃止になっただけでコンセプトは健在。
172:デフォルトの名無しさん
03/02/19 04:17
>>166
Webサービス・アーキテクチャってなレベルのもんではないでそ
173:デフォルトの名無しさん
03/02/19 04:17
>>159
「Webサービス」、「 XML Webサービス」なんて用語はM$が勝手に解釈した用語だ。
M$独自の中途半端な仕様というところだな。
174:デフォルトの名無しさん
03/02/19 04:18
「.NETってなんですか」 M＄信者の心の叫び
175:デフォルトの名無しさん
03/02/19 04:19
BizTalk ってまだやってんの?
アクティブチャンネルはどこ逝ったの?
176:デフォルトの名無しさん
03/02/19 04:19
.NETはSOAP/WSDL/UDDIに絞り込んだしょぼい製品でつか
177:デフォルトの名無しさん
03/02/19 04:20
>>176
M$も他のベンダーも、ワークフロー/トランザクション にも力をいれてるよ
178:デフォルトの名無しさん
03/02/19 04:21
>>175
BizTalkやんならロゼッタネットしてebXMLだよな
179:デフォルトの名無しさん
03/02/19 04:22
>>176
WS-Security / Routing / Attachments にも対応してるよ。
180:デフォルトの名無しさん
03/02/19 04:22
>>147
とりあえずもうCORBAはお終いってこと？
もとからそんなに使われてなさそうだけど。
181:デフォルトの名無しさん
03/02/19 04:24
>>180
EJBはIIOPですが…
182:デフォルトの名無しさん
03/02/19 04:25
>>181
だから腐ってる
183:デフォルトの名無しさん
03/02/19 04:27
>>179
そうそう、Atachments って最近よく名前出てくるけど、どうゆうものですか？
184:デフォルトの名無しさん
03/02/19 04:28
>>182
顧客の囲い込みの為だけに、通信のプロトコルをSOAPベースにするような
腐れた頭の連中の作り出すものよりはマシかと。
185:デフォルトの名無しさん
03/02/19 04:28
>>183
XMLに直接バイナリを貼り付けられる。Base64より効率がよろしい。
186:デフォルトの名無しさん
03/02/19 04:29
>>176
ようするにM$はSOAPなどの独自規格を広めて新たなる独占をしたいっつーことだな。
187:デフォルトの名無しさん
03/02/19 04:29
>>183
URLﾘﾝｸ(msdn.microsoft.com)
188:デフォルトの名無しさん
03/02/19 04:30
>>186
Javaも、SOAP/UDDI/WDSLはJAX-ﾅﾝﾁｬﾗでサポートしているはずだが…
189:デフォルトの名無しさん
03/02/19 04:31
ebXMLはWS-Reliabilityの実装が肝だと思ってたけど、
ちゃんとしたデータ送って欲しいからね。連携するときは。
.NETってちゃんとその考えられているのかな？
ごめんおいらDB屋さんなんでやさしく教えてね＞識者の方
190:デフォルトの名無しさん
03/02/19 04:31
>>186
独自規格ならJ2EEでサポートする必要はありませんね。
191:デフォルトの名無しさん
03/02/19 04:33
>188
その何チャラでebXMLもサポートしてるらしいですが
開発者からすると実装が美しくないとのうわさが、、、
192:デフォルトの名無しさん
03/02/19 04:33
>>188
しかしSOAPを作ったのはM$とIBM。
M$は互換性をできる限りWindowsのみに限定させようとし
Windowsで動かないものは使いものにならないと思い込ませる戦術を使って来る。
193:デフォルトの名無しさん
03/02/19 04:35
大抵最後においしいところを持ってくのは IBM
194:デフォルトの名無しさん
03/02/19 04:37
>>188
JWSDP?
JAXというとJAXP?
195:デフォルトの名無しさん
03/02/19 04:44
そうJWSDPだ。JAXPはXML parserだ。
196:デフォルトの名無しさん
03/02/19 05:00
やっぱりJava厨はXMLに無知だな。(ｹﾞﾗ
197:デフォルトの名無しさん
03/02/19 05:07
>>185
8bitスルーな環境では、データ本体がバイナリーでもおっけ、という感じでしょうか？
>>186
M$の WSE/DIME に関するポインタ、どうもありがとうございました。
結局、WS-Attachments って
・SOAP 1.1 message を、MIME multipart の仕組みで送るための約束事(multipart/related で転送)
・Base URIの決め方に関する約束事
・各パートのデータを Content-ID または Content-Location でラベリング/参照する
ってもんなのねぇー。
参考文献: "SOAP Messages with Attachments" URLﾘﾝｸ(www.w3.org)
あと、勉強しとくべきなのは、
WS-Reliability
でつか。
198:デフォルトの名無しさん
03/02/19 05:15
>>197
>WS-Reliability
IBMもMSも絡んでない時点で政治的に失敗確実。
199:デフォルトの名無しさん
03/02/19 05:24
>>198
Fujitsu Limited, Hitachi, Ltd., NEC Corp, Oracle Corp., Sonic Software, and Sun Microsystems っすか。
リファレンスは、URLﾘﾝｸ(xml.coverpages.org)
でおっけ？
200:デフォルトの名無しさん
03/02/19 05:29
ついでに、
・WS-Security
・Web Services Security Addendum
・DIME
・WS-Routing
・WS-Referral
ってあたりも勉強しておこう・・・
201:デフォルトの名無しさん
03/02/19 05:42
>>200
すべて.NETで対応済みのものばかりですな。
つまり、VB.NET使いの方がウェブサービスで先を行っている、と。
202:200
03/02/19 05:53
>>201
WSE のページから抜書きしただけですが、何か？
ついでに。
WSEのページ(>>186) で、MSもメッセージのreliability を考慮している、と書いてあるけど、
具体的に何してるの？
203:200
03/02/19 05:56
↑186 じゃなく、>>187 ﾀﾞﾀｰﾖ。
URLﾘﾝｸ(msdn.microsoft.com)
＞In order to drive Web service interoperability in the enterprise,
＞the major players in XML Web services (including Microsoft, IBM, and Verisign)
＞have proposed new specifications that will improve interoperability
＞in areas that are crucial for Web services, such as security, reliable messaging, and sending attachments.
204:デフォルトの名無しさん
03/02/19 06:18
>>203
そこの文脈は Routing / Referral のことを指してるだけだと思う。
205:デフォルトの名無しさん
03/02/19 10:50
>>90
>おいらが言いたいことは設計うんぬんの話ではなくて
>EntityBean使ったら、 取得したレコード分「EntityBeanインスタンス」が作られるっちゅー話です。
>分かりづらくて申し訳ない。
無知もほどほどにしてください。
206:デフォルトの名無しさん
03/02/19 11:33
この記述資料の最後の2,3ページが面白いよ。
URLﾘﾝｸ(bdn.borland.com)
207:デフォルトの名無しさん
03/02/19 11:46
やっぱりM$.Net厨はXMLに無知だな。(ｹﾞﾗ
208:デフォルトの名無しさん
03/02/19 11:49
M$ 厨の必死なレスが笑える
209:デフォルトの名無しさん
03/02/19 12:36
そこそこいい具合でいってたのによそのスレと勘違いしてる人がいるようで。
210:デフォルトの名無しさん
03/02/19 19:35
タイミングよくWS-Routingの記事が。
URLﾘﾝｸ(www.atmarkit.co.jp)
やはりこういう分野は.NETの方が先行してるね。
211:デフォルトの名無しさん
03/02/19 20:43
>>210
どういう分野が?
独自規格だけ先行してるだけじゃん
212:デフォルトの名無しさん
03/02/19 20:54
>>211
馬鹿だねー。
IBMとMSがまとめているのに。
213:デフォルトの名無しさん
03/02/19 20:58
>>212
それはWS-Routingのことやろ?
わいはM$の行動のことをいってんのや。
214:デフォルトの名無しさん
03/02/19 21:01
>>213
こういう分野 = M$の行動 ?????????????
215:デフォルトの名無しさん
03/02/19 21:08
>>214
何か疑問があるなら .Net上でWS-Routingをつかうメリットを説明してね。
216:デフォルトの名無しさん
03/02/19 21:11
>>213
さすがデムパは違うね。
急にあさっての方向にいってわけわかんね。
ごまかすならもっとうまくおやりんさい。
217:デフォルトの名無しさん
03/02/19 21:18
厨房の不毛な展開に質が低下する予感
218:デフォルトの名無しさん
03/02/19 21:25
>>204
WS-Routing は reliabilityを提供していないと書いてある。
WS-Referral の概説きぼんぬ
219:デフォルトの名無しさん
03/02/19 21:29
お前ら少しは実際に動かしてから物言え
220:デフォルトの名無しさん
03/02/19 21:34
頭より先に手を動かしてしまうのは、器用貧乏
221:デフォルトの名無しさん
03/02/19 21:55
J2EEはSunの独自規格ですが。
222:デフォルトの名無しさん
03/02/20 00:32
>>220
頭も手も動かさずに口だけ動かすのは、本当に救いがありませんよ。
223:デフォルトの名無しさん
03/02/20 00:33
>>205
無知で申し訳ないですが、分かるように説明してくださらないか？
224:デフォルトの名無しさん
03/02/20 01:31
知恵遅れで申し訳ないですが、.netはフリー（無料）で開発できるの？
期限付きとか以外で。
できるわけねーだろっていわれておしまいぽい。
225:sage
03/02/20 01:34
>198
WS-Reliability の重要性がわからないんだからM$はふしあなさんだっつーの。
ビジネスデータ連携のプロトコルでは必須だっつーの。
ほんとはIBMも噛むべき話なんだがね。ほかのことで忙しかったか。
大事なお約束が抜けてるからM$のビジネスはおまぬけだっつーの。
標準規約の制定なんかまかせられん。
226:デフォルトの名無しさん
03/02/20 01:35
>>224
フリーの.NET統合開発環境「SharpDevelop」
ｽﾚﾘﾝｸ(tech板)
227:デフォルトの名無しさん
03/02/20 02:16
フリーの実行環境は?
228:デフォルトの名無しさん
03/02/20 02:24
mono on Linux とか？
229:デフォルトの名無しさん
03/02/20 02:28
.net開発ツールと連携したＵＭＬツールは？
ソース吐き出したり
230:デフォルトの名無しさん
03/02/20 02:31
>>224
SDK(コンパイラ＋ライブラリ＋ランタイム)だけなら無料だったような。
231:デフォルトの名無しさん
03/02/20 02:37
OS が有料という罠
つか Windows の値段って気にしないよな……何でだろ。
232:デフォルトの名無しさん
03/02/20 04:16
>>229
UMLツールって、クラス図との連携だけだよな？
なら、有料だがEAならいける。(C++やJavaもOK)
URLﾘﾝｸ(www.sparxsystems.jp)
日本語版は4月に発売予定。
しかし実際のところ、UMLツールのキモはユースケース図、ロバストネス図(？)、
シーケンス図だと思うんだが。
233:デフォルトの名無しさん
03/02/20 09:31
～∞
彡川川川三三三ﾐ～ ←java信者
ﾌﾟｰﾝ 川｜川＼ ／｜～
∥｜∥ ◎---◎｜～
川川∥ 3 ヽ～ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
川川 ∴）〆（∴）～ ＜ C#は糞！！
川川 ～ /～ ｜
川川∥ ～ /∥～ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
川川川川 (⌒)川∥～ ｳﾞｨｼｯ！
／/::::::::|-､ ,-/::::::ﾉ ~.ﾚ-r┐
/ /:::::::::::| /:::::ノ__ | .| ﾄ､
| /:::::::::::::::| 〈￣ ｀-Lλ_ﾚ′
234:デフォルトの名無しさん
03/02/20 09:32
川｜川川 川 ←アンチC#厨
∥川 | | | ー ー|| ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
川川 | |ｰ□--□l ＜ C#いらねー。
川川| |；＼ J/|| ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿_
川川∥； | ロ|/| カタカタカタ
川川|∥＼|＿_|l|l ＿＿＿＿＿
／川川川＿_/川川 | |￣￣＼ ＼
| 川川| |／川l＿_,| | |￣￣|
| ＼＿|＿_|＿|､＿＿| | |＿＿|
| ＼＿＿＿＿|つ |＿_|＿＿／ ／
| | | |￣￣￣￣| 〔￣￣〕
｜ |￣
235:デフォルトの名無しさん
03/02/20 09:34
彡川三三三ﾐ ／￣￣￣￣￣￣￣￣
川川 ::::::⌒ ⌒ヽ ＜ C#は糞
川川::::::::ー◎-◎-） ＼＿＿＿＿＿＿＿＿
java厨→川（６|:::::::: （ 。。））
.＿川川;;;::∴ ノ ３ ﾉ
／;;;:::::::::::::::＼＿;;;;;;;;;;;;;;;;ノ
/:::: /:::::::::::: |::::|
236:デフォルトの名無しさん
03/02/20 10:28
C#死滅スレに始まり、Java死滅すれでもやってるかと思えばこのスレでもAAですか。
本当に聖なる戦いですね。
237:デフォルトの名無しさん
03/02/20 10:40
>>232
ロバストネス分析なら
オブジェクト図やステートチャート図などで構成できるので
ロバストネス図というものまではいらんと思うが
238:デフォルトの名無しさん
03/02/20 13:26
WS-ReliabilityはBizTalk Frameworkのパクリですけど。
239:デフォルトの名無しさん
03/02/20 18:54
>>238
ebXMLのパクリでも....?
240:デフォルトの名無しさん
03/02/20 19:13
>>232
JavaDoc を読めばクラス図なくてもいいという気はするね。
詳細すぎるクラス図を読み解く手間は JavaDoc +ソースを読むのと変わらないくらいだし。
してみるとクラス図を表示するときに、
フィルタリングして余計な情報を除外する機能があると嬉しいかも。
241:デフォルトの名無しさん
03/02/20 21:38
>>238
うん、ありえる。
Reliabilityをちょこっと調べてみると、一時期M$がぶいぶい言ってた。
で、今M$は reliable message をどーやって実現しようとしているの？
242:デフォルトの名無しさん
03/02/20 21:39
つーか、キーボードの下10cm位に置いてある BiztalkServer本をめくって調べる気力がでない、今日は疲れてて
243:デフォルトの名無しさん
03/02/20 23:36
>>237
いやいやクラス図とJavaDocは存在目的が全く違うよ。
クラス設計しないんか？
244:デフォルトの名無しさん
03/02/20 23:50
>>240
あったほうがええよ。
デザインパターンとかつかってんならクラズ図見ただけで
なにやってるか推測しやすい。
245:デフォルトの名無しさん
03/02/21 00:24
>>243
クラス図は手書きで書くよ。
ドキュメントとして残すものは visio で清書してるけど。
246:デフォルトの名無しさん
03/02/21 01:24
>>205
>>223の説明しれ
247:デフォルトの名無しさん
03/02/21 02:13
現時点ではJ2EEが圧倒的に先行している。
J2EEがデファクトになりそうだから、MSはあせりまくりだな。
248:sage
03/02/21 02:38
BizTalkは実装したソフトウェア製品自体が不安定だったから
くそだっツーの。規約を安定した実装で実現できないM$には
退場宣告
249:デフォルトの名無しさん
03/02/21 13:12
あのさ、Reliable Messagingなんか2001年前半にはもうすでに文脈が登場してるわけ。
URLﾘﾝｸ(www.w3.org)
MSとIBMは今これを実現するための仕様を策定中なわけだが、富士通が先走って作った仕様じゃ
WS-SecurityともWS-Routingともその他のWS-XXとも、極論言えばSOAP1.2とも
互換性がないわけよ。仕様読めばわかるだろ。WS-Reliablityなんかどうせ消えるから
無視しておいたほうがいいぜ。Sunが出した振り付け仕様だってはなっから無視されてるだろ。
あれと同じ運命。
J2EEがデファクトとかいってるやつ、おまえがもう少しあせって勉強したらどうだ。
BizTalkが不安定とかいってるやつ、BizTalkのレベルでメッセージングシステムを構築できる他社製品をあげてみな。
250:デフォルトの名無しさん
03/03/03 23:37
おまえら J2EE と .NeT が死滅寸前に追い込まれたときどうするよ？
ちゃんと対策とってるかよ
死滅対策をよ
死滅後の行動とってるかよ
251:デフォルトの名無しさん
03/03/04 00:04
おまえら250が死滅寸前に追い込まれたときどうするよ？
ちゃんと対策とってるかよ
死滅対策をよ
死滅後の行動とってるかよ
別に放っておいてもいいか
252:デフォルトの名無しさん
03/03/16 13:43
UMLの本を読んでいたらアナリシスパターンが出てきた。
Layersパターンなんてものもあるんだね。
POSA(Pattern-Oriented System Architecture)
という本もあるんだ。
イディオムなんてものもあったんだ。
253:デフォルトの名無しさん
03/03/17 14:45
なんだかとりとめのないスレだな
254:デフォルトの名無しさん
03/03/31 01:42
初心者に教えれ
J2EEアプリケーションサーバはJavaだからLinuxでもWinでも動くが
.NETアプリケーションサーバはWindowsでしか動かないのですか？
255:デフォルトの名無しさん
03/03/31 01:43
>>254
LinuxでXSPが動いてる
256:デフォルトの名無しさん
03/03/31 02:10
>>254
実質そうだな。
257:デフォルトの名無しさん
03/03/31 02:14
>>254
Linux版は9月正式リリースです。
258:デフォルトの名無しさん
03/03/31 10:43
>>255
つまり.NETはLinux上ではWindowsと同じように動いてくれないと？
259:デフォルトの名無しさん
03/04/01 00:57
Linux版Windowsが９月に出るよ。
260:デフォルトの名無しさん
03/04/01 03:37
>>259
ｴｲﾌﾟﾘﾙﾌｰﾙﾃﾞﾂｶ・ﾟ・(つД｀)・ﾟ・
261:254
03/04/02 00:06
>>256
やっぱりそうなのか、だったら.NETがJ2EEより流行るわけないじゃんね
.NET vs J2EEつーより、サーバーOSとしてWindows << Linuxだもんな
262:山崎渉
03/04/17 15:47
（＾＾）
263:デフォルトの名無しさん
03/05/19 08:55
サーバはJava一色と聞きましたが、J2EEからActiveXも使えるのですか？
それとも、ActiveXを使ったASPが廃れてるのかな？
264:デフォルトの名無しさん
03/05/19 10:47
>>263
ActiveXというとJavaAppletとJavaScriptの中間に当たる
セキュリティホール丸出しの悪い印象があってActiveXで
プログラミングしている人なんて聞かないなあ。
よほどの物好きが使いってイメージがあるよ。
しかもASPも、VBScriptなどで動いている以上、良い印象がないなあ。
ASP.NETならまだいいけど。それでもMVCのViewだけってのは・・・
265:デフォルトの名無しさん
03/05/19 11:39
じゃあ、サーバJavaというのは、HTMLオンリーか、JavaAppletになるわけですか？
質問ばかりですみませんが、先ず一般的にどう作られているのか知りたいです。
266:デフォルトの名無しさん
03/05/19 12:28
一般的なのはJSP/Servet+EJBだろうな。
267:デフォルトの名無しさん
03/05/19 12:34
>>265
HTMLオンリー、JavaAppletとといったらクライアントサイド。
サーバサイドJavaといったらEJB(EnterpriseJavaBeans), JSP(JavaServerPages),
JavaServlet。
MVCアーキテクチャのうちModelが EJB
View がJSP 、これがライバルではASPやASP.NET、PHPってところか。
ControllerがServlet ライバルは良く知らない。
268:デフォルトの名無しさん
03/05/19 12:49
>JSP/Servet+EJB
>JavaAppletとといったらクライアントサイド。
JSPでActiveX並みの画面は作れるわけでしか。
もちろん、JSPでJavaApplet利用ですよね？
一時期JavaAppletは死んだと言われてましたが、
まだ、JavaWebStartなんてインストールされてない気がするというか自分が使ってないような気がする。
269:デフォルトの名無しさん
03/05/19 13:07
>>268
ASPやPHP, CGIをご存知なら解るとは思いますが
それらと同じ目的で作られたJSPはAppletやFlashやActiveXのような派手なものを表現するために作られたものではありません。
掲示板やチャット、オークションサイト、eCommerce. eCRMとか、B2B,B2Cサイトとかで
ユーザからのリクエストに応じてHTMLやAppletに情報をレスポンスする部分に使うものです。
実際には、JSPのソースコードを見てみればわかります。
JSPのタグでもAppletを呼び出す(<jsp:plugin>タグ)ことができます。
が、このタグはブラウザ側からは見られません。
といえばわかるでしょうか？
270:デフォルトの名無しさん
03/05/19 14:24
>AppletやFlashやActiveXのような派手なものを表現するために作られたものではありません。
分かります。
>JSPのタグでもAppletを呼び出す(<jsp:plugin>タグ)ことができます。
>が、このタグはブラウザ側からは見られません。
ブラウザ側からは見られないなんて、初めて知りました。
じゃあ、派手な画面にはAppletが生きてるわけですね。
一時期Applet死滅と騒がれてたので。
271:デフォルトの名無しさん
03/05/19 22:54
>>268
AppletとJavaWebStartは関係ないぞ。
JavaWebStartはAppletよりむしろ、JavaApplicationをAppletのように各クライアントに
インストール不要にする技術。
272:デフォルトの名無しさん
03/05/19 23:32
>>270
Appletで派手なものやろうとすればできないことも無いが
それだけをやるんだったらFlash使ったほうがかなり楽なことは確か。
Flashはデザイナー好みの機能満載だからね。
AppletをFlashのようにマウスだけで簡単に作れるツールは少ないね。
デザイン以外の目的で使うならAppletはまだまだ生きている。
HTMLと併用して何かを表示したいならまだまだApplet
273:デフォルトの名無しさん
03/05/19 23:34
>>270
> >JSPのタグでもAppletを呼び出す(<jsp:plugin>タグ)ことができます。
> >が、このタグはブラウザ側からは見られません。
> ブラウザ側からは見られないなんて、初めて知りました。
ブラウザでソースをみても違うものが返ってきます。ただのHTMLにAppletへのリンク、
<object>タグまたは<Applet>タグが現れます。
サーバ側で<jsp:plugin>を<object>に変換してからクライアントにそのHTMLダウンロードして
表示しているだけなのです。
274:山崎渉
03/05/28 12:56
∧＿∧
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎―◎ 山崎渉
275:デフォルトの名無しさん
03/06/04 13:28
.Net, WebSphere Security Tested
URLﾘﾝｸ(www.eweek.com)
276:デフォルトの名無しさん
03/06/09 23:16
java厨とC#厨が知識をひけらかしてるだけのｽﾚってここでつか？
277:デフォルトの名無しさん
03/06/17 21:22
Security Evaluation of Microsoft .NET Framework and IBM WebSphere - Executive Summary
URLﾘﾝｸ(www.atstake.com)
278:デフォルトの名無しさん
03/07/14 15:41
XML WEBサービスという名前がカコわるい
279:山崎 渉
03/07/15 09:44
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
280:デフォルトの名無しさん
03/07/20 02:06
大抵最後においしいところを持ってくのは IBM
281:山崎 渉
03/08/02 02:30
（＾＾）
282:山崎 渉
03/08/15 16:58
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
283:デフォルトの名無しさん
03/08/25 21:10
WSDPの話出てこないな(ワラい
284:デフォルトの名無しさん
03/09/02 15:27
J2EE vs. .NET - An Executive Look
URLﾘﾝｸ(www.netreverie.com)
285:デフォルトの名無しさん
03/09/02 15:33
[Service or Feature] Microsoft .NET Platform ／Java 2 Enterprise Edition Platform
[Language] VB, C++, C#, Java, Jscript, Perl…30+ ／ Java
[OS Platform & Runtime] Windows - CLR ／ Any ? JRE, JVM
[Mobile Platform] .NET Compact Framework ／ Java 2 Micro Edition
[GUI/In-proc Component] .NET class ／ JavaBeans
[Server-side Component] .NET, with COM+ services ／ EJB
[Persistent Objects] ADO.NET DataSet ／ EJB Entity Beans
[Web Page Generation] ASP.NET ／ JSP
[“Code Behind”] ASP.NET ／ Java Servlet
[Relational Data Access] ADO.NET ／ JDBC, SQL/J
[Hierarchical Data Access] ADO.NET ／ -None-
[Queuing] System.Messaging, MSMQ ／ JMS
[Asynchronous Invocation] COM+ Queued Components ／ Message Beans (EJB 2.0)
[Eventing] COM+ Events ／ -Not specified-
[Remoting] SOAP/HTTP/DCOM ／ RMI-over-IIOP
[Naming] ADSI ／ JNDI
[HTTP Engine] IIS ／ Apache
[XML] System.XML ／ JAXP, JAXM, JAXB, JAXR…
[Web Services] (.NET) XML Web Services ／ Sun ONE, IBM, BEA, Oracle
[Legacy Integration] HIS (COMTI), BizTalk, MSMQ, WS ／ JCA, JMS, WS, CORBA, JNI
[Shared Context] Passport ／ The Liberty Alliance, JXTA
[Security API] System.Security ／ JAAS
286:デフォルトの名無しさん
03/09/06 22:23
>>284
.NETの圧勝！
287:デフォルトの名無しさん
03/09/06 22:43
もう結果は見えてるよね。
JAVAって何？ああ、昔馬鹿な人たちが使っていたやつね、Ah ha.
288:デフォルトの名無しさん
03/09/06 23:09
>284
一番肝心な
Windowsしか選択肢がない，MSと心中 / OSを選ばない，心中することはない
はどうなんだ？
289:デフォルトの名無しさん
03/09/06 23:13
>>288
ちゃんと書いてあるじゃん。
Vendor Neutrality
J2EE 9/14
.NET 3/14
Portability
J2EE 11/14
.NET 1/14
290:デフォルトの名無しさん
03/09/06 23:15
英語の読めない低学歴のためにちゃんと図表で書いてるのにそれでも分からないのか。(w
291:デフォルトの名無しさん
03/09/06 23:18
>>284の著者もM$に脅されて泣く泣く.NETに有利な記事を書かされたのか。
良心の呵責に悩まされながら。
292:デフォルトの名無しさん
03/09/07 00:13
MSと心中した方が幸せになれるのは明白です
293:デフォルトの名無しさん
03/09/07 00:31
それは言えてる
294:デフォルトの名無しさん
03/09/07 19:52
JAVAはエンタープライズ、携帯電話の組み込み向け
.netはVB,C++,Delphiの得意なクライアント市場向け。
クライアントだとネイティブコンパイルができる.NET有利
サーバーとか非MSプラットフォームだといろんなOSのVMがあるJAVAが有利
今後はわからんが現状だとちゃんとすみわけができてる
295:デフォルトの名無しさん
03/09/08 06:42
クライアントにはDelphiがあるので.NET不利。
296:デフォルトの名無しさん
03/09/08 17:04
>>254
そもそも
.NETアプリケーションサーバ
ってなんですか?
297:デフォルトの名無しさん
03/09/11 00:53
マルチプラットフォームなんていらねーじゃん。
298:デフォルトの名無しさん
03/09/11 16:50
>>297
Wintel PCだけがコンピュータではないぞ？
エンタープライズとか組み込み市場なんかだと非Wintelが主流。
299:デフォルトの名無しさん
03/09/11 20:54
マルチも駄目ネイティブも駄目.NETはなんなの
300:デフォルトの名無しさん
03/09/11 21:39
Unicode関連が駄目駄目な某糞ツールよりはマシですよ。
301:デフォルトの名無しさん
03/09/25 11:42
.NETのILってFORTHを彷彿とさせるな
302:デフォルトの名無しさん
03/11/16 02:48
>>299
たんなるマーケティング用語ですが、なにか？
303:デフォルトの名無しさん
03/12/11 17:25
今日ドッグイヤーといって、新たなシステムソリューションを立案・計画してから市場に
実際に投入するまでの時間を、短縮することは極めて重要な課題となっている。
まずこの観点から両方式を比較する。
J2EEは、.NETには見られない市場に出すまでの時間を短縮できる特徴を持っている。
例えば状態管理サービスが開発者たちが書くコード量を減らし、状態の管理を思い煩わ
なくてもよくさせている。その結果アプリケーション開発スピードをより高いレベルに押し上
げる。状態管理サービスにより、状態を保持できるコンポーネントを構築することが可能に
なる。（entityBeanの）パーシステンスサービスにより、開発者はデータアクセスの論理を
コーディングせずに、アプリケーションを書き下すことができる。
その結果より簡潔な、データベースから独立したアプリケーションを、
より簡単に構築・保守することができるようになる。プログラミングされたトランザクション
は、より大規模なトランザクション上のコントロールを有するようになる。
そしてカスタムタグ（自分で任意に定義したタグ）は極めて強力なものであり、
開発者やWebデザイナーたちが簡単に協業することができるようにする。
304:デフォルトの名無しさん
03/12/11 19:04
>>303
カスタムタグを使って開発者とWebデザイナが分業できるってよく言われるけど
本当にうまくいってる例あるのかなあ
デザイナがどれくらいこの板を見てるか分からないけど、うちはtaglibで
大助かりだったって人居るの頭？
305:デフォルトの名無しさん
03/12/11 19:09
その問題は.NETでもJ2EEでもどちらでも抱えている問題だわな。
しかしそれもJakarta Tapestryで解決する。
306:デフォルトの名無しさん
03/12/13 15:23
J2EEは今日、さまざまのミッションクリティカルなビジネス上の問題を扱っている。
しかしながら表面的なものを振り返れば、J2EEが成熟さを欠いている、
いくつかの認定可能なリスク領域が存在するということを、銘記すべきである。
・自動パーシステンスが提供されるEJBは、未だに未成熟である。
・Java接続アーキテクチャ(JCA)は、新しい技術である。
・あらゆるWebサービスのサポートは、新しい技術である。
マイクロソフトの.NETにとっては、話は少し違ってくる。.NETのいくつかはWindowsDNA
に基づいている。それはまた今日様々なミッションクリティカルなWebサイトの運用に用い
られ、成功を収めている。しかしながら
・新しいCLRの下では、基礎をなしている.NETプラットホームのかなりの部分が実質的
に書き直されている。実際プラットホームそれ自体は、目下の所β版しか入手できな
い（註：今日では製品版が提供されている）。
・C#は新しい言語である。
・あらゆるWebサービスのサポートは、新しい技術である。
結論としては、J2EEの方がより成熟したプラットホームであるということだ。
J2EEにおけるある種の新規の特徴が、新しくかつリスキーであることは事実である。
しかしながら.NETの基礎の基礎をなす構造は、完全に書き直されており、C#言語全体
が完全に新しく開発されたものである。このことは新しいJ2EEの特徴と比較しても、
極めて大きなリスクを伴うことを示している。.NETについての最良の特色は、
それがCOMレジストリの依存性を排除していることにある。即ち.NETは、
DLL地獄とサヨナラしたのである。しかし、.NETについての最悪の特色は、
今存在しているインフラを追い出してしまうということにある。リスクが嫌なら、
この(.NET)ような第1世代のソフトウエアに対しては「じっと待って観察する。」
というアプローチをとることを勧める。
307:デフォルトの名無しさん
03/12/13 15:24
>>306
何年前の記事だろ？
308:デフォルトの名無しさん
03/12/13 15:26
> NETのいくつかはWindowsDNAに基づいている。
> .NETの基礎の基礎をなす構造は、完全に書き直されており
矛盾してます。
309:デフォルトの名無しさん
03/12/13 15:29
> .NETのいくつかはWindowsDNAに基づいている。
> .NETについての最悪の特色は、今存在しているインフラを追い出してしまうということにある。
やはり矛盾してます。
310:デフォルトの名無しさん
03/12/13 20:34
どう矛盾しているって？
311:デフォルトの名無しさん
03/12/13 20:35
「特色」と「基礎」の意味を理解していれば矛盾していないことに気が付くんだけどなあ
312:デフォルトの名無しさん
03/12/13 21:44
>>304
スタイルシートを使いこなせる(ブラウザの特徴を完全に把握している)
Webデザイナと、ドキュメント構造からどんなデザイン的自由を確保できるのか
理解してるPGがいれば、カスタムタグなんて要らない。
313:デフォルトの名無しさん
03/12/14 05:17
>>312
それいったらJSFやstrutsはおろかASP.NETは敗北宣言しているようなものじゃん・・・・。
314:デフォルトの名無しさん
03/12/14 10:14
>>312
＞ドキュメント構造からどんなデザイン的自由を確保できるのか理解してるPG
この部分が分からないので教えて四。それは具体的にどういう職能を持ってれば
タムタムタグが不要なの？
315:デフォルトの名無しさん
03/12/14 14:59
まあJakarta Tapestryを使えばカスタムタグを覚える必要がないのは確かだね
316:デフォルトの名無しさん
03/12/14 15:10
業務でJakartaなんて使う馬鹿いない。
バグったら誰が責任取るのさ？
317:デフォルトの名無しさん
03/12/14 15:22
普通に業務で使ってるけど。
Jakartaであろうとなかろうとバグったらバグの原因を作ったものが責任をとるにきまってるやん
318:デフォルトの名無しさん
03/12/14 15:26
つまりJakartaは一切責任を取ってくれませんと。最低だな。
319:デフォルトの名無しさん
03/12/14 15:29
Jakarta の信頼と実績を知らないでしょチミ。
Apache HTTP Serverがあれだけのトップシェアを誇った理由も知らないんじゃ話しにならないねw
320:デフォルトの名無しさん
03/12/14 15:33
>>319
タダだからだろ？
有料だったら誰も使わないよ。
321:デフォルトの名無しさん
03/12/14 15:34
JakartaとApache WebServerを並べても意味ないだろ。
別物だし。
322:デフォルトの名無しさん
03/12/14 15:35
JakartaがあるからJ2EEは要らないのか
323:デフォルトの名無しさん
03/12/14 15:36
Jakartaなんか使ってまでJavaやりたいかねえ。
Perlで十分じゃん。
324:デフォルトの名無しさん
03/12/14 15:45
つまりJavaはオプソに頼らなければならないほど信頼性も実績もないということか。
325:デフォルトの名無しさん
03/12/14 16:01
オプソの信頼性と実績に頼れない.NET房は大変だな（ｗ
326:デフォルトの名無しさん
03/12/14 16:12
これはこのフレームワーク、とかいろいろ組み合わせないと使い物にならなかったり。
MSの1つでOKとは違うね。
327:デフォルトの名無しさん
03/12/14 16:17
まあ、それは文化の違いでしょう。
どちらがいいかはその人次第。
328:デフォルトの名無しさん
03/12/14 16:32
>>324
ﾌﾟ お前はPerlのことを良く知らないでperlでいいとかほざいているようだが
perlもオープンソースだぞ(藁
329:デフォルトの名無しさん
03/12/14 16:33
>>321
同じApacheに属しているぞw
330:デフォルトの名無しさん
03/12/14 16:34
>>322
ﾌﾟ J2EEのことをよくわかっていないアフォですねw
331:デフォルトの名無しさん
03/12/14 16:35
>>330
J2EEはApache WebServerを含んでいるとでも？
332:331
03/12/14 16:36
あ、>>322宛てか。>>321宛てと読み違えた。ｽﾏｿ
333:デフォルトの名無しさん
03/12/14 16:44
>>320
それだけじゃない。
まずソースコードが公開されているため
ソースが公開されていない商用ソフトウェアやフリーソフトウェアよりも非常に信頼性が高い。
一企業に依存しない、ネットワークでつながれた
世界中のより多くの人によって開発されている。
だれでもその開発に携わることができる。これも信頼性を大きく高める起因。
数多くの人が開発しながら実際に使ってみてテスターとして貢献しているため
一企業の市販の商用ソフトウェアや同人でやっているフリーソフトよりも信頼性が非常に高い。
競合するソフトウェアの真の価値を暴くことができ、ライバルとなっている企業が
どうしてもオープンソーススフとウェアより価値のある製品を作らなければならなくなる。
オープンソースにも同じような機能があることが顧客に知れ渡れば顧客は安いほうを選ぶ。
すると商用ソフトを作っている企業は、自社ソフトとの値段を下げたり、真剣に新規性を求めた
製品を作るようになる。
これはM$などソースをほとんど公開したがらないM$などにとっては
大きな痛手でもあり、M$に刺激を与える効果を十分に発揮している。
むしろM$が必死にLonghornなど新しいものを作りたがる傾向は
オープンソースのおかげといっても過言ではない。
334:デフォルトの名無しさん
03/12/14 17:38
> まずソースコードが公開されているため
> ソースが公開されていない商用ソフトウェアやフリーソフトウェアよりも非常に信頼性が高い。
ソースを公開すれば必ず信頼性が高くなるわけではありません。
すべては元のソースの品質次第です。
> 一企業に依存しない、ネットワークでつながれた
> 世界中のより多くの人によって開発されている。
それはすなわち一貫性のないカオスということです。
> だれでもその開発に携わることができる。これも信頼性を大きく高める起因。
最近でもクラッカーに書き換えられて被害を出してますね。
> 数多くの人が開発しながら実際に使ってみてテスターとして貢献しているため
> 一企業の市販の商用ソフトウェアや同人でやっているフリーソフトよりも信頼性が非常に高い。
テストにおいて、ソースが公開されているかどうかはほとんど関係がありません。
335:デフォルトの名無しさん
03/12/14 17:38
> 競合するソフトウェアの真の価値を暴くことができ、ライバルとなっている企業が
> どうしてもオープンソーススフとウェアより価値のある製品を作らなければならなくなる。
> オープンソースにも同じような機能があることが顧客に知れ渡れば顧客は安いほうを選ぶ。
> すると商用ソフトを作っている企業は、自社ソフトとの値段を下げたり、真剣に新規性を求めた
> 製品を作るようになる。
それはイニシャルコストの話に過ぎません。
トータルコストから見れば大した割合ではありません。
> これはM$などソースをほとんど公開したがらないM$などにとっては
> 大きな痛手でもあり、M$に刺激を与える効果を十分に発揮している。
それは事実ですが、相手がオープンソースだからということとは何の関連性もありません。
ただ単に競合相手だからです。
> むしろM$が必死にLonghornなど新しいものを作りたがる傾向は
> オープンソースのおかげといっても過言ではない。
いいえ。顧客の機能要求によるものです。
336:デフォルトの名無しさん
03/12/14 18:59
Javaの信頼性なんてこんなものだろ。
URLﾘﾝｸ(www.javalobby.org)
337:デフォルトの名無しさん
03/12/14 19:01
よくわかんないんだけど、ドットネットだとバグはマイクロソフトが責任とってくれるんですか？
338:デフォルトの名無しさん
03/12/14 19:11
>>337
ドットネットにバグなど存在しません。すべて仕様でつ
339:デフォルトの名無しさん
03/12/14 19:22
>>326
M$のAPIを使う香具師は自分で作って公開するって香具師が少ないねほんとに。
Monoだけでしょ, まともなところってw
340:デフォルトの名無しさん
03/12/14 19:43
>>334
> > まずソースコードが公開されているため
> > ソースが公開されていない商用ソフトウェアやフリーソフトウェアよりも非常に信頼性が高い。
> ソースを公開すれば必ず信頼性が高くなるわけではありません。
> すべては元のソースの品質次第です。
まったく言っている意味がわかってないな。このアフォは。
いちいち説明しなおしてやらんとわからんの？ この低脳は。
>>334はApache Jakartaの話をしているんだよ。
ソースを公開していることが信頼されるための第一条件だといってんの。
まずソースコードが公開されていることを説明し、ソースコードが公開されている上で
どれだけ多くの開発者がかかわっているかを全体にわたって説明したでしょうや。脳足りんのチミ？
M$学生エヴァンゲリストだかなんだか知らんが
物事を部分部分で捉えずに全体を見て捕らえるって事ができないのかねM$房は。
視野が狭すぎるんだよM$厨房は。
> > 一企業に依存しない、ネットワークでつながれた
> > 世界中のより多くの人によって開発されている。
> それはすなわち一貫性のないカオスということです。
俺たちはこんあ小学生の作文いたいなぱっとしないコメントを読みたがっているんじゃないんだよ。
何が一貫性がなく何がカオスなのか説明してみろよチミ。
なんでもかんでもわかったつもりになって詭弁術を唱えるんじゃないよ。
オープンソースというのはコミッターによって一貫性を保ちつつしっかりと管理されているんだよ。
勘違いしないように。
341:デフォルトの名無しさん
03/12/14 19:49
> > だれでもその開発に携わることができる。これも信頼性を大きく高める起因。
> 最近でもクラッカーに書き換えられて被害を出してますね。
M$のWindowsUpdateに見られるセキュリティパッチの多さや被害の多さにに比べればたいしたこともないぞ。
> > 数多くの人が開発しながら実際に使ってみてテスターとして貢献しているため
> > 一企業の市販の商用ソフトウェアや同人でやっているフリーソフトよりも信頼性が非常に高い。
> テストにおいて、ソースが公開されているかどうかはほとんど関係がありません。
チミ日本語読めてる？ 突然「ソースが公開されているかどうかはほとんど関係がありません。 」
とか意味不明なこといって。何言ってるのチミ？ 頭大丈夫？
この一文はソースが公開されてるされていないの話をしているんじゃないんだよ。
数多くのテスターによって何度も繰り返しテストされなんどもチェックされて信頼と実績を確保していることが
Apacheというオープンソースソフトウェアの素晴らしいところなんだよ。
342:デフォルトの名無しさん
03/12/14 19:49
>>335
> > 競合するソフトウェアの真の価値を暴くことができ、ライバルとなっている企業が
> > どうしてもオープンソーススフとウェアより価値のある製品を作らなければならなくなる。
> > オープンソースにも同じような機能があることが顧客に知れ渡れば顧客は安いほうを選ぶ。
> > すると商用ソフトを作っている企業は、自社ソフトとの値段を下げたり、真剣に新規性を求めた
> > 製品を作るようになる。
>
> それはイニシャルコストの話に過ぎません。
> トータルコストから見れば大した割合ではありません。
全ての顧客にとってたいした割合とは限らんだろう。
>
> > これはM$などソースをほとんど公開したがらないM$などにとっては
> > 大きな痛手でもあり、M$に刺激を与える効果を十分に発揮している。
>
> それは事実ですが、相手がオープンソースだからということとは何の関連性もありません。
> ただ単に競合相手だからです。
馬鹿か。オープンソースだからとかではなく、相手がApacheなどの有名で人気どこであることが
M$に強い刺激を与えていることも事実なんだよ。
たとえばEclipseにしてもそうだ。次期VS.NETにはEclipseにあったリファクタリング機能が追加されるんだろ。
タダでできるツールがあれだけ高度なことができるのになぜ有償ツールは
ああいうことができないのか？ と顧客、プログラマから当然のように不満が来る。
343:デフォルトの名無しさん
03/12/14 19:51
> > むしろM$が必死にLonghornなど新しいものを作りたがる傾向は
> > オープンソースのおかげといっても過言ではない。
>
> いいえ。顧客の機能要求によるものです。
馬鹿をいえ、正確な返事は「はい、顧客の機能要求も含めオープンソースソフトウェアより
良いものを作らなければM$社を延命できないからです。」だろ。
平静さを装って逃げるなよ小僧。
オープンソースソフトウェアを見てただであれだけ素晴らしいものができるのに
なぜM$は金を顧客から詐取しておきながらオープンソースソフトウェアよりも
素晴らしい信頼性と高いセキュリティを誇る製品を作れないのだ？
と顧客にいつまでもいわれ続けないように努力するために新しいものを必死に作って
オープンソースソフトウェアに負けまいとがんばっているんだろ。
344:デフォルトの名無しさん
03/12/14 20:04
長くて読んでないけどM$とあるから内容はよくあるやつだと予想できるな。
345:デフォルトの名無しさん
03/12/14 20:04
M$厨マジでウザい
逝ってよし
346:デフォルトの名無しさん
03/12/14 20:06
> >>334はApache Jakartaの話をしているんだよ。
つまり、Apache Jakarta以外には信頼性は当てはまらないこと認めてるわけですね。
理解しました。
> オープンソースというのはコミッターによって一貫性を保ちつつしっかりと管理されているんだよ。
誰でも貢献できるわけではないのですね。残念です。
> M$のWindowsUpdateに見られるセキュリティパッチの多さや被害の多さにに比べればたいしたこともないぞ。
オープンソースに被害があることに変わりはありませんね。
> 数多くのテスターによって何度も繰り返しテストされなんどもチェックされて信頼と実績を確保していることが
> Apacheというオープンソースソフトウェアの素晴らしいところなんだよ。
商用ソフトはテスターが少ないとでも言いたいのでしょうか？
根拠が感じられませんね。
347:デフォルトの名無しさん
03/12/14 20:06
> 馬鹿か。オープンソースだからとかではなく、相手がApacheなどの有名で人気どこであることが
> M$に強い刺激を与えていることも事実なんだよ。
ならば「Apacheが刺激を与えている」と適切に書きましょう。
> たとえばEclipseにしてもそうだ。次期VS.NETにはEclipseにあったリファクタリング機能が追加されるんだろ。
> タダでできるツールがあれだけ高度なことができるのになぜ有償ツールは
> ああいうことができないのか？ と顧客、プログラマから当然のように不満が来る。
だからWhidbeyで対応されました。不満ですか？
> オープンソースソフトウェアを見てただであれだけ素晴らしいものができるのに
> なぜM$は金を顧客から詐取しておきながらオープンソースソフトウェアよりも
> 素晴らしい信頼性と高いセキュリティを誇る製品を作れないのだ？
ユーザー数の多さと幅の広さゆえです。
仮にオープンソースがWindows並みに普及したとしたら、結局は同じ壁にぶつかることでしょう。
348:デフォルトの名無しさん
03/12/14 20:12
> つまり、Apache Jakarta以外には信頼性は当てはまらないこと認めてるわけですね。
> 理解しました。
これ読んだ時点で萎えた。向きになったただの負けず嫌いの餓鬼かよ。
349:デフォルトの名無しさん
03/12/14 20:14
MS房の餓鬼は相手にするだけ時間の無駄です
350:デフォルトの名無しさん
03/12/14 20:15
言い返せないアホアンチ。(ﾌﾟﾌﾟﾌﾟﾌﾟ
351:デフォルトの名無しさん
03/12/14 20:15
小学生みたいなレスだなM$信者のレスは・・・
352:デフォルトの名無しさん
03/12/14 20:16
どっちがムキになってるんだろう。(ｹﾞﾗ
353:デフォルトの名無しさん
03/12/14 20:29
何だよ、オプソの利点もまともに説明できないのかよ。使えない奴
354:デフォルトの名無しさん
03/12/14 20:35
っていうか、得意気にオープンソースを語っておきながら、反論されたら
ろくに説明もできずに一人で勝手に切れて議論打ち切ってるだけじゃん。
どうしようもない馬鹿だな
現実では誰にも相手にされてないんだろうな
355:デフォルトの名無しさん
03/12/14 21:20
Javaがオープンソース？
冗談キツいなぁ
356:デフォルトの名無しさん
03/12/14 21:22
.NET厨(?)も相当性格が歪んでるなあ。(ﾜﾗ
357:デフォルトの名無しさん
03/12/14 21:35
Ｍ＄厨は帰れ
358:デフォルトの名無しさん
03/12/14 21:45
>>357
スレタイよく見ろ馬鹿
359:デフォルトの名無しさん
03/12/14 22:05
小学生のようなM$信者の必死な無知な発言に呆れたよ
360:デフォルトの名無しさん
03/12/14 22:19
アホアンチは幼稚園児並み
361:デフォルトの名無しさん
03/12/14 22:33
×幼稚園児並み
○幼稚園児以下
362:デフォルトの名無しさん
03/12/14 23:14
アホアンチとか言っているやつ、
M$とか言ってるやつ、
どっちも目障り。
363:デフォルトの名無しさん
03/12/14 23:19
>>362
なんだかんだ言ってM$擁護するつもりなんだろ。
これだからM$厨はイタ過ぎる。
364:デフォルトの名無しさん
03/12/14 23:19
つまりアホアンチが一番目障り
365:デフォルトの名無しさん
03/12/14 23:21
生きる価値のない禿豚だからな。www
366:デフォルトの名無しさん
03/12/14 23:35
>>362-365
お前らのことだ。
367:デフォルトの名無しさん
03/12/15 02:53
NGワードで隠れている奴の発言があるぞw
368:デフォルトの名無しさん
03/12/15 02:57
>>346-347
こいつは真性だな。
ApacheCommunityが誰でも貢献できるわけではない、と思い込んでいるとは
なかなか香ばしいやつだ。
369:デフォルトの名無しさん
03/12/15 16:39
M$のはSOAPが使われているからM$製品を使ったほうがいいといってる奴がいるみたいだが
Javaでも普通に使えるぞ。
JBossで使う場合もJBossに入っているAXISが使える。
370:デフォルトの名無しさん
03/12/16 00:58
AxisのSAXExceptionを吐くバグ、だれかなおしてくれ。
マジ困ってる
371:デフォルトの名無しさん
03/12/16 07:22
これだからオープンソースは使い物にならないし誰も責任とってくれない
372:デフォルトの名無しさん
03/12/16 13:10
マイクロソフトの製品は信頼できるし、マイクロソフトがしっかり責任をとってくれる。
いったんは今月パッチださないといったのに、予定外のパッチを出してくれるという誠実ぶり。
くろうナシに、マイクロソフトの仕様に従ってプログラムを組んでればいい。
そうすれば、Javaには太刀打ちできないシステムがいつのまにができあがる。
373:デフォルトの名無しさん
03/12/16 21:48
J2EEの話してる時にJakartaって馬鹿じゃねーの？
あんな信頼性のかけらもないライブラリ使ってたら大規模に耐えられんだろ。
374:デフォルトの名無しさん
03/12/17 03:32
ウィンドウズぐらいだよ、大規模に耐えれる信頼性があるのは。フリーソフトな
んてとんでもない。
これからは、銀行システムもウィンドウズ一色になる。
OSとして生き残れるのは、信頼性の高い、ウィンドウズだけだ。
SunもいつまでJavaみたいな馬鹿なことやってられるのか。
375:デフォルトの名無しさん
03/12/17 03:32
age
376:デフォルトの名無しさん
03/12/17 11:43
.net訳わかんねぇ。言語として規則性が皆無で美しさが無い。イラネ。
あんなの使ってる馬鹿いるのか？何でも飛びついて自慢したがるヲタ？
377:デフォルトの名無しさん
03/12/17 16:50
>>370-374
お前ら明らかに釣りな発言でﾂﾏﾝﾈ
378:デフォルトの名無しさん
03/12/17 17:31
タテヨミ。
379:デフォルトの名無しさん
03/12/18 09:25
>>371
バグによって発生した膨大な損失を、M$が賠償してくれるわけでは・・・
380:デフォルトの名無しさん
03/12/18 18:06
>>378
マ
い
く
そ
374 名前：デフォルトの名無しさん 投稿日：03/12/17 03:32
ウ
ん
こ
O
S
ﾜﾗﾀ
マイ糞(＝Micro$oft)
うんこOS(＝Windows)
381:デフォルトの名無しさん
03/12/18 23:32
J2EEと.NETの連携を考える（1)
J2EEと.NET連携の意義を考える
URLﾘﾝｸ(www.atmarkit.co.jp)
とりあえずこれを読め怒濤熱湯厨
382:デフォルトの名無しさん
03/12/18 23:37
アフォくせぇ。
なんで同じ機能を提供する２つのプラットフォームを使い分けなければならないのか。
383:デフォルトの名無しさん
03/12/19 14:41
お前がｱﾌｫだ。
J2EEと.NETを連携する構想なら昔からすでに多くの企業がやっている。
384:デフォルトの名無しさん
03/12/28 23:21
.NETがLinuxでも完全に動くのなら.NETの方がいいような気がする。
JSPより.NET方がはるかに楽に感じるのは気のせいだろうか・・・。
ただ、OSがLinuxじゃないと不安な気が・・・。
やっぱり、JSPか？Jakartaになってしまうのか・・。
.NETは使いたいものはパッケージにまとまっているので安心。
でも・・・。の永久サイクル。どっちがいいのか？
385:デフォルトの名無しさん
03/12/28 23:28
>>24
がっ
386:デフォルトの名無しさん
04/01/01 20:24
>>384
無知の匂いがするぞ。
.NETの全ての機能はLinux上では完全には動きやしない。
JSPと.NETは比較するものではない。JSPだけに絞り込む場合はASP.NETとを比較するものだ。
安定性、信頼性からサーバOSには、LinuxよりもUnixを使ったほうが良い。Windowsは論外。
>.NETは使いたいものはパッケージにまとまっているので安心。
いまいちいっている意味が理解できないな。パッケージの意味わかってる？
387:デフォルトの名無しさん
04/01/18 03:48
細かいことだけど、.NETのFileクラスって全部staticメソッドで、
引数をパスの文字列で指定するようになってるんだが、
それってどうにもセンス無いと思うんが、どうよ。
388:デフォルトの名無しさん
04/01/18 07:21
>>387
FileInfo
389:377
04/01/18 16:05
>>388
ああ、なるほど。
俺の早とちりだった。
これって低レベルのFile, Directoryクラスを
高レベルのFileInfo、DirectoryInfoクラスでラップしてるのかな。
390:デフォルトの名無しさん
04/02/28 11:19
Javaから見たC#と.NET
URLﾘﾝｸ(nemuneko.com)
391:デフォルトの名無しさん
04/03/13 14:39
保守
392:デフォルトの名無しさん
04/04/09 12:18
.NET-Java「連合」の前途に立ちはだかる障壁
URLﾘﾝｸ(www.itmedia.co.jp)
SunとMSは「.NETとJavaを統合する計画はない」が、両プラットフォームの連係に
向けた取り組みを進めていく。しかしそれには、いくつもの技術的な障壁を解決しなくてはならない。
「『決して』とは言わない……言うべきではないが、C#とJava言語を統合する計画も、
.NETとJava Web Servicesアーキテクチャを統合する計画もない。しかしわれわれは、
適切な形で進むべき道を見つけるべく懸命に取り組んでいく」とSunのCEO、
スコット・マクニーリー氏は記者会見で語った。
SunとMicrosoftによると、両社のエンジニアはMicrosoftのActive Directoryと
SunのJava System Identity Serverの間でID情報を簡単に共有できるように協
力していくという。これらの2つのプラットフォームに相互運用性を持たせる取り
組みは過去にもあったが、それは主にSunのリバースエンジニアリングにより行
われていた。
「この取り組みではプロトコルを推測しなくてはならなかった。特にセキュリティ
とID管理に関して、一部の機能がうまく動作しない。例えば、J2EEを取り扱ってい
る一部の開発者はTuxedo向けにプログラムを書かなくてはならなかった。特にSIPに関
しては、認証とセキュリティ管理の次善策がいくつかあった。今はこれらの障壁の一部
をなくすために取り組んでいる」とSunのソフト担当CTO（最高技術責任者）ジョン・フォウ
ラー氏はinternetnews.comに語った。
393:デフォルトの名無しさん
04/04/09 19:22
うちの会社でNT4.0上のASP鯖がそろそろサポート切れになるんで、
Win2003鯖のASP.NETに再開発しようとしたら、コストの関係でだめになった。
Win2003鯖の問題なんだけど、調べてみたら、いままでＣＡＬが不要だった
イントラアプリが軒並みＣＡＬが必要になってやんの。
インターネット経由と言い張ろうとも、いちおう認証らしきこともしてるんで
結局CAL要になってしまった。
結局、PHP on Linuxで開発をやり直すことに。(J2EEじゃないところが
ヘタレ)
でもよかった。MSDN買う前で。
394:デフォルトの名無しさん
04/04/09 21:45
2003鯖のCAL問題はいろいろでてるね
2000のダウングレードインストールしてるところも多い
だからこそLinux＋J2EEなんだろうね
PHPでやるならjspのみで構築する方がいいような気がしないでもない
395:393
04/04/10 00:10
>>394
漏れが開発するわけじゃないからなぁ～（遠い目。ASP版を作ったのは漏れ）
でも、マジで開発者数分MSDEエンタープライズを買いかけてたみたいで、
そっちのほうが恐ろかった。
漏れ？ Borlandのいってる「EJBなしJ2EE」の開発をやってまふ（藁）。
出稼ぎ組み（要はオンサイト派遣ね。契約上は請負だけど）なんで社内で
の発言権まるでなし。
396:395
04/04/10 00:13
わりぃ、大チョンボ。
誤）でも、マジで開発者数分MSDEエンタープライズを買いかけてたみたいで、
正）でも、マジで開発者数分MSDNエンタープライズを買いかけてたみたいで、
個人向けデータベースのエンタープライズ版買ってどうすんだか。
397:デフォルトの名無しさん
04/04/10 01:10
EJBなしJ2EE?
JSP + Servletオンリー？
つまりTomcatオンリー？
398:395
04/04/10 09:26
>>397
そんな感じ。
ＤＢアクセスはJDBC直書き。テーブル数が１０くらいのプロジェクトがほとんど
なんでアクセスパターンを明確にしておけば、そんなに大変じゃない。
.Netのサンプルもそんな感じでしょ（もっとも、あっちのDBアクセス部分は
コード自動生成だけど）
399:デフォルトの名無しさん
04/04/10 16:49
>>398
DbUtils とか Hibernate は候補にもあがらず？
400:398
04/04/11 14:07
>>399
オープンソースのO/Rマッパーはお客さんが独自実装嫌がるんで使えない。
どっかの会社が「フレームワーク」として発売して、結構なシェアになれば
興味を示すかもね。(AppachやTomcatですら嫌がるくらいだからﾀﾞﾒﾎﾟ)
401:デフォルトの名無しさん
04/04/11 19:52
>>400
エンドユーザがORマッパーとかまで口出しすんの？ ってか知ってるんだ。
俺が組んだシステムが小規模ばかりだったためかどうか分からんけど、
そのへんは好き勝手に使いまくりだよ。もちろん責任は持たないとダメだけど、
それは自分で組んでも同じだからね。
客はWebサーバやAPサーバは気にするけど、そのへんは無頓着だった。
ってか DbUtils とかだったら勝手に使って後で聞かれても
あー Apache のライブラリっすよ。でいいんじゃないの？
俺、甘いか？
402:デフォルトの名無しさん
04/04/11 20:58
昔ほど一本あたりの単価が高く大規模、開発に時間をかけると言うことが少なくなってきて
短期、低予算というハードルの上で開発する場合やはり効率がもっとも重要視される
どんなにすばらしい設計でも間に合わなければお話にならないし最悪な環境に
どんどんなってる気がするけど
EJBって年々よくなってるのにどんどん使わなくなってるというのが俺の感想
凶悪な規模のシステムはのぞく
Apacheとはいえ勝手に使うのは論外だと思うがそのへんは柔軟に使えないと厳しいね
すべてはプロジェクトリーダー次第な気がするが
403:デフォルトの名無しさん
04/04/11 21:49
>>402
あーもちろん勝手に使うってのはチーム内で合意をとったうえね。
404:デフォルトの名無しさん
04/04/12 04:08
>>402
それ程大きくなくてもEJB使っていますよ。
405:デフォルトの名無しさん
04/04/12 11:04
マイクロソフトのTCO調査は本当に信用できるか？
ｽﾚﾘﾝｸ(tech板)
406:デフォルトの名無しさん
04/04/25 19:37
>>401
遅いレスだが、
オープンソース＝フリーウェア＝質がよくないと思ってる客が多いのは事実。
あとは、責任の所在が不明確になるのが嫌なんだろうね。
オープンソースの癖に「ライブラリのバグで」と言い訳するやつは多いだろうし。
407:デフォルトの名無しさん
04/05/01 10:14
おなじ機能をいまから作っても、オープンソースのメジャーなライブラリと同じ品質にはならんのにね。
408:デフォルトの名無しさん
04/05/13 18:47
J2EE用のリッチクライアント
URLﾘﾝｸ(www.nexaweb.co.jp)
409:デフォルトの名無しさん
04/05/14 01:53
15 Seconds : Survey Says Firms Choose .NET Over J2EE
URLﾘﾝｸ(www.15seconds.com)
Industry .NET J2EE
public sector 65% 35%
business services 64% 36%
media 62% 38%
retail/wholesale trade 58% 42%
manufacturing 55% 45%
finance/insurance 44% 56%
utilities/telecom 35% 65%
410:デフォルトの名無しさん
04/05/18 18:06
sessionを使わずにhtml（値入力）→サーブレット→JSP(値を入力)←あとはJSPのループ
の仕方がわかりません・・・
411:デフォルトの名無しさん
04/05/26 19:47
意味がわからん。
412:デフォルトの名無しさん
04/06/29 10:59
URLﾘﾝｸ(java.sun.com)
Performance is critical for the success of your applications built on Java technology
and it impacts all levels of the software stack. Software-stack performance involves
server-side programs, client-side programs, Web services, operating systems, servers,
and desktops. Here we provide tools and documentation to help you learn more about
improving performance in each of these areas.
June 23, 2004
WS Test 1.0 White Paper A comparison of SOAP based web services performance of
the J2EE and .NET platforms. In all cases tested J2EE significantly outperforms .NET. Get
the whitepaper to learn about the tests that were used and the results that were obtained.
Check back after the JavaOne 2004 conference for the downloadable code for WS Test.
413:デフォルトの名無しさん
04/06/29 10:59
February 11, 2004
XML Test 1.0 White Paper A team of engineers from Sun compared the XML Processing
Performance between Java and .NET. For example we found that the Java SAX parser
significantly outperformed the .NET pull parser for the majority of use cases. We took
care to ensure that the application code and hardware configuration used on both platforms
were as similar as possible in order to make an objective performance comparison. We don't
expect you to just to take our word for it; we've provided instructions and source code so that
you can run the test yourself. Get the whitepaper to learn more about the XML tests that were
used and download the source code from the Web Services Code Samples page so that you can
evaluate the performance yourself!
February 4, 2004
J2SE 1.5 in a Nutshell The beta 1 release of J2SE 1.5 ("Tiger") is now available and promises
easier performance tuning in addition to better startup, footprint and scalability. Check out this
article to get an overview of these exciting changes
よってJ2EEの勝ち！ ﾄﾞﾄﾈﾄの負け♪
414:デフォルトの名無しさん
04/06/29 11:05
URLﾘﾝｸ(java.sun.com)
のレポートでわかることは、
棒グラフをみてわかるように、
J2EEは.NETに比べスループット性能に優れ
.NETはJ2EEに比べレスポンス性能に優れているという点だ。
ゆえに、.NETは短期的な小規模開発向け、
J2EEは長期的な大規模開発向け
だということがよくわかる。
415:デフォルトの名無しさん
04/06/29 11:11
で、いつ惨は倒産するの？ｗ
416:デフォルトの名無しさん
04/06/29 11:12
SunにしろMSにしろ、特に凄いのはAppleだがメーカー謹製のベンチを信じているヤツは痴呆
417:デフォルトの名無しさん
04/06/29 11:22
TigerってMacのことだろ？
Javaはパクるなよ。
418:デフォルトの名無しさん
04/08/06 01:29
age
419:デフォルトの名無しさん
04/10/28 13:31:48
すみません、EJBが良くわからないのですが、
なんとかビーンってオブジェクト、つまりクラスのインスタンスって
ことで良いんですか？
EJBは.Netでの何に相当するんでしょうか？
ある種のCOM？
なんか、EJBのビーンがDBに特化してるようなので、
ADO.NETに相当するんでしょうか？
それとも、.NetではEJBに相当するものは存在しない？
420:デフォルトの名無しさん
04/11/04 01:43:20
EJBはコンポーネントトランザクションなんかをサポートするためのコンポーネント開発技術だよ。
ざっくり言うと以下のようなものがある。
・Session Bean
ビジネスロジックの記述向け。
さらに細かく分けるとStateless Session Bean(SLSB)とStateful Session Bean(SFSB)がある。
・Entity Bean
データアクセスコンポーネントの記述向け。（正確にはちょっと違うけど）
さらに細かく分けるとBean-managed persistent(BMP)とContainer-managed persistent(CMP)の2種類がある。
・Message-Driven Bean
メッセージングを扱うためのコンポーネント記述向け。
っつーかgoogleとかで検索かけてみれ。いくらでも出てくるぞ。
.NETにはCOM+（Enterprise Services）ってのがあるが、これはSLSBに対応する技術。
ADO.NETに対応するのはJavaだとJDBCとかになる。(JDBCほど低水準ではないけど)
データアクセス（オブジェクトの永続化）に対する考え方が根本的に違うから、.NETにはEntity Bean（～v2）に対応する技術はない。
しかしJavaの世界もSession Beanはともかく、Entity Beanは使いにくいねぇ。
v3で落ち着いてくれるといいんだが....
421:じゃばまる
05/01/12 05:56:39
Javaと.NETの掲示板です。
↓
URLﾘﾝｸ(8712.teacup.com)
誰か書込みしてやって下さい。
422:デフォルトの名無しさん
05/01/12 15:56:20
話についてイケない私は負け組みですか？
423:kabu
05/01/23 11:16:40
J2EEではないのですが、スレの有効活用のため使わせてください。
数年前まではVB,VBA,ASP中心、ここ2,3年は.NET(Windows, ASP.NET)をC#で開発してきましたが、
今回はJSP/ServletによるWebアプリケーションを作成しています。
それでApache,Tomcat,MySQL、Eclipseを使って開発しているのですが、
今までのIISやVS.NETに比べると、サーバーや開発環境などの設定方法が非常に煩雑で
今だ非常に効率の悪い開発をしています。
Javaはすごいっていうのでもっと良いものだと思っていたのですが、正直落胆しています。
J2EEとかを使った大規模開発なら分があるのかもしれませんが
小中規模のWebアプリ開発ではJavaよりも.NETの方が優れているものなのでしょうか。
それとも市販製品なら.NETに負けないくらいのよいサーバー、IDEがあったりするのでしょうか。