第5回 クライアント・サーバとの根本的な違いを理解する


インフラと業務ロジックを分けてしまう発想

 このようなサーバ・サイドJavaを採用するが故に出てくる、クライアント・サーバとのアーキテクチャの違いやプログラム・デザインの制限という観点では、いま盛んにeビジネスアプリケーションの作成で行われているサーブレットからビーンを活用するというMVCモデルを使う手法は、理にかなっているかもしれません。

 なぜならサーブレットの業務処理がたとえマルチスレッドで同時に複数動いたとしても、そこからビーンを新たにnewして活用すれば、ビーンの中ですべての処理を完結させることができるわけです。

 ビーンの中で、たとえメソッドが自由に参照できる変数をグローバル領域に持っていたとしても、マルチで稼働する業務ロジックごとにこのビーンは新しくnewされて動きます。ということは、ビーンの処理自体がそれぞれ個別に処理されることになりますので、ほかのビーン処理と混ざり合って変数が参照されるようなことはまったくありません。

 こうすることで、ビーンでプログラムを作る人は、それがサーブレットという特殊なインフラで動くということを意識することなく、自由に業務処理だけに専念してプログラムを記述出来るようになるわけです。

図14 サーブレットからビーンを活用する

 

 サーバ・サイドJavaのインフラは、非常にいいものです。しかしそれに特化してシステムを作ると、どこか微妙にうまくいかない個所も出てくるものです。いま解説したように、ビーンを活用するというデザイン手法を混在させながらシステム構築することで、問題ある個所を、また違った技法で解決することができます。このように知識や技術はただそれだけで活用するのではなく、うまくそれらを連携させて活用したり運用することで、スマートなサーバ・サイドJavaを実現させることが重要でしょう。

 さて、クライアント・サーバ技術者の観点からサーブレットの改善点を探るアプローチを進めてきましたが、だいぶページ数も長くなってきました。

 次回は「eビジネスアプリケーションの基幹連携の方法に違いがあること」の個所に焦点をおいて解説していくことにしましょう。こんどもサーバ・サイドJavaの技術や仕組みだけでなく、それをどううまく応用してシステム構築を進めるべきか、そういうノウハウが見えてくる内容にしたいと思います。

 

 5/5  

 

 INDEX

第5回 クライアント・サーバとの根本的な違いを理解する
  今回の内容の目的  
  システム構築者の土壌によって改善ポイントが変わる
クライアント・サーバ技術者がeビジネス・システムを見て、その違いを感じる時
eビジネスアプリは分散から集中に変化したシステム形態
  eビジネスアプリの処理は、1対1の処理ではない
サーバサイド側のプログラムはつねに1本
Webアプリケーション・サーバの動きが、プログラミングに影響してくる
  まず最初のサーブレット改善点は?
もっと頭のいい解決策はあるの?
インフラと業務ロジックを分けてしまう発想
  

連載記事一覧

 



Java Agile フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Java Agile 記事ランキング

本日 月間