Aplicações corporativas multicamadas - Partes 1 e 2

Sem dúvida, desenvolver software para atender necessidades empresariais é uma tarefa árdua. Envolve escolhas e decisões de projeto que podem tornar fácil ou difícil a evolução da solução construída. Quando se fala de software empresarial (aplicação corporativa), é um consenso que o melhor padrão arquitetural para diminuir a complexidade é dividir a aplicação em “camadas”, o que chamamos de uma arquitetura multicamadas.

A consolidação da arquitetura multicamadas para o desenvolvimento de aplicações corporativas é fruto de anos de evolução das tecnologias de rede e sistemas distribuídos. Porém, o amadurecimento ocorreu de fato com o emprego da web e da Internet como base de utilização e integração de sistemas empresariais, fazendo com que as empresas incorporem e tornem-se dependentes dessas tecnologias em seus modelos de negócios.

Entretanto, na arquitetura multicamadas, empregar a web na construção de uma aplicação corporativa é somente um dos elementos presentes na solução. Aplicações corporativas dizem respeito ao intenso uso de interfaces visuais com o usuário, possível integração com outros aplicativos, manipulação e armazenamento de grandes quantidades de dados, normalmente complexos, bem como o suporte e automação dos processos de negócio que fazem uso desses dados.

Esse tema será tratado em uma série de três artigos. Neste primeiro artigo, faremos uma breve introdução de conceitos; definição do que é um sistema multicamadas, distribuído e aplicação corporativa; aspectos de uma aplicação em camadas; quando desenvolver um sistema multicamadas; e, as tecnologias envolvidas (baseadas na plataforma Java EE).

Contexto histórico

Com a consolidação da Internet e da Web a partir dos anos 2000, surgiu a crescente demanda por sistemas corporativos que utilizam a Web como plataforma de desenvolvimento. Porém, para chegar até esse ponto, é necessário conhecer a evolução histórica desse tipo de software.

Podemos encontrar na literatura algumas formas de organizar, na linha do tempo, os principais eventos históricos da computação e das tecnologias da informação e comunicação. Faremos um breve destaque à evolução tecnológica das aplicações corporativas, considerando três grandes momentos ou “ondas”, isto é, marcos que estabelecem a ruptura com o modelo vigente e o surgimento de um novo modelo.

Momento 1: aplicações monolíticas ou centralizadas

Surge nos primórdios do uso de banco de dados na computação (anos 1960) até meados dos anos 80. Era baseada nos chamados computadores mainframe e em instalações denominadas CPD (Centro de Processamento de Dados), onde todo o processamento ocorria em uma máquina central, comunicando-se por meio de leitoras de cartões perfurados, substituídos em seguida por simples terminais de vídeo e teclado.

As aplicações eram escritas em um único módulo ou camada monolítica, com programas e dados firmemente entrelaçados. Tal integração estreita entre programa e dados dificultava a evolução e reuso de componentes.

Cada desenvolvedor de aplicação escolhia como estruturar e armazenar os dados e usava-se frequentemente técnicas para minimizar o caro armazenamento e manipulação em memória principal. Um dos problemas que surgiu com esse esforço por economia de hardware foi o chamado “bug do milênio”, ocorrido na virada para o ano 2000.

Momento 2: aplicações cliente-servidor

O modelo cliente-servidor predomina entre os anos 1980 e 1990. Uma série de mudanças e inovações surgem nessa época, como a adoção de tecnologias de armazenamento e de softwares para gerenciamento de banco de dados relacionais (SGBD), a utilização de rede locais interligando microcomputadores departamentais, o início do paradigma da programação orientada a objetos, e a redução dos custos do hardware, tornando possível a massificação da computação pessoal.

A característica principal do modelo cliente-servidor é a separação em duas camadas distintas: a cliente, representando as aplicações instaladas nas estações clientes, e o servidor, o componente central que fornece serviços às aplicações clientes. No contexto de aplicações corporativas, é no servidor que fica localizado o SGBD.

Tal modelo consolida-se com o surgimento das interfaces gráficas com o usuário (GUI, ou as populares “janelas”) nos computadores pessoais (desktops), e a viabilidade das redes locais para acesso às informações corporativas, centradas em um servidor de banco de dados relacional, como pode ser visto na Figura 1.

Figura 1. Modelo em duas camadas.

Apesar do modelo em duas camadas permitir concentrar o processamento das aplicações no servidor, o que ocorreu foi a escolha do processamento da lógica de negócio no lado cliente, aumentando o tamanho e a complexidade das aplicações clientes, solução conhecida por fat-client (“cliente gordo”). Entre os problemas que decorrem dessa decisão, podemos apontar a dificuldade em atualizar as versões dos aplicativos nas estações clientes, uma vez que qualquer mudança no código da aplicação implica em replicar para todas as máquinas clientes esse código, sobrecarregando o tráfego de rede.

Outra decisão adotada na arquitetura em duas camadas defendia a utilização de procedimentos armazenados em bancos de dados relacionais como forma de reuso, solução que obrigava os programadores a conhecerem detalhes das tecnologias do banco de dados, concentrando e escondendo a lógica de negócio em componentes vinculados aos dados.

Momento 3: aplicações distribuídas

Esse modelo arquitetônico se consolida a partir da metade dos anos 1990, como evolução do modelo cliente-servidor e da popularização da Internet e do amadurecimento das tecnologias para redes de computadores. A ideia básica é distribuir o processamento da aplicação em várias máquinas, evitando a sobrecarga sobre uma única camada, como ocorria no modelo cliente-servidor. Com a distribuição da carga de processamento em diversas máquinas é possível melhorar o desempenho e compartilhar recursos, utilizando-os como se fossem recursos locais, característica de transparência de uso que se chama independência de localização. Além dessas vantagens, há uma compensação no custo em relação ao desempenho, a possibilidade de aumento de escala e expansão da rede sem perda de qualidade, melhora na robustez em função da distribuição dos serviços em mais de uma máquina, e muitos outros benefícios.

Há diversas formas de estruturar um sistema distribuído. Na Figura 2 são vistos dois exemplos: um sistema “ponto-a-ponto” (peer-to-peer ou P2P), e um sistema web usando banco de dados. No modelo P2P, cada ponto (nó) da rede pode realizar tanto funções de servidor quanto de cliente, evitando o uso de um nó administrador da rede. No segundo exemplo, temos um sistema distribuído usando um servidor web que acessa um servidor de banco de dados, permitindo que diversos tipos de clientes acessem os serviços disponíveis no servidor web. Entre os serviços, poderíamos ter um servidor de mapas semelhante ao Google Maps, bem como provedores de informações sobre publicações, de cotação de moedas, condições climáticas de uma cidade, de identificação do CEP, e muito mais.

Figura 2. Dois exemplos de modelos para estruturar um sistema distribuído: peer-to-peer e web.

Para que os sistemas distribuídos troquem mensagens, é necessário o emprego de tecnologias básicas para comunicação em redes, como as chamadas de procedimentos remotos com RPC (Remote Procedure Call) e o uso de canais com sockets. Além disso, baseado em tecnologias orientadas a objetos é possível utilizar protocolos de padrões abertos para comunicação com objetos, como CORBA (Common Object Request Broker Architecture) e Web Service, ou proprietários, como DCOM (Distributed Component Object Model) e .NET Remoting, ambos da Microsoft. Protocolos específicos para a plataforma Java utilizam o RMI (Remote Method Invocation) e RMI-IIOP (Internet Inter-Orb Protocol), a serem apresentados a seguir.

Atualmente, com a evolução da infraestrutura de hardware e software que viabiliza o emprego de sistemas distribuídos, é possível combinar recursos computacionais com total transparência de uso, determinados apenas pelas restrições e necessidades de custo, processamento e escalabilidade, que são:

• Cluster (agregado): processadores estão interligados por barramento ou rede de alta velocidade;

• Grid (grade): reúnem recursos heterogêneos distribuídos geograficamente, interligados por uma rede de longa distância;

• Cloud (nuvem): conjunto compartilhado de recursos (servidores, armazenamento, rede, aplicações, etc.), distribuídos ou não, que são alocados temporariamente para os usuários.

Sistemas distribuídos em Java

Sistemas distribuídos em Java podem ser implementados com as tecnologias básicas para comunicação entre processos, como sockets e RMI, e adotando-se protocolos de comunicação para interoperabilidade entre sistemas heterogêneos.