EJB(初心者歓迎）
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGかなり複雑です。
そこでマッタリとEJBを語りましょう。
特にプログラミング技法など）
0652デフォルトの名無しさん
NGNGたとえば、東京に商品データベースがあり、大阪に在庫データーベース
がある、このように資源を分散させて配置したデータベースに対し
双方更新をかけ、コミットすることを２フェーズコミットと言うようです。
以前はこの処理をミドルウェアを使い実現していたが、EJBはこのトランザクション
の整合性をプログラムで意識せずに実装できる・・・
EJBのメリットとしてこのような事をよく効くが、本当かな？
まずデータベースの分散配置（負荷分散ではない）のメリットがよく
わからない。
0653デフォルトの名無しさん
NGNG一つのトランザクションで、2つ以上のDBを更新するときに、
全ての更新処理を纏めてトランザクショナルに扱う為の方法。
こういうときは気をつけないと、片方だけ更新して片方は更新
していないというような、ACIDに違反した状態になってしまう
わけで。
具体的な処理の流れは、ぐぐったほうがはやいかも。
0654デフォルトの名無しさん
NGNGデータベースの分散配置にメリットなんかないさ。
単に、今あるシステムで使っているデータベースが、たまたまそう
なっている時に、その上で新しいシステムを作るバヤイはどうする
かとか、そういう後ろ向きの話しだと思われ。既存システムに対する
派生開発ですね。
0655デフォルトの名無しさん
NGNG斬新だ。
0656デフォルトの名無しさん
NGNGDB分散んのメリットについてかたってくれ。
これが理解できないとEJBの真のメリットは理解できないと思う。
0658デフォルトの名無しさん
NGNGそうだ！そうだ！
0659デフォルトの名無しさん
NGNG一例だが、顧客、職員、経理、評価、会計、各部門といった具合に。
全てのデータを同一ノードで管理するのか？
部門ごとにサーバを立て、各サーバで管理するデータは切り離す。
もちろん、データを切り離す事が先ではなく、部門の切り分け、
ユースケースの抽出、そしてオブジェクトの配置と同時進行。
データを分散する事がまずあるのではなく、モデリングを進めていけば、
各部門で保持すべきインスタンスは自然と精査されていく。
分散ありきではなく、分散するしかなくなる。
0661デフォルトの名無しさん
NGNG後数年もすればバカでも後悔する
何でも正当化するな(#ﾟДﾟ)ｺﾞﾙｧ!!
0662デフォルトの名無しさん
NGNG0663654
NGNGEJBがローカルインターフェイスを採用した理由考えたことあるか？
無駄な分散=システム稼動時のオーバーヘッド。
抽象的に分けたものに対して、物理的な対応を必ず一対一に取る
なんて、バカじゃないの。
0664デフォルトの名無しさん
NGNG漏れのところも同じ状況。俺様わけわかでホスト間通信ライブラリを
作った香具師が、今ではその根本のミドルウェアを作ってるかのように話が大きくなってる。
もう神扱い。
0665デフォルトの名無しさん
NGNGここでインスタンスといったのはDBに限らない。
それから、まず、部門ごとの独立性を確保するには、
各部門（サーバ）を同一インスタンスで管理するわけにはいかない。
サーバは物理的にどこにおかれるかは分からないし、
物理的な位置を意識しないといけない設計にするわけにもいかない。
0666デフォルトの名無しさん
NGNGは理解できなかった。
もうやめるよ。
＞後数年もすればバカでも後悔する
後数年もすればEJBをプログラマーが意識する必要がなくなる気がする。
勉強するだけ無駄。
0668デフォルトの名無しさん
NGNG技術的なことがわからないＳＥが設計すると、
保証されていることさえもＤＢにぶち込む。あげくパフォーマンスがどうとか。
バカ抜かせと小一時間。
0669651
NGNG俺と同じところで働いているかモナー。
でも、世の中のいたるところで、こういう「開発資源の浪費」が
行われているというのが真実かもな。全くばかばかしいことで。
神扱いの奴本人以外の全ての人間にとっての、厄介の種だよな。
0670デフォルトの名無しさん
NGNGそもそも漏れにはホストの存在意義すらわからなくなってきた。
0671デフォルトの名無しさん
NGNG>後数年もすればEJBをプログラマーが意識する必要がなくなる気がする。
そんなこと言っているようじゃ、たいしたプログラマーになれないぞ。
Javaをかなりやっている様に言っているが、机で勉強しただけじゃメリット
なんか分からないだろ。
0672デフォルトの名無しさん
NGNGこの汎用異臭騒ぎオヤジめが。
0673デフォルトの名無しさん
NGNGすいません。666は既にjavaのSEです。
ちなみにEJBでシステムは何度も作ったことがあります。
ただ「メリット」について理解できないと言っているの。
0674671
NGNGEJBのどこがだめなんだ？
おれは有効に使っているけど。
0675デフォルトの名無しさん
NGNG製作者がメリットを感じることって少ないと思うぞ。
不便だと感じるだろうと思われ。
その不便さと、公知のほぼ標準化された仕組みを利用している
ことによる保守、改変作業の容易さのトレードオフかと。
0676デフォルトの名無しさん
NGNG何度も作ったはいいが、過去に構築したシステムの現状は把握してんの？
最初から最後まで見ないことには真のメリットやデメリットは見えないよ。
作り投げは簡単だからね。
0677デフォルトの名無しさん
NGNGおれも、あなたも問題ないさ。
ただ周りの反応はどうだ。嫌がられてないか？
おれはこれからSEとしてEJBをつかわないで
（JDBC経由）でシステムを作ることを提案するよ
0678デフォルトの名無しさん
NGNGJDBC経由が淘汰されゆく運命にあることを、どこかの記事で見たのだが。
0679デフォルトの名無しさん
NGNG0680デフォルトの名無しさん
NGNG別に嫌がってないよ。
俺はこれからもＥＪＢでシステムを提案していくよ。
EJBデザインパターンでも読んでから、もう一度考え直した方が
良いと思うが。
0681デフォルトの名無しさん
NGNG0682デフォルトの名無しさん
NGNG>>その不便さと、公知のほぼ標準化された仕組みを利用している
>>ことによる保守、改変作業の容易さのトレードオフかと。
これは大嘘！！
現状のjava開発の現場では、このスレで意見を交わせるほど、java
の技術者があつまるか？
0683デフォルトの名無しさん
NGNG居るところには居る。
で、議論大好きなのね、みんな。
それでいて誰も「これでいく！」と断言しないってな感じで（ｗ
0684デフォルトの名無しさん
NGNG周りは昔ながらの開発プロセスを信じてる香具師のみ。
JavaのシステムのはずだけどやってることはCと変わりない。
ＯＯも話題にならない。
３年以上前のシステムで、MVCなんだけどその思想も崩れつつあります。
誰かJava技術者を集めてください。
0685デフォルトの名無しさん
NGNG0686デフォルトの名無しさん
NGNGCORBAだと、>>684の悩みがあっというまに吹き出す可能性が高い。
＞MVCなんだけどその思想も崩れつつあります。
で、自前のFWを準備することになるが、EJB程の完成度は望めない。
0687デフォルトの名無しさん
NGNG数年後を考えてみませう。
因みに5年前、Javaはおもちゃ同然の糞と、多くの
セクト主義はびこる日本人技術者に蔑まれていました。
0688デフォルトの名無しさん
NGNGあなたはプログラムが趣味でしょ。
ビジネス的な思考でシステム開発している人はEJBを
>>おれは有効に使っているけど。
なんて発言でないと思うけど。
0689デフォルトの名無しさん
NGNGメンテやってるのですか？メンテ要員ってデキナイ君の配置＋神１人（障害時のみ）
配置されることが多いから思想なんてぐちゃぐちゃに掻き回される。
私が過去に携わったシステムで、４年後に再度見ることになったのだが・・・・
実装レベルで見直すと酷い物でした。
0690デフォルトの名無しさん
NGNG書いた後に何か言われそうだとは思ったけど、なんでそう思うのかを
説明してくれないかな。
ちなみに仕事以外でプログラムはしません。
0691デフォルトの名無しさん
NGNG香具師は多いと思う。
モジュールレベルでいい感じに作られてたのに、一人のプログラマのせいで
それがぐっちゃんこにされてしまう事もあるし。
人選びは重要だけど、自社の人員資源ではもう無理！って感じる人は多いと思う。
0692デフォルトの名無しさん
NGNGEJBで開発するのと単にJDBC経由で開発するので
技術者のスキルも、かかる工数も大幅に変わってくる。
開発での採算が合わなくなる。
EJBもJDBCもユーザーからすればどうでもいい話。
ならば、やすくシステム作るように提案したほうが
現場から喜ばれるでしょ。
0693デフォルトの名無しさん
NGNG似たような経験あるな。
確かにJAVAだが、そりゃねぇだろおいみたいな。
0694デフォルトの名無しさん
NGNG>>居るところには居る。
ならばあなたの意見
>>その不便さと、公知のほぼ標準化された仕組みを利用している
>>ことによる保守、改変作業の容易さのトレードオフかと。
はやっぱり大嘘！！
0695デフォルトの名無しさん
NGNG確かにユーザからしたらどっちでもいい話ではあるが、工数が大幅に変わる
というのはEJBを使うと工数が大幅に増えると言っているの？
そんなこと全然ないよ。
今やっているプロジェクトはjava初心者もいるけど、EJBでやっているよ。
ステートレスセッションBeanでEJB Commandパターン使っているから、EJB
を使っているということを意識していないと思うけど。
rollback、commit書かなくて済むから現場も喜んでいるよ。
0696デフォルトの名無しさん
NGNG0697デフォルトの名無しさん
NGNGごく基本的なことをわかっていない人がいるようで。
生RMIやCORBAでガリガリ、あるいはソケット直でゴリゴリやる
より100倍楽。
0698デフォルトの名無しさん
NGNG>>683だが、>>675にあらず。
0699デフォルトの名無しさん
NGNG既にEJB開発のためのフレームワークを開発したのですね。
0700デフォルトの名無しさん
NGNG設計者には面白いかもしれんが。
0701デフォルトの名無しさん
NGNGエンドユーザーが技術についてどうでもいいことくらいは、言わなくても誰もが認知済みでしょう。
少なくとも情シス部門は保守まで考えた視点で、どの技術を用いるかの決断はする。
やすく提案して、エンドユーザーに喜ばれた事例ってあるんですか？
部長クラスには喜ばれるだろうが、エンドユーザーはＵＩ以外で喜びませんよ。
0702デフォルトの名無しさん
NGNGだれも兄貴との性交イベント発生しないのだが？
これって不良品？
コンプしたら発生する？
0703デフォルトの名無しさん
NGNG口出してくるエンドユーザーもいるけど。
0704デフォルトの名無しさん
NGNG>>生RMIやCORBAでガリガリ、あるいはソケット直でゴリゴリやる
こんな需要ないね。
需要がないのに
>>どうも、EJBは面倒くさいことを簡単にしてくれているという
>>ごく基本的なことをわかっていない人がいるようで。
この意味は理解できない。
0705デフォルトの名無しさん
NGNG開発と言えるほどのことじゃなくて、EJBデザインパターンという本を
丸写ししただけのものです。
0706デフォルトの名無しさん
NGNGあるよ。少なくともCORBAは。
「普通の」ってどういう基準で言ってるのかわからんけど、
分散オブジェクトの技術としてはEJBもCORBAも同じ。
CORBAでもAPサーバを利用すれば随分プログラミングが楽になる。
もちろん、APサーバ依存になってしまうが。
0707デフォルトの名無しさん
NGNG上記文章で、何を言いたいのかは俺自信わからないわけだが。
0708デフォルトの名無しさん
NGNGエンドユーザーに喜ばれたとは書いてないですよ。
開発会社が利益が出て喜ぶでしょ。
0709デフォルトの名無しさん
NGNGおいおい、プロセス間通信を必要としない仕組みは、そもそもEJBの
適用範囲外だが。
0710デフォルトの名無しさん
NGNGその依存ってやつがどうしても嫌でしょうがない。
根本の仕様を押えておけば苦にならないだろうけど、
初学者にとってベンダ独自仕様は邪魔以外の何者でもない。
0711デフォルトの名無しさん
NGNG0712デフォルトの名無しさん
NGNG分散オブジェクトでなければ開発できないシステムの規模や条件について
具体的に説明してくれれば理解できるのですが。
0713デフォルトの名無しさん
NGNG＞初学者にとってベンダ独自仕様は邪魔以外の何者でもない。
それは、EJBやCORBAに限らずだね。
0714デフォルトの名無しさん
NGNGJDBCだって、DBとJDBCドライバに依存しますが。
0715デフォルトの名無しさん
NGNGXML-APIだってXerces/Xalanつかうか(以下略
0716デフォルトの名無しさん
NGNG依存部分もよく理解すればjavaのインターフェース内で処理できる場合が多い。
0717デフォルトの名無しさん
NGNG無いとは言わないが。
0718デフォルトの名無しさん
NGNG0719デフォルトの名無しさん
NGNG依存してねーだろ。もしかしてSQLのこと言ってんの？ﾌﾟ
0720デフォルトの名無しさん
NGNG第３者だけど。依存している部分はあるよ。
BLOBデータのあつかいとか。
0721デフォルトの名無しさん
NGNGあ、そうでした。いきがってスンマソン
0722デフォルトの名無しさん
NGNGｵｲｵｲ,夜中に付き合ってみたら、要するにど素人かよ…
JDBCの各インターフェイスに対して、機能が全て実装されているとは限らんよ。
ドライバの実装依存。幾つかの機能は、そもそもDBが持ってないから実装されない
こともある。即ちDB依存。
0723デフォルトの名無しさん
NGNGうろ覚え。
0724デフォルトの名無しさん
NGNG0725デフォルトの名無しさん
NGNG何ができるようになるんでしょうか？
皆さんがEJBを使って目指すものって何ですか？
0726デフォルトの名無しさん
NGNGEJBをサポートするアプリケーションサーバを使えば、
分散オブジェクトで作るシステムを(ﾏｯｻﾗから自作するよりは)
簡単に作れる。
分散オブジェクト自体がイロイロ面倒なので、ボタン一つでポイ
というほど簡単ではないですが。
0727デフォルトの名無しさん
NGNGお決まりのHelloWorldをリモートメソッド呼び出しによりやってみたが、
うまく動作しない。サンプルコードを動かすだけでこの手順は複雑すぎ。
これだけ時間かけてHelloWorldはないだろ。。。
で、いくつか思ったことがあったんだけど、スタブとスケルトンって沢山できない？
サンプルレベルなら１組でいいだろうけど。
0728727
NGNG外部ツールとかに割り当てて試してはみたけど、これまたうまく動作しないどころか
まったく反応なし。
0729デフォルトの名無しさん
NGNG全ての通信手順を一つのやり方に出来るので、規模が小さい時は不便なだけだ
けど、規模が大きくなってくると便利だよ。
でもって、EJBはRMIスタブとスケルトンの存在もラップして、もうちょっと抽
象度の高いレベルにしてくれているので、もっと便利。というだけの話。
0730デフォルトの名無しさん
NGNGAntにしたら？タスクあるから。
0731デフォルトの名無しさん
NGNG//127.0.0.1:1099/ほげほげ
片方のVMにレジストしたらいいのかな。試してみよ。
0732デフォルトの名無しさん
NGNGインターフェースなので当たり前ですが、
一度作成したスタブ・スケルトンはリモートメソッドの追加等がない限り、再コンパイルの必要なし。
ってのはちょっと感動した。なにせ初学者なもので・・・。
0733デフォルトの名無しさん
NGNG？エクスポートしてレジストリにバインドすれば、VMまたいでコールできるの
がRMIでっしゃろ？
レジストリへのバインドも、レジストリサーバに対する登録依頼のプロセス間
通信。レジストリサーバが、そのURLのドメイン部分で持ってこれる場所にｱﾚﾊﾞ
ｲｲだけっス。
0734デフォルトの名無しさん
NGNGなぜでしょうか？
私の認識ではEJBの持つ下記の性質のためだと思っていますが、
間違っていたらご指摘してください。
アベイラビリティ → 位置透過性（クラスタ対応＋CMT）
スケーラビリティ → 位置透過性（リモート呼び出し）
EJBを本当に使う必要があるのか迷っています。
またエンティティBeanは実際の業務ＡＰで皆さん使われてますか？
私の意見としては更新系にしかエンティティBeanは使えないと思っています。
使っている方はテーブルとエンティティBeanをどのようにマッピングしているのでしょうか？
CMP＋CMRを使ってテーブル：エンティティBean=１：１で対応させているのでしょうか？
業務ＡＰでＥＪＢを開発した方の意見をお願いします！
0735デフォルトの名無しさん
NGNG通常のClassでJDBCでがちがち書いた方が良さそうな気がしますが、
どうなのでしょう？
JSP、Servlet、セッションBeanはまず使わないだろうし。
エンティティBean、MessageDrivenBeanは使われていたりするのでしょうか？
一括更新だからメモリを食って効率も割るそうですなぁ・・・
0736デフォルトの名無しさん
NGNG漏れのところはJDBCでがちがち書いてる。
バッチでJ2EE使ったら許容時間超えそうで怖い。
といいますか、バッチのような単純処理にJ2EEを使うメリットありますか？
0737735
NGNG回答どうもです！
私としてはバッチでJ2EEを使うメリットを下記のように考えましたが、
エンティティBean
→ １．トランザクション自動制御
２．エンティティBeanのオンラインとの共有化
やはりエンティティBeanでは性能を考えると辛いような気がします。
0738デフォルトの名無しさん
NGNGもう少し具体的な説明頼む（何をするか
0739735
NGNGなぜバッチかというと現状Cで作成したバッチ処理を
Java（J2EE）で実装した場合どのようになるかを検討しています。
バッチ処理の内容としてはDBの一括更新＋CSVファイルの作成です。
説明不足で申し訳ありません。
0740デフォルトの名無しさん
NGNG最初は、JNIコールでやって、徐々にJavaに移行したら？
0741デフォルトの名無しさん
NGNG>トランザクション自動制御
整合性で同期とるのはダメなの？
0742デフォルトの名無しさん
NGNGおそらく２つの手法があると思っています。
どちらのパターンが推奨されるのでしょうか？
メリットは私の推測ですが間違っていたらご指摘してください。
１．APPLET→Servlet→EJB
メリット：ファイヤウォールを越えられる
２．APPLET→EJB
メリット：速度が速い、コーディング量が減る。
0743デフォルトの名無しさん
NGNGEJBをもう少し理解された方がよろしいかと思います。
0745デフォルトの名無しさん
NGNG間違いなく１でしょう。
セキュリティから考えてみてもIIOPなどのポートをインターネットに公開すべきではありません。
>２．APPLET→EJB
> メリット：速度が速い、コーディング量が減る。
コーディング量は減りますが速度が速くなるとは限りません。
サーブレットと通信するモデルは結果だけやり取りすれば良いので通信量を減らすことが出来ますが、
直接EJBを扱う場合は、IIOPなどのオーバヘッド、スタブのシリアライズ、デシリアライズやセキュリティの確認のための通信が
発生するため、かなりの通信量が発生します。
EJBの分散機能はノードがかなり近くにある状況で利用するのが、よりと思います。
0746デフォルトの名無しさん
NGNGどなたか734に対して意見をいただけませんか？
0747デフォルトの名無しさん
NGNG通常はフレームワークを使わないと品質がまばらになってかなり辛いと思うのですが、
実際はどうなんでしょうか？
あと、フレームワークはいろいろ調べてみたところcFrameworkが良さそうですが、
実際どうなんでしょう？
実際のプロジェクトで使われている方の意見が聞きたいです。
cFrameworkで非同期や会話型のAPは作れますか？
0748デフォルトの名無しさん
NGNG非同期も会話型も無理だろう。
0749デフォルトの名無しさん
NGNGということはオンライン同期処理しかできないということですか？
0750デフォルトの名無しさん
NGNG１００件ずつくらい分けてHTMLに出力するというのが一般のやり方だと思っていますが、
その実装方式って皆さんどうされてますか？（どこでそのデータを保持していますか？
）
StatefulSessionBeanを使われてますか？
HttpSessionで処理されてますか？
個人的には「StatelessSessionBean」＋「HttpSesion」の方が
メモリが消費されずに済むので良いと思っています。
0751デフォルトの名無しさん
NGNG■ このスレッドは過去ログ倉庫に格納されています