Partilhar via

Azure Issue Tracker : integração entre o enterprise e a nuvem

  • Artigo

Olá pessoal, tudo certo?

Já falamos aqui sobre o Azure Issue Tracker, uma solução SaaS (Software as a Service) que aproveita os recursos de computação na nuvem sobre o Windows Azure (veja aqui).

Um aspecto interessante dessa solução é sua integração entre as máquinas do enterprise e as API’s da solução, fazendo uso do Access Control do .NET SERVICES para controle de acesso e autorização de usuários. A figura a seguir exemplifica essa infra-estrutura:

image

Vemos que através da identificação do usuário enterprise junto ao Provedor de Identidades STS local, os vários agentes de monitoração da infra-estrutura local ganham acesso à API de gerenciamento (Management API) do Azure Issue Tracker. Essa primeira parte da solução é responsável por popular a base de gerenciamento (Management repository) que está colocada também na nuvem (através do SQL Data Services).

A partir da coleção de dados sobre Issues capturados do ambiente Enterprise, o usuário de TI de cada empresa podem consultar as informações de sua própria infra-estrutura, a partir da aplicação Web IssueTracker Web Site, também hospedada na nuvem.

Como vemos, o modelo SaaS é respeitado na solução, considerando os vários inquilinos (tenents) suportados, assim como a escalabilidade e o espaço de armazenamento de dados (Management repository) crescente e provisionável, conforme a demanda.

Achei interessante resgatar a estrutura interna do Azure Issue Tracker aqui no blog, pois várias empresas já estão trabalhando em cenários possíveis para testes da infra-estrutura Windows Azure. Como apresentado pela solução acima, existem várias questões possíveis para a escolha de nosso cenário de testes,  como:

  • Quais dados serão publicados no SQL Data Services?

Resp.: o SQL Data Services sofrerá mudanças em breve, com o próximo CTP que deve chegar até junho/julho. Conforme anunciado no último MIX09, teremos suporte ao TDS, permitindo que a aplicação faça acesso aos dados do SQL Data Services através de um cliente SQL típico, consumindo o Modelo T-SQL que já conhecemos. Desse modo, uma aplicação irá falar com dados relacionais persistidos na nuvem, o que será bem interessante para nossas aplicações. O suporte para consultas REST/SOAP deve continuar, mas mudará em relação ao antigo ACE – Authority, Container e Entity. Mas um fator de decisão é importante: qual o crescimento esperado de espaço necessário para armazenamento de dados, assim como o custo de administração e manutenção de uma infra-estrutura para persistência de dados localmente (on-premise). Será que alguns dados (como o histórico de Issues do Azure Issue Tracker) não são aderentes ao modelo da nuvem?

  • Podemos criar toda a solução como uma aplicação WEB ASP.NET hospedada na nuvem?

Resp: sem dúvida, um exemplo natural de solução sobre o Windows Azure é a construção de uma aplicação Web, usando Web Roles e Worker Roles para a implantação de suas funcionalidades na nuvem. Nesse modelo, temos suporte ao AJAX e Silverlight 2.0, permitindo a construção de interfaces ricas para a nuvem. Como estamos numa solução que caminha para o modelo SaaS, não podemos esquecer do tratamento multi-inquilino, que envolve o metadado sobre os vários clientes usuários da solução, assim como o tratamento de controle de acesso e autorização, que deve aproveitar os recursos do Access Control do .NET Services. Isso significa que um modelo de dados de metadados e metaconfiguração torna-se importante, para a personalização da interface e funcionalidades de forma dinâmica, de acordo com a empresa ativa na solução. Na solução do Issue Tracker isso aparece nos componentes de configuração, gerenciamento de contas e gerenciamento de tarefas, de acordo com um metadado de inquilios ativos.

  • Quais funcionalidades de serviços devo registrar no Service Bus do .NET Services Bus?

Resp: pense que estamos registrando serviços locais para o discovery na nuvem. Usando ainda o Access Control, podemos autenticar os usuários que irão consumir esses serviços de uma forma transparente, independente de chamadas feitas a partir da nuvem ou do ambiente enterprise (local). Um cenário interessante é mapear os serviços que podem oferecer REUSO a partir da nuvem, publicados para sistemas e clientes externos consumirem.

  • Como faço a autenticação e autorização da aplicação?

Resp: autenticação e autorização passam pela projeto “Geneva” e pelo Access Control. O Azure Issue Tracker utiliza a versão Beta do “Geneva” para a emissão de identidades baseadas em declarações (ou “claims”) que é a base do modelo CBA – Claim-based Authentication. Através dele, podemos usar qualquer tipo de provedor de identidades, abrindo as possibilidades para diversos mecanismos presentes no ambiente enterprise. Através das declarações, os atributos escolhidos para descrever os usuários são usados para autorizar o acessos em chamadas feitas para serviços e aplicações na nuvem. Segurança será sempre um aspecto importante num modelo SaaS sobre a nuvem.

Enfim, essas são apenas algumas das questões comuns presentes num modelo de computação na nuvem. Outros aspectos existem como transação, tratamento de exceção, monitoração, etc. Assim como vimos no post anterior, ainda é possível coordenar regras de negócio como workflow services, o que permite novas combinações na nuvem.

Em posts futuros, vamos continuar avaliando cenários reais, enquanto estudamos soluções possíveis para nossos projetos na nuvem.

Para saber mais sobre o Azure Issue Tracker, confira o link a seguir:

Azure Issue Tracker
Ref.: https://www.codeplex.com/azureissuetracker

Finalmente, se você já está construindo seus projetos no Windows Azure, fique a vontade para divulgar e comentar suas experiências aqui no blog. Se preferir, coloque também uma discussão no ARQBR, para que todos possamos aprender juntos. O canal está aberto! Pensar em equipe é sempre mais legal! :)

Por enquanto é só! Até o próximo post :)

Waldemir.

Comments