top / index / prev / next / target / source

2005-04-02 diary: ソフトウェアとアーキテクチャの調和

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

ソフトウェアとアーキテクチャの調和

ここのところ、ソフトウェアとアーキテクチャの間のバランスとか関係に興味があります。

ソフトウェアとアーキテクチャの調和と反発

コンピュータソフトウェアと アーキテクチャや性能との間には、調和が必要です。これは あたりまえのことです。ここのところ、リレーショナルデータベースに関して、ソフトウェアとアーキテクチャの調和について多くを考えさせられたので、ちょっとまとめて考えてみます。ちょちょいで書くので、かなりおおざっぱに考えています。細部に漏れている論点があるのはあしからず。なお、この考えはymotoさんに指摘され、話ながら考えをまとめたものです。

リレーショナルデータベース

この文章を書いているいまの時点で考えると、リレーショナルデータベース管理システム(RDBMS)という仕組みは コンピュータの性能や そのアーキテクチャとバランスが取れています。踏み込んで言うと、件数や情報量をコントロールして適切にDBスキーマ設計を行うことにより、かろうじてバランスを取ることが可能になっています。実際に多くのコンピュータシステムでは リレーショナルデータベースの仕組みが利用されています。そういえば、Javaによる情報処理システムがあったとして、コンピュータ的な最終目的はリレーショナルデータベースへの値の格納や紙の印刷であることが多いです。

今の時点では この親しみのあるよく使うリレーショナルデータベースという仕組みは、ちょっと一昔に戻って考えると とても使い物にならないものでした。使い物にならない主たる理由は、コンピュータの性能とバランスが取れていないことでした。当時のCPU性能やメモリ搭載量、そしてハードディスク性能にとって、RDBや SQLという仕組みはとてもコストが高くバランスの取れない「使い物にならないソフトウェア」だったのです。その当時は 「順編成ファイル」というアーキテクチャが常識的で現実的で、そして「使い物になるソフトウェア」の仕組みだったです…。その当時の人々にとっては リレーショナルデータベースや SQLといったものが実用的になる時代が到来するなんてほとんど想像できなかったです。むしろ当時は (汎用機上では) 順編成ファイルを拡張した 様々なアイデアおよびソフトウェア実装が提供されていて、そしてそれらを実際に利用していました。

実際の現場でリレーショナルデータベースが利用され出したのは、UNIXなどの 「ダウンサイジング」されたアーキテクチャ上においてだったと感じています。UNIXアーキテクチャは汎用機に比べると おおざっぱで乱暴なのですが、高速なCPUと多くのメモリを搭載しているのが魅力的でした。単純にCPU単価やメモリ単価が汎用機に比べて異常にパフォーマンスが良かったのです。今ふりかえって考えるとリレーショナルデータベース や SQLの普及にとって、UNIXのような「ダウンサイジング」されて「マルチベンダ」なアーキテクチャは不可欠なブレークスルーだったのでしょうね。むろん「ムーアの法則」もリレーショナルデータベース や SQLの普及に必要だったのでしょうけれどもね。そんなこんなで 最も言いたかったことは、リレーショナルデータベースとかSQLとかいうものが、現状のアーキテクチャやハードウェア性能などとかろうじて調和がとれているということです。だから SQLとかリレーショナルデータベースを否定しようとすると、とたんにアーキテクチャや性能から反発を食らってしまうのです。

でも、それは現時点でのアーキテクチャや性能とのバランスの話だけなのであって、ちょっと未来に 今では想像しがたいものが実用的になっていることも、良くあることです。もっといろいろ考えてみると、その昔は磁気媒体の多くはランダムアクセスが出来なかったです。逆に未来においては、オブジェクト指向ファイルシステム(イメージファイルを格納しようとすると、ファイルシステム勝手に考えて類似のものを差分格納とかインディックス付けとかしてくれたり…) とか非ノイマンアーキテクチャなどが登場したら、オブジェクト指向データベースのようなものが ごく普通に利用できていそうですしね。キーワードはグリッドコンピューティングやニューロン処理などかしらん。、、、おお、そういえば今時点で考えると HORBなんて丁度バランスが取れそうに思います。時間があればHORBを調べてみたいなぁ…。 ビジネスでも研究でも、恐らく何か新しいソフトウェアを考える際に いつ時点のアーキテクチャや性能をターゲットとしているのかは重要な要素になるのでしょう。今時点のアーキテクチャや性能をベースに考えると、いろいろな制約に対して調和させていく必要があるのです。5年後だったら、それをターゲットとして調和を試みて行くのでしょう。しかし 5年後までの間に、予想しがたい変化が発生するのだから難易度が高いです。、、、そういえば基礎研究に従事している人は、この限りではありませんね。基礎研究に従事している人は、どんどん得体の知れない謎めいた研究をしていく責務があり、あれはあれで大変でしょうね。今のコンピュータ技術は それら基礎研究のたまものですから。(例えばオブジェクト指向という概念は ものすごい太古の昔から存在しているのですから！)

リレーショナルデータベース・インタフェース

リレーショナルデータベースから思いをふくらませてみると、リレーショナルデータベースへのプログラミングインタフェース (API) が非常に興味深いです。今の時点では Java言語からリレーショナルデータベースにアクセスするインタフェースで最もメジャーなものは 間違いなくJDBC API です。ご存じの方には普通のことなのですけれど、JDBC APIの仕様はMicrosoftが策定した ODBCインタフェースに非常に良く似ています。いやもう初期の JDBC API的には ODBC APIとうり二つって感じだったです。これにはいろいろ理由があるのでしょうが、何よりも当初は JDBC Type1ドライバという ODBCドライバを内部利用するタイプの JDBC利用方法が現実的だったので、素直に ODBCの仕様に合わせておく制約があったのでしょう。ODBCとの調和こそがJDBCドライバにとって成功する必須条件だったのです。その ODBCにしたって、それ以前のプリコンパイルタイプのデータベースインタフェースと相似形となっています。データベースベンダー毎に てんでばらばらだったプリコンパイル・データベースAPI処理系を Microsoftさんが統一されたAPIとして ODBC APIを策定してくれたからこそ、さまざまなデータベースに対して同一のプログラミングで接続が可能になったのです。私は当時 InformixのC言語用のプリコンパイル型処理系を経験しました。今 生き残っているものを例に挙げると OracleのPro*C を代表として挙げていて誤解が少ないかしらん。とにかくその当時は データベース実装毎に データベースアクセスインタフェースが異なっていたのです。それを Microsoft ODBCによって統一的で画一のインタフェースによるデータベースアクセスが可能になったのだから驚きです。(そして Microsoft Accessから 様々なデータベースへの接続が可能になりました) ちなみに私は当時 全くODBCの実装が提供されていなかった頃に 英文の ODBC仕様を見て心躍らせたものです。その後実際に Microsoft Windows NT 3.1 + Microsoft SQL Server 4.2 という組み合わせに対してパッケージソフトを設計・製造しました :-P。

そんな経緯や歴史があるので、JDBC APIは ドキュメントには現れない不文律な制約に従う必要があります。プリコンパイル型データベースAPIの頃のアーキテクチャが JDBCドライバに今も息づいていることがほとんどなのです。

上記のおのおのは JDBCドライバのアーキテクチャや性能と密接に関わりがあります。ここのバランスを崩そうとすると、とたんに様々な反発 (多くの場合非現実的な性能問題) と直面してしまいます。あるいは データベースロックのアーキテクチャと調和がとれなくなります。そしてそれらは、もう10年以上も前のプリコンパイル・データベースAPI処理系の流れを汲んでいるのです。、、、だから JDBCは難しいのかも知れませんね。 広告: 書籍: やさしく学ぶ 基礎からのJDBC SQLもJDBCも初めての人のための Javaデータベースプログラミング入門本です

Java統合開発環境

今でこそ Eclipseという統合開発環境が実用的に利用できますが、その昔は Java言語用で マトモに使える統合開発環境はありませんでした。(そう言えば Symantec VisualCafeは性能的にいい感じだったのですが…。今 Symantec VisualCafeで思い出されるのは むしろそのJITコンパイラです。JITコンパイラを Windows版 Java実行環境に組み込んでくれたからこそ 今のJavaにつながったのです) 私が最初に Java統合開発環境を使ったのは JBuilder 1.0 だったと思います。Pentium 90MHzのパソコンで JBuilder 1.0を起動したら、ワークベンチが開くまでに 10分くらいかかっていました。(なんてこった!)

まあ、今の時点でも JBuilderは コンピュータの性能とはバランスが取れていないようにも感じますけれども… (私は JBuilderが ちとニガテ)。そんな中 Eclipseは まあ普通の速度で動作します。何より (Window版だと) Windowsの普通のソフトと同じような使い勝手が提供されます。この点は大きいです。Eclipseが Javaで書かれているんだっていう違和感について あまり感じない人が多いのではないでしょうか。Eclipseは 今時点でのアーキテクチャや性能とちょうど調和が取れているのです。でも Eclipseにつながるには相当な苦労があったことでしょう。その昔、IBM VisualAge for Javaという機能的にとても素晴らしい Java統合開発環境がありました。統合開発環境上でソースコードの差分取得ができたり、果てはヴィジュアル編集画面においてワイアードロジックまで備えていました。しかし残念なことに当時のアーキテクチャや性能とはバランスが全く取れていませんでした。私が検証したときに、統合開発環境を終了するのに 15分くらいかかりました。VisualAge for Javaは Pure Javaでは無いでしょうけれど…。実は Eclipseの祖先は VisualAge for Javaです。VisualAge for Javaにおける反省がEclipseに反映されたのでしょうね。Eclipseはとても機敏に動作します。

Eclipseが Windows上で常識的に動作することができる理由の一つ (そして最大の理由) に、SWTというツールキットを採用していることが挙げられます。SWTベースで開発されているからこそ、Eclipseは常識的な操作感を提供できているのです。私は SWTの仕様を知った時に、これまた心躍りました。まず SWTは Swingなどとは根本的に異なり、各プラットフォームのグラフィカルウィジットをベースに実装されていたのです。ベースラインとしては、AWTなのでしょうか。とにかくオブジェクト指向は極力利用せずに アーキテクチャ側に仕様を寄り添えたのです。(オブジェクト指向レスは今後の重要なテクノロジーだと考えます。これはいずれ掘り下げて考えたいです。)そして、なんと SWTでは メッセージループが前面に押し出されています！ これは私にとっては最大の衝撃でした。がつんときました。メッセージループなんて Visual C++以前の MSC + Windows SDK以来のお目見えだったのですから！ Eclipse (というかSWT) を設計した人はとても聡明で勇気のある人だったのでしょう。APIの実装レベルとして SWTは それまでの世間のAPIに比べて明らかに退行しています。抽象度が下がっているのです。しかし Eclipseを見ていると、あるいはSWTで実装をしてみるとわかるのですが、メッセージループは私たちプログラミングを行う側に無いといけないのです。モーダルレスダイアログボックスをスレッド上で動かす際に、メッセージループが私たちサイドにないと実装できない、あるいは実装が困難だったりトラブル続出だったりするのです。とにかく、SWTという仕組みが アーキテクチャや性能と絶妙な調和を取っているのです。SWTをもってして、初めて Java言語によるクライアントサイド・プログラミングが可能になるのです。SWTを創ってくれた方、とてもありがとう！ SWTは Javaのデスクトップ利用に大いなる一撃を与えてくれました。(携帯型端末の次世代ウィジットとして SWTがブレークする可能性だってあります、と予言してみる) 友情広告: 書籍: Java GUIプログラミング (SWT編) SWTが基礎からわかります。そもそも2005/04時点では SWTの和書はこの本しか存在しません。

ネットワーク技術

仕事柄、リレーショナルデータベースやSQLに不満を述べる人は良く見かけます。私はむしろ SQLやリレーショナルデータベースって、現時点のアーキテクチャや性能とのバランス的に最適だと考えるのですけれども…。でも、一方でネットワーク技術に対して、特に Web系だと HTMLやHTTPに対して不満や改善案を述べる人はあまり見かけません。でもよく考えると HTML/HTTPにこそ改善のチャンスが最大限与えられていると考えます。いま丁度アーキテクチャや性能とネットワーク技術との間にバランスのギャップがあり、改善する余地が与えられているのです。HTML/HTTPで最大の不満はセッションの概念や画面遷移(含む子ウィンドウ)の概念が HTML/HTTPに与えられていないことです。今の HTML/HTTPを利用した Webシステムは CookieやらセッションIDやらを駆使しまくって ようやくセッションや画面遷移を実現しています。残念なことに HTML/HTTPにはセッションや画面遷移の仕様が盛り込まれていないのです。今もし私がヒマだったら実装してみたいのが、セッションや画面遷移が盛り込まれた Webブラウザの作成です。基本は HTML/HTTPベースなのだけれど、セッションや画面遷移を適切に仕様として盛り込んだWebブラウザ (およびサーバサイド) の仕様を実装するのです。ちょうど FirefoxっていうオープンソースなWebブラウザがあるから、あれをベースに 意外に簡単に実装できそうだと思うのですけれどもね。、、、目標としては汎用機端末かしらん。(私 詳しくは知らないのだけれども、Curlとかが その概念に近いのやも知れません)

コンパイラとインタプリタ

コンパイラとインタプリタについても アーキテクチャや性能とのバランスが重要です。Eclipseを使っていると デフォルト設定では知らないうちに Javaコンパイラが実行されています。壮絶です。一昔から考えると、これは信じがたい高度な機能です。いろいろな諸条件が整い、Eclipseではその場でコンパイルが可能になっているのです。一方で Java言語のコンパイル後のclassファイルは 中間形式です。実行時には そもそもインタプリタで動作するのがキホンです (HotSpotのおかげで、ほとんどインタプリタは意識させられませんけれどもね) コンパイラとインタプリタの関係は やはりアーキテクチャや性能と調和をとる必要があり、今 Java言語は 絶妙にそのバランスを取っているのです。(だから流行っていて多く使われています)そしてある程度の規模をもったソフトウェアの開発・保守のしやすさという観点からは、実はコンパイラのような仕様を持った処理系の方が扱いやすいことが多いです。(最終的にコンパイルという手順は無くても文法チェックさへしてくれればOK)特に Eclipse時代とでも言うのでしょうか、知らないうちにコンパイルしてくれるようになってくると、開発時に可能な限りチェックしてくれるコンパイラの仕組みはとても有益なものです。、、、だから今の時点である程度の規模のものでインタプリタ系 (というか文法チェックを行ってくれない系統) の処理系を選ぶと かなり困難を伴ってしまう可能性があります。別に規模が小さければ、むしろインタプリタ系のほうが扱いがしやすいのですけれどもね。そこには規模と処理系とのバランス感も存在するのでしょう。いずれにしてもどこに調和があるのかを見いだすことは重要です。

歴史を知るということ

このように、ソフトウェアとアーキテクチャの調和を掘り下げて考えていく際には歴史を知ることが重要です。特に情報処理技術の世界は変遷が早いので 歴史から学び取ることが出来る側面がとても大きいです。そうであるのに、今の情報処理産業においては歴史を考える風潮があまりにも貧弱であるように感じます。なぜなのでしょうね。歴史を知る先輩が あまり語らないのか、逆に若手が先輩からあまり学ばないのか。ここも掘り下げて考えてみる価値が大きそうです。

逆に考えると、歴史を知った上で現状把握が出来る人こそが ビジネスチャンスや研究実績を得やすいのです。というか、今時の情報処理技術いおいて 時間軸が無視された論点展開も多いように感じます。以前そうであった技術なのか、現在有益な技術であるのか、将来性に満ちあふれた未熟だが魅力有る技術なのか、という軸さへあれば、誤解を招きにくいだろうし、だからこそ歴史を振り返るきっかけを得ることが出来るようにも考えます。だいたい、今のJava技術って未だに10年以上前の汎用機技術に追いついていないのですから。…私のこの考え方って、そんなに特殊なのかしらん。と考えてみる今日この頃。

この日記について