OSI の問題
前回のブログでは、OSIは、
1980年代後半の市場から熱狂的に待望されていたが、実際に出来上がってOSIネットワークが繋がり、詳細が広く知れ渡るにつれ、それまでの熱気が嘘のように消え去り、期待が失望に転じ、熱狂が落胆に変わって行ったと書きました。期待が大きかった分だけ失望も大きかったと言えます。
 |
| ネットワーク |
失望の理由は大きく言って２つがあげられました。
1. OSI仕様（スペック）そのものの問題
OSIは、１９８８年時点で実用段階にあったネットワーク技術の総まとめ的な性格を持ちました。
８０年代当時の最先端アプリ、たとえばマルチメディア（音声、画像、動画）などが市場ではさかんに話題になっていましたが、まだまだ研究段階であって、とても標準化の対象にはなりえませんでした。
たとえば、現在、皆さんが楽んでおられるYOUTUBEなどの動画アプリは、実験室レベルでは当時から既に存在していましたが、極めて大規模な設備と莫大なコストを要し、研究途上、発展途上の段階であって、とても標準化の対象とはなり得ませんでした。
つまり、ユーザー目線から言うと、OSIは、当時すでに実用段階にあったアプリを単に標準化しただけの存在であり、導入したところで何か新しい事ができたり、コストが安くなったりするようなものではなかったのです。
また、さらに言えば、OSIの対抗勢力である企業固有の（プロプライエタリな）ソリューションは、プロトコルは確かに非標準でしたが、基本機能に企業独自の拡張が付け加えられているいることが多く、実装標準を決める段階でこれらの拡張機能が対象外になりOSIには盛り込まれませんでした。
企業固有の拡張機能は、単なる通信の問題を超えてしまい、接続される2台のコンピュータが同じメーカーどうし（たとえばIBMのメインフレームどうし）でないと意味がないようなものも多く、当時の標準化の段階ではとても（標準化の）対象にはなりませんでした。
こういうわけで、OSIの仕様は小さくなり実装が容易になったわけですが（前回のブログ「世界標準と日本語 1」の（注＊） 参照）、ユーザー目線から言うと、極めて魅力の無いものになってしまいました。
2. 長い作業時間
OSIの相互接続は、市場が予測していた以上に手間と時間がかかりました。
そもそも昔の通信プロトコルは、たとえ同じメーカー同士であっても接続に時間がかかる、つまり手間がかかるものが多かったのですが、異なるメーカー間の異機種接続となるとさらに ー 当時のソフトウェア品質が発展途上でまだまだ不十分な段階にあったことも絡んで ー 非常に困難が伴いました。
当時のネットワーク・エンジニアが、現代主流になっているインターネット（TCP/IP)プロトコルを初めてさわった時など、あまりに簡単に、あっと言う間に短時間で繋がってしまい、驚いてしまった、とか、むしろ、繋がって欲しくない所まで繋がってしまい切る方が大変だった、という感想が多かったのも、頷けます。
こうした訳で、当時、実験的なシステムはともかくとして、実際に稼働しているプロダクション・システムをわざわざOSIに移行しようという気にはとてもなれなかったことは、ご理解いただけたかと思います。
では、世界の潮流が、OSIを諦めて、一気にインターネット(TCP/IP)に向かったかと言うと、決してそうではありませんでした。
インターネットの方はインターネットで、問題を抱えていたからです。
また同時に、本ブログの主題である「世界標準と言語」という問題も明らかになってきました。
続く・・・
