.net と J2ee - 暇つぶし2ch

.net と J2ee ..

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のように各クライアントに
インストール不要にする技術。

次ページ