グローバリゼーション

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

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

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

規則により、あるロケールを指定するには、異なる標準が適用されるコードのペア (言語と地域) を使用します。 ISO-639 標準は言語コードを管理し、ISO-3166 標準は地域コードを管理します。 2 つのコードを表記する際には、通常は下線 (_) 文字で結合させます。例えば、en_US は米国英語を表します。 Java™ コードでロケールの設定および検索を行う場合には、java.util.Locale クラスを使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cin_main
ファイル名:cin_main.html