Middleware: Evolução da Arquitetura Cliente/Servidor

Prévia do material em texto

41
CAPÍTULO 3
”MIDDLEWARE”
Para entender-se o aparecimento da tecnologia “middleware” é descrita a
seguir, e, brevemente, a sua evolução.
3.1 ARQUITETURA CLIENTE/SERVIDOR
Primeiramente, surgiu a arquitetura centralizada (“mainframe”). Esta arquitetura
consiste em centralizar toda a inteligência num computador central que recebe
a informação gerada pela captura da teclagem de um usuário através de um
terminal. Esta arquitetura é limitada por não suportar facilmente interfaces
gráficas com o usuário (“Graphic User Interface” - GUI) e o acesso a múltiplos
bancos de dados geograficamente dispersos (Sadoski, 1998).
Com o aparecimento de redes conectando vários PCs, surgiu a arquitetura de
arquivo compartilhado (“file sharing”). Nesta arquitetura, o servidor de arquivos
envia arquivos da localização compartilhada para o ambiente da estação de
trabalho. Neste local, o trabalho requisitado pelo usuário é então executado
(incluindo a lógica e os dados). Esta arquitetura apresenta limitações, pois só
se tem um bom desempenho se o número de compartilhamentos de um
arquivo e o volume de dados transferido forem pequenos (Sadoski, 1998). Para
solucionar estas limitações surgiu a arquitetura cliente/servidor.
A arquitetura de software cliente/servidor é uma infra-estrutura modular onde o
processamento é dividido, cabendo uma parte ao servidor e uma parte ao
cliente. A comunicação cliente/servidor é baseada em troca de mensagens.
Quando comparada à arquitetura de software centralizada e à arquitetura de
compartilhamento de arquivo, apresenta uma melhor “usabilidade”,
flexibilidade, “interoperabilidade” e “escalabilidade” (Sadoski, 1998). Nesta
42
arquitetura, o cliente é definido como requisitor de serviço; o servidor é definido
como provedor de serviços e dependendo da configuração de software uma
única máquina pode ser ambos: cliente e servidor. A arquitetura cliente/servidor
substituiu o servidor de arquivos por um servidor de banco de dados. Esta
substituição permite que as consultas do usuário sejam respondidas
diretamente através da utilização de um sistema de gerenciamento de banco
de dados relacional (“Data Base Management System” - DBMS). O servidor de
bancos de dados reduz o tráfego da rede pois provê a resposta a uma consulta
ao invés de transferir todo o arquivo.
A seguir, são descritos alguns tipos comuns de arquitetura cliente/servidor.
3.1.1 ARQUITETURA CLIENTE/SERVIDOR DE DUAS CAMADAS
Arquitetura cliente/servidor de duas camadas (“Two Tier”) consiste em três
componentes distribuídos em duas camadas. Uma das camadas é o cliente
que requisita os serviços e a outra é o servidor que provê os serviços. Os três
componentes desta arquitetura são descritos a seguir (Sadoski, 1999c):
• Interface do usuário com o sistema: normalmente localizada no ambiente da
estação de trabalho do usuário, constituindo-se de sessões, entrada de
texto, diálogo, “display” dos serviços de gerenciamento, etc.
• Gerenciamento dos processamentos: está localizado usualmente no
servidor e constitui-se dos processos desenvolvidos pelo usuário, da
monitoração dos mesmos, etc.
• Gerenciamento de banco de dados: está localizado usualmente no servidor
e constitui-se de serviços de manipulação de dados, arquivos, etc.
Nesta arquitetura, o servidor, que é a máquina mais potente, serve a vários
clientes. O gerenciamento do processo é dividido entre o ambiente da interface
43
do usuário com o sistema e o ambiente servidor de gerenciamento de banco de
dados, como mostrado na Figura 3.1.
Fig. 3.1 - Arquitetura cliente/servidor de duas camadas
 FONTE: Sadoski (1999c, p.1)
A arquitetura de duas camadas é uma boa solução para computação
distribuída quando o grupo de trabalho é definido entre 12 e 100 usuários
interagindo numa “Local Area Network” (LAN) simultaneamente. Um número
maior que 100 usuários implica uma deterioração do desempenho. Esta
limitação é resultado da necessidade do servidor manter a conecção via
mensagens de “estou vivo” (“keep-alive”) com cada cliente, mesmo quando
nenhum trabalho está sendo executado. Uma outra limitação é a pouca
flexibilidade que existe quando se deseja mover funcionalidades de um
programa de um servidor a outro sem efetuar alterações no código.
3.1.2 ARQUITETURA CLIENTE/SERVIDOR DE TRÊS CAMADAS
A arquitetura cliente/servidor de três camadas (“Three Tier”) surgiu para suprir
as limitações da arquitetura cliente/servidor de duas camadas. Nesta
arquitetura, uma camada média foi introduzida entre a interface do usuário
Interface do usuário
com o sistema +
algum gerenciamento
de processamento
Gerenciamento de
banco de dados +
algum gerenciamento
de processamento
44
com o sistema (ambiente cliente) e o gerenciador de banco de dados (ambiente
servidor), como mostrado na Figura 3.2. Esta camada média provê serviços de
gerenciamento de processos compartilhados por múltiplas aplicações (Sadoski,
1999a).
Fig. 3.2 - Arquitetura cliente/servidor de três camadas
 FONTE: Sadoski (1999a, p.1)
A seguir, são descritos alguns tipos de arquitetura cliente/servidor de três
camadas.
3.1.2.1 MONITORES DE PROCESSAMENTO DE TRANSAÇÃO
Arquitetura de três camadas com tecnologia de monitores de processamento
de transações (“TP Monitor”) é considerada uma arquitetura básica. A
tecnologia de monitores de processamento de transação está centrada no
servidor e consiste em filas de mensagens, seqüenciamento (“scheduling”) de
Interface do usuário
com o sistema
Gerenciamento de
processos
Gerenciamento de
banco de dados
45
transações e priorização de serviços. O cliente conecta esta camada média,
isto é, o monitor de transação, ao invés do banco de dados diretamente. A
transação é aceita pelo monitor, que a enfileira e toma a responsabilidade por
manejá-la e completá-la liberando o cliente. A Figura 3.3 mostra esse tipo de
arquitetura.
Fig. 3.3 - Monitores de processamento de transações
 FONTE: Sadoski (1999b, p.2)
A tecnologia de monitor de transação provê a habilidade de atualizar múltiplos
sistemas de gerenciamento de banco de dados (“Data Base Management
System” – DBMS) diferentes numa única transação, conectar-se a várias fontes
de dados, fixar prioridades às transações e promover robustez à segurança.
3.1.2.2 SERVIDOR DE MENSAGENS
Na arquitetura de três camadas com servidor de mensagens, o software
servidor de mensagens reside uma parte no cliente e outra no servidor, sendo
que as mensagens são priorizadas e processadas “assincronamente” entre
eles (Vondrak, 1999)
Monitor de
Processamento
de Transação
Cliente
Cliente
Cliente
Cliente
Cliente
Rotinas de
Processamento
Servidor
46
Mensagens consistem de informações, do endereço e do número de
identificação. A diferença entre esta tecnologia e a do monitor de transação é
que a arquitetura do servidor de mensagens foca a inteligência nas próprias
mensagens, isto é, a mensagem em si carrega toda a informação necessária
para o cliente processar a mensagem recebida do servidor e o servidor a
recebida do cliente, enquanto o monitor de transação tem a inteligência no
monitor, pois, a mensagem enviada pelo cliente é processada pelo monitor
antes de ser enviada ao servidor e vice-versa.
3.1.2.3 “OBJECT REQUEST BROKER”
Nessa arquitetura de três camadas adiciona-se um software distinto, conhecido
como ORB, que não faz parte do cliente e nem do servidor no qual as
mensagens recebidas e enviadas entre eles são tratadas. Nessa arquitetura
tem-se três elementos distintos cliente, servidor e ORB, como mostrado na
Figura 3.4. O ORB provê várias funcionalidades como: troca de mensagens
(comunicação) entre cliente e servidor, localização e ativaçãode um servidor
que atenderá a um pedido de um cliente que não precisa conhecer a sua
localização nem precisará ativá-lo.
Fig. 3.4 – Funções do ORB
 FONTE: Wallnau e Foreman (1999, p.1)
ORB
Serviço
Remoto
(objeto)
Aplicação
Cliente
Localização
do serviço
Ativação do
serviço
Comunicação
Estabelecimento
da conecção
47
3.2 “MIDDLEWARE”
A camada média da arquitetura cliente/servidor de três camadas pode ser
implementada de várias maneiras tais como, já descrito, monitores de
processamento de transações, servidores de mensagens, etc. onde cada uma
apresenta vantagens e limitações. A esta tecnologia que implementa os vários
tipos de camadas médias, juntamente com suas funcionalidades, dá-se o nome
de “middleware”.
“Middleware” é um software de “conectividade” que consiste em um conjunto
de serviços que permite a interação, através da rede, de múltiplos processos
executando em uma ou mais máquinas. “Middleware” é essencial para migrar
aplicações de “mainframe” para aplicações cliente/servidor provendo
comunicação através de plataformas heterogêneas (Bray, 1998).
Esse software de “conectividade” se localiza entre a aplicação e o sistema
operacional (Bernstein, 1996), com mostrado na Figura 3.5.
48
Fig. 3.5 - “Middleware”
 FONTE: Bernstein (1996, p.89)
O “middleware” oferece serviços de propósito geral que se situam entre a
aplicação e a plataforma utilizada (sistema operacional mais hardware). Os
serviços oferecidos pelo “middleware” devem (Bernstein, 1996):
• Ir ao encontro de uma grande variedade de aplicações, por exemplo:
ser capaz de traduzir ou facilitar a adição de mensagens de vários
formatos para serem utilizados em diversas aplicações.
• Ser implementados de forma a possibilitar a execução em plataformas
distintas. Por exemplo, em sistemas distribuídos as aplicações
localizadas em diferentes plataformas podem usar o serviço
“middleware” para se comunicar e/ou trocar dados, aumentando assim
a “interoperabilidade”.
• Possibilitar serem acessados remotamente por outros serviços ou
aplicações.
Aplicação ......... Aplicação
APIs
Middleware
(serviços de sistema distribuído)
Interface da Plataforma
Plataforma:
 - SO
 - Hardware
.........
Interface da Plataforma
Plataforma:
 - SO
 - Hardware
49
• Suportar, idealmente, um protocolo padrão, por exemplo, “Transmission
Control Protocol/Internet Protocol” (TCP/IP) ou “International Standards
Organization” (ISO) “Open System Interconnect” (OSI).
• Suportar uma “Application Programming Interface” (API) padrão. Os
serviços devem ser transparentes com respeito a API, isto é, eles
devem ser acessados via APIs sem necessidade de modificá-las.
Uma API (interface de programação de uma aplicação) é um conjunto de
regras para escrever funções ou chamadas de subrotinas que acessam uma
biblioteca. Por exemplo, para enviar dados uma aplicação pode invocar uma
API que apresenta uma função do tipo “SEND” especificando como parâmetros
o nome destino e os ponteiros para os dados, assim, esta API, que é uma
interface escrita utilizando regras específicas, acessa uma biblioteca que
contém a respectiva função. A biblioteca pode ser atualizada mas mantidas as
API as aplicações não precisam ser alteradas. APIs combinam recuperação de
erro, tradução de dados, segurança, filas e nomeação com interfaces de fácil
utilização que compreendem ações/comandos simples, mas poderosos (Bray,
1999).
Existem quatro tipos de APIs que possibilitam o compartilhamento de dados
entre aplicações diferentes de software em plataforma única ou distribuída, que
serão listadas a seguir (Bray, 1999):
• Chamada de Procedimento Remoto (“Remote Procedure Call” – RPC): os
programas usando RPCs comunicam-se via procedimentos ou tarefas
(“tasks”) que agem em “buffers” de dados compartilhados (Vondrak, 1998).
• Linguagem Padrão de Consulta (“Standard Query Language” – SQL): é uma
linguagem não procedural de acesso a dados que permite
compartilhamento de dados entre aplicações através do acesso a um banco
de dados comum.
50
• Transferência de Arquivo (“File Transfer”): permite compartilhamento de
dados através do envio de arquivos fomatados entre as aplicações.
• Entrega de Mensagens: provê compartilhamento de dados pela
comunicação via pequenas mensagens formatadas entre as aplicações.
O principal propósito do “middleware” é ajudar na resolução de muitos
problemas de “conectividade” e “interoperabilidade” de aplicações, mas é o
“desenvolvedor” que tem a difícil tarefa de decidir quais funcionalidades serão
colocadas no lado cliente e quais estarão no lado servidor da aplicação
distribuída. Desta forma, é importante entender o problema que será resolvido
pela aplicação e o valor dos serviços “middleware” que permitirão a distribuição
desta aplicação. Para determinar os tipos de serviços “middleware”
necessários, o “desenvolvedor” deve identificar as funções requeridas pela
aplicação, que podem recair em uma de três classes (Bray, 1998) (Bernstein,
1996):
• Se a aplicação é um serviço de sistema distribuído que inclue a
comunicação programa a programa como ponto crítico, os serviços
“middleware” que a auxiliam são os serviços de comunicação, tais
como, mensagem “peer-to-peer”, chamada de procedimento remoto
(RPC), fila de mensagens, correio eletrônico, troca de dados por meio
eletrônico, etc.
• Se a aplicação é um serviço que permite o acesso de aplicaçôes aos
serviços de rede e de banco de dados, os serviços “middleware” que a
auxiliam são os serviços de gerenciamento, tais como, balanceamento
de carga na rede, servidor de diretório, gerenciador de históricos (“log”),
gerenciador de arquivos, gerenciador de gravação, sistemas de banco
de dados relacionais e orientados a objeto, gerenciador de repositório,
etc.
• Se a aplicação é um serviço de gerenciamento que permite que as
aplicações e funções do sistema sejam continuamente monitoradas de
51
forma a assegurar uma performance ótima do ambiente distribuído, os
serviços “middleware” que a auxiliam são os serviços de gerenciamento
de sistema e controle, tais como, serviços de notificação de eventos,
gerenciamento de configuração, gerenciamento de instalação de
software, detetor de falhas, coordenador de recuperação, serviço de
autenticação, serviços de auditoria, serviços de criptografia, serviços de
controle de acesso, gerenciamento de “threads”, gerenciamento de
transação, recursos de “broker”, seqüenciador de requisições,
seqüenciador de tarefas, etc.
3.2.1 SERVIÇOS “MIDDLEWARE”
Devido à importância da “portabilidade” de aplicações e protocolos
padronizados para possibilitar a “interoperabilidade”, os serviços “middleware”
têm sido alvo de esforços de padronização. Algumas tentativas têm sido feitas
por entidades públicas, tais como, ISO e “American National Standards
Institute” (ANSI) e outras por consórcios industriais como X/Open, “Open
Software Fundation” (OSF), “Object Management Group” (OMG) e ActiveX
(Microsoft). O esforço de padronização demonstra a importância desses
serviços. O propósito principal dos serviços “middleware” é permitir que uma
plataforma não dependa de APIs específicas, permitindo que aplicações
executem em diferentes plataformas e incluam serviços de alto nível que
escondam a complexidade de redes e sistemas distribuídos.
3.2.2 TIPOS DE “MIDDLEWARE”
Uma organização com a necessidade de distribuir uma aplicação pode
escolher entre construir um ambiente de trabalho (“framework”) para integração
e desenvolvimento próprio (“customized”) ou utilizar produtos existentes no
mercado que ofereçam ferramentas de integração e desenvolvimento. Os
produtos existentes nomercado são desenvolvidos baseados nas
52
especificações CORBA da OMG, no “Distributed Computing Environment”
(DCE) da OSF, no DCOM da Microsoft, assim como, no “Remote Method
Invocation” (RMI) da linguagem Java.
Atualmente, as necessidades do mercado exigem um curto tempo para tornar
um novo produto disponível, antes que um concorrente o faça, e o sucesso de
uma organização depende de uma solução importante: a escolha da
ferramenta adequada ao desenvolvimento deste novo produto.
Estas ferramentas baseiam-se em diversas tecnologias, apresentam diferentes
características, mas em alguns pontos elas são similares ou mesmo
complementares. Desta forma, a escolha requer um estudo muito criterioso.
Deve-se considerar as características da organização (tipo de aplicação a ser
desenvolvida, grau de conhecimento da equipe, etc.) assim como, a plataforma
de hardware e software que ela possui e que deseja integrar e utilizar para a
aplicação a ser desenvolvida.
3.2.2.1 COM/DCOM
COM é um padrão da Microsoft que define como os objetos podem interagir e o
DCOM é o COM distribuído através da rede. Para o COM/DCOM tornar-se um
padrão foi necessário torná-lo público e seu controle feito por um consórcio.
Assim, o “ActiveX Core Technologies”, do qual o COM/DCOM faz parte, está
sendo controlado pelo “The Open Group”. Foi criado também um consórcio
chamado “The Active Group” com cerca de dezessete membros, no qual a
Microsoft é o principal deles (Microsoft, 1998a).
53
3.2.2.2 CORBA
O CORBA é uma especificação de um padrão de arquitetura para aplicações
orientadas a objeto. Esta especificação foi definida inicialmente pelo OMG no
documento “Object Management Architecture Guide”, publicado em novembro
de 1990 (OMG, 1998). O OMG é uma organização sem fins lucrativos, fundada
em 1989, que conta com mais de 600 membros. CORBA diz respeito a
interfaces e não a implementações específicas. Ela foi definida para prover
uma solução de “middleware”. É uma especificação de um padrão que vem
sendo usado em muitos produtos.
3.2.2.3 JAVA
O código Java é escrito de tal forma que possibilita a sua distribuição através
de uma rede, sendo a independência de plataforma uma das suas principais
características. O Java é independente da plataforma tanto a nível executável
quanto de fonte. O Java quando compilado produz um “bytecode”. “Bytecode” é
um conjunto de instruções bastante parecida com alguns códigos de máquina,
mas não é específica a nenhum processador. Este “bytecode” pode ser
interpretado por qualquer compilador que possua uma “virtual machine” (VM).
Java apresenta um grande suporte das empresas de software e está
implementada na maioria das plataformas (Lemay e Perkins, 1997). A
linguagem Java inicialmente foi utilizada como uma ferramenta para
desenvolver páginas Web, mas agora a linguagem e seu ambiente de
desenvolvimento estão sendo cada vez mais utilizados para desenvolver
software em ambiente de rede (Wallnau et al, 1997).
3.2.2.4 DCE
O OSF iniciou, no final dos anos 80, a elaboração de um ambiente que
permitisse criar aplicações cliente/servidor heterogêneas. A versão 1.0 foi
54
apresentada em 1992 e os primeiros produtos em 1993, na qual organizações
como IBM, DEC, AT&T, Hewlett-Packard, Hitachi, Bull, Siemens, Nixdorf e
muitas outras desempenharam um papel importante na elaboração das
especificações e referências de implementações (Rosenberry et al, 1992). DCE
é um “middleware”, isto é, uma camada entre o sistema operacional/protocolo
de rede e a aplicação distribuída. DCE é um conjunto de ferramentas e
serviços que auxiliam a criação e a execução de aplicações distribuídas. A
Figura 3.6 mostra a arquitetura DCE.
Fig. 3.6 - Arquitetura DCE
 FONTE: Mowbray e Ruh (1997, p.185)
Seus componentes chaves são descritos a seguir (Rosenberry et al, 1992):
• “Remote Procedure Call”: é o software que torna possível a operação
de distribuição. Ele gerencia a comunicação entre a aplicação do cliente
e do servidor, isto é, gera automaticamente os códigos, no lado cliente e
Aplicação Distribuída
Opções de gerenciamento
de rede
Serviços de Eventos Serviço de distribuição
de arquivos
Serviços de diretórios Serviços de temporização
distribuída
Serviços de segurança
Chamada de Procedimento Remoto (RPC)
Serviços de “thread”
Sistema Operacional e Serviços de rede
55
no lado servidor, que permitem abrir uma conecção e transmitir os dados
de forma organizada.
• “Cell” (célula): Uma célula é a unidade básica de operação e
administração no DCE. Uma célula é um grupo de usuários, sistemas e
recursos que tipicamente possuem propósitos comuns e compartilham
serviços DCE. Minimamente, uma configuração de célula inclui serviços
de diretórios (“Cell Directory Service” – CDS), serviços de temporização
(“Distributed Time Service” – DTS) e serviços de segurança (“DCE
Security”).
• Serviços de diretórios (CDS): permitem o gerenciamento e controle dos
domínios administrativos (ou células), serviços globais de diretórios e
nomeação de domínios.
• Serviços de temporização distribuída (DTS): assegura a sincronização
de tempo entre os recursos computacionais.
• Serviços de segurança (“DCE Security”): mantêm para todas as
aplicações a autenticidade, autorização, integridade e privacidade.
• Serviços de distribuição de arquivos (“Distributed File Service” – DFS):
provê o acesso e compartilhamento de arquivos sem o conhecimento da
sua localização ou de procedimentos locais de acesso.
Não será escopo desta dissertação uma apresentação mais detalhada do
modelo de distribuição e respectivo estilo de comunicação (RPC) adotado pelo
DCE. Esta dissertação aborda as possibilidades de distribuição usando
conceitos de orientação a objetos e o RPC não se adapta ao modelo de objeto
(Otte et al, 1996), pois precisamos adicionar construções e mecanismos à base
da tecnologia RPC para adaptá-la à tecnologia de orientação a objetos.
56