Java-Thin-Client
Der Java™-Thin-Client ist ein Java-SE-Modus (Java Platform, Standard Edition) für die Verwendung der Laufzeitumgebung einer Application-Client-Installation oder einer Installation von WebSphere Application Server. Die Java Thin-Client-Laufzeitumgebung stellt die Unterstützung bereit, die Java SE-Clientanwendungen mit vollem Funktionsumfang für Objektauflösung, RAS (Reliability Availability and Serviceability) und andere Services benötigen. Der Java-Thin-Client unterstützt jedoch keinen Client-Container, der einen einfachen Zugriff auf diese Services ermöglicht.
Der Java-Thin-Client wird manchmal auch als "Java-Thin-Anwendungsclient" bezeichnet.
Der Java Thin Client ist für die Unterstützung von Benutzern konzipiert, die eine Programmierumgebung mit vollem Funktionsumfang für Java-SE-Clientanwendungen haben möchten, um die bereitgestellte IBM® JRE verwenden zu können, ohne die Plattform Java Platform, Enterprise Edition (Java EE) auf der Clientmaschine installieren zu müssen.
Der Java Thin Client initialisiert keine Services, die die Clientanwendung eventuell benötigt. So ist die Clientanwendung beispielsweise für die Initialisierung des Namensservice über die API CosNaming oder JNDI verantwortlich.
Der Java Thin Client bietet keine Unterstützung für die Verwendung logischer Namen ("Kurznamen") für Enterprise-Beans und lokale Ressourcen. Wenn eine Clientanwendung eine Referenz für eine Enterprise-Bean (über Java Naming and Directory Interface (JNDI) oder CosNaming) auflöst, muss die Anwendung die Position des Namensservers und den vollständig qualifizierten Namen kennen, der verwendet wurde, als die Referenz an den Namespace gebunden wurde. Wenn eine Clientanwendung eine Referenz für eine lokale Ressource auflöst, kann die Clientanwendung die Referenz nicht über eine JNDI-Suchfunktion (Lookup) in die Ressource auflösen. Stattdessen muss die Clientanwendung die Verbindung zur Ressource explizit über die entsprechende API erstellen, z. B. über JDBC oder Java Message Service (JMS). Wenn sich die Position einer Enterprise-Bean oder einer Ressource ändert, muss auch die Thin-Clientanwendung den Wert in der Anweisung lookup() ändern.
Die Laufzeitumgebung des Java-Thin-Clients ermöglicht Java-SE-Clientanwendungen den Zugriff auf ferne Enterprise-Beans und stellt die Implementierung für verschiedene Enterprise-Bean-Services bereit. Clientanwendungen können die Laufzeitumgebung des Java-Thin-Clients auch verwenden, um auf CORBA-Objekte und CORBA-basierte Services zuzugreifen.
Der Java-Thin-Client verwendet das Protokoll RMI-IIOP, über das die Clientanwendung sowohl auf Enterprise-Bean-Referenzen als auch auf CORBA-Objektreferenzen zugreifen kann. Mit diesem Protokoll kann die Clientanwendung auch alle unterstützten CORBA-Services nutzen. Die Verwendung des Protokolls RMI-IIOP und die Zugänglichkeit der CORBA-Services kann Ihnen bei der Entwicklung einer Clientanwendung helfen, die auf Enterprise-Bean-Referenzen und auf CORBA-Objektreferenzen zugreifen muss.
Wenn Sie sich für die Verwendung des Enterprise-Beans- und des CORBA-Programmiermodells in derselben Clientanwendung entscheiden, müssen Sie die Unterschiede zwischen den Programmiermodellen kennen, um beide Umgebungen verwalten zu können. So erfordert beispielsweise das CORBA-Programmiermodell die Verwendung des CORBA-Namensservice CosNaming für die Auflösung von Objekten in einem Namespace. Das Enterprise-Beans-Programmiermodell hingegen setzt die Verwendung des Namensservice JNDI voraus. Die Clientanwendung muss die beiden Namensservices initialisieren und ordnungsgemäß verwalten.

Der Java-Thin-Anwendungsclient stellt einen Stapelbefehl zur Verfügung, mit dem Sie die Umgebungsvariablen CLASSPATH und JAVA_HOME für die Aktivierung der Laufzeitumgebung des Java-Thin-Anwendungsclients setzen können.

Sollten Umstände eintreten, die den Client an der Kommunikation mit dem Node Agent hindern oder die verhindern, dass die neuen Portdaten zwischen den Cluster-Membern und dem Node Agent weitergeleitet werden, können auf dem Client Anforderungsfehler auftreten. In einigen Fällen treten diese Fehler nur temporär auf. In anderen Fällen müssen Sie einen oder mehrere Prozesse erneut starten, um einen Fehler zu beheben.
Um die Fehler, die in den genannten Fällen beim Client-Routing auftreten können, zu umgehen, können Sie statische Ports in den Cluster-Membern konfigurieren. Bei statischen Ports werden die Portdaten nicht geändert, wenn ein Clientprozess Informationen zu den Cluster-Membern abruft. Selbst wenn die Cluster-Member erneut gestartet werden oder Probleme bei der Kommunikation oder der Weiterleitung von Daten zwischen Prozessen bestehen, sind die vom Client gespeicherten Portdaten immer noch gültig. Diese Umgehung führt nicht notwendigerweise dazu, dass diese Probleme gelöst werden, doch treten die Symptome nicht erwarteter oder uneinheitlicher Routing-Entscheidungen nicht mehr auf.
gotcha