arton】第4回TheServerSide.comを読んでみよう──筆者のJava情報源を公開arton2004.05.25コピーしましたPRJavaの面白さの1つに,情報が拡散しているということがある。注:この記事では日本語サイトが存在する場合はそちらのURLを紹介している)に集約されていると考えてよい(最近ではGotDotNet)のようなコミュニティ指向のサイトも存在するが)。したがって,定期的にMSDNをウォッチしていればマイクロソフトの技術動向についてはだいたい押さえることが可能だ。これはシステムを構築する側の我々にとっては有難い。企業システムは1度構築してしまうと,プレゼンテーション層(Webのユーザー・インタフェースなど)を除けば数年から10年近くは大幅な変更はできなくなる可能性が高い。それを考えると,やはり数年後にどのようなテクノロジが主流になるのかを見届ける必要がある。表裏の関係としてヴェイパーウエア(実際には存在しない製品)に惑わされる危険性や,大して意味があるわけではないマーケティング的な(実質的なテクノロジを伴わない)バズワードに惑わされる可能性もある。言って,テクノロジ・トレンドを無視してシステムの寿命よりはるかに短命にフェードアウトしてしまうテクノロジを採用してしまえば後々苦労することになる。その時点でシステムの基盤としているテクノロジがなくなっていれば,本来単純な修正で済むはずのものがシステムの再構築同然の作業になってしまう可能性があるのは自明だ。通常はベンダーもフェードアウト後しばらくはサポートするわけだが,それにしても既にフェードアウトしたテクノロジ上に新たなサブシステムを追加するといった作業はどうしてもプロジェクト遂行のモチベーションが低くなりがちになるのは避けられない。これがメインフレーム時代であれば,いずれにしろメインフレーマから情報を受けるしか他に手段がないから,それでも良かったのかも知れない。オープンシステムはベンダー同志も厳しい競争にさらされているわけだから,次から次へと新たな手を打ってくるのは,それは当然のことなのだ。そのため,結局,自分達の手で情報収集することは欠かすことができないことなのだ。J2EEでシステムを構築すると決めたとしよう。どこから情報を収集すればよいのだろうか?もちろんマイクロソフトがそうであるように,Javaに関連した製品を出荷しているベンダーサイトからの情報発信はある。それらはそれぞれ質が高い情報を提供している。例を挙げればSun(「本家」java.sun.comやJDC,昨年できたjava.netがある)やIBMのdeveloperWorks,BEAのdev2devなどだ。ここで挙げたサイトはベンダーが提供する情報とは言え,必ずしもそのベンダーの特定製品に偏ることなく,広くシステム構築やプロジェクトの進め方,あるいはプログラムの実装といった各種ノウハウや技術動向についての記事を提供していることが特徴だ(それもJavaがオープンプラットフォーム――いささか微妙な表現ではあるが――だからこそ可能なのだろう)。IBMのdeveloperWorksは翻訳にも熱心だし,一貫して質が高い情報を提供しているため好感度が高い。情報の質は高いにも関わらず,これらのサイトがマイクロソフトのMSDNにかなわない点が1つある。それは,これらのベンダー情報サイトをウォッチしているだけではJavaの最新動向が掴めないということだ。3週間ほど前EJB3.0の概要が明らかになったが(参照記事),この動きはこれらベンダーのサイトをウォッチしているだけでは,ほとんど予測できなかったのではないだろうか。Symposiumという外部の1企業が主宰するイベントで次期仕様が明かされるということも異例に感じられるかも知れない。Frameworkの仕様のように大きな影響を持つ発表がPDCやTechEDのような正規イベント以外で行われ,それがニュースとなるということは考えにくい。翻ってみれば,以前Javaをオープンソースにするかどうかが話題になったことがあるが(参照記事)。Javaそのものがオープンソースかどうかは別としても,これらの動向を見ている限り,Javaの仕様に関しては十分にオープン性を保持していると言えるだろう。どこでそれを知ることができるのか?」という疑問を持たれるかも知れない。Process(JCP)のWebサイトである。Requests(JSR)と呼ばれる一群の文書(レビュー中,初期ドラフトレビュー,公開レビュー,正式承認後のメンテナンス・レビューに分かれている)をウォッチしていればある程度までは予測が可能かも知れない。1.5で導入されるメタデータを利用することや,環境への依存性とJNDIアクセスをカプセル化する便利なユーティリティクラスや/とファクトリパターンの提供といった項目が挙げられている。言え,JSRはベースとなる議論ではなくその結果としてのリクエストなので,なぜそのようなリクエストが生まれたかといった背景までがわかりやすく提示されているわけではない。Symposiumを主宰したTheServerSide.comだ。Companyというトレーニングとコンサルティングの専門企業で,.同様にTheServerSide.NETという.NETのコミュニティサイトも運営している(筆者の見た感じだとこちらはGotDotNetという強力なライバルがいるためか,TheServerSide.comほどには成功していないように見える)。TheServerSide.comのメインコンテンツはコミュニティベースのBlog(スラッシュドットなどと同様)で,トップレベルに投稿時刻とコメント数付きでヘッドラインの列挙があり,それらをクリックすると,実際の記事とそれに対する読者のコメントが読めるようになっている。ニュースやコメントは登録すれば誰でも投稿できるため(その他,署名記事などもある),そこで種々の論議が行われるのが特徴だ。各記事のコメントの数を見ればある程度まではどのような動向に関心が集まっているのかを知ることもできるだろう。sides」という記事が253コメントで特にホットだということがわかる。ちなみに,この記事の執筆時点でのTheServerSideへの登録者数は360,777人だ。読むだけなら登録の必要はないため実際の読者数はもっと多いかも知れない。この人数が,EJB3.0の発表にJavaOneを待たなかった(待つ必要がなかった)という推測もできるだろう。読者の参考までにTheServerSide.comから軽量コンテナ(DIコンテナ:注:EJBではなくPOJO=通常のJavaオブジェクトを利用するコンテナ,DIに関する解説はこちらを参照)関連のニュースのリンクを示す。Injection)に関してどのような動きがあったかをおさらいすることができるだろう。Frameworkとの依存性注入の方法論の違いによるちょっとしたフレーム(論争)が起きている。PicoContainerは,最初コンストラクタベースの依存性注入をサポートするコンテナとして開発された。この場合,コンテナによって生成されるPOJO(ビジネスロジックを実装したオブジェクト)は,依存するインタフェースをコンストラクタで受け取るように記述する。Johnsonによる署名記事を受けたもの。Frameworkは最初,依存性注入にセッタメソッドを利用するように開発された。Burkeのインタービューを受けたもの。FowlerがIoCという呼び名からデペンデンシ・インジェクション(依存性注入)という呼び名への変更を提案したことを受けたもの。Hellesoy(PicoContainer)によるIoCコンテナからの名称変更への同意がある。この時点では両者はコンストラクタとセッタのいずれでも依存性注入可能としている。Colyerの見解を受けたニュース。Burkeのコメントで,コンストラクタベースの依存性注入ではビーンのプーリングに対応できないためEJB用にはならないという指摘が興味深い。本稿ではもっぱら依存性注入(DI)に関するページを取り上げたが,同様にCMPからJDOやO-Rマッピングなどについての論議もあるので,それらについても一読をお勧めする。arton謎のITエンジニア。RTOS上でのデータベースエンジンを皮切りにミドルウエアやフレームワークとそれを利用するアプリケーションの開発を行い現在に至る。専門分野がある業界に特化しているために逆にメインフレームクラスから携帯端末まで,その時の需要に応じてダウンサイジングしたりアップサイジングしたりしながらオブジェクトを連携させていくという変化に富んだ開発者人生を歩んでいる。最近はもっぱらJ2EEが主戦場。各種ブロックチェーン事業に携わった経験を整理し、適切なブロックチェーン事業の企画について、実践的...システム再構築の要件定義テクニック課題解決に役立つ機能を分析し、新システムに継承すべき機能を絞り込み、不要な機能は削除す―。新シス...シニア・ベテラン社員マネジメント講座シニア社員のモチベーションを高め、活躍を後押しできるマネジャーになるための講座です。情報銀行の成り立ち、事例、現状課題やその行方を網羅。経営戦略である以上、「会計」の知識やスキルが欠かせません。