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

---

最初のサーブレット改善点は？

　では前回のサーブレットの一体どこが悪かったのかいうと、以下の個所が問題だったことになります。

1 import java.io.*; 2 import java.util.*; 3 import java.sql.*; 4 import javax.servlet.*; 5 import javax.servlet.http.*; 6 7 public class TestServlet extends HttpServlet { 8     String RDBDRIVER ="COM.ibm.db2.jdbc.app.DB2Driver"; 9     String USERID 　="userid"; 10    String PASSWORD ="password"; 11 12    String inDs = new String(); 13    String inTbl = new String(); 14    String inKey = new String();

　この12〜14行目の個所は、サーブレットの中に記述されたどのメソッドからも参照できる領域にあるインスタンス変数です。これを以下の20〜22行目の内容を追加して書き換える必要が出てきます。

　この修正は、もともとグローバル領域に定義されていた変数（ここではコメントですね)をすべて削除して、新たにマルチスレッドで稼動するdoPostメソッドの中だけで有効なローカル領域の変数に変更しました。これでマルチスレッドで稼働するdoPostメソッドの中で使う変数は、その中だけで参照されるメソッドになります。

1 import java.io.*; 2 import java.util.*; 3 import java.sql.*; 4 import javax.servlet.*; 5 import javax.servlet.http.*; 6 7 public class TestServlet extends HttpServlet { 8         String RDBDRIVER ="COM.ibm.db2.jdbc.app.DB2Driver"; 9         String USERID ="userid"; 10        String PASSWORD ="password"; 11 12        /* String inDs = new String(); */ 13        /* String inTbl = new String(); */ 14        /* String inKey = new String(); */ 15 16 public void doPost(HttpServletRequest request, 17            HttpServletResponse response){ 18        try{ 19        /* ブラウザから入力値を受け取る */ 20        String inDs = request.getParameter("DS"); 21        String inTbl = request.getParameter("TBL"); 22        String inKey = request.getParameter("KEY");

　

もっとスマートな解決策はあるの？

　1つ目のサーブレットの改善点は以上のような内容です。しかし場合によっては、これで本当に解決になっているのか？ という議論をする人もいます。

　それはなぜかというと、このすべての変数をローカル領域に持ってくるということは、プログラムのデザインという観点でいまひとつ問題がある、ということです。プログラムというのは、必ず同じ処理をする部分を1つにまとめておいて、それをサブルーチンや関数、メソッドという形式で共有して使います。この手法は、プログラムの生産性を上げるための初歩の初歩というもので、だれしも異論はないことです。

　この考え方でいくと業務プログラムは、サブルーチンやメソッドの組み合わせで作成されていることになります。

　1つの処理は、サブルーチンからサブルーチンへのやりとりが連続して行われ、それがすべてうまく終了して初めて完結することになるわけですね。そうすると当然、前のサブルーチンの実行結果は、どこかに格納しておくなりして、それを次のサブルーチンが参照することで処理を続けていくことになります。この格納する場所が変数になるわけです。

　ところがサーブレットは処理がマルチスレッドで動くとなると、複数のメソッドが共有して見られる領域に変数を置くことができなくなります。もしどうしても次のメソッドに処理結果を渡したい場合は、相手を呼び出すときに引数を渡して、またその結果をリターンで受け取るという手順を取らざるを得なくなります。これは相手を呼び出すプログラムも、相手の処理をきちんと理解したコードを書かないと、プログラム同士の連携ができなくなってしまうのです。

図12　サブルーチンが共通領域を利用して変数を受け渡しする

　

図13　サブルーチンが引数を渡して変数を受け渡しする

　

　そしてこのようにプログラムを書かざるを得ない理由はどこにあるかといえば、それはひとえにeビジネスアプリケーションを行うために採用する、Webアプリケーション・サーバがやっているJavaの処理を使っているからにほかなりません。なんだかこれはあるべきプログラムの姿を選択すべきなのか、あるいはサーブレットを使わざるを得ないので、Webアプリケーション・サーバというインフラに合わせるべきなのか、かなり悩んでしまいそうなことなわけですね。

4/5

　

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

連載記事一覧

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）