WebSphere Application Server Network Deployment, Version 6.1   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

グローバリゼーション

国/地域別情報に応じてユーザーに情報を表示するアプリケーションを、 グローバリゼーション されていると形容します。こうしたアプリケーションは、 異なる場所のユーザーと国/地域別に適切な方法で対話するよう構成できます。 グローバリゼーションされたアプリケーションでは、 ある地域のユーザーが、エラー・メッセージ、出力、およびインターフェース・エレメントを自分の要求した言語で見ることができます。 通貨と同様に日付と時刻のフォーマットも、特定地域のユーザーに適した形で表示されます。 他の地域のユーザーは、その地域の標準的な言語やフォーマットで出力を見ることができます。 グローバリゼーションは 2 つの段階で構成されます。国際化対応 (アプリケーション・コンポーネントが地域の規則を使用できるようにします) とローカリゼーション (特定の地域規則を実装します) です。

従来、グローバル化されたアプリケーションの作成は、複雑なシステムを作成する大企業に限られていました。 しかし、分散コンピューティングの普及、およびワールド・ワイド・ウェブ (WWW) の利用の増加により、 アプリケーション開発者は、はるかに多種多様なアプリケーションをグローバル化するよう迫られています。 この傾向の結果、アプリケーション開発者がグローバリゼーションの技法をさらに簡単に利用できるようにす ることが必要になっています。

アプリケーションの国際化対応は、時間帯とロケールという 2 つの変数により実行されます。 時間帯 は、グリニッジ標準時 (GMT) などの標準時間からの時間差としてローカル時間を計算する方法を表します。 ロケール は、言語、通貨、および日付などの情報を表す規則に関する情報の集まりです。 1 つの時間帯に多数のロケールが含まれることもあれば、 1 つのロケールが複数の時間帯にまたがっている場合もあります。時間帯とロケールの両方を指定することにより、 特定地域にいるユーザーの日付、時間、通貨、および言語が判別されます。

最初のステップ: インターフェース・ストリングのローカリゼーション

グローバル化されていないアプリケーションでは、 ユーザー・インターフェースは変更できない方法でアプリケーション・コードに書き込まれています。 ユーザー・インターフェースを国際化対応する場合は、アプリケーションの設計に抽象層を追加することになります。追加の抽象層によりアプリケーションによってサポートする必要がある各ロケールのアプリケーションをローカライズすることができます。

ローカライズされたアプリケーションでは、 ロケールによりアプリケーションがメッセージ・ストリングを取得するメッセージ・カタログが決定されます。アプリケーションは、エラー・メッセージを印刷するのではなく、いくつかのニュートラル言語情報とともにエラー・メッセージを表示します。最も単純な場合、各エラー状態は 1 つの鍵に対応します。使用可能なエラー・メッセージを印刷するには、アプリケーションで メッセージ・カタログ 内のキーを検索します。 それぞれのメッセージ・カタログは、関連付けられたストリングを持つキーのリストです。 それぞれのメッセージ・カタログが、異なるサポート言語のストリングを提供します。 アプリケーションは適切なカタログのキーを検索して、 対応するエラー・メッセージを要求された言語で取り出し、ストリングをユーザーに向けて印刷します。

エラー・メッセージを翻訳するよりも、テキストのローカリゼーションの方がはるかに応用が利きます。 たとえば、グラフィカル・ユーザー・インターフェース (GUI) の各エレメントを示すためにキーを使用したり、適切なメッセージ・カタログを提供したりすることにより、 GUI (ボタン、メニューなど) で複数の言語をサポートできるようになります。 追加言語に対するサポートを拡張するには、これらの言語用のメッセージ・カタログを提供する必要があります。 多くの場合において、アプリケーションには修正を加える必要はありません。

ローカライズ可能なテキスト・パッケージは、 Java クラスとインターフェースのセットであり、分散アプリケーションでストリングを容易にローカライズするために使用できます。言語固有のストリング・カタログは集中して保管できるため、効果的に保守できます。

分散アプリケーションにおけるグローバリゼーションの課題

インターネット・ベースのビジネス計算モデルの出現によって、異なる 地理的地域で運用されるクライアントやサーバーで構成されるアプリケーションが増加しています。これらの相違により、 強固なクライアント/サーバー・インフラストラクチャーの設計のために以下のような課題が生じています。

各クライアントとサーバーが、異なるエンディアン方式やコード・セットを使用するコンピューター上で稼働できます。

クライアントおよびサーバーは、異なるエンディアン方式を持つコンピューター内に存在できます。 クライアントをリトル・エンディアン方式の CPU に置き、 サーバー・コードをビッグ・エンディアン方式の CPU で実行させることが可能です。 クライアントが、クライアントのものとは異なるコード・セット上で実行されるサーバー上の ビジネス・メソッドを呼び出す場合があります。

クライアント/サーバー・インフラストラクチャーは、正確なエンディアンおよびコード・セットの追跡および型変換の規則を定義する必要があります。 Java プラットフォームでは、すべてのストリング・データを UCS-2 形式でエンコードし、 すべてをビッグ・エンディアン形式で外部化する Java 仮想マシン (JVM) に依存する独特の方法でこれらの問題をほぼ解消してきました。JVM では、ネイティブ・プラットフォームとのインターフェースをとるための、 プラットフォーム固有のプログラムのセットを使用しています。これらのプログラムでは、 UCS-2 とプラットフォームのネイティブのコード・セットの間で必要なコード・セット型変換が実行されます。

各クライアントとサーバーが、異なるロケール設定を使用するコンピューター上で稼働できます。

クライアントおよびサーバーのプロセスは異なるロケール設定を使用することができます。例えば、スペインのクライアントが、米国英語のサーバー上にあるオブジェクト上のビジネス・メソッドを呼び出すことができます。実際は、いくつかのビジネス・メソッドは ロケールに依存します。例えば、 ストリングのソート済みリストを戻すビジネス・メソッドの場合、 スペインのクライアントは、サーバーの英語照合シーケンスではなく、 スペイン語照合シーケンスに従ってそのリストがソートされることを期待します。データ検索およびソート・プロシージャーはサーバー上で実行されるので、 合理的なソートを実行するためにクライアントのロケールが使用可能である必要があります。

類似した 考慮事項が適用される例がほかにもあります。サーバーが、 日付、時刻、通貨、例外メッセージなどを含むストリングをクライアントの国/地域別の期待に沿うフォーマットで 戻さなくてはならない場合です。

クライアントとサーバーは異なる時間帯への配置が可能です。

クライアントおよびサーバーのプロセスは異なる時間帯での稼働が可能です。 これまで、 すべての国際化対応の文献およびリソースは、主にコード・セットおよびロケール関連問題に集中していました。 ビジネス・メソッドが ロケールだけでなく時間帯に依存する場合があるにもかかわらず、これらでは 時間帯問題が概して無視されていました。

例えば、ベンダーが「2:00 PM までに受注した注文は、同日の 5:00 PM までに処理する」と要求すると仮定しましょう。 与えられる時刻は 当然、注文を処理しているサーバーの時間帯です。他の時間帯にいるカスタマーに同日処理の正しい時刻を与えるために、 クライアントの時間帯を認識していることが大切です。

他の時間帯依存の操作には、 サーバーにログ記録されるメッセージへのタイム・スタンプ付加、 およびファイルまたはデータベース・リソースへのアクセスが含まれます。夏時間調整の概念によって、 時間帯問題はさらに複雑になります。

Java 2 Platform, Enterprise Edition (J2EE) は、 異なるエンディアン方式およびコード・セットを使用したコンピューター上で実行されているアプリケーション・コンポーネントに対するサポートを提供します。 異なるロケールまたは時間帯を持つコンピューター上で実行されているアプリケーション・コンポーネントに対しては、 専用のサポートは提供していません。

リモートのアプリケーション・コンポーネント間のロケールおよび時間帯のミスマッチを解決するために、 従来の方法では、クライアント・サイドのロケールまたは時間帯をサーバーへ伝達する必要のあるすべてのビジネス・メソッドで、 1 つ以上の追加パラメーターを渡しています。 この技法は単純ですが、Enterprise JavaBeans (EJB) アプリケーションで使用した場合、以下の制限があります。
  • 1 つ以上のパラメーターを、 ロケール依存または時間帯依存のメソッドへの呼び出しチェーン内のすべての Bean メソッドへ追加する必要があり、 煩雑になる。
  • 本質的にエラーが起こりやすい傾向がある。
  • レガシー・アプリケーションなど、変更をサポートしないアプリケーション内では実行不可能である。

国際化対応サービスでは、 従来の技法の制限を受けることなく、 ロケールおよび時間帯のミスマッチにより発生する問題に対処できます。 このサービスは、クライアント・アプリケーション、エンタープライズ Bean、 サーブレットなどの EJB アプリケーションのさまざまなコンポーネント間で、 国際化対応コンテキストの配布を体系的に管理します。詳しくは、タスク概要: アプリケーション・コンポーネントの国際化対応 (国際化対応サービス) を参照してください。




関連タスク
タスクの概説: インターフェース・ストリング (ローカライズ可能テキスト API) の国際化対応
タスク概要: アプリケーション・コンポーネントの国際化対応 (国際化対応サービス)
ロケールと文字エンコードの処理
タスクの概説: アプリケーションのグローバリゼーション
関連資料
この製品で提供される言語バージョン
グローバリゼーション: 学習用リソース
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 7:44:53 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cin_main.html