Obtenha alta disponibilidade com o InfoSphere Master Data Management Server e o WebSphere Application Server

Use o WebSphere Application Server Network Deployment para aprimorar a disponibilidade do MDM Server

Dados principais, por sua natureza, são críticos para missão. Organizações que empregam o IBM® InfoSphere® Master Data Management (MDM) Server precisam que ele esteja disponível ininterruptamente. A perda das capacidades do MDM Server pode ter um impacto significativo nas operações de uma organização. Neste artigo, entenda as capacidades do MDM Server em conjunto com o IBM WebSphere® Application Server Network Deployment (WAS ND) e o IBM HTTP Server (IHS), que oferecem às organizações o poder de garantir que o MDM Server estará disponível sempre que necessário. Este artigo também oferece instruções de programação e configuração que ajudam a garantir que as altas capacidades de disponibilidade do MDM Server, WAS ND e IHS sejam usadas com sucesso.

Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Solutions, Inc.

Author photoDennis Sosnoski é um consultor e instrutor especializado em XML e serviços da Web baseados em Java. Sua experiência em desenvolvimento de software profissional se estende por mais de 30 anos, sendo que nos últimos 10 focou tecnologias XML e Java do lado do servidor. Dennis é o desenvolvedor líder da estrutura de software livre JiBX XML Data Binding e a estrutura de serviços da Web associada JiBX/WS, assim como um committer na estrutura de serviços da Web Apache Axis2. Também foi um dos membros do Grupo de Especialistas para as especificações JAX-WS 2.0 e JAXB 2.0. O material para a série Serviços da Web Java é baseado nas aulas de treinamento de Dennis.



23/Mar/2010

High availability (HA) e tolerância a falhas

Um sistema está altamente disponível quando não há nenhum tempo de inatividade indesejado. Um sistema é tolerante a falhas se consegue continuar operando apesar de ter passado por uma falha. Um sistema pode obter alta disponibilidade sem ser tolerante a falhas, se puder ser construído de forma a nunca passar por qualquer falha. Mas isso nunca vai acontecer, portanto alta disponibilidade e tolerância a falhas andam lado a lado.


HA com clusters

Com o MDM Server como um aplicativo Java™ EE sendo executado no WebSphere Application Server, a maneira mais simples de obter HA é instalar o MDM Server em um cluster do WebSphere. Um cluster é um grupo de servidores de aplicativo em que todos se comportam como se fossem um único servidor. A carga de trabalho do cluster é compartilhada entre os servidores individuais que compõem o cluster. Se um servidor passar por uma falha e for desativado, os outros servidores podem assumir o controle e redistribuir a carga. O sistema em geral permanece disponível. Clientes que acessarem o sistema podem nunca chegar a saber que um servidor passou por qualquer dificuldade.

Se quiser usar o WebSphere Clusters, então você precisa usar o WebSphere Application Server Network Deployment edition (WAS ND). A edição de base não suporta clusters. Este artigo não entra em detalhes de como configurar um cluster em WAS ND, já que a documentação do WebSphere oferece muito mais detalhes.

A Figura 1 ilustra um possível cluster do WebSphere:

Figura 1. Um cluster simples
This diagram depicts a deployment management computer with a local node, networked with two remote node computers

Este cluster consiste em seis servidores de aplicativo (também conhecidos como membros do cluster) configurados em três nós que residem em três hosts (computadores) separados. Um nó pode ser considerado o equivalente a um arquivo AppServer. Um servidor de aplicativo geralmente pode ser equacionado para a JVM na qual os aplicativos Java/Java EE são executados. É possível configurar mais de um servidor de aplicativo em um único nó e mais de um nó (arquivo appserver) em um único computador. Você deve fazer isso se possui computadores extremamente poderosos e não estiver obtendo o rendimento que gostaria. Às vezes a própria JVM pode ser o gargalo, e como cada servidor de aplicativo é uma JVM, a maneira mais simples de aumentar o rendimento é ter mais JVMs em execução. Além disso, como as falhas de sistema nem sempre de devem a problemas no hardware de computadores, ter mais de um servidor de aplicativo em cada computador aumenta ainda mais a tolerância a falhas dos sistemas (e, portanto, sua disponibilidade) sem investimento adicional em hardware.


Instalando o MDM Server em um cluster

Componente Java EE do MDM Server

É muito simples instalar o MDM Server em um cluster do WebSphere Application Server. O instalador simplesmente pede para você especificar se deseja ou não instalar o MDM Server em um cluster. Se desejar, é só especificar o nome do arquivo gerenciador de célula e o nome do cluster, e o instalador fará o resto. Quando os componentes Java EE do MDM Server são implementados em um cluster, eles serão implementados em todos os nós que compõem o cluster e executarão todos os servidores de aplicativo executados no cluster, semelhante à configuração ilustrada na Figura 2:

Figura 2. Componentes do MDM instalados em um cluster
Diagram of MDM components installed on a cluster - the same deployment management computer with a local node, networked with two remote node computers illustrated in Figure 1, with Java EE components deployed to each

Outros componentes do MDM Server

O MDM Server também possui vários componentes clientes. Estes são componentes que executam funções específicas e que usarão os componentes do servidor para realizar suas tarefas. Esses componentes incluem:

  • Processador de lote
  • Gerenciador de eventos
  • Repositório de configuração

Esses componentes geralmente não são executados em um cluster (em outras palavras, simultaneamente em diversos computadores ou servidores de aplicativo). Eles são executados no computador no qual estão instalados. Este artigo discute como você pode adotar princípios de HA também com esses componentes.


Acessando componentes do MDM Server em um cluster

O MDM Server é um aplicativo Java EE cujos serviços podem ser acessados usando Enterprise Java Beans (EJBs), serviços da Web e interfaces do usuário baseadas na Web.


Acessando o Enterprise Java Beans

A finalidade principal do MDM Server é como aplicativo descentralizado (em outras palavras, um sem interface do usuário principal) que é integrado a uma linha de aplicativos de negócio da organização envolvendo clientes, produtos e contratos. Esses aplicativos integram o MDM Server a seus processos usando a API do MDM Server. A API encontra-se na forma de várias centenas de serviços, todos acessados através de um único bean de sessão stateless do MDM Server. O EJB através do qual todos os serviços do MDM Server são acessados é chamado de DWLServiceControllerEJB.

Vamos construir um cluster hipotético no qual o MDM Server está instalado e sendo executado, como ilustrado na Figura 3:

Figura 3. Componentes MDM instalados em um cluster hipotético
Diagram of MDM components installed on a hypothetical cluster, similar to cluster illustrated in Figure 1, but with computers, nodes, and members named

O cluster é chamado de c1. Há três computadores participando do cluster, chamados Computer1, Computer2 e Computer3. Cada computador possui um perfil AppSrvr sendo executado nele que corresponde a um nó WAS ND. Esses nós são chamados de Computer1Node01, Computer2Node01 e Computer3Node01. Ao criar um nó, o WAS ND, por padrão, usa a convenção de nomenclatura, de forma que o nome do nó é uma concatenação do nome DNS dos computadores com "Node" e um número sequencial, dependendo do número de nós já instalados nesse computador. Também há o nó gerenciador de célula, que é usado pelo WAS ND para gerenciar o conjunto de computadores na célula. (Este artigo não entra em detalhes sobre o que é uma célula. Vamos dizer apenas que um cluster é parte de uma célula de computadores físicos. Se quiser saber mais, a documentação do WAS ND fornece informações vastas sobre as topologias do WAS ND.) Cada nó contém dois membros do cluster. Esses são os componentes do WAS ND que realmente fazem o trabalho. Como você já viu, eles são os contêineres do aplicativo Java EE. Os membros são chamados de member1 e member2 para cada nó, respectivamente. O endereço da porta de inicialização de cada contêiner do aplicativo é o número no canto direito inferior de cada caixa de membro do cluster. É a porta que os programas usam para obter a interface inicial do EJB do MDM Server.

Agora, a questão é: onde se obtém o EJB para usar? Afinal, o EJB está implementado e sendo executado em três computadores separados e em seis contêineres de aplicativo separados. O fragmento de código na Listagem 1 ilustra como é possível acessar a interface inicial do EJB DWLServiceController em um cluster composto de três computadores, cada um executando dois servidores de aplicativo (membros do cluster):

Listagem 1. Obtendo o Contexto Inicial do MDM Server Service Controller Bean
public DWLServiceControllerHome createDWLServiceController() { String JNDIName =
"cell/clusters/c1/com/dwl/base/requestHandler/beans/DWLServiceController";
DWLServiceControllerHome controllerHome = null; Hashtable<String,
String> env = new Hashtable<String, String>>();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory"); env.put(Context.PROVIDER_URL,
"corbaloc:iiop:computer1:2811,:2812," + ":computer2:2811, :computer2:2812, +
:computer3:2811, :computer3:2812);  try { InitialContext initCtx = new
InitialContext(env); Object obj = initCtx.lookup(JNDIName); Class theClass =
DWLServiceControllerHome.class; controllerHome = (DWLServiceControllerHome)
PortableRemoteObject .narrow(obj, theClass); return controllerHome; } catch
(NamingException e) { e.printStackTrace(); return null; } catch (Exception e) {
e.printStackTrace(); return null; } }

Há duas partes do fragmento que são de maior interesse. Primeira:

String ControllerJNDIName =
"cell/clusters/c1/com/dwl/base/requestHandler/beans/DWLServiceController";

O nome JNDI básico para DWLServiceController is com/dwl/base/requestHandler/beans/DWLServiceController. Quando se está trabalhando com um cluster, ele é pré-fixado como cell/clusters/clustername. Você ainda pode usar o nome JNDI básico se for acessar o EJB diretamente de um único membro do cluster, como member1 em Computer2Node01. Por exemplo, o código na Listagem 2 fará apenas isto:

Listagem 2. Acessando o EJB diretamente de um único membro do cluster
 ... String
ControllerJNDIName = com/dwl/base/requestHandler/beans/DWLServiceController";
DWLServiceControllerHome controllerHome = null; Hashtable<String,
String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory"); env.put(Context.PROVIDER_URL,
"corbaloc:iiop:computer2.ottawa.ibm.com:2811); ...

Mas o que acontece se member1 em Computer2Node01 não estiver funcionando por algum motivo? Seu programa não será capaz de obter a interface inicial do bean, e lá se vai sua alta disponibilidade. Isso nos leva à segunda parte interessante do código da Listagem 1:

 env.put(Context.PROVIDER_URL,
"corbaloc:iiop:computer1.ottawa.ibm.com:2811,:2812," +
":computer2.ottawa.ibm.com:2811,:2812, +
:computer3.ottawa.ibm.com:2811,:2812);

Para usar um EJB que está sendo executado remotamente em outro computador, você precisa da URI do computador e do número da porta de inicialização através dos quais o servidor do aplicativo possa retornar a interfaces dos EJBs. Nesse caso, o código especificou realmente todos os membros do cluster c1 onde o EJB está residindo. A infraestrutura subjacente pegará um da lista e o usará. Se não puder se conectar, ela irá para o segundo da lista, e assim por diante. É claro que se ela não puder se conectar a nenhum da lista, todo o sistema está inativo.

Quando tiver a interface inicial do EJB, você pode usar o método de criação de EJB para obter o EJB real e continuar com suas operações. Todo o resto é manipulado pelo WAS ND. Você pode pensar que se obteve Interface Inicial de um membro específico do cluster, então é para onde todas as suas demais solicitações de serviço serão direcionadas. Mas, esse não é o caso. O WAS ND na verdade irá distribuir suas solicitações para TODOS os membros do cluster, dependendo de quanto peso você atribuiu a cada membro do cluster. Quanto mais alto o peso atribuído a um membro do cluster, maior a proporção de requisições direcionadas a esse membro. Mas, como mencionado anteriormente, tudo isso é manipulado pelo WAS ND, e não há muito com o que você precise se preocupar.


Acessando os serviços da Web e os aplicativos da Web

Acessar os serviços da Web e os aplicativos da Web fornecidos pelo MDM Server em um cluster do WAS ND requer uma abordagem diferente. Vamos dar outra olhada no cluster hipotético (consulte a Figura 4). Você perceberá que os números no canto inferior direito de cada membro do cluster mudaram para 9081 e 9082. Esses números representam os números de porta dos hosts padrão de conteúdo da Web (WC_defaulthost), que servem conteúdo da Web para cada servidor. Quando você cria membros do cluster adicionais em qualquer computador, o WAS ND atribui números de porta ao WC_defaulthost (e WC_defaulthost_secure se você está se comunicando usando SSL), começando em 9080 (e 9040) e aumentando sequencialmente. No cluster hipotético, o WAS ND atribuiu os números de porta 9081 e 9082 (9080 foi usado em outro lugar).

No cluster hipotético mostrado na Figura 4, para acessar o MDM Data Stewardship UI, você precisa inserir um URL, como o seguinte, em seu navegador:

  • http://computer1:9081/CustomerDataStewardshipWeb/, se quiser acessar o Data Stewardship UI do member1 no Computer1
  • http://computer1:9082/CustomerDataStewardshipWeb/, se quiser acessar o Data Stewardship UI do member2 no Computer1
  • http://computer2:9081/CustomerDataStewardshipWeb/, se quiser acessar o Data Stewardship UI do member1 no Computer2, e assim por diante

Mas assim que tiver qualquer um desses URLs, seu navegador estará ligado ao computador e servidor de aplicativo que o URL representa. Se esse servidor falhar por algum motivo, você perderá sua sessão e precisará re-estabelecer uma sessão com outro computador no cluster.

Figura 4. Acessando componentes da Web do MDM Server
Diagram illustrating accessing MDM Server Web components using cluster similar to previous diagrams, but with a URL allowing from the client workstation to one of the computers

O mesmo é válido para acessar os serviços da Web do MDM Server, já que os serviços da Web e a UI da Web usam os mesmos protocolos. Por exemplo, ao acessar o Party Web Service, seu código deve parecer algo como:

Listagem 3. Acessando o Party Web Service
com.ibm.www.xmlns.prod.websphere.wcc.party.service.PartyService ps = new
com.ibm.www.xmlns.prod.websphere.wcc.party.service.PartyServiceLocator();
PartyService thePartyService = ps.getPartyPort( new
java.net.URL("http://computer1:9081/PartyWS_HTTPRouter/services/PartyPort"));

No entanto, seu programa estará ligado ao member1 executado no Computer1. Se ele parar de funcionar, o mesmo acontecerá com o programa. Seu programa terá que estabelecer explicitamente uma conexão com outro membro do cluster.

IBM HTTP Server para o resgate

Você pode usar o IBM HTTP Server (IHS) ou qualquer outro servidor da Web com um plug-in WAS suportado. Este artigo foca o IHS. Consulte a documentação WAS para certificar-se de que há um plug-in para o seu servidor da Web. Você pode configurar o IHS para direcionar requisições ao WAS ND e para distribuir a carga para todos os membros do cluster do WAS.

Você precisa instalar o IHS e o plug-in WAS correspondente. Você também precisa copiar alguns arquivos para o diretório bin gerenciador de implementação do WAS ND. Siga as instruções que acompanham os programas de instalação do IBM HTTP Server e o plug-in WAS para servidor HTTP. Elas são detalhadas e completas. Depois de ter instalado o IHS e o plug-in WAS para IHS, você também pode configurar o WAS para que você possa iniciar e interromper o servidor HTTP usando o WAS Admin Console. Para fazer isso, clique nos itens do menu do servidor da Web do servidor no console e depois clique no botão New no topo da lista. A partir daí, siga as instruções do assistente.

Assim que o servidor HTTP estiver instalado e em execução, e o plug-in tiver sido instalado e configurado, você será capaz de acessar todos os recursos da Web do MDM Server (servidores da WEB e UI baseada na WEB) através do servidor HTTP. Agora o seu cluster deve se parecer com o da Figura 5:

Figura 5. Accessando componentes da Web do MDM Server usando o IBM HTTP Server
Diagram illustarting accessing MDM Server Web components using IBM HTTP Server

Em vez de acessar os serviços da Web do MDM Server diretamente dos membros do cluster, você pode apontar para o servidor HTTP, como segue:

Listagem 4. Apontando para o servidor HTTP
com.ibm.www.xmlns.prod.websphere.wcc.party.service.PartyService ps = new
com.ibm.www.xmlns.prod.websphere.wcc.party.service.PartyServiceLocator();
PartyService thePartyService = ps.getPartyPort( new
java.net.URL("http://computer4/PartyWS_HTTPRouter/services/PartyPort"));

Nesse caso, a porta padrão (porta 80) é omitida pelo URL. O servidor HTTP receberá a solicitação e reconhecerá /PartyWS_HTTPRouter/services/PartyPort como sendo um serviço da Web fornecido no WAS. Ele então direcionará a solicitação para um dos membros do cluster.

De modo semelhante, você pode acessar os componentes de UI da Web do MDM Server usando o servidor HTTP, inserindo o URL do servidor HTTP seguido do nome do aplicativo da Web, como segue:

  • http://computer4/CustomerDataStewardshipWeb/ para o MDM Server Data Stewardship UI
  • http://computer4/CustomerBusinessAdminWeb/ para o MDM Server Administration UI

O IHS direciona as solicitações para cada um dos membros do cluster para garantir que a carga seja balanceada uniformemente. Se um dos membros do cluster para de funcionar, o IHS rebalanceia automaticamente a carga nos membros do cluster restantes.

Como o servidor HTTP sabe para quais computadores ele pode direcionar as solicitações? E como ele reconhece quais solicitações ele deve direcionar e a quais ele deve prestar serviços sozinho (em outras palavras, páginas normais da Web)? A resposta está em um arquivo de configuração de plug-in chamado, como você já deve imaginar, plugin-cfg.xml. O arquivo é criado quando o plug-in é instalado e configurado. Se você configurou seu WAS Console para acessar o servidor da Web, você pode visualizar os conteúdos do arquivo de dentro do console. Clique no item de menu Servers > Web Servers e depois clique no Servidor da Web que você configurou. Em seguida, clique no link Plug-in Properties. No painel resultante, clique no botão View próximo à caixa de texto contendo o plugin-cfg.xml para visualizar o conteúdo do arquivo.

Ele parece como se houvesse um link inadequado na cadeia HA. O que acontece se o IHS passar por um problema e parar de operar? Você volta para onde começou. Para garantir que você mantenha HA, é possível adicionar vários computadores executando o IHS em um cluster. Este artigo não entrará em detalhes aqui já que, novamente, os clusters dos servidores da Web são um fenômeno comum e há muita literatura descrevendo como fazer isso. A Figura 6 descreve como o cluster hipotético deve parecer agora:

Figura 6. Acessando componentes da Web do MDM Server usando o IBM HTTP Server em um cluster
Diagram illustrating accessing MDM Server Web components using IBM HTTP Server in a cluster, similar to Figure 5, but with more than one HTTP server

Construindo aplicativos tolerantes a falhas que acessam serviços MDM

Enterprise Java Beans

Sempre que um membro do cluster passa por uma falha e para de operar, o WAS ND redireciona automaticamente todas as solicitações subsequentes para os membros restantes do cluster. Todos os membros de um cluster enviam pulsações a outros membros que indicam que eles estão operacionais. Se um membro do cluster ficar fora de operação e parar de enviar suas pulsações, pode levar alguns segundos até que o WAS ND detecte a falta de pulsações. Se o seu programa enviou uma solicitação de serviço que foi direcionada pelo WAS ND para um membro do cluster com falha, provavelmente você receberá de volta uma exceção. Normalmente a exceção é um MarshalException, contendo em sua mensagem algo como:

java.rmi.MarshalException: CORBA COMM_FAILURE 0x4942f306 Maybe; nested exception is: org.omg.CORBA.COMM_FAILURE: purge_calls:1866 Reason: CONN_ABORT (1), State: ABORT (5) vmcid: IBM minor code: 306 completed: Maybe

Se o seu programa está fazendo uma solicitação de serviço ao MDM Server e recebe essa exceção, simplesmente aguarde alguns segundos e tente novamente. Se a causa da exceção foi a falha de um membro do cluster, a segunda ou a terceira tentativa deve ser bem-sucedida, já que o WAS ND redireciona as solicitações RMI para os membros restantes do cluster. O seguinte fragmento de código fornece uma ilustração simples:

Listagem 5. Chamando o MDM usando RMI
 public Serializable callMDMInThread2() { try
{ DWLServiceController thisDWLServiceController; DWLServiceControllerHome
controllerHome = null; Hashtable<String, String> env = new
Hashtable<String, String>>();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory"); env.put(Context.PROVIDER_URL,
"corbaloc:iiop" + ":computer1:2811,:2812," + ":computer2:2811,:2812," +
":computer3:2811,:2812"); InitialContext initCtx = new InitialContext(env); Object
obj = initCtx.lookup(JNDIName); Class theClass = DWLServiceControllerHome.class;
controllerHome = (DWLServiceControllerHome) PortableRemoteObject .narrow(obj,
theClass); int maxTries = 3; int numTries = 1; Serializable theResponse; while
(numTries <= maxTries) { try { thisDWLServiceController =
controllerHome.create(); theResponse = thisDWLServiceController.processRequest(
myHashMap, theRequest); return theResponse; } catch (DWLResponseException DWLe) {
//This could be a business error identified by MDMServer. return DWLe; } catch
(java.rmi.MarshalException e) { Thread.sleep(300); numTries++; if (numTries ==
maxTries) throw e } catch (Exception e) { // Something else is wrong return e; } } }
catch (Exception e) { // error trying to get the initial context in the first place.
// Something could be wrong not related to HA } }

Serviços da Web

A mesma abordagem se aplica a serviços da Web do MDM Server. Em vez de receber um MarshalException, no entanto, seu programa provavelmente receberá um WebServicesFault. No entanto, o mesmo tipo de algoritmo se aplica, como ilustrado na Listagem 5. Seu código pode fazer algo semelhante ao código na Listagem 6:

Listagem 6. Chamando o MDM usando serviços da Web
 public
PersonSearchResultsResponse searchPerson() throws javax.xml.rpc.ServiceException,
java.net.MalformedURLException, com.ibm.ws.webservices.engine.WebServicesFault,
com.ibm.www.xmlns.prod.websphere.wcc.common.intf.schema.ProcessingException,
java.rmi.RemoteException { int numTries = 1; int maxTries = 3; boolean gotTheService
= false; com.ibm.www.xmlns.prod.websphere.wcc.party.service.PartyService
partyServiceLocator = new
com.ibm.www.xmlns.prod.websphere.wcc.party.service.PartyServiceLocator();
PartyService thePartyService = null; while (!gotTheService) { try { thePartyService
= partyServiceLocator.getPartyPort(new
java.net.URL("http://computer4/PartyWS_HTTPRouter/services/PartyPort"));
gotTheService = true; } catch (javax.xml.rpc.ServiceException serviceException) {
numTries++; if (numTries > maxTries) throw serviceException; } catch
(java.net.MalformedURLException malformedURLException) { throw
malformedURLException; } } //if you made it to this point you've successfully
//retrieved the Web Service from the remote computer. PersonSearch ps = new
PersonSearch(); ps.setGivenNameOne("Fred"); ps.setLastName("Flintstone"); numTries =
1; PersonSearchResultsResponse response = null Control control = new Control();
control.setRequesterName("user1"); control.setRequesterLanguage(100);
control.setRequesterLocale("us-en"); control.setRequestId(1234567); String[] roles =
{"Superuser","normal"}; control.setRequesterRole(roles);
control.setReturnAvailableResultCount(true); while (numtries < = maxtries){
try { response = thePartyService.searchPerson(control, ps); return response; } catch
(WebServicesFault e) { numTries++; if (numTries > maxTries) throw e; } catch
(ProcessingException e) { throw e; } catch (java.rmi.RemoteException e) { throw e; }
} }

Esse código faz três tentativas para obter o serviço da Web. Se não puder obter o serviço, ele relança a exceção que recebeu durante sua tentativa de obter o serviço. Depois que tiver obtido o serviço com sucesso, ele faz três tentativas de executar o serviço PersonSearch. Depois que a terceira tentativa falhar, ele simplesmente irá relançar a falha de serviços da Web que recebeu. Quaisquer outras exceções são lançadas imediatamente.

É possível construir tolerância a falhas nos aplicativos clientes que construir que interagem com o MDM Server. Esta seção mostrou como gravar um programa que pega as prováveis exceções que ocorrerão se o próprio WAS ND passou por uma falha e está recebendo suas próprias correções de falha. Pegar essas exceções e tentar novamente aumentará a probabilidade de que suas próprias transações tenham êxito.


Outros componente do MDM Server

Apesar de o MDM Server ser antes de mais nada um aplicativo Java EE executado em um servidor de aplicativo, ele possui alguns componentes adicionais que não são aplicativos Java EE. Eles próprios são aplicativos clientes que implementam os serviços de componentes Java EE do MDM Server. Eles incluem:

Vamos dar uma olhada no papel que estes três componentes podem desempenhar em um ambiente de alta disponibilidade.

Cliente do repositório de configuração

O cliente do repositório de configuração é um aplicativo de tecnologia Java executado em um computador e é usado para manter a configuração do MDM Server. A configuração é o conjunto de configurações e seus valores armazenados em uma tabela. O MDM Server usa essas configurações para modificar seu comportamento, dependendo do que os clientes precisam. Por exemplo, há um item de configuração que especifica o número de itens de resultado que serão retornados de um serviço de procura.

Esses itens de configuração, por serem lidos continuamente, são armazenados em cache na memória do MDM Server. Assim, uma atenção especial é necessária quando há diversas instâncias de MDM Server sendo executadas em um cluster. O cache de cada instância deve ser atualizado sempre que um item de configuração é modificado. Considerando que o cliente do repositório de configuração normalmente é instalado em um computador, ele precisa garantir que os caches sejam todos atualizados simultaneamente em todos os computadores em um cluster.

O cliente do repositório de configuração foi planejado para fazer isso usando JMX. Este artigo não entra em detalhes sobre como ele faz isso; tudo está muito bem documentado na documentação oficial do MDM Server. A Figura 7 foi tirada da documentação on-line do MDM Server para ilustrar como os componentes de configuração e gerenciamento podem aparecer em um cluster do WAS ND.

Figura 7. Arquitetura do repositório de configuração do MDM
Diagram of MDM configuration repository architecture

Processador em lote

O processador em lote do MDM Server é um aplicativo de tecnologia Java que realiza operações em lote usando serviços do MDM Server. Os detalhes do aplicativo processador em lote podem ser encontrados na documentação do MDM Server. Esta seção descreve como ele pode operar em um cluster do WAS ND.

O processador em lote por ser instalado junto com o MDM Server, ou pode ser instalado separadamente. Ele pode ser instalado em quantos computadores for preciso. Apesar de ele não ser em cluster como os componentes Java EE do MDM Server, você pode obter um grau de HA instalando-o em vários computadores. Cada instalação operará independentemente de quaisquer outras.

Como o processador em lote é um aplicativo cliente Java EE, é possível configurá-lo para tirar proveito do fato de que o MDM Server é em cluster, e, com isso, é possível aumentar a própria tolerância a falhas do processador em lote ao não ligá-lo a nenhum servidor de aplicativo quando ele estiver tentando obter um EJB. O código a seguir na Listagem 7 foi tirado do arquivo de configuração Batch.properties do processador em lote.

Listagem 7. Arquivo de propriedades do Processador em Lote do MDM Server
#--------------------------------------------------------- # Server setting #
timeout is in seconds, 0 is infinite, default is 5 minutes
#---------------------------------------------------------
ServerConfiguration.provider_url=corbaloc:iiop:computer1:2811,
iiop:computer1:2812,iiop:computer2:2811, iiop:computer2:2812
ServerConfiguration.jndi_prefix = cell/clusters/c1 ServerConfiguration.timeout = 0
ServerConfiguration.context_factory =
com.ibm.websphere.naming.WsnInitialContextFactory

O fragmento acima especifica, como os exemplos de código anteriores, todos os membros de um cluster na propriedade provider_url. Ele contém uma lista separada por vírgulas, que consiste no URL do computador e endereço da porta de inicialização na forma de iiop:<computer url>:<port>. Assim, se algum membro não estiver disponível, a implementação subjacente do RMI do WebSphere pode tentar o próximo membro da lista.

Cliente gerenciador de eventos

O cliente gerenciador de eventos, como o processador em lote, é um aplicativo de tecnologia Java que pode ser instalado separadamente do MDM Server e é um cliente do MDM Server. Como o processador em lote, ele também usa um arquivo de configuração para que possa acessar os EJBs do MDM Server. Assim como com o processador em lote, você também pode especificar todos os lugares onde o Cliente Gerenciador de Eventos pode acessar os EJBs do MDM Server. A Listagem 8 fornece um fragmento do arquivo EventManagerClient.properties, onde todas as configurações são armazenadas:

Listagem 8. Arquivo de propriedades do Cliente Gerenciador de Eventos do MDM Server
 ##########################################################
{COPYRIGHT-END} ##### # The following property is the URL used by EventManagerClient
# to look up the ProcessControllerInternal session bean # For WebSphere, for
example, corbaloc:iiop:localhost:2809 # For WebLogic, for example,
t3://localhost:7001 #
ProcessControllerInternal.PROVIDER_URL=corbaloc:iiop:computer1:2811,
iiop:computer1:2812, iiop:computer2:2811,iiop:computer2:2812,
iiop:computer3:2811,iiop:computer3:2812 # The following property is the CONTEXT used
by EventManagerClient # to look up the ProcessControllerInternal session bean # For
WebSphere, for example, com.ibm.websphere.naming.WsnInitialContextFactory # For
WebLogic, for example, weblogic.jndi.WLInitialContextFactory #
ProcessControllerInternal.CONTEXT=com.ibm.websphere.naming.WsnInitialContextFactory
# The following property is the ProcessControllerInternal session bean JNDI name #
#ProcessControllerInternal.JNDINAME=ProcessControllerInternal
ProcessControllerInternal.JNDINAME=cell/clusters/c1/ProcessControllerInternal

Especificando todos os membros do cluster na propriedade PROVIDER_URL, você evita limitar o cliente gerenciador de eventos a qualquer membro do cluster se ele estiver tentando obter um EJB. Consequentemente, você aumenta a própria tolerância a falhas do gerenciador de eventos e, portanto, sua disponibilidade.


Resumo

Este artigo mostrou como você pode obter alta disponibilidade para o MDM Server instalando-o em um cluster do WAS ND. Ele também mostrou como, quando você grava os programas que usam serviços do MDM Server, você pode gravá-los de uma forma que eles também tenham um alto grau de tolerância a falhas. E, como discutido, tolerância a falhas e alta disponibilidade caminham lado a lado. Finalmente, este artigo discutiu como é possível configurar os componentes do MDM Server que são eles próprios clientes para os serviços do MDM Server, para que eles também possam obter tolerância a falhas e alta disponibilidade aumentadas.

Recursos

Aprender

Obter produtos e tecnologias

  • Elabore seu próximo projeto de desenvolvimento com o software de teste IBM, disponível para download diretamente no developerWorks.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java, Information Management, WebSphere
ArticleID=477282
ArticleTitle=Obtenha alta disponibilidade com o InfoSphere Master Data Management Server e o WebSphere Application Server
publish-date=03232010