5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

.net と J2ee

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を単純に比較するのはどうかと思うけど。
>>テクノロジーとしては全然違うものだよ。
あほか?どこが違うんだ?MSが独創的な製品作ったことあるのか
考えてものいえ




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
なんか自作自演な雰囲気がw
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
「中小企業」云々てフレーズをこの板で見るの、今日で3回目だけど、
その部分はホントかなぁー。

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
それは

http://www.mamezou.net/column/column13.htm

のコピペっぽい。

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
この際CORBAは関係ないでしょ。
>>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アーキテクチャのようなものがあるのですか?
ありません。詳しくはNET版PETSHOPをみてくれ


39 :デフォルトの名無しさん:03/02/17 21:46
>>37
2chってj2eeネタはウケが悪いけどどうしてよ?

40 :デフォルトの名無しさん:03/02/17 21:49
MVCも可能だが、.NET版で使ったデザイン パターンのほうが優れているし
パフォーマンスも良いと。
http://www.microsoft.com/japan/msdn/net/compare/petshopfaq.asp

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よりソース量が1/6に縮小。
ストアドプロシジャを使ってパフォーマンスの向上。
.NET版PetShopにはMSの必死さが伝わってくるよ。

>>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
よく言われてるのは、
トランザクション管理とリモート呼び出しが自動化
(EJBコンテナがやってくれる)されることだと思う。
逆にこれを使わないとほとんどメリットは無い。
コンポーネント化がうんぬんとか言ってるけど。
実際できんの?って感じです。

実際EJBを使うのは壁が高すぎるし、めんどくさい。
素直に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の話。
1万件のデータを持ってくるとしたら1万件の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
やっぱ、EJBだろ!?

60 :デフォルトの名無しさん:03/02/18 14:32
EJBはソース内に直接SELECT文を無駄に書かなくても良いというのが利点ですね。

61 :デフォルトの名無しさん:03/02/18 15:18
ボーランドが.NETプログラムでEJBを使えるようにするらしいよ。

62 :デフォルトの名無しさん:03/02/18 23:26
EJBつーかアプ鯖重過ぎ。


63 :デフォルトの名無しさん:03/02/19 01:06
結局WEBサービスって、
M$が参加したCORBA見たいなもんだと思ってよろしいか?

64 :デフォルトの名無しさん:03/02/19 01:10
>>55
>ごめん。メモリを食うのはEntityBeanの話。
>1万件のデータを持ってくるとしたら1万件の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はそういうもんだっぺ。
1レコード=EntityBean1インスタンスに対応するんだったら
1万件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
結局「1レコード=1EntityBeanインスタンス」で良いか?

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
PK1つでとってくるデータの塊って何?

テーブルAとテーブルBが1対他の関係だとして、
テーブルAの1レコード+テーブルBの対応する外部キーのNレコード取得している状態?

テーブルA、Bに対してEntityBeanをマッピングしたら
インスタンス数 =
 テーブルAに対応しているEntityBeanインスタンス×1
 テーブルBに対応しているEntityBeanインスタンス×N
でしょ。

塊すべて1レコードとは違うでしょ?
結局「1レコード=1EntityBeanインスタンス」では無いの?

87 :デフォルトの名無しさん:03/02/19 02:38
間違えた
1対他 → 1対N
です。


88 :デフォルトの名無しさん:03/02/19 02:44
>>86
どちらの実装も可能なのではないのかね。

89 :デフォルトの名無しさん:03/02/19 02:45
>>67-68
効率よくする方法自分で考えて自作しろよ。

ある情報、検索するにあたって検索エンジンで1万件ヒットすることがわかっていたとして
検索を1万件のデータをその場ですべてアップロードするような馬鹿な設計をするか?
Googleでも検索結果が10000件になったとしてもそれらすべてを
一つのページに表示するという馬鹿なことをするか?
10〜100件程度ずつ表示するだろ。
自動絞込み検索アルゴリズムを作ってBeanを分割統治することくらい考えろよ。

それにこの情報がもし画像だとしたらその実体をいちいちBeanの中にいれるアフォなことするか?
参照だけを入れて容量を節約するだろ。

それに一度取り出したBeanをブラウザに表示させるときも、
表示しない部分のBeanはいつまでもメモリ上に保持するなんて馬鹿なことするか?
使わなくなったオブジェクトにはnullを入れるか破棄するのが常識だろ。

それでも足りないなら圧縮できるなら圧縮し直列化して一時保存かさらにDBに保存するとかView表を作るとか考えろよ。
>>68もAPIのせいにしないでアルゴリズムと設計方法を考え直すくらいのことしろよ。

90 :デフォルトの名無しさん:03/02/19 02:48
>>88
どちらの実装もってどれとどれを指してるですか?
スマソ。
結局おいらが言いたいことは
どう実装しようがEntityBean使ったら、
「1レコード=1EntityBeanインスタンス」になるでしょということです。

なんか思いっきりすれ違いでうざいかな?

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(初心者歓迎)」でどうぞ
    http://pc2.2ch.net/test/read.cgi/tech/1017240849/


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レコード=1ValueObject」 (EntityBeanでなく単なるオブジェクト)

ちょっと工夫すると
「Nレコード=1ValuesObject」

100 :デフォルトの名無しさん:03/02/19 03:25
>>95
世の中には、リモートのEJBの1属性のget/setを鬼のように呼びまくって
挙句の果てに遅いのをAPサバのせいにするアホが大勢いますからねえ・・・

ええ、うちの会社にもいますよ…
そんでもって、J2EEもどきを自分で作ってますよ…
もうアホかと、馬鹿かと(以下略

101 :デフォルトの名無しさん:03/02/19 03:26
たとえばCMP Beanとか使ったら間違いなく
問い合わせの結果セットの1レコード = 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
パターンは良く3つあると言われてます。
デザインパターン
アナリシスパターン
アーキテクチャパターン

GoF→デザインパターン
J2EEパターン→アーキテクチャパターン

他にもアンチパターンとかありますが。

125 :デフォルトの名無しさん:03/02/19 03:51
>>117
似てないよ。ボトルネック回避のための苦肉の策なので、OO的には
全く綺麗ではありません。


126 :デフォルトの名無しさん:03/02/19 03:51
>>124
アナリシスパターンってどういうの?

127 :デフォルトの名無しさん:03/02/19 03:52
http://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
http://msdn.microsoft.com/webservices/building/default.aspx?pull=/library/en-us/dnwebsrv/html/wsedime.asp

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" http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211


あと、勉強しとくべきなのは、
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 っすか。

リファレンスは、http://xml.coverpages.org/WS-ReliabilityAnn.html#WD
でおっけ?

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 ダターヨ。
 http://msdn.microsoft.com/webservices/building/default.aspx?pull=/library/en-us/dnwebsrv/html/wsedime.asp

>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ページが面白いよ。
http://bdn.borland.com/article/images/29074/transaction_commit_options.pdf


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の記事が。
http://www.atmarkit.co.jp/fdotnet/special/wse03/wse03_01.html

やはりこういう分野は.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」
http://pc2.2ch.net/test/read.cgi/tech/1023727377/

227 :デフォルトの名無しさん:03/02/20 02:16
フリーの実行環境は?

228 :デフォルトの名無しさん:03/02/20 02:24
mono on Linux とか?

229 :デフォルトの名無しさん:03/02/20 02:28
.net開発ツールと連携したUMLツールは?
ソース吐き出したり

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)
http://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厨→川(6|::::::::  ( 。。))
    ._川川;;;::∴ ノ  3  ノ
  /;;;:::::::::::::::\_;;;;;;;;;;;;;;;;ノ
 /::::  /::::::::::::    |::::|


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年前半にはもうすでに文脈が登場してるわけ。
http://www.w3.org/2001/03/WSWS-popa/paper51
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が9月に出るよ。

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
ttp://www.eweek.com/article2/0,3959,1114315,00.asp

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
http://www.atstake.com/research/reports/eval_ms_ibm/

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⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

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

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

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