SSブログ
Java ブログトップ

今週のNews(06/05-)　[Java]

引越し等々で整理できずじまいの時期が続いてましたが。

○一般

  • SI業界再編の予兆
     伊藤忠商事グループのIT関連会社である伊藤忠テクノサイエンス（CTC）とCRCソリューションズが、10月1日付で合併すると発表しました。合併後の新社名は「伊藤忠テクノソリューションズ」で、両社の売上高合計は3,000億円規模となります。
     http://blogs.itmedia.co.jp/matsuoka/2006/05/si_2034.html?itmh530b

○JDK, JavaEE5

○AJAX

○JavaOne 2006

○その他


2006-05-31 17:48  nice!(0)  コメント(1)  トラックバック(32) 
共通テーマ：パソコン・インターネット

Struts 1.3　[Java]

○はじめに

  • Struts 1.3 もリリースされたようですので、主な変更点を整理してみます。

○Struts Action Library

  • Struts 1.2.8 から、Struts を複数のサブプロジェクトに分割し、おのおの個々のリリースサイクルを持たせるように変更されました。具体的には、Struts の subproject には、以下の７つが存在します。
    - Action
    - Applications
    - EL
    - Extras
    - Site
    - Taglibs
    - Tiles.
     これらのサブプロジェクトは、Struts 1.3 にも継承され、同じライブラリを使用しますが、
     今後 subproject の revision は(Struts1.2系列、1.3系列)個々に変更されることとなるようです。

○依存関係に関する変更

  • 仕様に関する変更
    Servlet 2.3, JSP 1.2, J2SE 1.4 に依存
  • ソフトウェアコンポーネントに関する変更
    Commons Chain 1.0, FileUpload 1.1, Commons IO 1.1, Commons Validator 1.2 に依存

○Struts 1.2, 1.3 の採用基準に関して

  • Struts 1.3 はたくさんのページ群から構成され、画面遷移が複雑な Web アプリケーションを想定したフレームワークです。シンプルな Web アプリケーションであれば、Model1 つまり 1.2.x を利用するほうが望ましいとのことです。

○Struts Action Framework

  • 主な変更点は以下のとおりです。以下で個々の変更点を整理してみます。
     - Composable Request Processor 
     - Arbitrary configuration properties 
     - Catalog and Command Elements 
     - Opt-In Cancel Handling 
     - Enhanced Global Exception Handlers 
     - Extends attribute 
     - "isCommitted" Exception Handling 
     - Postback Actions 
     - Wildcard ActionConfig properties

○Composable Request Processor

  • 以前のバージョンでは、Request Processing は、以下のように一連のメソッドとして表現されていました。よって、メソッドを override し、異なる機能を提供することは容易でありました。しかし、それぞれが異なる方法で Request Processor を override し、複数の拡張を利用することは容易くありませんでした。
    public void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { processLocale(request, response); if (!processRoles(request, response, mapping)) { return; } /// ... ActionForward forward = processActionPerform(request, response, action, form, mapping); processForwardConfig(request, response, forward); }
    そこで、Action 1.3 では、Request Processor のメソッドを Command に変更します。これにより、モノシリックなオブジェクトをサブクラス化するのではなく、Command を取り替えることができるようになります。
    Command は、挿入したり、除いたりすることができ、もし、必要ならば、異なる種類のアプリケーションのニーズに適合させるために、Request Processing を拡張させたり、不要なCommandを除き、合理化することが可能となります。
    <chain name="process-action"> <command className= "...SelectLocale"/> <command className= "...AuthorizeAction"/> <!-- ... --> <command className= "...CreateAction"/> <command className= "...ExecuteAction"/> </chain>
    以前のバージョンと互換性を確保していることは、もちろん期待されています。よって、追加の変更を加える前に、Composable Request Processor を持つ 1.3 をリリースすることとなったようです。Action 1.3.x で変更や向上がされる予定です。もし必要ならば、Struts 1.2 からのモノシリックな Request Processor を利用することも可能です。
    <controller processorClass="org.apache.struts.action.RequestProcessor"/>
    ただし、モノシリックな Request Processor は、Legacy Class と位置づけられており、Opt-In Cancel Handling のような新機能は Composable Request Processor のみによって、サポートされるようです。

○Arbitrary configuration properties

  • ほとんど全ての Struts の設定の要素は、key/value のペアの対応づけを可能とします。これにより、設定を外部化することが可能となり、再利用化を促進することが可能です。
    <action path="/EditSubscription" extends="Editor"> <set-property key="foo" value="bar"/> </action> public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { string foo = getProperty("foo"); // ...

○Opt-In Cancel Handling

  • Struts 1.2 およびそれ以前では、キャンセルタグにより生成されたトークンがリクエストの中に存在する場合はどんなときでも、ActionForm に対するvalidationはスキップされていました。よって、Struts 1.2 およびそれ以前では、validation に依存する Action は常に isCancelled メソッドをチェックする必要がありました。
    Struts Action 1.3 では、新しいプロパティの"canccellable"がAction Mapping でセットされているときのみ、キャンセルトークンは有効となります。もし、キャンセルトークンが存在し、cancellable がセットされていなければ、 InvalidCancelException が throw されます。InvalidCancelException は、他の例外のように Declarative Exception Handler によって catch されます。
     Declarative Exception Handler は、オプションの位置づけとなります。
    <action path="/ActionThatCanBeCancelled" validate="true" cancellable="true" ... > <exception key="errors.invalidCancel" type="org.apache.struts.action.InvalidCancelException" path="/InvalidCancelException.jsp"/> </action>
  • ※注意点：
     Opt-In Cancel Handler は、1.3 で導入された Composable Request Processor を使用する場合のみ有効となります。標準の CANCEL BUTTON を使用し、mapping の定義として validate を true にセットした場合には、mapping の定義として "cancellable=true" と指定しなければなりません。
     さもなければ、キャンセルボタンが使用されたときには、InvalidCancelException が throw されます。

○Enhanced Global Exception Handlers

  • ActionConfig が認識できない場合の Global Exception Handlers の利用をサポートします。ActionConfig が存在しない場合、AbstractExceptionHandler は、ModuleConfig 内の新しいメソッドを呼び出します。このメソッドは、与えられた例外クラスもしくはスーパークラスに対応付けられた例外ハンドラを探す同様のロジックを提供します。

○Catalog and Command elements

  • Controller と どんな Action Mapping の両方で利用可能です。
    - catalog：commons-chain catalogの名前
    - command：commons-chain command の名前
     
    ※要調査。理解できていないため、原文を掲載
     catalog - The name of a commons-chain catalog in which to look up a command to be executed as part of servicing this request. Only meaningful if "command" is also specified.
     command - The name of a commons-chain command which should be looked up and executed as part of servicing this request.
    <controller inputForward="true" catalog="Foo" command="FooBar"/>

○Extends attribute

  • Struts の 設定ファイルでは、他の要素からのディフォルト設定を適用するために、拡張した属性を使用することが可能となります。OOプログラミングの継承の概念を設定ファイルに持ち込んだと考えるとわかりやすいかもしれません。
    <struts-config> <form-beans> <form-bean name="registrationForm" type="org.apache.struts.action.DynaValidatorForm"> <form-property name="firstName" type="java.lang.String"/> <form-property name="lastName" type="java.lang.String"/> </form-bean> <form-bean name="managerRegistrationForm" type="org.apache.struts.action.DynaValidatorForm" extends="registrationForm"> <form-property name="department" type="java.lang.String" /> </form-bean> </form-beans> ... </struts-config>

○"isCommitted" Exception Handling

  • Tiles を使用する場合、Exception が発生したとき、レスポンスは既にコミットされている場合があります。今回の変更により、ExceptionHandler は、response.isCommitted をチェックし、もし、true ならば、フォワードするのではなく、設定された view path を含みます。更新された ExceptionHandler は、新しい設定の属性を許容します。これにより、他の振る舞い、もしくは振る舞いがないことをを選択することが可能となります。
    <exception key="GlobalExceptionHandler.default" type="java.lang.Exception" path="/ErrorPage.jsp"> </exception> <exception key="GlobalExceptionHandler.default" type="java.lang.Exception" path="/ErrorPage.jsp"> <set-property key="SILENT_IF_COMMITTED" value="true" /> </exception>

○Postback Forms

  • Form taglib のAction属性はオプション扱いとなりました。もし、省略した場合、リクエストの元のURIが使用されます。
    <html:form onsubmit="return validateLogonForm(this);">

○Wildcard ActionConfig properties

  • Wildcard は ActionConfig のプロパティの中で使用されます。これにより、"parameter"属性を複雑にさせずに、複数のリクエスト時の値を Actionに渡すことが可能となります。
    <action path="/Save*" name="Save{1}" extends="BaseSave"> <set-properties key="Save" value="{1}"/> </action>

○Other Miscellaneous Changes

  • 設定を介し DynaActionForm プロパティの値をリセットすることをサポート
  • Servlet2.3で導入された HttpServletRequestWrapper を拡張するMultipartRequestWrapper を変更
  • マルチパートリクエストでのフィールドごとの文字エンコーディングをサポート

○Struts EL
○Struts Extras
○Struts Site
○Struts Taglibs
○Struts Tiles

  • →リリースノート参照

○References


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

Glassbox Inspector の評価　[Java]

○はじめに

  • 現在評価中。まずは実際に動作させてみた所感を。

    Web プロジェクトを担当することにより、性能改善に関しては何度も苦労させられました。プロファイラも高価であり、評価したい観点を評価できないケースが利用できなかったころ、私は、複数のプロジェクトで汎用的に利用可能なツールにより性能を分析することができないかと試行錯誤しました。

    初期の段階は、各処理で現在時刻を出力することにより、処理間の処理時間を把握し、ボトルネックがどこにあるのかを確認していました。（処理時間の正確なベンチマークをおこなうことが目的ではないため、これで十分でした。）しかしながら、現在時刻を出力するコードを追加し、本番時には削除することは、開発者の作業量の増加に繋がるという課題も残っていました。（log4j などのログレベルでの制御も可能ですが、評価するアプリケーションの制御、評価する処理の制御などの観点により細かい制御は難解でありました。）

    よって、次の段階では、AOP を用い、ログ出力のコードを開発者の手を煩わせることなく、動的に追加することを模索しました。この段階で、開発者に対する負荷をかけずに、ログ評価アプリケーション・箇所の制御をより容易におこなうことを実現させることができました。

    これで、複数のプロジェクトで利用できる汎用的な性能分析ツールの実現には成功したわけですが、将来的には、性能ログだけでなく、コネクションプールの利用状況などシステム全体の状況を把握し、問題の検知、警告、改善を促すことを一元管理することはできないかと考えておりました。 全てのセンサーを MBean で実現し、JMX 経由で管理すればできるなとは思っていました・・・

    ・・・が、そこまでは実現できておりませんでした。そんな中で、Glassbox Inspector という当職が考えていたことを、より実用的に実現されていたツールを見つけ、感激していたのですが、なかなか時間を割くことができず、評価はできておりませんでした。

    前置きが長くなりましたが、今回はこのツールを実際に利用してみて評価したいと思います。

    このツールに関する記事は、IBM developerworks の  AOP@Work: Performance monitoring with AspectJ, Part 1, 2 の記事として公開されています。 よく纏まった記事だと思いますので、ご覧になってみてください。
     http://www.ibm.com/developerworks/java/library/j-aopwork10/index.html
     http://www.ibm.com/developerworks/java/library/j-aopwork12/index.html

○スクリーンショット

○評価結果

  • まずは実際に動作させてみた状況で詳細は調査中ですが、所感としては、期待通りのツールで満足しています。
  • developerWorks の記事では、発行したSQL文を把握することが可能であるようですが、実際に検証した結果、取得できていないケースもあるようです。（理由は不明、調査中）
  • Web システムの性能となると、Java プログラムの処理時間も評価ポイントとなりますが、DB に対して、どのような SQL を発行し、どのようなアクセスパスで実行されたかも評価ポイントとなります。DB に対する情報ももう少し取得することができないか検討してみたいと思います。

○動作検証環境およびライブラリ

  • Spring のサンプルアプリケーションである jpetstore で検証をおこないました。 DB は、サンプルアプリケーションのディフォルトの設定を利用することにしました。具体的には、hsqldb を利用します。 動作検証環境およびライブラリの詳細は以下のとおりとなります。

    Windows XP, JDK 1.5.0_03, Tomcat 5.5.7, Glassbox Inspector 1.0 beta2, hsqldb Spring 1.2.5(Glassbox Inspector同梱), Spring サンプルアプリケーション(jpetstore)

○設定手順

  • ここでは最低限の設定内容しか述べていません。詳細な情報に関しては、各アプリケーションのドキュメントをご覧ください。

○Glassbox Inspector 関連の設定

  1. AspectJ の Load-time weaving を有効するために、AspectJWeaver をtomcat の起動オプションに追加する。
    １．１．スタートメニューから、「Configure Tomcat」を選択し、tomcat のプロパティを編集するGUIを起動する。
    １．２．「Java」タブの「Java Options」に以下の行を追加する。
       -javaagent:C:\Program Files\Apache Software Foundation\Tomcat 5.5\shared\lib\aspectjweaver.jar
    ※Glassbox Inspector のWebページでは、バッチファイルに記述する手順を述べている。
  2. aspectjweaver.jar を クラスパスで参照できる場所にコピー
    %TOMCAT_DIR%/shared/lib にコピーする
  3. GlassboxInspector ライブラリをクラスパスで参照できる場所にコピー
    %WEBAPP_DIR%/WEB-INF/lib にコピーする。
      使用するライブラリは以下のとおりである。
      glassboxInspector.jar, commons-collections-3.1.jar, emory-util-1.4.jar, log4j-1.2.9.jar, spring-1.2.5.jar
    ※クラスローダ上で log4j.jar が競合し、動作しなかったため、現時点では、GlassboxInspector のライブラリは各アプリケーションの WEB-INF/lib ディレクトリに格納している。GlassboxInspectorのホームページで述べられた設定内容とは異なる。
  4. サンプルアプリケーションの log4j の設定に Glassbox Inspector の設定を加える。
    log4j.category.glassbox=INFO

○hsqldb の起動

  1. hsqldb の起動
    必要な設定はおこなわれているので、DBサーバを起動する。
      %SPRING_SAMPLES_DIR%/jpetstore/db/hsqldb の server.bat を実行する。

○tomcat の起動

  1.  スタートメニューから、「Configure Tomcat」を選択し、tomcat のプロパティを編集するGUIを起動する。
  2. 「General」タブの「Start」を選択し、tomcat を起動させる。
  3. %TOMCAT_DIR%/logs/stdout_date.log を確認し、正常に tomcat が起動していることを確認する。

○ブラウザでの動作検証

  1. jpetstore の Webページにアクセスし、正常に表示されることを確認する。
     URLは以下のとおりである。
      http://127.0.0.1:8080/jpetstore/

○Glassbox Inspector の動作検証

  1. 以下のコマンドで jconsole を起動し、Glassbox Inspector が提供する MBean の情報を確認する。
    jconsole service:jmx:rmi:///jndi/rmi://localhost:7132/GlassboxInspector

2006-02-23 15:03  nice!(0)  コメント(0)  トラックバック(214) 
共通テーマ：パソコン・インターネット

フレームワークの評価　[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) 
共通テーマ：パソコン・インターネット

J2EE design decisions　[Java]


J2EE design decisions(written by Chris Richardson)
http://www.javaworld.com/javaworld/jw-01-2006/jw-0130-pojo_p.html

■概要
 POJOs in Action（Manning Publications, January 2006） からの抜粋
 「Patterns of Enterprise Application Architecture」の考え方をJ2EEの世界をベースに、より実装に近い観点で論述された記事と考えてもらうとわかり易いかもしれません。新規性に富んだ話は多くはなかったですが、よく纏まった記事かと思います。

■要約
最近 POJOs、ライトウェイトフレームワークの話題が賑わせていますが、盲目的にそれを利用することは、EJB で犯した問題を繰り返すことになると警告しています。どんな技術でも強みと弱みがあり、それを理解してデザインを決定することが重要であると述べています。

大きく３つの選択肢があると述べています。

  • EJB2 style
  • POJO と ライトウェイトフレームワークの組み合わせ
  • EJB 3

この記事では、デザイン決定のための５つの観点を指摘しています。

Decision 1: Organizing the business logic

  • オブジェクト指向のアプローチか(Domain Model pattern)
  • 手続き型のアプローチか(Transaction Script pattern)

Decision 2: Encapsulating the business logic

  • EJB session facade(Figure 4.)
  • POJO facade(Figure 5.)
  • Exposed Domain Model pattern(Figure 6.)

Decision 3: Accessing the database

  • JDBC directly（良い選択ではない）
       - 開発やメンテナンスは難しく、コストがよりかかる。
       - SQLのポータビリティの観点で欠けている
      - JDBCコードの記述は時間がかかり、エラーを起こしやすい
  • object/relational mapping frameworks (such as JDO and Hibernate)
  • SQL mapping frameworks (such as iBATIS)

Decision 4: Handling concurrency in database transactions

  • Isolated database transactions
  • Optimistic locking
      - テーブルにバージョンカラムを追加する方法が一般的
      - JDO や hibernate のようなフレームワークは Optimistic locking の機能を提供
  • Pessimistic locking
      - 更新処理の最初に共有データをロックする方法
      - JDO は設定オプションとして Pessimistic Locking の機能を提供
      - Hibernate は locking object のためのプログラミング可能なAPIを提供

Decision 5: Handling concurrency in long transactions

 


2006-01-30 17:19  nice!(0)  コメント(0)  トラックバック(16) 
共通テーマ：パソコン・インターネット
Java ブログトップ

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