Java シン・クライアント

Java™ シン・クライアントは、Application Client インストール または WebSphere® Application Server インストールのランタイム環境を 使用する Java Platform, Standard Edition (Java SE) モードです。Java シン・クライアント・ランタイム環境は、オブジェクト解決、セキュリティー、Reliability Availability and Serviceability (RAS)、およびその他のサービスについて、フル機能の Java SE クライアント・アプリケーションに必要なサポートを提供します。 ただし、Java シン・クライアントは、これらのサービスへのアクセスを容易にするクライアント・コンテナーはサポートしません。

Java シン・クライアントは、「Java シン・アプリケーション・クライアント」と呼ばれる場合があります。

Java シン・クライアントは、クライアント・マシン上の Java Platform, Enterprise Edition (Java EE) プラットフォームのオーバーヘッドなしで、提供された IBM® JRE を使用するために、フル機能の Java SE クライアント・アプリケーション・プログラミング環境を必要とするユーザーをサポートするように設計されています。

Java シン・クライアントは、クライアント・アプリケーションが必要とするサービスの初期化は行いません。 例えば、クライアント・アプリケーションは、 CosNaming または JNDI API のいずれかを使用したネーミング・サービスの初期化を担当します。

Java シン・クライアントでは、エンタープライズ Bean およびローカル・リソースに論理名 (ニックネーム) を使用することはサポートされていません。 クライアント・アプリケーションは、エンタープライズ Bean に対する参照を (Java Naming and Directory Interface (JNDI) または CosNaming を使用して) 解決する場合に、ネーム・サーバーの場所と、参照が名前空間にバインドされたときに使われた完全修飾名を認識している必要があります。 ローカル・リソースに対する参照を解決する場合、クライアント・アプリケーションは JNDI 検索を使用してリソースに解決することはできません。 その代わりに、クライアント・アプリケーションは、適切な API (JDBC や Java Message Service (JMS) など) を使用してリソースへの接続を明示的に作成する必要があります。エンタープライズ Bean またはリソースの場所が変更された場合は、シン・クライアント・アプリケーションでも、lookup() ステートメントに指定される値を変更する必要があります。

Java シン・クライアント・ランタイム環境は、Java SE クライアント・アプリケーションがリモート・エンタープライズ Bean にアクセスするためのサポートを提供し、また、さまざまなエンタープライズ Bean サービスの実装を提供します。 クライアント・アプリケーションでは、Java シン・クライアント・ランタイム環境を使用して CORBA オブジェクトおよび CORBA ベースのサービスにアクセスすることもできます。

Java シン・クライアントは RMI-IIOP プロトコルを使用しています。そのため、クライアント・アプリケーションはエンタープライズ Bean 参照および CORBA オブジェクト参照の両方にアクセスできるようになります。また、このプロトコルを使用することによって、クライアント・アプリケーションはサポートされている任意の CORBA サービスも使用できるようになります。RMI-IIOP プロトコルと CORBA サービスのアクセシビリティーを併用することよって、エンタープライズ Bean 参照と CORBA オブジェクト参照の両方にアクセスする必要があるクライアント・アプリケーションを容易に開発できるようにします。

同一クライアント・アプリケーション内でエンタープライズ Bean と CORBA の両方のプログラミング・モデルを使用する場合には、これらのプログラミング・モデルの相違を理解し、両方の環境を管理する必要があります。 例えば、CORBA プログラミング・モデルでは、名前空間でのオブジェクトの解決のために CORBA CosNaming ネーム・サービスを使用する必要があります。 エンタープライズ Bean プログラミング・モデルでは、JNDI ネーム・サービスを使用する必要があります。 クライアント・アプリケーションは、 これら 2 つのネーミング・サービスの使用を初期化し適切に管理する必要があります。

別の相違点として、エンタープライズ Bean モデルでは JNDI の実装が Object Request Broker (ORB) を初期化し、クライアント・アプリケーションは ORB が存在することを認識しないことを挙げることができます。 しかし、CORBA モデルでは、クライアント・アプリケーションが ORB.init() 静的メソッドを用いて ORB を明示的に初期化することが必要になります。
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): CORBA モデルでは、ワークロード管理 (WLM) 機能とクラスター・フェイルオーバーは使用できません。クラスター環境内のオブジェクトにアクセスするには、エンタープライズ Bean モデル (および JNDI) を使用してください。gotcha

Java シン・アプリケーション・クライアントには、CLASSPATH および JAVA_HOME の環境変数を設定して Java シン・アプリケーション・クライアント・ランタイムを使用可能にするためのバッチ・コマンドが提供されています。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): Java シン・アプリケーション・クライアントが含まれる環境で、ターゲット・クラスターのクラスター・メンバーに関するポート情報が 突然失効することがあります。このような状況が最もよく発生するのは、 すべてのクラスター・メンバーに動的ポートがあり、要求が送信されていない期間に それらのクラスター・メンバーが再始動される場合です。 このような場合、クライアント・プロセスは、結果的に、 ノード・エージェントにルーティングしてクラスター・メンバーの新しいポート・データを受信し、 その新しいポート・データを使用してクラスター・メンバーにルーティングしようとします。

クライアントがノード・エージェントと通信する際に問題が発生した場合、 あるいは新しいポート・データをクラスター・メンバーとノード・エージェントの間で伝搬する際に問題が発生した場合、 クライアントで要求が失敗する可能性があります。 これらの失敗は、一時的なものにすぎない場合もあります。 そうでない場合は、失敗を解決するために 1 つ以上の プロセスを再始動する必要があります。

このような場合に発生する可能性があるクライアントのルーティング問題を回避するためには、 クラスター・メンバーで静的ポートを構成するようにします。 静的ポートを構成すると、 クライアント・プロセスがクラスター・メンバーに関する情報を取得する際にポート・データが変わることはありません。 クラスター・メンバーが再始動された場合や、 プロセス間で通信あるいはデータ伝搬の問題が発生した場合でも、クライアントが保持しているポート・データは引き続き有効です。 この回避策によって、 必ずしも通信やデータ伝搬の根本的な問題が解決されるわけではありませんが、 クライアントにより予期しないあるいは不規則なルーティングが決定される症状は回避されます。

gotcha

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



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