Com o advento de modelos computacionais de negócios baseados na Internet, os aplicativos consistem crescentemente em clientes e servidores que operam em diferentes regiões geográficas.
Essas diferenças apresentam as seguintes contestações para a tarefa de projetar uma infra-estrutura sólida de cliente/servidor.
Os clientes e os servidores podem residir em computadores que possuem arquiteturas endian diferentes: um cliente pode residir em uma CPU little-endian, enquanto o código do servidor é executado em uma big-endian. Um cliente pode desejar chamar um método de negócios em um servidor executando um conjunto de códigos diferente do que o do cliente.
Uma infra-estrutura de cliente-servidor deve definir regras exatas de conversão e monitoração do conjunto de códigos e de endian. A plataforma Java quase eliminou esses problemas de uma maneira exclusiva, confiando na JVM (Java Virtual Machine), que codifica todos os dados da cadeia no formato UCS-2 e externaliza tudo no formato big-endian. A JVM utiliza um conjunto de programas específicos da plataforma para fazer interface com a plataforma nativa. Esses programas executam quaisquer conversões necessárias do conjunto de códigos entre o UCS-2 e o conjunto nativo de códigos de uma plataforma.
Os processos de cliente e de servidor podem utilizar configurações de código do idioma diferentes. Por exemplo, um cliente espanhol pode chamar um método de negócios para um objeto que reside em um servidor para inglês dos Estados Unidos. Alguns métodos de negócios fazem distinção de códigos de idioma por natureza; por exemplo, fornecido um método de negócios que retorna uma lista classificada de cadeias, o cliente espanhol espera que a lista seja classificada de acordo com a seqüência intercalada do espanhol, não na seqüência intercalada do inglês do servidor. Como os procedimentos de recuperação e classificação de dados são executados no servidor, o código do idioma do cliente deve estar disponível para executar uma classificação legítima.
Uma consideração similar aplica-se em instâncias em que o servidor tem que retornar cadeias contendo mensagens de data, hora, moeda e exceção, e assim por diante, formatadas de acordo com as expectativas culturais do cliente.
Os processos de cliente e de servidor podem ser executados em fuso horários diferentes. Até o momento, toda a literatura e os recursos de internacionalização concentram-se principalmente em questões relacionadas ao conjunto de códigos e código do idioma. O problema de fuso horário tem geralmente sido ignorado, mesmo que os métodos de negócios possa ser sensíveis ao fuso horário e ao código do idioma.
Por exemplo, suponhamos que um fornecedor informe que os pedidos recebidos antes das 14:00 h são processados até as 17:00 h do mesmo dia. Os horários fixados, é claro, estão no fuso horário do servidor que está processando o pedido. É importante saber o fuso horário do cliente para fornecer aos clientes em outros fusos horários os horários corretos para os processos no mesmo dia.
Outras operações sensíveis ao fuso horário incluem data e hora de mensagens registradas em um servidor e o acesso a recursos de arquivos ou de bancos de dados. O conceito de horário de verão complica a questão de fuso horário.
O J2EE (Java 2 Platform, Enterprise Edition) fornece suporte para componentes de aplicativo que são executados em computadores com arquitetura e conjuntos de códigos endian diferentes. Ele não fornece suporte dedicado para componentes de aplicativo executados em computadores com diferentes códigos do idioma ou fusos horários.
O serviço de internacionalização trata das contestações apresentadas pela incompatibilidade de códigos do idioma e fusos horários sem incorrer nas limitações de técnicas convencionais. O serviço gerencia sistematicamente a distribuição de contextos de internacionalização nos diversos componentes de aplicativos EJB, incluindo aplicativos clientes, beans corporativos e servlets. Para obter informações adicionais, consulte o centro de informações do WebSphere Application Server Network Deployment.