Autor: Ricardo Shoiti Ikematu

MIDDLEWARE: A Market Overview

Rick van der Lans

Consultor independente, especialista em tecnologia de banco de dados, ferramentas de desenvolvimento em arquitetura cliente/servidor e modelagem de dados e membro do comitê holandês da ISO para SQL.

Nas aplicações centralizadas, a lógica de apresentação, a lógica da aplicação e os bancos de dados estavam na mesma plataforma e conversando com o mesmo protocolo de comunicação. Eram soluções proprietárias de um mesmo fabricante.

Com a popularização da arquitetura cliente/servidor esta situação mudou drasticamente. O cenário que se vê atualmente é várias ferramentas de front-end de várias gerações tendo de conversar com vários bancos de dados diferentes e sob protocolos de comunicação e plataformas heterogêneas.

Seria ótimo se tivéssemos o melhor da tecnologia cliente/servidor fornecida por um mesmo fabricante. Seria mais fácil de administrar este problema, pois facilitaria a integração dos vários componentes.

Porém, uma empresa não escolhe ter vários fornecedores de software ou várias plataformas de hardware. Determinadas tecnologias não estão disponíveis em determinada época, e um fornecedor de software não consegue dispor da melhor solução em todas as áreas que a empresa necessita em um determinado momento. Assim, as empresas vão construindo seus quebra-cabeças com peças de vários fabricantes. Em empresas maiores não se pode simplesmente jogar fora ou converter todo o seu aplicativo existente, comumente chamado de legado pela organização.

Esta situação decorre não pela falta de interesse, mas sim pela falta de recursos. Geralmente estas empresas estão com uma demanda reprimida, tendo na maioria das vezes que terceirizar estes serviços. Convivendo com esta pressão, as empresas não tem tempo, nem recursos técnicos, para cuidar do seu legado. Há ainda no Brasil a cultura de que em time que está ganhando e em sistema que está funcionando ...

Nas aplicações cliente/servidor corporativas, para ajudar a montar este difícil quebra-cabeças, um componente desta arquitetura vem ganhando destaque, e responde pelo nome de Middleware.

Segundo o palestrante, Middleware é uma categoria de produtos ou módulos de software que são utilizados por aplicações cliente, para acessar aplicações servidoras, e tentam esconder da aplicação a rede, a comunicação e plataformas específicas. O Middleware se posiciona entre a aplicação cliente e o protocolo de comunicação da rede, e entre o protocolo de comunicação e a aplicação no servidor.

O Middleware possibilitaria independência de tecnologia e de fornecedores no que se refere a sistemas operacionais, protocolos de comunicação, sistemas gerenciadores de banco de dados, hardware, etc. Possibilitaria, também, uma transparência de localização: a localização física dos processos no servidor estaria escondida e teríamos a habilidade de mover estes processos nos servidores. Vários módulos e plataformas poderiam ser misturados.

O palestrante divide o Middleware em 9 categorias:

- Middleware de transporte de SQL
DRDA, SQL*Net, SequeLink, EDA/SQL, Entire Access, SQLNetwork,...

- Middleware de adaptação,
ODBC, Q+E, Oracle Objects for OLE, DCL, ...

- Middleware de gateway para bases de dados
Oracle Transparent Gateway, OmniSQL Gateway, EDA/SQL, Infohub, ...

- Middleware para remote procedure call (RPC)
APPC, DCE, ...

- Middleware para gerenciamento de pedidos de objetos
CORBA, Microsoft COM, Sun DOE, IBM SOM, ...

- Middleware orientado para mensagem
MQSeries, Message Express, Pipes, ...

- Monitores de transação
Encina, Tuxedo, TopEnd, UTM, ACMS, CICS, ...

- Middleware para dar uma nova apresentação na tela
EHLLAPI, ...

- Middleware para apresentação remota
X Windows

A seguir temos as características dos principais produtos de Middleware do mercado.

 O palestrante ainda divide os Middlewares em dois grupos distintos: um grupo para interface com bancos de dados relacionais e outro grupo para interface com bancos de dados não relacionais.

Middleware e RDBMS

Middleware e SGBD não relacionais

O tipo de arquitetura cliente/servidor mais utilizado é o gerenciamento dos dados no servidor, e a lógica da aplicação e a apresentação ficarem no cliente, este tipo de arquitetura tende a parar de crescer. A arquitetura cliente/servidor que tem mais evoluído é o gerenciamento dos dados estar no servidor, a apresentação no cliente e a lógica da aplicação dividida entre o servidor e o cliente.

O palestrante alerta, que devemos escolher bem o que queremos antes de começarmos a construir o aplicativo, porque mudar as coisas no meio é bastante complicado. É mais fácil jogar tudo fora e construir um aplicativo novo. As diferentes opções de arquitetura necessitam de elementos diferentes para serem construídos. Se um software não estava previsto, a sua integração no aplicativo será bem mais difícil e não aproveitará toda a potencialidade do software.

Para implementar a distribuição de funções são necessários os seguintes requisitos:

• Ter uma clara separação entre a apresentação e a lógica da aplicação;
• Identificar facilmente as regras de negócio;
• Poder distribuir livremente as funções entre os clientes e os servidores;
• Poder mover as funções dinamicamente;
• Utilizar se possível uma única linguagem para todas as funções;
• A localização de funções deve ser transparente;
• As funções podem ser replicadas.

Um dos grandes problemas nesta arquitetura é ter uma única linguagem de desenvolvimento e não duas, geralmente uma implementação de SQL no servidor e uma linguagem de front-end no servidor. Existem duas exceções: Oracle que tem uma plataforma proprietária e Gupta, porém, com uma plataforma restrita ao SQLBase em que as stored-procedures são desenvolvidas em linguagem SQLWindows. O palestrante recomenda as linguagens UnifyVision, Dinasty, NatStar e Forté, dentre outras para resolver este problema.

Na parte de Middleware ele recomenda fortemente ODBC e os padrões DCE e CORBA. Quanto ao ODBC ele diz que as novas versões do padrão são muito boas, e o que realmente existe são implementações boas e ruins.

A arquitetura cliente/servidor é considerada uma solução aberta e dessa abertura decorrem problemas de segurança. Devido ao problema de segurança, o palestrante recomenda seguir os padrões DCE ou CORBA para a distribuição dos seus dados. Ele cita, também, a World Wide Web como uma alternativa de Middleware bastante popular, mas que está bastante imatura quanto à segurança.

O palestrante conclui que o pessoal de desenvolvimento deve fazer um bom planejamento antes de iniciar a construção do aplicativo. A equipe deve se preocupar com os seguintes itens:

• Determinar os objetivos, quão aberta será a solução;
• Verificar a situação atual, reutilizar os dados do legado;
• Considerar o conhecimento da força de trabalho;
• Determinar o volume de transações e dados;
• Determinar as características das aplicações: OLTP, OLAP, cálculos complexos, etc.;
• Determinar o tipo de arquitetura cliente/servidor.