.net と J2ee - 暇つぶし2ch

.net と J2ee at TECH

1:デフォルトの名無しさん
03/02/16 21:37
実際どっちがええの？なんか同じことできそうだけど。
.netはまだ生まれたてだから
JDK1.1の頃のようにバグだらけなんかな。
実績で言ったらJ2eeかえ？

2:デフォルトの名無しさん
03/02/16 21:38
>>1

3:デフォルトの名無しさん
03/02/16 22:01
.netとJ2EEを単純に比較するのはどうかと思うけど。
テクノロジーとしては全然違うものだよ。

4:デフォルトの名無しさん
03/02/16 22:13
>>1 >>1 >>1 >>1 >>1 >>1 >>1 >>1
>>1 >>1 >>1 >>1 >>1 >>1 >>1 >>1
>>1 >>1 >>1 >>1 >>1 >>1 >>1 >>1
ﾌﾟ

5:デフォルトの名無しさん
03/02/16 22:25
おいおいおいおいおいおいおい、

　　J　2　E　E　ネ　タ　は　マ　ジ　で　ヤ　バ　イ

って言ってるだろ

6:デフォルトの名無しさん
03/02/16 22:29
あぁ、マジやめたほうがいい。Java厨がわんさか暴れまわるから

7:デフォルトの名無しさん
03/02/16 22:46
　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ﾟ ∀ ﾟ）＜　わんさかわんさか！
　　　　　　　　　　　　　　　　　＼＿／　　＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ﾟ∀ﾟ）＜　わんさかわんさかわんさか！
わんさか～～～！　＞（ﾟ∀ﾟ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／｜　　　〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」
　　　　　　　　　　　　　￣　　　　 / ／

8:デフォルトの名無しさん
03/02/16 23:42
>>.netとJ2EEを単純に比較するのはどうかと思うけど。
>>テクノロジーとしては全然違うものだよ。
あほか？どこが違うんだ？ＭＳが独創的な製品作ったことあるのか
考えてものいえ

9:デフォルトの名無しさん
03/02/16 23:46
ほれみろ。Java厨が現れた

10:デフォルトの名無しさん
03/02/16 23:46
じゃ、全く同じということで終了

11:デフォルトの名無しさん
03/02/16 23:46
あぁ、マジやめたほうがいい。C#厨がわんさか暴れまわるから

12:デフォルトの名無しさん
03/02/16 23:47
そらみろ。C#厨が現れた

13:デフォルトの名無しさん
03/02/16 23:50
なんか自作自演な雰囲気がｗ
J2EEってのはフレームワークの一つで
別に使わなくたって似たような物はできる。
ただ、フレームワークを一個提案しておけば、
それにあわせてサードパーティーがなんかがいろいろ
作ってみると。

.netが何を指すのかは不明だが、
WEBサービスのJ2EEと同じような部分を指す物はない（はず）。
なぜなら、マイクロソフトがフレームワークの細部まで
作りこんでいるので、他の選択肢がないから。
もちろん、J2EEとやれる事は同じだけれど
開発方法は全然違う。

14:デフォルトの名無しさん
03/02/16 23:51
>>8
つまり .NetをJ2EEをちょっとパクッた程度でJ2EEほど基幹系業務には向いていないということで。

だから.NetはJ2EEと比べ大手企業では使われにくい。

.Netは中小企業で殆ど使われている傾向。

15:デフォルトの名無しさん
03/02/16 23:58
>>14
全然論理的な説明になっておりませぬ。やり直し。

16:デフォルトの名無しさん
03/02/17 00:05
>>14
「中小企業」云々てフレーズをこの板で見るの、今日で３回目だけど、
その部分はホントかなぁー。

M$が中小企業向け市場を開拓するってニュースは出てたけど。

17:デフォルトの名無しさん
03/02/17 00:08
J2EEが大手企業で使われる理由って何？
作るのが大変だから？

18:デフォルトの名無しさん
03/02/17 00:16
>>16 現状がそうなっているってことでしょ。
本当らしい。C#死滅過去スレにそのニュースサイトへのリンクがあったなあ。
でも中小企業ではかなり人気高いと思うよ。

>>17 大変だと言うのは否定できないかも。
逆に言えば中小企業には大掛かりなもの(基幹系)を扱う機会も金も資産も規模も
少ないため.NETでもどうにかなるっちゅーことでないの?
M$から資金や製品の割引サービスなどの支援も受けている可能性も否定できないな。

でっかい会社だとナリッジも増大し管理が大変そうだからなあ。

19:デフォルトの名無しさん
03/02/17 00:16
あんまり.netは知らないけど下記のような対応かね？
　CLR⇔JVM
　ASP⇔JSP
　ADO⇔JDBC
　Windowsフォーム⇔Swing

.NETでServletとEJBに対応するような技術はあるんですかいのう？

20:デフォルトの名無しさん
03/02/17 00:18
ついでにJMS＆MDBも

21:デフォルトの名無しさん
03/02/17 00:21
JTSも重要だしょ

22:デフォルトの名無しさん
03/02/17 00:23
J2EEとJWSDP知ってると、.NETがやってる事は大体理解できるよ。

23:こぴぺ
03/02/17 00:26
COM+(COM)⇔EJB コンポーネント技術
DCOM, .NET Remoting⇔RMI 分散オブジェクト技術
ASP.NET (ASP)⇔JSP, Servlet Webアプリケーション技術
ADO.NET, OLE DB⇔JDBC データアクセス技術
MSMQ⇔JMS 非同期メッセージング技術
ADSI(Active Directory）⇔JNDI ディレクトリ技術
MTS⇔JTAトランザクションモニタ技術

24:デフォルトの名無しさん
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 の値段って気にしないよな……何でだろ。

次ページ