Vous êtes sur la page 1sur 7

METAORB: UMA PLATAFORMA DE MIDDLEWARE PARA SISTEMAS

DISTRIBUÍDOS

Carlos Eduardo de Melo1

RESUMO
Este artigo descreve uma plataforma de middleware para sistemas distribuídos
baseada em componentes capaz de configuração estática assim como adaptação e
reconfiguração dinâmica.

Palavras-chave: Middleware, Computação Móvel, Multimídia, Sistemas Distribuídos.

1
Bacharelando em Ciências da Computação
Instituto de Informática
Universidade Federal de Goiás
Email: ceduardo.melo@inf.ufg.br
1 INTRODUÇÃO
O surgimento de padrões e tecnologias de middleware para desenvolvimento
de sistemas distribuídos como RM-ODP, CORBA, Java RMI, DCOM e .NET,
consolidou o uso desta abordagem no desenvolvimento de aplicações distribuídas. A
ampla utilização desta abordagem impulsionou o interesse no desenvolvimento de
aplicações distribuídas de larga escala cujos exemplos mais notáveis são as
aplicações de multimídia distribuída e os ambientes de computação móvel. Apesar
do sucesso dos modelos tradicionais de middleware, estes possuem limitações
fundamentais quando se trata de suportar estas novas áreas de aplicações. Assim,
um novo requisito importante surge com estas novas áreas, a flexibilidade. Durante
a última década, o desenvolvimento de plataformas de middleware mudou
significativamente, surgindo assim, novos padrões mais flexíveis a alterações no
ambiente computacional, os middlewares reflexivos.
Devido à imersão de computação móvel no escopo de sistemas distribuídos,
despontam novos problemas a serem tratados no âmbito do núcleo da plataforma,
objetivando o fornecimento de um nível alto de abstração e transparência para o
usuário. Em razão da fundamentação dos sistemas distribuídos ser, em súmula, a
comunicação entre pontos remotos interligados, o problema digno de maior
consideração é o da instabilidade das redes sem fio. Estas introduzem problemas
não conhecidos em redes com enlace físico como perda de sinal, baixa taxa de
transmissão, maior latência, handover e roteamento, segurança e confiabilidade das
conexões, entre outros. Destarte, nasce a gerência de mobilidade que, dentre outras
funções, tem por fim gerir a comunicação sem fio da plataforma fornecendo
confiabilidade na manutenção das conexões e, em casos excepcionais, no
tratamento de erros destas.
Visando a solução para o problema de flexibilidade das plataformas de
middleware, foi desenvolvido utilizando a linguagem Java™ o MetaORB, uma
plataforma capaz de se adaptar e reconfigurar dinamicamente, baseada no padrão
OpenORB (BLAIR et AL, 2001), com suporte a dispositivos móveis e gerenciamento
de mobilidade.
2 Modelo de Programação e Arquitetura
Por ter como base a abordagem OpenORB, que propõe a utilização de
reflexão computacional para construção de middleware flexível, o MetaORB utiliza
um modelo de programação baseado em componentes com o objetivo de facilitar a
construção de configurações e sua reconfiguração posterior. A plataforma possui três
unidades básicas em seu modelo de programação: componentes, interfaces e
bindings.
Componentes são unidades da plataforma que encapsulam funcionalidades
que podem ser acessadas utilizando interfaces. São definidas ainda, no modelo de
programação, duas categorias de componentes, os primitivos e os compostos. Os
componentes primitivos possuem funcionalidades de uma aplicação encapsuladas
de forma atômica, implementadas em alguma linguagem. Os componentes
compostos são formados pela ligação entre dois ou mais componentes (primitivos ou
compostos) representando sua funcionalidade em um único componente.
Interfaces são os únicos pontos de acesso que fornecem tanto acesso
externo ao componente quanto acesso do componente ao exterior. Na plataforma,
as interfaces também são divididas em categorias, sendo elas interfaces
operacionais, de sinal e de fluxo. As interfaces operacionais definem operações que
podem ser requeridas por outras interfaces, caracterizando uma relação
cliente/servidor entre os componentes envolvidos na ligação. As de sinal são
utilizadas para modelar eventos de interação primitivos, i.e., que não necessitam de
retorno. As interfaces de fluxo são utilizadas por aplicações multimídia, pois
permitem a comunicação entre produtores e consumidores utilizando fluxos de
dados.
Bindings representam a ligação entre duas interfaces de dois componentes
distintos, estejam eles no mesmo espaço de endereçamento (bindings locais) ou em
espaços de endereçamento distintos (bindings remotos). Os bindings remotos
podem ser implícitos ou explícitos. Para a criação de bindings implícitos, é utilizada
uma camada extra de software denominada stub. Os stubs (ou proxies) têm suas
instâncias armazenadas localmente e escondem os mecanismos de comunicação
entre aplicações distribuídas. Assim, os componentes interagem com os stubs que
possuem as mesmas interfaces que os objetos remotos, então os stubs fazem o
tratamento da chamada de método, entregando uma mensagem ao módulo de
comunicação (descrito posteriormente). De forma semelhante, porém reversa,
acontece ao se chegar uma mensagem no outro módulo remoto. A mensagem é
recebida pelo módulo de comunicação que repassa a mensagem para um skeleton
que, semelhante ao stub, é uma camada extra de software responsável por tratar a
mensagem e repassar a chamada de método para o componente final. Os bindings
explícitos podem ser considerados elementos distribuídos criados explicitamente
para ligar interfaces de componentes remotos, como a estrutura criada para a
comunicação dos objetos descrita anteriormente. Ao contrário dos bindings locais e
implícitos, os explícitos possuem uma estrutura interna formada por componentes e
outros bindings explícitos aninhados, a qual define como será realizada a interação
entre os componentes. A estrutura interna dos bindings pode ser modificada para
reconfigurar uma interação.
A arquitetura do MetaORB é composta por uma série de serviços de
middleware, constituído dos serviços convencionais, dos de gerenciamento de
nomes e de mobilidade, do repositório de tipos, e dos serviços de suporte a
reconfiguração, como as fábricas de componentes e os bindings.

2.1 Cápsulas
As instâncias básicas da plataforma são as cápsulas. Estas contêm os
serviços daquela e fornece a localização dos elementos criados em seu contexto.
Assim, no escopo da plataforma, interações remotas são aquelas realizadas entre
elementos de cápsulas distintas.

2.2 Repositório de Tipos


O gerenciamento de meta-informações, característica essencial na criação de
configurações, é realizado pelo repositório de tipos. Este fornece as definições em
formato textual, sendo previsto uso de formato XML em versões posteriores.

2.3 Fábricas
Na plataforma MetaORB, os elementos de primeira ordem – elementos
citados anteriormente neste artigo, no início da seção – são criados por fábricas que
são componentes especiais da plataforma. No escopo da plataforma existem duas
fábricas, sendo elas, a fábrica de componentes e a fábrica de bindings.
A fábrica de componentes possui como principais funções a busca da
definição do componente no repositório de tipos e, em seguida, a criação do
componente, seja ele simples ou composto, a partir de sua implementação, a
criação das interfaces e o registro dos nomes envolvidos na criação no serviço de
nomes.
De forma semelhante, a fábrica de bindings também solicita ao repositório as
definições dos elementos a serem criados, no caso, bindings. Em seguida cria os
componentes, interfaces e outros bindings que constituem o binding sendo criado,
trabalhando em conjunto com outras fábricas que criam os elementos do binding em
locais distintos da rede.

2.4 Serviço de Nomes


A função do serviço de nomes é de garantir a localização de elementos da
plataforma através de referências às interfaces destes elementos, cujas quais foram
criadas em cápsulas ativas da plataforma e que foram registradas no serviço. Como
referências de interfaces, pode-se dizer que são “representações locais de interfaces
localizadas remotamente” (PROVENSI, 2006, p. 31).

3. O Módulo de Comunicação
Devido à necessidade de portabilidade de dispositivos da plataforma (a
plataforma pode ser utilizada desde celulares a desktops) e à incompatibilidade das
APIs de comunicação das máquinas virtuais J2ME/CLDC (JSR 139, 2006) e J2SE
(JSR 270, 2006), foi projetado um módulo de comunicação que fornece uma única
interface para qualquer versão da máquina virtual Java™. Na versão para desktop
do módulo de comunicação, foi utilizada a biblioteca Apache MINA™, escrita
totalmente em Java, que suporta a criação de servidores de alta escalabilidade. Na
versão para J2ME, o módulo foi implementado sem utilizar nenhuma biblioteca de
auxílio.
A máquina virtual da configuração J2ME/CLDC não fornece suporte à reflexão
computacional. Com isso, um esquema de serialização de objetos foi necessário
para contornar o problema. Este esquema foi baseado no artigo (SIERRA, 2006),
porém aperfeiçoado, visando aumentar o desempenho no processo da serialização.
Com o intuito de diminuir a quantidade de dados trafegados nas redes sem
fio, o formato da mensagem entre instâncias do módulo de comunicação é binário,
não textual como em CORBA.
4. Gerência de Mobilidade
Um dos problemas mais comuns ao se trabalhar com redes sem fio é a sua
instabilidade. Esta instabilidade é caracterizada pela alta latência da rede, baixa
largura de banda, facilidade de perda de sinal e interferências. Assim, como parte da
plataforma existe o módulo de gerenciamento de configuração.
Este módulo é constituído por um servidor proxy que gerencia a conexão
entre dispositivos móveis e o restante dos nós da plataforma. Este servidor gerencia
as mensagens trocadas e, em caso de perda de sinal, assume o lugar do dispositivo
móvel até que o sinal seja restabelecido. Se a perda de sinal durar muito tempo, é
responsabilidade do proxy de informar a plataforma da saída do dispositivo.
Outra parte deste módulo é formada por um sistema que garante o uso da
melhor conexão disponível, baseado na qualidade de serviço desejada – seja
diminuindo custos ou aumentando a largura de banda ao máximo. Este processo é
conhecido como handover.

5. Conclusão
A plataforma foi desenvolvida utilizando linguagem Java, oferecendo suporte
a configurações e reconfigurações dinâmicas. Com a imersão de dispositivos
móveis, alguns problemas relacionados à comunicação e ao poder de
processamento puderam ser resolvidos utilizando métodos bastante divulgados, com
alguns aperfeiçoamentos.
REFERÊNCIAS

ADELSTEIN, Frank; SANDEEP, KS Gupta; RICHARD, Gupta III; SCHWIEBERT,


Loren. Fundamentals of Mobile and Pervasive Computing. California: McGraw-
Hill Professional, 2004.

BLAIR, Gordon; COULSON, George; ANDERSEN, Anders; CLARKE, Michael;


COSTA, Fábio; DURAN, Hector; MOREIRA, Rui; PARLAVANTZAS, Nikos;
SAIKOSKI, Katia. The Design and Implementation of Open ORB version 2. Vol 2,
No. 6. IEEE Distributed Systems Online Journal, 2001.

COSTA, Fábio Moreira. Combining Meta-Information Management and


Reflection in an Architecture for Configurable and Reconfigurable Middleware.
Lancaster: Lancaster University, 2001.

SUN. JSR 139: Connected Limited Device Configuration 1.1. 2006.

SUN. JSR 270: Java SE 6 Release Contents. 2006.

PROVENSI, Lucas Luiz. Uma Infra-Estrutura de Suporte a Binding Explícito na


Plataforma MetaORB4Java. Goiânia: UFG, 2006.

SIERRA, Antonio J. Recursive and non-recursive method to serialize object at


J2ME. Sevilla: University of Sevilla, 2006.

Vous aimerez peut-être aussi