G7-1 未来のインターネットの下で
Javaはどのように進化するのか?

植田 龍男(稚内北星学園大学)


概要

まずJavaの登場から現在までの進展を概観する。アプレットの興亡、急 速に膨れ上がったJava 2、J2EEの登場、一方で組み込み系Javaが突き当 たった壁などの事例を取り上げ、インターネットの普及やハードウェア の性能向上がJavaにどのような影響をもたらしてきたかを考察する。
そして、IPv6に代表される今後実用化されるであろう新しいネットワー ク技術によって、Javaはどのような方向に進化してくのか(いくべきか) を予想してみたい。新しいIPによる通信は、モバイル機器や電化製品も 含めた完全な P2Pの環境を実現することが可能である。その環境の下で Javaの分散オブジェクト技術によって構成されるアプリケーションは、 ユーザに対してきわめて柔軟性の高いサービスを提供可能である。コン ピュータ間、デバイス間の「境界」が消え去ることで、掌の上にあたか も世界中のコンピュータ資源が存在するようになる日も近い。


1,Javaの幸運--Javaはなぜ生き残ることができたのか?

Javaの登場は、この数年間のソフトウェアの世界の中で最も大きな出来 事の1つであろう。Javaが多くの支持を受けた背景には、各企業のさま ざまな思惑もあったであろうが、何よりもその優れた設計があり、さら にオープンソースの流れを受け継ぐ方針も( オープンソースの精神を完 全に受け継いだとは言えないが)大きな貢献をした。
しかし現在のJavaの発展は、それらだけで説明しきれるのであろうか? Javaが成功を納めることができたのには、やはり偶然の幸運と言うべき 要素もあるのではないだろうか?ほんの少しでもタイミングがずれてい たとしたら、もしかしたらJavaは広く受け入れられることなく終ってい た可能性もあったと思う。なぜ Microsoft社の強力な対抗措置にもかか わらず生き残ることができ、主導権を失うこともなかった理由を振り返 ってみる価値はあるかもしれない。

Javaの最初の幸運は、 Webサービスの登場とその急速な普及であった。 これは絶妙なタイミングであった。もちろんそれはJavaの主要戦略では あったのだが、Javaは Webの中を2つの経路を利用して広がることがで きた。そのうちの1つは、言うまでもなくアプレット(Applet)である。 Web ページの中で実行される軽量なアプリケーションという斬新なアイ ディアは、たちまち世界中のプログラマたちを魅了した。初期のJava(1 995年5月のαバージョンから 1996年末までの JDK1.0) は非常にコンパ クトな構成であり、 C言語に多少の覚えがある人間ならすぐにでも試し てみることができた。たちまち世界各地に自作のアプレットを公開する サイトがあふれることになったのである。
もう1つの経路は、インターネットを通じたドキュメントや開発環境の 配布である。 APIはもちろんクラスライブラリのソースもすべて公開さ れた。これらを通じて新しいコミュニティともいうべき開発者のネット ワークが Web上に構築されていった。現在では当初のフィーバーはすっ かり冷め、「Java=アプレット」などと考える人はいないだろう。しか し、当初のJava普及におけるインターネットとアプレットの存在は決定 的であった。"write once run anywhere" というJavaのモットーを最も わかりやすく伝える役割を果たしたと言える。
実は現在(2001年前半)、かつてのアプレットと似たような存在がある。 携帯Javaの世界である。この2月、NTTDocomoが Javaが動作する携帯電 話のサービスを世界に先駆けて開始した。この6月には J-PHONEも SUN が標準として公開している MIDP(Mobile Information Device Profile) に基づいた携帯Javaのサービスを開始する。
これらの携帯電話で動作するゲームなどのアプリケーションは、かつて のアプレットと酷似した性格を備えている。軽量のアプリケーションが 通信によってダウンロードされ、即座に実行される。開発環境ツールも 無償で入手可能である。おそらく現時点では実用的な利用には限界があ るだろうが、これまでJavaとは無縁だった多くの人々への普及には大き く貢献することになるだろう。

もう1つの追い風はマシンスペックの順調すぎるほどの向上である。当 初のJavaの最大の課題は実行速度であった。その改善の試みはさまざま 行なわれ部分的な成果もいくつか収められている。しかし、根本的な解 決を与えてくれたのは、ハードウェアの向上だということは否定できま い。JIT(Just In Time)コンパイラなどの特別な拡張を備えない標準的 な J2SE(Java 2 Standard Edition)でもJavaアプリケーションの操作性 は十分実用に耐えられるようになってきた。基本的な設計は大きく変わ らずクロック数が単純にアップし続けるCPUと、搭載量が年々倍増する メモリという「追い風」の恩恵を最大限に受けながら、J2SEは順調に膨 張をとげてきのである。たとえば 100MHz 以下のCPUや16Mbyte以下のメ インメモリの環境で「Java 2 のアプリケーションがまともに動かない」 と文句を言っても、「そんな古いマシンを使っている方が悪い」で 片付けられてしまうに違いない。

とはいえ、Javaの拡大路線のすべてが成功したわけではないこともしっ かり認識しておこう。Castanetはどこへ行ってしまったのだろうか? 何より、依然としてPC環境の主力アプリケーション開発環境の座を奪え ないのはなぜなのか? 一方でサーバサイドのJava(J2EE=Java 2 Enterprize Edition)は商用利用の領域で急速に普及をとげている。現在 のPCはJ2EEのサーバとしてのスペックは十分備えている。にもかかわらず PCで主に利用されている商用アプリケーションでは、Windows,UNIXいずれ の場合でも C,C++による「伝統的」な開発にとってかわることはできてい ない。個人利用の場合にはシステムの堅牢性とか透明性よりも、まだまだ 実行速度などの方が優先される風潮が残されているのかもしれない。ある いは、SUNのライセンシーの方針が、少なくとも商用アプリケーション開 発の場では、完全にオープンな開発を妨げているという見方もできる。
そして、Javaには先に挙げたような「追い風」をほとんど受けることが できなかった分野も存在するのである。それはPCとは異なる世界のJava の場合である。

2,Javaの理想と現実--組み込み系Javaの迷走

現在の組み込み系JavaはJ2ME(Java 2 Micro Edition)という形で統一が 図られている。J2MEという用語が登場したのは Java 2の登場(1999年) 以降のことだが、それ以前にも先行していた技術が存在した。 EmbeddedJava, PersonalJavaと呼ばれるものである。これらは、能力や 資源が限定されたデバイス上でJDKのAPIのコア部分を実現するために必 要最小限の機能を定めようというものである。また、それらをベースに 特殊化されたデバイスのためのAPIも提供されている。
たとえばカードにJavaを組み込む Java CardはJavaのかなり早い時期か ら提案されてきた。実際、家電機器への組み込みやモバイルへの応用は、 Javaのプロジェクトでも最も早い時期から重要課題として位置付けられ ていた。しかしながらその後の組み込み系Javaの普及のテンポは必ずし も順調ではなかった。現時点でも決して期待どおりに進んでいるとは言 えないだろう。
その大きな理由の1つは、組み込み系のソフトウェアの世界が持つ性格 だろう。組み込み系のソフトウェアは、特殊化された機能をきわめて限 定された資源の中に実現することを目的としている。ハードウェアに密 着してコントロールが要求される部分に、「どんな環境でも実行可能」、 「クラスの再利用」といったJavaのコンセプトを持ち込もうというわけ だから難しいのも当然だろう。開発を担当する技術者自身も、それまで に蓄積してきた経験や方向性と 180度異なる発想を要求され混乱したに 違いない。そして、ここにはPC環境のJavaが享受することができた「右 肩上がり」の性能向上とは無縁である。組み込み系のシステムでは、 CPUなどのハードウェアの性能は最優先されるとは限らない。必要とさ れるサービスを提供できる能力が十分保証されていれば、むしろ重量や 電気消費量、それに価格を抑えることの方が重要かもしれない。
困難のもう1つの理由は、組み込みJavaの対象があまりに多種多様であ ることだ。携帯端末、携帯電話、ゲーム機器、家電製品、電子カードな ど目的もデバイスの能力や資源にも大きな幅がある。組み込み系Javaで はほとんど無数と言っていいほどの種類のデバイスに対し、それらに共 通のプラットフォームを提供しようというのが究極の目標である。この 困難性はJ2MEとして再構成された現在でも根本的に変わっていない。実 は J2ME と呼ばれるものに「実体」は存在しない。J2MEは単独の開発環 境ではなく、いくつかの開発環境の総称である。組み込みJava用の開発 環境を設計する上の指針のようなものだと考えてもいいだろう。

ハードウェアの能力的制約と同じように(もしかしたらそれ以上に)厳 しい条件となったのがインターネットへの接続の制約である。現在、 bluetoothのような興味深い技術も登場しているが、これらのいわゆる PAN(Personal Area Network)の世界は、インターネットとは切り離され て存在している。PANの中にインターネットの出口を設けることは、もち ろん可能だが、PAN内部はあたかも「プライベートアドレス」で管理され るようなものに似ていなくもない。しかし、PAN自体の存在はDNSのよう なサービスで外部からアクセスするための情報を持っているわけではな い。この点はプライベートアドレスを用いる各ドメインとは異なる。
現在の携帯電話や携帯端末でのインターネット利用においても事情は同 様である。各機器は固有のIPアドレスを保有しているわけではない。パ ケット通信は電話会社のサーバを介してのみ実現されている。携帯端末 はシリアル回線(もしくは赤外線ポート)といういささか古い「閉じた ネットワーク」でしかLANに参加できない。このような状況は、もちろん 真の意味でのP2P通信提供していることにはならない。
現在のJavaのネットワーク機能はTCP/IPによる通信を前提としている。 bluetoothなどの技術に対してJavaのネットワーク機能が対応するのは 難しいだろう。携帯JavaでもURLの概念は存在するが、 java.net.URLク ラスを直接用いて処理を行うことはできない。 NTTDoCoMoの携帯Javaで は、ネットワークの通信は i-modeの機能を通じてNTTのサーバに HTTP プロトコルでアクセスする形態のものしか活用できない。このため機能 的には i-modeでCGIのサービスにアクセスした場合と大差はない。本来 はSocketによる直接の通信や RMIなどの分散オブジェクトの活用が可能 になってこそ、携帯Javaの存在の意義が増してくるのであるが、残念な がらこうした潜在的な可能性は今のところ活用されていない。

3,IPv6がもたらす革命--パーソナルネットワーク上のP2P

さて、ここまで現在のJavaの姿が、ハードウェアやネットワークインフ ラなどとどうかかわってきたかを考察してみた。今度は、将来の技術に よってJavaの利用がどのように進化していくのか、その可能性を考えて みたい。
まず、何よりも大きな影響を与えると予測されるのは、IPv4からIPv6へ の移行である。IPv6の登場で、利用可能なIPアドレスは事実上無尽蔵と なる。これまで独自のアドレスを持つことができなかった携帯機器も、 独立したサイトとして通信を行うことが可能となる。
現在でも携帯電話や携帯端末で音楽データの再生などの機能を利用する ものが増えている。しかし、現状ではダウンロードは必ず携帯電話会社 のサーバを介さなければならない。近い将来、こうしたスタイルは時代 遅れになるに違いない。IPv6の普及で個々のアドレスを持った携帯機器 はP2Pでインターネット上の任意のサーバに直接アクセスすることが可能 となる。携帯Javaで現行のJ2SEが提供するような IPアドレスやSocket通 信を取り扱う機能が利用可能ならば、音楽データをダウンロードするシ ステムをソフトウェア的に実現するのは、きわめて自然な形で実現が可能 だ。
たとえば携帯端末からLAN内の任意のPCやサーバマシンに直接アクセス することも可能となる。それらの通信を担うのは、次世代のJavaのAPI ということになるだろう。java.net.Socketなどのクラスが IPv6に対応 するような形で実現されるに違いない。携帯電話や携帯端末も、それら のAPIをベースにして任意のインターネットプロトコルを用いたサービ スを直接利用できるようになるであろう。WAN,LAN,PANのネットワーク は1つのプロトコルに完全に統一され、現在PCのレベルで実現されてい るいわゆるP2Pのサービスは、掌の上の携帯機器に広がっていくであろ う。多くのエンドユーザにとっては、現在の「着メロ」や「iアプリ」 のダウンロードと大差ないように見えるかもしれないが、実は本質的に 大きな違いが生じるはずだ。現在の携帯電話網のように電話会社の一元 的な集中管理型サービスから、各ユーザが独自にサービスをやり取りで きる分散型に移行するからである。
上記のような新しいサービス空間の中で、必要なサービスを動的に探索 したり、相互にコミュニケーションを取り合ったりする機能は非常に興 味深い。そうした新しい可能性を実現するのはJavaによるアプリケーシ ョンであるに違いない。
Javaのマルチメディア映像の取り扱いやブロードキャスト通信について はJMF(Java Media Framework)やJavaTVなどのAPIが提供されている。こ れらはもちろん既存のPCの上の処理を前提にしているが、今後は携帯機 器もターゲットとして拡張されるであろう。ブロードバンドのMPEG4に よるデジタル配信なども注目すべき対象であるが、各携帯機器にIPが割 り振られるようになれば、現在PCで実現されていることが容易に応用さ れるであろう。本学(稚内北星学園大学)のLAN内には既に上記のような IPマルチキャストMPEG4放送のシステムが構築されているが、このような スタイルは数年後には携帯機器のブロードバンドにそのまま受け継がれ るであろう。
また、必ずしも広い通信帯域が保証されていなくとも、IPによる直接通 信が可能になるだけで、新しい面白い試みはいくつか可能である。たと えば筆者が現在構想中のシステムは、音声や映像のデータをMIDIやテキ ストの座標情報の形に変換することで大きく圧縮し、狭い帯域でもマル チメディアのコミュニケーションを実現することを考えている。
先に述べたようにハードウェアの制約が大きいような携帯機器で、Java の膨大なAPIをすべてカバーさせるのには無理がある。少ない資源の中 で多用な機能を可能にする1つの工夫として、分散オブジェクトとの 「代理(proxy)オブジェクト」の活用がある。最後にその将来を予測し ておくことにしよう。

4,究極の分散オブジェクト環境--境界を持たないコンピュータ

掌の上の携帯機器が直接インターネットに接続された状態を仮定しよう。 その上ではもちろんコンパクトな JVMが動作している。携帯機器には通 常あらゆる機能を常駐させておくことはできない。サービスが必要にな ったら、アプリケーション本体や必要なデータを動的にダウンロードす ることで、それに対処することになるだろう。
もっとも、アプリケーションの本体やデータのすべてを読み込む必要は ない。一例として「翻訳ソフト」のアプリケーションを考えてみよう。 巨大な辞書や複雑な構文解析のルーチンは端末がそれぞれ抱え込む必要 などまったくないのは明らかだ(現在のPCは、それらをメモリやハード ディスクを贅沢に使用することで実現してしまっているが)。
アプリケーションのうち端末がダウンロードすべき機能は、ユーザから 翻訳したい文章の入力を受け付ける部分と、「翻訳結果」を表示するた めのユーザ・インターフェイスのみである。辞書と翻訳のために複雑な 処理は、専用のサーバが引き受けるようにするように設計することにす れば、端末の側で自前で多くの資源を抱え込む必要はまったくない。ダ ウンロードのための通信量も必要最少限で間に合う。ユーザから見た場 合、翻訳の処理をしたのがどのハードウェアであるのかは問題ではない。 実際、上述のようなシステムでは、サービスの実装はユーザからは覆い 隠されている。ユーザは「どこに資源が存在し、どの CPUがサービスを 提供してくれるのか?」といった問題は意識する必要がなくなる。「ど んなサービスが利用可能なのか?あるいは、どんなサービスを提供して ほしいのか?」という問題に集中すればよいことになる。
端末にIPが割り振られることで、JavaのRMIなどの分散オブジェクトの 機能はそのまま端末上のJVMで処理できるようになる。このメリットは 現実には軽量であるが、見かけ上は複雑な処理のインターフェイスを担 当する「代理オブジェクト」を使用できる点である。 分散オブジェクトは、単にアプリケーションの構築の手法というだけで はなく、資源の限定された掌サイズの携帯機器の上で高価な計算機資源 を必要とするアプリケーションがあたかも実行されているようにできる。
もちろん、外部の計算機資源を利用する方法として、従来のようなサー バ・クライアントモデルの通信を選択することも可能である。そのよう な方法と、ここで論じている「分散オブジェクトの集合体」とも言うべ きソフトウェアは、決して相反する存在ではない。むしろ分散オブジェ クトはより抽象化が進んだレイアを提供すると解釈していただきたい。 つまり、プロトコルとかデータベースの種類とかを意識せず、あたかも 巨大なスーパーバーチャルマシンが存在し、プログラマはその上の資源 を自由に利用できるアプリケーションを設計すればいいのである。

こうした分散型のアプリケーションはきわめて自然な形でネットワーク 全体に広がっていくだろう。これまでコンピュータのユーザは、どんな ハードウェアによってサービスが提供されるかを常に意識してきた。し かし、WAN,LANから移動体の携帯端末まで1つのプロトコルに統一された 環境では、もはやどの場所でサービスのための処理が行なわれているの かは次第に重要ではなくなっていくだろう。
そして先に述べた組み込み系Javaの1つの大きな課題である「ハードウ ェア資源の格差」の問題も解決してくれる可能性がある。なぜなら、分 散オブジェクトを用いたアプリケーションではメモリやCPU資源を意識し なくてもサービスを実現できるからである。ユーザから見た場合同じ機 能を持つアプリケーションを、あたかもどんな機器に対してもダウンロ ードできるように見えるだろう。あるいは、ダウンロードという概念自 体が消滅することになるかもしれない。ユーザにとっては、ネットワー クそのものが1つのコンピュータであって、アプリケーションを明示的 に呼び出すというようりも、その「たった1つのコンピュータ」に向け 単に必要なサービスを要求するというだけのスタイルに近づいて行くに 違いない。