さて、このあたりからネットワークが重要な役割をはたしはじめる。イーサネットをはじめとする、データリンク層（いわゆるレイヤ２）のプロトコルや物理層としての伝送メディア規格（レイヤ１）は早い段階で標準化はされていたが、いわゆるネットワークを作るためにはこれだけでは不十分だ。レイヤ３から上の層のプロトコルが必要である。しかし、最初の段階で、コンピュータ間通信のプロトコルは、そのOSやネットワークソフトウエアベンダに固有のものだった。一方で、国際的な標準化の動きも出てきたが、様々な利害がからんで遅々として進まなかった。その筆頭格であるOSIは、具体的なプロトコルの定義に入ったところで、事実上挫折してしまう。ただ、OSIがプロトコルを定義するために作った７階層の参照モデルは広く使われて、その後のプロトコルモデルの事実上標準となった。これはなんとなく皮肉な話かもしれない。一方、UNIX系のネットワークは米国を中心とした、政府、軍、教育機関などを繋ぐネットワークとしてどんどん普及していき、現在のインターネットの原型となった。もちろん、プロトコルはTCP/IPである。しかし、OSIの７レイヤモデルで見ると、TCP/IPとして総称されるプロトコル群、つまりレイヤ３のIPプロトコルとその補助的な役割をするICMPプロトコル、レイヤ４での確実な接続を保証するTCPと、同じくレイヤ４で軽量なデータグラム通信を行うUDPは、コンピュータ上のプロセスが１対１もしくは１対Nで通信をするための仕組みまでしか提供しない。OSIでいうところのレイヤ５（セッションの管理）とレイヤ６（交換されるデータの表現方式の互換性保障）、そしてレイヤ７（特定のアプリケーション間で行われる通信の約束事）は、まとめてTCP/IPの上で動くアプリケーションにゆだねられている。完璧にレイヤ７まで定義しようとしたOSIに対してTCP/IPのこの緩さが勝ったという見方もできるだろう。
いずれにせよ、やがてPCの世界もTCP/IPが主流になる。これまで独自のプロトコルを使ってきた各OSベンダは、レイヤ４以下でTCP/IPを使うモデルに移行しはじめた。また、UNIX系で使われているtelnet, ftpをはじめとする各種のアプリケーションもPCに実装され、PCとUNIXの世界がネットワークを介して接続されるようになった。当時は、UNIX系の処理能力がPCに勝っていたため、UNIX系を核としてPCを接続するようなモデルが広まりはじめる。PCが能力を持つことで、これまでメインフレームに集中していた処理をPCに分散することが可能になり、金食い虫のメインフレームを排除できるかもしれないと、PCやワークステーションメーカーは期待した。しかし、それはなかなか簡単ではなかった。個々のPCで処理を行っても、データをうまく共有できなければ、システムとしては成り立たない。つまり、少なくともデータは集中的に管理できる形が必要だった。そこで、能力に勝るUNIX機をデータ共有・管理のためのサーバとして使い、PCでそのデータを処理させる、初期のクライアント・サーバモデルが出来上がったわけだ。元来、技術計算用のワークステーションを作ってきたメーカーの多くが、サーバ用の高性能、高信頼性、大容量の機種を作り始める。しかし、このモデルでは、データのみをサーバに集め、ビジネスロジックは、そのほとんどをクライアント側で処理するという形であったため、アプリケーションを大量のPCにばらまく必要があり、その管理や保守コストの増大を招いてしまう。また、アプリケーションはOSやPCのアーキテクチャに依存してしまうため、たとえばWindowsとMacでは、同じことをするために違うプリケーションを作らなければならない。まんまとメインフレームを駆逐しつつあったクライアント・サーバモデルだったが、システム導入のイニシャルコストが大幅に下がった一方、保守・運用コストが著しく増加するという問題を招いてしまったのだ。
ここからの流れは、ほとんどの人が知っているはずだ。ハードウエア、ソフトウエア、ネットワークという大きな３つの流れは、インターネットという大きな海にたどりつく。この海を渡るための船がWebブラウザだ。一方、船がたどりつく先の港（Webサーバ）側では、船の乗客に対して魅力的なサービスを競って提供するようになる。それにつれて、船も大きく進化し、港もまた利便性に富んだものとなっていく。ブラウザの高機能化、様々なプラグインツール、これらを使って、使い勝手の「悪くない」サービスを提供できるようになると、アプリケーションは次第に、サーバ側に戻り始める。最初は、クライアントの使い勝手や互換性向上を目的に作られたJAVAは、クライアント側での処理系の重さや、目的とはちぐはぐな実行系の仕様変更などにより、バージョン依存などの問題が激しく、なかなか使い物にはならなかった。一方、サーバ側でも、Web用のアプリケーションを記述するためにJAVAを含む、様々な言語が使われはじめると、クライアント・サーバモデルは、あっけなく「ブラウザ・Webサーバ」モデル、すなわち結局、昔のメインフレーム＋ちょっとインテリジェントな端末のモデルとほとんど変わらない形に戻ってしまったのだ。これで保守・運用コストはとりあえず低減できたのだが、今度は、時代の流れとともにアプリケーションの肥大化に悩まされることになる。
（続く）
コメントする