第5回 クライアント・サーバとの根本的な違いを理解する
 |
システム構築者の土壌によって改善ポイントが変わる |
前回のサーブレットの内容を見て、いくつかの改善個所を考えてみていただけたでしょうか？
さて実は、最近面白い傾向があることが分かってきました。それは何かというと、前回、皆さんにお願いしたようなサーブレットの改善個所を列挙する場合、お尋ねした方によってその答える内容が全然違うということです。
例えば、最近のeビジネス・システムは、サーバ・サイドJavaの技術を使ってシステムを構築することが盛んです。
しかしこのようなeビジネス・システムを作る方々のいままでの仕事の内容が、最初からJavaやインターネットの仕事をしていらっしゃったのか、あるいは以前はホスト大型コンピュータの仕事をしていたとか、また最初はクライアント・サーバシステムの構築に従事されていたのか、などeビジネス・システム構築に従事される前の経験や知識が千差万別だということは当然です。
ですから、サーブレットの改善個所も、こういう皆さんのすでに持っている知識や経験の違う観点からまったく変わってきます。改善個所を解きほぐすアプローチは数多くあるかもしれませんが、この連載では、サーブレットの改善ポイントを、クライアント・サーバ技術者の技術ポイントの観点から見ていきたいと思います。
それは現在eビジネス・システム構築の現場では、以前にクライアント・サーバのシステム構築に従事された経験を持ち、それに関する知識や経験を豊富に蓄積されている方が大変多いので、これを切り口すると非常に面白い傾向や問題点も見えてくるからです。eビジネスアプリケーションというのは、クライアント・サーバとはかなり違った仕組みで作られています。たとえやりたい業務は同じであっても、クライアント・サーバとeビジネス・システムではまったく作り方が異なることも多々あります。
そのためか長年クライアント・サーバのシステム構築に携わった技術者が、新しくeビジネス・システムのシステム構築を始めたときに、その仕組みや内容の違いに気付く瞬間が非常に多いことが分かります。
実はこの前回説明したサーブレットの改善個所とこのクライアント・サーバとeビジネス・システムの仕組みの違いに気付く内容がそれぞれ非常に密着していることも分かります。
|
クライアント・サーバ技術者がeビジネス・システム |
まず多くのクライアント・サーバ技術者の方が、いくつかeビジネスアプリケーションを開発したり、その仕組みに接したときに感じる代表的なものとして、大きく以下の4つの内容が挙げられます。
|
|
それぞれを簡単に説明してみましょう。
まず「eビジネスアプリケーションが分散から集中へ変化したこと」ですが、これは明らかにコンピュータの仕組みの流れは輪廻の法則を持っていて、eビジネス・システムというのが、コンピュータの歴史の一番初めのホスト集中処理から分散処理、クライアント・サーバ処理を経て、そして再びホスト集中処理に戻ったということを実感される人が多いということです。サーバ・サイドJavaという言葉の「サーバ・サイド」という部分が表しているように、明らかにeビジネス・システムはホスト集中処理に分類されることも分かるでしょう。
また2つ目の「eビジネスアプリケーションの基幹連携の方法に違いがあること」ですが、クライアント・サーバではクライアントからダイレクトにデータベースなど基幹系システムにアクセスします。しかしeビジネス・システムでは、ブラウザから直接アクセスするわけではありません。サーバ側にあるプログラムが基幹システムへのアクセスを行います。これによってクライアント・サーバではまったく考えもつかなかった考慮点が出てくることが多いのです。
また3つ目の「eビジネスアプリアプリケーションには第三者の行動が強く影響すること」についてはこうです。クライアント・サーバの世界では、当然のことながらクライアント側のコンピュータとサーバ側のコンピュータの2つの関係しか存在しません。しかしeビジネスアプリケーションの世界では、なんとまったく関係のない第三者の存在も意識しないといけなくなる場合があります。そしてその第三者が、勝手に介入してくる場合もあるということもあり得ます。
そして最後の4つ目の「eビジネスアプリケーションを作るにはコツがあること」ですが、例えばうまく動くシステムを構築するには、数多くの守らなければならないことがあります。eビジネス・システムを構築する場合も、例外なく順守しないといけない規則が多いことが分かります。重要なのは、この規則がクライアント・サーバとはまた趣が違って、厳格なものが多いということも分かります。
さていろいろと解説しましたが、これらの内容は言葉で解説しても、なかなか分からないものではないでしょうか。
そこでこれから多くのクライアント・サーバ技術者がeビジネス・システムに対して感じるこれらの内容を切り口として、前回に出てきたサーブレットの改善点を洗い出してスマートなサーバ・サイドJavaの構築手法を考えていくことにしたいと思います。
|
eビジネスアプリケーションは分散から集中に変化した |
では「eビジネスアプリケーションが分散から集中へ変化したこと」を実感できる事例を見ていきましょう。ここでは、まず最初に前回に解説したサーブレットを動かしてみたいと思います。
このサーブレットは、ただ単に社員検索をするだけの単純なサーブレットです。しかしこのサーブレットは非常に奇妙な動作をするサーブレットでもあります。
例えば、このサーブレットを起動させる画面をブラウザに表示して、入力フィールドに検索キーを入れてエンターキーを押してみます。当然のことながら検索結果が返ってきますね。
 |
| 図1 検索キーを入れてボタンを押す |
 |
| 図2 結果が返る |
さてこれだけでは何の変哲もない検索サーブレットですが、これが2つ同時に動いたときにこのサーブレットは特徴ある動きをします。ではその実際の動きを見てみましょう。
ここでは1台目のパソコンで稼働するブラウザと2台目のパソコンで稼働するブラウザが登場します。
まず1台目のブラウザに検索キーを入力し、実行ボタンを押します。この1台目のブラウザの処理は検索負荷が高くて検索の結果が出るのが遅く、なかなかブラウザに結果が返ってきません。
 |
| 図3 1台目のブラウザに検索キーを入れる |
このとき、2台目のブラウザに検索キーを入れて、ボタンを押しました。この処理は、検索負荷はそれほど高くありません。ですから検索結果がすぐにブラウザに返ってきました。
 |
| 図4 2台目のブラウザに検索キーを入れる |
 |
| 図5 2台目のブラウザに結果が返る |
さてここで先ほどの1台目のブラウザに戻ります。ここでようやく1台目のブラウザでスタートさせた検索処理が終了しました。そしてこのブラウザに表示された内容を見ると、なんと！それはどう見ても1台目のブラウザで指示したキーを検索した処理結果ではありません。
結果の内容は、どう見ても1台目の処理の途中から処理が始まって、その後すぐに処理が終了した2台目のブラウザから入れたキーの処理結果とまったく同じではないですか！
 |
| 図6 1台目のブラウザに結果が返る |
 |
2/5 |  |
 |
連載記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
