 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 | ||||||||||||
|
||||||||||||
| ユーザインターフェースの開発 | ||||||||||||
|
オートコンポーネントに割り当てられる機能には、画面を持つものと持たないものがあります。画面を持つ機能では、Swingを使ってユーザインターフェースを開発します。開発者としては、特別な記述言語やフレームワークなどの約束ごとを新たに覚える必要がないため、すぐに開発をスタートできるメリットがあります。 ただし他の、特にクライアント／サーバ型の流れをくむリッチクライアント製品に比べると、ビジュアルな開発環境や便利な部品集といったサポートが少ないということもいえます。しかし、IdbA R2.0ではビジュアル的な開発環境や便利なツールが強化されるとのことですので、期待できるでしょう。 |
||||||||||||
| まとめ | ||||||||||||
|
「一括!コマース『速販』」のカスタマイズ開発事例を通じて、コンポーネントベースのリッチクライアントアプリケーションの開発の実際をご紹介しました。この開発は迅速な立ち上げに成功し、比較的短納期な状況の中での開発を完了することができました。振り返ると、それには次のような理由があったと考えます。
表1：短期納期の成功要因 事前の習熟については、開発の全体が馴染みのあるJava言語を使った開発であり、IdbA自体も特有の約束事をあまり要求しないプラットフォームであったことから、すぐに開発に入ることができました。今回はその効果が大きかったと考えています。開発・デバッグ環境がEclipseに統合されていたことも成功した要因として考えられます。また対象とするコンポーネントに集中した開発は、IdbAのアーキテクチャを活かして明確にコンポーネント化された設計が可能であり、それによって実現しました。 リッチクライアントの開発でいわれることに、かつてのWebアプリケーションもそうであったように、開発手順が確立していないことや、設計ノウハウの蓄積が浅いことによる計画上のリスクがあります。開発規模の見積りや要求される機能の実現可否の判断など、従来と異なる枠組みでの開発にはどうしても未知の部分があり、事前に技術的な難しい部分を潰しておくためのスパイクを必要とすることもしばしばあります。 そうした点でJavaなどの標準的な開発手順や設計ノウハウを活かすことのできるコンポーネントベースのリッチクライアントアプリケーション開発は、手堅い選択肢という面があります。 また、今回紹介した「一括!コマース『速販』」は、各ショッピングサイトから分散して提供される接続プログラムを、ユーザの必要に応じてネットワーク越しに動的に統合してアプリケーションを構成する仕組みになっていますが、このようなユニークな仕組みを、個々のコンポーネント開発ではあまり意識させることなく自然に実現する点はIdbAというプラットフォームの特徴です。 今後このようなタイプ、つまり様々に提供されるWebサービスなどをクライアントに統合し、そこでアプリケーションを構成するような技術はどんどん増えてくると思います。私たちもそうした技術を引き続き取り入れて、リッチクライアントの要件に幅広く対応していきたいと考えます。 |
||||||||||||
|
前のページ 1 2 3 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
