Um middleware de objetos distribuídos para Android

On 27 de agosto de 2012 by lucasscf

As API’s existentes nas linguagens de programação são complexas para programadores menos experientes, principalmente quando precisamos implementar aplicações que necessitam de computação paralela ou distribuída.

Um sistema distribuído pode ser caracterizado através de um modelo computacional de cliente-servidor, peer-to-peer (P2P) e objetos distribuídos. Basicamente o modelo computacional cliente-servidor é representado por um cliente que realiza requisições para o servidor e este retorna ao cliente o resultado do processamento. O modelo P2P caracteriza-se pela descentralização das funções na rede, onde cada modo realiza tanto funções de servidor quanto de cliente. Já os objetos distribuídos podem ser caracterizados semelhantemente ao modelo P2P, porém utiliza-se de um middleware como intermediário no processo de comunicação.

Uma das principais características de um sistema de objetos distribuídos é permitir a operação com objetos remotos. Através de uma aplicação cliente orientada a objetos, podemos obter uma referência para um objeto que oferece o serviço desejado e, através dessa referência, invocar métodos desse objeto – mesmo que a instância desse objeto esteja em uma máquina diferente daquela do objeto cliente. Exemplos de sistemas distribuídos são: Java RMI, CORBA e DCOM

Um middleware é a designação genérica utilizada para referir aos sistemas de software que se executam entre as aplicações e os sistemas operacionais. É geralmente constituído por módulos dotados com API’s de alto nível que proporcionam a sua integração com aplicações desenvolvidas em diversas linguagens de programação e interfaces de baixo nível que permitem a sua independência relativamente ao dispositivo a fim de facilitar o desenvolvimento de aplicações de forma a mascarar a heterogeneidade.

A plataforma móvel usada, o Android, possui uma forte integração com os web services. Contudo, ainda é um desafio o projeto eficiente de uma arquitetura orientada a serviços que abstraia as diferentes características dos dispositivos móveis com os web services. Um cenário que permita que dispositivos móveis possam comunicar entre si de maneira irrestrita e com outros web services. Em adição a isso, os recursos dos dispositivos móveis são escassos e limitados. O desafio principal é conseguir trazer o mundo dos web services para esta classe de dispositivo.

Baseado nisto, apresentamos um middleware de objetos distribuídos para dispositivos móveis (Android), desenvolvido em linguagem nativa C++ com interface e recursos da biblioteca QT, que torne transparente a programação de usuários programadores através de um sistema distribuído com o cliente assíncrono e com transparência de localização, nomeação e persistência dos resultados. Tecnicamente, o sistema provê de métodos de stub e sockets como solução de conexão entre clientes e servidores. Além disso, permite a integração com outras diversas plataformas, como Windows e Linux. Este middleware servirá tanto para processamento de aplicações no modo distribuído e paralelo quanto para processamento de aplicações de recuperação da informação.

Web services versus Objetos Distribuidos

Web services fazem parte da solução utilizada na integração de sistemas e na comunicação entre diferentes aplicações. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Web services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos pelo web service. Cada aplicação pode ter a sua própria “linguagem”, que é traduzida para uma linguagem universal, o formato XML. Basicamente, o objetivo dos web services é permitir a comunicação de aplicações através da Internet. Para a comunicação entre as aplicações, o transporte dos dados é realizado normalmente via protocolo HTTP ou HTTPS para conexões seguras. Os dados são transferidos no formato XML, encapsulados pelo protocolo SOAP.

Apesar da grande popularidade dos web services algumas limitações são encontradas nesta tecnologia, como segurança e privacidade pela utilização de HTTP, mensagens e encaminhamento pela falta de suporte das funcionalidades das mensagens assíncronas tradicionais, qualidade de serviço, por não garantir tempos de resposta e detecção de exceções, processamento transacional, gestão pela limitação de controle do estado e comportamento dos web services, desempenho por não realizar as execuções de forma otimizadas, e interoperabilidade por não garantir uma plataforma perfeita de integração entre aplicações e diferentes linguagens e implementados em qualquer sistema operativo. Dentre todas as limitações da tecnologia de web services outra será mais detalhada e melhor discutida neste artigo: o overhead de formatação dos documentos XML nos web services.

Conforme é apresentado por [Tian et al. 2003] antes de se realizar qualquer comunicação entre aplicações via XML em um web service, primeiramente a mensagem com o documento XML deve ser analisada tanto no lado do cliente quanto do servidor. Este tipo de análise em tempo de execução requer tempo de processamento adicional, que pode resultar em maior tempo de resposta do servidor, no caso de um servidor de web service.

Uma alternativa, a fim de escapar do overhead na formatação de arquivos XML em web services, é a adoção de aplicações baseadas em objetos distribuídos.

Podemos caracterizar objetos distribuídos como a tecnologia de orientação a objetos em um ambiente distribuído. A idéia básica dos objetos distribuídos é uma extensão do conceito onde um código é executado remotamente por intermédio de RPC (Remote Procedure Call). No paradigma RPC a unidade de distribuição é um procedimento (uma função ou método). Um cliente deve importar um stub para poder efetuar uma conexão com um servidor que oferece uma chamada remota.

No artigo [Birman 2004] o autor aproxima o conceito de web services com o de objetos distribuídos quando diz: “Web services é o que há de mais recente em uma longa série de plataformas interoperáveis orientadas a objetos e mistura idéias de CORBA, J2EE. e .NET enquanto explora a utilização de XML e outras tecnologias baseadas em documentos web. Desenvolvedores que utilizam plataformas de middlewares populares podem transformar um objeto de programa em um objeto de web service, ou acessar um objeto remoto com o toque de um botão”. Porém, podemos ver que no artigo [Vogels 2003] o autor expõe as diferenças entre web services e objetos distribuídos quando diz: “A troca de mensagens de documentos XML é muito diferente de pedir a instanciação de um objeto, solicitando um método de invocação remoto por intermédio de RPC”. Além disso, no trabalho de [Cook and Barfield 2006] é exposto um trabalho detalhado da diferença entre web services e objetos distribuídos. Neste trabalho, os autores apresentam um estudo de desempenho entre as duas tecnologias e verificaram que implementações RMI executam em tempo n(L+T +D) enquanto os web services executam em L+nT +W, onde n é o número de operações realizadas em um lote. O tamanho do lote que serão executados tantos os web services e objetos distribuídos é de n = (L+W) = (L+D). O desempenho pode ser aproximado por um modelo simples, baseado na latência L o tempo de transmissão / codificação tempo T (definido como o tamanho da mensagem dividida pela largura de banda), overhead de objetos distribuídos D e overhead de web service W. No trabalho foi identificado que a interface de web services é estranha e difícil de usar. Já a implementação do RMI é de fácil uso, mas tem problemas significativos de desempenho para acesso a vários arquivos de caminhos longos.

Arquitetura do middleware de objetos distribuídos para dispositivos Android

Figura 1. Middleware de objetos distribuídos para dispositivos Android

Conforme é apresentado pela Figura 1, a arquitetura deste middleware de objetos distribuídos para dispositivos Android é constituída pela seguinte estrutura: Clientes assíncronos que podem ser dispositivos Android e computadores com sistema operacional Linux ou Windows, e Servidores que também podem ser dispositivos Android e computadores com sistema operacional Linux ou Windows. Há também um Servidor de resolução de nomes entre cliente e servidor e um Data Access Object que permite a persistência de dados retornados aos clientes após a requisição de um processamento.
O usuário insere apenas o nome de seu objeto a ser executado e os devidos parâmetros necessários. O computador ou dispositivo cliente realiza uma requisição para o servidor de nomes para identificar o destino do servidor responsável para processamento do determinado objeto a ser invocado. O servidor de nomes retorna ao cliente o destino do servidor e o cliente estabelece então a conexão com o servidor determinado. Este servidor, responsável por processar o objeto invocado, realiza o processamento solicitado e o cliente aguarda o fim da execução de forma assíncrona. Os objetos que possuem a classe do problema a ser executado são encapsulados em arquivos de configuração (.so e .dll) e mapeados devidamente ao servidor. O servidor retorna o resultado do processamento ao cliente e envia o mesmo para o Data Access Object para persistência dos resultados obtidos.

Nas Figuras 2 e 3 apresentamos os diagramas de classe do cliente e servidor do middleware de objetos distribuídos para dispositivos Android.

Figura 2. Diagrama de Classes – Cliente

Figura 3. Diagrama de Classes – Servidor

A classe Client é responsável por fazer conexão com o servidor através de um stub. Nesta classe, são carregados os plugins (objetos) que se encontram no servidor. Já a classe Server mantém a conexão com o cliente através da classe ClientSocket. A classe Server também verifica as questões de transparência de localização e nomeação. Já a classe ClientSocket realiza as trocas de mensagens com o cliente através das funções response, invoke, receive, request e forward.

Deixe um comentário

O seu endereço de e-mail não será publicado.