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

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

J2EEを語ろう

1 :デフォルトの名無しさん:03/06/07 23:55
こんなサーブレット作ったぞと言ったような自慢、
こんなことをしたいんだがと言ったような希望、
〜は〜だといったような評価をするスレ。
ではどうぞ。

2 :デフォルトの名無しさん:03/06/07 23:56
キターーーーーーーーーーーーーーーーーーーーーーーーーーーーーッ

3 :デフォルトの名無しさん:03/06/08 00:00
質問ですが、
J2EEを素早く習得するに当たって、お勧めの本を教えてください。


4 :デフォルトの名無しさん:03/06/08 00:00
初めてjava使ってから1ヶ月でチャット作った漏れはどうよ?

5 :デフォルトの名無しさん:03/06/08 00:01
J2SEとかJ2MEとかあるけど、あれはなに?

6 :デフォルトの名無しさん:03/06/08 00:10
>>5
J2EE 早い話が、分散コンピューティングをするためにある。
エンタープライズコンピューティングをするためにある。動かすにはJ2SEが必要。

J2ME 携帯電話開発用。動かすにはJ2SEが必要。

7 :デフォルトの名無しさん:03/06/08 00:11
J2SE これがなければ話にならない。これがなければJavaプログラミングすることができない。

8 :デフォルトの名無しさん:03/06/08 00:14
J2EEの中核をなす、もっとも重要な部分であるEnterpriseJavaBeansもよろしく。

EJB(初心者歓迎) 2
http://pc2.2ch.net/test/read.cgi/tech/1054357210/

 

9 :デフォルトの名無しさん:03/06/08 00:14
J2SEが中核で、J2EEやJ2MEはそれの発展形(?)ということ?

10 :1:03/06/08 00:16
>>3
翔泳社の『標準J2EEテクノロジー (2) 基礎から学ぶJSP/サーブレット』を俺は買った。
本は、その場で自分に分かりやすいやつを選んだほうがいいと思う。

>>4
天才やな!

11 :デフォルトの名無しさん:03/06/08 00:23
J2EEネタはマジでヤバいって。

12 :デフォルトの名無しさん:03/06/08 00:24
>>9
J2SEダウソして、サーバ関係なら次にJ2EEダウソ。
携帯とか組み込み式関係だったらJ2MEダウソ。
まぁ、それ以外はほとんどJ2SEでまかなえると。


13 :デフォルトの名無しさん:03/06/08 00:25
>>11
やっぱり書くと思った。(w

14 :デフォルトの名無しさん:03/06/08 00:25
>>12
なるほど。J2EEやJ2MEは拡張キットみたいなものなんだ。
じゃあJavaを勉強するだけならJ2SEだけでいいんだ。

15 :デフォルトの名無しさん:03/06/08 00:25
>>11
ワラタ
どうヤヴァイと?

16 :デフォルトの名無しさん:03/06/08 00:26
つかJ2EE的スレ多くね?

17 :12:03/06/08 00:26
>>14
ソダネ。

18 :デフォルトの名無しさん:03/06/08 00:28
>>17
ありがとうございました。

19 :デフォルトの名無しさん:03/06/08 00:28
>>16
>>1いわく、自慢や希望を書けと自己マソのスレなんだろ、ここ?

20 :1:03/06/08 00:31
>>19
自己満か
ああ そうさ、そのとおりさ。

21 :デフォルトの名無しさん:03/06/08 00:34
今度、javaでサーバ関係のプログラムを書くアルバイトに行くことになったんだけど、
普通のjavaと違うところってなんですか?

22 :デフォルトの名無しさん:03/06/08 00:35
>>15
アホアンチ自爆事件があったのよ。スレ大荒れ。

23 :デフォルトの名無しさん:03/06/08 00:37
>>22
ワザワザアリガトゥ

24 :デフォルトの名無しさん:03/06/08 01:40
>>21
TCP/IPの知識も必要になる。

25 :21です:03/06/08 01:42
ありがとうございます。<<24
クグって、本買って独学していきます。

26 :デフォルトの名無しさん:03/06/08 02:52
J2EE とかって、JavaScript とは全然違うんだな。
Web上のスクリプトしてた漏れはてっきり同じものだと(ry

27 :デフォルトの名無しさん:03/06/08 03:18
>>26
JavaScriptは、
書き方は似てるかもしれないがJavaとは別物と良く耳にする。

28 :1:03/06/08 03:31
>>26 >>27
技術評論社『パソコン用語辞典』 一部引用。
JavaScript[ジャヴァスクリプト]
【言語】米国ネットスケープ社と米国SunSoft社が共同開発したスクリプト言語。
HTML文書中に"<script>"というタグを指定することにより直接書き込む。
名前にJavaとはついているが、Javaとの共通点は少なく、開発当初はLiveScriptといった。

ットサ;


29 :デフォルトの名無しさん:03/06/08 04:40
それって常識じゃないのか

30 :デフォルトの名無しさん:03/06/08 09:11
>>22
> >>15
> アホアンチ自爆事件があったのよ。スレ大荒れ。
愚痴をはきたければこちらへどうぞ。

.net と J2ee
http://pc2.2ch.net/test/read.cgi/tech/1045399051/



31 :デフォルトの名無しさん:03/06/08 10:50
>>26
とんでもないアフォだ。
ダウンロードしてから実行するものとサーバ側で実行してからダウンロードするものとの
区別がつかないとは。 

32 :デフォルトの名無しさん:03/06/08 12:32
>>31
専門領域が違うだけなのに、自分の方が偉いと
勘違いしていませんか?

33 :デフォルトの名無しさん:03/06/08 13:06
>>32 禿同
ま、専門分野以外は見えてこないのが当然だと思われ

34 :デフォルトの名無しさん:03/06/08 18:35
J2EE と Java2 とどう違うのか教え(ry

35 :デフォルトの名無しさん:03/06/08 18:44
レベル低っw

36 :デフォルトの名無しさん:03/06/08 20:48
>>34 わからんが J2までは同じでは

37 :デフォルトの名無しさん:03/06/08 20:48
J2EE=EJB と思っている香具師は多いだろ?
JSP, Servlet も J2EE だぞ。

38 :デフォルトの名無しさん:03/06/08 22:30
>>34
J2SE = Java 2 Platform, Standard Edition (J2SE)
http://java.sun.com/j2se/index.html
J2EE = Java 2 Platform, Enterprise Edition (J2EE)
http://java.sun.com/j2ee/
J2ME = Java 2 Platform, Micro Edition (J2ME)
http://java.sun.com/j2me/

ってことで、みんなJava2!
J2SE 1.2以降、Java2と呼ぶようになった。

39 :デフォルトの名無しさん:03/06/08 22:46
PerlとjavaどっちがCGIを書くのに適しているんだろう?



40 :デフォルトの名無しさん:03/06/08 22:49
CGIの意味しってっか?

41 :デフォルトの名無しさん:03/06/08 22:50
むぅ・・・レベル低っ

42 :デフォルトの名無しさん:03/06/08 22:50
Perl=メモリ消費大、java=あんまりメモリ食わない。
perl=効率が悪い,java=効率が良い。
ト 漏れは、勝手に判断した。

43 :39:03/06/08 23:00
>40 クグッテミタヨ
Common Gateway Interface
Webブラウザからの要求をサーバが処理してHTMLなどの形式で返す仕組み自体のこと。
>41
スマソ
>42
サンクス


44 :デフォルトの名無しさん:03/06/08 23:16
すさまじいレベルの低さだ

45 :デフォルトの名無しさん:03/06/08 23:35
>42
まじで?

46 :デフォルトの名無しさん:03/06/08 23:49
>>42
間違っちゃいないが正確でもない
単純に言えばJavaはメモリ食うよ。
たとえば、1リクエストを単純に処理するのみだったら
JavaよりPerlのほうがメモリ消費は少ない。
でも、同時に大量のトランザクションを処理するのだったら
Javaのほうが効率が良く、メモリ消費が少ない。
大量になればなるほどJavaのほうが有利。
同時処理の数が増えてもメモリをはじめとしたりソースの消費が
直接比例して増大しない。
Perlなんかだともろに増大するね。

47 :デフォルトの名無しさん:03/06/08 23:50
JMS 1.1が試せる無償の環境ってまだないんでしょうか?

48 :デフォルトの名無しさん:03/06/08 23:50
J2EEとEJBは別物?
それともJ2EE⊃EJB?

49 :デフォルトの名無しさん:03/06/08 23:57
J2EEってワカンネ。
サーブレットとかはそうなの?

50 :デフォルトの名無しさん:03/06/09 00:03
J2EEは
Servlet,JSP,EJB,JNDI,JMS,JCA,JavaMail等を含む仕様・規格のこと。

51 :デフォルトの名無しさん:03/06/09 00:07
>>1-50
やっぱDQN・JAVA厨は全員WEBpg板に隔離すべきだな
みていて吐き気がするオェ〜!

52 :デフォルトの名無しさん:03/06/09 00:11
JavaMailってJava製のメーラー?

53 :デフォルトの名無しさん:03/06/09 00:13
>>52
この辺でも見ておけ
http://java.sun.com/products/javamail/FAQ.html

54 :デフォルトの名無しさん:03/06/09 00:16
>>51
そういうオマエは何厨なのだ?

>>52
Java のメール API

55 :デフォルトの名無しさん:03/06/09 00:19
じゃあそれを使えばJavaでメールサーバをつくれるんだ?

56 :デフォルトの名無しさん:03/06/09 00:20
>>55 それがApache JAMESではないか。

57 :デフォルトの名無しさん:03/06/09 00:20
J2EEスレとは思えないレベルの低さだ!!

58 :デフォルトの名無しさん:03/06/09 00:22
>>55
つくれるよ

59 :デフォルトの名無しさん:03/06/09 00:22
>>47に誰か答えられんのか(俺は知らん)

60 :デフォルトの名無しさん:03/06/09 00:23
>39

わざわざjavaでCGIかく理由ってなんなんだ?
普通にservletとかjspとかでやったほうがいいと思うんだが.....

毎回毎回forkしなければいけない世界ならperlで書いたほうが早いと思うんだが、興味
あるなら実験してみたらどうよ?



61 :デフォルトの名無しさん:03/06/09 00:24
ここでレベル低いとか吼えてる奴は、現実では文句ばっかり言ってて
何の生産物も生み出せないタイプなんだろ?

62 :デフォルトの名無しさん:03/06/09 00:25
>>61
オマエモナー

63 :デフォルトの名無しさん:03/06/09 00:25
昔、javaの起動コマンドを書き込んだシェルをCGIにしてみた事があった。
ほんとわれながら馬鹿だと思った。

64 :デフォルトの名無しさん:03/06/09 00:27
このスレ見て思ったけど、
こんなに敷居高い言語なら技術者集まらないから使えないな。

65 :デフォルトの名無しさん:03/06/09 00:31
>>64
だから、Servlet、JSPくらいならまだしも、
EJBやJMSが広まらない
規格も実装もこなれてないというのもあるけど

66 :デフォルトの名無しさん:03/06/09 00:34
JavaBeansなんてふざけた名前のせいだろう。

67 :デフォルトの名無しさん:03/06/09 00:34
分散オブジェクトという点ではEJBはとてもいいと思う。
CORBAよりもお手軽だし。
ただCMPやCMRまで使おうとすると苦労しそう。

68 :デフォルトの名無しさん:03/06/09 00:35
ServletはCGI「みたいなもの」であってCGIではないだろうが。
それとも何か、>>39はシェルで
java Hello.class
とか書いて、それを呼び出すようにしたいのか?

69 :デフォルトの名無しさん:03/06/09 00:37
>>68
Exception in thread "main" java.lang.NoClassDefFoundError: Hello/class

70 :デフォルトの名無しさん:03/06/09 00:39
servlet=javaでのcgiという事で話を進めたほうが・・・。
俺の非力マシンで>>63と同じ子とやったけど、JVMが10個程度しか
立ち上がらなかった。
ほんと意味無し。

71 :68:03/06/09 00:41
ああ悪かったよ、漏れが厨だよ(藁
java Hello
な。回線切って首吊って寝るわ

72 :デフォルトの名無しさん:03/06/09 00:47
>>レベルが低い言う香具師
最初はなんでも簡単なとこからするもんさ。
public class MyFirstJava{
public static void main(String args[]){
System.out.println("モナー");
}
}

73 :デフォルトの名無しさん:03/06/09 00:48
Perlだってmod_perlとか使うと、CGIオーバヘッドはかなり解消されるし
比較が「普通のCGIによるPerl」とServletではフェアではないと思われ。

74 :デフォルトの名無しさん:03/06/09 00:53
>>73
正論だな。
厨は比較対照がしたいだけだろう。
気にすんな。

75 :デフォルトの名無しさん:03/06/09 00:53
>>64言語の敷居は高くない。J2EEという規格の敷居が高いだけだ。
>>65必要性が低いからだろ。何でも使えばいいってもんじゃない。
>>67RMIでいいだろ。分散トランザクションまで含めて初めてEJBの価値がある。

76 :デフォルトの名無しさん:03/06/09 00:54
>>73
CGI処理系の標準としてそういう動作が保証されてる訳ではないからね。
mod_perl も単なる Apache 拡張だし。

Servlet なら、Webコンテナの動作の標準にあるから、どの処理系でもスレッドで動く。

77 :デフォルトの名無しさん:03/06/09 00:56
>>73
それだけ進化してたら
毎秒数千トランザクションのチケット販売サイトとかも
今ならPerlで実装できる?俺はJavaしか無いと決めてかかってたよ。

78 :デフォルトの名無しさん:03/06/09 00:57
だからあれほどCGIにはRubyを使えと(ry

79 :デフォルトの名無しさん:03/06/09 00:58
どうでもいいが、「普通のCGIによるPerl」は逆じゃないか?
「普通のPerlによるCGI」じゃないか?

80 :デフォルトの名無しさん:03/06/09 00:58
>>76
>>39はそういう難しい話をしたいのではないと思うぞ(w
そういう意味でCGIを書きたいというなら、
最初からJavaと比較するわけないだろうしな。
要するにHTML吐き出す処理のコードの書きやすさだろ。

それにしたってJavaでも色んなフレームワークあるし、
PerlでもCPAN行けば色々と便利なものがあるわけで、
好みとしか言いようがないと思うがどうよ。

81 :java初心者:03/06/09 00:58
漏れjavaでチャットを作りたいんだけど、どんなことを学べばよいのでしょうか?
Linuxでapacheは立ち上げてあるから、プログラムを完成させるだけなんだよな。
ちなみに、J2EEもインストール済み。

82 :デフォルトの名無しさん:03/06/09 01:01
>>77

mod_perlの何が「それだけ進化」なのかと(ry

83 :デフォルトの名無しさん:03/06/09 01:03
ていうか、レベル引く杉。
WebLogicとかWebSphereとかふつうに使ってるやついないの?
WebProg板に逝っちゃってるのか?

84 :リアル消防:03/06/09 01:03
CORBAってなくなるんじゃないの?
仕様がでかすぎたとか使えないとかで
どうせ持ち上げてるのもうSUNだけでしょ?

85 :デフォルトの名無しさん:03/06/09 01:04
>>78
Rubyも良いナ。
漏れはRubyにニゲル。

86 :デフォルトの名無しさん:03/06/09 01:06
>>83 そういう香具師が>>1を見てカキコするとは思えん(w

87 :デフォルトの名無しさん:03/06/09 01:11
perlで大規模なものを作ったことないから分からないが
javaの方がトランザクションの管理とかが楽な気がする
DBwrapperとかが用意されてればの話だが

クラスが継承できる分大規模なシステムでの構築に向いている
逆に対して規模の大きくないシステムであれば
perlやPHPの方が向いてるんじゃないかと思う


88 :デフォルトの名無しさん:03/06/09 01:11
>>81
ソケット通信の勉強がいいんじゃないか?
そこに転がってるJ2EEってのは無駄に
なるかも知れんがな

89 :java初心者:03/06/09 01:14
>>88
ソケット通信ですね。
クグって勉強します。
アリガトウ。

90 :デフォルトの名無しさん:03/06/09 01:16
J2EEのターゲットは大企業向け基幹システム。
つまり、現行COBOLで組まれているレガシーシステムを
Javaで置き換える方向に持っていきたい、っていうのがSUNの思惑だと思われ。
だから、チャットとかそういうの作るためには仕様が重すぎる。
素直にPerlなりPHPなり使うべし。
単に勉強のためっていうのならばいいけどね。

91 :デフォルトの名無しさん:03/06/09 01:21
>>87

そういうこと書くと、今度はシステム設計やる人間のレベルでとか
言い出す奴出てきそうだから、比較ネタはそろそろやめれ。

比較ネタはこちらへどうぞ↓

【Java PHP CGI mod_perl】の使い分け for プロ
http://pc2.2ch.net/test/read.cgi/php/1010257796/l50

そろそろ「J2EEを語ろう」ぜ。後恥ずかしいからageるの止めないか(w

92 :デフォルトの名無しさん:03/06/09 01:22
>>90
要するに、Javaは大げさってことよね

93 :デフォルトの名無しさん:03/06/09 01:24
>>91
結構WebProg板に出入りしているつもりだが、そのスレ初めて見たぞ。

94 :デフォルトの名無しさん:03/06/09 01:25
>>92ワラタ

マジレスするとJ2EEは確かに大げさだ。
Java自体は別に普通だよ。

95 :87:03/06/09 01:25
>>90
COBOLで動いてるものを置き換えるつーのも結構無理あがるんじゃないの?
いやどうもjava=web系のアプリが多いし
自分がやった案件はweb系でもバッチはcとかが多かった(実行速度の問題等で)

基幹をjava系に置換しようとすると
メインフレームから離れちゃうわけだから企業としても勇気がいりそうだな

#IBMのメインフレームでlinuxが複数動くが日本であれを使ってる企業とか有るのかな?

96 :デフォルトの名無しさん:03/06/09 01:27
>>95 だってメインフレームからSolarisに乗り換えさせるためのJ2EEなんだから(w

97 :デフォルトの名無しさん:03/06/09 01:27
要するにJ2EEを理解するには、
システム構築におけるサーバサイドの技術を理解していないとできないっつーこった。
サーバサイドの技術って分散オブジェクト、トランザクション、ネーミングサービス、非同期呼出、Web技術等。

まあServlet、JSPだけなら、CGI作れる程度のWeb技術+Javaのコーディング技術があれば
できると思うが。
EJB、JMSやろうとすると上記のようなことを知らないとできないでしょう。

98 :87:03/06/09 01:27
>>91
いやそんなに長く比較ネタを続けようとはおもわんけど(w



99 :デフォルトの名無しさん:03/06/09 01:29
>>96
そういう魂胆なんだ。

100 :デフォルトの名無しさん:03/06/09 01:31
>>99 SunFire売りたいんだろ(w

100ゲト?


101 :デフォルトの名無しさん:03/06/09 01:32
>>95
時代的にはメインフレームは収束の方向だから、
J2EEはこれからの基幹に入っていくんでねーの?
現状は既存のメインフレームには手を入れずにWebのインタフェースを
くっつけるだけだろうけど。
#Linuxはメインフレームと考え方が正反対な気がするんだが、ほんとに基幹に入っていくのか?

102 :デフォルトの名無しさん:03/06/09 01:32
>>96
しかしSolaris上でWebSphereを使わせればIBMの逆転勝ち。

103 :デフォルトの名無しさん:03/06/09 01:32
>>100
あのめちゃくちゃ格好いいやつか!!

104 :87:03/06/09 01:33
>>96
> だってメインフレームからSolarisに乗り換えさせるためのJ2EEなんだから(w

いやまあそうなんだけどさ
自分の仕事しているところとかでは
sunがメインのプロジェクトってみたことないからさ

sun自体が
「メインフレームからハイエンドUNIX機にリプレースしましょう!!」とか客に提案するならまだしも
かなり大きいところでもそんな冒険はしたくないんじゃないかなと



105 :デフォルトの名無しさん:03/06/09 01:33
>>102
しかしというか、それが普通、という罠(w

106 :デフォルトの名無しさん:03/06/09 01:38
>>101 LinuxもSolarisと同じくUNIX陣営だからな。素人から見れば。
>>102 SUNはハードが売れればそれでいいと思ってるに1000ペリカ。
>>103 あれは中に人間が入ってるんだ。ちゃんと食事入れてやってくれ。
>>104 まあ不景気だからな。

107 :87:03/06/09 01:43
>>106
SunFireの中の人も大変だな

いや不景気っつーか
あそこら変まで行くとハード売って保守料とかでもうけたりする感じがあるから
sun自体がやらないと誰もがんばらないだろうね
ふつうのシステム屋がメインフレームを進めたりしないよね
結局ベンダーにもうけが行っちゃうから

日本ではその手の案件がないだけなのかもしれないが

108 :デフォルトの名無しさん:03/06/09 01:45
いや、以外とSunの戦略は実を結びつつあるんじゃないかと
思う今日この頃。
最初はJDBC、Servlet、JSPあたりであんまり信頼性要求が
高くないWebシステムを大企業に導入させて、それなりの
実績作っている。その上で、次のステップとして基幹に
入り込もうとしている状況が今何じゃないかな。
とはいっても、現行のEJBの仕様じゃまだまだ先の話のような
気がするんだけどね・・・

109 :デフォルトの名無しさん:03/06/09 01:55
何かすごい勢いでスレが伸びてるわけだが
>>11はある意味神だな(w

110 :デフォルトの名無しさん:03/06/09 01:56
>>106
こうやって大量レスかますのは
かまって君な >>1

111 :デフォルトの名無しさん:03/06/09 02:00
こうやってレスして>>1を喜ばせてあげるのは
かまってあげたい君な>>110

112 :デフォルトの名無しさん:03/06/09 02:37
もしや名スレ!?

113 :デフォルトの名無しさん:03/06/09 03:50
>>112
なるかモナー

114 :デフォルトの名無しさん:03/06/09 06:32
このスレいこごちいいな。

115 :デフォルトの名無しさん:03/06/09 10:38
>>90
perlのチャットはあまりにもおせーよ。
Servlet + Appletで動くチャットサイコー

>>92
.NETも大げさだね

116 :デフォルトの名無しさん:03/06/09 10:56
>>115
Perlだから遅いわけじゃないよ。UDP使えば何だって同程度にはなる。

それとな、Javaと比較するならC#だ。J2EEと.NETなら比較の対象だ。

.net と J2ee
http://pc2.2ch.net/test/read.cgi/tech/1045399051/l50


117 :教えてクン:03/06/09 17:44
J2EEってどんなことができるんですか?

118 :デフォルトの名無しさん:03/06/09 17:50
>>117
サーバーの膨大なリソースを使い果たすこと

119 :デフォルトの名無しさん:03/06/09 18:01
>>117
ますこのスレと、このスレにリンクされたJ2EE関連スレを全部読み返してください。

120 :教えてクソ:03/06/09 18:02
サーバの無駄遣いって意味で?
それとも、有効利用って意味で?

121 :デフォルトの名無しさん:03/06/09 18:05
>>120
だからスレを全部読んでから質問しろとってるだろ

122 :教えてクソ:03/06/09 18:09
>>120
ンジャ全部ヨム。

123 :デフォルトの名無しさん:03/06/09 19:06
J2EEは、乱暴な言い方をすると分散コンピューティングをするためにある、
とオライリーの本には書いてあった。

124 :デフォルトの名無しさん:03/06/09 19:20
J2EEはなんのために、あるかというと
みんなが各地で勝手にJ2EEのような仕組みをつくらないようにするためだ。

J2EEの一番のメリットは、それが仕様だということ。
標準化されているというこれ以上のありがたみはないよ。
いろんなアプリケーションサーバーを使用しているとマジに思うよ。

125 :デフォルトの名無しさん:03/06/09 20:16
アプサバ間の互換性はまったくないけど、J2EEという考え方があてはまるのはイイ!
互換性がないから作り直しがおおいけど、それでもイイ!

126 :デフォルトの名無しさん:03/06/09 23:09
漏れは、ゲイツが嫌いじゃ。
だからsunに走るのみ!

127 :デフォルトの名無しさん:03/06/09 23:18
>>126
正直、それは正しい選択かがなじょ

ゲイシ嫌いは別にカマワンカ・・・゙

128 :126:03/06/09 23:20
javaの技術を追求して、
漏れが、スンの明日を切り開く!
俺について来い(プッ

129 :デフォルトの名無しさん:03/06/09 23:27
>>122
なんて素直なやつなんだ。偉いぞ。

130 :デフォルトの名無しさん:03/06/10 13:25
>>122
みたいな奴が増えて欲しいもんだ・・・

131 :デフォルトの名無しさん:03/06/10 14:11
口だけだろ。

132 :デフォルトの名無しさん:03/06/10 16:19
>>131
なんて素直でないやつなんだ。酷いぞ。


133 :デフォルトの名無しさん:03/06/10 16:22
>>132
思ったことを素直に口にしてるんじゃないか。

134 :デフォルトの名無しさん:03/06/10 18:22
>>133そうか!なるほど!

>>131
なんて素直なやつなんだ。酷いぞ。


135 :デフォルトの名無しさん:03/06/10 21:37
>>131
みたいな奴が増えて欲しくないもんだ…

136 :デフォルトの名無しさん:03/06/10 21:51


   彡川川川三三三ミ〜
   川|川/  \|〜 プゥ〜ン
  ‖|‖ ◎---◎|〜        / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  川川‖    3  ヽ〜      < (*´д`*)ハァハァハァ
  川川    ∴)д(∴)〜       \_______________
  川川      〜 /〜 カタカタカタ
  川川‖    〜 /‖ _____
 川川川川___/‖  |  | ̄ ̄\ \ ←>>1-1000
   /       \__|  |    | ̄ ̄|
  /  \___      |  |    |__|
  | \      |つ   |__|__/ /
  /     ̄ ̄  | ̄ ̄ ̄ ̄|  〔 ̄ ̄〕
 |       | ̄


137 :デフォルトの名無しさん:03/06/10 23:13
J2EEでもっとも簡単な分野といえばなんだと思う?

漏れはJSPだと思う。


138 :デフォルトの名無しさん:03/06/10 23:14
JavaMail

139 :デフォルトの名無しさん:03/06/10 23:28
JDBC

140 :デフォルトの名無しさん:03/06/10 23:35
>>137
実装担当にとっては、EJBをインプリするのがいちばん簡単だろう。
設計担当には地獄だが。


141 :デフォルトの名無しさん:03/06/10 23:39
仕事で作るときの難しさか。
習得や慣れるにはそうもいかないような・・・。
初心者は、他人が作ったものが信用できなくて、
どうなっているのかドキュメントやソースコードを見ようと必死に
解析するのでは?

142 :デフォルトの名無しさん:03/06/10 23:50
> 初心者は、他人が作ったものが信用できなくて、
> どうなっているのかドキュメントやソースコードを見ようと必死に
>解析するのでは?

よくあるね。
せっかく実装とインタフェース分けてるのに実装クラスを見たがったり。

143 :デフォルトの名無しさん:03/06/11 00:07
>>142
ちょっとまて。それは初心者の特性なの???

おいらは良く、Jakartaのソースを読んで、変な場所があったらパッチ
提案してるけど…

144 :デフォルトの名無しさん:03/06/11 00:47
>>143
それはあなたが初心者だということでは?

145 :デフォルトの名無しさん:03/06/11 00:48
>>144
そうか、JakartaのCommiterは初心者なのね。リョウカイ。

146 :デフォルトの名無しさん:03/06/11 01:15
そりゃ初心者だな。確定。
次いってみよ〜

147 :デフォルトの名無しさん:03/06/11 02:24
>>138
そのjavamailの使い方というかやり方はどこを探せばよいと?


148 :デフォルトの名無しさん:03/06/11 02:32
>>147
そんぐらいぐぐれよな
http://java.sun.com/products/javamail/FAQ.html
http://java.sun.com/j2ee/1.3/docs/
http://java.sun.com/products/javamail/javamail-1_2.html

149 :デフォルトの名無しさん:03/06/11 02:34
ぐぐるよりもsun.comの検索使った方がはやいとおもうけど。

150 :デフォルトの名無しさん:03/06/11 02:53
interfaceを使っているからといってもオブジェクトの依存度が
低くなるとは限らない。
これは経験者なら痛いほどわかると思う。
それをモデリングする段階での完成度がモノをいうわけだが。
実装を見たがるのは仕方がない。

151 :_:03/06/11 03:06
http://homepage.mac.com/hiroyuki44/jaz02.html

152 :デフォルトの名無しさん:03/06/11 23:40
>>150
だね。抽象クラスのほうがよかったりね。

ここはデザインパターンやアーキテクチャパターンを学ぶしかないと。

J2EEぱたーんですか

153 :デフォルトの名無しさん:03/06/12 02:42
J2EEパターンてのは、性能上の理由から行われる、ぶっちゃけマヌケモデリング
ですよ。

ValueObjectだのSessionFacadeだの、オブジェクト指向のあるべき姿から
はかけはなれてますが、分散オブジェクトで性能出すためにはしかたないん
ですよ。

154 :デフォルトの名無しさん:03/06/12 21:46
>>153
君、EARレベルでのJ2EEアプリ書いたことないだろ?
各Tierにきちんとわけたアプリのデザインしたことないだろ?

SessionFacadeやValueObject(いまはTransferObjectっていう)は何も性能のためだけではないよ。
不必要な結合を減らすという意味では重要だよ。

155 :デフォルトの名無しさん:03/06/12 23:06
J2EEとApacheは連携できるんですか? 

156 :デフォルトの名無しさん:03/06/12 23:24
ここまで苦労するくらいなら、おとなしくTPモニタで
アプリケーション書いたほうがいいなあ。
苦労はたいしてかわらず、性能や信頼性はけた違い。
IMSとかCICSとかさ。
EJBがもうちょいこなれてからでいいよ。

157 :デフォルトの名無しさん:03/06/12 23:27
>>155
J2EEとは仕様や規格を指す用語だが?
もしかしたらJ2EE RIのことか?

158 :デフォルトの名無しさん:03/06/12 23:28
>>154
ウソツキ。少なくともValueObjectは便宜の一手段でしかないよ。
おいらは、性能要件によってはクライアント側にDelegateクラス
作って完全にラップしますよ。

159 :デフォルトの名無しさん:03/06/12 23:29
>>157
J2EEサーバのことでは?
Tomcatになぞらえていってるんだろうよ。

160 :デフォルトの名無しさん:03/06/12 23:31
>>159
J2EEサーバってなんだ?
J2EE RIのことか?
J2EE準拠のアプリサーバ製品全般のことを言っているのか?

161 :デフォルトの名無しさん:03/06/12 23:37
>>155
EJBサーバとHTTPサーバは、直接は関係無いな。

ServletからEJB呼ぶのは、良くやることで、別にかまわない。

162 :デフォルトの名無しさん:03/06/12 23:49
>>158
うそじゃないと思うけど・・・
ValueObjectは分散システムじゃなくても、Tier間や
サブシステム間で依存性を減らすのに有効な手段だよ。
オブジェクト指向的でないことは認めるけど、
オブジェクト指向のあるべき姿に向かって突き進むと、
大規模システムではクラス間の依存性が高すぎて
作業の分担ができないと思う。

163 :デフォルトの名無しさん:03/06/13 00:32
>>162
依存性をなくしたいだけなら、Mapのインスタンスでも投げあってればええんでわ。

164 :デフォルトの名無しさん:03/06/13 00:59
ValueObjectが有用なこと自体は言うまでも無いんだが。
シリアル通信の頃にも、オレ様プロトコルでメッセージフォーマットに従って
データ塊を投げ合っていたよ。通信コストの関係で。

通信コストのかからないローカルアプリケーションで階層化を行いたい場合に、
データ塊を投げ合うかと言えばそうじゃない。小さな単位でデータを交換しあう
のが普通だろ。dll間だって、class間だってそう。
関連性が密でないデータをまとめて送りあうなんて、通信コスト以外に何の
メリットがあるんだ?
疎結合を目指すなら、#163の言うようにmapを投げ合うしか無かろうが。

165 :デフォルトの名無しさん:03/06/13 01:23
>>164
J2EEの開発で、Servlet,JSPを担当するチームと、
ビジネスロジックを担当するチームで分けたりすることはない?
そいうった感じでチーム間でインターフェースの取り決めを
する必要がある時に、小さい単位でデータの交換しあっていると、
インターフェースがやたら増えて、折衝が大変になるでしょ。
だから、インターフェースをなるべく少なくして、
一つのメソッドでなるべく多くのデータを渡したいことって
あると思うんだけど。
ビジネスロジック担当側で作った、複雑な階層構造を持った、
小さなオブジェクトをそのままServlet側に渡していたら、
インターフェースの変更の影響が大きすぎて収集がつかなくなるんじゃない?


166 :デフォルトの名無しさん:03/06/13 01:30
あと、MapをやりとりするのとValueObjectをやりとりすることに、
そんなに差があるか?
Mapなら、確かにクライアント側が型を知らなくていいという
メリットはあるけど、KeyとValueをお互いで取り決めしとかなきゃならないし、
コンパイルによるチェックが入らないしで、
大変さはそれほどかわりないような気がするが。
変更が入ったら、どちらもリコンパイルしなきゃならんのは同じだし。

167 :デフォルトの名無しさん:03/06/13 01:48
>>164
EJBでインターフェイス定義を配布しないのか?どんな開発してんだ?
それに、「インターフェイスの数を減らすため」に、余計なものも纏
めて送るなんて、まともじゃないぞ。
>>165
Mapでリコンパイルが必要になるってのはどういうことだ?

どうも、あんたの職場がカタワバカのにおいがするな。

168 :デフォルトの名無しさん:03/06/13 02:04
>>167
何故にそう、煽り口調で話すのかね・・・
普通に議論できないの?まあ、いいや。2ちゃんだし。

>EJBでインターフェイス定義を配布しないのか?どんな開発してんだ?
そもそも分散システムじゃないときに、
ValueObjectが価値があるかどうかっていう話をしているわけで、
EJBを何故ここで持ち出すのかよく分からない。
多人数でシステム開発する時は、なるべくインターフェースが
少なくなるようにするのが鉄則だと思っていたんだけど、
あんたの職場では違うのか?他の人たちはどうよ?

あと、Mapでもリコンパイルが必要になるっていうのは勘違い。スマソ。
リコンパイル不要の場合もあるわな。
でも、普通Mapで渡すデータが変更されたら、
受け側のプログラムも変更しないといかんだろ。

169 :デフォルトの名無しさん:03/06/13 08:38
XMLでやりゃあいいじゃん。

170 :デフォルトの名無しさん:03/06/13 21:12
>>156
EJBはIMSやCICSより信頼性がけた違いに落ちるのか?
その程度のものなのか。。。

171 :名無し@沢村:03/06/13 22:05
J2SEの間違いだろ?

172 :デフォルトの名無しさん:03/06/15 12:11
半年前の沢村はJavaをあまり触ったことがないと聞いたが。

173 :デフォルトの名無しさん:03/06/15 19:12
>>168
そんなこといったら、もっとも優秀なインターフェイスは

interface GeneralInterface{
Object invoke(Object target,Object[] param);
}

ってことか?
おいおい、見通しがよくなるのに必要なだけのインターフェイスを
作るのが鉄則ですよ。アプリケーション開発のレイヤーでこんな
インターフェイスしか定義していないプロジェクトがあったら、
設計者を張ったおすけどな。

174 :デフォルトの名無しさん:03/06/15 20:41
>>173
「少なく」って漠然と書いてしまったから誤解されてしまったようですが、
俺が言っている、「インターフェースを少なく」っていうのは、
1個のユースケースについて1〜3個くらいのインターフェース、
くらいの意味合いです。
依存関係を減らすために一枚ファサードかまして、
クライアント側が直接Modelを操作しないよう、
やりとりするデータはValueObjectで値渡しにするっていうイメージ。
そういう意味で、ValueObjectもMapもXMLも、データのやりとりを
値渡しにして、依存関係を減らすと言う意味で、
あんまり違いを感じません。

175 :デフォルトの名無しさん:03/06/16 01:00
>>174
だから、サーバーからクライアントにVOを投げるんじゃなくて、
クライアントにサーバのプロキシを置くという解決法もあるでし
ょがって前から言ってんだけど。IBMのDW逝ってBusinessDeleg
ateで検索掛けてくれ。

あと、VOを否定しているわけじゃ全然ない。「便宜」の仕様で
あって設計上の理想じゃないっていってるだけなんだが。

176 :デフォルトの名無しさん:03/06/16 01:34
最近はValueObject(VO)じゃなくて、
DataTransferObject(DTO)って言うらしいけど、
いったい誰が定義してるんだろうね。


177 :デフォルトの名無しさん:03/06/16 18:56
オブジェクトの内容が
Stringとかintの場合、
VOの変わりに、JMSでメッセージ駆動型Beanに処理してもらうやり方は
バカですか?
いまいち、どこでメッセージ駆動型Beanを使っていいのかわからないもので・・・

178 :デフォルトの名無しさん:03/06/16 19:02
☆セクシー画像を生クリック☆(閲覧無料)
http://endou.kir.jp/moe/linkvp.html

179 :デフォルトの名無しさん:03/06/16 22:23
>>177
原因と結果に関連がないが、何でそんなことをするのだね。

180 :デフォルトの名無しさん:03/06/16 22:49
>>175
読んでみたよ。ここであってる?
http://www-6.ibm.com/jp/developerworks/java/030110/j_j-ejb1022.html

で、BusinessDelegateパターンってメソッドの引数、戻り値に
VO使わないのですか?

181 :デフォルトの名無しさん:03/06/16 23:06
>>180
最早データのキャッシュがクライアントにあるので、VOもヘッタクレ
もないでそ。プロキシ<>EJBサーバ間でVO使って通信しているかも
しれんが、そんなことはクライアントの知ったことじゃない(隠蔽され
ている)っていう構造だよん。

182 :181:03/06/16 23:13
そういう構造になっていれば、クライアントサイドのプロキシが細粒度のアクセサ
持っていても何の問題もない。という話。
時と場合によってはいい方法だけど、時と場合によってはダメダメ。



183 :デフォルトの名無しさん:03/06/16 23:38
>>181
うーん、ちょっと考えてみたのですけど、
VOを直にクライアントに渡して、そのアクセサ呼んでもらうのに比べて、
プロキシにアクセサもたすことにどういうメリットがあるのでしょうか。
教えてクンで申し訳ないが、もう少し教えてくらさい。

184 :デフォルトの名無しさん:03/06/17 00:23
>>183
メリットは2つでしょう。
1.EJB開発者とServlet開発者を分けられる。
 プロキシにEJBの通信部分(lookup、RemoteExceptionの処理)を隠蔽することでクライアントは裏にEJBがあることを
 意識しなくて済む。下手するとEJBにアクセスせずにキャッシュデータを返却することも可能。
 (プロキシはEJB開発者が提供)

2.EJBが完成されなくても、プロキシをスタブとすることで試験が可能。


185 :デフォルトの名無しさん:03/06/17 00:33
>>184
いや、質問の意図はそうではなくて、
BusinessDelegateを使用した場合、プロキシに定義するインターフェースと
してVOをそのまま返すメソッドを提供するのに比べて、
プロキシ内部にVOをキャッシュしておいて、
プロキシ自体に細かい粒度のアクセサを用意する
>>182はそういう意味で捉えていたのだけど、間違っている?)
ことのメリットが何かを知りたいのです。

186 :デフォルトの名無しさん:03/06/17 00:39
>>185
VOの存在を隠蔽できるのはメリットじゃないのかね。
毎回VOのサイズの、本来必要ないデータもくっついたカタマリデータを
毎回サーバから呼び出すより、好き勝手にキャッシュできる分効率いい
こともあるでしょ。

187 :186:03/06/17 00:45
VOの場合は、そのVOが持つ値を何時まで使いまわすかは、クライアントの
実装者の責任になってまう。クライアントサイドプロキシなら、プロキシ
実装者(おそらくサーバーサイド実装者の責任範囲)がコントロールできるな。

188 :デフォルトの名無しさん:03/06/17 01:00
>>186,187
うーん、それがメリットだと感じられるのが、俺にはどうしてもわからない。
どうせキャッシュしているのなら、VO丸ごと返した方が、
プロキシのインターフェースも少なくて済むし、
同じようなアクセサ(VOにも定義するよね)をあちこちに
書かなくても済むと思うんだけど。
あと、VOの値をいつまで使い回すかっていう話も、
プロキシが返すのが値のコピーである以上は、
プロキシ実装者がコントロールできるなんてことはありえないと
思うのだが。

といいつつも、なんか不毛な議論になりつつあるような気がするので、
面倒だったら答えなくていいよ。俺もそろそろ寝ます。

189 :デフォルトの名無しさん:03/06/17 01:06
>プロキシが返すのが値のコピーである以上は、
>プロキシ実装者がコントロールできるなんてことはありえないと
>思うのだが。

IBM DWの記事をいろいろ読め。賢い人たちがいろいろ挑戦しとるがな。


190 :デフォルトの名無しさん:03/06/17 01:11
>>189
はい、読んでみます。
質問につきあってくれてありがと。おやすみ。

191 :186=189:03/06/17 01:14
よくよく考えると、なんか折れ他人のふんどしオンリーで偉そうだな。
鬱打詩嚢…

192 :java入り口:03/06/19 02:00
オウゥ、J2EE系のアルバイトにまわされることになった(ツユダク

J2SEとどう違うか教えてくれ、たのむ!

できれば、どんな本を買えばよいか教えてくれ!

漏れはjava暦は2ヶ月だ!大体の内容は把握してるつもりなんだー

193 :デフォルトの名無しさん:03/06/19 02:12
>>192
J2EEはおおざっぱに言うとWebシステムを組むためのAPI群。
覚えるべきAPIや技術がたくさんある。
他言語でもWeb系のプログラム組んだことある?
無いとクッキーやHTTPの仕組みとかセッション管理の概念もわからないと思うから苦労するかも。
・Servlet
・JSP
・JavaBeans
・EJB(5種類ある)
・JavaMail
・JMS
・JAXP
・JCA
・JTA
・JNDI
標準技術だけをざっと挙げてもこんな感じ。
あとはJakartaプロジェクト関連のライブラリとか
アプリケーションサーバの製品固有の使い方とか

194 :デフォルトの名無しさん:03/06/19 02:23
>>192
アルバイトとはいえ、そんな状態で仕事できるのか・・・
いや、煽りじゃなくて・・・
プログラマって意外といいかげんでも出来るんだろか・・・
助けてくれる人がいれば何とかなるのか・・・・
おれ、プロじゃないんでその辺のことわからんけどさ

195 :デフォルトの名無しさん:03/06/19 05:42
なる

業界はアホであふれかえっている
実質、多少インテリな事務仕事

196 :192:03/06/19 17:04
>>193
Web系のプログラムはRubyで組もうとしてた矢先だったんだ。
だからぜんぜん組んだことが無い。<HTMLでHPならけっこう作った。
最初は教育をうけさせるって事になってるらしいけど・・
漏れは覚えが遅いから今のうちから努力を。
その単語を一つ一つくぐって把握していくことにする。
レスサンクス!
>>194
すまん、頑張りを期待されたなりゆきなんだ・・・。
基本情報とソフ開の資格はもってるから、基礎はあると認識されたんだろうな。
早く身に付けて役に立つ人材になってみせる。
>>195
なるべくアホと呼ばれないように努力するよ。

197 :デフォルトの名無しさん:03/06/19 20:56
なにげに192はいいやつ。教えて上げたくなるな。

198 :デフォルトの名無しさん:03/06/19 21:48
>>197
「全然」(真田広之風に)

199 :デフォルトの名無しさん:03/06/19 21:55
素直なヤツは得すると思うぞ。
裏切られることもあるだろうが。

200 :デフォルトの名無しさん:03/06/19 22:05
>>192
へっへっへっへ・・・


201 :デフォルトの名無しさん:03/06/20 21:30
推薦図書スレで聞いたんですがレスがつかなかったので、
ここで重複質問させて下さい。

J2EEについて勉強しなくてはならなくなりました。
自分JAVAは一応結城浩のJava言語プログラミングレッスン上下を読了してます。
サーバサイドの基礎も無く非常に弱っております。
それくらいのレベルの人間がまぁがんばりながら勉強できるJ2EEの本て無いですか?
自分的には

何せタイトルに惹かれて
EJB・Servlet・JSP わかりやすいJ2EEのしくみ
http://www.amazon.co.jp/exec/obidos/ASIN/4883731650/qid=1055869791/sr=1-5/ref=sr_1_2_5/249-8553102-3707562

これが一番かなぁと思ってるんだけど、
某所でJSPから入るのが楽だと読んだので躊躇。EJBから入ってます。
J2EEチュートリアル??The Java series
http://www.amazon.co.jp/exec/obidos/ASIN/4894716917/qid=1055869791/sr=1-8/ref=sr_1_2_8/249-8553102-3707562

装丁がイカスってだけでこれも。
標準J2EEテクノロジー〈1〉基礎から学ぶEJB??Super Java Books
http://www.amazon.co.jp/exec/obidos/ASIN/4798103780/qid=1055869836/sr=1-19/ref=sr_1_2_19/249-8553102-3707562

の三点。
それとも
http://www.atmarkit.co.jp/fjava/rensai/index/index.html
ここら辺でことは足りるのでしょうか?ご教授願います。

192への援護射撃になるか?

202 :デフォルトの名無しさん:03/06/20 22:37
>>192
>>201

難しいよなあ。

新人がJSPやServletの開発にまわされることも多いが、
それはフレームワークなり設計・開発手法のお膳立てが用意された上で作業ができるから。

Javaの範囲の効率化、Webアプリとしての効率化だけでもあらゆる手法がある。
Web層の範囲の効率化手法が、Web層+EJB層をターゲットにした場合にはそれが使えないこともある。
またWeb経由サーバサイドアプリとしての設計手法も存在する。

勘所を分かっている人間ならば、最初からターゲットをもとにした設計や開発を行える。
しかし>>192>>201のような感じなら、試行錯誤にならざるを得ない。

アサインされたのが勉強プロジェクト(=時間に余裕があってやり直しが効く)であることを祈る。
タイトなスケジュールであったり、事前の検証期間を確保できないような場合は……合掌でございます。
スレ上では応援するぞ。がんがれ。

まずは時間が許す限り濫読しろ。
あふれるくらいに知識を詰め込んで、実装作業で整理しろ。





203 :デフォルトの名無しさん:03/06/20 22:43
そうこうしているうちに、J2EE 1.4の足音がヒタヒタと、、、。
勉強には切りがないね。

204 :192:03/06/22 16:15
>>193-203ありがとうございます。
くぐりながら。
大まかな概要はわかってきた気がします。
あとは、>>201さんのお勧めの本を買って、
スキルを磨きつつアルバイトに備えることにします。
では、今から本屋へ。

205 :デフォルトの名無しさん:03/07/01 01:03
>204
藻前イイヤツ
age

206 :デフォルトの名無しさん:03/07/17 16:51
このスレいこごちいいな。

207 :_:03/07/17 16:58
http://homepage.mac.com/hiroyuki44/

208 :山崎 渉:03/08/02 02:35
(^^)

209 :山崎 渉:03/08/15 17:10
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

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

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

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)