ＴＳＳ端末からリッチクライアントへ

学習のポイント

業務を依頼するコンピュータをクライアント，その依頼により処理を行うコンピュータをサーバといいます。その構成は，メインフレーム時代，ＬＡＮ時代，Ｗｅｂ時代の技術変化と利用や運用管理からの要請により，変化してきました。特に最近では，リッチクライアント（Rich Client）が注目されています。この構成変化を歴史的に考察することにより，利用面と運用面での考慮すべき事項を理解します。

キーワード

ＴＳＳ，ＣＳＳ，３層構造，Ｗｅｂクライアント，ＭＶＣ構造，ＨＴＭＬクライアント，リッチクライアント

１　ＴＳＳ端末

１９７０年代に，１台のメインフレームに多数の端末（当時は「クライアント」といわず「端末（ターミナル）」といっていました）を通信回線で接続して，ＴＳＳ（Time Sharing System：時分割方式）により共同利用する方式が普及しました。これにより，情報システム部門以外の人が直接にコンピュータを操作するＥＵＣ（End-user Computing）が普及しました。

当初の端末（クライアント）は，タイプライタに通信回線をつけたようなものでしたが，パソコンの普及とともに，パソコンをＴＳＳの端末として利用するようになりました。しかし，ＴＳＳ端末としての機能とパソコンとしての機能は完全に分離されており，端末は，単にメインフレームの入出力装置としての機能でした。しかも，メインフレームの時代ではＯＳも通信プロトコルもメーカー独自のものでしたので，富士通のメインフレームに接続するには富士通のパソコンに限定されるというようなメインフレームに付属したものでした。
　すべての処理はメインフレームで行っていました（注１）。それで，個別のアプリケーションごとに入出力画面をプログラムで作成する必要がありました。その画面はＣＵＩ（Character-based User Interface）で，文字と枠だけの非常にシンプルなものでしたし，入力個所の位置決めはマウスではなくカーソルで行う環境でした。
　しかし，個別のアプリケーションごとに個別のファンクションキーを割り付けるなど，それなりに操作しやすい工夫はできました（注２）。また，あるアプリケーションを利用している間は，一つのセッションとして管理できたので，画面の切り替えやデータベースとのデータ交換などは，案外容易にできたのです。

注１：ＥＵＣが盛んな先進企業では，メインフレームの負荷が大きくなり，定例的な業務を夜間にまわして，日中をＥＵＣを主体に行うようにしました。さらには，ＥＵＣのためにメインフレームを増強するようなことも発生しました。

注２：実際には，個々のアプリケーションでファンクションキーの機能が異なると利用者が戸惑うので，標準化しようという対策がとられていましたが。

２　クライアント・サーバシステム（ＣＳＳ）

１９８０年代末から１９９０年代にかけて，ダウンサイジングが進み，多数のパソコンをＬＡＮで接続してクライアントからの処理依頼により，サーバが処理を行う構成をＣＳＳ（Client-Server System）といいます。

（１）２層構造

ＣＳＳの普及によりメインフレームからサーバに変りました。パソコンのオープン化も進み，どのメーカーのパソコンでもクライアントにすることができるようになりました。しかし，この状況では通信プロトコルはいくつかのネットワークＯＳが存在しており，そのためのソフトをクライアントに持つ必要がありましたし，アプリケーションごとにクライアントに個別のソフトをを持つ必要がありました。
　ＣＳＳ環境になると，パソコンと同様な画像やアイコンなどのＧＵＩ（Graphic User Interface）が用いられるようになり，見やすく操作しやすい画面設計ができるようになりました。しかし，この環境でも個々のアプリケーションによりインタフェースが異なり，パソコン側にそれぞれのインターフェースのためのソフトウェアをインストール必要がありました。あるいは，データをサーバに置いておき，パソコン側のアプリケーションで処理する形式もありました。このような構成を２層構造といいます。

この間にパソコンのワープロソフトや表計算ソフトなどのソフトウェアが充実し，その利用も広まりました。それらの機能が大きくなるにつれ，巨大なディスクが必要になり，性能を高めるために，大容量のメモリや高速なＣＰＵが必要になりました。パソコンはFat PC（ファットＰＣ，太ったパソコン）になったのです。

そうなると多くの問題が顕著になりました。

クライアント費用の増大: この頃になると，１人に１台近いパソコンが設置されるようになりました。利用者を満足させるハードやソフトを提供するには，非常に多額の費用がかかります。
ソフトの配布: ワープロソフトで作成した文書を共有するには，同じワープロソフトを使う必要がありますし，新バージョンで作成した文書は旧バージョンでは読めないことがあります。また，個別のアプリケーションはパソコン側のＯＳを指定しますので，すべてのパソコンのＯＳやソフトのバージョンを統一する必要があります。しかも，あるアプリケーションの対象ＯＳを変更すると，他のアプリケーションもそれに合わせなければなりません。パソコン台数は多く，事業所も散在している環境で，短期間でいっせいにバージョンアップするのは大変な作業になります。このように，ソフトの配布が大きな問題になりました。
パソコン管理: これらを円滑に行うには，多数のパソコンについて，ハードの仕様やソフトのバージョンを集中的に管理する必要があります。ところが，利用者が勝手にハードやソフトを購入していることもありますし，ディスクに大量のデータを保管しており空きスペースが不足しているために，単純にはバージョンアップできないこともあります。

（２）ＣＳＳ（３層構造）

ＣＳＳでの適用業務が増大してくると，上記のような問題が深刻になるだけでなく，サーバの性能や容量が不足して，常にサーバを増強する状態になります。ところが，アプリケーションやデータを保管しているサーバが変るたびに，クライアントの設定を変更するのでは，ますます管理が複雑になります。
　そこで，考えられたのが３層構造です。３層構造とは，機能をプレゼンテーション，ファンクション，データの３層に区分して，クライアントから直接アクセスするサーバに，どのアプリケーションやデータがどこにあるかを示す機能（ブローカー機能）を持たせることにより，アプリケーションやデータの配置変更管理を容易にしようというものです。

３層構造では，クライアントはプレゼンテーション機能（入力や出力など人間と直接に関係する機能）だけを持てばよいことになります。これまで必要としていた多様なソフトは不要になりますので，ハードやソフトの費用が下がります。これをThin PC（シンＰＣ，やせたパソコン）といいます。
　この環境では，バージョンアップは比較的少数のサーバだけを行えばよいし，この面に限ればクライアントパソコンの管理も不要になります。また，その後のインターネットの普及によるウイルスや不正アクセスの脅威や，個人情報や機密情報の漏洩の危険を防ぐために，クライアントにディスクなどの記憶装置を持たせないことが注目されるようになりました。

Thin ＰＣは，１９９５年にオラクル社のラリー・エリソン会長によって提唱されたネットワークＰＣ構想がありました。パソコンにJavaを搭載して，アプリケーションは，ユーザーが使用するときにネットワークからダウンロードして使用する方式にすれば，当時は２０００ドルしていたパソコンを５００ドルにできるとされ，５００ドルパソコンといわれました。ところが，その後通常のパソコンの価格性能比が急激に向上したこと，Ｊａｖａの速度を上げられなかったこと，利用者が機能を手元に置きたいと思ったことなどにより，現実には消え去ってしまいました。
　現在，５００ドルパソコンとえば，アップルが２００５年１月に発表した「Ｍａｃ　ｍｉｎｉ」（価格４９９ドル）をいうようです。これは，一応のソフトを揃えたfat PCです。また，日立は２００５年２月に，ディスクなしのノートパソコン（セキュアＰＣ）を発表しましたが，これは紛失・盗難での情報漏洩防止を目的としたものです。

３　Ｗｅｂクライアント

１９９０年代中頃になると，Ｗｅｂブラウザが利用できるようになり，インターネットが急速に普及しました。そのインターネット技術を社内ネットワークに適用した環境をイントラネットといいます。その特徴は，通信プロトコルをＴＣＰ／ＩＰにすること，プレゼンテーションソフトをＷｅｂブラウザにすることです。ＴＣＰ/ＩＰを採用すれば，イントラネットにもインターネットにも同じに使えますし，これはパソコンに標準装備されています。Ｗｅｂブラウザも同様です。現在では，大部分の市販ソフトがこの環境で稼動するようになっています。
　クライアントにＷｅｂブラウザだけを置いたものをＷｅｂクライアントといいますが，後述のリッチクライアントと区別してＨＴＭＬクライアントというようになりました。

（１）ＨＴＭＬクライアント

ＨＴＭＬクライアントによる３層構造は，上述以外に次の利点があります。

フリーソフトの利用: Ｗｅｂ環境では，サーバ管理，アプリケーション連携，データベースなどに豊富なフリーソフトがあるので，安価でシステムを構築できます。
利用者教育が容易: インターネットの普及により，ほとんどの人がＷｅｂブラウザの操作方法に慣れ親しんでいます。それで，アプリケーション特有事項（むしろ業務での事項）だけを教えればよいことになります。
企業間利用の容易化: パソコン環境ではオープン化がいわれていましたが，Windows，MacOS，UNIXの間には互換性がありません。それに対して，ＷｅｂブラウザはＯＳを問いません。Ｗｅｂブラウザの種類により仕様が異なることもありますが，ＯＳの違いにくらべればたいしたことはありません。企業間ではＯＳの異なる環境がありますが，Ｗｅｂブラウザをプレゼンテーションソフトにすれば，その障害を低くできます。

ＨＴＭＬクライアントは，もともとＷｅｂページ表示用に作られたブラウザを、業務用のクライアントに応用するのですから，実際にはいろいろな限界があります。

Ｗｅｂブラウザの違い: Ｗｅｂブラウザの仕様はＷ３Ｃにより定められているのですが，残念なことに，流布しているＷｅｂブラウザはそれを厳密に守っていません。同じブラウザでもバージョンによる違いもあります。それで，同じＨＴＭＬを表示しても，Ｗｅｂブラウザにより異なることが多いのです。特にJavaScriptなどを使ったＨＴＭＬでは，表示だけでなく動作も異なることがあります。それで開発者は，多くのＷｅｂブラウザで動作確認をしたり，Ｗｅｂブラウザごとにそれに適したページを用意するなど煩雑な作業を強いられます。
ユーザインタフェースの限界: 一般にＨＴＭＬの仕様は文書構造を明確に伝えることを第一義にしており，印刷物のよう利用者に見やすい画面を作成するには限界があります。データの入力方式も画一的であり，きめの細かい機能を持たせることができません。ファンクションキーの設定もできないので，個々のアプリケーションに適した操作方法をとるのが困難です。このように，ユーザインタフェースには多様な限界があります。これは仕様が不備だからではなく，目的が異なるからです。
処理速度が遅い: 業務システムでは，応答時間が生産性に大きく関係します。ところがＷｅｂページ閲覧用のブラウザでのサーバとの通信時間やブラウザの表示時間は，それに特化したシステムに比べて非常に非効率です。
サーバの負荷: ＨＴＭＬでもJavaScriptでも，セキュリティ確保の観点から，クライアントにあるデータやアプリケーションと連動させることができません。メインフレームのときと同様に，すべての処理をサーバ側で行います。利用度が高くなるとサーバの負荷が増大し，応答が遅くなるだけでなく，ダウンしてしまうこともあります。

○ ＭＶＣ構成

Ｗｅｂクライアントの環境では，サーバをＭＶＣ構成にするのが適しています。ＭＶＣとは，Ｍｏｄｅｌ（処理），Ｖｉｅｗ（表示），Ｃｏｎｔｒｏｌｌｅｒ（制御，入力）のことです。

Ｖｉｅｗ（表示）: クライアントからのデータを受け取りチェックをする機能と，処理の結果をＪＳＰなどを利用してＨＴＭＬの文書を生成して，クライアントに送る機能です。クライアントには多様なＷｅｂブラウザがありますし，利用者は結果を数表やグラフなど多様な出力形式を要求しますので，それに対応できることが必要ですので，多様性を持ち、頻繁な変更が発生しがちです。逆にいえば，このような要請の少ないロジックを部分を切り離してＭｏｄｅｌにするのだといえます。
Ｃｏｎｔｒｏｌｌｅｒ（制御）: アプリケーションに関係のあるものを選択して、適切な形に変換してＭｏｄｅｌに伝達したり，画面更新が必要なときはを伴う場合はＶｉｅｗを呼びだすなど、アプリケーション全体の流れの制御をします。クライアントからサーバで処理をさせるのですから，サーブレットを用いるのが適切です。
Ｍｏｄｅｌ（処理）: アプリケーションとそれが用いるデータを保持しており、目的の業務で特定の環境に依存しない処理を実行します。通常は，JavaBeansを用いて記述します。

リッチクライアント

リッチクライアント（Rich Client）には，未だ統一された定義はないのですが，「Ｗｅｂで（シンクライアントをハードウエアのベースコンセプトとして追い求めながら）リッチなコンテンツもしくはクライアントアプリケーションを実行させるようなクライアントミドルウエアコンセプトおよび環境もしくはそれを体現した製品を指す。」（アクシスソフト）とか，「最低でも，高い描画能力（表現力），高い操作性の作りこみ易さ，クライアントリソースの有効利用が可能，配布が容易，の４つの特徴を持つＷｅｂアプリケーションのクライアント技術」（野村総研）などといわれています。

単純にいえば，ファットクライアントとＨＴＭＬクライアントとの「いいとこどり」をしたような形式です。
　リッチクライアントでは，パソコンで処理できることは，サーバに接続しなくてもクライアント側で処理できるようにします。それにより，パソコンで作るのと同様なきめの細かい画面にしたり，優れた操作性を持たせることができます。また，ネットワーク接続は必要なときだけ行い，常時はパソコン内部での処理になるので，処理速度もＷｅｂクライアントより高速になります。
　ＯＳやＷｅｂブラウザの違いの問題は，ＪａｖａやＪ２ＥＥなどＯＳと独立したソフトウェアを利用することにより，解決します。また，それを支援する開発環境を構築するシステムが提供されるようになりました。
　アプリケーション変更時のクライアントへの配布が問題になりますが，Ｗｅｂクライアントと同じように，クライアントがＷＷＷサーバにアクセスしたときに，変更するべき新アプリケーションをダウンロードすることにより，配布問題を解決します。特にこれらの処理を利用者の手を煩わせないように自動化する「ノータッチ・デプロイメント」機能が発展してきました。

先に，Fat PC／Thin PCがありましたが，Ｗｅｂの観点からは，Thin PCとはＨＴＭＬベースのクライアント，Fat PCリッチクライアントを指すようになってきました。