O Servidor de Aplicações Borland AppServer 4.5

Para tentar diminuir as dificuldades do desenvolvimento, da implantação, e da gerência de aplicações distribuídas para a plataforma Web, a Borland Software Corporation desenvolveu o Borland AppServer, um servidor de aplicações que, além de implementar os serviços da plataforma J2EE, oferece ferramentas visuais para auxiliar tanto o desenvolvedor quanto o administrador do sistema [Borland 01-3]. Por usar o protocolo IIOP para comunicação entre objetos remotos, é possível que aplicações clientes escritas em outras linguagens além do Java acessem os componentes instalados nesse servidor.

Apesar de oferecer um servidor Web integrado, este servidor de aplicações não oferece nenhum tipo de mecanismo para garantir a utilização contínua e correta do sistema para os usuários que o acessam através de um navegador Web [Borland 01-1]. Como muitas aplicações Web utilizam a sessão do servlet, o fato de não haver suporte para que esta possa ser preservada caso o servidor apresente uma falha pode causar a indisponibilidade do sistema.

Já para preservar as informações do serviço JNDI, o Borland AppServer permite que seja usado um meio persistente como um banco de dados. Essa solução consiste em executar até duas instâncias do serviço de nomes JNDI em máquinas diferentes especificando que todas estarão compartilhando o mesmo banco de dados [Borland 01-2]. Dessa forma, caso uma instância do serviço de nomes torne-se indisponível, a outra continuará atendendo aos clientes uma vez que as instâncias sempre obtêm as informações do banco de dados. Entretanto, a disponibilidade do sistema como um todo irá depender do servidor de banco de

dados. Caso ocorra uma falha neste serviço, as instâncias do JNDI não poderão recuperar os registros previamente armazenados. Além disso, como o grau de replicação do serviço JNDI é fixo em um [Deshpande 00], essa solução suporta que apenas uma instância falhe.

O Borland AppServer foi criado com um conjunto de módulos independentes que implementam os serviços requeridos pela plataforma J2EE [Borland 01-4]. Isso permite que cada instância que faça parte do grupo de replicação possa ser customizada para responder apenas a um ou por alguns serviços. Os principais módulos são [Borland 01-4]:

• Contêiner Web – responsável pela execução dos servlets;

• Serviços CORBA – serviços utilizados para realizar a comunicação entre os objetos remotos e entre estes e as aplicações clientes;

• Serviço JNDI – implementação da especificação JNDI da SUN;

• Contêiner EJB – responsável por executar e gerenciar os componentes EJB; • Gerenciador de transações – implementação das especificações JTS e JTA da

SUN; e

• Serviço de armazenamento de sessão – banco de dados interno utilizado para armazenar estados dos componentes.

Dos serviços acima, os únicos que não permitem replicação são o contêiner Web e o serviço de armazenamento de sessão. Assim, além de ser possível executar mais de uma instância do serviço JNDI, pode-se ter várias instâncias de contêineres EJB, cada uma possuindo um conjunto diferente de componentes [Borland 01-2].

Como o Borland AppServer permite que várias instâncias do servidor em um grupo de replicação hospedem um contêiner EJB, é possível replicar todos os tipos de componentes EJB. Uma vez que cada tipo de componente possui características e comportamentos próprios, o procedimento empregado por este servidor de aplicações no momento da falha de uma instância vai variar conforme o tipo de componente [Borland 01-2]. Se um determinado

session bean stateless for instalado em mais de um contêiner EJB de um grupo de replicação,

o protocolo de comunicação será responsável por direcionar as requisições das aplicações clientes para uma instância livre de falhas de forma transparente para o cliente [Deshpande 00]. Uma vez que esse tipo de componente não possui estado, uma réplica é escolhida aleatoriamente para responder a uma requisição. Entretanto, se a falha ocorrer durante o

processamento do método do componente, a aplicação cliente que invocou o método irá perceber a falha e ela deverá ser responsável por refazer a requisição de forma explícita [Borland 01-2].

Da mesma forma que o stateless, os componentes EJB stateful também são replicados de forma automática no instante em que são instalados nas instâncias do contêiner EJB do grupo de replicação [Borland 01-1]. Além disso, o comportamento do protocolo de comunicação no momento em que ocorre uma falha em uma instância é semelhante ao que ocorre no stateless: a cada requisição efetuada, o protocolo de comunicação confere se a instância do componente que estava sendo usada continua operacional e, caso não esteja, uma réplica desse componente é localizada para responder pela requisição. Se a falha ocorrer durante o processamento do método, a aplicação que o invocou deverá tratar a exceção e invocar novamente o método [Deshpande 00]. Neste servidor de aplicações, em vez do estado do EJB ser mantido na instância do componente, ele é preservado no serviço de armazenamento de sessão. Assim, no momento que uma réplica é escolhida pra substituir uma instância falha, ela é inicializada com o último estado salvo do componente que falhou [Borland 01-2]. Entretanto, é possível que a réplica seja inicializada com um estado que não reflete a última modificação feita por um cliente. Como o estado das instâncias é passado para o serviço de armazenamento de sessão periodicamente [Borland 01-4], pode acontecer que uma falha ocorra depois que o estado foi modificado e antes dele ser salvo. Além disso, como não é possível replicar o serviço de armazenamento de sessão, todos os estados dos componentes serão perdidos caso ocorra uma falha na instância do servidor que hospeda esse serviço.

O Borland AppServer também permite que entity beans do mesmo tipo instalados em instâncias do contêiner EJB do mesmo grupo de replicação atuem como réplicas uns dos outros [Borland 01-1]. Como nos outros casos, o protocolo de comunicação será responsável por enviar a requisição para um servidor livre de falhas. Uma vez que o contêiner EJB faz com que a instância do entity bean leia o seu estado da tabela o qual ele representa antes de cada transação ser iniciada e requer que esse componente salve as alterações antes da transação ser finalizada [Borland 01-4], há a garantia de que sempre haverá um estado consistente do componente a ser usado. Porém, caso a falha ocorra durante o processamento da transação, não é possível continuar a transação em uma réplica de um outro contêiner EJB.

Uma vez que a transação é desfeita quando uma falha ocorre, fica sob responsabilidade da aplicação cliente reiniciar toda a transação.