Exemplo: Obtendo o Contexto Inicial Padrão

Existem várias formas de um programa obter o contexto inicial padrão.

O exemplo a seguir obtém o contexto inicial padrão. Observe que nenhuma URL de provedor é transmitida ao construtor javax.naming.InitialContext.

...
import javax.naming.Context;
import javax.naming.InitialContext;
...
Context initialContext = new InitialContext();
...

O contexto inicial padrão retornado depende do ambiente de tempo de execução do cliente JNDI (Java™ Naming and Directory Interface). As seguir estão os contextos iniciais retornados nos vários ambientes:

Cliente Thin
O contexto inicial é o contexto raiz do servidor que executa no host local na porta 2809.
Cliente Puro
O contexto inicial é o contexto especificado pela propriedade java.naming.provider.url transmitida ao comando launchClient com o parâmetro -CCD da linha de comandos. O contexto em geral será o contexto raiz do servidor no endereço especificado na URL, embora seja possível construir um URL corbaname ou corbaloc que seja resolvido para algum outro contexto.

Se não foi especificada uma URL de provedor, será o contexto raiz do servidor em execução no host e a porta especificados pelos parâmetros da linha de comandos -CCproviderURL ou -CCBootstrapHost e -CCBootstrapPort da linha de comandos. O host padrão é o host local, e a porta padrão é 2809.

Processo do Servidor
O contexto inicial é o contexto raiz do servidor para esse processo.

Embora nenhuma URL de provedor seja especificada explicitamente no exemplo acima, o construtor InitialContext pode localizar uma URL de provedor definida em outros lugares que ele pesquisará pelas definições de propriedades.

Os usuários de propriedades que afetam a inicialização do ORB devem ler o restante desta seção para uma compreensão mais profunda de exatamente como os contextos iniciais são obtidos.

Determinando Qual servidor É Utilizado para Obter o Contexto Inicial

Os servidores de nome WebSphere Application Server são CORBA CosNaming, e o produto fornece uma implementação de plug-in CosNaming JNDI para cliente JNDI a fim de executar operações de nomenclatura nos espaços de nome do produto. A implementação de plug-in CosNaming é selecionada através de uma propriedade JNDI que é transmitida ao construtor InitialContext. Essa propriedade é java.naming.factory.initial, e especifica a implementação de fábrica de contexto inicial a ser utilizada para obter um contexto inicial. A fábrica retorna uma instância de javax.naming.Context, que é parte de sua implementação.

O context factory inicial, com.ibm.websphere.naming.WsnInitialContextFactory, normalmente é utilizado pelos aplicativos para executar operações da JNDI. O ambiente de tempo de execução do WebSphere Application Server será configurado para utilizar esse context factory inicial se um não for especificado explicitamente pelo cliente JNDI. Quando o factory de contexto inicial é chamado, um contexto inicial é obtido. Os parágrafos a seguir explicam como o context factory inicial obtém o contexto inicial nos ambientes de cliente e servidor.

  • Registro de referências iniciais em processos do servidor

    Cada WebSphere Application Server tem um ORB utilizado para receber e enviar chamadas em objetos sendo executados nesse servidor. Os serviços em execução no processo de servidor podem registrar referências iniciais com o ORB. Cada referência inicial é registrada sob uma chave, a qual é um valor de cadeia. Uma referência inicial pode ser qualquer objeto CORBA. Os servidores de nome do WebSphere Application Server registram diversos contextos iniciais como referências iniciais em chaves predefinidas. Cada referência inicial de servidor de nomes é uma instância da interface org.omg.CosNaming.NamingContext.

  • Obtendo referências inicias em processos do cliente puro

    Clientes JNDI puros, isto é, aqueles que não estão sendo executados em um processo do WebSphere Application Server, também têm uma instância ORB. Essa instância de ORB do cliente pode ser transmitida ao construtor InitialContext mas, em geral, a fábrica de contexto inicial cria e inicializa a instância de ORB do cliente transparentemente. Um ORB de cliente pode ser inicializado com referências iniciais, mas as referências iniciais mais provavelmente serão resolvidas para objetos em execução em algum servidor. A fábrica de contexto inicial não define nenhuma referência inicial padrão quando inicializa um ORB. Se o método resolve_initial_references for chamado no ORB do cliente quando nenhuma referência inicial tiver sido configurada, a chamada de método falhará. Esta condição é típica para processos de cliente puro. Para obter uma referência NamingContext inicial, o depósito de informações do provedor de contexto inicial deve chamar string_to_object com um URL do objeto CORBA do tipo IIOP, como corbaloc:iiop:myhost:2809. A URL especifica o endereço do servidor do qual deve ser obtido o contexto inicial. As informações sobre o host e a porta são extraídas da URL do provedor transmitido para o construtor InitialContext.

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]Se nenhuma URL do provedor for definida, o context factory inicial do WebSphere Application Server utilizará a URL do provedor padrão corbaloc:iiop:localhost:2809.

    [IBM i]Se nenhuma URL do provedor for definida, o context factory inicial do WebSphere Application Server utilizará a URL do provedor padrão corbaloc:iiop:your.server.name:2809.

    O método ORB string_to_object resolve o URL e comunica-se com o ORB do servidor de destino para obter a referência inicial.

  • Obtendo referências iniciais em processos do servidor

    Se o cliente JNDI estiver em execução em um processo do WebSphere Application Server, o context factory inicial obterá uma referência para a instância ORB do servidor se o cliente JNDI não fornecer uma instância ORB. Em geral, os clientes JNDI em execução em processos de servidor utilizam a instância de ORB do servidor; ou seja, eles não transmitem uma instância de ORB para o construtor InitialContext. O servidor de nomes que está em execução no processo do servidor define uma URL de provedor como uma propriedade java.lang.System para servir como a URL de provedor padrão para todos os clientes JNDI no processo. Esse URL de provedor padrão é corbaloc:rir:/NameServiceServerRoot. Esse URL é resolvido para o contexto raiz de servidor para esse servidor. (O URL é equivalente a chamar resolve_initial_references no ORB com uma chave de NameServiceServerRoot. O servidor de nomes registra o contexto raiz do servidor como uma referência inicial sob essa chave.)

  • Entendendo o protocolo ORB legado

    Releases anteriores ao WebSphere Application Server Versão 5 utilizavam uma implementação ORB diferente, que usava um protocolo legado em comparação com o protocolo INS (Interoperable Name Service) utilizado atualmente. Essa alteração afetou a implementação do context factory inicial. Determinados tipos de clientes puros podem encontrar um comportamento diferente ao obter contextos JNDI iniciais em comparação com liberações anteriores do WebSphere Application Server. Esse comportamento é discutido em mais detalhes posteriormente nesta seção.

    As seguintes propriedades de ORB são utilizadas com o protocolo de ORB legado para inicialização do ORB e agora são reprovadas:

    • com.ibm.CORBA.BootstrapHost
    • com.ibm.CORBA.BootstrapPort

    O novo ORB INS é diferente em um aspecto principal, pois não exibe um comportamento padrão se nenhuma referência inicial for definida.

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]No ORB legado, os valores do host de auto-inicialização e porta tinham como padrões localhost e 900.

    [IBM i]No ORB legado, os valores do host e da porta de auto-inicialização utilizam como padrão your.server.name e 900.

    Todas as referências iniciais eram obtidas do servidor em execução no host e porta de bootstrap. Portanto, se o usuário do ORB não fornecesse o host e a porta de bootstrap, todas as referências iniciais eram resolvidas do host em execução no host local na porta 900. O ORB INS não tem um conceito de host de bootstrap ou porta de bootstrap. Todas as referências iniciais são definidas independentemente. Ou seja, referências iniciais diferentes podem ser resolvidas para servidores diferentes. Se ORB.resolve_initial_references for chamado com uma chave de modo que o ORB não seja inicializado com uma referência inicial que tenha essa chave, a chamada falhará.

    Nos releases anteriores à Versão 5, o context factory inicial chamava resolver_referências_iniciais no ORB na ausência de qualquer URL do provedor. Essa ação obtinha êxito se um servidor de nomes no host e porta de bootstrap padrão estivesse em execução. No release atual, com o INS ORB, isso falharia. (Na verdade, o ORB reverteria para o protocolo legado durante o período de reprovação, mas quando o protocolo legado não for mais suportado, a operação falhará.)

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]O depósito de informações do provedor de contexto inicial agora utiliza um URL de provedor padrão corbaloc:iiop:localhost:2809 e chama string_to_object com o URL de provedor.

    [IBM i]O context factory inicial agora utiliza uma URL de provedor padrão corbaloc:iiop:your.server.name:2809 e chama string_to_object com a URL do provedor.

    Essa operação preserva o comportamento que clientes puros encontravam em releases anteriores quando não definiam propriedades de bootstrap do ORB ou da URL de provedor. Entretanto, essa implementação de factory de contexto inicial diferente altera o comportamento encontrado por determinados clientes puros legados, que não especificam uma URL de provedor:

    • Clientes que configuram as propriedades de autoinicialização de ORB anteriormente listadas ao obter um contexto inicial.
    • Clientes que fornecem sua própria instância de ORB para o construtor InitialContext.

    Há duas maneiras de contornar essa mudança de comportamento.

    • Sempre especificar uma URL de provedor do tipo IIOP. Esta abordagem não depende das propriedades de host e porta de bootstrap e continuará a funcionar quando o suporte para as propriedades de host e porta de bootstrap for removido. Por exemplo, você pode expressar valores de propriedades de host de auto-inicialização e porta de myHost e 2809, respectivamente, como corbaloc:iiop:myHost:2809.
    • Utilizar uma URL de provedor do tipo rir:
      • Especifique corbaloc:rir:/NameServiceServerRoot se o ORB for inicializado para utilizar um servidor Versão 5 como servidor de auto-inicialização.
      • Especifique corbaname:rir:/NameService#domain/legacyRoot se o ORB for inicializado para utilizar um servidor Versão 4.0.x como servidor de auto-inicialização.
      • Especifique corbaloc:rir:/NameService se o ORB for inicializado para utilizar um servidor que não seja da Versão 5 ou 4.0.x como servidor de auto-inicialização.

      Os URLs desse tipo são equivalentes a chamar resolve_initial_references no ORB com a chave especificada. Se as propriedades de host e porta de bootstrap estiverem sendo utilizadas para inicializar o ORB, esta abordagem não funcionará quando as propriedade de bootstrap e de host não forem mais suportadas.

  • A ordem de procura do construtor InitialContext para propriedades JNDI

    Se o snippet de código mostrado no início desta seção for executado por um aplicativo, o servidor de bootstrap dependerá do valor da propriedade java.naming.provider.url.

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]Se a propriedade não estiver definida (em processos do servidor o valor padrão é definido como uma propriedade do sistema), o host padrão localhost e a porta padrão 2809 serão utilizados como o endereço do servidor a partir do qual obter o contexto inicial.

    [IBM i]Se a propriedade não for definida (em processos de servidores, o valor padrão é definido como uma propriedade do sistema), o host padrão your.server.name e a porta padrão 2809 serão utilizados como o endereço do servidor a partir do qual deve-se obter o contexto inicial.

    A especificação de JNDI descreve onde o construtor InitialContext procura definições da propriedade java.naming.provider.url mas, em resumo, a propriedade é obtidas dos seguintes lugares na ordem mostrada:

    Construtor InitialContext
    Isto não se aplica ao exemplo acima porque o exemplo usa o construtor InitalContext vazio.
    Ambiente de Sistema
    É possível adicionar propriedades de JNDI ao ambiente do sistema como uma opção na chamada do comando Java e por código de programa. A maneira recomendada de definir a URL do provedor no ambiente do sistema é como uma opção fornecida para a chamada do comando Java. A definição da URL do provedor dessa maneira não é temporal, portanto, a obtenção de um contexto inicial padrão sempre apresentará o mesmo resultado. Geralmente recomenda-se que o código do programa não defina a propriedade de URL do provedor no ambiente do sistema porque, como efeito colateral, isto poderia afetar de forma adversa outro código, provavelmente não relacionado, em execução em algum outro lugar no mesmo processo.
    Arquivo jndi.properties
    Pode haver muitos arquivos jndi.properties que estejam dentro do escopo do carregador de classes em efeito. Todos os arquivos jndi.properties são utilizados para definir propriedades de JNDI, mas a definição do URL do provedor é determinada pelo primeiro arquivo jndi.properties retornado pelo carregador de classes.

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rnam_example_prop1
Nome do arquivo: rnam_example_prop1.html