Um aplicativo virtual é uma entidade projetada pelo cliente que contém: artefatos de padrão de mercado (que podem ser implementados em componentes de middleware corporativos), um conjunto de políticas que controla o comportamento do aplicativo no tempo de execução, após ser implementado.

Um dos principais recursos do IBM® Workload Deployer 3.0 (nova marca do WebSphere® CloudBurst) é permitir que o cliente se concentre em uma visualização lógica do aplicativo corporativo e deixe que o dispositivo determine quais componentes de middleware devem ser implementados e também como configurá-los.

Este artigo demonstra como desenvolver um padrão de aplicativo virtual, em outras palavras, como avaliar os requisitos do aplicativo corporativo e defini-los de modo que seja possível usar o recurso Virtual Application Builder do Workload Deployer.

O cenário da tarefa: desenvolvimento de padrão de aplicativo virtual

Digamos que a sua organização possua alguns aplicativos em produção e outros que ainda estão por vir. O processo típico para o pessoal de TI é determinar os requisitos de hardware e software para cada aplicativo, seus requisitos de arquivo, e em seguida realizar o processo cansativo de instalar e configurar o hardware e o software. Em seguida, vem a fase na qual se tenta configurar monitoramento e failover, bem como uma maneira de coletar e monitorar logs. Você pode ter que criar scripts customizados para cada aplicativo, para que as coisas sejam mais fáceis da próxima vez, e acabar criando uma enorme coleção de hardware/software/aplicativo e scripts etc.

Suponha que você pudesse padronizar as necessidades de aplicativos e ter espaço de manobra suficiente para aumentar o número não só de aplicativos em produção, mas também em desenvolvimento e teste. Você aproveitaria a oportunidade? É aqui que entra o Workload Deployer. Digamos que um aplicativo típico tenha código implementado em um servidor de aplicativo J2EE com alguns dados em um banco de dados relacional, e há uma maneira rápida e fácil de configurar criação de log, monitoramento, failover etc. Isso não seria prático? É exatamente isso que o Workload Deployer oferece no padrão WebApp. Após implementar o Workload Deployer em um datacenter, é possível implementar rapidamente aplicativos e configurar monitoramento, ajuste de escala e criação de log de forma padronizada.

Os artefatos típicos para um aplicativo virtual baseado no padrão WebApp incluem:

• J2EE Enterprise Archive (EAR) ou J2EE Web Application Archive (WAR) para implementação em um servidor de aplicativo.
• Script para criar esquema/tabela/filas de banco de dados para inicialização.
• Lista de usuários e grupos como arquivo LDIF (Formato de Troca de Dados LDAP).

O Workload Deployer permite projetar rapidamente um aplicativo virtual, carregar esses artefatos, especificar políticas relacionadas a criação de log, monitoramento, ajuste de escala... e implementar o aplicativo virtual em uma nuvem privada.

Voltar para parte superior

O jeito rápido de criar um aplicativo virtual

Ou é possível usar o Virtual Application Builder no IBM Workload Deployer 3.0 para criar um aplicativo virtual.

Por exemplo, é possível criar um novo aplicativo virtual, arrastar e soltar os componentes Enterprise Application e Database e associar um ao outro. Você faz upload de um Web Archive (WAR) ou Enterprise Archive (EAR) baseado em JEE que contém artefatos de código e de um esquema de banco de dados que descreve a estrutura de tabela que o código espera. O IBM Workload Deployer reconhece esse aplicativo como algo que pode ser implementado usando o padrão WebApp de forma otimizada, por isso o termo "aplicativo virtual".

Uma das principais distinções entre o conceito existente do sistema virtual do WebSphere Cloudburst legado é que não é preciso decidir ou saber exatamente quantas máquinas virtuais seriam iniciadas nos hypervisors para desenvolver o sistema em execução. Essa responsabilidade é delegada ao Workload Deployer, que examina os componentes, os links entre eles e as políticas associadas para estabelecer a melhor solução em termos de número de máquinas virtuais e do que exatamente é executado em cada uma delas.

Com um sistema virtual, é possível escolher o componente de middleware necessário, bem como sua quantidade. Com aplicativos virtuais, não é preciso se preocupar com isso, basta especificar políticas para controlar, por exemplo, o aspecto de escalabilidade do aplicativo ao projetá-lo.

Voltar para parte superior

Desenvolvimento de padrão de aplicativo virtual com IWD

O que significa desenvolver um padrão de aplicativo virtual? De forma simples, significa fazer uma avaliação dos requisitos do aplicativo corporativo e defini-los no IBM Workload Deployer. A parte difícil do processo é entender os requisitos do aplicativo corporativo, mas, depois disso, para defini-los no Workload Deployer bastam algumas operações de arrastar e soltar usando a ferramenta Virtual Application Builder.

Nesta seção, iremos explorar a ferramenta Virtual Application Builder e examinar como:

• Desenvolver um padrão de aplicativo virtual.
• Configurar componentes.
• Configurar links entre componentes.

Informações sobre a ferramenta Virtual Application Builder

A ferramenta Virtual Application Builder é uma ferramenta gráfica integrada que permite desenvolver um aplicativo virtual graficamente. Essa ferramenta é composta por três seções primárias, que funcionam em conjunto para desenvolver graficamente seu aplicativo virtual:

• Ativos (ou paleta): Contém todos os componentes disponíveis que podem ser usados para o desenvolvimento de aplicativos virtuais. Os componentes estão agrupados logicamente (por exemplo, o grupo Database Components contém todos os componentes de banco de dados).
• Tela: Local em que o aplicativo virtual é desenvolvido graficamente.
• Folha de propriedade: Cada componente possui uma folha de propriedade: ela contém as propriedades para um componente particular, link ou política que podem ser configurados.

A Figura 1 mostra a interface com o usuário da ferramenta Virtual Application Builder.

Agora, vamos examinar como desenvolver um padrão de aplicativo virtual.

Desenvolvendo um padrão de aplicativo virtual

Agora que você tem um conhecimento básico da ferramenta Virtual Application Builder, é hora de começar a desenvolver um padrão de aplicativo virtual. Mas, primeiro, entenda que um aplicativo virtual é uma estrutura genérica que permite desenvolver vários tipos de padrões de carga de trabalho. O exemplo de padrão deste artigo possui os seguintes requisitos:

• 1 dependência de um servidor de aplicativos para hospedar o aplicativo corporativo.
• 1 dependência de um banco de dados para manter os dados.
• 1 dependência de um registro do usuário para autenticação.

A primeira etapa do processo é navegar para o painel Virtual Application Pattern localizado em Pattern > Virtual Applications. Essa visualização lista todos os padrões de aplicativo virtual que você está autorizado a visualizar. Clique no ícone de "mais" verde para abrir o painel de criação de aplicativo virtual. Esse painel permite criar um aplicativo do zero ou a partir de um modelo existente. Selecione Blank application e clique em Start Building que leva à ferramenta Virtual Application Builder, mostrada na Figura 2.

O aplicativo corporativo de amostra possui três requisitos de middleware: servidor de aplicativo, banco de dados e registro de usuário. Para satisfazer esses requisitos, é preciso arrastar os componentes da paleta e soltar na tela, como mostra a Figura 3:

• O requisito de servidor de aplicativos será satisfeito pelo componente Enterprise Application (WebSphere Application Server), localizado na subseção Application Components.
• O requisito de banco de dados será satisfeito pelo componente Database (DB2®>), localizado na subseção Database components.
• O requisito de registro do usuário será satisfeito pelo componente User Registry (Tivoli Directory Server), localizado na subseção User Registry Components.

Quando todos os componentes dependentes estiverem na tela, você estará pronto para a próxima etapa, que é estabelecer links entre eles. Links fazem muitas coisas, as mais importantes são:

• Abrir portas na máquina virtual para permitir fluxo de tráfego para dentro e para fora da VM. Todas as portas são bloqueadas, a menos que sejam especificamente abertas usando um link.
• Definir propriedades adicionais.

Nesse caso, o aplicativo tem como requisito comunicar-se com o banco de dados e com o registro do usuário, mas o registro não tem como requisito comunicar-se com o banco de dados ou vice-versa. Para estabelecer um link, clique na esfera azul na ponta do componente de origem, segure o mouse e arraste o link para o componente de destino. A Figura 4 mostra os dois links definidos para esse cenário.

Nesse momento, você já estabeleceu a estrutura do aplicativo virtual. A próxima etapa, antes da implementação, é configurar as propriedades de cada componente e fazer o link. Cada componente e link tem um conjunto exclusivo de propriedades (opcionais e obrigatórias) que podem ser configuradas.

Não há uma regra fixa para a ordem na qual configurar os componentes, mas é recomendado configurar primeiro o Enterprise Application. O motivo ficará claro quando você configurar as propriedades do link.

Configurando componentes

1. Para configurar o componente Enterprise Application, faça upload do aplicativo corporativo (Figura 5).
   
   Figura 5. Configure as propriedades do componente Enterprise Application
   
   
   
2. Para configurar o componente Database, especifique um nome e tamanho para o banco de dados. Se o aplicativo esperar que o banco de dados seja preenchido previamente, também é necessário fazer o upload de um arquivo de esquema. É importante notar que o ciclo de vida desse banco de dados segue o ciclo de vida do aplicativo virtual ao qual pertence. Se o aplicativo for finalizado, o banco de dados e todas as suas informações de estado serão finalizados.
3. Para configurar o componente User Registry, faça upload de um arquivo LDIF e especifique os filtros de usuário e grupo.

Configurando links

Cada link representa um caminho de comunicação ou uma associação entre componentes. Assim como ocorre com componentes, as propriedades de cada link são exclusivas.

1. Configure o link do banco de dados entre os componentes Enterprise Application e Database. Clique no link para exibir suas propriedades. Além de abrir um canal de comunicação, esse link permite mapear os nomes de JNDI da origem de dados do aplicativo corporativo. A Figura 6 mostra um exemplo.
   
   Figura 6. Configure o link de Enterprise Application para Database
   
   
   

   No momento da implementação, o nome JNDI que você especificou será ligado àquele que o WebSphere Application Server cria para suportar o componente Database.

2. Configure um link entre os componentes Enterprise Application e User Registry. Esse link permite mapear funções definidas no aplicativo corporativo para usuários e grupos concretos definidos no componente User Registry. A Figura 7 mostra esse mapeamento.
   
   Figura 7. Configuração do link entre Enterprise Application e User Registry
   
   
   

   Observe que a referência Data Source da propriedade Resource do componente Database e a propriedade Role Name do componente User Registry possuem opções pré-configuradas derivadas do seu aplicativo corporativo. Ao incluir um link no aplicativo virtual, o Workload Deployer procura informações relevantes nos descritores de implementação do aplicativo corporativo. No caso de referências JNDI, ele inspeciona web.xml; para funções de segurança, inspeciona application.xml. A Figura 8 exemplifica essa situação.

   
   
   Figura 8. Pontos de inspeção de application.xml e web.xml
   
   
   
3. Salve seu aplicativo virtual (Figura 9):
   
   Figura 9. Salve seu aplicativo virtual
   
   
   

E isso é tudo! Em seguida, implemente e monitore o aplicativo virtual.

Voltar para parte superior

Implementando o aplicativo

É aqui que a diversão começa! Depois que o aplicativo for modelado no Virtual Application Builder, é possível implementar o aplicativo vAppArticle. Isso é muito fácil de ser feito! Para implementar o aplicativo virtual:

1. Clique em Patterns > Virtual Application e clique em vAppArticle. A Figura 10 mostra um exemplo.
   
   Figura 10. Localizando o aplicativo virtual
   
   
   
2. No lado direito do painel, clique em Deploy the virtual application into the cloud para iniciar a implementação, como mostra a Figura 11.
   
   Figura 11. Implementação do aplicativo virtual
   
   
   Clique para obter uma imagem ampliada.
   
3. Após clicar em Deploy the virtual application into the cloud, você terá a opção de selecionar o grupo de nuvens, como mostra a Figura 12.
   
   Figura 12. Destino da implementação do aplicativo virtual
   
   
   

   No Workload Deployer, os aplicativos virtuais somente oferecem suporte a grupos de nuvens como destino da implementação. Eles não oferecem suporte a perfis de ambiente como destino de implementação.

   A caixa de diálogo na Figura 12 também oferece uma opção Advanced para configurar acesso de SSH seguro para as VMs implementadas. É possível fazer upload de sua própria chave pública ou fazer com que o Workload Deployer gere uma chave pública/privada para você. As VMs implementadas não permitem acesso por usuário/senha, em vez disso, requerem acesso de usuário/chave privada. Se você não configurar o acesso de SSH seguro, não poderá acessar as VMs diretamente. É possível incluir e alterar essa chave no console do aplicativo virtual após o aplicativo ter sido implementado. Clique em OK.

4. Workload Deployer inicia a implementação de um aplicativo virtual. Pouco tempo depois, dependendo da configuração de rede, o aplicativo virtual foi implementado e está pronto para ser usado.

   O Workload Deployer transforma a implementação do aplicativo em ações específicas da infraestrutura. Ele inicia as implementações de VMs necessárias e configura o middleware e o aplicativo.

5. Para verificar o status da implementação, clique em Instances > Virtual Application e, em seguida, clique no aplicativo vAppArticle como mostra a Figura 13.
   
   Figura 13. Instância do aplicativo virtual
   
   
   

   A implementação do aplicativo virtual oculta os detalhes específicos da infraestrutura e do middleware. Por exemplo, não é preciso especificar o número de VMs ou a versão do WebSphere Application Server. Isso ajuda o desenvolvedor do aplicativo a se concentrar em desenvolver o aplicativo e deixar os detalhes sobre infraestrutura e middleware para o IBM Workload Deployer.

   A Figura 14 mostra o status da implementação do aplicativo virtual.

   
   
   Figura 14. Status da implementação do aplicativo virtual
   
   
   Clique para obter uma imagem ampliada.
   
   

   À medida que o aplicativo virtual é implementado, o Status da VM muda de Launching para Running. Quando a VM estiver totalmente instanciada, o agente específico do Workload Deployer que reside dentro dela inicia a ação para configurar a VM para a função que ela terá na implementação desse aplicativo.

   Uma função para uma VM indica a natureza do middleware que uma VM específica terá. Por exemplo, uma função para uma VM pode ser WebSphere Application Server, DB2 ou um TDS. Quando o agente do IBM Workload Deployer configurar a VM para uma função específica, o seu Status de Função mudará e eventualmente ficará verde quando a função estiver totalmente configurada. Quando todas as funções forem configuradas com sucesso e estiverem com o status verde, o aplicativo virtual estará pronto para ser acessado.

6. Quando o aplicativo virtual for implementado, ele pode ser acessado diretamente ao clicar no hyperlink ENDPOINT para a VM do WAS, como mostra a Figura 15.
   
   Figura 15. Acesse seu aplicativo corporativo
   
   
   Clique para obter uma imagem ampliada.
   
   

   A URL de terminal para as VMs de banco de dados e registro do usuário indica informações específicas para acessar o middleware. Por exemplo, a URL do terminal do banco de dados fornece informações de conexão para acessar o banco de dados usando um cliente DB2.

Voltar para parte superior

Monitorando o aplicativo

Quando o aplicativo virtual é implementado, o IBM Workload Deployer permite monitorar e gerenciar a implementação do aplicativo virtual a partir do Virtual Application Console. Também oferece recursos para realizar operações específicas nas máquinas virtuais implementadas e visualizar logs específicos do SO, do middleware e do agente do Workload Deployer a partir deste painel centralizado.

Para acessar o Virtual Application Console, clique em Instances > Virtual Applications e clique em vAppArticle. No painel à direita, clique em More details and advanced options como mostra a Figura 16. O Virtual Application Console é aberto em uma nova janela do navegador.

O Virtual Application Console possui quatro guias:

• Virtual Machine Monitoring: Essa visualização exibe as estatísticas da máquina virtual em tempo real, em um formato gráfico. Por exemplo, se o aplicativo implementado estiver consumindo muitos ciclos de CPU, essa visualização irá mostrar um alto uso de CPU para essa VM.
• Middleware Monitoring: Essa visualização exibe as estatísticas de monitoramento do middleware em tempo real, em um formato gráfico. Por exemplo, durante os horários de pico no uso do aplicativo, é possível controlar a sua contagem de solicitações.
• Operation: Essa visualização oferece a possibilidade de realizar operações específicas do middleware nas VMs de destino. Por exemplo, você pode querer atualizar o aplicativo instalado com uma versão, mas não finalizar toda a implementação. A guia Operation permite que um usuário atualize o aplicativo e realize outras operações necessárias.
• Logging: Essa visualização oferece uma interface com o usuário centralizada, com uma coleção de logs específicos do SO, do middleware e do agente do Workload Deployer para cada VM. Ter todos os logs disponíveis é muito útil para depurar falhas de modo simultâneo em diferentes subsistemas em diferentes VMs.

Capturas de tela de exemplo das guias Operation e Logging são mostradas nas Figuras 17-18.

Voltar para parte superior

Bônus: Configure seu próprio padrão de banco de dados

Embora isso não seja válido para todas as configurações, geralmente o banco de dados é uma entidade separada do aplicativo, seguindo seu próprio ciclo de vida e gerenciado por uma equipe completamente diferente com um conjunto de qualificações exclusivo. O Workload Deployer reconhece esse requisito, e permite que o banco de dados seja criado e gerenciado como uma entidade separada. Desse modo, o aplicativo virtual pode se conectar a esse banco de dados existente, não sendo necessário criar um próprio.

Nesta seção, você irá configurar o padrão de banco de dados do Workload Deployer (chamado vAppDB) e aumentar o aplicativo virtual para que ele use o componente Existing Database, para utilizar o banco de dados que criamos. O foco deste artigo é examinar padrões de aplicativos da Web e não padrões de banco de dados, mas esse é um importante recurso de suporte do Workload Deployer. Em essência, este artigo demonstra como ativar um modelo de Banco de Dados como Serviço.

Configurar e implementar o padrão de banco de dados vAppDB

1. Navegue até Patterns > Database Patterns e clique no ícone verde de "mais". O painel Database Pattern é exibido. Nesse painel, é possível definir o nome e tamanho do banco de dados e também fazer upload de qualquer arquivo de esquema de suporte, como mostra a Figura 19.
   
   Figura 19. Painel de criação Database Pattern
   
   
   
2. Após definir todas as propriedades do banco de dados, clique em Save e implemente o banco de dados realçando o banco e clicando no ícone Deploy. Esse processo pode levar alguns minutos, dependendo da rede. Para monitorar o status da implementação do banco de dados, navegue até Instances > Databases e realce o banco de dados para exibir suas informações. Quando a implementação for concluída, anote as informações de Host, Porta, Usuário e Senha, como mostra a Figura 20.
   
   Figura 20. Informações da instância do banco de dados (Host e Porta)
   
   
   

   Essas informações são usadas ao aumentar o aplicativo virtual com o componente Existing Database.

Aumentar com o componente Existing Database

Frequentemente, é preciso se conectar a um middleware existente ou a um sistema corporativo legado dentro ou fora da organização. O Workload Deployer também ajuda esse processo. Ele oferece a flexibilidade para acessar e continuar a explorar sistemas fora da nuvem privada. O Workload Deployer tem componentes que permitem se conectar a bancos de dados existentes, registros de usuário, CICS, IMS etc.

Este cenário realça esse recurso ao aumentar o aplicativo virtual com o componente Existing Database. O único motivo pelo qual esse componente foi escolhido em vez de, por exemplo, o componente Existing User Registry, é que ele demonstra o recurso de padrão do banco de dados. Vale reforçar que foi apresentada apenas uma parte das funções do padrão de banco de dados, agora que sabe disso, você pode explorar ainda mais esse recurso, caso deseje.

1. Abra seu aplicativo virtual na ferramenta Virtual Application Builder. Exclua o componente Database (essa ação também removerá o link associado), inclua o componente Existing Database (DB2) e restabeleça o link, como mostra a Figura 21.
   
   Figura 21. Componente Database removido e restaurado
   
   
   
2. Configure o componente Existing Database. Use as informações de host, porta, usuário e senha que você anotou durante as etapas de criação e implementação do vAppDB para configurar esse componente.
3. Reconfigure a folha de propriedade do link, pois essas informações não existem para o link recém-criado. A Figura 22 mostra um exemplo.
   
   Figura 22. Folha de propriedade de Existing Database
   
   
   

Com exceção de salvar suas atualizações, você concluiu a configuração de um banco de dados que será gerenciado como uma entidade separada. Você aumentou seu aplicativo virtual para usar um componente Existing Database em vez de um componente Database.

Voltar para parte superior

Serviços compartilhados (cache e proxy)

Serviços compartilhados são serviços que são compartilhados por uma ou mais instâncias de aplicativo virtual. Atualmente, existem dois serviços compartilhados:

• Armazenamento em Cache como Serviço.
• Proxy como Serviço.

Configurar e iniciar os serviços compartilhados são atividades administrativas. Isso é feito uma única vez e, posteriormente, pode ser usado por todas as instâncias de aplicativo virtual. O usuário não precisa se preocupar em iniciar e gerenciar um serviço de cache e de proxy para sua implementação.

Dois importantes benefícios do compartilhamento desses serviços:

• Recursos são mais bem utilizados. Não é necessário ter proxy e armazenamento em cache separados para cada implementação de aplicativo virtual.
• Suporte de failover: serviços compartilhados são implementados com diversas VMs, de modo que, se uma VM ficar inativa, as outras compensam a carga de trabalho até que a VM com falha seja recriada ou reiniciada.

Ativando serviços compartilhados (administrador)

1. Para iniciar os serviços compartilhados, faça login como usuário de nível administrativo. Clique em Cloud > Shared Services como mostra a Figura 23.
   
   Figura 23. Ativação de serviços compartilhados
   
   
   Clique para obter uma imagem ampliada.
   
   
2. Você verá 2 serviços compartilhados: CachingService e PROXY. Os serviços são pré-configurados. Clique no ícone de implementação para cada serviço.
3. Duas informações são necessárias para implementação de cada serviço: número de VMs e grupo de nuvens de destino. E é isso. Clique em Deploy e, após um breve período, os serviços compartilhados estarão prontos para serem usados. A Figura 24 mostra um exemplo da execução do serviço de cache.
   
   Figura 24. Implementação do Serviço de Cache compartilhado
   
   
   Clique para obter uma imagem ampliada.
   
   

Ativando serviços compartilhados para padrão de aplicativo da Web (usuário)

Os serviços de cache e proxy foram projetados para uso com aplicativos virtuais em geral. O que demonstramos aqui é um uso de serviços compartilhados por meio do padrão Web Application.

O padrão Web Application usa o serviço de cache para armazenar informações sobre a sessão HTTP. Ele usa persistência na memória e não no banco de dados, mas isso não deve ser um problema, dado o suporte a failover oferecido pelo serviço de cache. Ative o padrão Web Application para usar o serviço de cache, inclua primeiro a política Scaling e, em seguida, marque a caixa de opção Enable session caching.

O padrão Web Application usa o serviço de proxy para encaminhar solicitações para o aplicativo virtual. Para ativar o padrão Web Application para usar o serviço de proxy, inclua as políticas Scaling e Routing no componente Enterprise Application.

Isso é tudo para a funcionalidade básica. A Figura 25 mostra um exemplo desses serviços ativados.

A próxima e última etapa é implementar o aplicativo virtual com essas novas configurações. A única verdadeira diferença que você irá notar é que agora o aplicativo é acessado usando o nome do host virtual. Nos bastidores, há muita coisa acontecendo: o acesso ao aplicativo através do nome do host virtual é roteado primeiro pelo serviço de proxy. Além disso, as informações sobre a sessão HTTP são mantidas no serviço de cache e não localmente na VM.

Uma última coisa que deve ser mencionada para concluir este cenário, mas que não está no escopo deste artigo, é a necessidade de configurar os balanceadores de carga máquina virtual de IP para rotear solicitações recebidas destinadas ao host virtual para os endereços IP da VM do serviço de proxy.

Voltar para parte superior

Conclusão

Criar, implementar e gerenciar aplicativos e bancos de dados virtuais é uma tarefa essencial na computação em nuvem, e o Workload Deployer é uma solução pronta para uso que permite fazer isso facilmente.

Recursos

Aprender

• Em Domine o poder da nuvem com o IBM Workload Deployer V3, saiba sobre as melhorias do IBM Workload Deployer para aplicativos, em relação ao seu antecessor, o WebSphere CloudBurst.
  
  
• O entusiasta do WebSphere Dustin Amrhein escreve com frequência sobre IBM Workload Deployer em seu blog A view from the clouds: Cloud computing for the WebSphere developer.
  
  
• O artigo de blog com três partes IBM Workload Deployer: Application-centric cloud platform oferece muitas informações sobre IWD.
  
  
• Visite o site do IBM Workload Deployer . A biblioteca de documentos contém webcasts, Redbooks e white papers sobre o Workload Deployer.
  
  
• Nos recursos para desenvolvedores de nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão desenvolvendo os seus projetos de implementação de nuvem.
  
  
• Nos Recursos do WebSphere, descubra e compartilhe conhecimento e experiência sobre o IBM Workload Deployer.
  
  
• Próximas etapas: Descubra como acessar o IBM SmartCloud Enterprise.
  
  
• Para obter conteúdo e recursos para desenvolvedores técnicos em computação em nuvem, consulte Cloud computing: Fundamentals.
  
  
• Siga o developerWorks no Twitter.
  
  

Obter produtos e tecnologias

• Consulte as imagens do produto disponíveis para IBM SmartCloud Enterprise.
  
  

Discutir

• Participe de um grupo sobre computação em nuvem no developerWorks.
  
  
• Leia todos os ótimos blogs sobre nuvem no developerWorks.
  
  
• Participe da comunidade do developerWorks, uma rede profissional e conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.
  
  

Sobre os autores

Brian Stelzer é engenheiro de software e chefe da equipe do IBM Workload Deployer. Em sua posição atual, ele fornece treinamento e soluções de arquitetura para ambientes baseados em nuvem, com foco em IBM Workload Deployer, WebSphere Application Server e tecnologias com base em VMware. Anteriormente, ele projetou soluções de migração para o WebSphere Application Server e o WebSphere Application Server Community Edition.

Davanum Srinivas é engenheiro de software senior e chefe da equipe do IBM Workload Deployer. Em sua função atual, ele lidera uma equipe que trabalha nos aspectos de armazenamento do IBM Workload Deployer. Anteriormente, ele trabalhou como arquiteto de release da equipe IBM Workload Deployer e participou do desenvolvimento do WebSphere Web Services.

Amit Acharya é Advisory Software Engineer na organização IBM Cloud Initiatives Development. Ele chefia o planejamento de qualidade estratégica e a execução do produto no espaço de nuvem privada.Também tem uma participação importante na execução do programa beta de Platform as a Service. Ele tem grande experiência no desenvolvimento de aplicativos corporativos e soluções de middleware com foco orientado ao cliente. Escreveu IBM Redbooks sobre a arquitetura orientada a serviços e contribuiu ativamente para o IBM Patent Portfolio. Possui mestrado em engenharia elétrica e de computação pela Universidade Purdue.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• O cenário da tarefa: desenvolvimento de padrão de aplicativo virtual
• O jeito rápido de criar um aplicativo virtual
• Desenvolvimento de padrão de aplicativo virtual com IWD
• Implementando o aplicativo
• Monitorando o aplicativo
• Bônus: Configure seu próprio padrão de banco de dados
• Serviços compartilhados (cache e proxy)
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais