インターネット・ベースのビジネス・コンピューター・モデルの到来により、ア プリケーションはさまざまな地理上の地域で作動するクライアントとサーバーで構成される傾向 が高まります。
これらの相違点により、堅固なクライアント/サーバー・インフラストラクチャーを設 計するタスクに以下の課題が組み込まれます。
異なるエンディアン方式を持つコンピューター内に、それぞれクライアントとサーバーを持つことができます。 クライアントをリトル・エンディアン方式の CPU に置き、 サーバー・コードをビッグ・エンディアン方式の CPU で実行させることが可能です。 クライアントが、クライアントのものとは異なるコード・セット上で実行されるサーバー上の ビジネス・メソッドを呼び出す必要がある場合があります。
クライアント/サーバー・インフラストラクチャーは、正確なエンディアンおよびコード・セットの追跡および型変換の規則を定義する必要があります。 Java プラットフォームでは、すべてのストリング・データを UCS-2 形式でエンコードし、 すべてをビッグ・エンディアン形式で外部化する Java 仮想マシン (JVM) に依存するという独特 の方法でこれらの問題をほぼ解消してきました。 JVM では、ネイティブ・プラットフォームとのインターフェースをとるための、 プラットフォーム固有のプログラムのセットを使用しています。 これらのプログラムでは、 UCS-2 とプラットフォームのネイティブのコード・セットの間で必要なコード・セット型変換が実行されます。
クライアントおよびサーバーのプロセスは異なるロケール設定を使用することができます。 例えば、スペインのクライアントが、米国英語のサーバー上にあるオブジェクト上のビジネス ・メソッドを呼び出すことがあります。 いくつかのビジネス・メソッドは、本質的に ロケールに依存します。例えば、 ストリングのソート済みリストを戻すビジネス・メソッドの場合、 スペインのクライアントは、サーバーの英語照合シーケンスではなく、 スペイン語照合シーケンスに従ってそのリストがソートされることを期待します。 データ検索およびソート・プロシージャーはサーバー上で実行されるので、 合理的なソートを実行するためにクライアントのロケールが使用可能である必要があります。
類似した 考慮事項が適用される例が他にもあります。サーバーが、 日付、時刻、通貨、例外メッセージなどを含むストリングをクライアントの国/地域別の期待に沿うフォーマットで 戻さなくてはならない場合です。
クライアントおよびサーバーのプロセスは異なる時間帯で稼働させることができます。 これまで、 すべての国際化対応の文献およびリソースは、主にコード・セットおよびロケール関連問題に集中していました。 ビジネス・メソッドが 時間帯およびロケールに依存する場合があるにもかかわらず、これらの文献およびリソースでは 時間帯問題が概して無視されていました。
例えば、ベンダーが、2:00 PM までに受注した注文を同日の 5:00 PM までに処理 することを要求すると仮定します。 与えられる時刻は 当然、注文を処理しているサーバーの時間帯です。 他の時間帯にいるカスタマーに同日処理のための正しい時刻を与えるためには、 クライアントの時間帯がわかっていることが大切です。
他の時間帯依存の操作には、 サーバーにログ記録されるメッセージへのタイム・スタンプ付加、 およびファイルまたはデータベース・リソースへのアクセスが含まれます。 夏時間調整の概念によって、 時間帯問題はさらに複雑になります。
Java 2 Platform, Enterprise Edition (J2EE) は、 異なるエンディアン方式およびコード・セットを使用したコンピューター上で実行されている アプリケーション・コンポーネントに関するサポートを提供します。 さまざまなロケールまたは時間帯を持つコンピューター上で実行されているアプリケーション・ コンポーネントに対しては、専用のサポートは提供していません。
国際化対応サービスでは、 従来の技法の制限を受けることなく、 ロケールおよび時間帯のミスマッチにより発生する問題に対処できます。 このサービスは、クライアント・アプリケーション、エンタープライズ Bean、 サーブレットなどの EJB アプリケーションのさまざまなコンポーネント間で、 国際化対応コンテキストの配布を体系的に管理します。 詳しくは、WebSphere Application Server Network Deployment インフォメーション・センターを参照してください。