SSブログ
今週のJava関連News(06/02/..｜Glassbox Inspector の.. ブログトップ

フレームワークの評価　[Java]

06/01

■はじめに

Web 開発で、現時点でプレゼンテーションレイヤのフレームワークを採用するとするとどれが望ましいかを評価する。要件に応じてどれが良いかは変わるため、一概にどれがよいとはいえないと思えないが、 それぞれのフレームワークの得手・不手の観点から評価する。
・・・と書きましたが、いくつか考えさせられることがありましたので、自分の中での整理してみます。

 ■フレームワーク選定に影響を及ぼす要素

  • プロジェクトチームのスキル・体制
    フレームワーク選定には、技術者としてはいろいろと好みがあるが、現実的な実プロジェクトに適用することを考えると、開発メンバーのスキル、教育コスト、開発・保守体制の要素が、フレームワーク決定に大きく影響を及ぼすと考える。
  • アーキテクチャ全体構成
    システム全てを replaceするならともかく、部分的に新規開発する場合には、現在の全体のアーキテクチャの構成、それに対する接続方式に左右される。つまり、現在のアーキテクチャーに接続するための手段を考慮しておく必要がある。
    例えば、サーバ側がJ2EEアーキテクチャーで実現されていたとしても、J2EE のどのバージョンで稼動しているかに影響を受ける。また、 ローカル接続なのかリモート接続なのかにも影響を受ける。
  • ユーザの要求するUI がどのような機能を要求するかに大きく影響を受ける。
    Rich な UI を要求するのか、Simple な UI を要求するのか？
    フレームワークには、Rich な UI を提供するフレームワークや JSP をベースにしたシンプルな UIを提供するフレームワーク、プレゼンテーションレイヤは他のフレームワークを利用するものと様々である。ユーザ要件によっては、Rich な UI を要求する場合もある。この要求により、選択されるフレームワークが影響を受ける。Flash のような表示を要求した場合、選択できる実現手段は自然と決まることとなる。
  • マイグレーションに関する考察
    マイグレーションの場合、既存のシステムの UI が新規システムの UI に影響を与えることは理解しておかねばならない。例えば、 dotNET アプリケーションを J2EE に移行した場合、いくつか利用できない機能、使い勝手が異なる機能が生じることは必然である。このことをお客様の理解を得ずに技術者先行で選択することは大きな危険を伴うものと考える。
  • フレームワークが提供する機能
  • 標準化・投資される金額
    フレームワークは少数な開発者が作成したものから、複数ベンダーの支援を受けているもの、JSR等で標準化されているものまで多岐にわたる。（技術者の観点から捕らえると少数の開発者が作成したものでも、いいものはイイなのですが・・・）多額の投資、多くの開発者の評価を受けて洗練されたものは、ドキュメント、マーケティング、様々な要素により、広く開発者・ユーザから受け入れやすい環境にある。もちろん、利害関係者の数が多くなるにつれて、要件を詰め込みすぎた仕様として纏まったり、過去の EJB の EntityBean の内容を見る限りは、必ずしも良いとはいえないが、技術的にも洗練されていることが多いことは確かである。

 ■結論（検討中）

最初に述べたとおり、前提要件に応じてどれが良いか変わるため、一概にどれがよいとはいえない。この前提の基、あえて結論をだすとすると、技術者からの観点では、今までの J2EE の問題を改善した Java EE 5.0 が最有力となるのは間違いない。しかし、Java EE5.0 のリリースと開発期間が適合するかどうか、初期バージョンの品質に対するリスク、システムが利用される期間とリスク・教育に対する投資金額が見合うか等考慮する項目も多いと考える。それ以外の選択子で考えると、Rich な UI が必要でない場合には、プロジェクトチームの要員確保の観点からは、Struts(1.3, 1.2選択の基準は以下で述べたとおり) がよいのではないか。Rich な UI が必要な場合は、Browser 上での Rich な UI でよければ、JSF1.1, Struts, Struts-Faces の組み合わせが有力であると考える。ただし、JSF により UI部品 がコンポーネントされたとはいえ、HTML の表現能力を超えることはできないことは認識しておく必要がある。また、お客様の要求に応じて実現技術が決まる場合(Flash, dotNET等)も考えられる。

 ■調査

  • JSF 1.1：(2004/05)
    実際のプロジェクトでもある程度適用されており、IDE、ライブラリ、情報のサポートは大きい。
    MyFaces, Eclipse Plugin(FacesIDE), Struts-Faces 
    しかしながら、おそらく 2006年には、Java EE5 が承認され、JSF1.2 が標準となり、将来的には、Struts と統合されることが決定されているため、移行を考慮すると選択する価値がどれくらいあるか判断する必要がある。
  • JSF 1.2：(2006 GA予定、JavaEE5.0 2006 Q1予定 from 2005 JavaOne)
    JSF 1.2 は JSR252 で検討されている。
     JSF1.1からの大きな変更点はなく、Java EE5に含まれる標準仕様であるため、将来性は有望である。
    変更点は、主にJSPとの統合に焦点が当てられている。１つは式言語（JSF-EL）との整合性をとるというものである。さらに、JSPと組み合わせた場合に発生する問題点の解消などが図られている。
     (Struts の統合は JSF 2.0 で予定)
    ただし、現時点では、Sun のAPサーバ GlassFish プロジェクトのサブプロジェクトとして開発中であり、現段階で採用することは危険を伴う。JSF1.1 をサポートするライブラリ(MyFaces等), IDEは存在するが、1.2をサポートするものは当然公開されていない。（存在したとしても開発中である）
  • WebWork2.2：(06/01/11)
    http://www.opensymphony.com/webwork/
    将来的にはStrutsと統合される方向である。WebWorks経験者が多数いるのであれば別だが、現時点で採用するメリットは大きくはないかと思う。（Strutsに比べると限られた決定機関の中で進められているおかげか）いつくかの先進的な機能を実装していることは技術者の観点では魅力的である。
       - 2.2 は Struts 統合前の最終メジャーバージョンである。
       - Java5 のアノテーション、Generics のフルサポート
       - DWR, Dojo を利用した AJAX のサポートあり。
       - AJAX, JavaScript を利用したクライアントサイドの validation があり。
       - 英語だけど900ページを超える詳細なドキュメントあり。
       - JSR168準拠のPlutoによるPortlet開発が可能
       - JSP, FreeMarker, and Velocity を利用したリッチクライアントを開発可能
       - Spring ,Pico IOC containers のネイティブにサポート
       - タグの構文の簡略化
       - ドメインオブジェクトを含むどんなオブジェクトと動く先進的なデータバインディングフレームワークである。
       - より賢いエラーレポート
  • Struts1.2.8：(05/11/25)
    安定バージョンであり、開発経験者、ドキュメント、IDEの観点でもサポート力が強い。
    実際のプロジェクトで採用することを考えると、一番安全ではないかと思う。
    - Struts 1.2の機能概要に関して
        http://www.mamezou.com/tec/equip015.htm
        http://itpro.nikkeibp.co.jp/members/ITPro/oss/20040810/148439/
    - 1.2.7 から 1.2.8 の主な変更は、XSS の脆弱性に対する改善である。
        http://struts.apache.org/struts-doc-1.2.8/userGuide/release-notes.htm
     - 1.2.4 から 1.2.7 の主な変更点
        http://struts.apache.org/struts-doc-1.2.7/userGuide/release-notes-1.2.4.html

    Struts Scripting 1.0.1 がリリースされている。(06/01/25)旧StrutsBSFと呼ばれていたスクリプトであり、最初の安定版となる。これにより、Struts Actions をJava クラス以外の BSF をサポートするスクリプト(e.g., Perl, Python, Ruby, JavaScript, Groovy, VBScript)等で記述することが可能になる。
  • Struts1.3.0：(06/02/21)
    つい近日リリース。Servlet 2.3, JSP 1.2, J2SE 1.4 を前提とする。
    以下の期待できる機能が実装されている。
    http://struts.apache.org/struts-action/userGuide/release-notes.html
       - Composable Request Processor （Key Feature）
       - ActionDynaForm interfaces
       - Arbitrary configuration properties
       - Catalog and Command Elements
       - Enhanced Global Exception Handlers
       - Extends attribute for XML configurations
       - "isCommitted" Exception Handling
       - Postback Actions
       - Wildcard ActionConfig properties
    Struts 1.3 は、Struts Action Framework と呼ばれている。Struts 1.3 はたくさんのページ群から構成され画面遷移が複雑な Web アプリケーションを想定したフレームワークである。シンプルなWebページであれば、Model1 つまり 1.2.x を利用するほうが望ましいと指摘している。
    http://struts.apache.org/struts-action/index.html
    http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html
    http://www.scioworks.net/devnews/articles/struts_adoption_issues/index.html
  • Struts2.0(Shale)：(未定)
    現在開発中のバージョン。Struts, JSF との統合そして、WebWorks との統合が予定されており、次世代フレームワークのディファクトスタンダートになると思われる。しかしながら、現時点では開発中であり、採用することは難しい。
  • Tapestry4.0：(06/01/07)
    http://jakarta.apache.org/tapestry/
    コンポーネントベースのWebアプリケーションフレームワークであり、デザイン(HTML)とロジック(Javaコード)を分離している点が特徴である。最近メジャーアップデートが発表され、Strutsの開発で挙げられている問題点の多くはShaleで改善される方向に比べ、Tapestryはそれを先んじて検討・実装されていると評価は高い。

    主な特徴は以下のとおりである。
        - 簡素化された新しい4.0仕様DTD
        - バインディングパラメータとして使われる構文の一貫性保持
        - "Friendly" URLの組み込み
        - Listener methodの簡素化と柔軟化
        - Component parameterの改善
        - JSR-168 Portletsサポートの追加
        - HiveMind および Spring のサポート改善
        - JDK 1.5アノテーションサポートの追加(Optional)
        - 新しい、より洗練されたUIヴァリデーション
        - エラーレポートの改善
        - Form の キャンセル機能
        - ページプロパティは、Session 同様 クライアントに対して永続性を保持可能に

    Strutsに比べると開発で利用される機会は少なく、スキルをもつ開発者は多くはないと推察される。また、Strutsに比べるとIDE、ライブラリ、情報のサポートは少ない。
      Eclipse Plugin(Spindle)
  • その他リッチクライアント
    サーバ側との通信は、HTTP/HTTPSプロトコルで電文はSOAPあるいは独自のXML形式というケースが殆どです。 それによりクライアントとサーバが異なるプラットフォームであったとしてもデータ互換性・機種依存性の問題を意識してのことだと思われます。また、最近では配布を意識したソリューションを提供しているため、一昔ほどの導入のハードルは高くなくなっていると考えられます。しかしながら、開発メンバーのスキル、教育コスト、開発・保守体制の要素が、フレームワーク決定に大きく影響を及ぼすと考える。
    ・リッチクライアント(Java)
       - Eclipse RCP
        SWT/JFaceによるレンダリング。配布はUpdate Managerによる。
       - Swing
        - Swingによるレンダリング。配布はJava Web Startによる。
    ・リッチクライアント(.NET)
       - dotNET
        ASP.NET/Web Form/Mobile Web Form/Windows Formなどを利用する。
    ・Macromedia FLEX
       FlashをUIに使いたいJ2EE開発者に最適なリッチクライアント開発環境で、
       サーバサイドはMXMLという タグベースのXML言語にてページ記述。
    ・その他
       - Curl
       - BizBrowser

 ■References


2006-02-22 16:26  nice!(0)  コメント(2)  トラックバック(107) 
共通テーマ：パソコン・インターネット

nice! 0

コメント 2

えなり


おっさん童★貞が15万ゲットォォォ！！！！
若いコに筆おろししてもらえるとかマジ勝ち組すぐるｗｗｗｗｗ

ていうか女とやるって意外とカンタンなんだなｗｗｗｗ
最近じゃ俺のメタボディを武器に、おにゃのこハメまくりっすよ！(*ﾟ∀ﾟ)=3
http://3bmgo8j.becquerel.tubuyaku.com/3bmgo8j/
by えなり (2011-04-03 06:02) 

師子乃

こんばんは。

勉強させていただきます！
by 師子乃 (2018-12-05 20:31) 

コメントを書く

お名前：[必須]
URL：
コメント：
画像認証：
下の画像に表示されている文字を入力してください。

トラックバック 107

今週のJava関連News(06/02/..｜Glassbox Inspector の.. ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。