パッケージ javax.microedition.io

参照先:
          説明

パッケージ javax.microedition.io の説明

MID Profile は、Connected, Limited Device Configuration(CLDC) による Generic Connection フレームワークに基づくネットワーク・サポートを含みます。

HTTP ネットワーク

Connected, Limited Device Configuration で規定された javax.microedition.io のクラスに加えて、Mobile Information Device Profile は HTTP アクセスのために以下のインタフェースを含みます。 HttpConnection は"http://"接続文字列を Connector.open() でオープンすることで取得できます。

• HttpConnection

MIDP は Connected, Limited Device Configuration(CLDC) によって提供される接続性を定義する、Generic Connection フレームワークの機能を拡張しています。 MIDP は Internet で HTTP サーバーへのアクセスを提供するゲートウェイを利用して、TCP/IP などの IP プロトコルと WAP およびｉモードなどの非 IP プロトコルとの両方の実装において使用することができる、HTTP プロトコルのサブセットをサポートしています。 Generic Connection フレームワークは、クライアント - サーバとデータグラム・ネットワークをサポートするためにも使用します。 MIDP によって指定されたプロトコルだけを使用すれば、アプリケーションが全ての携帯用情報機器に（互換性よりも低い意味で移植性よりも高い意味で）ポータブルであると考えることができます。

ワイヤレス・ネットワークには幅広い変化が発生します。 これに対してデバイスとワイヤレス・ネットワークは、アプリケーション・サービスを提供する共同責任を負います。 このためにネットワークとワイヤード（有線）な Internet と比較して、特定のワイヤレス転送との間でブリッジすることができるゲートウェイを必要とすることがあります。 クライアント・アプリケーションと Internet サーバーは、非 IP ネットワークがそれらのネットワークに使用されることや特性について知っておく必要はありません。 クライアントとサーバの間のデータ転送を最適化するために、そのような知識を利用することができるかもしれませんが、そのようなことをしてはなりません。

例えば携帯情報機器において Internet Protocol(IP) のサポートを全く行わないかもしれません。 この場合 Internet にアクセスするためにゲートウェイを利用するでしょう。ゲートウェイは Internet URL のために DNS 名前解決など、いくつかのサービスに責任を持つでしょう。 デバイスとネットワークは、アクセスを制限するセキュリティとネットワーク・アクセスのポリシーを定義し、実装することができます。

HTTP ネットワーク接続

CLDC 由来の Generic Connection フレームワークは、基本となるストリームとコンテントのインタフェースを提供します。 インタフェース HttpConnection はリクエスト・ヘッダの設定、レスポンス・ヘッダの分析、他の HTTP 定義の機能を実装するのに必要な追加機能の定義を提供します。

インタフェースは HTTP 1.1 のサポートを必須とします。

MIDP を実装する各デバイスは以下の URL スキーム（RFC2396 Uniform Resource Indetifiers(URI) : Generic Syntax / 汎用構文）による接続をサポートしなければなりません。

RFC2616 Hypertext Transfer Protocol - HTTP/1.1 で定義されている"http"

MIDP を実装する各デバイスは RFC2616 による HEAD、GET および POST リクエストの完全な仕様をサポートしなければなりません。 また実装は絶対形式の URI をサポートしなければなりません。

実装はアプリケーションとサーバーから提供された全てのリクエスト・ヘッダとレスポンス・ヘッダを通過させなければなりません。 リクエストとレスポンス・ヘッダの順序は変更することができます。 ヘッダが通過時に変更されている場合は、同等なヘッダとしてデバイスおよびサーバーでヘッダを再構築しなければなりません。 どのような変換もアプリケーションと基点サーバに対して透過でなければなりません。 HTTP 実装は自動的にどのようなヘッダも含めることはありません。 アプリケーションは自身が必要とする全てのレスポンス・ヘッダを設定する責任を負います。

全ての適切なプロトコルは HTTP ヘッダとデータを確実に転送する能力を提供するように接続を実装するでしょう（RFC2616 は転送メカニズムだけを要求しており、TCP ストリームに依存しないようにかなりの注意を払っています）。

HTTP リクエスト・ヘッダ

HTTP 1.1 仕様はアプリケーションの取り決めたヘッダ、フォーム、フォーマット、言語またはその他の属性など、コンテンツを取得するためのリクエストとレスポンス・ヘッダの多様なセットを提供します。 MIDP では、アプリケーションはリクエストおよびレスポンス・ヘッダの選択と処理に責任を負います。 User-Agent だけは詳細に解説します。 サーバーとの間でお互いに同意する他のヘッダも使用することができます。

User-Agent と Accept-Language リクエスト・ヘッダ

MIDP においては、シンプルな User-Agent を現在のデバイスを特定するために使用することができます。 RFC2616 において定義されているように、フィールドには、特定の名前と任意のバージョン番号を含む空白で区切られたフィーチャを含みます。

インタフェース javax.microedition.io.HttpConnection の setRequestProperty メソッドによって、User-Agent フィールドを書式化および設定するのはアプリケーションの責任です。 これにより、以下に記載するプロファイル特有のリクエスト・ヘッダのいずれかに加えて、全ての適切なアプリケーション特有のフィーチャをも提供することができます。

HTTP を使用してデバイスにアプリケーションをロードできることを必須とはしません。 しかし、それを行うなら、User-Agent リクエスト・ヘッダにはデバイスがアプリケーション・ディスクリプタかアプリケーション JAR ファイルをロードするつもりであるということをリクエストに含めるべきです。 これによって、サーバーは最もデバイスに適合するアプリケーションを提供することができます。

"User-Agent"と"Accept-Language"フィールドは java.lang.System.getProperty を使用することで取得できるシステム・プロパティに定義された以下のフィーチャを含まなければなりません。 複数の値が存在する場合には、それらを要求ヘッダの個々のフィールドに合わせて再フォーマットする必要があります。

"User-Agent"と"Accept-Language"リクエスト・ヘッダに使用するシステム・プロパティ

HTTP リクエスト・ヘッダの例

User-Agent: Profile/MIDP-2.0 Configuration/CLDC-1.0
Accept-Language: en-US

StreamConnection の振る舞い

MIDP の全ての StreamConnection は一つの InputStream と一つの OutputStream を含んでいます。 DataInputStream をオープンすることは InputStream をオープンすることと等価であるとみなします。 また DataOutputStream をオープンすることは OutputStream をオープンすることと等価であると見なします。 StreamConnection から別の InputStream や別の OutputStream を開こうとすると IOException を throw します。 StreamConnection がクローズされた後に InputStream や OutputStream を開こうとすると IOException を throw します。

StreamConnection のメソッドは同期化を行いません。 別のスレッドから安全に呼ぶことができるストリーム・メソッドは close のみです。 別のスレッドで実行中の処理がストリームの close を呼び出した場合、全ての未確定の入出力メソッドは InterruptedIOException を throw しなければなりません。 この例では実装は直ちに例外を throw しなければなりません。 全ての開かれているストリームがクローズされた時および全ての StreamConnection がクローズされた時には、全ての未確定の入出力操作は直ちに中断しなければなりません。

セキュアなネットワーク

MIDP 2.0 以降で追加されたインタフェースは、WWW ネットワーク・サービスとのセキュアなコミュニケーションを利用可能にします。 セキュア・インタフェースは IP ネットワークの上に HTTPS と SSL/TLS プロトコルによるアクセスを提供します。 接続を保証するために適合する証明書プロファイルの詳細については javax.microedition.pki のパッケージ・ドキュメントを参照してください。 接続文字列に"https://"を含むアクセスに対して、Connector.open() は HttpsConnection を返します。 接続文字列に"ssl://"を含むアクセスに対しては、Connector.open() は SecureConnection を返します。

• HttpsConnection
• SecureConnection
• SecurityInfo
• Certificate
• CertificateException

低レベル IP ネットワーク

MIDP 2.0 以降では、MIDP 仕様に TCP/IP ソケットおよび UDP/IP データグラムのためのオプションのネットワーク・サポートを含みます。 接続文字列中にホストを含むものはアウトバウンド（外向き）の接続を意味し、ホストを含まないものはインバウンド（内向き）の接続を意味します。 ホストにはホスト名、直接の IPv4 アドレスまたは IPv6 アドレスを使用することができます（RFC2732 Format for Literal IPv6 Addresses in URL's [URL への IPv6 アドレスによるリテラルを含む書式 ] の規定に従い URL 文字列中に IPv6 アドレスを指定するためには、キャラクタ '[' と ']' を使用します。例えば http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.htm のように）。 実装は URL 文字列を解析して使用するアドレス形式を認識することができなければなりませんが、全てのアドレス形式とプロトコルをサポートする必要はありません。

ソケットまたはデータグラム接続においてホストとポート番号の両方が省略された場合、システムは利用可能なポートを割り当てます。 ホストとポート番号として割り当てられた内容は getLocalAddress と getLocalPort メソッドを呼び出すことで取得できます。 接続文字列にポート番号のためのパラメータが含まれない場合はコロン ':' を省略します。

接続文字列が"socket://host:port"という形式のアクセスに対して、Connector.open() は SocketConnection を返します。 接続文字列が"socket://:port"という形式のアクセスに対しては、Connector.open() は ServerSocketConnection を返します。 また、接続文字列が"datagram://host:port"という形式のアクセスに対しては、Connector.open() は UDPDatagramConnection を返します。

• SocketConnection
• ServerSocketConnection
• DatagramConnection
• Datagram
• UDPDatagramConnection

Push アプリケーション

MIDP 2.0 以降で使用可能な PushRegistry は、現在実行中ではないアプリケーションに対して発生した、ネットワーク接続イベントを受け取るための手段を MIDlet に提供します。

• PushRegistry

シリアル・ポート・コミュニケーション

MIDP 2.0 以降で使用可能な CommConnection は、ストリーム接続としてローカルのシリアル・ポートから他方のシリアル・ポートにアクセスする手段を MIDlet に提供します。

• CommConnection

ネットワーク機能のセキュリティ

セキュリティ・モデルとして、API と機能が署名かユーザーによって明確に許可が与えられた MIDlet スイートに対してのみ許容されるように制限するフレームワークを、パッケージ javax.microedition.midlet が提供します（特定のパーミッションを MIDlet スイートに与えることに関する詳細については MIDlet スイートのセキュリティを参照してください）。

MIDlet スイートによるネットワークの使用に関連してリスクが伴います。ネットワークを乱用したりそのことにより発生するコストがデバイス使用者に発生する可能性があります。 MIDP 2.0 は適切なパーミッションを要求し、許可されたそれらのアプリケーションだけにネットワーク機能を保護して提供することができるセキュリティ・フレームワークを提供します。

各プロトコルへはプロトコルと引数を含む URI を javax.microedition.io.Connector.open でオープンすることによりアクセスします。 パーミッションは、以下のアクセスが個別のプロトコルに許可されることを認めます。 プロトコルの機能性は URI の構文を定義する Connection インタフェースのサブクラスで規定され、それぞれのプロトコルに特有のメソッドを定義します。 デバイスはあらゆるプロトコルを実装することを要求されません。 プロトコルを実装する場合は、プロトコル名が指し示すプロトコルにアクセスするために使用する API のパッケージとクラス名にしたがって、セキュリティ・フレームワークにパーミッション名を定義します。 アクセスを提供する API は javax.microedition.io.Connector.open です。 この仕様によって定義されたプロトコルのために対応するパーミッションを以下の表に示します。

PushRegistry のセキュリティ

PushRegistry はセキュリティ・フレームワークとパーミッションを使用することで保護されます。 MIDlet スイートは、アラーム・ベースによる起動の登録、PushRegistry を使用することでの動的な登録、アプリケーション・ディスクリプタにおける静的な登録、ユーザーに対して Push 接続イベントまたはアラームに対応して MIDlet スイートの呼び出しを促し、以上のそれぞれに javax.microedition.io.PushRegistry パーミッションを必要とします。 保護ドメインは、ワンショット、セッションおよびブランケットの３つの対話モードでユーザー・パーミッションのための一般的な振る舞いを定義します。 PushRegistry および AMS（Application Management Software : アプリケーション管理ソフトウェア）の起動のための振る舞いは以下のように特化されています：

• ワンショット： MIDlet スイートが Push イベントやアラームによって呼び出される前および PushRegistry に対して要求を行うたびに、毎回ユーザーに確認を求めます。 例えばアラームや接続を登録する場合に。
• セッション： MIDlet スイートが Push イベントやアラームによって呼び出される前、または PushRegistry に対する１回目の要求を行う際に、ユーザーに確認を求めます。 例えばアラームか接続を登録する場合に。 次回 MIDlet が PushRegistry を使用する際はユーザーに確認を求めません。
• ブランケット： MIDlet スイートのインストール時、MIDlet スイートが Push イベントやアラームによって呼び出される前、または PushRegistry に対する１回目の要求を行う際に、ユーザーに１度だけ確認を求めます。

Push メカニズムはデバイスが他のネットワークの他の要素からサーバーとして接続を受け入れることができるように機能するプロトコルを使用します。 Push メカニズムを使用するために、MIDlet スイートはサーバー接続を使用するパーミッションを必要とします。 例えとして、Push で開始することができるチャット・プログラムを登録する場合のマニフェストの属性を以下に示します。

MIDlet-Push-1: socket://:79, com.sun.example.SampleChat, *
MIDlet-Permissions: javax.microedition.io.PushRegistry, javax.microedition.io.Connector.serversocket

導入されたバージョン:

CLDC 1.0, MIDP 1.0