No.151
WebObjectsってどうなん。
レス数: 247
概要: Java遅いからObjCのEOFマダー？
No.152
> 非接続型と接続型の区別がついていない発言だな。
詳しく。
>> Deployしながら、JVMメモリ、Session、DBコネクションレベルでモニタリングできるんだっけ?
>> リクエストがApp鯖のコンポーネントを通過していく時間を見れるんだっけ?
パフォーマンス分析ツールが無いと、チューニングできないと思うんだが。
>>137
> 現状のBPEL,ESBはただ単なるキーワードでしなかいし、有効な導入事例がない。
確かに新しい概念ではあるけど使ってるところは使ってるよ。
> BPELで業務フローを変えられても、やり取りするデータの種類が変わったら、
ESBわかってないんじゃね?
Binding Component(BC)が何の為にあるかわかってるの?
>>138
WOは開発者寄りの設計と思うよ。
Class Libraryで楽してる分パフォーマンスはめっちゃ悪そうだがね。
DeploymentがMacOSX Serverだけというのはどうなんですかねぇ。
No.153
詳しく。
ADO.NETのDataSetを学んだ上で、EJBがなぜセッションビーン、エンティティビーンなんて
概念が必要か考えてみな。
>確かに新しい概念ではあるけど使ってるところは使ってるよ。
国内において有効な、しかもESBならではの事例をあげてみな。
>ESBわかってないんじゃね?
>Binding Component(BC)が何の為にあるかわかってるの?
取引先が部品コードを入れ替えて、しかもその数が多い場合にBCで
制御するのが現実解なのか？1対1のマッピングならまだしもそんな都合よくないぞ。
>WOは開発者寄りの設計と思うよ。
>Class Libraryで楽してる分パフォーマンスはめっちゃ悪そうだがね。
パフォーマンスについては俺も知りたい。
No.154
Excelがフロントエンドの基幹システムなんてあるのか?
だいたい基幹系って、ばしばしデータ更新が入るもんじゃないの。
DBからのCacheは更新が頻繁な物には向かないし、EJBにもEJBキャッシュがある。
> 国内において有効な、しかもESBならではの事例をあげてみな。
ESBかどうかは知らんがBPELは使ってるよ。
ttp://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040715/1/
> 取引先が部品コードを入れ替えて、しかもその数が多い場合にBCで
すまん。これだけだと具体的にどんな例なのかよくわからん。
> パフォーマンスについては俺も知りたい。
あんなコテコテのClass Libraryで、パフォーマンスがいい訳ないじゃん。
何にしろMacOSX Server以外で動かないのは致命的と思わないかい。
No.155
>Excelがフロントエンドの基幹システムなんてあるのか?
>だいたい基幹系って、ばしばしデータ更新が入るもんじゃないの。
Excelをそのままフロントに使うとはいっていない。
Excelのようなインタフェースで大量入力に対応すると言うこと。
ちなみにSAPは今Officeをインタフェースとして活用しようとしている。
一般的な業務では殆どオプティミスティックロックで十分。
ペシミスティックな場合は少ない。
更新が頻繁なクリティカルな業務でEJBを使うメリットは無い。
>ESBかどうかは知らんがBPELは使ってるよ。
>ttp://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040715/1/
アリス使っている＝BPELって論理が分からんな。
アリスがどんな製品か分かっていて言っているのか。
アリスの吐き出したBPMN→BPELで業務を動かしているのか？
そんな事は一言も書いてないけどね。
>すまん。これだけだと具体的にどんな例なのかよくわからん。
考えてくれ。
>あんなコテコテのClass Libraryで、パフォーマンスがいい訳ないじゃん。
いい加減な推論じゃなくて、もう少し具体的な論拠が欲しいね。
Hibernateだって使う人が使えばクエリ発行しまくるで遅くなるのは変わらないし、
JDBC直に使ったって同じ。
ttp://www.eisbahn.jp/yoichiro/2006/02/post_2.html
No.156
どういう用途かさっぱり。
名簿屋とか、データ入力専門業者が名簿渡して、SOHOで仕事させてエクセルファイルで納品してもらって集計させたいってこと？
部品コード入れ替えは辞めさせるべき。
ICタグで全部やっちゃうぜって方向に動きつつ有るのに、コード使い回しじゃ混乱するだけ。
今からでもJANコードベースに整備させた方がいい。
No.157
> 一般的な業務では殆どオプティミスティックロックで十分。
あいまいな表現じゃなく定量的にTransactionがなんぼ以下の場合は
みたく書いてくれ。あんたの経験値でよいから。
> 更新が頻繁なクリティカルな業務でEJBを使うメリットは無い。
トランザクションを任せられないと意味が無い。
銀行や勘定系でEJBはばしばし使われてる。
ttp://www-06.ibm.com/jp/domino07/fss/finnetjp_www.nsf/vwdockey/8DF1A4A58D8E966C49256F65005EFCB7?Open&cat=01#case
> そんな事は一言も書いてないけどね。
そう言われてもなぁ。まさかARISでお絵書きだけしないと思うんだが。
海外事例なら沢山あるがそれではダメなのか?
> 考えてくれ。
よくわからんが、その場合SOA以前の問題だと思う。
> いい加減な推論じゃなくて、もう少し具体的な論拠が欲しいね。
じゃWASのSPECjAppServer2004貼っておくから、もまいさんの方でWOの公式な速さの数字を貼ってくれ。
ttp://www-06.ibm.com/jp/software/websphere/developer/was/wv6/benchmark/
それから、MacOSX Serverでしか稼働しない件についてもスルーしないでおまいさんの見識を書いて欲しい。
No.158
取引先の関係があってもそれが可能かというとそうも言ってられないだろう。
>あいまいな表現じゃなく定量的にTransactionがなんぼ以下の場合は
>みたく書いてくれ。あんたの経験値でよいから。
Transactionの数量じゃなく、業務の種類だろ。厳密な座席予約が必要な場合は、
ペシミスティックロックだが、業務全体からみれば少ない。
>トランザクションを任せられないと意味が無い。
>銀行や勘定系でEJBはばしばし使われてる。
EJBがなくたってトランザクションは可能だろう。EJBならではの理由はないよ。
UFJのjavaでバッチを組んだ事例も、ただ単なるリクエストのディスパッチャ的な使い方で
EJBである必然性は全く無かったけどね。
>そう言われてもなぁ。まさかARISでお絵書きだけしないと思うんだが。
>海外事例なら沢山あるがそれではダメなのか?
ARISでお絵書きの方が事例としては多いし、そもそもどこがBPELなんだ？
一言もBPELなんて書いてないだろ。
>よくわからんが、その場合SOA以前の問題だと思う。
じゃあSOAならではの事例をあげてくれ。
>じゃWASのSPECjAppServer2004貼っておくから、もまいさんの方でWOの公式な速さの数字を貼ってくれ。
だから俺もWOを使ったことはないからパフォーマンスについては知りたいから聞いているんだよ。
それといま時まともにマルチコアライセンスを考えられていないWASなんかの
パフォーマンス値はいらない。
>それから、MacOSX Serverでしか稼働しない件についてもスルーしないでおまいさんの見識を書いて欲しい。
これについては、自分も問題なしとは思わない。
と言うかこんな不毛な議論より、WOの情報が欲しいだけなんだけどな。
No.159
言い忘れたが去年日本IBMが発表したSOAのサンプル事例が、
取引先との受発注で、部品コードの変換とかをやっていたけどね。
No.160
日本でWOを使ってると思われるサイトの検索結果 約２０件 (0.29 秒)
huis.huis.hiroshima-u.ac.jp
jobmatch.ai-link.ne.jp
www2.kiryu-jc.ac.jp
www.dynamicbind.co.jp
www.web-ya.jp
aps.bell.ne.jp
ds.sie.dendai.ac.jp
db2.kahaku.go.jp
www.myroots.jp
reas.nime.ac.jp
portal.idec.or.jp
www2.usnet.ne.jp
www.techpit.co.jp
osxs.eleap.co.jp
aps.next-fc.gr.jp
weyl.ed.ehime-u.ac.jp
www.kiwamu-dennou.co.jp
www.fujita-denki.co.jp
www.trein.jp
wise.nime.ac.jp
No.161
No.162
> Transactionの数量じゃなく、業務の種類だろ。
定量的か定性的かの言い方の違いだろ。
テスト工程で実稼働を想定した負荷をかけてテストしないのか?
それともどんぶり勘定なのかね。
> 厳密な座席予約が必要な場合は、ペシミスティックロックだが、業務全体からみれば少ない。
座席予約にバッティングは許されないから、「厳密」という表現はおかしいのでは。
> EJBがなくたってトランザクションは可能だろう。EJBならではの理由はないよ。
個人の嗜好にかかわらず現状ではEJBが業界標準だよ。
例を出すなら公の引用を貼ってくれ。
> 一言もBPELなんて書いてないだろ。
海外の例で悪いけど。
ttp://www.fiorano.com/jp/frontpage.htm
ttp://www.sonicsoftware.com/customers/index.ssp
ttp://www.oracle.co.jp/appserver/bpel/doc/doc19109.pdf
> それといま時まともにマルチコアライセンスを考えられていないWASなんかの
WASの場合baseライセンス以上だったらCPU無制限だから必要ないんじゃないの。
そんな事言ったらWOの方は何も考えてないじゃん。
> これについては、自分も問題なしとは思わない。
いや、これが一番の問題のハズだが。
大学みたく一部の教育機関を除いてMacでしか動かない案件なんてまず無いよ。
> と言うかこんな不毛な議論より、WOの情報が欲しいだけなんだけどな。
一般人成りすましマカですかね。
始めてWOに触れたのならいざ知らず、今時そんなヤシいるのか疑問ですが。
No.163
5.2.4と5.3.1のフレームワーク上での大きな差異はなく、開発ツールが変わった程度。
テキストエディタで開発してた人たちにしてみればどうってことない。
ライセンス気になるなら5.2パッケージを買ってSoralisなどにインスコすれば良いし。
で、WOのどういう情報が欲しいの？技術的なことなら少しばかり答えられるかも。
No.164
もちろんマクしか動かないようなプロダクトを採用するのもマカだけどな。
テキストエディタって(w
EOMは使わないとどうにもならんよ。EOM無しで開発出来るようなwoaとかcayenneのようなmodelerでも既に開発済み？
5.3がマク縛りなのに、今更5.2をソラリスで動くからって納品出来る無神経ぶりがマカだな。
数ヶ月使えればいいシステム作れば済む次元じゃないし。
数年〜１０年ぐらい使う息の長いシステム作りを要求されるのに、先の見えないプロダクトで納入なんて出来るかよ。
No.165
No.166
No.167
他のベンダがSOAに基づいた技術をどんどん採り入れて開発している事について
不安に思わないのかね。
WOに関係しない技術は基地扱いだし。
>>163
は著しくプロ意識が欠落してるな。
こんなのにお金払ってWeb Site作って貰ってる人は不幸だよ。
成りすましマカ確定ですかね。
No.168
Java捨てて速度命で盛り返してくれ。
No.169
MacOSX Nativeアプリでも作らん限りObjective-Cにするメリットは無い。
No.170
Mac OS X Server限定なら、速度出すためにウニバーサルなObjC版を出したほうがいい。
糞重いiLifeアプリケーションさえJavaじゃなくてObjCだぞ。
No.171
それにJavaだとコミュニティが充実してるので勝手に色々開発してくれる。
ObjCに先祖返りするメリットはないよ。
No.172
今、Xserve G5を買うのはどう見ても得策じゃないし。
WO5.x(Java)でコミュニティが充実して勝手に色々開発してくれる恩恵って特にないし。
ワンダー程度で恩恵受けてるの？
ObjCに先祖帰りするメリットは処理速度。4.5の実行速度を知らない素人？
No.173
WOはメインストリームじゃないから今の位置付けで良いと思うけどなぁ。
EOFは2.1から10年くらい基本構造が変わってないから
そっちの方をなんとかしないと根本解決にはならんと思うよ。
といってもEOFの開発者はMicrosoftに行っちゃったし、今後ドラスティックに変わる事はないよ。
速くしたいんならWASとかWebLogicを使うでしょ。ふつう。
どうせWO使ってる香具師は趣味かその延長だろうから、EOFにスピードを求めるのは間違ってるよ。
No.174
No.175
漏れだったらWO一本じゃハズかしくて飯は食えん。
No.176
WASもWLもマカには使いづらいし。
No.177
No.178
電気屋で５万で売ってるPCすら、持ってない貧乏マカ。
No.179
力を入れるのかと期待したんだけどダメでしたね。
NeXT版以来実に17年ぶりの快挙なんだが、64bit版10gR2出ないよなぁ。
No.180
無難にSolaris鯖使った方が良かったって事に成って、ますますXserveが売れなくなる。
No.181
MacOSXが中途半端に64bit化してるからだめなんだよ。
マク以外の10gは皆64bit版があるから
あえてOracle10gをXserveで使う理由が無い。
No.182
早くフル64bitカーネル出せばいいのに。
No.183
漏れはてっきり、32bit GUIに64bit ビジネスロジックを繋ぐのがへんてこだと思っていたんだが
そういう根深い訳があったんでつね。
ttp://developer.apple.com/macosx/64bit.html
No.184
XPで動くようにしとけば、PCでもマクでも動く訳だし。
No.185
ADCのページも、JBossやTomcatのネタが増えてきたし。
ttp://developer.apple.com/internet/
No.186
iTMSもWOだし。アポーストアもWOだしな
ほとんど自分たちが使う為だけにメンテしてるだけかもしれんが
No.187
早々と出してくるというのは、WOを捨てたという事だろう。
アポーもここに来てようやくメインストリームに舵を切り始めたかな。
ttp://developer.apple.com/java/
No.188
元々NeXT使ってたからマクOSなんてどうでもいいし。
No.189
No.190
ttp://www.itmedia.co.jp/enterprise/articles/0604/28/news060.html
No.191
No.192
No.193
ajaxとかJPAとか取り残されてるし。
No.194
No.195
No.196
ttp://www.apple.com/jp/xserve/howto/parco/index.html
まあjbossならSolarisでも運用出来るからな。Oracle RACとの併用だと、Xserveにする理由が無い。
おまいらまだwo続けられてる？
No.197
いつの時代のこと？？
というか脱woになるほどのシェアだった？
No.198
woのシェアよりはjbossのシェアの方が多い。
No.199
オープンソースで公開すべき
No.200
事実上というより誰がみても完全終了です。
モノはいいと思うがユーザー層が悪すぎｗ
アポー以外がひきとってれば違っていたのかもしれないが。
WOの進化とかサポートじゃなくてユーザーの質って意味でｗ
