Vamos falar um pouco sobre o modelo de desenvolvimento atual, mais especificamente sobre o modelo baseado em COM/COM+ da Microsoft. Para falar sobre este assunto vamos fazer um histórico sobre o desenvolvimento, desde os bons e velhos tempos do MS-DOS.

Ai que saudade do MS-DOS???

Não, não é saudade da época do MS-DOS, apenas uma breve recapitulação. Para desenvolver aplicações para o ambiente MS-DOS, utilizamos diversas linguagens de programação, tais como:

• Clipper
• Pascal – Turbo Pascal
• Basic
• C – Turbo C
• C++

Um programa para o ambiente MS-DOS, na grande maioria das vezes era composto por um arquivo executável (.exe). Os demais arquivos necessários ao funcionamento do programa, tais como imagens gráficas ou arquivos de dados, eram salvos, normalmente, no mesmo diretório (na época do MS-DOS não falávamos em Pastas) do arquivo executável e tudo funcionava perfeitamente bem.

Para instalar o programa em outro computador, bastava copiar o diretório do programa e pronto, nada mais precisava ser feito. Podemos ver que o processo de instalação era bastante simplificado, mas em contrapartida o desenvolvimento era todo manual e as funcionalidades bastante limitadas. As redes locais ainda não eram realidade e a grande maioria dos programas era feito para trabalhar em um único computador, acessando dados locais.

Comunicação entre programas, reaproveitamento de código e acesso via rede, eram coisas raras ou inexistentes. Para as necessidades da época, era um modelo plenamente satisfatório. A maior prova disso é que, ainda hoje, facilmente encontramos programas feitos em Clipper, para o ambiente MS-DOS, rodando em pequenos estabelecimentos, dando suporte a todas as operações diárias. Tente você propor que estas pessoas substituam seus programas em Clipper, que atendem perfeitamente às necessidades destes pequenos estabelecimentos, por programas para Windows com interface gráfica. Com certeza você receberá um sonoro “NÃO”.

Porém logo as redes começariam a invadir as empresas, os programas a tornar-se mais complexos. Com o advento das redes e do sucesso dos PCs, mais e mais pessoas começaram a utilizar computadores. A velha interface a caracter do MS-DOS não atendia mais as necessidades. Neste momento é que o Windows começa a surgir no mercado.

Prazer. Eu sou o Windows!

Com a chegada doWindows tivemos a popularização das interfaces gráficas e de termos como: mouse, ícone, atalho e janelas. As ferramentas para desenvolvimento no ambiente Windows custaram a chegar. No início a programação tinha que ser feita em linguagem C, utilizando as APIs (Application Program Interface) do Windows.

Com o lançamento do Visual Basic 1.0 teve início a era das ferramentas gráficas para desenvolvimento de programas para o Ambiente Windows.

Com o Windows já passou a existir o conceito de Instalar o programa. A instalação do programa não se limitava a uma simples cópia de arquivos. Ao instalar um programa no Windows, o mesmo gravava uma série de informações de configuração: no Windows 3.x em arquivos .ini e no Windows 9x na Registry do Sistema Operacional. Além destas informações de configuração, partes do programa eram disponibilizadas no formato de arquivos .DLL (Dynamic Link Library). Falando assim paraecia um modelo, digamos, bastante elegande. Um local centralizado para informações sobre configuração e o programa dividido em partes menores, que no conjunto forneciam a funcionalidade do programa.

Porém o modelo de programação para o Windows começou a apresentar uma série de inconvenientes. Vamos falar destes inconvenientes, através de exemplos:

• Se alguma das configurações, necessárias ao funcionamento do programa, fossem alteradas,o programa deixava de funcionar. Isto gerava uma chamada ao pessoal de suporte que, na maioria das vezes, somente conseguia resolver a situação reinstalando o programa.
• Os arquivos .DLL poderiam ser utilizados por mais do que um programa. Pode acontecer uma situação em que um programa que esteja sendo instalado, substitua uma determinada .DLL por uma versão mais nova do que a versão da .DLL atualmente existente no sistema. O problema é que podem existir programas que dependam da versão mais antiga. Nesta situação os programas que dependem da situação mais antiga simplesmente deixarão de funcionar. Pode também acontecer o contrário, ou seja, um programa que está sendo instalado, substitui uma .DLL por uma versão mais antiga, fazendo com que outros programas deixem de funcionar. Em situações mais críticas poderia acontecer do programa que está sendo instalado, substituir uma .DLL vital para o Windows. Nestas situações todo o sistema deixaria de funcionar e em alguns casos, somente uma reinstalação poderia resolver o problema.

Vejam que o que parecia uma boa solução, acabou se mostrando um verdadeiro pesadelo para gerenciar e manter em funcionamento. Neste époco surge, inclusive, a expressão “DLL Hell”, que poderíamos traduzir por: “O Inferno das DLLs.”

• Cada vez que um programa fosse alterado, o mesmo precisaria ser reinstalado em todas os computadores onde fosse necessária a nova versão. E se ao fazer a atualização para a nova versão, fosse substituída alguma .DLL necessária ao funcionamento de algum outro programa? Novos problemas para o pessoal do suporte. Vejam que este modelo gera uma grande carga de suporte, o que encarece muito a manutenção em funcionamento de uma estação de trabalho da empresa.

Redes e Internet – mais problemas (ou soluções) à vista!

Com o advento das redes como uma realidade nas empresas e com a explosão da Internet como uma plataforma viável para fazer negócios, os modelos de desenvolvimento de aplicações sofreram profundas mudanças.

Primeiro, com as redes, foi a época da “febre” em descentralizar as estruturas de TI e migrar para o modelo Cliente/Servidor, baseado em redes locais. Neste modelo, também conhecido como modelo de duas camadas, temos um ou mais equipamentos de maior capacidade de processamento, atuando como Servidores. Nas estações de trabalho dos usuários, conhecidas como clientes, são instalados programas, que fazem acesso a recursos residentes nos servidores. O exemplo mais típico de aplicação Cliente/Servidor, seria uma aplicação desenvolvida em Visual Basic ou Delphi, a qual acessa dados de um servidor SQL Server 2000, instalado em um servidor da rede. Na Figura 1.4, temos uma visão geral do modelo Cliente/Servidor.

Figura 1.4 O modelo Cliente/Servidor.

Vamos falar um pouco mais sobre o modelo de duas camadas.

Modelo em 2 camadas.

No início da utilização do modelo Cliente/Servidor, as aplicações foram desenvolvidas utilizando-se um modelo de desenvolvimento em duas camadas. Neste modelo, um programa, normalmente desenvolvido em um ambiente de desenvolvimento, como o Visual Basic, Delphi ou Power Builder, é instalado em cada estação de trabalho - Cliente. Este programa acessa dados em um servidor de banco de dados, conforme ilustrado na Figura 1.5:

Figura 1.5 O Modelo de desenvolvimento em duas camadas.

Neste modelo , temos um programa que é instalado no Cliente. Programa esse que faz acesso ao banco de dados que fica residente no Servidor de Banco de dados. Na maioria dos casos, a máquina do cliente é um PC rodando Windows, e a aplicação Cliente é desenvolvida utilizando-se um dos ambientes conhecidos, conforme citado anteriormente. Sendo a aplicação cliente, um programa para Windows (na grande maioria dos casos), a mesma deve ser instalada em cada um das estações de trabalho da rede. É o processo de instalação normal, para qualquer aplicação Windows. No modelo de 2 camadas, a aplicação Cliente é responsável pelas seguintes funções:

• Apresentação: O Código que gera a Interface visível do programa, faz parte da aplicação cliente. Todos os formulários, menus e demais elementos visuais, estão contidos no código da aplicação cliente. Caso sejam necessárias alterações na interface do programa, faz-se necessária a geração de uma nova versão do programa, e todos as estações de trabalho que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações da interface. Aí que começam a surgir os problemas no modelo em 2 camadas: Uma simples alteração de interface, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de estações de trabalho. O gerenciamento desta tarefa, é algo extremamente complexo e oneroso financeiramente.
• Lógica do Negócio: As regras que definem a maneira como os dados serão acessados e processados, são conhecidas como “Lógica do Negócio”. Fazem parte das Regras do Negócio, desde funções simples de validação da entrada de dados, como o cálculo do digito verificador de um CPF, até funções mais complexas, como descontos escalonados para os maiores clientes, de acordo com o volume da compra. Questões relativas a legislação fiscal e escrita contábil, também fazem parte da Lógica do Negócio. Por exemplo, um programa para gerência de Recursos Humanos, desenvolvido para a legislação dos EUA, não pode ser utilizado, sem modificações, por uma empresa brasileira. Isso acontece porque a legislação dos EUA é diferente da legislação brasileira. Em síntese, as regras para o sistema de Recursos humanos são diferentes. Alterações nas regras do negócio são bastante freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país. Com isso,  faz-se necessária a geração de uma nova versão do programa, cada vez que uma determinada regra muda, ou quando regras forem acrescentadas ou retiradas. Desta forma,  todos as estações de trabalho que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações . Agora temos mais um sério problema no modelo de 2 camadas: Qualquer alteração nas regras do negócio, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O que já era complicado, piorou um pouco mais.

Com a evolução do mercado e as alterações da legislação, mudanças nas regras do negócio são bastante freqüentes. Com isso o modelo de duas camadas, demonstrou-se de difícil manutenção e gerenciamento, além de apresentar um TCO – Total Cost Ownership (Custo Total de Propriedade) bastante elevado.

A outra camada, no modelo de 2 camadas, é o Banco de dados, o qual fica armazenado no Servidor de banco de dados.

Sempre que um determinado modelo apresenta problemas, aparentemente intransponíveis, a indústria de informática parte para a criação de novos modelos. Em busca de soluções para os problemas do modelo de duas camadas, é que surgiu a proposta do modelo de 3 camadas, conforme analisaremos a seguir.

Aplicações em 3 camadas.

Como uma evolução do modelo de 2 camadas, surge o modelo de três camadas. A idéia básica do modelo de 3 camadas, é retirar as Regras do Negócio, da aplicação Cliente e centralizá-las em um determinado ponto, o qual é chamado de Servidor de Aplicações. O acesso ao banco de dados é feito através das regras contidas no Servidor de Aplicações. Ao centralizar as Regras do Negócio em um único ponto, fica muito mais fácil a atualização das mesmas. A Figura 1.6, nos dá uma visão geral do modelo em 3 camadas:

Figura 1.6 O Modelo de desenvolvimento em três camadas.

Todo o acesso do cliente, aos dados do servidor de Banco de dados, é feito de acordo com as regras contidas no Servidor de Aplicações. O cliente não tem acesso aos dados do servidor de Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as três camadas são as seguintes:

• Apresentação: Continua no programa instalado no cliente. Alterações na Interface do programa, ainda irão gerar a necessidade de atualizar a aplicação em todos as estações de trabalho, onde a aplicação estiver sendo utilizada. Porém cabe ressaltar, que alterações na interface, são menos freqüentes do que alterações nas regras do negócio.
• Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados e manipulados. Esta camada foi deslocada para o Servidor de Aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de Aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de Aplicações, estamos facilitando a tarefa de manter a aplicação atualizada. As coisas estão começando a melhorar.
• Dados: Nesta camada temos o servidor de banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Cabe reforçar, que os dados somente são acessados através do Servidor de Aplicação, e não diretamente pela aplicação cliente.

Com a introdução da camada de Lógica, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de estações de trabalho, toda vez que uma regra do negócio for alterada. Porém continuamos com o problema de atualização da interface da aplicação, cada vez que sejam necessárias mudanças na Interface. Por isso que surgiram os modelos de n-camadas.

No próximo tópico, iremos falar um pouco sobre o modelo de 4 camadas

Aplicações em quatro camadas.

Como uma evolução do modelo de três camadas, surge o modelo de quatro camadas. A idéia básica do modelo de 4 camadas, é retirar a apresentação do cliente e centralizá-las em um determinado ponto, o qual na maioria dos casos é um servidor Web. Com isso o próprio Cliente deixa de existir como um programa que precisa ser instalado em cada computador da rede. O acesso a aplicação, é feito através de um Navegador, como por exemplo, o Internet Explorer ou o Netscape Navigator.  A Figura 1.7, nos dá uma visão geral do modelo em quatro camadas:

Figura 1.7 O Modelo de desenvolvimento em quatro camadas.

Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador, como no exemplo

http://intranet.minhaempresa.com/sistemas/vendas.aspx

Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso temos as seguintes camadas:

• Cliente: Nesta caso o Cliente é o Navegador utilizado pelo usuário, quer seja o Internet Explorer, quer seja o Netscape Navigator, ou outro navegador qualquer.
• Apresentação: Passa para o Servidor Web. A interface pode ser composta de páginas HTML, ASP, PHP, Flash ou qualquer outra tecnologia capaz de gerar conteúdo para o navegador. Com isso alterações na interface da aplicação, são feitas diretamente no servidor Web, sendo que estas alterações estarão, automaticamente, disponíveis para todos os Clientes. Com este modelo não existe a necessidade de reinstalar a aplicação em todos os computadores da rede. Fica muito mais fácil garantir que todos estão tendo acesso a versão mais atualizada da aplicação. A única coisa que o cliente precisa ter instalado na sua máquina, é o navegador.
• Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada está no Servidor de Aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de Aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada estação de trabalho da rede. Vejam que ao centralizar as regras do negócio em um Servidor de Aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
• Dados: Nesta camada temos o servidor de banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação.

Com o deslocamento da camada de apresentação para um Servidor Web, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que uma a interface precisar de alterações.  Neste ponto a atualização das aplicações é uma tarefa mais gerenciável, muito diferente do que acontecia no caso do modelo em 2 camadas.

Os servidores de Aplicação, Web e banco de dados, não precisam, necessariamente ser servidores separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de servidor de Aplicação, servidor Web ou servidor de Banco de dados, é um conceito relacionado com a função que o servidor desempenha. Podemos ter, em um mesmo equipamento, um Servidor de aplicações, um servidor Web e um servidor de banco de dados. Claro que questões de desempenho devem ser levadas em consideração.

Também podemos ter a funcionalidade do Servidor de Aplicações distribuída através de vários servidores, com cada servidor tendo alguns componentes que formam parte das funcionalidades da aplicação. Este modelo onde temos componentes em diversos equipamentos, é conhecido como Modelo de Aplicações Distribuídas. Também podemos colocar os componentes em mais do que um servidor para obtermos um melhor desempenho, ou redundância, no caso de um servidor falhar.

Questões a considerarmos nos modelos de 3 ou mais camadas utilizados atualmente.

Muitas são as vantagens dos modelos de 3 ou mais camadas, em relação a facilidade de gerenciamento e atualização das aplicações. Mas se tudo funciona tão bem, porque precisamos de um novo modelo de programação – leia-se Framework .NET?

Para responder a pergunta anterior, vamos continuar colocando alguns problemas com o modelo de desenvolvimento em uso atualmente, que é o modelo de n-camadas, com aplicações que utilizam componentes distribuídos através de diversos servidores: Servidor Web, de aplicações, de banco de dados,etc.

O modelo de programação atual, para o ambiente Windows, é fortemente baseado no conceito de componentes. No exemplo do modelo de 4 camadas, quando uma aplicação cliente acessa uma regra de negócio, esta regra de negócio é implementada na forma de um componente COM/COM+. O regra de negócio pode utilizar um outro componente para fazer a conexão com o banco de dados e retornar os dados solicitados pela aplicação. Para que os diversos componentes possam comunicar-se e trocar informações, os mesmos precisam de um padrão para a troca de mensagens. O padrão determina a estrutura interna do componente e a maneira como cada componente expõe suas funcionalidades. O padrão para o ambiente Windows é chamado, a partir do Windows 2000,  de COM+. Para o Windows NT 4.0 e versões anteriores, tínhamos o COM/DCOM trabalhando em conjunto com o MTS – Microsoft Transaction Server.

Mas se existe um padrão para troca de mensagens qual é o problema? Acontece que a implementação de componentes utilizando COM/COM+ não é das tarefas mais simples. Se utilizarmos linguagens como o Visual C++, a criação e disponibilização de componentes é uma tarefa que exige programadores altamente especializados. Já com ferramentas como o Visual Basic e Delphi, a criação de componentes para o padrão COM+ é um pouco mais fácil. Porém a grande dificuldade é fazer com que componentes implementados em diferentes linguagens, sejam capazes de trabalhar em conjunto e trocar mensagens entre si.

Agora imagine as dificuldades em um ambiente onde devemos criar aplicações para a Internet, onde deve existir uma maneira padronizada para que os diversos componentes sejam capazes de se comunicar. A Microsoft com a sua iniciativa DNA, procurou disponibilizar informações para que seja possível tirar o máximo do modelo COM+, na criação de aplicações em n-camadas para a Internet. Porém a própria Microsoft reconheceu as limitações e dificuldades deste modelo, ao propor uma nova revolução nos métodos e práticas de desenvolvimento, revolução essa que atende pelo singelo nome de .NET.

Outro fator importante a considerar é que o padrão COM/COM+ é um padrão proprietário, desenvolvido pela Microsoft. Como fazer com que um padrão proprietário possa ser utilizado, sem maiores problemas para aplicações distribuídas na Internet? Fica muito difícil, para não dizer impraticável. Já com o .NET, conforme comentamos anteriormente, utiliza-se padrões não proprietários, como XML para os dados e SOAP sobre HTTP como protocolo de transporte. Desta forma a comunicação entre Web Services acontece de uma maneira fácil, sem maiores problemas.

Para que um componente COM/COM+ possa ser utilizado, o mesmo precisa ser registrado no servidor que irá disponibilizar o componente para isso. Ao registrar o componente, são gravadas informações sobre o mesmo, na registry do Sistema Operacional. O programador precisa preocupar-se em garantir que o componente seja registrado corretamente, pois caso contrário, o mesmo não poderá ser acessado. Já os serviços do .NET não necessitam de registro, sendo que toda a informação necessário para que os mesmos funcionem , está contida no próprio serviço, no formato de metadados – Metadata. Mais adiante falaremos um pouco mais sobre Metadata.

Com componentes COM/COM+, o programador precisa preocupar-se em carregar o componente na memória, retirar o componente da memória quando o mesmo não for mais utilizado e uma série de outras funções necessárias ao funcionamento do componente. Com o .NET, todas estas “preocupações” foram transferidas para o Framework .NET. Isto faz com que o programador somente tenha que codificar a funcionalidade do serviço que está sendo desenvolvido, a parte mais, digamos assim: “chata”, será de responsabilidade do Framework .NET, mais especificamente do CLR. Isso aumenta a produtividade do programador e evita erros mais graves, os quais normalmente fazem com que o componente não funcione corretamente.

Já apresentamos os principais problemas do modelo atual, no restante deste capítulo veremos os demais elementos que compõem o Framework .NET e como, cada um destes elementos, procura solucionar problemas que os modelos anteriores não foram capazes de resolver.