Risiko ved byggekostnader

O termo middleware apareceu pela primeira vez no final de 1980 para descrever gerenciamento de conexões em software, mas passou a receber mais destaque a partir da metade da década de 1990, quando a tecnologia de rede começou a ser mais intensamente utilizada (BAKKEN, 2003).

O RM-ODP foi estabelecido entre 1995 e 1996, mesma época na qual o

middleware começou a ganhar destaque no mercado, pois ambos, cada um ao seu nível,

tratam de aplicação distribuída em plataformas computacionais heterogêneas. O

middleware é mais antigo e nasceu da necessidade do mercado em resolver e adaptar

sistemas com aplicação distribuídas.

Cronus foi o primeiro sistema middleware de objetos distribuídos, sendo Clouds e Eden como seus contemporâneos. O RPC foi desenvolvido no início da década de 1980 por Birrell e Nelson. Rapidamente o sistema RPC foi utilizado pela Sun em seu

Open Network Computing (ONC), e no Apollo's Network Computing System (NCS). A Open Software Foundation's Distributed Computing Environment (DCE), incluiu também

sistema RPC, que foi uma adaptação do Apollo fornecido pela Hewlett Packard (que adquiriu Apolo). Qualidade Objetos (QuO) foi o primeiro framework de middleware criado para uso geral e extensível com qualidade do serviço de objetos distribuídos (ZINKY; BAKKEN; SCHANTZ, 1997). TAO foi o primeiro grande sistema CORBA a proporcionar qualidade de serviço, ou seja, com desempenho em tempo real, diretamente no ORB (BAKKEN, 2003).

O Message Oriented Middleware (MOM) é um método de comunicação entre componentes de software utilizado em sistemas distribuídos, sendo considerado como um tipo de middleware orientado a mensagens. Devido ao seu grande uso na década de 1990, a Message Oriented Middleware Association (MOMA) foi formada em 1993. No final dos anos 1990, o protocolo Hypertext Transfer Protocol (HTTP) se tornou freqüente em vários tipos de middleware, devido à sua transversalidade de implantação e sua capacidade de transpor a maioria dos firewalls conforme BAKKEN (2003).

O middleware trouxe novos paradigmas e serviços para ajudar a tornar mais fácil e controlável a construção e desenvolvimento de aplicações distribuídas. O termo foi associado principalmente com bases de dados no início da década de 1990, mas já na metade dessa década passou a ser utilizado em outras aplicações (BERNSTEIN, 1996) (CAMPBELL, GOULSON, KOUNAVIS, 1999). Os conceitos de

middleware de hoje anteriormente foram associados aos atributos dos sistemas

operacionais de rede, sistemas operacionais distribuídos, e ambientes de computação distribuída.

Uma plataforma middleware fornece o ambiente para aplicações orientadas a objetos distribuídos serem executados em tempo de execução (runtime). Ela prove os mecanismos de tratamento das conexões entre objetos, em um programa local ou entre objetos de uma aplicação que estejam distribuído em rede. Ela também fornece serviços de gestão de recursos para hospedagem lógica do programa aplicativo em tempo de execução (por exemplo: gestão de memória, sistema operacional de processos

e threads, carregando programas a partir do disco, conforme necessário, iniciando, parando e multiplexando programas, balanceando a carga, etc). Plataforma middleware também fornece interfaces para uma ou várias formas de comunicação middleware (one-

way messaging e request/respond) (LHEUREUX et al., 2004).

Uma definição de middleware é um sistema de software que executa em tempo real e que permitem um nível de interação direta entre os programas da aplicação em um ambiente distribuído de computação (LHEUREUX et al., 2004). Ele é uma camada de Software que tem a função de auxiliar no gerenciamento da complexidade e heterogeneidade típicos de sistemas distribuídos, localizando-se entre a camada do sistema operacional e a da aplicação, como mostra a Figura 20 (LHEUREUX et al., 2004).

O middleware é dividido em quatro categorias, em função da abrangência das atividades que executa (BAKKEN, 2003):

• Distributed Tuples: Permite a distribuição de bancos de dados em

um ambiente de rede. Uma base de dados relacionais distribuída oferece a abstração de enuplas distribuídas e é uma das formas mais utilizadas de middleware atualmente. A sua linguagem SQL (Structured Query Language) permite aos programadores manipularem conjuntos de enuplas (uma base de dados) em uma linguagem parecida com o Inglês porém com semânticas intuitivas e funções matemáticas rigorosas baseadas na teoria de conjuntos e cálculo de predicado. Bases de dados relacionais distribuídas também oferecem a abstração de uma transação. Produtos de bases

Figura 20: Representação da posição relativa de um middleware extraída de Gartner Research LHEUREUX et al (2004).

de dados distribuídas tipicamente oferecem heterogeneidade entre linguagens de programação, porém muitos não oferecem a heterogeneidade entre as implementações de fabricantes. Monitores de Processamento de Transação (em inglês, TPMs) são comumente usados para gerenciamento ponto-a-ponto de recursos de consultas de clientes, especialmente gerenciamento de processos do servidor e gerenciamento de transações entre múltiplas bases de dados (BAKKEN, 2003). Exemplos deste tipo de middleware incluem sistemas de arquivos remotos, como os embutidos em NetWare, o

Network File System (NFS) e Windows, e também incluem o acesso

remoto de dados, por exemplo, Open Database Connectivity (ODBC) ou o Java Database Connectivity (JDBC), que são bibliotecas agrupadas em SGBDs como o DB2, Oracle e SQL Server;

• Remote Procedure Call (RPC): Permite que a lógica de uma

aplicação seja distribuída ao longo de uma rede, permitindo que programas em sistemas remotos sejam chamados como se fossem sistemas locais. Assim tem-se: Java Message Service (JMS), ou serviços da Web (com base em Simple Object Access Protocol (SOAP);

• Message-Oriented Middleware (MOM): Permite troca de

informações entre programas através de mensagens, prevê a transparência de filas de mensagens que podem ser acessadas através de uma rede. É um software que suporta um protocolo de transmissão de mensagens ou dados entre dois pontos, assim como um sistema de programação interface (SPI) para invocar o serviço de comunicação. É uma generalização do conhecido sistema de caixa de correio. É muito flexível na forma como ele pode ser configurado com a topologia de programas que deposita e retira as mensagens a partir de uma dada fila. Muitos produtos oferecem MOM filas com persistência, replicação, ou em tempo real. Comunicação mais avançada, prevê também, a segurança e garante somente uma mensagem entregue no destino. Protocolos e APIs podem ser proprietárias (como por exemplo, IBM WebSphere MQ ou Microsoft MSMQ). Hoje, a comunicação geralmente é executada nos

middlewares baseados na Internet, como os protocolos FTP, HTTP e-

Secure HTTP (S-HTTP), IP, SMTP ou TCP;

• Object Request Brokers (ORB): Permite que objetos que compõem

uma aplicação sejam distribuídos ao longo de uma rede. Um exemplo é CORBA (Commom Object Request Broker) é uma plataforma de distribuição resultante da arquitetura OMA (Object Management

Architecture) do OMG (Object Management Group) , uma

organização internacional, fundada em maio de 1989 pelas empresas 3Com Corporation, American Airlines, Canon Inc, Data General, Hewlett-Packard, Phillips , Telecommunications N.V., Sun MicroSystems e Unisys Corporation. A plataforma CORBA fornece mecanismos pelos quais objetos fazem pedidos e recebem respostas em um ambiente distribuído de forma totalmente transparente (OH et al. 2003).

Na Figura 21 tem-se um diagrama mostrando a posição do middleware abaixo da aplicação e dentro da infra-estrutura. Observando-se apenas a camada

middleware e os serviços locais e na rede tem-se o modelo apresentado na Figura 20.

Uma ilustração completa e mais abstrata do contexto do middleware está representado na Figura 22 e Figura 23, nela tem-se a observação que o middleware é totalmente acessado por APIs. Tanto a aplicação quanto o sistema operacional é tratado por acesso de APIs.

A ilustração da Figura 22 apresenta uma comparação entre o modelo de referência OSI para protocolo de comunicação em relação às camadas de uma estrutura

middleware. Nesta Figura, o correspondente as APIs que tratam o middleware estão na

mesma posição da camada 7, ou seja, da aplicação do OSI. Esse fato está de acordo com a iniciativa de se desenvolver o RM-ODP, como foi visto, sendo o mais utilizado como possibilidades de soluções em sistema de aplicação distribuída, conforme apresentado nos parágrafos anteriores deste capítulo.

Figura 22: Arquitetura de middleware x OSI

Pode-se concluir que, o middleware é a condição necessária para que a programação distribuída seja realizada. Neste ponto da pesquisa, observa-se que as estruturas são complexas e o fato de o acesso se processar por meio de APIs poderá dificultar a sua implementação em sistemas baseados em microcontroladores, utilizando esta modelagem.

Uma definição típica de sistemas operacionais embute o conceito de que ele é “o software que torna o hardware utilizável”; de modo similar, o middleware pode ser considerado como: “o software que torna programável os sistemas orientados a objeto ou aplicação distribuída” (BAKKEN, 2003).