|
|
| Webアプリケーション・フレームワーク Egretの開発... |
|
|
|
|
Servlet API 2.0の発表当時(1997年)にServletをコアとしたリクエストブローカの仕組みを開発しました。
その後これをベースに、EJBへの対応、セキュリティスキームの組み込み、携帯電話など各種端末への対応、ポータルサイト構築支援ライブラリの追加、J2EE
Patternsに基づくリファクタリングなどを行い、 Egretと呼ぶWebアプリケーションフレームワークを完成させました。
|
|
|
|
|
|
|
|
|
|
我々がEgretを開発した動機は、単にWebアプリケーションのライブラリ集が欲しかったからではありません。
我々はWebアプリケーションの構造をオブジェクト指向技術をベースに検討することで、
「クラスライブラリとして実装できる部分」、
「アプリケーションごとに異なるが仕様から自動生成できる部分」、
「アプリケーションごとに実装を行う必要がある部分」
の3つに分類しました。そして、仕様記述からJavaソースコードを自動生成するジェネレータを開発することで
アプリケーションごとに実装が必要な部分を徹底的に減らすことに成功しました。このような検討を十分に行っていたため、J2EE Patternsが発表された際も、
Egretが採用するDesign PatternsはJ2EE Patternsとほぼ1対1で対応しており、クラス名の変更程度でJ2EE Patternsへの対応を行うことができました。
|
|
|
|
|
|
|
|
|
|
我々は開発作業を「要求分析、プログラミング、デバッグ」といった工程の単なる集合とは考えていません。
例えば複数の開発者がチームを組む場合には、それぞれの開発者が担当する部分やインタフェース、進捗状況といった情報をチームで共有する必要があります。
要求分析の結果をもとに各開発者が従うパターンを定義し、可能な限りそれらを自動生成したりチェックしたりするためのツールを作ります。ツールによってそれぞれが従う手順や方法を規定するのです。
また、ソースコードの版管理はもとより、タスクやバグ、テスト結果を統合的に管理するプロジェクトマネージメントツールを使って情報の共有を図ります。
これらの総合的な組み合わせが我々の開発メソドロジであり、Webアプリケーション開発をこの考え方にしたがってブレークダウンした結果がEgretに代表されるフレームワークや
開発支援ツール、Design Patternsなのです。
|
|
|
|
|
|
|
|
|
|
Egret開発当時の状況とは異なり、Strutsに代表されるWebアプリケーション・フレームワークはもはや一般的です。
開発コストやメインテナンス性の観点から、独自のフレームワークよりも有名なオープンソースのフレームワークを採用するケースも少なからず存在します。
しかし、我々がEgretを開発した動機、経緯、ノウハウはStrutsに代表されるフレームワークにも同じように適用することができます。
Webアプリケーションの開発だけにとどまらず、コンサルティングや開発支援や技術アドバイザリにまで踏み込んだサポートを提供できる理由がここにあります。
|
|
|
