Sem resumo de edição |
Sem resumo de edição |
||
| Linha 18: | Linha 18: | ||
Sendo o AutoI, a solução escolhida ou outra, será criado uma infraestrutura para abrigar o software que deverá ser "dissecado" em todo o seu código para seu conhecimento pleno e posterior procedimentos de alteração e compilação até que se chegue com sucesso a um código executável. | Sendo o AutoI, a solução escolhida ou outra, será criado uma infraestrutura para abrigar o software que deverá ser "dissecado" em todo o seu código para seu conhecimento pleno e posterior procedimentos de alteração e compilação até que se chegue com sucesso a um código executável. | ||
O procedimento de instalação, especificamente do AutoI, é similar aos inúmeros códigos-fonte espalhados pela Internet. A partir de um endereço disponível na web | O procedimento de instalação, especificamente do AutoI, é similar aos inúmeros códigos-fonte espalhados pela Internet. A partir de um endereço disponível na web, é possível descarregar o código e instalá-lo num sistema operacional linux e a partir daí, compilá-lo segundo as regras do ambiente., identificando os possíveis erros e posteriormente corrigi-los até que o executável esteja disponível. | ||
Este primeiro passo na maioria dos casos é bem crítico porque o proccesso entre identificar os erros, corrigi-los e compilá-los é feito de uma maneira empírica. A cada erro corrigido, descobrem-se novos que geram um novo ciclo de correção. Isto não seria tão difícil se os programas-fonte fossem bem organizados e tivessem uma documentação efetiva, algo como um diagrama de Fluxo de Dados ou Diagramas de Classes e Estudos de Caso. Como na grande maioria, estes documentos não são encontrados fica a cargo da equipe de pesquisadores, debruçar-se sobre cada código, como faz um arqueologista decifrando um hieróglifo e se propõe a desvendar o que o programador original teria feito. | Este primeiro passo na maioria dos casos é bem crítico porque o proccesso entre identificar os erros, corrigi-los e compilá-los é feito de uma maneira empírica. A cada erro corrigido, descobrem-se novos que geram um novo ciclo de correção. Isto não seria tão difícil se os programas-fonte fossem bem organizados e tivessem uma documentação efetiva, algo como um diagrama de Fluxo de Dados ou Diagramas de Classes e Estudos de Caso. Como na grande maioria, estes documentos não são encontrados fica a cargo da equipe de pesquisadores, debruçar-se sobre cada código, como faz um arqueologista decifrando um hieróglifo e se propõe a desvendar o que o programador original teria feito. | ||
| Linha 28: | Linha 28: | ||
Um fato que atrasa bastante ou inviabiliza todo o processo de conseguir um executável eficiente são as várias versões de ambientes. Para isso, é importante que o desenvolvedor avalie bem os requisitos de infraestrutura de sistema operacional, de banco de dados e de outros softwares exigidos pela solução. Feito isso, pode-se submeter os ''patches'' de correção de versão para que todos estejam alinhados quanto à ultima edição do software em avaliação. | Um fato que atrasa bastante ou inviabiliza todo o processo de conseguir um executável eficiente são as várias versões de ambientes. Para isso, é importante que o desenvolvedor avalie bem os requisitos de infraestrutura de sistema operacional, de banco de dados e de outros softwares exigidos pela solução. Feito isso, pode-se submeter os ''patches'' de correção de versão para que todos estejam alinhados quanto à ultima edição do software em avaliação. | ||
= Módulos do AutoI = | |||
A solução AutoI disponível em www.ist-autoi.eu, é dividida em vários módulos que completam toda o projeto e implementação de uma camada de recursos virtuais auto gerenciáveis. O modelo de arquitetura do AutoI consiste de vários sistemas de gerenciamento descritos com a ajuda de cinco abstrações: Plano de Orquestração, Plano de Serviços, Plano de Conhecimento, Plano de Virtualização e Plano de Gerenciamento. Juntos, estes sistemas distribuídos formam uma infraestrutura de controle de rede dirigida a software que pode ser executada no topo de qualquer estrutura física de rede. | |||
Para efetivamente criar esta visão e utilização, o AutoI propiciou um modelo muito interessante. Inicialmente foi desenvolvido o vCPI (''Virtual Controller Programming Interface'') preparado para alterar dinamicamente a infraestrutura de rede virtual e o vSPI (''Virtual System Programmability Interface''), hábil em executar operações de gerenciamento em larga escala que permite aos Planos de Orquestração e Gerenciamento controlarem recursos virtuais em grupo usando vCPI. | |||
A regra e o projeto do Plano de Orquestração dentro da arquitetura do AutoI e suas interações com outros planos do AutoI tem sido definidas, junto com o projeto inicial do DOCs (''Distributed Orchestration Components''). Além disso, o projeto dos Planos de Gerenciamento e conhecimento foram contemplados e os protótipos do AMS (''Autonomic Management Systems'') também foram desenvolvidos. Com respeito à implantação de serviços, o principal foco tem sido as redes virtuais e máquinas virtuais e o projeto do ANPI (''Autonomic Network Programming Interface''). | |||
* Testar casos específicos | * Testar casos específicos | ||
* Benchmarking | * Benchmarking | ||
Edição das 12h28min de 7 de maio de 2011
Desenvolvimento
Implementar um projeto que vise a implantação de um ambiente que permita servir de laboratório às atuais demandas da Internet é uma tarefa que requer inicialmente um estudo aprofundado das soluções em fase de desenvolvimento na comunidade global.
Os passos previstos para este projeto, pretendem como primeira etapa prospectar com bastante amplitude sobre os esforços de pesquisadores interessados em promover as mudanças para a Internet do Futuro. Um grande desafio é encontrar material atualizado porque muitas correntes de pesquisa ainda estão em fase de desenvolvimento e consequentemente não possuem muita bibliografia e se existir, os benchmarkings e estudos comparativos provavelmente serão poucos ou nulos.
Ainda assim, amparado nas publicações existentes, serão avaliados os projetos que promovem uma reformulação da arquitetura atual mas com o requisito de ser open-source para que possa existir colaboração por parte do grupo de pesquisa deste projeto.
Alguns projetos já são destaques no mundo
Descrever os resultados de algumas soluções [Caio]
De posse dos resultados da pesquisa de pŕojetos em desenvolvimento no mundo, deverá ser feita uma avaliação criteriosa das soluções encontradasa por meio de relatórios e requisitos de colaboração como: facilidade na instalação do software, documentação atualizada, participação da comunidade em foruns e discussões, requerimentos de hardware e possibilidades de cooperação efetiva.
Estas informações subsidiarão a escolha da solução mais viável. De início, com base em alguns relatos e antecipando aos trabalhos ainda a serem feitos, foi destacada a solução AutoI que possui uma estruturação interessante que facilita a colaboração e a possibilidade de colaboração com o projeto. Como essa solução não é a única, pode ser que outra solução seja eleita para ser usada pelo grupo do projeto em questão.
Sendo o AutoI, a solução escolhida ou outra, será criado uma infraestrutura para abrigar o software que deverá ser "dissecado" em todo o seu código para seu conhecimento pleno e posterior procedimentos de alteração e compilação até que se chegue com sucesso a um código executável.
O procedimento de instalação, especificamente do AutoI, é similar aos inúmeros códigos-fonte espalhados pela Internet. A partir de um endereço disponível na web, é possível descarregar o código e instalá-lo num sistema operacional linux e a partir daí, compilá-lo segundo as regras do ambiente., identificando os possíveis erros e posteriormente corrigi-los até que o executável esteja disponível.
Este primeiro passo na maioria dos casos é bem crítico porque o proccesso entre identificar os erros, corrigi-los e compilá-los é feito de uma maneira empírica. A cada erro corrigido, descobrem-se novos que geram um novo ciclo de correção. Isto não seria tão difícil se os programas-fonte fossem bem organizados e tivessem uma documentação efetiva, algo como um diagrama de Fluxo de Dados ou Diagramas de Classes e Estudos de Caso. Como na grande maioria, estes documentos não são encontrados fica a cargo da equipe de pesquisadores, debruçar-se sobre cada código, como faz um arqueologista decifrando um hieróglifo e se propõe a desvendar o que o programador original teria feito.
Apesar de ser uma tarefa árdua, tem a grande fascinação pela descoberta gradativa de cada novo cenário. A cada erro transpassado, abre-se um novo caminho que motiva o pesquisador a buscar a correção para aquele novo problema. Seria muito crítico se não houvesse a disposição algumas ferramentas como tracers, pontos de teste e identificação de bibliotecas ausentes. Nesse caso, os frameworks, ferramentas CASE com as várias funcionalidades que facilitam a vida do desenvolvedor tornam-se obrigatórias.
Além disso, em muitos casos, a comunidade mundial pode auxiliar por meio dos fóruns tecnicos onde podemos encontrar as experiências vividas por outras pessoas. Se der sorte, o pesquisador pode achar um passo a passo para a correção e compilação total dos bugs apresentados pela solução. Deve-se ter como premissa, que encontrando ou não alguma ajuda nos foruns é condição sine qua non que o pesquisador retorne sua contribuição por meio de informações sobre as experiências vividas para que a solução open source evolua com a participação efetiva de vários colaboradores.
Um fato que atrasa bastante ou inviabiliza todo o processo de conseguir um executável eficiente são as várias versões de ambientes. Para isso, é importante que o desenvolvedor avalie bem os requisitos de infraestrutura de sistema operacional, de banco de dados e de outros softwares exigidos pela solução. Feito isso, pode-se submeter os patches de correção de versão para que todos estejam alinhados quanto à ultima edição do software em avaliação.
Módulos do AutoI
A solução AutoI disponível em www.ist-autoi.eu, é dividida em vários módulos que completam toda o projeto e implementação de uma camada de recursos virtuais auto gerenciáveis. O modelo de arquitetura do AutoI consiste de vários sistemas de gerenciamento descritos com a ajuda de cinco abstrações: Plano de Orquestração, Plano de Serviços, Plano de Conhecimento, Plano de Virtualização e Plano de Gerenciamento. Juntos, estes sistemas distribuídos formam uma infraestrutura de controle de rede dirigida a software que pode ser executada no topo de qualquer estrutura física de rede.
Para efetivamente criar esta visão e utilização, o AutoI propiciou um modelo muito interessante. Inicialmente foi desenvolvido o vCPI (Virtual Controller Programming Interface) preparado para alterar dinamicamente a infraestrutura de rede virtual e o vSPI (Virtual System Programmability Interface), hábil em executar operações de gerenciamento em larga escala que permite aos Planos de Orquestração e Gerenciamento controlarem recursos virtuais em grupo usando vCPI.
A regra e o projeto do Plano de Orquestração dentro da arquitetura do AutoI e suas interações com outros planos do AutoI tem sido definidas, junto com o projeto inicial do DOCs (Distributed Orchestration Components). Além disso, o projeto dos Planos de Gerenciamento e conhecimento foram contemplados e os protótipos do AMS (Autonomic Management Systems) também foram desenvolvidos. Com respeito à implantação de serviços, o principal foco tem sido as redes virtuais e máquinas virtuais e o projeto do ANPI (Autonomic Network Programming Interface).
- Testar casos específicos
- Benchmarking
- Documentar
Adicionar estas referências no link correto:
- Autonomic Internet (AutoI) Project. Alessandro Bassi. Hitachi Europe SAS. 2008.