arclamp.jp アークランプ

OSGi以外はすべてSeasar Projectで対応プロダクトがあるよ。
Seasarのことを知らないだけでは。

もちろん、プロダクトがあるのは知っていますよ。ただ選択肢はSpringの方が多いです。メッセージングフレームワークで言えば、ServiceMix、Mule、Apache MQがSpringサポートをしていますし、Spring Integrationもあります。
もちろん、MuleのSeasar対応があったりして動かせないわけではないですが。

そう考えるとSpringを統合プラットフォームとして考えている人が多いこと自体がアドバンテージかもしれません。多くのフレームワークが勝手にSpring対応はしてくれるので。

自分が必要としない選択肢がいくらあっても生産性にはつながりません。安心感にはなるけどね。

Seasar2の場合、Springほどの選択肢はありませんが、使いそうなやつは大体そろっていると思いますよ。

規模で世の中の 80% を占めるところのエンタープライズシステムじゃ ServiceMix も Mule も Active MQ も使ってないでしょう．どれも RDB でいうと Derby みたいな位置づけじゃないですか．言い方は悪いけど相手にもされないのが現実でしょう．PTP なら IBM WebSphere MQ，Pub/Sub なら TIBCO Rendezvous，SOA/SCA/ESB は話題にもならないのが真のエンタープライズです (暴言)．

ともあれ (JW)，大規模なプロジェクトでメッセージングを含めたインフラが大きな工数を占めるとは思えません．100 人くらいのプロジェクトだとインフラ担当はせいぜい 10～20 人くらいじゃないでしょうか．っていうか，Spring との連携なんてインフラの仕事じゃないですね．そんなのはアプリの中の一部分に過ぎなくて，直接関わるのは 100 人くらいのプロジェクトだとどんなに多くても 5 人くらいでしょう．全体の工数を大きく左右する要素ではありません．

一方で，100 人中の 50～60 人くらいは画面を出したり DB にアクセスしたりメッセージの中身を扱ったりするコードを書くわけです．工数にインパクトがあるのはどう考えてもこっちです．そこで SSH 等を採用しても，Spring は Struts/Hibernate などとの穏やかな連携を提供するだけで，より高水準な方向への拡張は (意図的に) 提供しないですよね．つまり，SSH を採用するということは，裸の Struts，裸の Hibernate を使うことと大差ないわけです (暴言？)．そのため，SSH 等の上により高水準なアプリケーションフレームワークを「自前で」，繰り返す「自前で」，構築する必要があるわけですが，それは大手 SIer にとってさえも簡単なことではなく，ひがさんに声がかかったり，SAStruts や S2Dao を Spring でも使いたいという声になるんじゃないでしょうか．

Spring を支持する人達はそこにもっと目を向けてもいいんじゃないかな．例えば JSUG が中心になってより上位のフレームワークを OSS で開発するとか．それを Seasar2 でも使いたいなんて言われるものが出てくると面白いと思うんですけどね．

「SSH 等の上により高水準なアプリケーションフレームワークを「自前で」，繰り返す「自前で」，構築する必要がある」と言うことですよ。単純に。もちろんSAStrtusをSpringで使うのもOK。

ただ、Springだからダメとか、SeasarだからOKというのは違うと思う。プロジェクトや会社によって生産性の定義は違うから、正解なんてない。自分できちんと選ぶことが大事。それをフレームワークのせいにしていることが問題だと思います。

このエントリの本文は，規模で世の中の 80% を占めるところのエンタープライズシステムでは Spring の方が生産性を高められると主張しているようにしか読めないのですが，その根拠らしきものを否定するコメントを付けたのに，その返答がこのコメントというのは拍子抜けというか肩すかしというかガッカリです．
自分としては，本文の主張 (エンタープライズシステムでは Spring の方が～) の根拠たり得る説得力ある意見が聞きたかったですね．

たぶん、ゆーすけが勘違いしているのは、誰もSpringがだめで、SeasarがOKとは思っていないということ。

そして俺が言っているのは、Springは選択肢が多いことがメリットだけど、選択肢が多いこと自身は生産性には関係ないこと。

ゆーすけを見ていると、選択肢が多いことを主張するだけで、その先がない気がするよ。

Seasarな人たちは、生産性を向上させるために一生懸命いろんなものを作っているわけじゃない。Springな人たちもそういうことを積極的にやってもいいと思う。

選ぶことが大事じゃなくて作ることが大事なのでは。

> koichik:
エンタープライズという観点で言うなら、現状バッチや分散(Remoting, Messaging), セキュリティに関わる部分でSeasarはSpringに全然勝ててないでしょ。
ミドルウェア自体は商用だろうがオプソだろうがどうでも良い訳で、WebSphereMQとかTibcoを出して反論している時点でズレてるよね。
まあ、Seasarの優位点とすればJTA実装持ってるくらい？でもそれこそミドルウェアで代替するとこだし…
（そもそもS2系のRemoting, MessagingってISID絡んでいないところで誰か使ってるの？）

> 裸の Struts，裸の Hibernate を使うことと大差ないわけです
それで何か問題あるの？Spring2.5系ベースで見るとHibernateやJdbc系は最低限の抽象化は
されているし、Struts2なんてSpringとの親和性はバリバリでしょ。
拡張する処理が必要だったらそれぞれにInterceptorかますだけだし、現状の抽象度で何も困らんよ。

そもそも裸のStrutsに対比されている(のかな？)SAStrutsの仕様でStrutsとして主張するのは
詭弁以外のなにものでもないよね。
あんな独自仕様にヒットするターゲットはアーキテクトがそれほど拡張しなくても許される程度の
シンプルなWebアプリあたりでしょ。基盤として使う側からすると、アプリケーションレイヤーの
考え方が短期間でブレまくるアーキテクトの作るフレームワークはあんまり信用できない。申し訳ないけど。

あ、誤解の無いように書くとRailsと同じコンテキストをターゲットにしてるならSAStrutsでも全然いいと思うよ。
要はターゲットが違うのにSpringを敵視しないでねって事で。

> そもそも生産性を上げるためには、アプリケーションの部位毎に個別最適化していき、
> それらを統合するというのが正しい戦略です。

この戦略が正しいと考えた理由に興味があるので、
宜しければ教えて頂けないでしょうか？
（最初から全体最適を目指したものとの戦略の違いが気になっています。）

Seasarの人たち大丈夫？さん：
> それで何か問題あるの？

問題を抱えてる人たちがいるというのが発端になってるわけですが．それは Spring そのものの問題じゃないということは分かるのだけど，Spring を使っていて問題を抱えている人が複数いるならもっと問題を共有して一緒に解決していってもいいんじゃないのかな．っていうことを問題だと思ってない人に言ってもしょうがないか．

> 要はターゲットが違うのにSpringを敵視しないでねって事で。

ターゲットが違うかどうかは知らないけど，敵視してるつもりもないですよ．
規模で 80% を占めるところのエンタープライズシステムというコンテキストで，Mule や ActiveMQ を出して「Seasarに比べて大きなアドバンテージ」があるなんて言われたら，それはアドバンテージじゃないだろと突っ込みたくなるというものです．そのコンテキストでその理由はありえない．じゃあ，そのコンテキストでアドバンテージになってるのは何なのか，なるほどと思えるものが聞きたかったのですが，その後のコメントも次のエントリも違う方向に行っちゃってますね．それだったらエンタープライズだとか Seasar に比べてとか書く必要はなかったんじゃないかと．

DIによるエンタープライズ連携機能の充実度合いでSpringにアドバンテージがあることで生産性に優位ということのようですが、CTCやNTT-Dが悩んでいるのはそれら連携機能を使いアーキテクチャを設計したけれども、開発にかかる時間は簡単には減っていかないですよね、ということじゃないでしょうか。
ソースコード修正後にアプリケーションサーバの再起動が必要なくなるS2のHotDeployは、規模が大きくなればなるほど開発時間にダイレクトに影響してくるはずなのに話題に上らないので残念です。「システム全体として生産性の高さ」というのは、開発全体にかかる時間ということかなぁと思ったのですが、それを言うとプロジェクト内のアーキテクチャ設計チームより、業務実装チームの方が人数も工数も多いはずだし、HotDeployの影響は大きいんじゃないかと。
生産性（開発時間）という観点ではS2の方がしっかりフォーカスしているんじゃないでしょうか、と思いました。

通りすがりさんへ

部分最適は統合を前提としていますので、全体からの視点は当然あります。

例えば車であればエンジン、ボディ、シャーシと言った要素は、相互に統合されることを前提として部分最適化ます。ただ実際には各部位個別要件から統合には調整が必要になるのでインターフェースは曖昧なまま作業が進むことになります。

全体視点なく部分最適をするのは、崩壊を招くことで、ここで意図するモノではありません。

こうすると部分最適ではノリシロとして統合コストがかかることになります。ですが、それでも良い。
全体最適の欠点は、「全体を一度に考えてしまう」というように単純化した場合に、複雑さの限界を迎えやすいことです。

ですから、複雑さを階層化し、部分最適化を統合していくという階層化が効率化につながります。

ちょっとずれてしまう例ですが、道具の歴史でも似たようなことがあります。包丁にもたくさんの種類があります。それぞれの作業に最適化されていた方が、包丁を1本だけ買うことよりも、結果的には効率的であるということです。