Client léger Java
Le client léger Java™ est un mode JavaPlatform, Standard Edition (Java SE) qui utilise l'environnement d'exécution d'une installation d'Application Client for WebSphere Application Server ou d'une installation WebSphere Application Server. L'environnement d'exécution de client léger Java fournit le support nécessaire aux applications client Java SE complètes pour la résolution des objets, la sécurité, RAS (Reliability Availability and Serviceability) et d'autres service. Toutefois, le client léger Java ne propose pas de conteneur de client permettant d'accéder facilement à ces services.
Le client léger Java est parfois appelé le client d'application léger "Java".
Le client léger Java est conçu pour prendre en charge les utilisateurs qui souhaitent disposer d'un environnement de programmation d'application Java complet pour utiliser l'environnement JRE IBM® sans surcharger la machine client avec la plateforme Java Platform, Enterprise Edition (Java EE).
Le client léger Java ne procède à aucune initialisation des services dont peut avoir besoin l'application client. Ainsi, l'application client est responsable de l'initialisation du service de nommage, soit via CosNaming, soit via JNDI.
Le client léger Java ne permet pas d'utiliser des noms logiques ("pseudonymes") pour les beans enterprise et les ressources locales. Lorsqu'une application client résout une référence pour un bean enterprise (avec Java Naming and Directory Interface (JNDI) ou CosNaming), l'application doit connaître l'emplacement du serveur de noms ainsi que le nom qualifié complet qui a été utilisé lors de la liaison de la référence dans l'espace de noms. Lorsque l'application client résout une référence pour une ressource locale, elle ne peut pas obtenir la ressource à travers une recherche JNDI. A la place, elle doit créer explicitement la connexion à la ressource en utilisant l'API adéquate, par exemple JDBC ou JMS (Java Message Service). Si l'emplacement d'un bean enterprise change, l'application client léger doit également changer la valeur de l'instruction lookup() en conséquence.
L'environnement d'exécution du client léger Java permet aux applications client Java SE d'accéder aux beans enterprise distants et fournit l'implémentation requise pour différents services de bean enterprise. Les applications client peuvent aussi utiliser l'environnement d'exécution du client léger Java pour accéder aux objets CORBA et aux services basés sur CORBA.
Le client léger Java utilise le protocole RMI-IIOP qui permet à l'application client d'accéder non seulement aux références de beans enterprise mais aussi aux références des objets CORBA. L'utilisation de ce protocole permet aussi à l'application client d'accéder à tous les services CORBA pris en charge. L'emploi du protocole RMI-IIOP et l'accessibilité des services CORBA permettent de développer des applications client devant accéder à des références de beans enterprise et d'objets CORBA.
En cas d'utilisation de beans enterprise et de modèles de programmation CORBA dans une même application client, vous devez comprendre les différences entre ces modèles de programmation pour gérer les deux environnements. Par exemple, le modèle de programmation CORBA fait appel au service de nommage CosNaming pour la résolution des objets dans un espace de noms. Par contre, le modèle de programmation des beans enterprise nécessite le service de nommage JNDI. L'application client doit initialiser et gérer de manière adéquate ces deux services de nommage.

Le client léger d'application Java fournit une commande batch qui permet de définir les variables d'environnement CLASSPATH et JAVA_HOME pour activer le contexte d'exécution du client léger d'application Java.

Si des problèmes surviennent qui empêchent le client de communiquer avec l'agent de noeud ou qui empêchent les nouvelles données de port d'être propagées entre les membres de cluster et l'agent de noeud, les demandes peuvent échouer sur le client. Dans certains cas, ces échecs sont temporaires. Il peut également être nécessaire de redémarrer un ou plusieurs processus pour résoudre une situation d'échec.
Pour empêcher les problèmes d'acheminement pouvant survenir dans ces cas, vous pouvez configurer des ports statiques sur les membres du cluster. Avec des ports statiques, les données de port ne changent pas lorsqu'un processus client obtient des informations sur les membres du cluster. Même lorsque ces derniers sont redémarrés ou lorsqu'il existe des problèmes de communication ou de propagation des données entre les processus, les données de port conservées par le client sont toujours valides. Il n'est pas toujours possible de résoudre les problèmes de communication ou de propagation des données sous-jacents, cependant les symptômes des décisions d'acheminement client inappropriées ou inattendues sont supprimés.
gotcha