Posts filed under ‘Arquitetura’

Sai uma moda, entra outra

Até pouco tempo, a moda no mundo do desenvolvimento era apenas desenvolver. Tudo que todos faziam era simplesmente escrever linhas de código, e se virar depois para garantir seu funcionamento, documentação, etc.

Agora (claro que com um salto no tempo :), o mundo fashion da tecnologia está caminhando – e isso é realmente muito bom – para a moda dos testes. Seja teste unitário, integração, regressão, entre muitos outros, a moda agora é fornecer uma possibilidade de testar seu código enquanto é desenvolvido.

E seguindo esta tendência, alguns padrões de design entram em cena como protagonistas da história. Entre eles, certo destaque para Inversion of Control (IoC) e Dependecy Injection, que não tem uma função voltada para testes, mas facilita e muito a vida quando pensamos em objetos mock e testes unitários do Visual Studio 2008, por exemplo.

Portanto, não vamos fugir da moda. Afinal, pelo menos nesse mundo, o que está nas passarelas é bonito e deve ser usado 🙂

Abraços.

Anúncios

Junho 12, 2008 at 5:06 am Deixe um comentário

Gravação de Log utilizando MSMQ e BizTalk

Contexto:
Em um projeto que trabalho, existem algumas interfaces que fazem comunicação com o Mainframe, com diferentes objetivos. Estas interfaces fazem uso excessivo de Event Viewer, para acompanhamento dos processos, visualização de erros, avisos, início e fim de processos. Atualmente existem 15 interfaces, o que gera uma quantidade alta de logs e dificulta qualquer ação sobre estas informações.

Problema:
Como criar uma solução que possibilite consultas, filtros e relatórios sobre estes Logs, sem interferir na performance do web service?

Solução:
A primeira decisão neste caso é armazenar as informações em banco de dados. E esta decisão é também a razão de inúmeras preocupações:

  1. Como garantir que este acesso ao banco, no momento da execução do web service, não irá interferir no seu processamento principal?
    1. Se o banco estiver fora, o que vai acontecer?
    2. Em caso de timeout?
    3. Em caso de demora na resposta do banco de dados?
    4. etc, etc, etc

A partir destes itens, chegamos a uma solução interessante: tratar os Logs de forma assíncrona, garantindo que o processamento principal do web service não esteja intimamente ligado à gravação de Logs.

Para isso, foi utilizando MSMQ (Microsoft Message Queue – http://www.microsoft.com/windowsserver2003/technologies/msmq/default.mspx). Este recursos funciona como uma FIFO (First In, First Out). O Web Service envia uma mensagem (LOG) para a fila e outra aplicação, em outro momento, irá tratar esta mensagem, formatando e gravando no banco de dados. Isto garante que a gravação de logs, independente de seu volume, não irá influenciar no processamento principal da aplicação.

msmq3.jpg

 

Note que na arquitetura acima, o BizTalk é responsável por ler a fila e processar a mensagem. Esta escolha foi feita pela garantia que o BTSK6 oferece e pelo seu gerenciamento. 

Abraços!

Setembro 11, 2007 at 3:24 am 1 comentário

Acessando Serviços

Este post tem o objetivo de apresentar uma solução que criei recentemente para acessar serviços externo à aplicação, obtendo os dados e formatando-os, conforme o padrão do projeto.

Problema
Obter informações de serviços externos à aplicaçao, independentemente do protocolo de comunicação, permitindo a formatação dos dados de retorno da aplicação e facilidade na execução do serviço, possibilitando fácil manutenabilidade e novos desenvolvimentos baseados nesta estrutura.

Contexto
O projeto em questão acessa dados em duas fontes diferentes, Commerce Server 2007 e SQL Server 2005.

Além destas duas fontes, o projeto terá que acessar dados obtidos a partir de outro serviço, seja por HTTP, SOAP, WCF, etc.

Solução
Para estabelecer qualquer tráfego de informações, será necessário determinar qual é o meio de comunicação, a formatação dos dados (pois as duas partes conversam em “idiomas” diferentes) e ainda por cima, como garantir que isto tudo seja configurável.

Para todos estes requisitos, resolvi criar uma solução que separasse em camadas da seguinte maneira:

  1. ServiceGateway: ou se desejarem, Remote Façade. Esta camada centraliza todas as chamadas aos serviços.
  2. ServiceGatewayImplementation: Responsável por criar o meio de comunicação, obter os dados e formatá-los.
    1. Para criar o meio de comunicação, utilizei o conceito de canais (mesmo de WCF). Estes canais são instanciados através de um Factory, que deverá decidir, a partir de uma configuração no web.config, qual o tipo de canal que será utilizado (HTTP, SOAP, WCF, etc).
    2. Para formatar os dados, utilizei uma camada chamada Assembler, que receberá, de forma genérica, os tipos de origem e de destino de cada objeto.

clip_image002_thumb3

Como podem ver, a camada de serviços é invocada a partir de uma camada BusinessObject. O service gateway pode efetuar alguma validação, mas normalmente irá repassar a chamada para a GatewayImplementation, centralizando a menor quantidade de lógica possível.
Já a GatewayImplementation é quem concentra a orquestração desta comunicação. Ela irá obter, através de um factory (ChannelFactory), o canal responsável pela comunicação. Este factory irá retornar o tipo de canal adequado (HTTP, WCF, SOAP, etc) de acordo com uma configuração no web.config, para um determinado provider. Este canal é quem executa a requisição, após a configuração do endereço do serviço e de seus parâmetros. Note que o canal é uma classe generic, o que possibilitará uma maior performance, sem executar boxing e unboxing.

IChannel<DataSet> channel = ChannelFactory<DataSet>.CreateChannel(“ProviderName”);
channel.SetServiceAddress(DigipixConstants.EnderecoLoginCliente);
channel.SetParameter<string>(“LOGIN”, “anobre@brq.com”);
return channel.Execute();

No retorno da execução, quando necessário, o Assembler deveré ser chamado para formatar os dados. Esta classe também é generic, e irá receber a informação do tipo do objeto que está recebendo, o tipo para o qual irá formatar e o objeto a ser formatado. Desta maneira,  fácil identificar qual o comportamento de formatação deverá ser executado (algo como “Se estou recebendo um XmlDocument e preciso transformar em um objeto Pedido, sei o que fazer!”).

DigipixAssembler<XmlDocument, Pedido> assembler = new DigipixAssembler<XmlDocument, Pedido>();
Pedidopedido = assembler.Assemble(channel.Execute());

Aguardo opiniões a respeito 🙂

Abraços!

Agosto 15, 2007 at 12:44 pm 2 comentários

Camadas com elementos Web?

Recentemente tive que expor as funcionalidades de um projeto Web em serviços (Web Services e WCF). Este projeto tem uma arquitetura em 5 camadas, tendo como apresentação páginas ASPX.

Em todas as execuções, logo no início através de httpHandlers, são criados contextos de usuários, produtos, etc. Estes contextos são baseados em elementos web, como HttpContext, utilizam cookies, etc.

O problema está em onde utilizar este contexto de forma correta, para que, quando utilizado em algum sistema que não fornece este contexto, o mesmo código funcione.

Neste projeto, muitos recursos web, como HttpContext, Session, etc, eram utilizandos em camadas auxiliares (Helpers) e de regras de negócio (BusinessObject). Quando as funcionalidade, através de um Façade/ESB, foram expostas para os serviços, várias exceções foram lançadas, pois os contextos estavam nulos.

Moral da história: Refactoring! Temos que saber definir corretamente o limite entre Web e a aplicação. Até onde posso associar componentes web na minha arquitetura? Eis a questão! 🙂 

Julho 5, 2007 at 3:36 am 2 comentários

Arquitetando o impossível…

Servidores, firewall, DMZ, Zones, Load Balance, Cluster, amém.
É engraçado que existem tantas siglas mas mesmo assim, quando em produção, parece que falta alguma coisa.

É realmente muito difícil fazer uma arquitetura de infra-estrutura funcionar perfeitamente, como esperado. Assim como as aplicações se comportam de forma diferente (pelo menos um pouco vai) quando entram em produção.

A questão é: como ter o menor impacto, ter as mínimas mudanças? Como garantir um ambiente confiável, escalável, 24×7?

Claro que este artigo não tem as respostas para essas perguntas, mas pode ajudar em alguma coisa 🙂

http://msdn2.microsoft.com/en-us/arcjournal/bb491120.aspx

Abraços!

Junho 19, 2007 at 2:05 am Deixe um comentário

Pragmatic Architecture: Layering

Um artigo interessante envolvendo arquitetura.

Summary: Why, precisely, do we build systems using the n-tier architectural model, again? It’s a basic article of faith in software that, when presented with a new project, we divide the system cleanly into three tiers: the presentation tier, the business-logic tier, and the data-access or resource tier. Doing things “just because they’ve always been done that way” deserves re-examination.

Novembro 9, 2006 at 3:32 pm 1 comentário


Calendário

Outubro 2017
S T Q Q S S D
« Ago    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Posts by Month

Posts by Category