| 目次 | 前の項目 | 次の項目 | JavaTM Image I/O API ガイド |
Image I/O API の設計は、いくつかの基本的な目標をサポートしたいという願いに影響を受けました。特定の API 機能セットに対して、正当な理由によって各目標が設けられています。それらの目標は、クライアント側アプリケーションの必要を主要な動機とするものと、サーバー側アプリケーションの必要を主要な動機とするものに大別できます。もちろん、これらの基本的な目標は、API の機能のごく一部を表現しているに過ぎません。ここでは、この API を設計するに至った動機について感触をつかんでいただくために、これらの目標を列挙していきます。経験からすると、アプリケーションの開発者にとっての使いやすさと、プラグインの開発者にとっての使いやすさの間に二律背反的な条件が存在する場合には、いつでもアプリケーションの開発者の方が優先されてきました。API を利用してプラグインを作成するユーザーは比較的少数であり、実際にプラグインを作成する開発者でさえ、すぐに使用するイメージ形式をサポートするためにほんの一握りのプラグインを作成するだけなのが通例であるため、複雑な事柄をアプリケーションではなくプラグインの方に押し込んでしまうというのは、道理にかなっています。
プラグイン開発の複雑さを改善するために、よく使われる機能を実行するユーティリティーメソッドや実装クラスがいくつか提供されています。しかし、あらゆる状況をカバーする実装クラスを提供するのは不可能です。しかも、提供するユーティリティークラスやユーティリティーメソッドの数が多くなり過ぎると、標準以外のプラグインを使用しない API ユーザーにまで、サイズの大きい API を使わせることになってしまいます。プラグインの開発者には、既存のプラグインのソースコードや、サンプルのソースコードを、自分たちのプラグインに組み込むように期待します。このようにして、別々に開発されたプラグインを複数使用するといくらかの冗長性が生じることがありますが、大部分のユーザーはおそらく、どんな場合でも一度に少数のプラグインしか使用しないでしょう。というわけで、理論上は共用される可能性があっても実際には共用されないコードをロードしなければならないコストの方が、多数のプラグインを使用する場合にいくらか冗長なコードをロードするコストよりも高くつく、と私たちは考えます。
プラグイン可能性
Image I/O API を使用するように作成されたアプリケーションは、新しいプラグインが登場したときに、アプリケーションを作り直したり再コンパイルしたりしなくても、その新しいプラグインを自動的に利用できるようであるべきです。そのためには、イメージ形式に依存しない一式のインタフェースに、できるだけプラグインが準拠している必要があります。しかし、すべてのイメージ形式にはそれぞれ独自のプロパティーや機能があり、プラグインはそれらのプロパティーや機能をアプリケーションに対して公開できなければなりません。このことは、API 内のいくつかのインタフェースをプラグインが拡張できるようにすることによって実現されます。プラグインが提供する特定の拡張機能に対応していないアプリケーションは、プラグインの通常の機能だけを引き続き利用しますが、拡張されたインタフェースに対応しているアプリケーションはそれを利用できるというわけです。メタデータ (イメージ以外のデータ) に対する汎用のアクセスとプラグイン固有のアクセスをどちらもサポートするために、複数の形式のメタデータへのアクセスをプラグインが提供できるようにします。メタデータの形式には、プラグインに固有の形式、プラグインに依存しない、API によって定義された形式、および業界標準の形式があります。
自動および手動によるプラグインのインストールと選択
ユーザーの介入なしでイメージをロードしたい単純なアプリケーションの場合、ファイルの内容に基づいて読み込みプラグインを自動的に選択できることが重要です。ただし、不必要なのに複雑なクラスをロードしてインスタンス生成することは避けたいものです。プラグインのコード全体をロードしなくても、そのプラグインが特定のイメージを処理できるかどうかを判別できるようにしなければなりません。この目標を達成するため、プラグインのメインコードをロードしなくても簡単な照会を実行できるサービスプロバイダインタフェースの機構を利用して、プラグインのインスタンスを生成するようにします。1 つのプラグインに関係するすべてのバイトコード (.class) ファイルを、1 つの JAR ファイルにまとめることができます。そして、その JAR ファイルは、Java Runtime Environment に永続的にインストールすることも、アプリケーションの
CLASSPATH機構を使用して動的にロードすることも可能です。
手動によるプラグインの選択
プラグインを自動的に選択する機能は多くのアプリケーションにとって便利ですが、さらに先進的なアプリケーションのために、プラグインを選択するプロセスをもっと制御できるようにしておく必要もあります。これを実現するには、アプリケーションから照会したり操作したりできる、プラグインの実行時レジストリを利用します。
ネットワーク経由、ディスクベース、およびダイレクトな入出力
アプリケーションにとって、ディスクベースのデータとネットワークベースのデータの両方を処理できる必要性は、ますます大きくなってきました。多くの場合、ディスクベースのデータでさえ、ほかの API の必要を満たすために、InputStreamの形式で処理しなければなりません。Image I/O API が提供するインタフェースのセットでは、File、InputStream、またはその他のソースからのデータを統一的な方法で処理することができます。しかも、後方向と前方向にシークする機能は失われていません。この API には、将来、新しい入出力インタフェースを追加する余地も残されています。たとえば、イメージのキャプチャー装置や出力装置へのダイレクトなインタフェースを、アプリケーションコードを書き直さずに使用できます。
メタデータへのアクセス
イメージと一緒に格納されるメタデータは、イメージそのもののデータと同様の重要性を持つことがあります。Java Image I/O API では、完全かつ柔軟にメタデータにアクセスできます。メタデータの形式は多岐にわたり、イメージ形式に特化した情報が含まれているため、そのようなメタデータに直接アクセスする機能を汎用の API に組み入れるのは困難です。そこで、API には、メタデータを XML ドキュメントの構造にキャストするためのプラグインが必要です。そして、テキストデータだけでなく、Objectによる参照も可能なように拡張することができます。ここまで変換してしまえば、そのメタデータは、標準の XML DOM (Document Object Model) インタフェースを使用してアクセスしたり編集したりできます。Documentの構文がプラグインごとに異なるとしても、そのオブジェクトのデータを処理 (トラバース) し、表示し、編集するのに、使用しているプラグインに特有の知識は不要です。
高度なアプリケーションのサポート
高度なアプリケーションをサポートするためには、API は、「サムネール」イメージ、1 つのファイルに格納された複数のイメージ、マルチ解像度のイメージ、タイリングされたイメージなどにアクセスする機能を提供しなければなりません。また、大きいイメージを部分的に復号化する機能や、非常に大きいイメージを見渡すことができるようにするため、復号化中にサブサンプリングを実行する機能も必要です。さらに、イメージを書き込むときには、イメージ全体を一度にメモリ内に格納しなくても、断片ごとにイメージデータを書き込めなければなりません。
イメージの動的な生成
最近の Web サーバーでは、コンテンツの大部分を動的に生成するのが通例になっています。Java Servlet および Java Server Pages (JSP) の 各 API により、Web ブラウザからの要求に応答して HTML ページを生成するための、移殖可能な手段が提供されます。ユーザーごとに独自にカスタマイズされた HTML を生成できるのとまったく同じように、イメージの内容をカスタマイズすることもできます。多くの場合、イメージの内容は動的に生成しなければなりません。たとえば、株価チャートを提供する場合のことを考えてみましょう。表示される株式ごとに、限られた数のチャートを前もって生成して格納しておくことも可能かもしれません。しかし、ユーザーがチャートをカスタマイズできるようにするとしたら、どうなるでしょうか。たとえば、株価を表示する時間間隔を設定したり、株価の比較対象にする指標やほかの株式を選べるようにしたりすると、前もって生成しなければならないイメージの数は指数関数的に増加します。そのようなカスタマイズを可能にするには、動的な生成というアプローチしかありません。
イメージのカスタマイズ
Web のイメージは 1 つのサイズですべて間に合わせてしまうのが普通で、受信側の表示能力を考慮に入れることなく、いつも同じイメージデータを配信しています。無線端末や携帯端末が増加するにつれて、それらの端末の限られた帯域幅や表示能力に合わせてイメージをカスタマイズする必要が生じてきます。逆に、デスクトップコンピュータの表示解像度は大きくなる傾向にあるため、Web のイメージの多くは見え方が小さすぎるという状況も起きています。イメージを拡大/縮小できないことは、視力障害をもつユーザーにとっても問題になります。サーバー側でのイメージのカスタマイズ処理を利用すれば、すべてのユーザーに最適なイメージを提供できます。ユーザーの好みに合わせて、イメージの解像度やカラー特性を選択できるわけです。