Configurando os Aplicativos do WebSphere Application Server para Iniciar Automaticamente os Servidores de Contêiner

Os servidores de contêiner em um ambiente do WebSphere Application Server iniciam automaticamente quando é iniciado um módulo que possui os arquivos XML do eXtreme Scale.

Antes de Iniciar

WebSphere Application Server e WebSphere eXtreme Scale devem estar instalados e você deve estar apto a acessar o console administrativo do WebSphere Application Server.

Sobre Esta Tarefa

Os aplicativos Java Platform, Enterprise Edition possuem regras de carregador de classe complexas que complicam muito o carregamento das classes quando uma grade de dados compartilhados é usada dentro de um servidor Java EE. Um aplicativo do Java EE normalmente é um arquivo Archive Corporativo (EAR). O arquivo EAR contém um ou mais módulos do Enterprise JavaBeans (EJB) ou archive web (WAR) implementados.

O WebSphere eXtreme Scale procura cada início de módulo e consulta arquivos XML do eXtreme Scale. Se o serviço de catálogo detectar que um módulo inicia com os arquivos XML, o servidor de aplicativos será registrado como um servidor de contêiner Java Virtual Machine (JVM). Ao registrar os servidores de contêiner com o serviço de catálogo, o mesmo aplicativo pode ser implementado em grades de dados de dados diferentes, mas não pode ser usado como uma grade de dados única pelo serviço de catálogo. O serviço de catálogo não é referente às células, grades ou grades dinâmicas. Uma única grade de dados pode se propagar por diversas células, se necessário.

Procedimento

  1. Compacte seu arquivo EAR para ter módulos que incluem os arquivos XML do eXtreme Scale na pasta META-INF. O WebSphere eXtreme Scale detecta a presença dos arquivosobjectGrid.xml e objectGridDeployment.xml no META-INF dos módulos EJB e da WEB quando eles iniciam. Se apenas um arquivo objectGrid.xml for localizado, a JVM será assumida para ser o cliente. Caso contrário, assume-se que esta JVM atua como um contêiner para a grade de dados que é definida no arquivo objectGridDeployment.xml .

    É necessário utilizar os nomes corretos para estes arquivos XML. Os nomes do arquivo fazem distinção entre maiúscula e minúscula. Se os arquivos não estiverem presentes, então o contêiner não será iniciado. É possível verificar no arquivo systemout.log se há mensagens que indicam que os shards estão sendo localizados. Um módulo EJB ou módulo WAR utilizando o eXtreme Scale deve ter arquivos XML do eXtreme Scale em seu diretório META-INF.

    Os arquivos XML do eXtreme Scale incluem: O tempo de execução detecta estes arquivos e, em seguida, entre em contato com o serviço de catálogo para informá-lo que outro contêiner está disponível para hospedar shards para esse eXtreme Scale.
    Dica: Se seu aplicativo tiver entidades e você estiver planejando usar um servidor de contêiner, configure o valor minSyncReplicas para 0 no arquivo descritor XML de implementação. Caso contrário, é possível ver uma das mensagens a seguir no arquivo SystemOut.log, pois o posicionamento não pode ocorrer até que outro servidor seja iniciado para atender a política minSyncReplica:
    CWPRJ1005E: Erro ao resolver associação de entidade. Entity=entity_name, 
    association=association_name.
    CWOBJ3013E: O repositório EntityMetadata não está disponível.  Tempo Limite 
    limite atingido ao tentar registrar a entidade: entity_name.
  2. Implementar e iniciar seu aplicativo.

    O contêiner inicia automaticamente quando o módulo é iniciado. O serviço de catálogo inicia para colocar primários e réplicas de partição (shards) o quanto antes. Esta disposição ocorre imediatamente, a menos que você configure o ambiente para atrasar o posicionamento. Para obter informações adicionais, consulte Controlando o Posicionamento.

O que Fazer Depois

Aplicativos dentro da mesma célula que os contêineres podem se conectar a estas grades de dados utilizando um método ObjectGridManager.connect(null, null) e, em seguida, chama o método getObjectGrid(ccc, " object grid name "). Os métodos connect ou getObjectGrid podem ser bloqueados até que os contêineres tenham colocado os shards, mas este bloqueio é um problema apenas quando a grade de dados está iniciando.

ClassLoaders

Quaisquer plug-ins ou objetos armazenados em um eXtreme Scale são carregados em um determinado utilitário de carga de classes. Dois módulos EJB no mesmo EAR podem incluir esses objetos. Os objetos são o mesmos, porém são carregados usando ClassLoaders diferentes. Se o aplicativo A armazena um objeto Person em um mapa que é local para o servidor, o aplicativo B recebe um ClassCastException se ele tentar ler esse objeto. Esta exceção ocorre porque o aplicativo B carregou o objeto Person em um utilitário de carga de classe diferente.

Uma abordagem para resolver este problema é ter um módulo raiz que contém os plug-ins e objetos necessários que estão armazenados no eXtreme Scale. Cada módulo que utiliza o eXtreme Scale deve referenciar tal módulo para suas classes. Outra resolução é colocar este objetos compartilhados em um arquivo JAR do utilitário que está em um carregador de classe comum compartilhado por ambos os módulos e aplicativos. Os objetos também podem ser colocados nas classes do WebSphere ou no diretório lib/ext, no entanto, esse posicionamento complica a implementação.

Os módulos EJB em um arquivo EAR normalmente compartilham o mesmo ClassLoader e não são afetados por este problema. Cada módulo WAR possui seu próprio ClassLoader e é afetado por este problema.

Conectando-se apenas ao cliente da grade de dados

Se a propriedade catalog.services.cluster for definida na célula, nas propriedades customizadas de nó ou servidor, qualquer módulo no arquivo EAR poderá chamar o método ObjectGridManager.connect (ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) para obter um ClientClusterContext. O módulo pode também chamar o método ObjectGridManager.getObjectGrid(ccc, "grid name") para obter uma referência para a grade de dados. Se qualquer objeto do aplicativo for armazenado em Mapas, verifique se esses objetos estão presentes em um ClassLoader comum.

Os clientes Java ou clientes fora da célula podem conectar-se usando a porta IIOP de autoinicialização do serviço de catálogo. No WebSphere Application Server, o gerenciador de implementação hospeda o serviço de catálogo por padrão. O cliente pode então obter um ClientClusterContext e a grade de dados nomeada.

Entity Manager

Com o gerenciador de entidades, as tuplas são armazenadas nos mapas em vez de nos objetos de aplicativos, resultando em menos problemas do carregador de classe. Entretanto, os plug-ins podem ser um problema. Observe também que o arquivo descritor XML do ObjectGrid de substituição do cliente sempre é necessário ao se conectar a uma grade de dados que possui entidades definidas: ObjectGridManager.connect("host:port[,host:port], null, objectGridOverride) ou ObjectGridManager.connect(null, objectGridOverride).