第6回　最適な設計はホスト時代の流儀に同じ？

---

もっとパフォーマンスUPを狙った改造をする

　ちなみにこの方法は、もう少しエレガントにサーブレットに応用することができます。サーブレットには、initメソッドという、サーブレットが一番初めに呼び出されたときに一度だけ起動するメソッドを記述することができます。これを応用して、サーブレットが最初に起動したinitメソッドの中で、データソースを獲得してデータベースに接続しておき、この接続状態を複数で稼働するサーブレットの業務ロジックの中で使いまわすという方法です。

1 .....<中略>..... 2 3 import java.sql.*; 4 import javax.sql.*; 5 import javax.naming.*; 6 7 public class TestServlet extends HttpServlet { 8   String USERID ="userid"; 9   String PASSWORD ="password"; 10   String DATASOURCENAME = "jdbc/empdb"; 11   DataSource ds=null; 12 13   public void init(ServletConfig config){ 14     try{ 15       super.init(config); 16       InitialContext initCtx=new InitialContext(); 17       ds=(DataSource)initCtx.lookup(DATASOURCENAME); 18     }catch(Exception e){ 19       e.printStackTrace(); 20     } 21   } 22   public void doPost(.....){ 23     Connection dbConn=null; 24     try{ 25       /* データソースからDB接続オブジェクトを獲得する */ 26       dbConn=ds.getConnection(USERID,PASSWORD); 27       /* SQLステートメントを実行する */ 28       String sql=("SELECT * FROM....."); 29       Statement stmt = dbConn.createStatement(); 30       ResultSet rs=stmt.executeQuery(sql); 31       .....<中略>..... 32     }catch ( Exception e){ 33       .....<中略>..... 34     }finally{ 35     try{ 36       if(dbConn !=null){ dbConn.close();} 37     }catch(SQLException e){ 38     .....<中略>..... 39     } 40   } 41 } 42 43 .....<中略>.....

　initメソッドの中の16行目と17行目で、データソースを探し出して獲得しています。獲得されたデータソースは、11行目の変数に格納されていることに注意してください。

　22行目以降は、業務処理が記述されているdoPostメソッドです。このメソッドの中の26行目にデータソースを使って、DBにアクセスする記述があります。多くのユーザーがこのサーブレットにアクセスしてくると、このdoPostメソッドが同時にマルチ実行されます。DBにアクセスする場合も、すでにinit処理の中でネームサービスを使ってデータソースの在りかを特定しているので、いちいちWebアプリケーションサーバ上のデータソースを探しにいく手間も省け、パフォーマンスの悪化を防ぐことができます。

　いろいろとプログラムのお作法の話をしましたが、皆さんもサーバ・サイドJavaから他システムへ連携する場合は、直接他システムへ連携させる手法と接続マネージャを経由する手法が、混在しないように、いまから標準を決めておくといいでしょう。

まとめ

　クライアント・サーバの世界では、ミドルソフトへの直接アクセスが当然であったのに、サーバ・サイドJavaの世界になると、その方法をそのまま踏襲しては、問題があることが分かりました。その例として接続マネージャを使った例で解説してきました。このようにサーバ・サイドJavaのシステムを効率的に動かすには、ホスト側にあるWebアプリケーションサーバが提供してくれた接続マネージャのような仕組みを使い、Webアプリケーションサーバの恩恵を受けられるように作ることが重要です。こういうお作法をうまく守りながらシステム構築を勧めていくことが重要になってくるのです。今回お話しした内容のポイントは、以下の2点でした。

• eビジネスアプリは、ホスト集中形態のシステムである
• eビジネスアプリケーションは、Webアプリケーションサーバの恩恵を受けながら、決まったお作法の下で作成される必要がある

　今回は、eビジネスアプリケーションの基幹連携の手法にはクライアント・サーバシステムのそれとは違いがあることに焦点を絞って解説してきましたが、次回は、さらに一歩話を進めて、いま、さらに重要になってきているセキュリティの話をしてみたいと思います。この解説では、第4回に出てきたサーブレットを題材に使っていますが、実はこのサーブレットの中にもセキュリティの問題が出てくる部分があるのです。次回はこれを分かりやすく解説してみたいと思います。

6/6

INDEX
第6回　最適な設計はホスト時代の流儀に同じ？
	今回の目的は？
	eビジネス・アプリケーションは基幹連携の方法に違いがある プログラムが他の機能の恩恵を受ける、それは相手の資源を使うこと システム連携処理には、ミドルソフトの存在が欠かせない クラサバの基幹連携をサーブレットに置き換えてみると
	システム連携を集中管理する接続マネージャの考え方
	接続マネージャは、誰が用意するのか Webアプリケーションサーバを使った接続マネージャの作成
	eビジネス・アプリケーションは、お作法を守って記述されないといけない 悪いサーブレットを改善しましょう
	もっとパフォーマンスUPを狙った改造をする まとめ

連載記事一覧

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