EJB(初心者歓迎） ２

1000を超えたので、新たにスレたてました。

EJBを勉強しています。
かなり複雑です。
そこでマッタリとEJBを語りましょう。
特にプログラミング技法など）

前スレ
http://pc2.2ch.net/test/read.cgi/tech/1017240849/

2GET

また初心者歓迎かよ(;´Д`)

前スレで ejb-client.jar を知りたがってたやつのために一肌脱ぐ。

EJB は Home インタフェース、コンポーネントインタフェース、実装 Bean クラスで構成されている。
前 2 つのインタフェースは、EJB を呼び出すときにソースコードに書く必要がある。
逆に実装 Bean クラスの呼び出しは EJB コンテナが自動生成するクラスが行うから書く必要がない。
つまり、EJB の利用側には前 2 つのインタフェースさえクラスパス上に存在すればよい。

じゃあ次に、インタフェースのメソッドシグネチャについて考える。
たとえば、価格を計算して PriceInfo クラスを返す EJB のメソッド calculate があるとする。
お金じゃ買えない価値がある場合には PricelessException をスローする。
　public PriceInfo calculate() throws PricelessException
これを使うには、クラスパスに PriceInfo クラスや PricelessException も必要になる。

EJB コンテナと Servlet コンテナは、異なるクラスローダを持つ。
加えて、Web アプリも独自のクラスローダを持つ。
これらは同じ JVM 上の異なるクラスローダかもしれないし、そもそも JVM が異なるかもしれない。
クラスローダが異なるということは、クラスパスも異なるということだ。

Webアプリ上で、上で説明した EJB を利用するには、クラスパス上に次のものがあればよい。
　・Home インタフェース
　・コンポーネントインタフェース
　・PriceInfo クラス
　・PricelessException クラス
これらをまとめて .jar にしたのが ejb-client.jar ファイルだ。

開発時の話について。

EJBを呼び出す側のクラスを記述するとき、どうにかしてコンパイルしなければならない。
このとき、EJBの実装Beanクラスが完成していなくても、ejb-client.jar さえあればコンパイルすることができる。

EJBメソッドシグネチャさえ変えなければ、
どれだけ実装Beanクラスの内容を変えようとも呼び出し側には何の影響もない。

つまり ejb-client.jar は、コンパイルのために必要なクラスを集めた .jar ファイルということだ。

>>4-5
ありがとう！ようやく分かりました！
感謝いたします。

>>4-5
最初から素直に回答していれば荒れずに済むんだ。

実際に開発された方に質問です。
実際のプロジェクトでは、
いろいろなクラスから使用される、ビジネスロジックをまとめた共通（Utility）クラスが抽出されると思われますが、

I.どのように共通クラスを提供しましたか？
　　１．SessionBean
　　２．通常のクラス（JavaBeans)＋ＩＦ
　　３．その他？

�U．通常のクラスで作成した場合、パッケージングはどうされましたか？
　　１．Utilクラスを利用している全てのWar、ejb-jarに詰め込む。
　　２．ＡＰサーバのCLASSPATHに追加し、War、ejb-jarには含まない。
　　３．その他？

今回は、良スレの 予 感 ！！

http://homepage.mac.com/yuuka20/

"ejb-client"という名称に惑わされがちだが、平たい話がcorbaでいうスタブの類。

J2EEと同等の仕組みをCで実装してみました。すっごい速いです。

>8
>３．その他？

別のjarにまとめ、EARに一緒にいれる。
warやejb-jarから見えるように、MANIFEST.MFのClasspath:にそのjarへのパス(EAR内の相対パス）
を書いておく。
これが一番自然、かつ無駄がない。

>>13

EARファイルに入れるなら、ejb-jarと一緒にjarで固めても良いのでは？

こちらでは、MANIFEST.MFに書くのは外部から提供されているjarファイル
に対して使うことが多いです。

実際にアーキテクトとしてプロジェクト開発した方に質問です。

１．EntityBeanを使用する際にＢＭＰ、ＣＭＰ選択基準とはなんでしょうか？
　　使い分ける基準って言うのはあるのでしょうか？

２．CMPは基本的に１テーブル＝１エンティティBeanにしかできないのでしょうか？

>>15
1. 参照系は基本的にBMP。テーブル結合があるので。

2. そのはず。

>>16
対ViewでCMPしたり、CMR使ったりするよりBMPでごりごりのほうがいいのですか？

>>17
よかないよ。仕方なくという感じ。
EJB2.0に完全準拠してる製品使ってないから。
理想通りの使い方するにはもう少し時間がかかると思う。

おれはむしろＢＭＰとセッションＢＥＡｎの
切り分けかたを聞きたい。ＣＭＰはコード書かないだけ
メリットあるかもしれんがＢＭＰでＳＱＬ書くなら
あまりセッションＢＥＡＮにＳＱＬ書くのと代わらないような気がする
それとベンダーによるＥＪＢの設定の違い。
なんとかする気はないのか
write onece run anwherが泣いているぞ

＞ベンダーによるＥＪＢの設定の違い。
＞なんとかする気はないのか
この秋に出るJ2EE1.4ではデプロイヤAPIが共通化されるそうだが、
実際どんなもんだろうね。ちょっと期待。

ついでにだめだめのＩＤＥを何とかしろ。
何回１日にフリーズするんだ。
（誤）write once run anywhere

>>15-17
参照系ではEntityBeanを使う必要はないでしょう。
SessionBean＋DAO（DACB)で実装した方が、性能、メモリ効率を考えると全然いいと思う。

１．CMP2.0が出た今はBMPは必要ないと思います。
　　懸念点はEJB-QLがしょぼいという点があるけど、それもそのうち解消されていくし、
　　そこらへんはAPサーバベンダーが上手いことやっているから、問題ないでしょう。
　　そのうちBMPは消えていくんでは？

２．そうでしょう。
　　だからあまり粒度の小さいテーブル使ってしまうと、
　　多重EntityBean問題が発生して辛いかも。
　　そう思うと、ここでBMPを使うべきなんかなぁ

>>19
永続化コード（SQL文）とビジネスロジックの切り分けでしょう。

SessionBean＋JDBCで実装した場合、
ビジネスロジックにSQL文が混ざって、メンテナンス性がひどいことになる。
いろいろなSessionBeanに一つのEntityBean更新ロジックが混ざりこんでしまう。

BMPで実装すると、ビジネスロジックと永続化コードが分離され、
永続化コードはBMP＋DAOで隠蔽＋局所化されるので、
メンテナンス性は向上するんじゃない。
Entity更新したければ、BMPを更新するだけなので。

だーかーら、CMP2.0が出たのと実際の現場で使うのとでは大きなタイムラグがあるんだってば。

>>24
確かにCMP1.Xの時代にはBMPを使うしか選択肢がなかったと思う。
ただ現状はもうAPサーバがCMP2.0を実装してきているので、
もはやBMPは捨ててもいいのでは？
めんどくさいし。

>>25
今からはじめるならEJB2.0が良いのだろうね、きっと。
でも、俺の場合今やってるEJB1.1のプロジェクト1〜2年続く予定なので、
2.0に実務で触れることができるのは相当先なんだよな。
J2EE変化早すぎて、ついていけねえよ。と思っているのは
俺だけじゃないはずだ。

＞ J2EE変化早すぎて、ついていけねえよ。と思っているのは
＞ 俺だけじゃないはずだ。
特にEJB使うようなプロジェクトは期間も長いからね。

つまらん質問だが
セッションビーズでclass.forname(・・・
と使ってはいけないのか？

>>28
そんなアーティストはいない

なぜじゃ・・・
なんでじゃ
どうしてじゃ

個人的にはJ2EE2.1対応のアプリケーションサーバが出揃うまでCMPは待ちかなという感じなのですが。
皆さんはいかがですか。
そんなに永続化フレームワークに困窮してますか。

何年後の話でつか？
>J2EE2.1

Strutsでいいじゃん。

>>33
EJBの代わりになるのか？
Strutsってなんだか知ってる？

RMI＋JDOはだめかなぁ？

あ、トランザクションが無理か・・・

じゃ CORBA+JDOってことで

JTAサーバってないかねえ

結局ＥＪＢは不可分散び部分はロードバランサでカバーできるから
分散トランザクションぐらいしかメリットはみえないが
再利用はうまくいっているようにはみえないが（ｗ

EJBって、RMIのラッパーとして便利、という程度じゃ導入理由にならんのかな？

メリットは分散トランザクションだけか（ｗ

うんこ

EJBQL書かなあかんのやったら
BMPでいいじゃん
EJBQL覚えるんだったら
SQLに精通したほうがまだマシ
余計にややこしくして何考えてんだよ
それから、EJBに限らんがDDに頼りすぎだよ
DDの設定がこうも多いと
DD書いてんのかプログラム書いてんのかわかんねーよ
わけわからんよこの仕様

EJBは仮名で書くと「いーじぇいびい」
自信満々で偉そうで、腹が立つ
「おら、どうだ、すげーだろ？」的な態度がむかつく
ティンティンデカイだけで自信もってる男性と一緒だ

その点SQLは「えすきゅーえる」
すごく腰がひくく、やさしそう。女ならお嫁さんにしたい感じ
「ども。ぼくSQLです。がんばりますのでよろしくお願いします。」
すごくいい感じ、いしょうけんめいやってくれれば
女性にも母性本能が沸いてくるよ
基本は愛情があるかないかってこと

これがEJBのすべてだ
http://cgi.members.interq.or.jp/hokkaido/asato/upload/jam3ddr/OB000694.jpg

すいません教えてください
CMPをやってみたんですが
なぜ、EJBコンテナをシャットダウンすると
データベースのデータも消そうとするのでしょうか？
せっかく入れたデータが台無しですよ
っていうかejbRemoveをコンテナが呼んだときは
そういう仕様になってるんですか？
なんでそうなってるのか教えてください
まったく理解できない
データベースのデータが消えたら何にもなんないと思うんですが・・・

> っていうかejbRemoveをコンテナが呼んだときは
> そういう仕様になってるんですか？

この辺の、日本語がよくわからない。なにを言いたいの？

bean.remove()でデータが消えるのは当たり前のことだと思うのだが。

>>45
> データベースのデータが消えたら何にもなんないと思うんですが・・・

まぁそりゃそうだ。
ところで「永続化」って言葉、聞いたことない？

http://homepage.mac.com/norika27/

初心者です。
同じオブジェクトが各サーバにありアプリケーションサーバがそれを
不可分散に応じて選択。ただしロードバランスと違うのは
分散トランザクション機能がある。これがＥＪＢのメリットなんですか？
他にメリットありますか？

>49

メリット、メリットうるさいよ。
この小心者。

PetStoreのソースでもよめ。

（　´,_ゝ｀） ﾌﾟｯ

ＥＪＢで使われるパターンはプログラミングで参考になる事も多い。

ということは技術者のマスターベーションがＥＪＢなんですね（ｗ

>>46 >>47
データベースのデータも消えてしまうんだったら
一度立ち上げたAPサーバ一回も、とめること出来ない
と思うんですが・・・
デプロイアンデプロイもできなくなっちゃう

>>54
あ〜俺も疑問だ
remove()呼び出しが
クライアントだけならデータ消しても当然だが
コンテナシャットダウンしたとき、
モジュールデプロイしたときも
勝手に呼び出されて
DBのデータ消されるもんな
ずーっと、DB内にデータだけ残しておきたいときって
どうすんだろ

ejbRemove()に削除を実装してるのか？

>>56
いえ、空っぽのままです
だから、何もしないようにしたいんですが
どうすればいいのかわからないので・・・
空っぽのやつを定義しておけば
何もやらない（DBのデータ削除しない）と思ってるんですが
違うんですか？

CMPです

ほほう、findByPrimaryKey（）は見つからなければ
例外出すが
自分で定義したfinderメソッドは
例外出さないのか・・・
ちょっと勉強になった

>>45
ひょっとしてSunのJ2EESDKを使っている？
deploytoolのEntityBean設定には、アンデプロイする時に
テーブルも同時に削除するオプションがあって、
デフォルトでオンになっています。

>>60
いえ、JBossです
J2EESDKも以前やりました、結果は同じでした
こういう指定は、DDでやるのですか？
DDの書き方教えていただけると幸いです
どの解説書もそんな設定のこと書いてないので・・・

実際に重要な情報（たとえば商品購入のリスト）
が消えたら意味ないじゃん？と、思いました
クライアントコードからremove呼んだらDB上の
データも削除されるのはわかる
しかし、デプロイやAPサーバシャットダウンのときも
コンテナによって勝手に削除されるっていうのが
納得いきません。だってそれだったら普通のクラスと
変わらないんじゃ・・？なんのためにDBに保存しているのか
理解できません

<defaults>
<datasource>java:/PostgresDS</datasource>
<datasource-mapping>PostgreSQL 7.2</datasource-mapping>
<create-table>true</create-table>
<remove-table>true</remove-table>←ココ
</defaults>

>>61
いえ、DDでやるわけではありません。
EJBの仕様には含まれていませんし、
普通の製品（WebLogicやWebsphere）などでは、
そういったオプションはなかったと思います。
J2EESDKのその機能は、どっちかといえばサンプルアプリを
簡単に動かすための付加機能ととらえるべきでしょう。
実業務でそんなことするはずがありません。
JBossは触ったことはありませんが、おそらく同じ理由で
そういう機能が付いているんじゃないでしょうか。
多分、オプションをはずすことが出来ると思いますので、
マニュアル読んで自分で対処して下さい。

>>62が答えだしてます

>>60
明らかにおかしいだろ？
そういうときは、だいたい自分が間違えてるんだよ

>>61

まずオブジェクトありき、という純粋なオブジェクト指向の発想で、実装を考えます。

オブジェクト（インスタンス）がこの世（メモリ上）から消えたら、
そのオブジェクトをDB上に永続化した残骸も消すって
わからなくもないですよね。

オブジェクトがこの世に存在していないんだから、DB上にそのデータが
あるのはおかしいと、考えられなくはないと。

まその場合確かに普通のクラスと変わらないようにみえるけど、
DBだと排他制御とかトランザクション管理とかできるでしょ。

まず、DBありきの業務システムの発想だと、理解できないかも。

>>66
その考え方はいくらなんでも違うだろ。

>> 67

ま、たしかに。むりやりこじつけてみただけです。

評価でサーバの動作を確認するとき、DB上のテーブル設定とその削除を
ユーザがやらなくていいと考えるのが普通ですかね。

>>66
その考え方はおかしい。永続化という意味を分かっていない。

問題はejbremove()がどうのではなくて、
「デプロイやAPサーバシャットダウンのときも
コンテナによって勝手にテーブルが削除されるのか？」という事でしょう。

結論は「そんなEJBの仕様はありません。」
そんな仕様だったら誰も使わないでしょう。

それは>>62の方が回答を書いていますが、
EJBコンテナ独自のＤＤに
「デプロイやAPサーバシャットダウンのときにテーブルを削除する」
に設定しているから。
「勝手に」削除しているわけではありませんよ。

ま、どっちにしても「削除」は
開発段階に便利であるが
実運用では絶対にやらんな

>>66
お前の世界はメモリだけなのか。
オブジェクトが生きる世界はそんなに狭くはない

>>66

> オブジェクト（インスタンス）がこの世（メモリ上）から消えたら、

言いたいことはわかる。でも「（メモリ上）」は余計だね。

> オブジェクトがこの世に存在していないんだから、DB上にそのデータが
> あるのはおかしいと、考えられなくはないと。

EJBにおけるDBは、オブジェクトを永続化するための一手段だからね。

> まその場合確かに普通のクラスと変わらないようにみえるけど、
> DBだと排他制御とかトランザクション管理とかできるでしょ。

これらはオブジェクトレベルの話ではなく、それを永続化するのに
使っているDB上で起こる不都合を回避するためのものと捉えるべき
でしょう。
現実的ではないが、DB以外のものを永続化の手段として使うことも
理屈の上では可能。だからこういったことはコードではなくDDに書く。

> まず、DBありきの業務システムの発想だと、理解できないかも。

EJB以前に永続化、さらにはオブジェクト指向が理解できていない人には
無理な話よ。

　ああもっとなじって　庶民たちよ
　君たちには本質が見えないのだろう
　私はちーさまの声に音に凌辱され姦淫された奴隷なのだ
　苦しい，でも幸せ
　絶望だから快楽
　それが鬼ちーワールド

>>71

この世界は、JBOSSの寿命で決まっているのさ。

JBossのソースコード理解できるか？
それとＪｂｏｓｓ４のアスペクト指向てなんだ？

アスペクト指向　＝　オブジェクト指向でなしえなかった部品の再利用
だと、漏れは勝手に判断した。

物事を concern で捉え、concern 単位のソースの断片をあちこちにばら撒く
・・・ように見える。

>>75
要はユースケースで共通に現れる基盤部品を別のクラスにしようぜ！
って言うあたりまえのことをえらそうに名前を付けただけ。

要するにトリガーてこと
トリガー＝＝アスペクト

>>79
>>トリガー＝＝アスペクト
納得

>>76-80
全然とはいわないが、まったく本質をとらえてないよ。

アスペクト指向自体は、Cross Cutting Concernという
プログラミングに関わる本質的問題を解決しようという試み。

ただ、アスペクト指向プログラミングを実現する代表的実装のaspectjがまだそれほど
枯れていない、満足できないものなので、

アスペクト指向 = トリガー、プリプロセッサ

みたいな見方しかされていないのが大方の現状。

＞全然とはいわないが、まったく本質をとらえてないよ。

・・・全然とまったくの違いがわかりまつぇん

過去ログからのコピーです。http://natto.2ch.net/mass/kako/974/974478132.html

489 名前： 文責：名無しさん 投稿日： 2001/04/11(水) 17:25
　一般人なのに盗聴される、じゃなくて、「一般人だから盗聴される」んじゃないのかな？
　基本的にネタ集めのためにやってんなら、有名人のネタを盗むと、有名人は告発できるし、
そんなことされても当たり前だと思われるので告発しても信じてもらえる。
　そうでない人は、ここの途中の書き込みにもあったように「電波」扱いされるだけ。

　ただで、ネタを仕入れるんなら、一般人に限るでしょう。
　マスコミは自分らの無能さを恥じてほしいです。

　ちなみに私が盗聴されはじめたのは、芸能人にストーカーされ始めてからでした。
　そこからマスコミに広がって行った。
　だから余計「妄想」とか思われそう。
　友人に話したら完全に病気扱いされた。ストーカーって言葉がない時代だったしね。
　書いておいておいた小説のネタが、他人の原作でドラマ化されたときにはきれまくっ
たなあ。（一度や二度のことじゃないけど）

おまえらＥＪＢはoracle9iAS
だこれできまりだな。
値段は安いしＪｄｅｖｅｌｏｐｅｒまでついてくる。
他はだめだな（ｗ

>>84
俺はJBoss + Eclipse + Lomboz で充分なのだが

>>84
しかも、US OTN 版を使えば開発用途には只！！

oracle9iASって何気に高機能なんだけどあまり使われないね。

>>87
OC4Jの中途半端な実装がちょっとな。

OC4J、EJB周りの独自路線突っ走りまくりがなんとかなったら
結構いけてると思うのだが。
軽いし。

>>89
うん俺も基本的には気に入ってるよ。珍しくpure Javaなサーバだし、
軽いから開発するときは手軽で良いと思う。

2,3年でＢＥＡは合併吸収されるでしょう
ＢＥＡ殺しのＯＲＡ９ＡＳとＪＢＯＳＳ。
時代は
ＯＲＡＶＳＷＡＳなのだ
ところでＢＥＡの××ＳＨＯＰ（ＶＢの連中がスピンアウトしてつくった）
つかいかたわからんのよ。だから１時間でけしました（ｗ

社員降臨？

ＯＲＡ９ＡＳはうんこ

昔はＡＰサーバと言えばOWASといういう時代もあったのだが。
いまだにＸＸカードリッジみたいな方式なのかな。
PL/SQLカートリッジなんておっそろしくて使えるかっての。

http://yomi.kakiko.com/hiroyuki/jaz_b01.html

EJBを勉強できるサイトありませんか？
初心者です。

EntityBeanを使わなきゃいけない場面てありますか？

SessionBeanとO-R Mapperで十分だと思うんですが。

大体EJBのメリットってリモート呼び出し＋トランザクション管理くらいしか
無さそうなので、SessionBeanでそれをやってしまえばおしまいじゃんと思うのですが。

さらにEntityBean使うと、
■めんどい
■メモリを食う
■性能が悪い（CMPだとそんなことないかな・・・）
といったようなデメリットしか思い浮かばないのですが・・・

>>97
実際にどの程度のことが出来るのかはおいといて、理想は
「ストレージの形態を隠蔽する」ことじゃないかねえ。

最終的にはRDBじゃなくてもいいように「したい」んだと思われ。

ここでいいかわからないのですが教えてください。
今までTomcatで勉強してたんですけどJ2EEでもjspが動くことがわかり
J2EEの/public_htmlへjspファイルを移動しました。
しかし、DBConnectionPool.classをどこへ移動すればよいかわかりません。
どこへ、移動したらよいのでしょうか？

すみません。できました。
J2EEサーバーを再起動しないといけなかったんですね。

>>99
何度も書かれているが、"J2EE"とは仕様・規格を指す。
あんたの言う"J2EE"とはJ2EE Reference Implementation （J2EE RI）のことだろうと推測して回答。

JSPファイルもclassファイルも配置はJ2EEの仕様に沿っていればOK。
その書き方だとおそらくJSPファイルをそこに置いて動いてしまっているは
いいが、どうしてそこに配置すると動いているのかわかっていなさそうだな。
設定・デプロイ方法はTomcatと同じだ。というかJ2EE RIはTomcatを含んでいる。
server.xmlにContextの設定はしたか？

J2EEにTomcatが入っていたのかー
WebLogicとかになったらまた違うのかなー
面倒だなー

ここで聞いちゃってもいいですかな。JBoss 3.0 使ってる人いますか？

Stateful SessionBean を使用する Web アプリケーションをつくりまして、
EJB とセットして EAR 形式でデプロイさせています。

例えば JSP やプロパティファイルを修正して EAR を作りなおしてデプロイす
ると正常にデプロイされますが、デプロイ前のセッションが初期化されてしま
うようで参照できません。

なんとか初期化されずに済むような方法はないですかね。

>>103
初期化されないアプ鯖ってあるの？

コンパイルしなおしてデプロイしたんだろ？
なんで前のが残ってるんだ（ｗ

>104-105
ホットデプロイって知ってる？君たち。

>>97-98
っつーことは、
ストレージがＲＤＢ固定だったら、
EntityBeanは使う意味がないって事ですかねぇ
どなたかストレージがRDB固定の時にO-Rマッパー（JDO等）よりEntityBeanが優れている点を
説明できる方居ませんか？

EntityBeanの方がノウハウが進んでるし、多分管理も楽（それでも十分難しいと思うが）
JDOだとCastorだろうか？XMLとの統合もいい。
ってOracleも同じか。

>>106
EJBのインスタンスが存在している状態で
ホットデプロイするとどうなるの？

次に生成されたインスタンスから
変更となる

>>110
新旧入り混じるとシステム的に整合性が
取れないことは無いでつか？

あるはずのクラスが無くなったりメソッドのシグニチャとか変わったらどうなるんだろう？

>>107
EJBの方がトランザクション管理とかやりやすいでしょ？

（ビジネスロジック面で）システム整合性が
とれないような場合はAP鯖止めてからデプロイし、
起動したほうがいいね。
あくまで、AP稼働中にクラスモジュールを
入れ替えることが可能ということで、
ビジネス上の整合については
自己（運用者）責任だよ。

>>114
そゆことか。ｻﾝｽｺ！

>>108
最近のフレームワークではEntityクラスを簡単に自動生成してくれるので、
ノウハウはいらないと思います。
むしろEntityBeanの余計な排他制御等の知識等のほうがめんどくさいのでは？

>>113
トランザクション管理はもちろんSessionBeanで行います。
ここで言っているのは

１．SessionBean＋EntityBean
２．SessionBean＋O-Rマッパーで作成したEntityクラス

で、１の方が勝っている点がおいらの知識ではわからないのです。
２の方が勝っている点については>>97に書きました。

EJBのメリットってリモート呼び出し＋トランザクション管理＋オブジェクトライフサイクル管理くらいだから、
そこらへんは全てSessionBeanでカバーできると思っているので、
EntityBeanの必要性は感じません。

個人的にはEntityBeanは廃れていくんじゃないかなぁと思っています。
どなたか反論（１．パターンの優れている点）をお待ちしています。

俺もCORBAよりEJBの方が面倒が無い、という理由でEJB良いと思う。
が、EntityBeanは使わない。
Javaのおかげでにわかにオブジェクト指向が脚光を浴びてきて
OODBに移行していくと思ってたんだけど、全然アテが外れた。

1.4のJ2EE Tutorialでも見てみ。EJBの扱いが突然小さくなってるぞ。

＞OODBに移行していくと思ってたんだけど、全然アテが外れた。
同じく（ｗ

＞＞1.4のJ2EE Tutorialでも見てみ
まだ出てないだろ。夏ぐらい？

>>120
まだ完成版じゃないけど
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html

>118

Note: With the exception of timer beans,
Enterprise JavaBeans technology will be covered in the next release of the tutorial.

が読めないのかい？

もともとJ2EE1.3チュートリアルへの補完として今のJ2EE1.4チュートリアルがつくられているんだよ。
いずれJ2EE1.3チュートリアルから、EJBの部分はコピー＆ペーストされるよ。

>>118-119
データベースシステムの移行ってのは兎角スムーズにはいかんだろ。
OODBってまだ信頼性に問題あるのおおいし。保守できる奴殆どいないし。

Oracleだって今の信用？を得るまでは、おもちゃ扱いだったんでは？

データベース中心に考えると
JDOとか標準になったら
EJBの特筆点は分散技術だけになってしまうのか？

それと、やったことないがメーッセージドリブンBeanってこの先伸びるの？

でもさぁ、パフォーマンスとかデザインパターンとか
考えるのでやってて面白いけどな

難しい話題になると敬遠するな
JavaやってるやつでEJBまで理解してるやつっていないのかな？
さすが、入門言語

入門用じゃねーよ(;´д`)
エキスパート用だよ(;´д`)

>>126
さすがにお前の頭も分散技術ってことだな

>>124
Enterprise-MessageQueueのラッパですよ。
MQ自体は需要ありまくりですよ。

確かにMDBは需要有りまくりでしょう。
楽にメッセージ受信側が実装できるし。

なんか話を聞いてるとSFSBとEntityBeanだけ取り残されてる気がします。

CMP2.0で、コンポジットプライマリキーは使えるんでしょうか？
BMPでは成功したんですが、CMPではできません
いちおう、ejb-jarのDTD見たんですが
<primary-key>要素を使うな　としか書いてありませんでした
一応そうやってるのですが・・・・
エラーの内容としては、SQLExceptionが出て
「”FROM”付近の入力が間違っている」みたいなSQLの文法が間違っているみたいです
プライマリキークラスは、intと、Stringの2つのフィールドがあって
きちんと、ハッシュコードもイコールもオーバーライドしています
ただ、SQL文のエラーっぽいので、うまく2つの値が分解されていないのかな？と思います
BMPではその辺は自分でコーディングできるんですが
CMPだと、すべて任せてしまうので中でどんな処理してるのか僕の入る余地がないのです
一番いいのはデバッグすればいいんですが、EJBコンテナのデバッグツールってあるのですか？
たとえば、EclipseのTomcatプラグインのようなものがあれば一番いいんですが･･･
DBの方のログファイルにも詳細まで書かれていません。
また僕はログに関してはあまり詳しくないので
こういうふうにすれば、中で何やってるかわかるよ」みたいなアドバイスくれれば幸いです

環境は、JBoss3.0.7+PostgreSQL7.2.2です

>131
JBossって、デプロイされてできたクラスのソースコードを見ることはできないのかい？
WebSphereとかだと、デプロイメント後、自動生成されたクラスのソースも見ることができて、
実際のSQLのイメージがなんとなくわかるようになっているのだが。

>>131
ソースコード落してきてデバッグ実行。オプソマンセー。

Stateless SessionBeanにインスタンス変数持ってる例を見かけたんだけど、それってアリなの？
ユーザーごとに変わる値でなければ別に構わないのかな？(参照EJBのHomeとか)

>>134
セッション基準に見たら無意味だが、ありなんでわ。
単純にSLSB自体のIDがほしいとか。何につかうかｼﾗﾝｹﾄﾞ。

>>131
プライマリーキークラスのフィールドは、publicという点も中尉。

すいませんが質問させてください
エンティティBeanの
ejbCreateの戻り値についてなんですが
return null;となってる解説書と
return primarykey;となっている解説書があるんですが
いったいどっちが本当なんでしょうか？
どっちも正常に動くんですが
どうなってるんでしょうか・・・？

>>137
CMP→Null
BMP→主キー
（J2EE TutorialのP119を参照）

>>138
レスさんくす
ということは、CMPなのに主キーが返ってる解説書は
糞ということでいいですか？
本のタイトル書いたろかな

>>139
CMP1.1はどうだか忘れたけど、
CMP2.0でそんなことやっている解説書は糞です。
本のタイトル載せてください。

EJBのファインダーの戻り値は
java.util.Collectionとなってる例が多いんですが
ListとかVectorじゃダメなんですか？

>>141
順序に意味が「ない」という意思表示なのでわ。

>>142
ん〜でも、OrderByで取得したいときって
やっぱ、Collectionだとダメですよね？

>>138-140
return null; でも return primarykey; でも、どっちでもOKなんですが...
ただ、return primarykey; としたとしても、そのprimarykeyは使われない
というだけで...。

EJBやっていると
例外をthrowする場面が多くなると思うんですが
どの辺りまで引っ張ってくればいいんでしょうか？
いちおう、いまのところ
クライアントの手前に例外のフィルターみたいな役割のクラスを置いて
そこで、とりあえずすべてキャッチするようにして
あとは、例外でたことをクライアントにしらせる
って言うやり方してるんですが
こういうやり方でよいのかどうか判断つきません

とくに、どこまで引っ張ってくれば（throw）よいのか？
っていうのがわかりません
クライアントに知らせることが出来るなら
なにもthrowしなくてもフラグやメッセージさえ
わたせばいいのかな？とも思いますし・・・
この辺に関しての標準的な考え（パターンとか）ってありますか？

上げ忘れましたすいません

＞ なにもthrowしなくてもフラグやメッセージさえ
＞ わたせばいいのかな？とも思いますし・・・
フラグやメッセージの取り決めしなきゃならんだろ。
プロジェクトによってバラバラだったりで毎回決めなきゃならん。
ひどいときはシステムのあちこちで統一性のないフラグやメッセージの
使い方がまかり通ることもある。

そんなことしなくてもいいのが例外処理の利点じゃないか。

>>145
サーバ側で処理する必要がないなら、RemoteExceptionのサブクラス作って
そいつにラップしてクライアントに丸投げ、サーバの処理は全部ロールバック、
あとはクライアント側でどうにでも、が一番楽なんじゃないかねえ。

>>145
「どこまで引っ張ってくれば（throw）よいのか？」と書いてるところを見ると、
システムを層に分けてるだろうから、自分の層で処理できるものだけcatchして
メッセージなり戻り値なりに置き換えればいいんじゃないの?
最終的には（どの層も処理できない例外は）、フィルター的なもので処理することに
なるだろうけど（Strutsにもそういう仕組みがあるし）。

レスサンクスALL

俺がやってるのはクライアントがサーブレットなんだが
とりあえず、アプリケーション例外は呼び出し元で処理して、
そこで、なんらかの復旧作業

システム例外はそのままWebのコンテナにServletExceptionとして
throwすることにしました

すいません教えてください
EJBの数が多いので
ejb-jar.xmlファイルなどのDDファイルがすごく長くなります
とくに、CMPだとフィールドとかも書かなければならないので・・・
なので、それぞれ別々のJARファイルにまとめて
それらをWEBコンポーネントと一緒にEARとかにまとめても
大丈夫でしょうか？

EJBとEJBクライアントで発生する例外を次のように分類する。
　(1)EJBのシステム例外
　(2)EJBのアプリケーション例外
　(3)Webアプリのシステム例外
　(4)Webアプリのアプリケーション例外
システムが直面するエラー状況を次のように分類する。
　(A)入力値エラー
　(B)アプリケーションエラー
　(C)システムエラー

(1)-(4)を(A)-(C)のどれに対応させるかについて、ちゃんと設計しておいたほうがいいよ。
(A)は例外発生ではなく、カスタムのエラーオブジェクトをハンドリングするような設計になるかもしれない。
(StrutsはActionErrorというカスタムのエラー型を定義している)

>151
ejb-jarの分割方針はそんな管理上の面倒くささで決めるのではなくて、
あくまでもアプリケーションの意味上で決めるべきだろ。

そもそもCMRとか使用すると同一ejb-jarじゃなきゃいけないってこともあるぞ。

EJBって何がエンタープライズなのかと思ったら、
EJBの仕組みその物がエンタープライズなんですね！

>>151
まさか、いまどきDDを手で書いてるの??

>>155
じゃあどうやって書くんだ？ん？

>>156
アプリサーバに付属のデプロイツールとか使わないの？
もちろん、初めて学習するときには仕組みや設定内容を理解するために
テキストエディタ等使って手で書くことも必要かもしれないが、
一度やってみれば手書きは限界に近いものだと誰でも悟ると思うよ。
EJB使うってだけで大半は大規模アプリ。
大規模アプリのDDを全部手書きでメンテするのは大変でしょ。

いや、いちおうXDoclet使ってますけど
DDがこんなに長くていいのかなぁ〜と思ったわけです
みんなどうしているのかなぁと・・・
一枚でいいのなら（それが標準なら）それでいいんですけど

>>158
JBuilder Ent版 の EJBデザイナを使えば、全部自動で作成してくれる。
もちろん主要なサーバーに対応してるし。

>>159
多毛絵よ！

>158
DDが長くなるのはしょうがない。みんなそうだ。気にするな。

159>>さんに質問！
全自動で作ってもコンパイルはantでするんですか？
ＩＤＥはいまいち信頼性がなくＪＢも情報が少なすぎ。
（特に他のＡＰＳ使う場合）

>>162
>全自動で作ってもコンパイルはantでするんですか？
いいえ。

すいません教えてください
ＥＪＢのＱＬに渡すパラメータって
intやlongなどのプリミティブ型はダメなんでしょうか？
java.lang.Integerやjava.lang.Longに変換して渡さないといけないんでしょうか？

>164
Spec読め。

↓>>164のPCのスペックがこの辺に。

＞＞多毛絵よ！
キージェネがあるだろ

IDEは使い物なりのか？

ejbCreateの引数ってなんでオブジェクトなんですか？
int や　booleanはそのまま使えないんでしょうか？
いちいち、取り出してキャストするのがめんどくさいんですけど
理由がわかりません

http://homepage.mac.com/hiroyuki44/

>169
intで返すならjava.lang.Integerでいいじゃん。
そんなに変わらんでしょ。

>>159
XDocletもおすすめやで〜日本語マニュアル少ないけど

>>171
は？言ってる意味がわからん
キャスト発生するじゃん？

>>169
ちったぁ頭使えよ。

>>169
オブジェクト指向って知ってる?
こういう奴にはsmalltalkの刑だ。

DTO（VO）とかを使わないで、ただ単に
文字の配列をDTOとして使うのは
あまり良くないことですか？

返り値のデータ量が非常にコンパクト
（データベースから条件に相当する2〜3文字を引っ張ってくる）なので
わざわざ、DTOのインスタンス作るの馬鹿らしいんですけど

>>176
当然そうするべきです

>>177
すいません

「当然そうするべきです」
っていうのはどっちなんでしょうか？
どっちとも取れる答えなので・・・すいません

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

MessageDrivenBean って使ってる人いる？どんな感じで使うのかなー

>>181
MessageDrivenBean のほうが使い勝手あるらしいが
おれもどういうときに使うのかよーわからん
でも、覚えるのは簡単だよ

っていうかよースレの順番逆転してないか？
「age」進行の山崎 渉 にやられたのか

びっくりしたよ、起きたら別の板かと思ったよ
で慌てて玄関の表札確認したよ

>182
使い勝手があるというより、
J2EEでは他に大体手段がないのだから、
（ユーザーアプリの中で、別スレッドでキューを監視しつづけるなんてことはできないから）
使わざるを得ない。

CMPのEntityBeanをつかってカッチリO-RマッピングしてRelationまでつかってるような開発って実際どのくらいあるのかな。だれか実際開発してる人いますか？

>>185
私が関ったシステムでは、CMPオンリーで、Relationもバリバリ使ってますよ。

earやwarの圧縮の話で盛り上がっていたことで気になること。
全部ひとつのearにまとめてしまえば楽じゃね？

>>187
ヴァカかおまえは。
圧縮の話しなんか誰もしてないが。字が読めないならプログラミングなんて無理じゃないのか?

>>182
MDBはトランザクションを即効で終わらせたいときに便利。
DB負荷も少なくてすむ。

>>186
どのくらいの規模ですか？
何エンティティくらいあるのですか？

>>187
バグ等で入れ替えることまで考えると１つのEarファイルなんか無茶だと思うが・・・
一人で開発しているならともかく。

> バグ等で入れ替えることまで考えると１つのEarファイルなんか無茶だと思うが・・・

だから、EARはアプリケーションの論理的な単位でまとめろって。
運用上の都合で分けるのは、素人仕事だぞ。

EJBは再利用コンポーネントだ。
.ear ファイルにまとめちまうということは、
その中の一部を入れ替えるだけでもサービスの停止が必要になるということだ。

たとえば従業員を示す EmployeeEntityBean を Employee.jar としてまとめる。
EmployeeEntityBeanを利用して給与計算する SalarySessionBean を Salary.jarとしてまとめる。
Salary.jarのクライアントとなる給与表作成アプリを salary-view.war としてまとめる。

EntityBeanも、SessionBeanも、Webアプリも、すべて何らかの修正が発生する可能性がある。
.ear ファイルでまとめられていると、無駄なサービス停止が生まれてしまうのだ。

小さなアプリだけ作ってる分には分からないだろうが、
大規模になればなるほど、
24h*365dに近いサービスが求められるほど、
ミッションクリティカルになるほど、
重要な設計要素となる。

>>193
earにまとめとかないと、参照渡しによる高速化ができなくねぇ？

>193

それこそ、運用上の都合だ。そいうことは運用、またはトポロジー（クラスタリング）でカバーしろ。
運用上の都合をアプリケーションに持ち込むのは素人仕事。

運用無視してつくられたアプリケーションの面倒なんか見てられねーよ。
それこそ素人仕事もいいところだ。
ただ動くアプリケーションなんか誰でも作れるんだよ。
動かしつづけられるアプリケーションつくってくれよ。

>>195みたいなやつは、
「データ不整合が起きたらリカバリに1週間かかります」
みたいなシステムを作るんだろうな。

てか、サービスまったく止めないで運用しているのが存在するのか？

>>193のネタって重要だよね。J2EEアプリが、オブジェクトがどこにある
どのバージョンのクラスファイルに基づいて作成されるのかを把握しづら
いのは、どうにかナランかねえ。

>>193

これってやっぱしクラスタリングで対応するのではないですかね。

2台のマシンをクラスタリングして、1台目のマシンに ear をデプロイして、
完了したら2台目のマシンにデプロイさせてやるってふうにすれば、
サービスとして停止はないのじゃないですかね。もちろん変更内容にも
よるでしょうけど。

http://homepage.mac.com/hiroyuki44/hankaku04.html

>193
>.ear ファイルでまとめられていると、無駄なサービス停止が生まれてしまうのだ。

違うでしょ。
全てをひとつのearにまとめるからそうなるのでしょ。

アプリケーションを独立させたいのなら、
earをわけろよ。

そうすれば、ひとつのearに含まれるejb-jarを更新したところで、
もうひとつのearには何の影響もない。

>>193は、だからearのまとめ方を考えろといってるんじゃないの。
ひとつにまとめるんじゃねえよﾓﾙｧって

どこでまとめようがそんなの知らんよボケェ
まとめたっていいじゃんいいじゃん
っていうかよ、Classファイル入れ替えの機能ってついてないのか？
高級なお値段のAP鯖には？

>>204
適当にClass入れ替えたら何が起きるか想像してみろよ。

>>200
普段はクラスタで動いてて、デプロイ時にはクラスタの
メンバーからはずしてってことを言ってるんだよな？

それって単純だと思う？
漏れにはとても単純には思えないんだが。
片側止めてる最中にトラぶったらどうする？

ちょっともとめられないような場合は切替までちゃんと設計するし、
そのときには代理のパスを準備するもんだ。


>>193がいってるのはサンプルとして不適切だと思うんだが。
クリティカルな部分でアプリが替わったんならさすがにとめなきゃだめだろ。

安全にバックアップするために毎日とめてくださいってのは開発側のエゴかもしれんが
明日から途中流れるデータが変わるのでしばらくとめてくださいってのは当たり前。

一緒になってるかバラバラになってるか関係ないじゃんバカァ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ

独立して運用できる単位でearにまとめるのが普通じゃないの。
大きいシステムなら、普通サブシステムに分割されているだろ。
1つのサブシステムをさらに細かくearに分けることは、
あんまり意味がないと思う。
ところで、J2EEのアーキテクチャだと、earっていうのは
いくつかの再利用可能なEJBコンポーネントやWebコンポーネントを
アセンブルした後のアプリケーションのことであって、
再利用の単位じゃないと思うんだけど、違ったっけ。

>208
> ところで、J2EEのアーキテクチャだと、earっていうのは
> いくつかの再利用可能なEJBコンポーネントやWebコンポーネントを
> アセンブルした後のアプリケーションのことであって、
> 再利用の単位じゃないと思うんだけど、違ったっけ。

そのとおり。
EARはあくまでそれ自体で完結しているアプリケーションの単位。
必要なライブラリは全てEAR内に含めるのが基本。

ここで話題を提供
日経コンピュータでそろそろＪａｖａで大規模なシステムを作る
計画が急速に進んでいるがどう思う？
成功すると思う？
俺は成功すると思うが。代わりがないからね（ｗ

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／

>
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／

>
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／

　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／

Linux が OSの仮想化を促し、
Java がアプリケーションの実行環境を仮想化する。
XML がデータの抽象化を推進する。
ネットワークやストレージも仮想化されてる。
これらすべてがオープンな標準として実績を築いている。
駒は揃ってきたよね。

これで「複数企業や業界にまたがる共同インフラの構築」なんて案件がいくつもあれば完璧だろう。
実際に構築しているところも知ってるし。

>>216
何が完璧なんだ？
何のためのコマがそろったんだ？

>>Linux が OSの仮想化を促し、
意味ふめい　

池田大作大先生はかって

「国立戒壇の建立こそ、悠遠六百七十有余年来の日蓮正宗の宿願であり、また創価学会の唯一の大目的なのであります」

といってますが、今はどうなんですか？

ttp://society.2ch.net/test/read.cgi/koumei/1057065225/

http://www-6.ibm.com/jp/servers/eserver/zseries/server/z990/index.html
とかのことか？

>>220
それはLinuxがOSの仮想化を促しているのではなく、
メインフレームH/WとVMがLinuxの仮想化を促しているのだ。

>>216は夢見すぎ

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン