Uma arquitetura de referência para aplicações Web 2.0

Olá pessoal, tudo certo?

Hoje pretendo demonstrar, com considerações práticas , como planejar a arquitetura de um sistema Web partindo de uma arquitetura de referência.

Utilizar arquiteturas de referência ajuda a melhorar a “cobertura” do escopo. Além disso, otimiza o tempo de concepção de um sistema indicando claramente que questões estão relacionadas ao tipo de software que esta representa.

Sem mais delongas…

O que é uma arquitetura de referência?

Uma arquitetura de referência é um ponto de início. É uma representação, bem genérica e abstrata, que ajuda o time (e o arquiteto) na definição de elementos concretos do sistema. Elas apontam para os principais componentes a serem definidos – orientando indiretamente seus papéis, comportamentos e relacionamentos.

Arquiteturas de referência surgem da observação de determinados tipos de software. Definem e explicitam elementos comuns aplicados por vários profissionais de arquitetura no projeto de vários software de um determinado tipo. São representações em alto-nível das similaridades identificadas nessas diversas instâncias.

Considerar uma arquitetura de referência, ao conceber um novo sistema, poupa ao arquiteto um volume considerável de análise e ponderação na identificação de componentes – seus comportamentos, papéis e relacionamentos.

Arquiteturas de referência não foram criadas para atender conjuntos específicos de requisitos. Isso significa que não podemos pegar uma arquitetura de referência e apontá-la como sendo a arquitetura de um novo sistema sem a avaliação e ajustes indispensáveis. Elas são projetadas para servir como “uma indicação de caminho a seguir”. Uma arquitetura concreta surge da adaptação de uma referência para as necessidades e propósitos de um sistema específico.

Arquiteturas de referência apontam, com alguma precisão:

• cardinalidade, ou seja, uma ideia clara da quantidade de componentes necessários para o desenvolvimento um sistema;
• algumas demandas de infraestrutura.

Para cada tipo de sistema, há pelo menos uma boa arquitetura de referência. A que apresento hoje é direcionada para sistemas Web.

Começando a desenvolver uma arquitetura para sistemas Web 2.0

A arquitetura de referência apresentada aqui foi extraída do (apenas bom) livro

O diagrama que segue indica, em alto-nível, os componentes principais apontados por essa arquitetura de referência. Observe:

Os componentes dessa arquitetura são:

• Resource Tier – a base de nossa arquitetura. Provê fundação e capacita todos os serviços que serão consumidos através da Internet. Residem, geralmente, nessa camada: arquivos, banco de dados, interface com sistemas de ERP e/ou CRM, diretórios, acesso a outros sites. É também a responsável pela persistência, mas não se resume a isso;
• Service Tier – Provê conexão para os recursos (fornecidos pela camanda base). Geralmente composta por serviços. Dá ao provedor desses serviços algum controle sobre o fluxo de informações que entram e saem.
• Conectivity (setas vermelhas) – Meio pelo qual um serviço será acessado. Para que qualquer serviço possa ser consumido, ele precisa estar “visível” e “tangível” para quem o deseja consumir. Deve ser possível “entender” o que um serviço faz tanto em termos técnicos quanto em termos de negócio. Conectividade trata de protocolos e padrões;
• Client Tier – Ajuda o usuário a consumir serviços exibindo representações gráficas. Aqui fica o nosso bom “Silverlight”, por exemplo.
• Design, development, and governance tools – Conjunto de ferramentas que habilitam desenvolvedores (e parceiros) no desenvolvimento da aplicação. Tipicamente essas ferramentas são utilizadas no desenvolvimento dos componentes das camadas de serviço e cliente. Também dizem respeito a mecanismos que serão providos para expansibilidade.

Repare como a simples identificação desses “componentes” nos permite atribuir ao código uma primeira, e objetiva, separação de responsabilidades. Digamos que desejamos, por exemplo, prover conexão com o Twitter. A arquitetura de referência aponta para alguns elementos fundamentais. Observe:

• Será necessário desenvolver uma “interface” com a API do Twitter. Essa interface deverá residir somente na Resource Tier. Será através dessa interface que dados serão recuperados e submetidos. Serviços serão acionados e orquestrados;
• Também precisará existir uma "API” especifica de nossa aplicação para exercutar e orquestrar operações sobre Resource Tier. Esta é uma atribuição clara de Service Tier! Penso que, quanto mais forte for a separação do código que manipula recurso (resource) e do código que orquestra esse acesso (service), maior será a testabilidade e separação de responsabilidades;
• Para cada serviço definido em Service Tier deverá ser definido um conjunto de regras (policies) de publicação e acesso. Além disso, deverão ser selecionados protocolos e padrões que serão utilizados. Essas são atribuições de Conectivity.
• Por fim, será necessário decidir quais serão as interfaces que acessaram os dados providos pelos serviços. Podemos usar Silverlight, Flash, Views ASP.NET (whatever)

Perceba que, quanto mais clara for a distinção entre o código relacionado a cada tier, menor será o acoplamento de tecnologias.

Uma visão detalhada dessa arquitetura de referência

Se as coisas ficaram “altas” demais para você, talvez haja espaço para um nível extra de detalhamento. Segue o mesmo conceito, agora com um nível a mais de detalhes:

Mais uma vez, lembre-se que esse modelo de referência não representa uma solução final. Dependendo do seu cenário, muitas das “caixas” relacionadas podem estar presentes, ou não, em sua solução. Afinal, uma arquitetura de referência serve como uma “facilidade” para o trabalho do arquiteto, não como uma subsituta.

Esse modelo é essencialmente o mesmo apresentado anteriormente, porém, decomposto em mais detalhes. Arquitetos e agentes de negócio podem usar esse modelo quando estiverem considerando um meio de implementar um certo conjunto de padrões arquiteturais.

Observe como esse modelo permanece agnóstico quanto a tecnologia ou padrões. Isso permite que arquitetos possam decidir como implementar essa arquitetura usando padrões e tecnologias que atendam melhor suas necessidades.

Uma análise rápida do diagrama que apresentei acima aponta para diversos componentes necessários (e comuns) no desenvolvimento de aplicações Web. Felizmente (ou infelizmente) devido a riqueza dos frameworks que utilizamos hoje em dia, em aplicações mais simples, podemos nos dar ao luxo de ignorar a função de muitos desses elementos. Service Tier, por exemplo, acaba “escondida” da maioria dos desenvolvedores por frameworks como o WCF e por facilitadores como o RIA Services. 

Um pouquinho de arquitetura forense

Infelizmente, poucos são os sistemas Web disponíveis no mercado onde a equipe possua uma noção clara das decisões arquiteturais relacionadas ao projeto. Por isso, talvez seja hora de você praticar um pouquinho de arquitetura forense.

Arquitetura Forense é o processo de explicitar a arquitetura de um sistema depois que este tenha sido desenvolvido.

Arquitetos de software geralmente utilizam um vocabulário rico e artefatos para descrever uma arquitetura. Logo, fazer arquitetura forense, consiste em criar alguns desses artefatos, utilizando esse vocabulário, para um sistema que já está pronto (ou em desenvolvimento).

Como exercício, recomendo que você tente identificar, no sistema Web que você está trabalhando hoje, os componentes de seu sistema baseando-se na arquitetura de referência que apresentei.

Por hoje, era isso