| |
| Acadêmico(a): Abel Luiz Cechinel |
| Título: HMI: um Middleware para Objetos Ditribuídos sobre o Protocolo http |
| |
| Introdução: |
Desde o surgimento dos computadores, há demanda por compartilhamento de recursos. As primeiras necessidades surgiram em função do hardware caro. Vários terminais precisavam compartilhar a mesma unidade central de processamento, as mesmas impressoras e as mesmas unidades de gravação.
Até o início da década de 80, os computadores eram extremamente grandes e caros. Poucas organizações possuíam um computador. Muitas empresas, como as Têxteis de Blumenau, por exemplo, montavam empresas birôs de processamento de dados, onde um único computador realizava o processamento de várias empresas.
Esta realidade começou a mudar a partir da primeira metade dos anos 80. Primeiramente com o surgimento dos microcomputadores de grande capacidade. Inicialmente, surgiram os micros de 8 bits, extremamente rudimentares, com poucos kbytes de memória e de utilidade apenas para os aficionados. Mas logo apareceram as máquinas de 16, 32 e 64 bits e a memória passou a ser contada em megas e gigas. Segundo Tanenbaum e Steen (2008, p. 1), os atuais computadores de mil dólares apresentam uma capacidade de processamento 1013 vezes maior que os primeiros computadores, que custavam dez milhões de dólares.
Outro avanço significativo foi a disseminação das redes de computadores, ocorrida a partir da década de 90. Segundo Tanenbaum e Steen (2008, p. 1), uma Local Area Network (LAN), permite que centenas de máquinas localizadas dentro de um edifício sejam conectadas de modo tal que as informações possam ser movimentas entre máquinas a taxas de 100 milhões a 10 bilhões de bits/s. Uma Wide Area Network (WAN), permite que milhões de máquinas no mundo inteiro sejam conectadas a velocidades que variam de 64 Kbits/s a gigabits por segundo.
Unindo-se a enorme capacidade de processamento dos microcomputadores modernos à capacidade de compartilhamento oferecida pelas redes, passou a ser possível a montagem de sistemas compostos por diversos computadores conectados. Segundo Tanenbaum e Steen (2008, p. 1), estes sistemas costumam ser denominados sistemas distribuídos, em comparação com os Sistemas Centralizados anteriores, que consistem em um único computador, seus periféricos e talvez, alguns terminais remotos.
Na última década, o crescimento da Internet popularizou o conceito de sistemas distribuídos. O usuário acessa parte da aplicação em seu browser, sem ter a mínima idéia de onde está rodando o restante do sistema que efetivamente processará suas requisições.
Os sistemas distribuídos, em sua maioria, rodam em ambientes heterogêneos, formados por computadores com diversas arquiteturas e sistemas operacionais. Em computação, quando há necessidade de integrar componentes com estas características, utiliza-se o conceito de middleware, uma camada adicional de software que provê uma interface comum à componentes heterogêneos (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 29).
Existem diferentes implementações de middlewares para integração de sistemas distribuídos. As primeiras plataformas utilizavam técnicas procedurais, com chamada remota de procedimento, do inglês Remote Procedure Call (RPC), e baseavam-se no modelo cliente-servidor. Neste contexto, uma aplicação cliente invoca um procedimento remoto, passando como parâmetros, todas as informações necessárias para que o processo servidor possa tratá-lo. Posteriormente, surgiram middlewares orientados a objetos, como Common Object Request Broker Architeture (CORBA) e Java RMI. Todos os modelos de middleware têm como princípio básico encapsular os detalhes de comunicação exigidos pelos diferentes sistemas operacionais e arquiteturas de rede, facilitando o desenvolvimento das aplicações distribuídas.
A categoria de middlewares orientada a objetos, foco deste trabalho, também é conhecida como Objetos Distribuídos. A vantagem da aplicação de técnicas de objetos distribuídos é que leva-se para os sistemas distribuídos o paradigma da Programação Orientada a Objetos (POO). Neste contexto, além de abstrair detalhes da transmissão de dados entre os computadores da rede, o middleware de objeto distribuído, deve prover todas as características da POO como herança e polimorfismo, por exemplo.
Atualmente, alternativas “não orientadas a objetos” têm surgido com força no mercado, como Web Services e Service Oriented Architecture (SOA). Embora ofereçam facilidades por utilizarem o HyperText Trasnfer Protocol (HTTP) como protocolo de aplicação, estas alternativas provocam uma “mistura” de paradigmas nas aplicações desenvolvidas com técnicas de POO. Toda aplicação fica orientada à objetos, exceto as chamadas remotas. JAVA REMOTE METHOD INVOCATION (2008), diz que no baixo nível, os middlewares orientados a objetos fazem RPC, mas camadas de abstração adicionais, oferecem significativas vantagens aos programadores das linguagens orientadas a objetos.
A recente popularização da computação móvel tem aumentado significativamente a demanda por sistema distribuídos. Porém, as opções de middlewares disponíveis não são adequadas aos dispositivos portáteis, que em sua maioria têm pouca memória e limitada capacidade de processamento. Além disso, os Web Services exigem significativas configurações nos servidores e Java RMI e CORBA, abertura de portas de comunicação específicas nem sempre compatíveis com as políticas, cada vez mais rígidas, de segurança de rede das empresas.
Para Herity (2006, tradução nossa), “middlewares para objetos distribuídos têm alcançado sucesso no processamento distribuído tradicional. CORBA, COM e Java RMI são implementações bem conhecidas do paradigma. Mas estas tecnologias são projetadas para computadores com alta capacidade de processamento, muita memória e sistemas operacionais com muitos recursos”. Não há segundo ele, um middleware para objetos distribuídos adequado para sistemas embarcados.
Frente ao exposto acima, este trabalho se propõe a desenvolver um middleware com as seguintes características:
a) facilidade de implantação e o nível de abstração e aderência ao paradigma orientado a objetos semelhante do Java RMI;
b) facilidade de utilização na Web e compatibilidade com firewalls como os Web servises;
c) leve e configurável para ser suportado pelos dispositivos móveis.
Além das característica acima, o middleware deve ter a estratégia de serialização dos objetos configurável. Isso é necessário porque o Java Micro Edition (JME) não provê serialização de objetos e neste caso, o programador da aplicação terá que implementar a serialização, seguindo uma especificação do middleware. Por outro lado, caso o middleware venha a ser utilizado num ambiente Java Standard Edition (JSE) ou Java Enterprise Edition (JEE), o que faz sentido pela facilidade com que lidará com firewalls, é desejável que utilize a serialização nativa do Java. Essa configuração do middleware, deverá ser via eXtensible Markup Language (XML), sem necessidade de alteração no código ou recompilações. |
| |
|
