3層クライアントサーバについて

１．趣　旨

Webを利用して3層クライアント・サーバの構成を取るシステムは日進月歩で、 さまざまな方式が存在します。
ここでは特にWeb関連の仕事に付きたての人からの質問が多いこれらの方式に付いて 整理のために私なりに少しまとめておこうと思います。
といってもあまり専門的な且つ最新の事情に詳しいいわけではないので、基本的な事項しか記述できません。

２．２層の問題点

1990年代前半、日本にあるシステムの主流は２層のクライアントサーバーシステムでした。
この時代、GUI（Graphic User Interface）またはCUI（Comannd User Interface）関連処理と業務処理をクライアント側で行っていました。

ところがイントラネットやインターネットも含めネットワークがこれだけ普及した今、 この方式だとデータベースから抽出したデータがネットワーク上を流れるため、 トラヒック上の問題が発生します。
また、大量のデータを流すのでデータ側の排他的ロック時間が長くなり、 クライアントが待たされる時間も増大します。

３．３層の概要とメリット，デメリット

これを回避するためにクライアントではGUI（あまりCUIは有り得ない）関連処理のみを行い、 業務処理をサーバー側で行う様になりました。

GUIのみを受け持つクライアントをプレゼンテーション層、中間の業務処理を行う部分をファンクション層、データベースシステムによる内部処理や固有ファイルそのものをデータ層と呼びます。

ファンクション層とデータ層をサーバー側に配置し、ネットワーク上には要求と結果のみが流れる様にします。これにより一般的に２層よりトラヒックが軽減します。
またサーバー側でデータ抽出等の処理が完結するので排他的ロック時間も比較的短くて済みます。

デメリットとして、サーバー負荷が２層にくらべて大きいと言えますが、今日のマシンパワーを考えれば取るに足らないコストと言えるでしょう。

４．Webにおける３層クライアントサーバー（C/S）の構成

おそらくWWW（イントラネットも含め以後単にWebという言葉を使います）の普及にともない３層クライアントサーバーシステムの普及も加速したのではないかと私は思います。
Webを利用する場合クライアントはブラウザが受け持つわけです。 日本でもWebが普及しだした頃の３層クライアントシステムは、図1の様な構成でした。

ここでは、伝統的なCGI(Common Gateway Interface）を使用します。

掲示板やゲストブック、簡易検索エンジンなど多くの小規模なシステムは、今でもこの方式が多いと思います。 これらはデータ層がそのCGIプログラム固有のファイル（シーケンシャルファイル、ランダムアクセスファイルなど）である場合が多いでしょう。

もちろん伝統的なCGIプログラムがRDBMSにアクセスしている場合も有ります。
BtoB,BtoC双方においてWWWを利用したさまざまなビジネスモデルが生まれるに至って、システムのすばやい開発と柔軟でスピーディーな仕様変更が必須となり、 その生産性・メンテナンス性・再利用性・パフォーマンスの向上を目指して、 現在では Aplication Server という概念の基ににさまざまな構成が存在します。図2にその主な構成を示します。

※図2は古い情報です。2017年現在の技術に即していない名称もあるかも知れませんので注意してください。

５．図2の構成具体例

図2の構成でいくつか説明しておきます。

※下記は古い情報を含みます。2017年現在の技術に即していない名称もあります。特にWindowsの.NET環境には適用できない情報も含みますので注意してください。

WindowsPCが普及している職場のイントラネット等で比較的手軽に出来るものとして、 MicrosoftのIIS(Internet Information Server) + ASP(ActiveServer Pages)でデータベースにアクセスする場合は2のルートでODBC経由になります。 例えばMicrosoft Access用のODBCドライバをWindowsに登録しておくか動的に登録する事によって、htmlに埋め込んだのServer Side ScriptからAccessにSQL文を発行する事が可能です。

ASPとは、VBScriptなど本来ブラウザに搭載されているスクリプトエンジンを新たな便利な組み込みオブジェクト数種類とともにWebサーバー側に搭載したものです。これにより拡張子がaspであるhtmlファイル内に埋め込まれたVBScript等はサーバー側で実行されます。また、組み込みオブジェクト以外にも、COMコンポーネントをインストールすれば、 ユーザー定義オブジェクトとして利用可能です。この方式のコンポーネントとしては フリーのBASP21というCOMコンポーネントを私は良く利用していました。ASPでメール送信機能を書く場合などに最適です。

PostgreSQLと言えばPHPですが、これはルート2でlibpq経由となります。libpqはCによるPostgreSQLクライアントインターフェースAPIです。上記同様、拡張子がphpであるhtmlファイル内に埋め込まれたPerlに似た独自言語プログラムはサーバー側で実行されます。特徴は既存のいろいろなRDBMS向けの専用操作関数を多数持っている事です。これらの関数を利用する事により比較的容易にSQL文を使用してRDBにアクセス可能です。

図2のAplication Serverで「IIS or Apache & Servlet/JSP & Java2 & JDBC Driver」というのは WebServerとServer Side Javaがドッキングした様なイメージです。
例えばWindowsNTやWindows2000で「IIS & tomacat & Java2」という環境であれば、ASPを使ってルート3でODBC経由でAccessにアクセスする事もできますし、Java Servletから、Java2コアに入っているODBC-JDBCブリッジ(TYPE1 Driver) を使用してルート3でODBC経由でAccessにアクセスする事も可能となるわけです。当然JSPも利用できます。ここでtomcatとは Apache Jakarta Projectが開発したServlet Containerで、ServletとJSPの統合動作環境を提供します。WindpwsだけでなくUNIX系OS上でも動作するパッケージが用意されています。JSPとはASPのJava版と思えばわかりやすいと思います。言語は当然Javaのみです。またJSPはファイル毎全てtomcat上で一旦Servletに変換されます。

また、Linuxで「Apache & tomacat & Java2」という環境であれば、 PostgreSQLのTYPE4 JDBC Driver をインストールしておけば、ルート4で直接PostgreSQLにJava Servletからアクセスできます。

「Other Aplication Server」というのは、Webのさまざまなビジネスモデルを実現するシステム向けに最近各社しのぎを削っている商品です。いろいろな商品がある様ですが、いずれもJ2EEやEJBを搭載し、Javaによる効率的かつ生産性の高いアプリケーション開発が可能というPRを行っています。 これにXML,XSLTやいろいろなORBの仕組(RMI,CORBA,DCOM,..)なども搭載されている製品が有る様です。

2017年現在「Application Server」という言葉はあまり聞かなくなり「Webフレームワーク」という言葉がもっぱら流通しているようです。私に詳細解説はできませんが、ＪａｖａであればJSPが進化したJSF（Java Server Faces）というフレームワークが有名です。本来「Application Server」にしても「Weｂフレームワーク」にしても図1のファンクション層を担う仕組みの事です。しかしWebフレームワークは様々なブラウザサイドプログラムを動的に出力することによってプレゼンテーション層の一旦も担っていると考えたほうが良いと思います。「Weｂフレームワーク」という言葉で検索かけると、色々なサーバーサイド言語毎に多くの仕組みが存在することに驚かされます。しかもこの世界は日々変化しつづけています。

６．PerlによるWebフレームワーク

Perlそのものの衰退論があり大変悲しい限りです。その理由として「可読性が低く、読みにくい」というのがありますが、確かにその自由度の高さから「どうとでも書けてしまう」のです。これはチームで効率よく開発する場合はデメリットになるかもしれませんが、しかしまさにその「どうとでも書けてしまう」という所が、私が一番好きな理由です。

Webフレームワークは、MVC（Model-View-Controller）モデルを採用しているものがほとんどのようです。これはModel,View,Controllerの３つの役割に分割したコードにより、チーム開発の効率性やメンテナンス性を高める仕組みです。PerlによるWebフレームワークで有名なところは、MVCに対応しているcataryst、MVのみに対応してCはユーザー開発が必要なmojoliciousといったものがあります。後者は仕様を流し読みする限り、Cを実装していない分柔軟性が高く小規模なプロジェクトにも簡単に対応可能な気がします。本サイトで採用しているMovable TypeはPerlで書かれていますが、MVCモデルに沿った独自開発がなされているそうです。

下記の記事はMVCの概念を理解するのに大変役立った記事です。 http://qiita.com/tshinsay/items/5b1724baf32b8b5113c2

APIの標準化がなされたHTML5.0では、今までブラウザプラグインに頼っていた事を、ウェブ標準のAPIを操作することによってJavaScriptから扱うことができるようになるのだそうです。pull型とpush型が存在しているMVCモデルにとっては、これによりブラウザサイドでできることが増大するわけですから、ブラウザから頻繁にリクエストがを発生せざるを得なかったpull型に有利に働くことになります。

簡単に考えれば、jQueryでサーバーとJSONデータのやり取りを頻繁に行っていた回数が減る可能性があるとか、そういう話かもしれません。このあたりが今後のWebフレームワークの動向として注目すべき点なのでしょうが、Webフレームワーク自体を使ったことが無い私には今一実感が湧かないわけですが。。

MVCモデルより、私にとってはPSGI/Plackの方が目下興味のあることろです。

[HOME]