Cliente thin Java
O cliente thin Java™ é um modo Java Platform, Standard Edition (Java SE) de usar o ambiente de tempo de execução de uma instalação do Application Client ou uma instalação do WebSphere Application Server. O ambiente de tempo de execução do thin client Java fornece o suporte necessário aos aplicativos clientes Java SE com funções integrais para resolução de objeto, segurança, Confiabilidade, Disponibilidade e Capacidade de Manutenção (RAS) e outros serviços. Porém, o cliente thin Java não suporta um Contêiner do Cliente que forneça acesso fácil a esses serviços.
O thin client Java é às vezes referido como "cliente do aplicativo thin Java".
O cliente thin Java é projetado para suportar aqueles usuários que desejam que um ambiente de programação de aplicativo cliente Java SE com funções completas, use o IBM® JRE fornecido, sem a sobrecarga da plataforma Java Platform, Enterprise Edition (Java EE) na máquina cliente.
O cliente thin Java não executa inicialização de nenhum serviço que o aplicativo cliente possa necessitar. Por exemplo, o aplicativo cliente é responsável pela inicialização do serviço de nomes, por meio das APIs de CosNaming ou JNDI.
O cliente thin Java não suporta o uso de nomes lógicos ("apelidos") para enterprise beans e recursos locais. Quando um aplicativo cliente resolve uma referência para um enterprise bean (usando Java Naming and Directory Interface (JNDI) ou CosNaming), o aplicativo deve conhecer o local do servidor de nomes e o nome completo usado quando a referência foi ligada ao espaço de nomes. Quando um aplicativo cliente resolve uma referência para um recurso local, o aplicativo cliente não pode resolver para o recurso por meio de uma pesquisa JNDI. Em vez disso, o aplicativo cliente deve explicitamente criar a conexão para o recurso usando a API apropriada; por exemplo, JDBC ou Java Message Service (JMS). Se o local de um enterprise bean ou recurso for alterado, o aplicativo cliente thin precisará também alterar o valor colocado na instrução lookup().
O ambiente de tempo de execução do cliente thin Java fornece suporte para aplicativos clientes Java SE para acessar enterprise beans remotos, e fornece a implementação para vários serviços de enterprise bean. Aplicativos clientes também usam o ambiente de tempo de execução do cliente thin Java para acessar objetos CORBA e serviços baseados em CORBA.
O cliente thin Java usa o protocolo RMI-IIOP, que possibilita ao aplicativo cliente acessar ambas as referências, de enterprise bean e objeto CORBA. O uso desse protocolo permite que o aplicativo cliente use quaisquer serviços CORBA suportados. O uso do protocolo RMI-IIOP junto com a acessibilidade de serviços CORBA pode ajudá-lo no desenvolvimento de um aplicativo cliente que necessite acessar referências de enterprise bean e referências de objeto CORBA.
Se escolher usar ambos os modelos de programação, enterprise beans e CORBA, no mesmo aplicativo cliente, você precisa compreender as diferenças entre esses modelos de programação para gerenciar ambos os ambientes. Por exemplo, o modelo de programação CORBA exige o serviço de nomes CosNaming de CORBA para resolução de objetos em um espaço de nomes. O modelo de programação de bean corporativo exige o serviço de nomes JNDI. O aplicativo cliente precisa inicializar e gerenciar corretamente esses dois serviços de nomes.

O aplicativo cliente thin Java fornece um comando em lote que você pode usar para definir as variáveis de ambiente CLASSPATH e JAVA_HOME para ativar o tempo de execução do aplicativo cliente thin Java.

Se ocorrer qualquer problema que impeça o cliente de se comunicar com o agente do nó, ou que impeça que os dados da nova porta sejam propagados entre os membros de cluster e o agente do nó, poderão ocorrer falhas de solicitação no cliente. Em alguns casos, estas falhas são temporárias. Em outros casos, é necessário reiniciar um ou mais processos para resolver uma falha.
Para contornar os problemas de roteamento do cliente que possam suscitar nestes casos, é possível configurar portas estáticas nos membros de cluster. Com portas estáticas, os dados da porta não são alterados conforme um processo do cliente obtém informações sobre os membros de cluster. Mesmo se os membros de cluster são reiniciados, ou há problemas de comunicação ou de propagação de dados entre os processos, os dados da porta que o cliente retém ainda são válidos. Essa solução alternativa não resolve necessariamente os problemas de comunicação ou propagação de dados subjacentes, mas remove os sintomas de decisões de roteamento do cliente inesperadas ou irregulares.
gotcha