BR112012018768B1 - método implementado por um sistema de tratamento de informação e sistema de tratamento de informação - Google Patents

Abstract

PORTAGEM DE IMAGENS DE MÁQUINAS VIRTUAIS ENTRE AS PLATAFORMAS. Em uma concretização, é fornecida uma abordagem que diferencia um modelo de topologia de origem associado a uma plataforma de origem e um modelo de topologia de destino associado a uma plataforma de destino. Esta diferenciação é executada por um processador e resulta em uma diferença de topologia. Uma operação em um modelo de fluxo de trabalho é obtida a partir de uma biblioteca de recursos, a operação estando associada à diferença de topologia. Pelo menos uma parte da biblioteca de recursos é armazenada em um meio de armazenamento persistente. A operação para implementar uma parte de uma solução é transmitida para implementação. A parte implementada da solução inclui uma imagem de destino compatível com a plataforma de destino.

Description

Campo da Invenção

[0001] A invenção refere-se ao campo de sistemas de computador distribuídos. Em particular, a invenção refere- se a um método e sistema para portabilidade de imagens virtuais entre plataformas.

Antecedentes da Invenção

[0002] Computação em nuvem é um termo que descreve os serviços com base na internet. Os serviços com base na Internet são hospedados por um provedor de serviços. Os provedores de serviços podem fornecer infraestrutura de hardware ou aplicativos de software para clientes solicitantes em uma rede de computadores. Os clientes solicitantes podem acessar os aplicativos de software usando aplicativos de software de "navegador" com base em cliente tradicionais, enquanto que o software (instruções) e dados são armazenados em servidores mantidos pelos provedores de computação em nuvem.

[0003] Para que um provedor de serviços possa aproveitar a execução de aplicativos em um ambiente de computação em nuvem, o provedor de serviços precisa mover seus aplicativos existentes para o ambiente de computação em nuvem. Alternativamente, pode ser necessário que um provedor de serviços atualize seus aplicativos de um ambiente de computação para outro.

[0004] A portabilidade de aplicativos de um ambiente para outro, muitas vezes, é demorada e difícil de fazer. A portabilidade de soluções independentes de plataforma em uma ou mais imagens virtuais de um provedor de nuvem para outro é difícil porque os formatos de imagem são específicos da tecnologia de hipervisor suportada pelo ambiente de computação em nuvem. Além disso, várias etapas de configuração manual tediosas são necessárias no sistema operacional convidado para se adequar aos requisitos de hipervisor específicos da nuvem e, muitas vezes, não há disponibilidade de imagens base com componentes de software dependentes parcialmente instalados e configurados nas versões apropriadas, etc.

[0005] O documento US0090282404 descreve um servidor de provimento para configurar automaticamente uma máquina virtual (Virtual Machine- VM) de acordo com as especificações do usuário e implementar a VM em um host físico.

[0006] O usuário pode escolher entre uma lista de VMs pré-configuradas e preparadas para implementar ou pode selecionar qual hardware, sistema operacional e aplicativos ele gostaria que a VM tenha. O servidor de provimento configura, então, a VM em conformidade se a configuração desejada estiver disponível ou aplica heurísticas para configurar uma VM que melhor corresponda à solicitação de usuário se não estiver. A invenção também inclui mecanismos para monitorar o estado de VMs e hosts, para migração de VMs entre hosts e criar uma rede de VMs.

[0007] O documento US 7356679 descreve como uma imagem de origem da configuração de hardware e software de um computador de origem, incluindo o estado de pelo menos um disco de origem, é automaticamente capturada. O computador de origem pode permanecer despreparado e não requerer nenhum programa para facilitar a clonagem e reconfiguração do computador. A imagem de origem é automaticamente analisada e a configuração de hardware de um computador de destino é determinada. A imagem de origem é modificada conforme necessário para compatibilidade com o computador de destino, ou para personalização e, após possível modificação, a imagem de origem é implementada no computador de destino. Qualquer um ou ambos dos computadores de origem e de destino podem ser máquinas virtuais.

[0008] No entanto, nenhuma das soluções anteriores do estado da técnica descreve um meio no qual portar uma solução parcial/completa que inclui uma ou mais imagens virtuais com verificações/informações de compatibilidade de um ambiente de computação em nuvem para outro.

Sumário da Invenção

[0009] Em uma concretização, é fornecida uma abordagem que diferencia um modelo de topologia de origem associado a uma plataforma de origem e um modelo de topologia de destino associado a uma plataforma de destino. Esta diferenciação é executada por um processador e resulta em uma diferença de topologia. Uma operação em um modelo de fluxo de trabalho é obtida a partir de uma biblioteca de recursos, a operação estando associada à diferença de topologia. Pelo menos uma parte da biblioteca de recursos é armazenada em um meio de armazenamento persistente. A operação para implementar uma parte de uma solução é transmitida para implementação. A parte implementada da solução inclui uma imagem de destino compatível com a plataforma de destino.

[0010] O precedente é um sumário e, portanto, contém, por necessidade, simplificações, generalizações e omissões de detalhes; consequentemente, aqueles versados na técnica apreciarão que o sumário é apenas ilustrativo e não se destina a estar limitado de forma alguma. Outros aspectos, características e vantagens da invenção, conforme definido apenas pelas reivindicações, se tornarão evidentes na descrição detalhada não limitativa a seguir.

[0011] Vista a partir de um primeiro aspecto, a presente invenção fornece um método implementado por um sistema de processamento de informações que compreende: diferenciar um modelo de topologia de origem associado a uma plataforma de origem e um modelo de topologia de destino associado a uma plataforma de destino que resulta em uma diferença de topologia, em que pelo menos uma parte da diferenciação é executada por um processador; obter uma operação em um modelo de fluxo de trabalho a partir de uma biblioteca de recursos, em que a operação está associada à diferença de topologia e em que pelo menos uma parte da biblioteca de recursos é armazenada em um meio de armazenamento persistente; e transmitir a operação para implementar pelo menos uma parte de uma solução, em que a parte implementada da solução inclui uma imagem virtual de destino compatível com a plataforma de destino.

[0012] De preferência, a presente invenção fornece um método que compreende ainda: implementação da parte da solução na plataforma de destino ao executar a operação.

[0013] De preferência, a presente invenção fornece um método em que um resultado da implementação inclui uma portabilidade da solução da plataforma de origem para a plataforma de destino.

[0014] De preferência, a presente invenção fornece um método em que a plataforma de origem é uma primeira nuvem e em que a plataforma de destino é uma segunda nuvem.

[0015] De preferência, a presente invenção fornece um método em que a solução é uma solução compósita e em que a segunda nuvem inclui uma pluralidade de nuvens.

[0016] De preferência, a presente invenção fornece um método em que a plataforma de origem é uma nuvem privada e em que a plataforma de destino é uma nuvem pública.

[0017] De preferência, a presente invenção fornece um método que compreende ainda: buscar metadados para pelo menos um metadado de imagem virtual de base que está associado à plataforma de destino.

[0018] De preferência, a presente invenção fornece um método que compreende ainda: buscar os metadados em uma ou mais bibliotecas de imagens virtuais específicas da nuvem.

[0019] De preferência, a presente invenção fornece um método que compreende ainda: recuperar parâmetros de entrada usados na busca, em que os parâmetros de entrada são fornecidos pelo modelo de topologia de destino.

[0020] De preferência, a presente invenção fornece um método que compreende ainda: recuperar uma ou mais descrições de imagem virtual de base a partir dos metadados armazenados na biblioteca de recursos em resposta à busca.

[0021] De preferência, a presente invenção fornece um método em que a plataforma de origem é uma primeira nuvem e em que a plataforma de destino é uma segunda nuvem, o método compreendendo ainda: recuperar, a partir da biblioteca de recursos, um primeiro conjunto de unidades modelo que correspondem à plataforma de origem; recuperar, a partir da biblioteca de recursos, um segundo conjunto de unidades modelo que correspondem à plataforma de destino, em que a diferenciação resulta em uma ou mais unidades modelo em comum e uma ou mais unidades modelo diferentes; reutilizar um primeiro conjunto de uma ou mais etapas de fluxo de trabalho que correspondem a cada uma das unidades modelo em comum; recuperar, a partir da biblioteca de recursos, um segundo conjunto de uma ou mais etapas de fluxo de trabalho que correspondem a uma ou mais das diferentes unidades modelo; e criar o modelo de fluxo de trabalho usando o primeiro conjunto de etapas de fluxo de trabalho reutilizado e o segundo conjunto de etapas de fluxo de trabalho recuperado.

[0022] De preferência, a presente invenção fornece um método que compreende ainda: associar a diferença de topologia ao modelo de topologia de origem e ao modelo de topologia de destino; e armazenar a diferença de topologia e as associações na biblioteca de recursos como um patch.

[0023] De preferência, a presente invenção fornece um método que compreende ainda: receber um segundo modelo de topologia de origem que é parcialmente em comum ao modelo de topologia de origem e uma segunda plataforma de destino que é parcialmente em comum à plataforma de destino; buscar um ou mais patches, incluindo o patch, na biblioteca de recursos, em que a busca inclui o modelo de topologia de origem associado; recuperar o patch da biblioteca de recursos em resposta à busca; e aplicar o patch recuperado ao segundo modelo de topologia de origem, resultando em um segundo modelo de topologia de destino associado à segunda plataforma de destino.

[0024] De preferência, a presente invenção fornece um método em que a solução é uma solução compósita compreendida de múltiplas partes virtuais, em que uma parte virtual é compreendida de um modelo de uma imagem virtual e seus OS convidados constituintes, middleware e unidades modelo de aplicativo, em que cada parte virtual é implementada em uma plataforma de destino diferente e em que cada plataforma de destino corresponde a uma nuvem pública ou uma nuvem privada.

[0025] De preferência, a presente invenção fornece um método que compreende ainda: transmitir uma pluralidade de operações, incluindo a operação, para implementar uma solução completa.

[0026] De preferência, a presente invenção fornece um método em que a diferenciação compreende ainda: identificar um primeiro conjunto de unidades modelo que correspondem à plataforma de origem; identificar um segundo conjunto de unidades modelo que correspondem à plataforma de destino; comparar o primeiro conjunto de unidades modelo com o segundo conjunto de unidades modelo, a comparação resultando em um conjunto de uma ou mais unidades modelo modificadas e um conjunto de uma ou mais unidades modelo em comum; recuperar um primeiro conjunto de modelos de etapas de automação a partir do modelo de topologia de origem que corresponde às unidades modelo em comum; buscar na biblioteca de recursos as unidades modelo modificadas, a busca resultando em um segundo conjunto de modelos de etapa de automação que correspondem às unidades modelo modificadas; e incluir os primeiro e segundo conjuntos de modelos de etapa de automação no modelo de fluxo de trabalho.

[0027] De preferência, a presente invenção fornece um método em que a diferenciação resulta em uma identificação de uma ou mais unidades novas, em que as unidades novas são encontradas no modelo de topologia de destino e não são encontradas no modelo de topologia de origem e em que o método compreende ainda: buscar na biblioteca de recursos as unidades novas.

[0028] De preferência, a presente invenção fornece um método em que a operação para implementar a parte da solução permite que a parte da solução seja transferida de um provedor de nuvem para outro provedor de nuvem.

[0029] De preferência, a presente invenção fornece um método em que a operação para implementar a parte da solução define um firewall de segurança.

[0030] De preferência, a presente invenção fornece um método em que a operação para implementar a parte da solução copia a imagem virtual de destino na plataforma de destino.

[0031] De preferência, a presente invenção fornece um método em que a plataforma de origem é um primeiro hipervisor que é executado em um primeiro conjunto de um ou mais sistemas de computador, em que a plataforma de destino é um segundo hipervisor que é executado em um segundo conjunto de um ou mais sistemas de computador e em que os primeiro e segundo hipervisores são diferentes tipos de hipervisores.

[0032] De preferência, a presente invenção fornece um método em que os modelos de topologia de origem e de destino incluem, cada um, metadados que descrevem um ou mais componentes de aplicativo de software, um componente de aplicativo de software de middleware e um componente de sistema operacional convidado.

[0033] De preferência, a presente invenção fornece um método em que os metadados incluídos com os modelos de topologia de origem e de destino incluem, cada um, um ou mais parâmetros de implementação de imagem virtual, em que o modelo de topologia de origem inclui unidades modelo de topologia de origem de parâmetros de configuração de origem que correspondem a uma nuvem de origem e credenciais de origem e endpoints de serviço de origem, em que o modelo de topologia de destino inclui unidades modelo de topologia de destino de parâmetros de configuração de destino que correspondem a uma nuvem de destino e credenciais de destino e endpoints de serviço de destino.

[0034] De preferência, a presente invenção fornece um método que compreende ainda: associar cada uma das unidades modelo de topologia de origem a um modelo de etapa de automação de origem que detalha uma ou mais das operações usadas para implementar a unidade modelo de topologia de origem associada; associar cada uma das unidades modelo de topologia de destino a um modelo de etapa de automação de destino que detalha uma ou mais das operações usadas para implementar a unidade modelo de topologia de destino associada; e armazenar cada um dos modelos de etapa de automação de destino no modelo de fluxo de trabalho.

[0035] De preferência, a presente invenção fornece um método em que a execução da operação para implementar a parte da solução permite "multi-tenancy"(várias locações).

[0036] De preferência, a presente invenção fornece um método em que a execução da operação para implementar a parte da solução permite cargas de trabalho variáveis.

[0037] Vista de outro aspecto, a presente invenção fornece um sistema de processamento de informações que compreende: um ou mais processadores; uma memória acessível por pelo menos um dos processadores; um meio de armazenamento persistente acessível por pelo menos um dos processadores; uma interface de rede que conecta o sistema de processamento de informações a uma rede de computadores, em que a interface de rede é acessível por pelo menos um dos processadores; e um conjunto de instruções armazenadas na memória e executadas por pelo menos um dos processadores para executar ações de: diferenciar um modelo de topologia de origem associado a uma plataforma de origem e um modelo de topologia de destino associado a uma plataforma de destino que resulta em uma diferença de topologia; obter uma operação em um modelo de fluxo de trabalho a partir de uma biblioteca de recursos, em que a operação está associada à diferença de topologia e em que pelo menos uma parte da biblioteca de recursos é armazenada no meio de armazenamento persistente; e transmitir a operação para implementar pelo menos uma parte de uma solução, em que a parte implementada da solução inclui uma imagem virtual de destino compatível com a plataforma de destino.

[0038] De preferência, a presente invenção fornece um sistema de processamento de informações em que as ações compreendem ainda: implementação da parte da solução na plataforma de destino que executa a operação.

[0039] De preferência, a presente invenção fornece um sistema de processamento de informações em que a plataforma de origem é uma primeira nuvem e em que a plataforma de destino é uma segunda nuvem.

[0040] De preferência, a presente invenção fornece um sistema de processamento de informações em que as ações compreendem ainda: buscar metadados para pelo menos um metadado de imagem virtual de base que está associado à plataforma de destino.

[0041] De preferência, a presente invenção fornece um sistema de processamento de informações em que as ações compreendem ainda: recuperar uma ou mais descrições de imagem virtual de base a partir dos metadados armazenados na biblioteca de recursos em resposta à busca.

[0042] De preferência, a presente invenção fornece um sistema de processamento de informações em que a plataforma de origem é uma primeira nuvem, em que a plataforma de destino é uma segunda nuvem e em que as ações compreendem ainda: recuperar, a partir da biblioteca de recursos, um primeiro conjunto de unidades modelo que correspondem à plataforma de origem; recuperação, a partir da biblioteca de recursos, de um segundo conjunto de unidades modelo que correspondem à plataforma de destino, em que a diferenciação resulta em uma ou mais unidades modelo em comum e uma ou mais unidades modelo diferentes; reutilizar um primeiro conjunto de uma ou mais etapas de fluxo de trabalho que correspondem a cada uma das unidades modelo em comum; recuperar, a partir da biblioteca de recursos, um segundo conjunto de uma ou mais etapas de fluxo de trabalho que correspondem a uma ou mais das diferentes unidades modelo; e criar o modelo de fluxo de trabalho usando o primeiro conjunto de etapas de fluxo de trabalho reutilizado e o segundo conjunto de etapas de fluxo de trabalho recuperado.

[0043] De preferência, a presente invenção fornece um sistema de processamento de informações em que as ações compreendem ainda: associar a diferença de topologia ao modelo de topologia de origem e ao modelo de topologia de destino; e armazenar a diferença de topologia e as associações na biblioteca de recursos como um patch.

[0044] De preferência, a presente invenção fornece um sistema de processamento de informações em que as ações compreendem ainda: receber um segundo modelo de topologia de origem que é parcialmente em comum ao modelo de topologia de origem e uma segunda plataforma de destino que é parcialmente em comum à plataforma de destino; buscar um ou mais patches, incluindo o patch, na biblioteca de recursos, em que a busca inclui o modelo de topologia de origem associado; recuperar o patch da biblioteca de recursos em resposta à busca; e aplicar o patch recuperado ao segundo modelo de topologia de origem, resultando em um segundo modelo de topologia de destino associado à segunda plataforma de destino.

[0045] De preferência, a presente invenção fornece um sistema de processamento de informações em que as ações compreendem ainda: identificar um primeiro conjunto de unidades modelo que correspondem à plataforma de origem; identificar um segundo conjunto de unidades modelo que correspondem à plataforma de destino; comparar o primeiro conjunto de unidades modelo com o segundo conjunto de unidades modelo, a comparação resultando em um conjunto de uma ou mais unidades modelo modificadas e um conjunto de uma ou mais unidades modelo em comum; recuperar um primeiro conjunto de modelos de etapas de automação a partir do modelo de topologia de origem que corresponde às unidades modelo em comum; buscar na biblioteca de recursos as unidades modelo modificadas, a busca resultando em um segundo conjunto de modelos de etapa de automação que correspondem às unidades modelo modificadas; e incluir os primeiro e segundo conjuntos de modelos de etapa de automação no modelo de fluxo de trabalho.

[0046] De preferência, a presente invenção fornece um sistema de processamento de informações em que a diferenciação resulta em uma identificação de uma ou mais unidades novas, em que as unidades novas são encontradas no modelo de topologia de destino e não são encontradas no modelo de topologia de origem e em que as ações compreendem ainda: buscar na biblioteca de recursos as unidades novas.

[0047] De preferência, a presente invenção fornece um sistema de processamento de informações em que a plataforma de origem é um primeiro hipervisor que é executado em um primeiro conjunto de um ou mais sistemas de computador, em que a plataforma de destino é um segundo hipervisor que é executado em um segundo conjunto de um ou mais sistemas de computador e em que os primeiro e segundo hipervisores são diferentes tipos de hipervisores.

[0048] De preferência, a presente invenção fornece um sistema de processamento de informações em que os modelos de topologia de origem e de destino incluem, cada um, metadados que descrevem um ou mais componentes de aplicativo de software, um componente de aplicativo de software de middleware e um componente de sistema operacional convidado.

[0049] De preferência, a presente invenção fornece um sistema de processamento de informações em que os metadados incluídos com os modelos de topologia de origem e destino ainda incluem, cada um, um ou mais parâmetros de implementação de imagem virtual, em que o modelo de topologia de origem inclui unidades modelo de topologia de origem de parâmetros de configuração de origem que correspondem a uma nuvem de origem e credenciais de nuvem e fonte e endpoints de serviço de origem, em que o modelo de topologia de destino inclui unidades modelo de topologia de destino de parâmetros de configuração de destino que correspondem a uma nuvem de destino e credenciais de destino e endpoints de serviço de destino.

[0050] De preferência, a presente invenção fornece um sistema de processamento de informações em que as ações compreendem ainda: associar cada uma das unidades modelo de topologia de origem a um modelo de etapa de automação de origem que detalha uma ou mais das operações usadas para implementar a unidade modelo de topologia de origem associada; associar cada uma das unidades modelo de topologia de destino com um modelo de etapa de automação de destino que detalha uma ou mais das operações usadas para implementar a unidade modelo de topologia de destino associada; e armazenar cada um dos modelos de etapa de automação de destino no modelo de fluxo de trabalho.

[0051] Vista de outro aspecto, a presente invenção fornece um método implementado por um sistema de processamento de informações que compreende: obter uma unidade modelo de topologia que deve ser implementada em uma plataforma de destino; buscar uma pluralidade de modelos de etapas de automação armazenados, em uma biblioteca de recursos armazenada em um meio de armazenamento persistente, um modelo de etapa de automação selecionado que esteja associado à unidade modelo de topologia recebida, a busca executada por um ou mais processadores; obter uma ou mais operações de implementação a partir da biblioteca de recursos, em que as operações de implementação obtidas estão associadas ao modelo de etapa de automação selecionado; e executar as operações de implementação obtidas para implementar a unidade modelo de topologia na plataforma de destino.

[0052] De preferência, a presente invenção fornece um método em que a busca compreende ainda: identificar um conjunto de modelos de etapas de automação a partir da pluralidade de modelos de etapas de automação, em que cada um dos conjuntos de modelos de etapa de automação está associado à unidade modelo de topologia; e comparando o conjunto de modelos de etapas de automação identificados com um conjunto de critérios, em que a comparação de resultados na identificação do modelo de etapa de automação selecionado.

[0053] De preferência, a presente invenção fornece um método implementado por um sistema de processamento de informações que compreende: recuperar, usando um processador, um metadado de imagem de origem a partir de um meio de armazenamento persistente, em que os metadados de imagem de origem correspondem a uma imagem de origem associada a uma plataforma de origem; comparar, pelo processador, os metadados de imagem de origem recuperados com um ou mais metadados de imagem disponíveis que correspondem a uma ou mais imagens virtuais disponíveis associadas a uma plataforma de destino; identificar, com base na comparação, um dos metadados de imagem disponíveis que é mais compatível com os metadados de imagem de origem; e usar a imagem virtual disponível que corresponde aos metadados de imagem disponíveis identificados como uma imagem virtual de destino compatível com a plataforma de destino.

[0054] De preferência, a presente invenção fornece um método em que os metadados de imagem de origem estão associados a um modelo de topologia de origem e a plataforma de destino está associada a um modelo de topologia de destino.

[0055] De preferência, a presente invenção fornece um método em que os metadados de imagem de origem e os metadados de imagem disponíveis incluem metadados de componentes de software.

[0056] De preferência, a presente invenção fornece um método que compreende ainda: melhorar a imagem virtual disponível antes de uso.

[0057] De preferência, a presente invenção fornece um método em que o melhoramento compreende ainda: atualizar um ou mais componentes de software incluídos na imagem virtual disponível.

[0058] De preferência, a presente invenção fornece um método em que a atualização inclui a adição de um dos componentes de software.

[0059] Vista de outro aspecto, a presente invenção fornece um método que compreende: obter uma operação associada a uma diferença de topologia, em que a diferença de topologia é a diferença entre um modelo de topologia de origem associado a uma plataforma de origem e um modelo de topologia de destino associado a uma plataforma de destino; e implementar pelo menos uma parte de uma solução ao executar a operação obtida, em que a parte implementada da solução inclui uma imagem de destino compatível com a plataforma de destino.

[0060] De preferência, a presente invenção fornece um método em que a plataforma de origem é uma primeira nuvem, em que a plataforma de destino é uma segunda nuvem e em que a implementação de pelo menos uma parte de uma solução compreende: transferir pelo menos uma parte da solução da primeira nuvem para a segunda nuvem.

[0061] De preferência, a presente invenção fornece um método em que a plataforma de origem é uma nuvem privada, em que a plataforma de destino é uma nuvem pública e em que a implementação de pelo menos uma parte de uma solução compreende: implementar a solução de uma nuvem privada para uma nuvem pública.

Breve Descrição dos Desenhos

[0062] Concretizações da invenção serão agora descritas, apenas a título de exemplo, com referência aos desenhos anexos nos quais: A Figura 1 é um diagrama de blocos de uma concretização de um sistema de processamento de informações que serve como um nó em um ambiente de computação em nuvem e no qual os métodos descritos aqui também podem ser implementados de acordo com uma concretização preferida da invenção; A Figura 2 é uma concretização de uma extensão do ambiente do sistema de processamento de informações mostrado na Figura 1 para ilustrar que os métodos descritos aqui podem ser executados em uma grande variedade de sistemas de processamento de informações que operam em um ambiente em rede de acordo com uma concretização preferida de a invenção; A Figura 3 é um diagrama que representa uma concretização de um ambiente de computação em nuvem de acordo com uma concretização preferida da invenção; A Figura 4 é um diagrama que representa uma concretização de um conjunto de camadas de abstração funcionais fornecidas pelo ambiente de computação em nuvem de acordo com uma concretização preferida da invenção; A Figura 5 é um diagrama de uma concretização de modelos de topologia de origem e de destino e modelos de etapas de automação armazenados em uma biblioteca de recursos que são usados para transferir uma solução de uma plataforma de origem para uma de destino de acordo com uma concretização preferida da invenção; A Figura 6 é um fluxograma que mostra as etapas realizadas para usar as unidades modelo de topologia para encontrar semelhanças e diferenças entre os modelos de topologia de origem e de destino de modo a gerar fluxos de trabalho de implementação de acordo com uma concretização preferida da invenção; A Figura 7 é um diagrama que mostra uma concretização de modelos de etapa de automação usados para criar um fluxo de trabalho de implementação exemplar que é implementado em um ambiente de nuvem de acordo com uma concretização preferida da invenção; A Figura 8 é um fluxograma que mostra as etapas realizadas para criar um modelo de topologia de acordo com uma concretização preferida da invenção; A Figura 9 é um fluxograma que mostra as etapas realizadas para criar modelos de etapa de automação de acordo com uma concretização preferida da invenção; A Figura 10 é um fluxograma que mostra as etapas realizadas para especificar parâmetros de entrada e armazenar no modelo de topologia de acordo com uma concretização preferida da invenção; A Figura 11 é um fluxograma que mostra as etapas realizadas para especificar e implementar completamente uma cópia em execução do aplicativo com base em nuvem de acordo com uma concretização preferida da invenção; A Figura 12 é um fluxograma que mostra as etapas realizadas para reutilizar recursos armazenados na biblioteca de recursos e implementar a solução a um ambiente de nuvem de destino usando os recursos reutilizados de acordo com uma concretização preferida da invenção; A Figura 13 é um fluxograma que mostra as etapas realizadas para encontrar unidades de topologia existentes que correspondem a uma solicitação, substituir unidades modelo específicas em nuvem e armazenar unidades modelo novas e alteradas na biblioteca de recursos de acordo com uma concretização preferida da invenção; A Figura 14 é um fluxograma que mostra as etapas realizadas para gerar um modelo de fluxo de trabalho de implementação de acordo com uma concretização preferida da invenção; A Figura 15 é um fluxograma que mostra as etapas realizadas para gerar um fluxo de trabalho de implementação a partir do modelo e implementar usando um mecanismo de implementação de acordo com uma concretização preferida da invenção; e A Figura 16 é um fluxograma que mostra as etapas realizadas para gerar um fluxo de trabalho de implementação a partir do modelo e implementar uma solução compósita em múltiplos ambientes com base em nuvem de acordo com uma concretização preferida da invenção.

Descrição Detalhada da Invenção

[0063] Por conveniência, a Descrição Detalhada possui as seguintes seções: Seção 1: Definições de Computação em Nuvem e Seção 2: Implementação Detalhada.

Seção 1: Definições de Computação em Nuvem

[0064] Muitas das seguintes definições foram derivadas do "Draft NIST Working Definition of Cloud Computing" de Peter Mell e Tim Grance, datado de 7 de outubro de 2009.

[0065] A computação em nuvem é um modelo para permitir acesso de rede conveniente e sob demanda a um pool compartilhado de recursos de computação configuráveis (por exemplo, redes, servidores, memória, aplicativos e serviços) que podem ser rapidamente provisionados e liberados com o mínimo de esforço de gerenciamento ou interação com provedor de serviços. Este modelo de nuvem promove a disponibilidade e é compreendido de pelo menos cinco características, pelo menos três modelos de serviço e pelo menos quatro modelos de implementação.

[0066] As características são as seguintes: Autoatendimento sob demanda: um consumidor pode fornecer recursos unilaterais de computação, como tempo de servidor e memória de rede, conforme necessário automaticamente, sem necessidade de interação humana com cada provedor de serviços. Acesso amplo de rede: as capacidades estão disponíveis através de uma rede e acessadas através de mecanismos padrão que promovem o uso por plataformas de cliente leves ou pesadas heterogêneas (por exemplo, telefones celulares, laptops e PDAs). Compartilhamento de recursos: os recursos de computação do provedor são agrupados para atender a múltiplos consumidores usando um modelo "multi-tenant", com diferentes recursos físicos e virtuais atribuídos e reatribuídos dinamicamente de acordo com a demanda do consumidor. Há uma sensação de independência de localização na medida em que o cliente geralmente não tem controle ou conhecimento sobre a localização exata dos recursos fornecidos, mas pode especificar a localização em um nível de abstração mais alto (por exemplo, país, Estado ou datacenter). Exemplos de recursos incluem memória, processamento, memória, largura de banda de rede e máquinas virtuais. Flexibilidade rápida: as capacidades podem ser rápida e flexivelmente provisionadas, em alguns casos automaticamente, para dimensionar prontamente, e liberadas rapidamente para dimensionar rapidamente. Para o consumidor, as capacidades disponíveis para provimento muitas vezes parecem ser ilimitadas e podem ser adquiridas em qualquer quantidade a qualquer momento. Serviço medido: os sistemas em nuvem controlam e otimizam o uso de recursos, alavancando uma capacidade de medição em algum nível de abstração apropriado ao tipo de serviço (por exemplo, armazenamento, processamento, largura de banda e contas de usuários ativas). O uso de recursos pode ser monitorado, controlado e relatado, fornecendo transparência tanto para o provedor quanto para o consumidor do serviço usado.

[0067] Modelos de serviço são os seguintes: Software de Nuvem Como Um Serviço (Cloud Software as a Service - SaaS): a capacidade fornecida ao consumidor é para usar os aplicativos do provedor em execução em uma infraestrutura da nuvem. Os aplicativos são acessíveis a partir de vários dispositivos cliente através de uma interface de cliente leve, como um navegador da Web (por exemplo, e-mail com base na web). O consumidor não gerencia ou controla a infraestrutura da nuvem subjacente, incluindo rede, servidores, sistemas operacionais, memória ou mesmo recursos de aplicativos individuais, com a possível exceção de definições de configuração de aplicativos específicas para usuário limitadas. Plataforma de Nuvem Como Um Serviço (Cloud Platform as a Service - PaaS): a capacidade fornecida ao consumidor é para implementar na infraestrutura da nuvem aplicativos criados pelo consumidor ou adquiridos usando linguagens de programação e ferramentas suportadas pelo provedor. O consumidor não gerencia ou controla a infraestrutura da nuvem subjacente, incluindo redes, servidores, sistemas operacionais ou memória, mas tem controle sobre os aplicativos implementados e, possivelmente, configurações de ambiente de hospedagem de aplicativos. Infraestrutura de Nuvem Como Um Serviço (Cloud Infrastructure as a Service - IaaS): a capacidade fornecida ao consumidor é para provisionar processamento, memória, redes e outros recursos de computação fundamentais, onde o consumidor pode implementar e executar software arbitrário, o qual pode incluir sistemas operacionais e aplicativos. O consumidor não gerencia nem controla a infraestrutura de nuvem subjacente, mas tem controle sobre sistemas operacionais, memória, aplicativos implementados e possivelmente controle limitado de componentes de rede selecionados (por exemplo, firewalls do host).

[0068] Modelos de implementação são os seguintes: Nuvem Privada: A infraestrutura de nuvem é operada exclusivamente para uma organização. Pode ser gerida pela organização ou por terceiros e pode existir no local ou fora do local. Ela tem mecanismos de segurança no local. Um exemplo de um mecanismo de segurança que pode ser posto em prática é um firewall. Outro exemplo de um mecanismo de segurança que pode ser posto em prática é uma rede privada virtual (Virtual Private Network- VPN). Nuvem Comunitária: A infraestrutura de nuvem é compartilhada por várias organizações e dá suporte a uma comunidade específica que tem preocupações em comum (por exemplo, missão, requisitos de segurança, política e considerações de cumprimento). Pode ser gerida pelas organizações ou por terceiros e pode existir no local ou fora do local. Nuvem Pública: A infraestrutura de nuvem é disponibilizada ao público em geral ou um grupo de grande indústria e é propriedade de uma organização que vende serviços em nuvem. Nuvem Híbrida: A infraestrutura de nuvem é uma composição de duas ou mais nuvens (privada, comunitária ou pública) que permanecem entidades únicas, mas são unidas por tecnologia padronizada ou proprietária que permite portabilidade de dados e aplicativos (por exemplo, estouro de nuvem para balanceamento de carga entre nuvens).

[0069] Um ambiente de computação em nuvem é orientado a serviços com foco em ausência de Estado, baixo acoplamento, modularidade e interoperabilidade semântica.

[0070] Uma imagem virtual representa uma máquina virtual em um sistema de arquivos e pode incluir parâmetros de configuração conforme necessário para executá-lo como uma máquina virtual. A imagem virtual pode ser executada por um componente de software denominado hipervisor que pode estar localizado em uma máquina física e pode suplementar um sistema operacional da máquina física. A imagem virtual também pode ser denominada uma imagem de máquina ou uma imagem de máquina virtual.

[0071] Uma máquina virtual é uma implementação de software de uma máquina que executa programas como uma máquina física.

[0072] Uma "imagem" é o estado de um sistema de computador e o software em execução no sistema de computador. Em um sistema de hipervisor, a imagem pode ser uma "imagem virtual" porque o hipervisor controla o acesso ao hardware do sistema de computador e, a partir da perspectiva de um sistema operacional convidado ou partição, ele aparece como se o sistema operacional convidado/partição controlasse todo o sistema de computador quando, na verdade, é o hipervisor que realmente controla o acesso aos componentes de hardware de computador e gerencia o compartilhamento dos recursos de hardware do computador entre várias partições (por exemplo, sistemas operacionais convidados, etc.).

Seção 2: Implementação Detalhada

[0073] Conforme será apreciado por aqueles versados na técnica, a implementação detalhada pode ser concretizada como um sistema, método ou produto de programa de computador. Consequentemente, as concretizações podem ter a forma de uma concretização de inteiramente de hardware, uma concretização inteiramente de software (incluindo firmware, software residente, microcódigo, etc.) ou uma concretização que combina os aspectos de software e hardware que podem todos ser geralmente ditos aqui como um "circuito", "módulo" ou "sistema". Além disso, as concretizações podem ter a forma de um produto de programa de computador incorporado em um ou mais meios legíveis em computador que têm o código de programa legível em computador incorporado no mesmo.

[0074] Qualquer combinação de um ou mais meios legíveis em computador pode ser usada. O meio legível em computador pode ser um meio de sinal legível em computador ou um meio de armazenamento legível em computador. Um meio de armazenamento legível em computador pode ser, por exemplo, porém sem limitações, um sistema eletrônico, magnético, óptico, eletromagnético, infravermelho ou semicondutores, um aparelho ou dispositivo ou qualquer combinação adequada dos anteriores. Exemplos mais específicos (uma lista não exaustiva) do meio de armazenamento legível em computador incluem o seguinte: uma conexão elétrica que tem um ou mais fios, uma disquete de computador portátil, um disco rígido, uma memória de acesso aleatório (Random Access Memory - RAM), uma memória somente de leitura (Read-Only Memory - ROM), uma memória somente de leitura programável e apagável (Erasable Programmable Read-Only Memory - EPROM ou memória "flash"), uma fibra óptica, um disco compacto, memória somente de leitura em disco portátil (Compact Disc Read-Only Memory - CD-ROM), um dispositivo de armazenamento óptico, um dispositivo de armazenamento magnético ou qualquer combinação adequada dos anteriores. No contexto do presente documento, um meio de armazenamento legível em computador pode ser qualquer meio tangível que possa conter ou armazenar um programa para uso por ou em conexão com um sistema, aparelho ou dispositivo de execução de instrução.

[0075] Um meio de sinal legível em computador pode incluir um sinal de dados propagado com um código de programa de computador incorporado no mesmo, por exemplo, na banda de base ou como parte de uma onda portadora. Tal sinal propagado pode tomar qualquer de uma variedade de formas incluindo, porém sem limitações, eletromagnético, óptico ou qualquer um combinação adequada dos mesmos. Um meio de sinal legível em computador pode ser qualquer meio legível em computador que não seja um meio de armazenamento legível em computador e que possa se comunicar, propagar ou transferir um programa para uso por ou em conexão com um sistema, aparelho ou dispositivo de execução de instrução.

[0076] O código de programa incorporado em um meio legível em computador pode ser transmitido usando qualquer meio apropriado incluindo, porém sem limitações, dispositivos sem fio, cabos, cabos de fibra óptica, RF, etc., ou qualquer combinação adequada dos anteriores.

[0077] O código de programa de computador para execução de operações pode ser escrito em qualquer combinação de uma ou mais linguagens de programação, incluindo uma linguagem de programação orientada a objeto, tal como Java, Smalltalk, C++ ou similar e linguagens de programação procedurais convencionais, tais como a linguagem de programação "C" ou linguagens de programação similares. O código de programa pode ser inteiramente executado no computador do usuário, em parte no computador do usuário, como um pacote de software autônomo, em parte no computador do usuário e em parte em um computador remoto ou inteiramente no computador remoto ou servidor. Neste último cenário, o computador remoto pode estar conectado ao computador do usuário através de qualquer tipo de rede, incluindo uma rede de área local (Local Area Network- LAN) ou uma rede de longa distância (Wide Area Network- WAN), ou a conexão pode ser feita a um computador externo (por exemplo, através da Internet usando um Provedor de Serviços da Internet).

[0078] São descritas abaixo concretizações com referência a ilustrações de fluxograma e/ou diagramas de blocos de métodos, aparelhos (sistemas) e produtos de programa de computador. Será entendido que cada bloco das ilustrações de fluxograma e/ou diagramas de blocos e combinações de blocos nas ilustrações de fluxograma e/ou diagramas de blocos podem ser implementados por instruções de programa de computador. Estas instruções de programa de computador podem ser fornecidas a um processador de um computador de uso geral, computador de aplicação específica ou outro aparelho de processamento de dados programável para produzir uma máquina, de modo que as instruções, as quais são executadas através do processador do computador ou outro aparelho de processamento de dados programável, criem meios para implementar as funções/atos especificados no fluxograma e/ou bloco ou blocos do diagrama de blocos.

[0079] Estas instruções de programa de computador também podem ser armazenadas em um meio legível em computador que pode controlar um computador, outro aparelho de processamento de dados programável ou outros dispositivos para funcionar de uma forma particular, de modo que as instruções armazenadas no meio legível em computador produzam um artigo de manufatura que inclui instruções que implementam a função/ato especificado no fluxograma e/ou bloco ou blocos do diagrama de blocos.

[0080] As instruções de programa de computador (material descritivo funcional) também podem ser carregadas em um computador, outro aparelho de processamento de dados programável ou outros dispositivos para fazer com que uma série de etapas operacionais sejam executadas no computador, outro aparelho programável ou outros dispositivos para produzir um processo implementado em computador, de modo que as instruções as quais são executadas no computador ou outro aparelho programável forneçam processos para implementação das funções/atos especificados no fluxograma e/ou bloco ou blocos do diagrama de blocos.

[0081] Determinados detalhes específicos são expostos na descrição a seguir e figuras para fornecer um entendimento exaustivo de várias concretizações. Determinados detalhes bem conhecidos, muitas vezes associados à computação e tecnologia de software, não são apresentados na descrição a seguir, no entanto, para evitar obscurecer desnecessariamente as várias concretizações. Além disso, aqueles versados na técnica relevante entenderão que podem praticar outras concretizações sem um ou mais dos detalhes descritos abaixo. Finalmente, embora vários métodos sejam descritos com referência a etapas e sequências na descrição a seguir, a descrição como tal é para fornecer uma implementação clara das concretizações e as etapas e sequências de etapas não devem ser tomadas como necessárias para a prática das concretizações. Em vez disso, o seguinte se destina a fornecer uma descrição detalhada de uma ou mais concretizações e não deve ser tomado como sendo limitativo, em vez disso, qualquer número de variações podem cair dentro do âmbito que é definido pelas reivindicações que seguem a descrição detalhada.

[0082] A descrição detalhada a seguir, em geral, acompanhará o sumário, conforme apresentado acima, explicando e expandindo ainda mais as definições dos vários aspectos e concretizações, conforme necessário. Para esta finalidade, a presente descrição detalhada apresenta primeiro um exemplo de um ambiente de computação na Figura 1 que é adequado para implementar as técnicas de software e/ou hardware associadas a uma concretização. Uma concretização de um ambiente de rede é ilustrada na Figura 2 como uma extensão do ambiente de computação básico para enfatizar as técnicas de computação por modem que podem ser executadas em vários dispositivos distintos.

[0083] Em referência agora à Figura 1, é mostrada uma representação esquemática de uma concretização de um sistema de processamento de informações que pode servir como um nó de computação em nuvem. O nó de computação em nuvem 10 é apenas um exemplo de um nó de computação em nuvem adequado e não se destina a sugerir qualquer limitação em relação ao escopo de uso ou funcionalidade descrita aqui. Todavia, o nó de computação em nuvem 10 é capaz de ser implementado e/ou executar qualquer das funções apresentadas na seção I acima.

[0084] No nó de computação em nuvem 10 há um sistema de computador/servidor 12, o qual é operacional com numerosos outros ambientes ou configurações de sistema de computação de uso geral ou aplicação específica. Exemplos de sistemas, ambientes e/ou configurações de computação conhecidos que podem ser adequados para uso com o sistema de computador/servidor 12 incluem, porém sem limitações, sistemas de computador pessoal e sistemas de computador de servidores, clientes leves, clientes pesados, dispositivos portáteis ou computadores portáteis, sistemas de multiprocessadores, sistemas com base em microprocessadores, set top boxes, dispositivos eletrônicos de consumo programáveis, PCs em rede, sistemas de minicomputador, sistemas de computadores "mainframe"e ambientes de computação em nuvem distribuídos que incluem qualquer um dos sistemas ou dispositivos acima e assim por diante.

[0085] O sistema de computador/servidor 12 pode ser descrito no contexto geral de instruções executáveis em sistema de computador, tais como módulos de programa, que estão sendo executadas por um sistema de computador. Em geral, os módulos de programa incluem rotinas, programas, objetos, componentes, lógica, estruturas de dados e assim por diante que executam tarefas particulares ou implementam determinados tipos de dados abstratos. O sistema de computador/servidor 12 pode ser praticado em ambientes de computação em nuvem distribuídos onde as tarefas são executadas por dispositivos de processamento remoto que estão ligados através de uma rede de comunicações. Em um ambiente de computação em nuvem distribuído, os módulos de programa podem estar localizados em meios de armazenamento de sistema de computador local e remoto, incluindo dispositivos de armazenamento de memória.

[0086] Conforme mostrado na Figura 1, o sistema de computador/servidor 12 no nó de computação em nuvem 10 é mostrado na forma de um dispositivo de computação de uso geral. Os componentes do sistema de computador/servidor 12 podem incluir, porém sem limitações, um ou mais processadores ou unidades de processamento 16, uma memória de sistema 28 e um barramento 18 que acopla vários componentes do sistema, incluindo a memória de sistema 28 ao processador 16.

[0087] O barramento 18 representa um ou mais de qualquer um dos vários tipos de estruturas de barramento, incluindo um barramento de memória ou um controlador de memória, um barramento periférico, uma porta de acelerador gráfico e um processador ou barramento local que usa qualquer uma de uma variedade de arquiteturas de barramento. A título de exemplo e não limitação, tais arquiteturas incluem barramento Industry Standard Architecture(ISA), barramento Micro Channel Architecture(MCA), barramento Enhanced ISA (EISA), barramento local Video Electronics Standards Association(VESA) e barramento Peripheral Component Interconnects(PCI).

[0088] O sistema de computador/servidor 12 inclui, tipicamente, uma variedade de meios legíveis no sistema de computador. Tais meios podem ser qualquer meio disponível que é acessível por sistema de computador/servidor 12 e inclui tanto meios voláteis como não voláteis, meios removíveis e não removíveis.

[0089] A memória de sistema 28 pode incluir meios legíveis em sistema de computador na forma de memória volátil, tal como a memória de acesso aleatório (RAM) 30 e/ou memória cache 32. O sistema de computador/servidor 12 pode incluir ainda outros meios de armazenamento em sistema de computador removíveis/não removíveis, voláteis/não voláteis. A título de exemplo, uma unidade de disco rígido 34 pode ser fornecida para leitura e gravação para um meio magnético não removível, não volátil (não mostrado e tipicamente denominado "disco rígido"). Embora não seja mostrado, uma unidade de disco magnético para leitura e gravação em um disco magnético removível não volátil (por exemplo, um "disquete") e uma unidade de disco óptico para leitura ou gravação em um disco óptico removível não volátil, tal como um CD-ROM, DVD-ROM ou outro meio óptico, pode ser fornecido. Em tais casos, cada um pode ser conectado ao barramento 18 através de uma ou mais interfaces de meios de dados. Conforme será adicionalmente ilustrado e descrito abaixo, a memória 28 pode incluir pelo menos um produto de programa que tem um conjunto (por exemplo, pelo menos um) de módulos de programa que são configurados para desempenhar as funções descritas aqui.

[0090] O programa/utilitário 40 que tem um conjunto (pelo menos um) de módulos de programa 42 pode ser armazenado na memória 28, a título de exemplo e não como limitação, bem como um sistema operacional, um ou mais programas de aplicativos, outros módulos de programa e dados de programa. Cada um do sistema operacional, um ou mais programas de aplicativos, outros módulos de programa e dados de programa ou alguma combinação dos mesmos pode incluir uma implementação de um ambiente de rede. Os módulos de programa 42 geralmente executam as funções e/ou metodologias conforme descrito aqui.

[0091] O sistema de computador/servidor 12 também pode se comunicar com um ou mais dispositivos externos 14, tais como um teclado, um dispositivo ponteiro, um monitor 24, etc.; um ou mais dispositivos que permitem ao usuário interagir com o sistema de computador/servidor 12; e/ou quaisquer dispositivos (por exemplo, placa de rede, modem, etc.) que permitam que o sistema de computador/servidor 12 se comunique com um ou mais de outros dispositivos de computação. Tal comunicação pode ocorrer por meio de interfaces E/S 22. Além disso, o sistema de computador/servidor 12 pode se comunicar com uma ou mais redes, tal como uma rede local (LAN), uma rede de área ampla geral (WAN) e/ou uma rede pública (por exemplo, a Internet) através do adaptador de rede 20. Conforme representado, o adaptador de rede 20 se comunica com os outros componentes do sistema de computador/servidor 12 através do barramento 18. Deverá ser entendido que, embora não mostrado, outros componentes de hardware e/ou software podem ser usados juntamente com o sistema de computador/servidor 12. Exemplos incluem, porém sem limitações: microcódigo, drivers de dispositivo, unidades de processamento redundantes, arranjos de disco rígido externo, sistemas RAID, drivers de fita e sistemas de armazenamento de arquivo de dados, etc.

[0092] A Figura 2 fornece uma extensão do ambiente do sistema de processamento de informações mostrado na Figura 1 para ilustrar que os métodos descritos aqui podem ser executados em uma ampla variedade de sistemas de processamento de informações que operam em um ambiente de rede de acordo com uma concretização. Os tipos de sistemas de processamento de informações variam de pequenos dispositivos portáteis, tal como um computador portátil/telefone móvel 210 a grandes sistemas "mainframe", tal como um computador "mainframe"270. Exemplos de computador portátil 210 incluem assistentes pessoais digitais (Personal Digital Assistants- PDAs), dispositivos de entretenimento pessoal, tais como MP3 players, televisores portáteis e leitores de discos compactos. Outros exemplos de sistemas de processamento de informações incluem caneta, ou tablet, computador 220, laptop ou notebook, computador 230, estação de trabalho 240, sistema de computador pessoal 250 e servidor 260. Outros tipos de sistemas de processamento de informações que não são mostrados individualmente na Figura 2 são representados pelo sistema de processamento de informações 280. Conforme mostrado, os vários sistemas de processamento de informações podem ser conectados em rede usando a rede de computadores 200. Os tipos de rede de computadores que podem ser usados para interligar os vários sistemas de processamento de informações incluem Redes de Área Local (Local Area Networks - LANs), Redes de Área Local Sem Fio (Wireless Local Area Networks - WLANs), a Internet, a Rede pública de telefonia comutada (Public Switched Telephone Network- PSTN), outras redes sem fio e qualquer outra topologia de rede que possa ser usada para interligar sistemas de processamento de informações. Muitos dos sistemas de processamento de informações incluem memória de dados não voláteis, tais como unidades de disco rígido e/ou memória não volátil. Muitos dos sistemas de processamento de informações mostrados na Figura 2 descrevem memórias de dados não voláteis separadas (o servidor 260 usa memória de dados não volátil 265, o computador de "mainframe"270 usa memória de dados não volátil 275 e o sistema de processamento de informações 280 usa memória de dados não volátil 285).

[0093] A memória de dados não volátil pode ser um componente que é externo aos vários sistemas de processamento de informações ou pode ser interna a um dos sistemas de processamento de informações. Além disso, o dispositivo de memória removível não volátil 145 pode ser compartilhado entre dois ou mais sistemas de processamento de informações usando várias técnicas, tal como conexão do dispositivo de memória não volátil removível 145 a uma porta USB ou outro conector dos sistemas de processamento de informações. Além disso, a rede de computadores 200 pode ser usada para conectar vários sistemas de processamento de informações a ambientes de computação em nuvem 201 que incluem o ambiente de computação em nuvem 205 e qualquer variedade de outros ambientes de computação em nuvem. Conforme descrito nas Figuras 3 e 4, um ambiente de computação em nuvem 300 compreende uma série de sistemas de processamento de informações em rede (nós) que funcionam juntos para fornecer o ambiente de computação em nuvem. Os ambientes de computação em nuvem 201 fornecem, cada um, camadas de abstração mostradas na Figura 4. Uma camada de abstração compreende uma camada de hardware e software 400, uma camada de virtualização 410, uma camada de gestão 420 e uma camada de volume de trabalho 430. Os componentes dentro das várias camadas 400-430 podem variar de um ambiente de nuvem para outro. Um exemplo de componentes encontrados dentro das várias camadas é mostrado na Figura 4.

[0094] Em referência agora à Figura 3, um ambiente de computação em nuvem 201 ilustrativo está representado. Conforme mostrado, o ambiente de computação em nuvem 201 compreende um ou mais nós de computação em nuvem 10 com os quais dispositivos de computação tais como, por exemplo, um assistente pessoal digital (PDA) ou um telefone celular 210, computador laptop 250, computador portátil 290, sistema de computador automotivo 230 e outros tipos de dispositivos de cliente mostrados na Figura 2 se comunicam. Isto permite que a infraestrutura, plataformas e/ou software sejam oferecidos como serviços (conforme descrito acima na Seção 1) a partir do ambiente de computação em nuvem 201 de modo a não exigir que cada cliente mantenha separadamente tais recursos. Deverá ser entendido que os tipos de dispositivos de computação mostrados nas Figuras 2 e 3 se destinam a ser apenas ilustrativos e que o ambiente de computação em nuvem 201 pode se comunicar com qualquer tipo de dispositivo computadorizado através de qualquer tipo de rede e/ou conexão de rede/endereçável (por exemplo, usando um navegador da web).

[0095] Conforme os inventores aqui reconheceram, imagens virtuais de origem e destino para diferentes provedores de nuvem (ou hipervisor) podem ter arquiteturas de hardware, tecnologias de hipervisor, tipos e/ou versões de sistema operacional e/ou middleware convidado incompatíveis. As partições de disco em uma imagem virtual podem ser específicas para um provedor de nuvem (ou hipervisor). A cópia direta de conteúdos com personalizações secundárias pode não funcionar. Por exemplo, Amazon EC2 dá suporte a imagens virtuais XEN para hardware x86, enquanto que uma nuvem da IBM com servidores da série P dão suporte apenas a imagens de sistema P.

[0096] Os presentes inventores também reconheceram que, em algumas situações, configurações específicas de nuvem (ou hipervisor), tais como firewalls e volumes de armazenamento em bloco, não podem ser adicionadas à solução de portabilidade em virtude de diferenças de API. Por exemplo, Amazon EC2 oferece opções de configuração para fixação de volumes de armazenamento em bloco para as cópias em execução, mas uma nuvem privada com base em VMware pode não fornecer esta opção.

[0097] Os presentes inventores também reconheceram que as soluções que incluem várias imagens virtuais podem precisar ser apenas parcialmente transferidas para uma nuvem diferente (ou hipervisor). Por exemplo, uma solução com uma camada de lógica de negócios em uma imagem virtual e uma camada de banco de dados em outra imagem virtual pode requerer que apenas a imagem virtual da camada de lógica de negócios seja transferida para uma nuvem pública e a imagem virtual da camada de banco de dados permaneça em uma nuvem privada em virtude de questões de privacidade de dados. No entanto, os inventores também reconheceram que, em algumas situações, pode ser desejável transferir uma solução inteira para uma nuvem diferente (ou hipervisor).

[0098] Os presentes inventores também reconheceram que pode ser desejável identificar e/ou visualizar componentes/configurações de solução alterados, adicionados e/ou eliminados e operações de implementação alteradas, adicionadas e/ou eliminadas correspondentes em um fluxo de trabalho de provimento quanto de portabilidade para uma nuvem diferente (ou hipervisor). Os inventores também reconheceram que pode ser desejável armazenar estas modificações, adições e/ou eliminações em um patch para o modelo de origem. Por exemplo, transferir um aplicativo WebSphere de uma nuvem privada com base em VMware para Amazon EC2 requer alteração da imagem VMware de base para uma Amazon Machine Image (AMI) de base com operações WebSphere e alteradas para implementação em uma imagem AMI, em vez de uma imagem VMware.

[0099] Conforme os presentes inventores reconheceram também, pode ser desejável a provisão de soluções para múltiplas nuvens. Por exemplo, Amazon EC2 e IBM Development at Test Cloud oferecem ambos APIs para copiar uma imagem e conectar remotamente à máquina virtual em execução de forma segura e executar tarefas de solução de provimento remotamente.

[0100] Em referência agora à Figura 4, é mostrada uma concretização de um conjunto de camadas de abstração funcionais 400 fornecidas pelo ambiente de computação em nuvem 201 (Figura 3). Deverá ser entendido antecipadamente que os componentes, camadas e funções mostrados na Figura 4 se destinam a ser apenas ilustrativos e as concretizações não se limitam aos mesmos. Conforme representado, as camadas e funções correspondentes a seguir são fornecidas: - a camada de hardware e software 410 inclui componentes de hardware e software. Exemplos de componentes de hardware incluem "mainframes", em um exemplo, sistemas IBM® zSeries®; servidores com base na arquitetura RISC (Reduced Instruction Set Computer), em um exemplo sistemas IBM pSeries®; sistemas IBM xSeries®; sistemas IBM BladeCenter®; dispositivos de memória; redes e componentes de rede. Exemplos de componentes de software incluem software de servidor de aplicativos de rede, em um exemplo, software de servidor de aplicativos IBM WebSphere®; e software de banco de dados, em um exemplo, software de banco de dados IBM DB2®. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere e DB2 são marcas registradas da International Business Machines Corporation nos Estados Unidos, em outros países ou em ambos); - a camada de virtualização 420 fornece uma camada de abstração a partir da qual podem ser fornecidas as seguintes entidades virtuais: servidores virtuais; memória virtual; redes virtuais, incluindo redes virtuais privadas; aplicativos virtuais; e clientes virtuais; - a camada de gestão 430 fornece as funções descritas a seguir. Provimento de recursos permite a aquisição dinâmica de recursos de computação e outros recursos que são usados para executar tarefas dentro do ambiente de computação em nuvem. Medição e preços permite controle de custos à medida que os recursos são usados dentro do ambiente de computação em nuvem e cobrança ou faturamento para o consumo destes recursos. Em um exemplo, estes recursos podem incluir licenças de software de aplicativo. Segurança permite a verificação de identidade para usuários e tarefas, bem como a proteção de dados e outros recursos. Portal do usuário permite acesso ao ambiente de computação em nuvem para usuários e administradores de sistema. Gestão de nível de serviço permite alocação e gestão de recursos de computação em nuvem, de modo que os níveis de serviço requeridos sejam cumpridos. Planejamento e realização de Contrato de Nível de Serviço (Service Level Agreement- SLA) permite a pré- configuração para, e aquisição de recursos de computação em nuvem para os quais um futuro requisito é antecipado de acordo com um SLA; - a camada de volume de trabalho 440 permite a funcionalidade para a qual o ambiente de computação em nuvem é usado. Exemplos de volumes e as funções que podem ser fornecidas a partir desta camada incluem: mapeamento e navegação; desenvolvimento de software e gestão de ciclo de vida; distribuição de educação em sala de aula virtual; análise de dados de processamento; e processamento de transações. Conforme mencionado acima, todos os exemplos anteriores descritos em relação à Figura 4 são apenas ilustrativos e não se limitam a estes exemplos.

[0101] A Figura 5 é um diagrama de uma concretização de modelos de topologia de origem e de destino e modelos de etapa de automação armazenados em uma biblioteca de recursos a ser usada para transferir uma solução de uma plataforma de origem para uma plataforma de destino. Em uma concretização, uma "solução" é uma solução que inclui um ou mais aplicativos de software que são executados por um ou mais sistemas de computadores com base em hardware que são usados para satisfazer determinados requisitos funcionais e não funcionais. Uma solução de software inclui um ou mais aplicativos de software, bem como seus parâmetros de configuração relacionados. Em uma concretização, uma solução é uma solução completa ("turn-key") e uma abordagem de uma interrupção ("one-stop"). A solução pode incluir múltiplos aplicativos e pode incluir informações de configuração afiliada aos aplicativos. Uma solução pode ser de natureza compósita pelo fato de que ela pode incluir várias imagens virtuais. Parte de uma solução pode estar em uma imagem virtual e outra parte da solução pode estar em outra imagem virtual. A biblioteca de recursos 500 é usada como um repositório de dados de topologia e automação. Dados de topologia descrevem componentes de soluções com base em nuvem e suas relações. A biblioteca de recursos 500 é usada para armazenar dados para qualquer número de modelos de topologia 510. Em uma concretização, a biblioteca de recursos 500 é armazenada em um meio de armazenamento persistente, tal como um dispositivo de memória não volátil, acessível a partir de um sistema de computador. Cada um dos modelos de topologia 510 descreve os dados usados em uma solução com base em nuvem. Quando de primeira implementação de uma solução com base em nuvem (a "topologia nuvem de destino") em um ambiente de nuvem particular (a "nuvem de destino"), os recursos armazenados na biblioteca de recursos 500 podem ser buscados para identificar uma topologia já armazenada na biblioteca de recursos (a "topologia de nuvem de origem") que pode ser usada para desenvolver a topologia de nuvem de destino ao reutilizar várias unidades modelo de topologia de nuvem de origem. Em uma concretização, isto ocorre quando se transfere uma solução da nuvem de origem (por exemplo, uma nuvem fornecida por um primeiro provedor de nuvem) para a nuvem de destino (por exemplo, uma nuvem fornecida por um segundo provedor de nuvem).

[0102] Uma concretização de uma plataforma de origem seria uma nuvem (por exemplo, nuvem Amazon EC2™), onde uma solução tenha sido implementada. Uma concretização de uma plataforma de destino pode ser outra nuvem (por exemplo, nuvem IBM Smart Business Development and Test) para que a solução está sendo transferida. Uma concretização de uma plataforma de origem pode ser um hipervisor (por exemplo, hipervisor VMware) e uma concretização da plataforma de destino correspondente poderia ser outro hipervisor (por exemplo, hipervisor KVM). Uma concretização de uma plataforma de origem pode ser um sistema de computador físico com partições de disco (por exemplo, servidores IBM pSeries) e uma concretização da plataforma de destino correspondente poderia ser outro sistema de computador físico (por exemplo, servidor Sun Microsystems). Além disso, as plataformas podem ser misturadas e combinadas. Por exemplo, uma concretização de uma plataforma de origem pode ser um hipervisor e uma concretização da plataforma de destino correspondente poderia ser uma nuvem.

[0103] Embora unidades modelo que correspondem a numerosos modelos de topologia possam ser armazenadas na biblioteca de recursos 500, duas são mostradas na Figura 5 - unidades modelo de topologia de nuvem de origem 520 e unidades modelo de topologia de nuvem de destino 560. Ambos os modelos de topologia de nuvem de origem e de destino incluem várias unidades modelos, tais como metadados (522 e 562, respectivamente), credenciais e dados de endpoints de serviços (524 e 564, respectivamente) e os parâmetros de configuração (526 e 566, respectivamente). As unidades modelos podem ser usadas para representar aplicativos, middleware, sistemas operacionais convidados, imagens virtuais, parâmetros de configuração e outros componentes da solução. Cada unidade modelo pode incluir metadados, tal como tipo de imagem virtual, ID, parâmetros de configuração, versões de software, credenciais de acesso, regras de firewall, etc. Os metadados para os respectivos modelos de topologia incluem uma série de itens de metadados, tais como os parâmetros de distribuição de imagem virtual, metadados sobre o software incluído na topologia, metadados sobre o middleware incluído na topologia e metadados sobre o sistema operacional convidado incluído na topologia.

[0104] Conforme mostrado, os modelos de etapa de automação 515 também são armazenados na biblioteca de recursos 500 e estão associados a unidades modelo de topologia. Como o nome indica, os modelos de etapa de automação descrevem as etapas de automação usadas para implementar as várias unidades modelos de topologia incluídas na topologia. O modelo de etapa de automação de nuvem de origem 530 inclui as etapas de automação usadas para implementar unidades modelos de topologia na nuvem de origem 520, enquanto que o modelo de etapa de automação de nuvem de destino 570 inclui as etapas de automação usadas para implementar a unidades modelos de topologia de nuvem de destino 560. Quando do desenvolvimento das unidades modelos de topologia de nuvem de destino 560 e modelo de etapa de automação de nuvem de destino 570, as diferenças entre as unidades modelos de topologia de nuvem de origem 520 e as unidades modelos de topologia de nuvem de destino são identificados juntamente com novas unidades modelos que existem na topologia de destino, mas não na topologia de origem.

[0105] Além disso, as diferenças incluem unidades modelos removidas que existem na topologia de origem, mas não na topologia de destino. A biblioteca de recursos 500 é pesquisa a fim de encontrar modelos de etapa de automação para as unidades modelos novas e diferentes identificadas no modelo de topologia de destino. As diferenças podem ser armazenadas na biblioteca de recursos 500 como um patch e podem ser aplicadas a um modelo de topologia de origem similar para criar um modelo de topologia de destino. Um ou mais processadores podem ser usados para executar uma diferenciação entre o modelo de topologia de origem que está associado a uma plataforma de origem (por exemplo, nuvem de origem, hipervisor de origem, etc.) e uma topologia de destino que está associada a uma plataforma de destino (por exemplo, nuvem de destino, hipervisor de destino, etc.). Um modelo de topologia inclui unidades modelos de topologia.

[0106] As unidades modelos de topologia podem incluir parâmetros ou atributos de unidade e também podem incluir um tipo. O tipo pode ser, por exemplo, uma imagem virtual, middleware, sistema operacional, firewall ou qualquer outro tipo conhecido na técnica. Um hipervisor é um software que pode ser executado em um sistema operacional. Um hipervisor pode ser executado subjacente a um sistema operacional. Um hipervisor pode permitir que os diferentes sistemas operacionais ou diferentes cópias de um único sistema operacional sejam executadas em um sistema ao mesmo tempo. Em outras palavras, um hipervisor pode permitir que um sistema host hospede várias máquinas convidadas. Esta diferenciação resulta em uma diferença de topologia que inclui unidades modelos novas, modificadas e removidas. A diferença de topologia pode ser um conjunto de unidades modelos de topologia que correspondem aos vários componentes da solução que são diferentes no modelo de topologia de destino em relação ao modelo de topologia de origem.

[0107] Pode ser necessário que o conjunto de unidades modelos de topologia seja modificado quando de transferência da solução de uma plataforma de origem para uma plataforma de destino. Um conjunto que inclui pelo menos uma operação em um modelo de fluxo de trabalho (por exemplo, um modelo de etapa de automação armazenado em modelos de etapa de automação 515) é obtido a partir de biblioteca de recursos 500. A operação em um modelo de fluxo de trabalho é um recurso que pode ser executado. Por exemplo, uma operação em um modelo de fluxo de trabalho pode ser usada para instalar um aplicativo sMash em um servidor de aplicativos sMash.

[0108] A título de outro exemplo, uma operação em um modelo de fluxo de trabalho pode ser usada para copiar uma imagem virtual. Cada operação está associada a uma das unidades modelo na diferença de topologia entre os modelos de topologia de origem e de destino. Em uma concretização, uma solução completa (por exemplo, a solução que está sendo transferida da topologia de origem para a topologia de destino) é implementada ao executar uma ou mais das operações obtidas usando um ou mais processadores. Em uma concretização, uma parte de uma solução é transferida da topologia de origem para a topologia de destino ao executar uma ou mais das operações obtidas usando um ou mais processadores. A parte implementada da solução inclui uma imagem de destino que é compatível com a plataforma de destino (por exemplo, nuvem de destino 590, um hipervisor de destino, etc.). Em uma concretização, a compatibilidade resulta de uma variedade de razões, tais como a tecnologia de hipervisor, arquitetura de hardware, versões do sistema operacional, versões de middleware, API's disponíveis em diferentes nuvens (tal como a configuração de firewalls e VPNs) e assim por diante. Em uma concretização, a incompatibilidade resulta de uma variedade das mesmas razões, onde um ou mais componentes, conforme discutido acima, são incompatíveis de uma plataforma de origem para uma plataforma de destino.

[0109] Conforme mostrado, o fluxo de trabalho de implementação de origem 575 opera de modo a implementar a solução na nuvem de origem 580. A implementação resulta em uma imagem virtual 582 sendo carregada na nuvem de origem e um aplicativo 550 implementado em uma cópia de imagem de middleware em execução. Da mesma forma, o fluxo de trabalho de implementação de destino 585 funciona para implementar a solução na nuvem de destino 590. A implementação resulta em uma imagem virtual 592 sendo carregada na nuvem de destino e o aplicativo 550 implementado em uma cópia de imagem de middleware em execução.

[0110] Deve ser observado que o aplicativo em comum 550 é implementado tanto na nuvem de origem 580 como na nuvem de destino 590. Em uma concretização, o aplicativo 550 é um aplicativo independente de plataforma, tal como um aplicativo escrito em uma linguagem de computador independente de plataforma, como a linguagem de programação Java, o qual é executado em uma "máquina virtual" que é dependente de plataforma. A imagem de destino pode ser identificada usando os metadados na unidade modelo de imagem virtual e suas unidades contidas no modelo de topologia de destino. Estes metadados podem ser usados como entrada para buscar metadados para todas as imagens virtuais conhecidas na nuvem de destino. Todos estes metadados podem ser armazenados na biblioteca de recursos. Uma imagem de destino pode ser identificada e implementada na plataforma de destino (nuvem), de modo que o aplicativo possa ser implementado na plataforma de destino ao executar a imagem de destino. Em uma concretização, a imagem de destino inclui o sistema operacional e o middleware (por exemplo, a máquina virtual) que fornece um ambiente de destino adequado para que o aplicativo funcione. Desta maneira, uma solução atualmente em execução na nuvem de origem e descrita no modelo de topologia de origem pode ser transferida e implementada na nuvem de destino com unidades modelo similares àquelas descritas no modelo de topologia de destino.

[0111] A Figura 6 é um fluxograma que mostra as etapas realizadas para usar unidades modelo de topologia para encontrar semelhanças e diferenças entre os modelos de topologia de origem e de destino de modo a gerar fluxos de trabalho de implementação de acordo com uma concretização.

[0112] As características em comum podem ser um conjunto de unidades modelo de topologia que correspondem aos vários componentes da solução que são os mesmos no modelo de topologia de destino em relação ao modelo de topologia de origem. Um exemplo de uma característica em comum pode ser que o tipo de imagem virtual representado em uma unidade modelo associada à plataforma de destino pode ser o mesmo que o tipo de imagem virtual representado em uma unidade modelo associada à plataforma de origem. As características em comum podem ser de natureza parcial, tal como quando o tipo é o mesmo para ambas as unidades modelos, mas algum outro parâmetro tal como, por exemplo, um identificador de imagem, é diferente na unidade modelo associada ao modelo de topologia de destino em comparação com a unidade modelo associada ao modelo de topologia de origem. As características em comum podem ser de natureza completa, tal como quando todos os parâmetros das duas unidades modelos de topologia são os mesmos e não há quaisquer parâmetros que sejam diferentes. Se as características em comum são de natureza completa, as operações de implementação associadas e os componentes da solução podem não precisar de ser modificados quando de transferência da solução da plataforma de origem para a plataforma de destino. Se as características em comum são de natureza parcial, estas podem ser tratadas como uma diferença ou podem ser tratadas como inteiramente em comum.

[0113] As diferenças podem ser um conjunto de unidades modelo de topologia que correspondem aos vários componentes da solução que são diferentes no modelo de topologia de destino em relação ao modelo de topologia de origem. Um exemplo de uma diferença pode ser que o tipo de imagem virtual representado em uma unidade modelo associada à plataforma de destino pode ser diferente do tipo de imagem virtual representado em uma unidade modelo associada à plataforma de origem. Se há uma diferença, pode ser necessário alterar as operações de implementação associadas e os componentes da solução quando de transferência da solução de uma plataforma de origem para uma plataforma de destino.

[0114] O processamento começa em 600 quando do que, na etapa 610, as unidades modelos de topologia de origem e modelos de topologia são criadas e armazenadas na biblioteca de recursos 500. Na etapa 620, um modelo de etapa de automação é criado para algumas unidades modelos de topologia que foram criadas para os modelos de topologia de origem na etapa 610 e estes modelos de automação também são armazenados na biblioteca de recursos 500. Na etapa 625, os modelos (topologia e automação) que foram criados nas etapas 610 e 620 são usados para gerar o fluxo de trabalho de implementação 628 para a nuvem de origem 580.

[0115] As etapas 630 e 640 são similares às etapas 610 e 620, no entanto, as etapas 630 e 640 são dirigidas a uma nuvem diferente (destino). Na etapa 630, as unidades modelos de topologia de destino e modelos de topologia são criados e armazenados na biblioteca de recursos 500. Estas unidades modelos de topologia de destino e modelos de topologia são concebidas para implementar a mesma solução implementada na nuvem de origem, no entanto, as unidades modelos de topologia de destino e modelos de topologia são concebidas para executar a solução em uma nuvem "de destino" diferente. Na etapa 640, um modelo de etapa de automação é criado para algumas das unidades modelo de topologia que foram criadas para os modelos de topologia de destino na etapa 630 e estes modelos de automação também são armazenados na biblioteca de recursos 500.

[0116] Na etapa 650, os modelos de topologia de origem e de destino são lidos a partir da biblioteca de recursos 500 e comparados para identificar as diferenças entre os modelos. Estas diferenças podem incluir unidades modificadas, novas ou removidas. As unidades modelos modificadas são aquelas unidades que existem em modelos de origem e de destino, mas que têm diferentes parâmetros ou subtipos, por exemplo, uma imagem virtual de um subtipo de topologia de origem é diferente de uma imagem virtual de um subtipo de topologia de destino. A diferença nos parâmetros pode incluir versões de middleware. As unidades modelos novas são aquelas unidades que não existiam na topologia de origem, mas foram adicionadas à topologia de destino (por exemplo, uma unidade modelo de topologia que não era necessária para implementar a solução na nuvem de origem, mas é necessária de modo a implementar a solução na nuvem de destino, etc.). As unidades modelos removidas são aquelas que estavam na topologia de origem, mas não estavam presentes na topologia de destino. Na etapa 660, a biblioteca de recursos 500 é pesquisada quanto a modelos de etapa de automação que correspondem às unidades modificadas e novas identificadas. Os modelos de etapa de automação encontrados na etapa 660 são modelos de etapa automação armazenados na biblioteca de recursos 500. Por exemplo, se uma unidade modelo nova ou modificada foi identificada, uma topologia diferente armazenada na biblioteca de recursos pode já existir a qual corresponde à unidade modelo nova ou modificada identificada. Além disso, quando uma unidade modelo é encontrada pela primeira vez, um modelo de etapa a automação pode ser desenvolvido para a unidade modelo encontrada e armazenado na biblioteca de recursos 500, de modo que ele será encontrado quando a etapa 660 ocorrer.

[0117] Na etapa 670, o fluxo de trabalho de implementação 675 na nuvem de destino 590 é gerado usando modelos de etapa de automação identificados na etapa 660 (para unidades modelo novas/modificadas) e algumas das etapas usadas para gerar o fluxo de trabalho de implementação na nuvem de origem na etapa 625 (para unidades modelo sem modificação). Deve ser observado que as operações de implementação para as unidades removidas são descartados do modelo de fluxo de trabalho de origem. Na etapa 680, a implementação fluxos de trabalho 675 e 628 é executada pelo mecanismo de implementação 690 resultando em uma cópia em execução 582 da solução na nuvem de origem 580 e cópia em execução 592 da solução na nuvem de destino 590. Em uma concretização, a execução do fluxo de trabalho de implementação é executada ao transmitir as operações incluídas no modelo de fluxo de trabalho para mecanismo de implementação 690.

[0118] O mecanismo de implementação 690 pode ser um processo de software no mesmo sistema de computador que executa a etapa de geração em 670 ou pode estar em um sistema de computador diferente conectado através de uma rede de computadores. Se o mesmo sistema de computador é usado, então, a operação pode ser transmitida usando uma operação interna (por exemplo, através de uma chamada de subrotina, ao executar um código em-linha que lida com as operações de implementação, através de uma chamada de programa externo, etc.). Se um sistema de computador diferente é usado, então, a operação pode ser transmitida para outro sistema de computador por meio de uma transmissão através de uma rede, tal como uma rede de computadores privada (por exemplo, LAN) e/ou uma rede pública (por exemplo, a Internet, rede de telefonia pública comutada (PSTN), etc.). Embora um mecanismo de implementação seja mostrado, diferentes mecanismos de implementação podem ser usados. Em uma concretização, os modelos de etapa de automação fornecem uma representação genérica das etapas usadas para automatizar a implementação das várias unidades modelos, enquanto que os fluxos de trabalho de implementação gerados (628 e 675) incluem um material funcional descritivo (por exemplo, scripts, etc.) concebidos para serem lidos e processados pelo mecanismo de implementação 690.

[0119] A Figura 7 é um diagrama que mostra uma concretização de modelos de etapa de automação usados para criar um fluxo de trabalho de implementação exemplar que é distribuído para um ambiente de nuvem. O modelo de topologia 700 inclui unidades modelos de topologia. Modelos de etapa de automação 710 correspondem a algumas das unidades modelos de topologia. O fluxo de trabalho de implementação 720 é gerado a partir de modelos de etapa de automação 710 e fornece uma série de operações para implementar a solução. A Figura 7 mostra um exemplo de uma solução híbrida que inclui uma nuvem de destino pública 760 e uma nuvem de destino privada 780. Um exemplo da função de nuvem de destino pública seria a operação "front-end" de cliente acessível ao público a partir de uma rede, tal como a Internet. Um exemplo da função de nuvem de destino privada seria a operação de servidor "back-end" que lida com operações de banco de dados e LDAP.

[0120] No exemplo mostrado, o fluxo de trabalho de implementação inclui as operações 725 a 750. A operação 725 copia uma imagem de máquina particular em nuvem de destino pública 760 e uma nuvem de destino privada 780. Isto resulta em uma imagem de máquina em nuvem com o OS host 7 68 sendo copiada em nuvem de destino pública 760. Em uma concretização, a operação 725 também copia a imagem de máquina em nuvem 782 na nuvem de destino privada 780 enquanto que, em uma concretização, uma imagem de máquina em nuvem 782 é um servidor de "back-end" em comum usado por várias nuvens de destino públicas. A imagem de máquina em nuvem 782 copiada e em execução na nuvem de destino privada 780 inclui um sistema operacional convidado 7 84 o qual pode ser um sistema operacional diferente do sistema operacional que está sendo executado na nuvem de destino pública. A imagem de máquina em nuvem 782 também pode incluir o servidor de banco de dados 786 (por exemplo, servidor de banco de dados IBM DB2™, etc.) sob o qual os aplicativos de banco de dados operam. A imagem de máquina em nuvem 782 também pode incluir o servidor LDAP (Lightweight Directory Access Protocol) 788 sob o qual aplicativos LDAP funcionam.

[0121] A operação 730 instala um aplicativo de middleware, tal como o aplicativo de middleware IBM Websphere® sMash™ na imagem copiada na nuvem de destino pública. Isto resulta em um servidor de aplicativos 772 que funciona na imagem de máquina em nuvem com OS convidado 768. Além disso, a operação 730 pode copiar o aplicativo independente de plataforma 774 que é executado no servidor de aplicativos. Conforme mostrado, a imagem de máquina em nuvem com OS convidado 768 inclui regras de tabela de IP e configuração de VPN 770 e a nuvem de destino pública inclui endereços de IP flexíveis da nuvem 762, grupos de segurança de nuvem 764 e armazenamento em bloco flexível da nuvem 766. Em um ambiente de nuvem, a operação 735 é executada para configurar endereços de IP flexíveis, resultando em uma configuração de endereços de IP flexível da nuvem 762. Neste ambiente de nuvem, a operação 740 é executada para configurar grupos de segurança da nuvem 764 e a operação 745 é executada para configurar a operação armazenamento em bloco flexível da nuvem 766. A operação 750 é executada para configurar VPNs (redes virtuais privadas). O resultado da operação 750 é uma atualização das regras de tabela de IP e configuração de VPN 770 que são executadas na imagem copiada 768, o que cria uma rede virtual privada entre a nuvem de destino pública 760 e a nuvem de destino privada 780.

[0122] A Figura 8 é um fluxograma que mostra as etapas realizadas para criar um modelo de topologia de acordo com uma concretização. O processamento começa em 800 após o que, na etapa 802, uma unidade de middleware é selecionada, tal como uma máquina virtual Java (por exemplo, aplicativo IBM WebSphere® sMash, etc.). A unidade de middleware é, em geral, dependente da plataforma. O modelo de topologia 804 inclui o dispositivo virtual 806 no qual o ambiente de execução de middleware selecionado 810 está localizado. O aplicativo independente de plataforma 808, tal como um aplicativo Java, também é selecionado e associado ao ambiente de tempo de execução de middleware 810. Na etapa 805, uma unidade modelo de topologia é adicionada a uma imagem virtual de base específica da nuvem. A imagem de máquina 812 é, então, incluída no aplicativo virtual 806. Neste exemplo, a imagem de máquina 812 inclui o sistema operacional convidado 814 (por exemplo, o sistema operacional Linux, etc.), software de servidor 816 e a cópia da imagem em nuvem 818.

[0123] OS metadados para imagens virtuais existentes compatíveis com uma nuvem podem ser encontrados em uma ou mais bibliotecas de imagem específicas para nuvem para esta nuvem. Estes metadados podem incluir descrição dos componentes de software pré-instalados nas imagens virtuais existentes. Os metadados na unidade de dispositivo virtual e suas unidades incluídas no modelo de topologia de destino podem descrever os componentes de software pré-requeridos para a solução que podem ser encontrados pré-instalados na imagem virtual de base específica para a nuvem. Os metadados na unidade de aplicativos virtuais podem ser usados para buscar os metadados nas bibliotecas de imagem para encontrar uma imagem virtual de base adequada para implementar a solução na nuvem de destino. Se as imagens virtuais identificadas como um resultado da busca não incluem todos os componentes de software pré-requeridos ou as versões corretas dos componentes de software pré-requeridos, então, uma imagem virtual de base de correspondência mais próxima pode ser determinada. Tal imagem virtual de base de correspondência mais próxima pode, então, ser intensificada como parte de um fluxo de trabalho de implementação ao adicionar, atualizar ou remover componentes de software na imagem virtual.

[0124] Na etapa 820, em uma concretização, definições de configuração específica para nuvem 822 e 824 são adicionadas, tais como endereços de IP flexíveis, informações sobre o volume, configurações de grupos de segurança e assim por diante. Na etapa 826, o servidor de aplicativos (ambiente de execução de middleware 810) é ligado a unidades de aplicativos (aplicativo independente de plataforma 808). Na etapa 828, as configurações específicas do sistema operacional são adicionadas e associadas ao sistema operacional convidado 814.

[0125] Estas definições de configuração específica do sistema operacional podem incluir configurações de HTTP, configurações de rede, configurações de firewall, etc. Na etapa 832, um ou mais dispositivos virtuais (unidades de serviço externo 834) são adicionados para a nuvem de destino que hospeda serviços de aplicativos pré-requeridos, tais como serviços de banco de dados e serviços LDAP, os quais são fornecidos externamente a partir do aplicativo virtual com base em nuvem. Na etapa 836, links de comunicação de aplicativos são configurados entre as unidades de aplicativos (aplicativo 808) e os serviços externos pré- requeridos que foram adicionados na etapa 832. Na etapa 838, restrições de ordem de implementação são especificadas entre diferentes unidades modelo. A etapa 838 permite um sequenciamento das etapas de automação usadas para implementar a solução. Na etapa 840, o modelo de topologia 804, incluindo todas as unidades modelo de topologia e a ordem de implementação especificada, é armazenado na biblioteca de recursos 500. Em uma concretização, a biblioteca de recursos 500 é gerida pelo software gestor de recursos 850. No processo predefinido 860, o modelo de topologia armazenado e as etapas de implementação especificadas são usados para criar um modelo de automação que também é armazenado na biblioteca de recursos 850 (vide Figura 9 e texto correspondente para obter detalhes de processamento sobre a criação do modelo de automação).

[0126] A Figura 9 é um fluxograma que mostra as etapas realizadas para criar modelos de etapa de automação de acordo com uma concretização. O processamento cria vários modelos de etapa de automação 910 usados para implementar a solução para a nuvem de destino. O processamento começa na etapa 900 quando do que, na etapa 905, é criado um modelo de etapa de automação 915. O modelo de etapa de automação 915 inclui a operação 920 para implementar uma configuração específica para nuvem que estabelece grupos de segurança, etc. na nuvem de destino.

[0127] Na etapa 925, o modelo de etapa de automação 930 é criado para instalar o aplicativo, incluindo parâmetros para o servidor de aplicativos (ambiente de execução de middleware) e o aplicativo de software independente de plataforma. O modelo de etapa de automação 930 inclui a operação 935 usada para instalar o aplicativo independente de plataforma (por exemplo, aplicativo Java sMash, etc.) e a operação 940 usada para configurar o ambiente de tempo de execução de middleware. Na etapa 945, o modelo de etapa de automação 950 é criado para copiar uma imagem na nuvem de destino. O modelo de etapa de automação 950 inclui a operação 955 usada para copiar uma imagem particular sobre a nuvem de destino. Na etapa 960, os modelos de etapa de automação 910 são armazenados na biblioteca de recursos 500 mostrada ser gerida pelo software de aplicativo gestor de recursos 850. No processo predefinido 970, especificações dos parâmetros de entrada são fornecidas e armazenadas com a topologia de destino na biblioteca de recursos (vide Figura 10 e texto correspondente para detalhes de processamento).

[0128] A Figura 10 é um fluxograma que mostra as etapas realizadas para especificar parâmetros de entrada e armazenar no modelo de topologia de acordo com uma concretização. Na Figura 10, o modelo de topologia 804 introduzido na Figura 8 é mostrado. Na Figura 10, o processamento começa em 1000 após o que, na etapa 1010, unidades modelo de implementação são relacionadas aos componentes. Por exemplo, um recurso de arquivo compactado particular na biblioteca de recursos que contém os binários independentes de plataforma passíveis de implementação é relacionado à unidade de aplicativos no modelo de topologia. O aplicativo 808 inclui as propriedades e parâmetros 1020 que, por exemplo, têm um arquivo comprimido especificado (arquivo "zip") configurado no mesmo. Na etapa 1030, alguns, mas talvez não todos, os parâmetros de configuração são especificados para as unidades modelo de topologia. Por exemplo, uma porta HTTP, um nome de arquivo zip e uma URL para o aplicativo poderiam ser especificados. Na etapa 1040, o padrão parcialmente especificado é compartilhado na biblioteca de recursos 500 como um recurso reutilizável. No processo predefinido 1050, a(s) cópia(s) é/são completamente especificada(s) e implementada(s) para a plataforma de destino (vide Figura 11 e texto correspondente para detalhes de processamento).

[0129] A Figura 11 é um fluxograma que mostra as etapas realizadas para especificar e implementar completamente uma cópia em execução do aplicativo com base em nuvem de acordo com uma concretização. O fluxograma mostrado na Figura 11 também mostra a implementação de múltiplas cópias para "multi-tenancy" com alterações de configuração mínimas durante especificação. O processamento começa em 1100 após o que, na etapa 1105, os parâmetros das unidades modelo de topologia são completamente especificados e armazenados no modelo de topologia 804. Algumas unidades modelos de topologia são associadas a modelos de etapa de automação 910 que descrevem a operação usada para implementar as unidades modelo de topologia. Na etapa 1110, uma sequência ordenada de operações de implementação é gerada e armazenada no modelo de fluxo de trabalho de automação 1115. Em uma concretização, o modelo de fluxo de trabalho de automação é uma representação genérica das operações usadas para implementar as unidades modelo de topologia. O fluxo de trabalho de implementação 1125 é gerado a partir do modelo de fluxo de trabalho de automação 1115 na etapa 1120. Em uma concretização, o fluxo de trabalho de implementação 1125 é uma descrição não genérica das operações que está em um formato que pode ser executado por um mecanismo de implementação 1135 particular. Deste modo, a etapa 1120 pode ser executada para fornecer diferentes fluxos de trabalho de implementação que funcionam com diferentes mecanismos de implementação.

[0130] Na etapa 1130, o mecanismo de implementação 1135 executa o fluxo de trabalho de implementação 1125 e cria uma ou mais cópias em execução (cópias 1150 e 1155) do aplicativo com base em nuvem que está sendo executado em uma ou mais nuvens de destino 1140. Na etapa 1160, a cópia em execução é observada e testada para garantir que a solução com base em nuvem está funcionando corretamente. Uma determinação é feita para saber se são necessárias alterações dos parâmetros especificados nas unidades modelos (decisão 1170).

[0131] Se forem necessárias alterações, então, a decisão 1170 ramifica para o ramo "sim" quando do que, na etapa 1175, os parâmetros da cópia são editados e o processamento retorna para gerar novamente o modelo de fluxo de trabalho, fluxo de trabalho de implementação e executar novamente o fluxo de trabalho de implementação pelo mecanismo de implementação. Este ciclo continua até que não haja necessidade de novas alterações, quando do que a decisão 1170 ramifica para o ramo "não". Deve ser observado que pode não ser necessário gerar novamente o modelo de fluxo de trabalho se tais parâmetros são especificados como parâmetros de entrada que podem ser modificados antes de nova implementação através da entrada do usuário. Uma determinação é feita para saber se múltiplas cópias do aplicativo (solução com base em nuvem) estão sendo criadas na nuvem de destino (ou nuvens de destino). Se múltiplas cópias do aplicativo estão sendo criadas, então, a decisão 1180 ramifica para o ramo "sim" quando do que, na etapa 1185, alguns parâmetros de fluxo de trabalho são alterados de modo a criar a próxima cópia e o processamento retorna para gerar outro modelo de fluxo de trabalho e outro fluxo de trabalho de implementação e o processamento executa o novo fluxo de trabalho de implementação usando o mecanismo de implementação. Por exemplo, pode ser necessário implementar uma nova cópia para um novo locatário em uma solução "multi- tenant". Em uma concretização, "multi-tenant" é a capacidade de compartilhar plataformas (por exemplo, nuvens, hipervisores) entre múltiplos clientes. Em outro exemplo, nova(s) cópia(s) da solução pode(m) ser necessária(s) de modo a satisfazer diferentes requisitos de desempenho ou de segurança em diferentes volumes de trabalho. Este ciclo continua até que mais nenhuma cópia do aplicativo seja desejada, ponto no qual a decisão 1180 ramifica para o ramo "não" e o processamento termina em 1195.

[0132] A Figura 12 é um fluxograma que mostra as etapas realizadas para reutilizar recursos armazenados na biblioteca de recursos e implementar a solução em um ambiente de nuvem de destino usando os recursos reutilizados de acordo com uma concretização. O processamento começa em 1200 após o que, na etapa 1210, o processamento recebe uma solicitação para transferir uma solução para uma nuvem de destino ou hipervisor particular. No processo predefinido 1220, uma topologia existente e unidades modelo de topologia mais próximas à solicitação são encontradas na biblioteca de recursos 500. O processo predefinido 1220 inclui a substituição de unidades modelo específicas para nuvem e armazenamento da nova topologia e novas unidades modelo na biblioteca de recursos 500. Vide Figura 13 e texto correspondente para detalhes de processamento em relação ao processo predefinido 1220. Na etapa 1230, parâmetros de configuração no modelo de topologia de destino são totalmente especificados e armazenados na biblioteca de recursos 500. No processo predefinido 1240, modelos de etapa de automação que correspondem às unidades modelo específicas para nuvem substituídas ou adicionadas são encontrados na biblioteca de recursos 500. Também no processo predefinido 1240, modelos de etapa de automação que correspondem às unidades modelo de topologia específicas para nuvem identificadas são encontrados dentro de biblioteca de recursos 500 e os modelos de etapa de automação são armazenados na biblioteca de recursos 500.

[0133] Os modelos de etapa de recursos são usados para implementar as unidades modelo de topologia para a nuvem de destino. Vide Figura 14 e texto correspondente para detalhes de processamento sobre o processo predefinido 1240. No processo predefinido 1250, um fluxo de trabalho de implementação é gerado com base nos modelos de etapa de automação (vide Figura 15 e o texto correspondente para detalhes de processamento e vide Figura 16 e texto correspondente para detalhes em relação à implementação de uma solução compósita). O resultado de implementação é a nuvem de origem 1260 com uma cópia 1265 de uma solução com base em nuvem existente e nuvem de destino 1270 com uma nova cópia 1275 da solução com base em nuvem. Em uma concretização, tanto a nuvem de origem como a nuvem de destino são acessíveis a partir da rede de computadores 200, tal como a Internet. Assim, por exemplo, cada cópia pode fornecer uma cópia de um aplicativo com base na Web acessível pelos clientes através da rede de computadores, por exemplo, usando o software de navegação na Web com base no cliente.

[0134] A Figura 13 é um fluxograma que mostra as etapas realizadas para encontrar unidades de topologia existentes que correspondem a uma solicitação, substituir unidades modelo específicas para nuvem e armazenar unidades modelo novas e modificadas na biblioteca de recursos de acordo com uma concretização. A Figura 13 é chamada pelo processo predefinido 1220 mostrado na Figura 12. O processamento mostrado na Figura 13 começa em 1300 após o que, na etapa 1320, os requisitos para uma nova solução com base em nuvem são recebidos a partir do usuário 1310. Na etapa 1325, os metadados de modelos de topologia existentes armazenados na biblioteca de recursos 500 são pesquisados de modo a encontrar modelos de topologia existentes que correspondem, até certo ponto, aos requisitos fornecidos pelo usuário. Em uma concretização, as diferenças calculadas anteriormente podem ser recuperadas a partir da biblioteca de recursos 500 como um patch e podem ser aplicadas a um modelo de topologia de origem existente para criar um modelo de topologia de destino. Uma determinação é feita para saber se todos os modelos de topologia existentes que correspondem aos requisitos do usuário foram encontrados na biblioteca de recursos (decisão 1330). Se nenhum modelo de topologia existe atualmente na biblioteca de recursos que corresponde às necessidades do usuário, então, a decisão 1330 ramifica para o ramo "não" quando do que, no processo predefinido 1335, é criado um novo modelo de topologia (vide, por exemplo, Figura 8 e texto correspondente para um exemplo de criação de um novo modelo de topologia).

[0135] Por outro lado, se foram encontrados um ou mais modelos de topologia que correspondem aos requisitos do usuário, então, a decisão 1330 ramifica para o ramo "sim" quando do que, na etapa 1340, o modelo de topologia existente encontrado na biblioteca de recursos que mais se aproxima das necessidades do usuário é copiado. Na etapa 1350, o novo modelo de topologia é armazenado na biblioteca de recursos (ou um modelo de topologia recém-criado criado no processo predefinido 1335 ou um modelo de topologia existente copiado na etapa 1340).

[0136] Uma determinação é feita para saber se as unidades modelos de topologia requerem modificação (decisão 1360). Por exemplo, se um modelo de topologia foi copiado na etapa 1340, o novo modelo de topologia de destino pode requerer modificação se o modelo de topologia copiado não corresponde exatamente aos requisitos especificados pelo usuário. Se uma ou mais unidades modelo de topologia requerem modificação, então, a decisão 1360 ramifica para o ramo "sim" quando do que, na etapa 1370, as unidades modelos de topologia que requerem modificação são recuperadas a partir do modelo de topologia de destino e modificadas para atender às necessidades do usuário. Na etapa 1380, as unidades modelos de topologia modificadas são armazenadas no modelo de topologia de destino na biblioteca de recursos 500. Voltando para a decisão 1360, se as unidades modelos de topologia não requerem modificação, então, a decisão 1360 ramifica para o ramo "não" pulando as etapas 1370 e 1380. Na etapa 1390, as unidades modelos específicas para nuvem para a nuvem de destino são substituídas. O processamento retorna, então, para a rotina de chamada (vide Figura 12) em 1395.

[0137] A Figura 14 é um fluxograma que mostra as etapas realizadas para gerar um modelo de fluxo de trabalho de implementação de acordo com uma concretização. A Figura 14 é chamada pelo processo predefinido 1240 mostrado na Figura 12. O processamento mostrado na Figura 14 começa em 1400 após o que, na etapa 1410, a primeira unidade modelo de topologia nova ou modificada usada para implementar a solução sobre a nuvem de destino é identificada. Observe que as unidades modelos de topologia de origem que não foram modificadas não precisam ser identificadas porque o modelo de etapa de automação já associado à unidade modelo de topologia sem modificação pode ser usado. Observe que, se qualquer unidade modelo é removida do modelo de topologia de origem, então, a operação de implementação correspondente também pode ser removida do modelo de fluxo de trabalho de destino. Observe também que, em uma concretização, várias unidades modelos de topologia podem ser associadas a um modelo de etapa de automação (Automation Step Model- ASM). Se várias unidades modelos de topologia são associadas a um modelo de etapa de automação, então, uma verificação pode ser feita para saber se todas as unidades estão presentes no modelo de topologia de destino. Na etapa 1420, a biblioteca de recursos 500 é pesquisada quanto a modelos de etapa de automação associados à nuvem de destino.

[0138] Uma determinação é feita para saber se todos os modelos de etapa de automação correspondentes foram encontrados na biblioteca de recursos (decisão 1430). Se nenhum modelo de etapa de automação correspondente foi encontrado, então, a decisão 1430 ramifica para o ramo "não" quando do que, na etapa 1450, um novo modelo de etapa de automação é criado para a nuvem de destino. Por outro lado, se um modelo de etapa de automação correspondente foi encontrado, então, a decisão 1430 ramifica para o ramo "sim", após o que o modelo de etapa de automação encontrado é usado. Na etapa 1450, o modelo de etapa de automação (quer encontrado através de busca ou criado na etapa 1440) é associado à unidade modelo de topologia nova ou modificada identificada. Uma determinação é feita para saber se há mais unidades modelo de topologia novas ou modificadas para processar (decisão 1460). Se há mais unidades modelo de topologia novas ou modificadas para processar, então, a decisão 1460 ramifica para o ramo "sim" o qual retorna para identificar a próxima unidade modelo de topologia nova ou modificada e associá-la a um modelo de etapa de automação, conforme descrito acima. Observe que, para unidades modelo modificadas, o nome Modelo de Etapa de Automação usado na nuvem de origem pode ser usado na busca para encontrar Modelos de Etapa de Automação semelhantes para a nuvem de destino. Este ciclo continua até que não haja mais unidades modelo de topologia novas ou modificadas para processar, quando do que a decisão 1460 ramifica para o ramo "não".

[0139] Na etapa 1470, o modelo de fluxo de trabalho de implementação 1480 é gerado para a nuvem de destino. O modelo de fluxo de trabalho é gerado usando os modelos de etapa de automação encontrados ou recém-criados associados às unidades modelo de topologia novas ou modificadas identificadas, bem como modelos de etapa de automação já associados às unidades modelo de topologia no modelo de topologia de origem que não foram modificadas de forma a transferir a solução para a nuvem de destino. O processamento retorna, então, para a rotina de chamada (vide Figura 12) em 1395.

[0140] A Figura 15 é um fluxograma que mostra as etapas realizadas para gerar um fluxo de trabalho de implementação a partir do modelo e implementar usando um mecanismo de implementação de acordo com uma concretização. A Figura 15 é chamada pelo processo predefinido 1250 mostrado na Figura 12. O processamento mostrado na Figura 15 começa em 1500 após o que, na etapa 1510, um mecanismo de implementação que será usado para implementar a solução para a nuvem de destino é selecionado a partir da memória de dados mecanismos de implementação 1515. Algumas nuvens de destino podem usar um mecanismo de implementação particular, embora outros mecanismos de implementação de uso geral também possam ser usados para implementar soluções para nuvens de destino. Os mecanismos de implementação podem ter diferentes capacidades de processamento e características que podem tornar um determinado mecanismo de implementação atraente para implementação de uma solução para uma determinada nuvem de destino. Na etapa 1520, a(s) primeira(s) operação(ões) de implementação é/são selecionada(s) a partir do modelo de fluxo de trabalho de implementação 1480 que foi gerado na Figura 14.

[0141] Cada modelo de etapa de automação pode incluir várias operações de implementação. Estas operações de implementação são ordenadas sequencialmente no modelo do fluxo de trabalho. As operações de implementação também são específicas para o mecanismo de implementação. Cada operação de implementação é, então, usada para gerar uma etapa específica para mecanismo de implementação. A etapa 1520 gera uma ou mais etapas específicas para mecanismo de implementação 1515 que são capazes de ser executadas pelo mecanismo de implementação escolhido. As etapas específicas para mecanismo de implementação geradas são armazenadas no fluxo de trabalho de implementação 1530 como primeira etapa de implementação 1531, segunda etapa de implementação 1532, etc., até a última etapa de implementação 1534. Uma determinação é feita para saber se há mais operações de implementação a processar (decisão 1540). Se há mais modelos de etapa a processar, então, a decisão 1540 ramifica para o ramo "sim" que retorna para selecionar o próximo modelo de etapa de automação a partir do modelo de fluxo de trabalho de implementação 1480 e gerar etapas específicas para mecanismo de implementação, conforme descrito acima na etapa 1520. Este ciclo continua até que não haja mais operações implementação a processar, ponto no qual a decisão 1540 ramifica para o ramo "não", quando do que o mecanismo de implementação 1550 selecionado é chamado para processar o fluxo de trabalho de implementação 1530. O fluxo de trabalho de implementação 1530 inclui as operações de implementação e é transmitido ao mecanismo de implementação 1550 selecionado antes de chamada.

[0142] O processamento do mecanismo de implementação começa ao executar a primeira etapa de implementação (etapa 1531) incluída no fluxo de trabalho de implementação 1530. A execução de uma primeira etapa de implementação resulta na implementação de uma parte da solução na plataforma de destino (nuvem de destino 1270).

[0143] Uma determinação é feita por um dos mecanismos de implementação 1515 para saber se há mais etapas de implementação a processar (decisão 1570). Se há mais etapas de implementação a processar, então, a decisão 1570 ramifica para o ramo "sim" que retorna para selecionar e executar a etapa seguinte (por exemplo, segunda etapa de implementação 1532) a partir do fluxo de trabalho de implementação 1530, resultando na implementação da solução na plataforma de destino. Este ciclo continua até que a última etapa de implementação (última etapa de implementação 1534) seja processada na etapa 1560, ponto no qual a decisão 1570 ramifica para o ramo "não" e o processamento retorna em 1595.

[0144] O resultado da execução de todas as etapas de implementação é a nova solução com base em nuvem 1275 sendo executada na plataforma de destino (nuvem de destino 1270).

[0145] A Figura 16 é um fluxograma que mostra as etapas realizadas para gerar um fluxo de trabalho de implementação a partir do modelo e implementar uma solução compósita a vários ambientes com base em nuvem de acordo com uma concretização. As etapas são as mesmas conforme aquelas mostradas e descritas na Figura 15, no entanto, na Figura 16, as etapas de implementação resultam na implementação da solução através de duas plataformas de destino (primeira nuvem de destino 1610 e segunda nuvem de destino 1630), resultando em uma solução compósita 1600. Cada nuvem de destino hospeda uma parte virtual da solução (parte virtual 1620 hospedada pela primeira nuvem de destino 1610 e parte virtual 1640 hospedada pela segunda nuvem de destino 1630). Além disso, uma ou mais das etapas de implementação incluídas no fluxo de trabalho de implementação 1530 estabelecem links de comunicação 1630 entre a parte virtual 1650 e a parte virtual 1640. O link de comunicação 1650 pode ser estabelecido através de uma rede virtual privada (VPN). Embora duas nuvens e partes virtuais sejam mostradas na solução compósita 1600, qualquer número de nuvens de destino e partes virtuais pode ser incluído em uma solução compósita com links de comunicação estabelecidos entre qualquer número das partes virtuais.

[0146] Em uma concretização, uma solução para a nuvem de destino ou hipervisor pode ser reconstruída usando uma abordagem controlada por modelo que pode evitar: i) cópia dos conteúdos de imagem; e ii) representação de conteúdos de imagem virtual em um formato de arquivo de disco unificado. As concretizações podem permitir que uma solução seja transferida entre diferentes provedores de nuvem (ou hipervisor) com arquitetura de hardware, tecnologia de hipervisor, tipo e versão de sistema operacional convidado incompatíveis. As concretizações também podem permitir que configurações específicas para nuvem (ou específicas para hipervisor) sejam adicionadas quando de transporte. As concretizações também podem permitir a inclusão de partes de imagem virtual em uma solução compósita para nuvens híbridas que pode ser parcialmente transferida.

[0147] Em uma concretização, a diferenciação de um modelo de topologia de origem associado a uma plataforma de origem e um modelo de topologia de destino associado a uma plataforma de destino que resulta em uma diferença de topologia pode ser obtida e/ou armazenada em patches usando uma ferramenta tal como Eclipse Modeling Framework (EMF) Compare Project. Em uma concretização, uma parte da diferenciação é executada por pelo menos um processador que pode ser selecionado a partir de um ou mais processadores. Em uma concretização, as unidades modelos de topologia podem ser construídas e/ou visualizadas usando o Rational Software Architectno Eclipse. Em uma concretização, os modelos de etapa de automação podem ser construídos e/ou visualizados usando o Rational Software Architectno Eclipse. O Rational Software Architectarmazena os dados do modelo em formato XML. XML inclui diferentes seções para as diferentes unidades modelo, tais como o aplicativo virtual, o middleware, a imagem virtual, o sistema operacional convidado, configuração específica para nuvem, links de comunicação a nível de aplicativo e assim por diante. Cada seção XML pode incluir vários parâmetros de implementação, tais como as versões e tipos de software. Os parâmetros na seção de aplicativo virtual podem ser usados como entrada em buscas na biblioteca de recursos para encontrar uma imagem virtual compatível para a nuvem de destino.

[0148] Em uma concretização, a obtenção de uma operação em um modelo de fluxo de trabalho a partir de uma biblioteca de recursos pode ser feita através de busca no Rational Asset Manager onde modelos de etapa de automação que incluem as operações de implementação podem ser armazenados. A busca pode usar como entrada de metadados para a unidade modelo de topologia associada ao modelo de etapa de automação. Em uma concretização, uma parte da biblioteca de recursos pode ser armazenada em um meio de armazenamento persistente. Em uma concretização, toda a biblioteca de recursos, incluindo uma parte da biblioteca de recursos, pode ser armazenada em um meio de armazenamento persistente.

[0149] Em uma concretização, a execução da operação para implementar uma parte de uma solução, em que a parte implementada da solução inclui uma imagem de destino compatível com a plataforma de destino, pode ser feita usando o Tivoli Provisioning Managercomo um mecanismo de implementação. Em uma concretização, o Tivoli Provisioning Managerpode executar um fluxo de trabalho que implementa diferentes partes da solução em diferentes nuvens ou hipervisores.

[0150] São descritas concretizações de métodos, produtos de programa de computador e sistemas para transferir uma solução de uma plataforma de origem para uma plataforma de destino. Uma diferença é determinada entre um conjunto de unidades modelo em um modelo de topologia de origem e um conjunto de unidades modelo em um modelo de topologia de destino. O modelo de topologia de origem está associado a uma plataforma de origem e o modelo de topologia de destino está associado a uma plataforma de destino. Uma operação de um modelo de fluxo de trabalho é obtida a partir de uma biblioteca de recursos em virtude de sua associação com a diferença calculada entre o conjunto de unidades modelo de topologia de origem e o conjunto de unidades modelo de topologia de destino. A operação é transmitida. A operação é configurada para implementar pelo menos uma parte de uma solução que compreende uma imagem de destino compatível com a plataforma de destino. Tais concretizações podem ser usadas para transferir soluções entre nuvens de diferentes infraestruturas ou hipervisores que dão suporte a diferentes arquiteturas de hardware, formatos de imagem virtual e interfaces de programação. Tais concretizações também podem ser usadas para reutilização de componentes de solução, parâmetros de configuração e operações de automação de implementação em comum quando de transferência de soluções.

[0151] De acordo com outras concretizações descritas, a plataforma de origem é um primeiro conjunto de recursos de hardware e software e a plataforma de destino é um segundo conjunto de recursos de hardware e software. Pelo menos uma parte da solução é transferida do primeiro conjunto de recursos de hardware e software para o segundo conjunto de recursos de hardware e software. Tais concretizações podem ser usadas para transferir uma solução de uma nuvem (ou hipervisor ou sistema de computador) para outra nuvem (ou sistema de computador ou hipervisor).

[0152] De acordo com outras concretizações descritas, a plataforma de origem é um conjunto privado de recursos de hardware e software. A plataforma de destino é um conjunto público de recursos de hardware e software. Tais concretizações podem ser usadas para transferir uma solução de uma nuvem privada para uma nuvem pública. Outras concretizações podem ser usadas para transferir uma solução de uma nuvem pública para uma nuvem privada, de uma nuvem privada para uma nuvem particular e/ou de uma nuvem pública para uma nuvem pública.

[0153] De acordo com outras concretizações descritas, a solução é uma solução compósita. O segundo conjunto de recursos de hardware e software compreende uma pluralidade de conjuntos de recursos de hardware e software. Tais concretizações podem ser usadas para transferir diferentes partes virtuais de uma solução para diferentes nuvens (ou hipervisores ou sistemas de computadores) que compreendem uma nuvem híbrida.

[0154] De acordo com outras concretizações descritas, os metadados armazenados em uma biblioteca de recursos são pesquisados quanto a pelo menos uma metadados de imagem de base que está associada à plataforma de destino. Tais concretizações podem ser usadas para encontrar imagens virtuais de base compatíveis para a plataforma de destino na qual os componentes de software pré-requeridos da solução estão pré-instalados.

[0155] De acordo com outras concretizações descritas, a plataforma de origem é um primeiro hipervisor que é executado em um primeiro conjunto de um ou mais sistemas de computadores. A plataforma de destino é um segundo hipervisor que é executado em um segundo conjunto de um ou mais sistemas de computador. Os primeiro e segundo hipervisores são diferentes tipos de hipervisores. Tais concretizações podem ser usadas para transferir uma solução de um hipervisor (ou sistema de computador) para outro hipervisor (sistema ou computador).

[0156] De acordo com outras concretizações descritas, a diferença determinada compreende pelo menos um de uma nova unidade modelo, uma unidade modelo modificada ou uma unidade modelo removida. Tais concretizações podem ser usadas para reutilização de componentes de soluções, parâmetros de configuração e operações de automação de implementação em comum quando de transferência de soluções.

[0157] De acordo com outras concretizações descritas, a diferença determinada compreende ainda identificar um ou mais atributos de um conjunto de unidades modelo no modelo de topologia de origem e identificar se os atributos identificados são incompatíveis com um ou mais atributos identificados do conjunto de unidades modelos na topologia de destino. A diferença determinada pode compreender a identificação de atributos incompatíveis (incluindo tipo) em unidades modelos do modelo de topologia de origem em comparação com o modelo de topologia de destino. Tais concretizações podem ser usadas para identificar os componentes da solução, parâmetros de configuração e operações de automação de implementação que precisam ser modificados quando de transferência de soluções.

[0158] De acordo com outras concretizações descritas, o atributo incompatível identificado da unidade modelo é analisado em resposta à identificação de que os atributos identificados são incompatíveis. O atributo incompatível da unidade modelo é modificado de forma a transferir a solução da plataforma de origem para a plataforma de destino. Tais concretizações podem ser usadas para determinar as alterações nos componentes da solução, parâmetros de configuração e operações de automação de implementação para transferência de soluções; e também podem ser usadas para tornar os atributos incompatíveis identificados nas unidades modelo compatíveis com o modelo de topologia da plataforma de destino.

[0159] De acordo com outras concretizações descritas, o atributo incompatível identificado identifica se uma unidade modelo foi removida, adicionada ou modificada na topologia de destino quando comparado com o modelo de topologia de origem. Tais concretizações podem ser usadas para identificar os componentes da solução, parâmetros de configuração e operações de automação de implementação que precisam ser modificados quando de transferência de soluções.

[0160] De acordo com outras concretizações descritas, a modificação dos atributos incompatíveis compreende ainda adição de uma nova unidade modelo, atualização da unidade modelo ou remoção da unidade modelo de modo a corrigir a incompatibilidade identificada entre o conjunto de unidades modelo da topologia de origem e o conjunto de unidades modelo da topologia de destino. Tais concretizações podem ser usadas para determinar as alterações nos componentes da solução, parâmetros de configuração e operações de automação de implementação para transferência de soluções.

[0161] De acordo com outras concretizações descritas, uma unidade modelo compreende dados que identificam um ou mais atributos de um modelo de topologia. Tais concretizações podem ser usadas para determinar os parâmetros de configuração e implementação para implementação de uma solução em uma plataforma.

[0162] De acordo com outras concretizações descritas, a plataforma de origem é um primeiro hipervisor que é executado em um primeiro conjunto de recursos de hardware e recursos de software. A plataforma de destino é um segundo hipervisor que é executado em um segundo conjunto de recursos de hardware e software. Os hipervisores de origem e de destino são de tipos diferentes. Tais concretizações podem ser usadas para transferência de uma solução entre imagens virtuais compatíveis com diferentes tipos de hipervisores.

[0163] São fornecidas concretizações de métodos, produtos de programa de computador e sistemas que obtêm uma unidade modelo de topologia que tem de ser implementada em uma plataforma de destino. Uma pluralidade de modelos de etapa de automação armazenados em uma biblioteca de recursos é pesquisada quanto a um modelo de etapa de automação selecionado que está associado à unidade modelo de topologia recebida. A busca é realizada por um ou mais processadores. Uma ou mais operações de implementação são obtidas a partir da biblioteca de recursos. As operações de implementação obtidas estão associadas ao modelo de etapa de automação selecionado. As operações de implementação obtidas são executadas a fim de implementar a unidade modelo de topologia para a plataforma de destino. Tais concretizações podem ser usadas para construir um modelo de fluxo de trabalho novo ou modificado para implementação de uma solução em uma plataforma diferente.

[0164] São fornecidas concretizações de métodos, produtos de programa de computador e sistemas que recuperam um metadados de imagem de origem a partir de um meio de armazenamento persistente. Os metadados de imagem de origem correspondem a uma imagem de origem associada a uma plataforma de origem. Os metadados de origem recuperados são comparados com um ou mais metadados de imagem disponíveis que correspondem a uma ou mais imagens disponíveis associadas a uma plataforma de destino. Um dos metadados de imagem disponível que é mais compatível com os metadados da imagem de origem é identificado com base na comparação. A imagem disponível que corresponde aos metadados de imagem disponível identificados é usada como uma imagem de destino compatível com a plataforma de destino. Tais concretizações podem ser usadas para encontrar imagens virtuais de base compatíveis para a plataforma de destino em que a maior parte (se não todos) os componentes de software pré-requeridos da solução estão pré-instalados.

[0165] Deve ser entendido que há várias concretizações alternativas. Por exemplo, em uma concretização, a invenção fornece um meio legível/utilizável em computador que inclui o código de programa de computador para permitir que uma infraestrutura de computador forneça funcionalidade conforme discutido aqui. Até este ponto, o meio legível/utilizável em computador inclui um código de programa que implementa cada um dos vários processos. Deve ser entendido que os termos meio legível em computador ou meio utilizável em computador compreendem um ou mais de qualquer tipo de concretização física do código de programa. Em particular, o meio legível/utilizável em computador pode compreender o código de programa incorporado em um ou mais artigos de manufatura de armazenamento portáteis (por exemplo, um disco compacto, um disco magnético, uma fita, etc.), em uma ou mais partes de memória de dados de um dispositivo de computação, tal como a memória 28 (Figura 1) e/ou sistema de armazenamento 34 (Figura 1) (por exemplo, um disco fixo, uma memória somente de leitura, uma memória de acesso aleatório, uma memória cache, etc.) e/ou como dados de sinal (por exemplo, um sinal propagado) que se desloca através de uma rede (por exemplo, durante uma distribuição eletrônica cabeada/sem fio do código de programa).

[0166] Em uma concretização, um método que executa o processo quando de assinatura, publicidade e/ou com base em taxa é fornecido. Ou seja, um provedor de serviços, tal como um Solution Integrator, poderia oferecer os serviços descritos aqui. Neste caso, o provedor de serviços pode criar, manter, dar suporte, etc., uma infraestrutura de computador, tal como o sistema de computador 12 (Figura 1) que executa o processo para um ou mais clientes. Em troca, o provedor de serviços pode receber o pagamento do(s) cliente(s) sob um contrato de subscrição e/ou taxa e/ou o provedor de serviços pode receber o pagamento pela venda de conteúdo publicitário para uma ou mais partes terceirizadas.

[0167] Em uma concretização, é fornecido um método implementado em computador para fornecer a funcionalidade descrita aqui. Neste caso, uma infraestrutura de computador, tal como o sistema de computador 12 (Figura 1), pode ser fornecida e um ou mais sistemas para execução do processo podem ser obtidos (por exemplo, criados, comprados, usados, modificados, etc.) e implementar a infraestrutura de computador. Até este ponto, a implementação de um sistema pode compreender um ou mais de: (1) instalar um código de programa em um dispositivo de computação, tal como o sistema de computador 12 (Figura 1), a partir de um meio legível em computador; (2) adicionar um ou mais dispositivos de computação à infraestrutura de computador; e (3) incorporar e/ou modificar um ou mais sistemas existentes da infraestrutura de computador para permitir que a infraestrutura de computador execute o processo.

[0168] Uma das implementações descritas é um aplicativo de software, ou seja, um conjunto de instruções (código de programa) ou outras instruções de programa de computador em um módulo de código que podem, por exemplo, estar residentes na memória de acesso aleatório do computador. Material funcional descritivo inclui "código de programa", "código de programa de computador", "instruções de computador" e qualquer expressão, em qualquer linguagem, código ou notação, de um conjunto de instruções com a intenção de fazer com que um dispositivo de computação tenha uma capacidade de processamento de informações para executar uma função particular, diretamente ou após qualquer um ou ambos do seguinte: (a) conversão para outra linguagem, código ou notação; e/ou (b) reprodução em uma forma material diferente. Até este ponto, o código de programa pode ser incorporado como um ou mais dos seguintes: um programa de aplicativo/software, software componente/uma biblioteca de funções, um sistema operacional, um sistema de dispositivo básico/driver para um dispositivo de computador particular e assim por diante. Até requerido pelo computador, o conjunto de instruções pode ser armazenado em outra memória do computador, por exemplo, em uma unidade de disco rígido, ou em uma memória removível, tal como um disco óptico (para uso eventual em um CD-ROM) ou disquete (para uso eventual em uma unidade de disquete). Assim, as concretizações podem ser implementadas como um produto de programa de computador para uso em um computador. Além disso, embora vários métodos descritos sejam convenientemente implementados em um computador de uso geral seletivamente ativado ou reconfigurado por software, aqueles versados na técnica também reconhecerão que tais métodos podem ser executados em hardware, firmware ou em um dispositivo mais especializado construído de modo a executar as etapas necessárias do método. O material funcional descritivo é a informação que confere a funcionalidade a uma máquina. O material funcional descritivo inclui, porém sem limitações, programas de computador, instruções, regras, fatos, definições de funções computáveis, objetos e estruturas de dados.

[0169] Um sistema de processamento de informações (sistema de processamento de dados) adequado para armazenamento e/ou execução de código de programa pode ser fornecido aqui abaixo e pode incluir pelo menos um processador acoplado em comunicação, direta ou indiretamente, ao(s) elemento(s) de memória através de um barramento de sistema. Os elementos de memória podem incluir, porém sem limitações, memória local empregada durante execução real do código de programa, memória comum e memórias cache que permitem armazenamento temporário de pelo menos algum código de programa de modo a reduzir o número de vezes que o código deve ser recuperado a partir da memória durante execução. Dispositivos de entrada e/ou dispositivos de saída (incluindo, porém sem limitações, teclados, monitores, dispositivos ponteiros, etc.) podem ser acoplados ao sistema, quer diretamente ou através de controladores de dispositivos intervenientes.

[0170] Adaptadores de rede também podem ser acoplados ao sistema para permitir que o sistema de processamento de dados se torne acoplado a outros sistemas de processamento de dados, impressoras remotas, dispositivos de armazenamento e/ou similar através de qualquer combinação de redes privadas ou públicas intervenientes. Adaptadores de rede ilustrativos incluem, porém sem limitações, modems, modems a cabo e placas de Ethernet.

[0171] A descrição anterior foi apresentada para fins de ilustração e descrição. Ela não se destina a ser exaustiva ou limitativa uma vez que, obviamente, muitas modificações e variações são possíveis. Tais modificações e variações que podem ser evidentes para aqueles versados na técnica e devem ser incluídas dentro do escopo da descrição, conforme definido pelas reivindicações anexas.

[0172] Embora concretizações particulares tenham sido mostradas e descritas, será óbvio para aqueles versados na técnica, com base nos ensinamentos descritos aqui, que alterações e modificações podem ser feitas sem se afastar da presente descrição e seus aspectos mais amplos.

[0173] Além disso, deve ser entendido que uma ou mais concretizações são definidas nas reivindicações anexas. Será entendido por aqueles versados na técnica que, se um número específico de um elemento reivindicado introduzido é pretendido, tal intenção será expressamente citada na reivindicação e, na ausência de tal citação, nenhuma limitação está presente. Como um exemplo não limitativo, como um auxílio para compreensão, as reivindicações anexas a seguir contêm o uso de frases introdutórias "pelo menos um" e "um ou mais"para introduzir elementos reivindicados.

[0174] No entanto, o uso de tais frases não deve ser interpretado como implicando que a introdução de um elemento reivindicado pelos artigos indefinidos "um" ou "uma" limita qualquer reivindicação particular que contém tal elemento reivindicado introduzido a limitações que contêm apenas um de tais elementos, mesmo quando tal reivindicação inclui as frases introdutórias "um ou mais"ou "pelo menos um" e artigos indefinidos, tais como "um" ou "uma"; o mesmo vale para o uso nas reivindicações de artigos definidos.

Claims (10)

1. Método implementado por um sistema de tratamento de informação caracterizado pelo fato de que compreende: receber uma solicitação para uma solução em uma plataforma alvo, em que a plataforma alvo está associada com um modelo de topologia alvo, e em que a solicitação inclui a plataforma alvo e um ou mais requerimentos para a solução; comparar, por um processador, metadados de imagem alvo correspondendo ao um ou mais requerimentos por uma ou mais imagens virtuais disponíveis associadas com uma pluralidade de plataformas; identificar, com base na comparação, um dos metadados de imagem disponíveis que seja mais compatível com os metadados da imagem fonte; selecionar a imagem virtual disponível correspondendo aos metadados de imagem disponíveis identificados como uma imagem virtual alvo compatível com a plataforma alvo; modificar um ou mais unidades de modelo de topologia associados com a imagem virtual alvo; armazenar as unidades de modelo de topologia modificadas em uma biblioteca de ativos do modelo de topologia alvo; e gerar um modelo de fluxo de trabalho de entrega para a plataforma alvo, em que o modelo de fluxo de trabalho de entrega compreende um ou mais modelos de etapa de automação correspondendo às unidades de modelo de topologia modificada e um ou mais modelos de etapa de automação correspondendo a uma ou mais unidades de modelo de topologia inalteradas.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os metadados de imagem alvo e os metadados de imagem disponíveis incluem metadados de componente de software.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: aprimorar a imagem virtual disponível, em que o aprimoramento compreende adicionar um ou mais componentes de software à imagem virtual disponível.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: implementar a solução na plataforma alvo.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que implementar compreende adicionalmente: selecionar um mecanismo de implementação; gerar uma ou mais etapas de mecanismo de entrega para cada modelo de etapa de automação no modelo de fluxo de trabalho de entrega; e executar as etapas de mecanismo de entrega.

6. Sistema de tratamento de informação caracterizado pelo fato de que compreende: um ou mais processadores; uma memória acessível por pelo menos um dos processadores; um meio de armazenamento persistente acessível por pelo menos um dos processadores; uma interface de rede que conecta o sistema de tratamento de informação a uma rede de computadores, em que as interfaces de rede estão acessíveis por pelo menos um dos processadores; e um conjunto de instruções armazenados na memória e executados por pelo menos um dos processadores para realizar as ações de: receber uma solicitação para uma solução em uma plataforma alvo, em que a plataforma alvo está associada com um modelo de topologia alvo, e em que a solicitação inclui a plataforma alvo e um ou mais requerimentos para a solução; comparar metadados de imagem fonte correspondendo ao um ou mais requerimentos por um ou mais metadados de imagem disponíveis correspondendo a um ou mais imagens virtuais disponíveis associadas com uma pluralidade de plataformas; identificar, com base na comparação, um dos metadados de imagem disponível que seja mais compatível com os metadados de imagem fonte; e selecionar a imagem virtual disponível correspondendo aos metadados de imagem disponíveis como uma imagem virtual alvo compatível com a plataforma alvo; modificar uma ou mais unidades de modelo de topologia associados com a imagem virtual alvo; armazenar as unidades de modelo de topologia modificadas em uma biblioteca de ativos do modelo de topologia alvo; e gerar um modelo de fluxo de trabalho de entrega para a plataforma alvo, em que o modelo de fluxo de trabalho de entrega compreende um ou mais modelos de etapa de automação correspondendo às unidades de modelo de topologia modificada e um ou mais modelos de etapa de automação correspondendo a uma ou mais unidades de modelo de topologia inalterada.

7. Sistema de tratamento de informação, de acordo com a reivindicação 4, caracterizado pelo fato de que os metadados de imagem alvo e os metadados de imagem disponível incluem metadados de componente de software.

8. Sistema de tratamento de informação, de acordo com a reivindicação 4, caracterizado pelo fato de que as ações compreendem adicionalmente: aprimorar a imagem virtual disponível, em que o aprimoramento compreende adicionar um ou mais componentes de software à imagem virtual disponível.

9. Sistema de tratamento de informação, de acordo com a reivindicação 4, caracterizado pelo fato de que as ações compreendem adicionalmente: implementar a solução na plataforma alvo.

10. Sistema de tratamento de informação, de acordo com a reivindicação 9, caracterizado pelo fato de que as ações compreendem adicionalmente: selecionar um mecanismo de implementação; gerar uma ou mais etapas de mecanismo de entrega para cada modelo de etapa de automação no modelo de fluxo de trabalho de entrega; e executar as etapas de mecanismo de entrega.

Images