RemoteServer.NET

A arquitetura em camadas tem sido amplamente adotada pelos analistas e desenvolvedores de sistemas computacionais. Isso porque esta arquitetura favorece a aplicação de vários conceitos envolvendo a engenharia de software como, por exemplo, modularidade, manutenibilidade, etc. O conceito que motivou a escrita deste post é a escalabilidade, ou seja, o desafio de construir sistemas preparados para “crescer”. Um sistema e dito escalável, por exemplo, quando seu desempenho aumenta com acréscimo de hardware. Não estou falando em ficar mais rápido por que agora ele está rodando em um servidor mais rápido do que o antigo. Estou falando em potencial de crescimento e adaptação a cenários de produção. Imagine a situação: Uma pequena empresa com poucos recursos financeiros requisitou da equipe de TI um sistema de gestão empresarial. Após levantamento de requisitos, avaliação das condições de infraestrutura, decidiu-se pela seguinte configuração: arquitetura cliente/servidor. Um servidor de banco de dados foi colocado na rede e a aplicação cliente faria solicitações a este servidor. A aplicação cliente implementava todas as regras de negócio do sistema de gestão e o servidor de banco de dados serviria apenas como repositório de dados. A princípio tudo funcionava bem: LAN com poucos usuários, poucos dados no banco… Mas a empresa cresceu. Mais usuários na rede, maior volume de dados, novas filiais, negócios via internet, novas regras de negócio, etc. Já está claro que o velho sistema precisaria ser reescrito. Talvez até em outra plataforma de desenvolvimento. Sem falar que, possivelmente, novos especialistas em TI precisarão ser contratados ou, pelo menos, os anteriores terão que passar por algum treinamento/reciclagem. Tudo isso porque não se pensou na possibilidade do sistema crescer em necessidades de regras de negócio juntamente com a necessidade de infraestrutura. A pequena empresa, hoje, tem condições para investir em mais computadores-servidores, internet, redes de longa distância. Ela tem alto volume de dados que precisam ser tratados com velocidade dentro e fora do ambiente da empresa. Eu pergunto: é qualquer sistema que pode se adaptar a esta nova realidade? O grande desafio é CONSTRUIR SISTEMAS PREPARADOS PRA CRESCER. O sistema não precisa nascer grande mas deve possuir características que, com pequenas adaptações, tenha seu potencial aumentado.

Um bom começo para quem prentende trabalhar com escalabilidade é verificar se seu sistema admite a possibilidade de trabalhar utilizando um servidor de aplicação: as aplicações clientes (desktop ou web) fazem requisições a um servidor. Neste servidor estão implementados todas as regras de negócio e esse servidor faz acesso ao banco de dados para, então, responder às solicitações. Para utilizar essa proposta, que modificações voce teria que fazer no seu sistema?

  1. Teria que reescrever o sistema em outra plataforma?
  2. Teria que efetuar algumas mudanças sim. Voce acha que dá pra fazer? Em quanto tempo?
  3. Teria que, primeiro ser treinado em ambiente em camadas pra depois pensar nisso?
  4. Teria que, primeiro mudar sua forma de programar?
  5. Teria que colocar as regras de negócio da aplicação em um só lugar para depois pensar no servidor de aplicação?
  6. Teria que modelar o sistema primeiro em orientação a objetos?
  7. Outro “teria” qualquer….

Veja que parece simples responder a esta pergunta mas não é tão imediato assim. Nem todos os sistemas são preparados para isso efetivamente. Outras respostas:

  1. Construimos o sistema com esta visão. Foi previsto que o projeto teria grande possibilidade de crescimento tanto em recursos quanto em necessidades.
  2. Sim. É só modificar o arquivo de configurações do sistema para que as aplicações clientes façam solicitações para o servidor.
  3. Sim. Só preciso modificar uma linha do sistema, recompila-lo e recolocá-lo em produção.
  4. Quantos servidores posso utilizar? Pelo menos um servidor para DAO´s e banco de dados e um outro servidor de regra. Poderiam ser mais servidores de aplicação espalhados pela rede. Depende apenas do nível de resposta que a empresa pretende ter e da disponibilidade de recursos físicos.
  5. O sistema permite dividir papéis facilmente.
  6. Outros “só se for agora” qualquer….

Se voce puder utilizar alguma dessas respostas, parabéns. Voce já está no caminho certo. É essa linha que a engenharia de software moderna quer que os novos sistemas sigam. Para aqueles que aindam não perseguem estes objetivos vou tentar passar algumas dicas como roteiro inicial a seguir.

Eu utilizava .NET 1.1 quando me fiz a seguinte pergunta: Em J2EE, pode-se configurar a utilização de um servidor de aplicação através dos EJB containers. JBoss é um exemplo de servidor de aplicação gratuito em Java. Pode-se também construir aplicações distribuidas com JavaRMI. E qual o servidor de aplicação para .NET e como construir aplicações distribuidas??? Há um tempo atrás fui a uma apresentação sobre .NET 2.0 com Visutal Studio 2005. Na saída fiz essa pergunta ao facilitador e ele me respondeu com uma palavra: “Remoting”. Ao chegar em casa me dediquei a pesquisar sobre o assunto. A seguir, deixo indicado um artigo que serviu de base para nossa trajetória sobre o assunto:

.NET Remoting – Parte 1 – Acessando informações remotamente
.NET Remoting – Parte 2 – Acessando informações remotamente

NOTA: A Microsoft recomenda a utilização do  Windows Communication Foundation (WCF)  para implementar arquitetura baseada em serviço e/ou distribuídas. O .NET Remoting foi preservado apenas por compatibilidade retroativa e ela não recomenda mais seu uso em novas aplicações. Por outro lado, eu ainda prefiro utilizar o recurso pela simplicidade de configuração.

Desde então temos trabalhado para que a construção dos nossos sistemas tenham carateríscas que viabilizem a arquitetura de acesso remoto. As pessoas que acompanharam em nosso blog os post entitulados NHIbernate + Visual Studio: Construindo aplicações em camadas devem ter notado em algumas partes dos códigos e da explanação a presença de flags para utilização de servidor de aplicação. E ainda nestes post nós desenvolvemos uma aplicação que utiliza este conceito e implementamos juntamente com a solução chamada RemoteServer.NET que foi desenvolvida também Visual Studio.NET com 3 projetos que casa perfeitamente com esses indicadores:

  1. RemoteServerWin: Um servidor de aplicação utilizando .NET Remoting que roda como aplicação do windows.
  2. RemoteServerService: Um servidor de aplicação, também utilizando .NET Remoting que roda como serviço do windows.
  3. RemoteServerSetup: Um instalador dos projetos anteriores.

Vamos entender o esquema abaixo numa proposta didática, porém bem próxima de uma arquitetura ideal:

No ínicio do processo temos um usuário utilizando o seu computador para fazer solicitações ao servidor web através de um navegador. O servidor web é responsável apenas pela apresentação e desenho da página web. Qualquer necessidade de processamento de regras de négocio deverá ser enviada ao servidor de negócio. A linha usuario-navegador-servidor web-servidor de negócio poderia ser subistituida por outras configurações: celular-servidor web-servidor de negócio, aplicativo windows-servidor de negócio, etc. O fato é que o servidor de negócio precisa está preparado para receber e responder a requisições remotas. Neste servidor estaria configurado o RemoteServer.NET para responder solicitações da camada de apresentação. Algumas vezes o servidor de aplicação precisaria acessar dados do banco de dados. Esse acesso, de acordo com padrões de projetos e arquitetura em camadas deveria ser através de DAO´s. Logo poderiamos ter um servidor DAO para responder requisições feitas pelo servidor de negócio. Neste servidor DAO também teria instalado o RemoteServer.NET para responder requisições remotas. Por fim, temos uma máquina como servidor de banco de dados para acesso a dados.

As possibilidades são inúmeras. Imagine um enorme volume de usuários fazendo acesso ao servidor de regra. Poderiamos colocar novos servidores de negócio pra dividir a carga ou mesmo, mais servidores de acesso a dados fazendo com que as requisições fossem aleatórias a estes servidores evitanto o engarrafamento de requisições no mesmo servidor. Poderiamos também fazer replicação sincrona de dados no banco ou mesmo, utilização de cluster para dividir a carga de acesso ao banco de dados. Tudo dependendo do potencial do parque de informática da empresa e necessidade de acesso rápido às informações. Adicionemos a tudo isso uma dose de XML Web Service para que outra aplicações possam conectar-se diretamente a seu servidor de regras via web.

As aplicações que voce desenvolve suporta essas possibilidades?  Isso é ESCALABILIDADE.

Estamos disponbilizando a solução RemoteServer.NET para aqueles que desejarem adquirir e ampliar seus horizontes. Vale lembrar que o RemoteServer.NET sozinho não faz milagre. A aplicação como um todo deve ser pensada para suportar esse requisito. O primeiro passo é repensar seus conceitos em desenvolvimento e pesquisar sobre soluções que sejam multi-utilizáveis.

Características Técnicas

Valor Simbólico: R$ 99,99

Anúncios