コンピュータの歴史として、

汎用機→サバクラ→Webアプリの流れがあると思いますが、
汎用機とWebアプリは、「必要な処理は中央で集中して処理する」という点で
似ていると思います。しかし、コンピュータの歴史の流れとしては汎用機→Webアプリとはならず、
間にサバクラが入っています。
こうなった主な要因は現代のブラウザが汎用機の時代には存在しなかったからでしょうか?

回答の条件
  • 1人5回まで
  • 登録:
  • 終了:2011/08/11 11:15:02

回答6件)

id:sibazyun No.1

回答回数1823ベストアンサー獲得回数246

まあそういえますが、そもそも初期のコンピュータは入出力装置としてタイプライタ、あるいはカードリーダとプリンタであって、入出力の両方ができる「画面+キーボード」ではなかったですね。

そして、今のウェブアプリは、中央で仕事をするといっても、手元にあるのは、単なる「画面+キーボード」ではなく(なにしろパソコンなので)ある程度のことはやっています。この「ある程度のこと」(グラフィックを描くとか)ができるようになるにも、「サーバー+クライアント」以後のグラフィックボードが入っているパソコンが必要になっています。

id:TransFreeBSD No.2

回答回数668ベストアンサー獲得回数268

Webアプリも、昔のCGIのはホスト/端末的ですが、今時のJavascriptやflashを使ってるようなのはC/S的ではないでしょうか。

基本的に、標準化と多様化が交互に進みます。

昔のホスト/端末モデルでは端末がテレタイプライタを元にしていました。

それが、端末が高機能になる事でホストと端末の関係が見直されC/Sモデルとなり、多様化しました。

そのうちにWebサーバ/ブラウザの組み合わせが標準的になり、この枠組みで様々なサービスが再実装されます。

しかし、そのうちにflashやajaxが出現し端末側が高機能化し、動的なUIが構築されていきます。

最近はtwetterクライアントのように専用アプリケーションも出現しています。

今はまだ、それなりに多様ですが、少しずつ認証方式など標準化が起こっています。

いずれ、それらを取り込んだ汎用的アプリケーションが登場し、またサービスが再実装されるのではないでしょうか。

id:papavolvol No.3

回答回数1078ベストアンサー獲得回数199

汎用機の本体と端末との間は、専用線で結ばれていました。

クラサバも専用LANで結ばれていることを想定されていて、公衆ネットの使用は当時は想定していませんでした。

Webアプリは、専用線や仮想専用線(VTN)なども使われますが、公衆インターネットの使用を前提としています。

クラサバが主流であった時代の公衆ネットワークと言えば、NTTのISDNは64Kでした。そのネットワークの独占が日本の法律で守られていたのです。それでも電話回線を使うよりは2倍早かったのです。通信料金も従量制や時間課金で、当時の1日の通信料金は現在の1月の通信料金よりも高かったのではないでしょうか?

現在は、一般家庭でも100Mの光ケーブルが来ているのが当たり前ですよね。定額制も当たり前です。

ネットワーク技術の進歩と、通信の自由化・規制緩和が、Webアプリの稼動を可能にしたのだと、私は思います。

id:Baku7770 No.4

回答回数2832ベストアンサー獲得回数181

 回答者には申し訳ないですが、#a1から#a3までは間違っているというか、視点が幾つも抜けていますね。

 まずは、通信費の問題。この点で#a3は救いようがありますが、当時の通信費用って現在とは違って、べら棒に高かったんですよ。現在のインターネットユーザは4千円で毎月楽しめますが、あの当時は1分10円、それに電話回線費用が加わって3分40円というのが公衆回線での費用でした。

 これを何時のだったかは忘れましたが、1990年代のG7でインターネットを一般に広げようという決議がなされて、国内ではNTTに圧力をかけて6~7千円の定額制が導入されてというのが、かなりWEBアプリへ進めたということになります。

 ですからインターネット以前の時代のパソコン通信時代なんて、通信費用を10万円個人で支払っていましたからね。

 

 2番目はハードウェアの価格。今では数万円で買えますが、1980年代後半に私がパソコンを担当しろと言われた頃は、大体一式で百万円と見ていました。プリンタ、ソフトを含めてです。

 そういったものを含めて考えると、職場の1人1台なんてありえなく、事業所間の通信をできるだけ抑えるしかなかったんですね。

 

 次にパッケージ技術の問題があります。あの当時のパッケージは殆どがそのままでは使い物になりませんでした。経理で『大番頭』という大ヒット商品が生まれましたが、販売管理となると業界毎に帳票や電文のフォーマットが違っていましたから使い物にはならなかったんですね。

 そのため、パッケージと言ってもカスタマイズが前提とされていました。

 その当時、htmlエディタなんてありませんから、どうしてもWEB対応というのは考えられませんでした。

 

 ここまでが、中堅未満の企業の事情です。

 

 汎用機、オフコンを導入済みだった企業の場合は更に深刻でした。資産が膨大過ぎたんですね。現在でも多いですよ。移行できないままでいる大手企業は。

 中堅企業の場合、プログラムの内部ロジックが分っていないところの方が遥かに多いんです。

 最初はベンダーに作らせますからドキュメントも揃っていますが、途中自社で手を加えた箇所にはそんなものはないというのが殆どでした。

 そのため、特にオフコンからサバクラへの移行キットというものが売られました。基本はCOBOLです。

 そういった幾つもの事情が重なり合ったことによるものです。

id:saijyoh_739 No.5

回答回数113ベストアンサー獲得回数10

> 汎用機→サバクラ→Webアプリの流れがあると思いますが、

Webアプリってクラサバを前提にしてますよ。

というか、クラサバって一つ一つのサービスについての話で、システム的には分散モデルです。

例えば、名前解決(DNS)やメールサーバ・ウェブサーバ・ファイルサーバ・SQL(RDBMS)など機能毎に分散して処理しています。(一つのサーバで全部行う事も可能ですし、それぞれ別のサーバで運用する事も、あるいは一つの機能を複数のサーバで実現する事すらできます)

ウェブアプリもインターネットの技術を前提に(基盤にクラサバでDNSやらDBMSやらメールサーバやら動いている環境で)使いますし。

それぞれのサービスを見ると、メーラとメールサーバであったりウェブサーバとブラウザであったりとサーバ・クライアントモデルで様々なサービスが実装されていて利用・運用しています。

ウェブサービスはそんな分散環境上で実現されています。


> こうなった主な要因は現代のブラウザが汎用機の時代には存在しなかったからでしょうか?

ウェブアプリはクラサバが根付いてクラサバでできた基盤の上に乗っかる形で実現されています。ウェブアプリが単独で存在しているわけではありません。(ウェブアプリもDNSやらRDBMSやら使いますよね)

id:a-kuma3 No.6

回答回数4973ベストアンサー獲得回数2154

クラサバをちょっと、避けておきます。

こうなった主な要因は現代のブラウザが汎用機の時代には存在しなかったからでしょうか?

細かいことを言っちゃうと、汎用機上で動作する unix 系の OS も無くは無かったし、

現在の Webブラウザの形を決めた Mosaic ができたのは、1990年代の前半で、

それまでにも Webブラウザの実装は幾つかあったので、「主な要因」とは言えないかな。


日本で Webの仕組みが広まるきっかけになったのは、Windows95 の発売だと思います。

でも、それ以降、勘定系のシステムなどでは、汎用機がまだまだ主流な時代が続きます。


Web系システムがはやりだした要因は、二つあると思います(ひとつに絞れんかった)。

  • システムの信頼性に対する考え方が変わった
  • 回線速度が飛躍的に速くなった

汎用機の時代の信頼性の考え方は、とにかく止まらないこと。

単体の信頼性を極力高めて、高い買い物だけど、それだけ信頼性が高いんだ、と。

ただ、どうしてもコストがかかるので、安いものを組み合わせて、システムとしての

信頼性を高める、という技術があみだされたことと、それを実現するだけの

そこそこ信頼性があって、安いものが出てきたこと。

ハードディスクの RAID なんかが、そういう考え方です。


昔は、基幹業務で使う高額の通信でも、16~64kbps みたいな世界でしたから、

通信するデータも極力無駄をなくすというのが常識でした。

金を出したって、ギガなんて回線が無かったんです。

HTML みたいに、ただ色を付けるためだけに、「値」のデータよりも大きなものを

付加するなんて、ありえませんでした。


で、クラサバの話なんですが、何故、Webよりも先に流行ったかというと、以下のようなことが要因かと(どれが主だ、とかいうのではなく)。

  • 汎用機のシステムから乗り換えやすかった
  • 運用にかかるコストが軽視されてた
  • 大手ベンダーでは、開発方式を変えるのに時間がかかる

「汎用機のシステムから乗り換えやすかった」というのは、汎用機を買い替えずに、

システムの移行ができた、という意味です。

例えば、汎用機が抱えてるデータはそのままにして、専用端末のエミュレーション機能を使って通信し、

そのデータの視覚化(グラフ)とか、集計/分析機能を追加する、とか。


「運用」については、システムの管理部門から見ると、リソースが集中している方が、

はるかに管理しやすいんですが、管理にかかるコスト、というのが二の次、三の次で、

システムの増強しやすい方式が選択されたのだと思います。

クラサバの初期では、端末の数も限られてたので、表面化しませんでしたが、

ひとりに一台のパソコンが割り当てられ、日常業務もそれでこなすようになると、

最新のプログラムや設定データが配信されて無い、だとか、で保守員が走り回ったりするような、

コスト(主に人件費)が、馬鹿にならないんだぞ、というのが浮き彫りになってきます。


システムを供給する側の都合で言うと、汎用機のシステムを供給するのは大手ベンダーが主でしたが、

こういったところでは、開発標準なんかもきちんと決まってて、それをひっくり返して

新しい方式に移るには、かなりのパワーと時間を食います。

「今のやり方で、それほど困ってないなら、このままで良いじゃん」ってな感じです :-(


で、Webに移っていったのは、

  • 汎用機自体の耐用年数が切れて、ハード自体を入れ替える時期になった
  • 運用にかかるコストを低減したい、という要求が強くなってきた
  • 中小ベンダーの台頭

という、先の理由の裏返しに加えて、以下のようなことがあると思います。

  • 処理能力を段階的に増強できる
  • クラサバの方が、操作性が高い、という言い訳ができなくなった

もっと、絞り込んで書きたかったんですが、これでも半分くらいには抑えたんです (^^;

先の回答でも、いろいろ出てるように、単純な話では無かった、というふうに理解してもらえれば良いんじゃないかな、と。

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません