WebSphere Virtual Enterprise, Version 6.1.1
             Sistemas Operacionais: AIX,, HP-UX, Linux, Solaris, Windows


Conceitos sobre o Gerenciador de Edição de Aplicativo

Conhecendo a diferença entre as versões e as edições do gerenciador de edição do aplicativo, os métodos de implementação e de upgrade do aplicativo, e a validação e compatibilidade da edição, você pode utilizar inteiramente o gerenciador de edição do aplicativo para gerenciar as implementações do aplicativo.

Os aplicativos da Web não gerenciados podem ser definidos com uma edição. No entanto, uma implementação não pode ser executada neles, nem eles podem ser colocados no modo de validação. Eles são suportados, exceto que nem toda a capacidade está disponível para eles em razão de sua natureza como aplicativos de gerenciamento de ciclo de vida assistido.

Versões e Edições

Os termos versão e edição são distintos entre o que ocorre no ambiente de construção e desenvolvimento e o que ocorre no ambiente operacional e de implementação. Uma versão é uma geração sucessiva de uma interface, função, implementação ou do aplicativo inteiro, e assim por diante. Versão é um conceito de desenvolvimento e de construção.

Uma edição é uma geração de implementação sucessiva, por exemplo, a implementação de um conjunto específico de artefatos com versão. Edição é um conceito de implementação e operacional.

Edição de aplicativo

Uma edição de aplicativo é uma implementação exclusiva de um aplicativo específico. No ambiente administrativo do WebSphere Application Server, uma edição de aplicativo é um aplicativo que é identificado exclusivamente pela combinação de um nome do aplicativo e um nome da edição. Várias edições do mesmo aplicativo possuem o mesmo nome de aplicativo, mas nomes de edições diferentes. O nome da edição pode ser numérico, como 1.0 ou 2.0, ou o nome pode ser descritivo, como first edition ou blue edition.

Edição de Base

Edição Básica refere-se a um aplicativo implementado que não tenha informações de edição associadas. Por exemplo, os aplicativos que são instalados antes do suporte do gerenciador de edição de aplicativo ser incluído na célula do produto, são exibidos no gerenciador de edição de aplicativo como edições de base.

Ativação da edição

Ativação de Edição distingue entre dois estados nos quais pode existir uma edição de aplicativo. Quando uma edição é instalada pela primeira vez, essa edição está no estado inativo. É possível iniciar a edição apenas quando ela estiver no estado ativo. A transição de inativa para ativa é conhecida como ativação.

Ativação Simultânea

A Ativação simultânea existe quando várias edições do mesmo aplicativo estão ativas e são iniciadas simultaneamente. As edições ativas simultaneamente podem fornecer a alguns usuários acesso a uma edição e a outros usuários acesso a outra. Por exemplo, se você introduzir uma nova edição de um aplicativo, poderá desejar selecionar um grupo de usuários para testar a edição, e não desejar que todos os usuários tenham acesso à edição. Com a ativação simultânea, você deve estabelecer uma política de roteamento para distinguir quais usuários têm acesso a uma edição. Uma política de roteamento é armazenada como parte dos metadados de configuração para um aplicativo. Além disso, uma política de roteamento evita a ambiguidade e determina qual edição recebe controle. O exemplo a seguir é um diagrama de edições ativas simultaneamente.

Figura 1. Edições Ativas Simultaneamente A Figura 1 mostra múltiplas edições do mesmo aplicativo simultaneamente ativadas

Upgrade e Implementação do Aplicativo

Muitos aplicativos de negócios requerem disponibilidade constante. O padrão para disponibilidade de aplicativos assegura que os aplicativos sejam implementados em clusters do servidor de aplicativos. A redundância de um cluster é essencial para fornecer disponibilidade contínua. O upgrade de aplicativo sem interrupção refere-se à capacidade de fazer upgrade enquanto mantém a disponibilidade contínua do aplicativo. Os usuários do aplicativo não têm perda de serviço durante o upgrade do aplicativo.

Implementação da edição

Ao executar uma implementação em uma edição, a edição ativa é substituída por uma nova edição. Para fornecer upgrades do aplicativo sem interrupção, a execução de uma implementação em uma edição inclui os seguintes itens:
  • Protegendo esse servidor de receber novos pedidos.
  • Suspendendo pedidos para o aplicativo em um servidor específico.
  • Parando a edição ativa atualmente.
  • Iniciando a nova edição.
  • Continuando o fluxo de pedidos para a edição.
Quando você executa uma transferência uma edição através de um cluster de servidor de aplicativos, você completa as seguintes atividades através do conjunto dos servidores que estão naquele cluster:

Transferência em grupo

Para executar uma implementação em um cluster de destino, você pode dividir o cluster em grupos e definir um tamanho do grupo, o que especifica o número de nós a serem processados de cada vez. A execução de uma implementação em um grupo resulta no upgrade dos servidores em cada grupo para uma nova edição ao mesmo tempo. Cada servidor no grupo está inativo, parado e reconfigurado. Uma implementação pode ser executada em apenas um grupo de cada vez com o console administrativo. Quando qualquer membro na nova edição se torna disponível, todos os pedidos são roteados para a nova edição.

Conforme uma implementação é executada em uma edição, alguns servidores no cluster se movem da edição anterior para a nova edição, alguns servidores estão fazendo a transição e outros servidores não a iniciaram. Todos os pedidos de aplicativos são enviados a todo servidor que tem uma instância ativa e em execução da edição mais recente do aplicativo solicitado. Por exemplo, quando você executa uma transferência da edição 1.0 para 2.0, todos os pedidos do aplicativo serão servidas pela edição 2.0 quando a 2.0 se tornar disponível em um servidor. Todos os servidores que ainda estiverem executando a edição 1.0 não servem pedidos até que este servidor seja atualizado para a edição 2.0. O exemplo a seguir é um diagrama de uma transferência em grupo.

Figura 2. Transferência em Grupo
A Figura 2 mostra um cluster de destino sendo dividido em grupos conforme uma transferência é executada

Transferência Atômica

A execução de uma transferência atômica em uma edição substitui uma edição na metade do cluster de cada vez para servir a todos os pedidos do usuário com uma edição consistente do aplicativo. Todos os pedidos do usuário são servidos pela edição anterior ou nova. Os pedidos do usuário nunca são servidos pelas duas edições.

Uma transferência atômica assegura que todos os pedidos do aplicativo são servidos por uma edição consistente, por exemplo, edição 1.0 ou 2.0, mas não ambas. A edição disponível atualmente é mantida off-line na metade dos servidores que compõem o cluster. Nestes servidores, a nova edição é ativada e iniciada, mas esses servidores são mantidos off-line até a conclusão da próxima etapa. A próxima etapa é tornar off-line a edição ativa no momento nos servidores restantes. Neste ponto, nenhum servidor tem uma instância de nenhuma edição disponível para atender pedidos de aplicativos. O ODR enfileira temporariamente qualquer pedido que chega para esse aplicativo. Quando o aplicativo estiver totalmente off-line, a primeira metade do cluster se tornará on-line novamente. A segunda metade do cluster faz a transição da edição anterior para a próxima edição e se torna on-line novamente. O exemplo a seguir é um diagrama de uma transferência atômica:

Figura 3. Transferência Atômica
A Figura 3 ilustra como a primeira metade do cluster de destino se torna on-line novamente depois de o aplicativo ficar completamente off-line, e a segunda metade das transações de cluster da edição anterior para a próxima edição se tornam on-line novamente.

Validação e Compatibilidade da Edição

Validação da Edição

A Validação da edição refere-se a um caso especial de ativação simultânea em que um destino de implementação designada da edição, por exemplo, um cluster dinâmico, é clonado e a edição é preparada para ser iniciada no destino de implementação clonado. O destino de implementação clonado é conhecido como um destino de validação. As regras de roteamento devem ser utilizadas para designar quais pedidos de aplicativos serão enviados para a edição que está passando por validação. Quando uma edição está em validação, é está no modo de validação.

O modo de validação assegura que uma nova edição de um aplicativo funcione em seu ambiente de produção sem tornar off-line a edição disponível no momento. Geralmente, um carregamento de teste é enviado para uma edição no modo de validação para confirmar se os aspectos do ambiente de aplicativos e de configuração, como conectividade e acesso ao banco de dados, estão funcionando conforme o esperado. Ao executar uma implementação em um modo de validação da edição, a operação ocorre no destino de implementação no qual a edição foi originalmente instalada. A execução de uma implementação faz com que a edição saia do modo de validação. Quando a validação é concluída, o destino da validação é excluído. O exemplo a seguir é um diagrama de validação da edição.

Figura 4. Validação da Edição
A Figura 4 mostra como um cluster dinâmico é clonado e a edição fica pronta para iniciar no destino de implementação clonado durante a validação da edição

Compatibilidade de Edições

Algumas mudanças no aplicativo são transparentes, enquanto que outras mudanças são vistas pelo usuário final. Quando um upgrade de aplicativo entrega no mínimo as mesmas interfaces de programação de aplicativos como a última mudança feita e nenhuma semântica muda o comportamento essencial, essa edição do aplicativo é um upgrade que é compatível com versões anteriores. Como um usuário existente, você pode usar o aplicativo em que foi feito o upgrade sem alterar o modo de usá-lo e sem reconhecer uma diferença entre as edições atuais e anteriores.

Um upgrade de aplicativo que requer que os usuários existentes alterem a forma como eles utilizam o aplicativo é um upgrade incompatível. Você pode precisar descartar a função anterior ou alterar as interfaces, por exemplo, aprimorar a sustentabilidade ou outros fatores e pode introduzir mudanças incompatíveis no ambiente de implementação. As mudanças incompatíveis requerem planejamento cuidadoso para gerenciar o impacto em usuários existentes.




Conceitos relacionados
Application Edition Manager
Referências relacionadas
Estados do Gerenciador de Edição de Aplicativo
Tópico de Conceito    

Termos de Uso | Feedback

Última atualização: 24/09/2009 14h14min58s EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/appedition/cxappedcon.html