| 目次|前|次 |
目標
2.1 APIの目標
Image I/O APIの設計は、いくつかの基本的な目標をサポートしたいという願いに影響を受けました。特定のAPI機能セットに対して、正当な理由によって各目標が設けられています。それらの目標は、クライアント側アプリケーションの必要を主要な動機とするものと、サーバー側アプリケーションの必要を主要な動機とするものに大別できます。もちろん、これらの基本的な目標は、APIの機能のごく一部を表現しているに過ぎません。ここでは、このAPIを設計するに至った動機について感触をつかんでいただくために、これらの目標を列挙します。
経験からすると、アプリケーションの開発者にとっての使いやすさと、プラグインの開発者にとっての使いやすさの間に二律背反的な条件が存在する場合には、いつでもアプリケーションの開発者の方が優先されてきました。APIを利用してプラグインを作成するユーザーは比較的少数であり、実際にプラグインを作成する開発者でさえ、すぐに使用するイメージ形式をサポートするためにほんの一握りのプラグインを作成するだけなのが通例であるため、複雑な事柄をアプリケーションではなくプラグインの方に押し込んでしまうというのは、道理にかなっています。
プラグイン開発の複雑さを改善するために、よく使われる機能を実行するユーティリティ・メソッドや実装クラスがいくつか提供されています。しかし、あらゆる状況をカバーする実装クラスを提供するのは不可能です。しかも、提供するユーティリティ・クラスやユーティリティ・メソッドの数が多くなりすぎると、標準以外のプラグインを使用しないAPIユーザーにまで、サイズの大きいAPIを使わせることになってしまいます。プラグインの開発者には、既存のプラグインのソース・コードや、サンプルのソース・コードを、自分たちのプラグインに組み込むように期待します。このようにして、別々に開発されたプラグインを複数使用するといくらかの冗長性が生じることがありますが、大部分のユーザーはおそらく、どんな場合でも一度に少数のプラグインしか使用しないでしょう。というわけで、理論上は共用される可能性があっても実際には共用されないコードをロードしなければならないコストの方が、多数のプラグインを使用する場合にいくらか冗長なコードをロードするコストよりも高くつく、と私たちは考えます。
2.1.1クライアント側アプリケーションの目標
プラグイン可能性 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つのファイルに格納された複数のイメージ、マルチ解像度のイメージ、タイリングされたイメージなどにアクセスする機能を提供しなければなりません。また、大きいイメージを部分的にデコードする機能や、非常に大きいイメージを見渡すことができるようにするため、デコード中にサブサンプリングを実行する機能も必要です。さらに、イメージを書き込むときには、イメージ全体を一度にメモリー内に格納しなくても、断片ごとにイメージ・データを書き込めなければなりません。
2.1.2サーバーでの使用事例
イメージの動的な生成 最新のWebサーバーでは、コンテンツの大部分を動的に生成するのが通例になっています。Java ServletおよびJava Server Pages (JSP)の各APIにより、Webブラウザからの要求に応答してHTMLページを生成するための、移殖可能な手段が提供されます。ユーザーごとに独自にカスタマイズされたHTMLを生成できるのとまったく同じように、イメージの内容をカスタマイズすることもできます。
多くの場合、イメージの内容は動的に生成する必要があります。たとえば、株価チャートを提供する場合のことを考えてみましょう。表示される株式ごとに、かぎられた数のチャートを前もって生成して格納しておくことも可能な場合があります。しかし、ユーザーがチャートをカスタマイズできるようにするとしたら、どうなるでしょうか。たとえば、株価を表示する時間間隔を設定したり、株価の比較対象にする指標や他の株式を選べるようにしたりすると、前もって生成しなければならないイメージの数は指数関数的に増加します。そのようなカスタマイズを可能にするには、動的な生成というアプローチしかありません。
イメージのカスタマイズ Webのイメージは1つのサイズですべて間に合わせてしまうのが普通で、受信側の表示能力を考慮に入れることなく、いつも同じイメージ・データを配信しています。無線端末や携帯端末が増加するにつれて、それらの端末のかぎられた帯域幅や表示能力に合わせてイメージをカスタマイズする必要が生じてきます。逆に、デスクトップ・コンピュータの表示解像度は大きくなる傾向にあるため、Webのイメージの多くは見え方が小さすぎるという状況も起きています。イメージを拡大/縮小できないことは、視力障害を持つユーザーにとっても問題になります。サーバー側でのイメージのカスタマイズ処理を利用すれば、すべてのユーザーに最適なイメージを提供できます。ユーザーの好みに合わせて、イメージの解像度やカラー特性を選択できるわけです。
目次|前|次