Ｗｅｂアプリケーションが本格的に使用されて来た事で、そろそろ次世代論が 言われつつあります。 Ｗｅｂサービスをにらんだエンタープライズアプリケーション化と、ユーザー アクセシビリティーの向上をにらんだ、リッチクライアント化です。 この流れは、相反する者ではなく、ベクトルが異なっているだけです。
Ｗｅｂサービスは、Ｊ２ＥＥ と ．ＮＥＴ の陣営が、それぞれしのぎを削っていますが、 現段階では、Ｊ２ＥＥ 陣営（Ｊａｖａ系）で進めています。 Ｗｅｂサービスも、鳴り物入りで出てきた割には未だに本格的には立ち上がっていない 状況です。Ｊ２ＥＥに関しても、まだまだ開発工数がかかり、デスマーチに陥る プロジェクトが、後を絶ちません。
※ プロジェクト成功率は26.7％ （2003年情報化実態調査）
http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20031111/1/
リッチクライアント化については、ユーザーの要求が、ＨＴＭＬのみでは対応できない 状況になってきており、Ｗｅｂプラグイン系のリッチクライアント（ＣｕｒｌやFlash）に より、アプリケーションの自動配信も可能になってきた為、注目を集めています。 下記に代表的なツール（言語）を記述します。 ただし、業務システムの画面として、開発する場合、どれも１世代前のＣ／Ｓ系ツール よりも開発生産性、操作性は、落ちると思われます。（個人的な見解です。）
※ 安藤幸央のランダウン[25] リッチクライアント時代の到来 より
http://www.atmarkit.co.jp/fjava/column/andoh/andoh25.html
J2EE を初めとするオブジェクト指向の世界では、オブジェクト指向による業務分析、 設計、開発という一貫した流れを目指しています。 これは、UMLなどの用いて、分析、設計した情報を、そのまま開発につなげることが 出来る（つなげたい）という目標があります。 一般に、機械図面や、電気図面（回路図）などの設計情報は、そのまま板金や、 基板という物体に仕上がります。そうすることにより、基本設計（要件定義）から、 詳細設計への落とし込みに抜けが無ければ、そのまま成果物が完成します。 CAD/CAMなどの進展と同じく、クラス図よりソース自動作成や、テストコードの 自動作成、データベースアクセスに関するスキーマ情報とのORマッピングなど 自動化も進みつつあります。
現在は、フレームワーク乱立の時代であるといえます。 従来の部品化による共有/標準化という考え方は、部品の組み合わせによって 特色を出そうとする為、どうしても部品の粒度（大きさ、塊）が小さくなります。 つまり、釘や板や柱、瓦 などの共通部品が出来上がり、窓やドアのようなカスタマイズ が入る可能性がある部品や、骨格そのものは、その都度作りこむ必要があります。 逆にフレームワークは、骨格や土台などを作り、個別の部品を都度作りこみます。 また、その部品も窓枠のサイズは標準サイズを使用することで、作りこむ速度も 早くなります。 この、フレームワークでの開発において、肝心のフレームワークそのものが標準化 されていない為、各社各様に作っているのが現状です。 大ブームを引き起こしている Ｓｔｒｕｔｓ でさえ、Apache の独自フレームワークです。
次世代フレームワークとして最も注目されているのが、ＪＳＦ（ＪａｖａＳｅｒｖｅｒ Ｆａｃｅｓ） です。従来のフレームワークとの決定的な違いは、Ｊａｖａの世界標準であるＪＣＰ（ Ｊａｖａ Community Process)で作成された事です。 さらに、次期 J2EE1.5 での標準フレームワークになります。
※ JSFとStrutsのどちらを使うべきかについて、Strutsの作者であり、JSFの仕様リーダ である、クレイグ・マクラナハン氏の個人的見解として、下記の様に述べられています。openGionでは、システム構築が一巡し、今後は、保守と外販強化、品質向上など、安定稼動 を目指した活動が活発になると考えられます。 Webサービス化や、J2EE対応は、今後、２～３年は、対応する必要性はないでしょう。
リッチクライアントに関しても、現状、および、将来的にどの技術が主流になるか、 また、実際の業務において、本当にリッチクライアントが必要なのか、検討の余地が あります。部分対応レベルであれば、現状のWebアプリケーションの延長線上で 対応可能な範囲ではないかと思われます。
業務ロジックを、PL/SQLから、Javaへ転換することに対して、大きなメリットが３つ
あります。
一つは、DBサーバーへの負荷集中を、アプリケーションサーバーへ分散させることで、
スケーラビリティーの向上を図る事が可能になります。
２つめは、きちんとしたJavaでは、開発生産性と品質の向上が見込めることです。
３つめは、エンジンフレームワークの拡張機能として、Javaを利用できることです。
ここで、業務ロジックをJavaで記述する場合に、大きく２つの方向性があります。
先ほどの一般論で述べましたように、業務ロジックをオブジェクト指向で分析、設計 することで、開発まで、シームレスにつなげようという動きが一般的です。 ただし、ここで問題になるのが、オブジェクトデータとリレーショナルデータの インピーダンス・ミスマッチです。 これらも、解決方法も、現状では混迷しているといえます。 エンジンでは、当面、１．の方向性で進めるのが無難であると考えています。
openGionフレームワークは、JSPを使用しています。これは、J2EE体系の一部であり、 エンジンでは、EJB以外のJ2EE技術に準拠した形で使用しています。 つまり、Javaの世界標準である、J2EE技術を使いつつ、EJBを避けている使い方で 今後も進めることになります。 この考え方は、今後２～３年は、変わらないと思います。
EJBを避ける最大の理由は、業務ロジックの分析・設計に、オブジェクト指向を 取り込むつもりがあるかどうかに関係します。
エンジンでは、今後も、［１］方式を踏襲するつもりです。 業務ロジックをオブジェクト指向で分析・設計・開発するのは、設計者、開発者の オブジェクト指向に関する高度なスキルが必要になってくる為、それ相応の覚悟と 苦労が必要になってきます。 しかし、RDBMSを使いつづけ、業務ロジックをRDBMS準拠で考えて、開発のみ、 オブジェクト指向技術を使用するのであれば、業務ロジックフレームワークの導入に より、開発者に高度なスキルを要求せずに、高度なアプリケーションの開発が 可能になると考えています。
世間一般的な動向と、MISでの動向（進め方）を図示しました。 UMLやオブジェクト指向分析・設計などの高度な知識が必要な分野は、 まだ、環境が熟していないと考えている為、費用対効果を考え、当面の目標 から、はずしています。Webサービスに関しても同様です。
J2EE は、次期バージョンでも、より進化していきますが、EJB３．０やJFSなど 調査段階のレベルだと考えています。Ver４ 以降に対応できるかどうかという所です。 ただし、現段階では、ORマッピングは、PL/SQLからJavaへの業務ロジック 切り替えにおいて、早急に使用を検討していきます。
Struts は今から始めるのであれば、JSFとの見解もある為、当面見送りです。 同様に、リッチクライアントによる全面置き換え（Curlなど）は、不可能と判断します。 ただし、一部対応という選択肢は、ありうるため、継続して調査は行います。
フレームワークの進化を、先ほどのロードマップと対比させて機能図を作成します。 エンジンコア部分の進化と周辺ツールの充実の両方により、品質、納期、を改善 していきます。