1
NetLab Web Lab: um laboratório de
experimentação remota para o ensino de redes de
computadores baseado em SOA
L. Agostinho UFU, A. F. Farias UFU , L. F. Faina UFU,
E. G. Guimarães CenPRA, P. R. S. L. Coelho Unicamp, E. Cardozo Unicamp
Resumo– A diversidade de ambientes de EAD para Web
proporciona a seus usuários diferentes funcionalidades que
podem ser exploradas no processo de ensino e aprendizagem
à distância. Neste sentido, este artigo apresenta uma arquite-
tura para a construção de laboratórios de acesso remoto (ou
Web Labs) segundo o paradigma de computação orientada a
serviço. Nesta arquitetura, os blocos elementares são serviços
que, recursivamente, podem ser combinados na construção de
serviços mais complexos. Cada recurso do laboratório (fı́sico
ou lógico) é modelado e implementado como um Serviço Web
e experimentos oferecidos pelo Web Lab são construı́dos por
meio da composição destes serviços. Um Web Lab construı́do
segundo a arquitetura proposta é apresentado, juntamente com
exemplos de experimentos remotos na área de redes de serviços
diferenciados.
Palavras-chave– Web lab, Computação orientada a serviço,
Laboratório de Acesso Remoto, Redes DiffServ, Serviços Web.
I. I NTRODUÇ ÃO
Internet, através da Web, tem contribuı́do para o surgi-
A mento de ambientes de ensino e aprendizagem cada vez
mais dinâmicos e interativos. Estes ambientes disponibilizam
ferramentas diversas que permitem professores e alunos explo-
rarem positivamente a Web como um meio para compartilhar
conhecimento.
O número crescente de usuários que necessitam usar a
Internet para fins educacionais intensifica a diversidade de
preferências, interesses e capacitação de alunos.
Neste sentido, este artigo propõe o desenvolvimento de
um Web lab utilizando o paradigma da arquitetura orien-
tada a serviço, implementando um modelo conceitual uti-
lizando serviços web, classificados em três categorias: serviços
de acesso, de interação e comunicação (ou difusão). Estes
serviços constituem na infra-estrutura básica para um Web lab.
Laboratórios de experimentação remota têm sido propostos
como poderosas ferramentas de suporte ao ensino. Apesar da
literatura apresentar um grande número de implementações,
poucas destas implementações que seguem o paradigma da
Arquitetura Orientada a Serviço (SOA).
Web labs foram desenvolvidos inicialmente com as mais
diversas tecnologias Web. O Projeto iLAB [MIT 2006] con-
duzido pelo MIT é pioneiro em utilizar serviços Web no
À CAPES pelo financiamento de bolsas de estudos para que esta pesquisa
fosse realizada.
adriano.fiad@gmail.com
domı́nio de Web labs. O iLAB desacopla as funcionalidades
especı́ficas dos Web labs relativas a execução dos experi-
mentos, das funcionalidades administrativas gerais, tais como
autenticação, registro e autorização de usuários, gerência de
grupos e armazenamento de resultados dos experimentos. Para
as tarefas administrativas, iLAB usa um Service Broker que
concentra e processa as requisições de gerenciamento e uso
de Web Labs.
A proposta aqui apresentada possui similaridades com o
iLAB, como desacoplamento entre o uso e a gerência do
Web lab, utilização de serviços web para gerência e acesso ao
laboratório. As principais diferenças da arquitetura proposta
em relação ao iLAB são: composição de serviços para a
construção dos experimentos; utilização de navegador padrão
para execução dos experimentos e acesso por diferentes tipos
de terminais (notebooks, palms e celulares).
O trabalho está assim dividido, Seção II apresenta a arquite-
tura orientada a serviço. A Seção III apresenta o framework
proposto para um Web Lab com a arquitetura SOA. O labo-
ratório remoto NetLab Web Lab é apresentado na Seção IV.
DiffServ e QoS são apresentados na seção V. Finalmente, a
Seção VI tece considerações finais.
Abril, 2008
II. A RQUITETURA O RIENTADA A S ERVIÇO
O paradigma de computação orientada a serviço, Service
Oriented Computing (SOC), e sua respectiva arquitetura de
suporte, Service Oriented Architecture (SOA), são considera-
dos atualmente os mais promissores na área de computação
distribuı́da. O paradigma SOC prega a interoperabilidade e
o fraco acoplamento entre elementos básicos (serviços) de
software através da definição de interfaces neutras e da
utilização de protocolos de transporte padronizados. Serviços
são unidades lógicas de software, podendo encapsular um sim-
ples método ou um grande processo envolvendo múltiplos co-
laboradores [Souza 2005]. Algumas caracterı́sticas relevantes
da SOC:
• Interoperabilidade - alcançada com o uso de um protocolo
de transporte independente, usualmente HTTP (HiperText
Transfer Protocol);
• Capacidade de composição - serviços podem ser com-
postos para formar outro serviço, provendo um modo
de criação de novos serviços flexı́vel, rápido e de baixo
custo;

• Capacidade de reuso - sendo uma unidade modular e
auto-contida de software, serviços podem ser reutilizados,
reduzindo o tempo e esforço para criar novas aplicações;
• Ubiqüidade - serviços podem ser acessados através da
Internet de qualquer lugar a qualquer momento;
• Acoplamento - um fraco acoplamento é alcançado em
diferentes nı́veis:
– Apenas as interfaces expostas pelos serviços são uti-
lizadas nos mecanismos de composição de serviços;
– Com o uso de mecanismos de registro e descoberta
desacopla-se o uso da localização do serviço;
– Acoplamento à linguagem e plataforma pode ser evi-
tado usando um protocolo de transporte independente
de plataforma;
A SOC utiliza serviços como elementos fundamentais
para o Desenvolvimento de aplicações/soluções. Serviços são
elementos computacionais auto- descritı́veis e independentes
de plataforma que suportam uma composição rápida e de
baixo custo de aplicações distribuı́das [Papazoglou 2003].
Esses serviços são oferecidos por provedores de serviços,
os quais fornecem a descrição do serviço, bem como
suporte técnico e de negócio. Desta forma, provê-
se uma infra-estrutura de computação distribuı́da para
integração e colaboração de aplicações intra-domı́nio inter-
domı́nio [Leymann et al. 2002].
SOA é uma arquitetura para organização e utilização de
competências distribuı́das que estão sob controle de dife-
rentes domı́nios proprietários através de diferentes unidades
funcionais, ou serviços, de uma aplicação com interfaces e
contratos entre estes domı́nios bem definidos [Bueno 2006].
Na arquitetura SOA, as interfaces dos diversos serviços são
definidas de forma neutra, independente da plataforma de hard-
ware, sistema operacional e linguagem de programação. Isso
permite que serviços desenvolvidos em diferentes plataformas
de hardware e software possam interagir entre si de maneira
uniforme e universal. Esse baixo acoplamento traz benefı́cios
na habilidade e agilidade de sobreviver a mudanças evolu-
cionárias na estrutura e na implementação interna de cada
serviço que compõe a aplicação distribuı́da. A tecnologia atual
que mais conformidade possui com a arquitetura e com o
paradigma de computação orientada a serviços é notadamente
a de serviços web.
A. Serviços Web
Serviços Web (Web Services) são definidos como uma tec-
nologia para a integração de sistemas distribuı́dos [Neto 2006].
Essa tecnologia baseia-se na troca de mensagens em formato
XML (E’x’tended ’M’arkup ’L’anguage) para a comunicação
entre as aplicações.
SOAP (Simple Object Access Protocol) é um protocolo de
comunicação baseado em XML e que também confere um
formato de codificação para comunicação entre aplicações
distribuı́das que utilizam SOA. O SOAP é visto como a nova
geração para aplicações de computação distribuı́da conhecidas
como serviços Web.
Um serviço web é um sistema de software projetado para su-
portar interações máquina-máquina interoperáveis sobre uma
2
rede. O serviço web possui uma interface descrita em um
formato passı́vel de processamento pela máquina, especifica-
mente Web Service Description Language (WSDL). Outros
sistemas interagem com o serviço web da maneira definida
na sua interface usando mensagens SOAP (Simple Object
Access Protocol), tipicamente transportadas usando HTTP
com serialização XML (Extensible Markup Language) e em
conjunto com outros padrões relacionados à web.
Um dos grandes diferenciais da tecnologia de serviços Web
é a possibilidade de realizar a troca de mensagens na Internet
sem que estas sejam bloqueadas, a priori, por um sistema de
firewall. Ao contrário de outras tecnologias, o uso do padrão
SOAP permite realizar a troca de informações como se estas
fossem arquivos HTML modificados. Na verdade, estes são
documentos XML cujas informações podem ser interpretadas
como métodos a serem executados, como dados, ou como
qualquer outro tipo de informação definida no Serviço Web.
Por utilizar SOAP é possı́vel integrar sistemas distintos, es-
critos em linguagens de programação diferentes e utilizando
padrões gratuitos de código-fonte aberto.
III. A RQUITETURA PARA W EB L ABS SOA
A arquitetura proposta neste artigo e apresentada através
do NetLab Web Lab permite a criação de experimentos a
partir da composição dos serviços oferecidos, classificados em
três categorias: serviços de acesso, interação e comunicação.
Novos serviços (experimentos) podem ser adicionados sem
qualquer interferência àqueles já existentes. Essa composição
de serviços pode ainda utilizar serviços oferecidos por outros
Web labs, formando assim uma federação de Web labs.
Serviço de interação Serviço de Acesso Serviço de Comunicação
Experimento 1
Gerenciamento
de usuários
Gerenciamento de
papéis e permissões
Serviço de
Difusão
Experimento 2
...
Gerenciamento Gerenciamento Serviço de
laboratório Sessão Streaming
Experimento n
Fig. 1. Arquitetura para Web Labs SOA
A Fig. 1 descreve a arquitetura proposta neste artigo em
um diagrama de pacotes UML. Os componentes apresentados
permitem ao usuário remoto ter acesso a uma gama de
experimentos disponibilizados no Web lab.
A. Serviços de acesso
O pacote de serviços de acesso reúne um conjunto de fun-
cionalidades para a administração de usuários e experimentos,
compreendendo o controle de acesso a laboratórios, bem como
o controle da sessão de uso dos experimentos.
O serviço de gerência de participantes é o responsável
pelo cadastro, exclusão e atualização de dados de usuários
(participantes). A cada participante deve ser atribuı́do um papel
(administrador, instrutor, estudante, etc) e uma permissão de
acesso que define as suas autorizações/restrições para deter-
minado experimento.

O serviço de gerência de papéis e permissões é o res-
ponsável pela adição, remoção e atribuição de papéis e per-
missões aos participantes do laboratório.
O serviço de gerência de laboratório é o responsável pelo
cadastro, exclusão e atualização de dados de Web labs, ex-
perimentos e recursos. O experimento reúne um conjunto de
recursos selecionados. Por sua vez, o recurso é a unidade do
experimento que pode sofrer alteração ou consulta. No entanto,
é necessário que todos os recursos do experimento tenham
sido reservados junto a Gerência do Laboratório para que seja
possı́vel iniciar o experimento. Ao usuário cabe somente a
reserva do experimento, enquanto que aos serviços de acesso a
garantia que os recursos associados ao experimentos reservado
estarão disponı́veis.
O serviço de gerência de sessão realiza a autenticação,
verificação da reserva do usuário e inı́cio da sessão de acesso
pelo perı́odo de tempo estabelecido para o experimento. A
sessão de acesso é finalizada pelo usuário ou pelo sistema, caso
o perı́odo de reserva tenha expirado. O serviço de gerência de
sessão inicia os serviços de interação (seção III-B) e propaga
no serviço de comunicação (seção III-C) eventos relativos ao
inı́cio e término de sessões.
B. Serviços de interação
Os serviços de interação correspondem aqueles que efeti-
vamente tornam o Web lab funcional do ponto de vista de
uso por parte do usuário final. No framework proposto, os
serviços de interação devem ser implementados como serviços
web especı́ficos para o domı́nio dos Web labs. Tendo em
vista os objetivos para o desenvolvimento do NetLab Web lab,
foram implementados serviços de interação que possibilitem
ao usuário um maior contato com tecnologias de redes de
computadores suportando a execução de experimentos, ofere-
cendo interfaces de manipulação de recursos necessários ao
experimento.
A utilização deste serviço depende do estabelecimento de
uma sessão de acesso para autenticar o participante e verificar
a existência de reserva para o uso do laboratório.
Lado Cliente
Aplicação Cliente Agente de Serviços Servidor de
Serviços Web
Site do Laboratório Gerenciador de
Serviços Remotos
Rede de Acesso
Fábrica de
Portal de Acesso Serviços Remotos
Fig. 2. Serviço de Interação em Web Labs SOA
Os laboratórios cadastrados no domı́nio podem ser vi-
sualizados através do componente Portal de Acesso, como
apresentado na Fig. 2. Cada laboratório possui um conjunto de
experimentos que podem ser acessados através do componente
aplicação cliente, acessı́vel para o usuário, através do link
encontrado no site do laboratório. Ao acessar esse link o
3
componente agente de serviços é chamado para encaminhar
a solicitação de inicialização de serviços remotos. no compo-
nente servidor de serviços web encontram-se disponibilizados
os serviços web para os experimentos no Web lab.
O Agente de Serviços informa ao Serviço Web Gerenciador
de Serviços Remotos os hosts do experimento e quais os
Serviços Remotos que devem ser instanciados nesses hosts.
Isso é feito porque serão os Serviços Remotos os responsáveis
por executar eventos e estes serviços devem ser inicializados
antes da Aplicação Cliente, garantindo a presença dos recursos
para o usuário.
As Fábricas de Serviços são componentes responsáveis
pela instanciação de Serviços Remotos. O Gerenciador de
Serviços Remotos deve conter a lógica de negócio necessária
para localizar e informar quais Serviços Remotos devem
ser instanciados por cada uma das Fábricas de Serviços da
rede interna. Cada host gerenciável do laboratório possui a
sua própria Fábrica de Serviços. Uma vez que os Serviços
Remotos estejam ativos o Agente de Serviços redireciona a
execução para a Aplicação Cliente.
A comunicação entre a Aplicação Cliente e a rede interna do
laboratório é limitada pela visão disponibilizada para o usuário
do experimento. Dessa forma, apenas os recursos reservados
serão passı́veis de consulta e/ou alteração.
Os eventos do usuário são encaminhados para o Servidor
de serviços Web utilizando o protocolo SOAP. Cada evento
possui o seu respectivo Serviço Web e Serviço Remoto. O
Serviço Web é o responsável por encaminhar as solicitações
do usuário para a rede interna; já o Serviço Remoto é o
responsável por executá-las. Uma vez que a solicitação tenha
sido processada pelo Serviço Remoto cabe ao Serviço Web
redirecionar a resposta para a Aplicação Cliente.
C. Serviços de comunicação
Para suporte à comunicação foram especificados dois
serviços: serviços de difusão e serviço de streaming; O serviço
de difusão é responsável por prover comunicação ponto-
multiponto entre usuários e Web lab. O serviço é baseado no
modelo produtor-consumidor, sendo responsável pela entrega
Rede Interna do Laboratório aos consumidores dos documentos submetidos pelos produ-
Serviço Web tores de informação.
O serviço de difusão Fig. 3 expões uma interface WSDL que
permite o registro de produtores e consumidores, a submissão
Serviço Remoto de documentos para difusão e a consulta de documentos ar-
mazenados. Aos documentos submetidos, o Gerente Produtor
* acrescenta uma marca de tempo e os repassa ao Canal de
Difusão. No canal é averiguado se o documento é persistente
1
ou transiente, de acordo com o tempo de vida estipulado pelo
produtor. Em caso de persistência, o documento é armazenado
na base de dados. Por último, o Gerente Consumidor procede
a entrega do documento aos consumidores registrados.
O serviço de streaming permite a gerência de fluxo de
mı́dia contı́nua entre produtores e consumidores de fluxo,
sendo implementado sobre o serviço de difusão. O serviço
de streaming suporta gerência de conexões multimı́dia ponto-
multiponto com negociação de parâmetros de mı́dia tais como
codificação e tamanho de vı́deo, codificação e tamanho da
amostra de áudio, taxa de amostragem, etc.
 4

Serviço de Difusão
cadastrados tenham acesso aos experimentos. Cabe também
Consumidor de
Produtor de
Informação
Gerente
Canal de Difusão
Gerente Informação ao site fornecer para o software do experimento as permissões
Produtor Consumidor
do usuário e a identificação do experimento.
Interface de
Base de Notificação
F1 F2 Fn
Dados
Filtros XPath
A. Arquitetura Fı́sica do NetLab Web Lab
A Fig. 4 mostra o ambiente onde os experimentos podem
usa
ser suportados. Os hosts do laboratório estão previamente
Produtor de Consumidor de
Fluxo Serviço de Streaming Fluxo configurados de maneira que cada um seja capaz de consultar
todos os demais. O host servidor da rede possui conexão
Interface de
Negociação~
Negociador
com a Internet para que seja possı́vel o acesso remoto ao
Fluxo de Mídia Contínua
Web Lab. Os hosts possuem NICs Ethernet 10/100/1000Mbps
conectados por um Switch Ethernet Gigabit formando a rede
Fig. 3. Componentes do serviço de difusão e streaming. principal do Web Lab. Aliado a isso, NICs 10/100Mbps são
utilizadas para a conexão com um HUB formando a rede de
retaguarda. Isso é necessário para garantir que as alterações no
IV. N ET L AB W EB L AB laboratório remoto sejam executadas fazendo com que os hosts
NetLab Web Lab é um laboratório da Universidade Federal envolvidos com os experimentos, em momento algum percam
de Uberlândia para ensino remoto de redes de computadores a conectividade com o servidor do laboratório. Essas NICs
aplicado em um domı́nio de Serviços Diferenciados. Atual- passam desapercebidas pelos usuários, pois as mesmas não são
mente, a garantia de recursos para aplicações que exigem um apresentadas a eles em momento algum, por serem interfaces
fluxo contı́nuo de informações tem se tornado cada vez mais administrativas, que servem para efetuar as configurações das
evidente. Por isso, a oferta de Serviços Diferenciados permite demais NICs envolvidas com os experimento e desfazer as
priorizar diferentes tipos de tráfego de dados. No entanto, configurações efetuadas pelos usuários ao término de cada
a configuração exige esforço para dispor uma rede fı́sica experimento. Os computadores utilizam o sistema operacional
que suporte essas alterações e o entendimento das complexas Linux Slackware 10.2 e kernel 2.6.15.6 com suporte a Serviços
configurações realizadas. O NetLab Web Lab se propõe a Diferenciados.
ser uma ferramenta que permita agregar funcionalidades para 192.168.10.3 192.168.10.5 192.168.10.6

o ensino de redes e Serviços Diferenciados (Differentiated

172.16.50.1 172.16.50.2
Services - DiffServ). Internet
172.16.20.2 172.16.20.1

A infraestrutura de software do laboratório é composta 172.16.70.1 172.16.10.2 172.16.30.1

por um container de serviços Web Apache Axis/Java, um

Zeus
container JSP/Servlet Apache Tomcat, um banco de dados Urano Poseidon

relacional MySQL e utiliza a tecnologia Java RMI para realizar 172.16.70.2

172.16.60.1 Rede Principal
172.16.60.2
a comunicação entre a rede interna do Web Lab e o container 172.16.10.1 172.16.30.2 Rede de Retaguarda

172.16.40.1 172.16.40.2
de Serviços Web.
Hodes
A parte administrativa do laboratório é realizada no site que Helios Gaia

implementa os Serviços de Acesso. Apenas o administrador 192.168.10.1 192.168.10.2 192.168.10.4

do sistema tem acesso a esse componente. As tarefas do
administrador incluem a gerência de participantes, de papéis e Fig. 4. Disposição Fı́sica do NetLab Web Lab.
permissões, do laboratório e da sessão do experimento, como
detalhado na arquitetura proposta.
Para que um experimento possa ser disponibilizado, o ad-
B. Experimentos no NetLab Web Lab
ministrador do sistema deve fazer a alocação de recursos para
o experimento. Feito isso, o experimento pode ser disponibi- A Fig. 5 representa a visão do experimento de configuração
lizado por um determinado perı́odo de tempo. Então, através da rede interna do laboratório remoto NetLab. Esse experi-
do site do NetLab Web Lab, os usuários podem realizar a mento tem o objetivo principal de verificar quais alterações
reserva de experimentos no dia e horário que considerarem permitem manter a comunicação entre os nós da rede. Neste
mais conveniente dentro da disponibilidade do laboratório. caso, os hosts e as suas respectivas interfaces de rede são os
O site do NetLab Web Lab apresenta links para os experi- recursos alocados para o experimento. Os seguintes eventos
mentos suportados (aplicação cliente). Ao selecionar um link estão disponı́veis para esse experimento:
o software do experimento será downloaded no computador • Alteração de IP: O usuário pode fazer a alteração remota
do usuário. Esses usuários têm acesso limitado aos recursos dos endereços IP das interfaces de rede. O intuito é
do laboratório, o que implica que a configuração apresentada permitir que o usuário compreenda o significado da
no software do experimento pode não refletir todos os recursos representação numérica que identifica unicamente a in-
disponı́veis e que ocorrem na rede. terface na rede.
O site do NetLab Web Lab comunica-se com os compo- • Rotas: O usuário pode fazer a consulta e a alteração das
nentes do Serviço de Acesso para que apenas os usuários rotas de encaminhamento de pacotes de cada um dos
 5

apresentados e testando a comunicação. Por outro lado, a

representação visual do experimento pode ser vista como um
atrativo.

Fig. 5. Experimento de configuração da rede interna do NetLab Web Lab.
hosts. O intuito é permitir que o usuário compreenda
que a simples alteração de endereços IP não garante a
comunicação entre dois ou mais hosts na rede.
• Teste de conexão: O usuário pode testar a comunicação
entre os dois nós da rede de forma a verificar periodica-
mente se as alterações realizadas nos eventos anteriores
surtiram efeito no enlace entre os hosts.
V. R ESULTADOS DO EXPERIMENTO DE Q O S
Aplicações de tempo-real que utilizam a Internet como meio
de integração de serviços de telefonia fixa, difusão de fluxos
de áudio e vı́deo, laboratórios virtuais, teleconferência e outros
mais, exigem um nı́vel maior de qualidade de envio e recepção
de informações se comparado com aplicações convencionais.
Para dispor de QoS (Quality of Service) em uma rede IP
três componentes têm de ser disponibilizados: manipulação
do tráfego, sinalização e configuração [Roberts 1999],
[Bernet 2000]. O primeiro diz respeito à manipulação do
fluxo de pacotes, escalonamento e algoritmos empregados para
o gerenciamento de cada fluxo. O segundo diz respeito à
forma como a marcação desses fluxos será interpretada para a
provisão de QoS na rede. Finalmente, o terceiro componente
lida com a medição, o monitoramento, o estabelecimento de
limiares e polı́ticas de controle do comportamento do tráfego
de pacotes.
Perda de pacotes (%)
140 AF11 obtida
AF21 obtida
AF22 obtida
120 BE obtida
EF obtida

• Configuração de Disciplinas de Fila: Para realizar testes 100

relacionados a Qualidade de Serviço, o usuário pode 80
realizar a configuração de disciplinas de fila nas interfaces
de rede. Devido o caráter pedagógico do experimento, 60

a configuração realizada em um nó pode ser propagada 40

por todos os nós da rede. A representação visual da
20
estrutura lógica da configuração aliada à exibição do
código auxiliam no entendimento da configuração. 0
0 10 20 30 40 50 60 70 80
Segundos

Vazão (MBytes / segundo)

12
AF11 obtida
AF21 obtida
AF22 obtida
10 BE obtida
EF obtida

Fig. 6. Experimento com Disciplinas de Fila no NetLab Web Lab. 0

0 10 20 30 40 50 60 70 80
Segundos

Os eventos apresentados podem ser utilizados para melhorar

o entendimento de aspectos importantes relacionados à teoria
de comunicação em redes de computadores. A arquitetura
do software do experimento permite que novas funcionali-
dades sejam agregadas sem comprometer as anteriores. De
forma semelhante, o mesmo aplicativo pode ser estendido
para comportar mais recursos da rede, combinando os eventos
Fig. 7. Comportamento Obtido dos Fluxos no Domı́nio DiffServ do
laboratório.
O NetLab Web Lab disponibiliza a configuração de Serviços
Diferenciados junto à rede interna do laboratório utilizando
uma representação gráfica das classes de comportamento,
filtros e disciplinas de fila. Para manter a semântica de

representação são informadas as linhas de comando e suas
respectivas alterações a cada iteração do usuário com o
experimento. Atualmente é possı́vel gerar fluxos de dados
pré-definidos para avaliar as configurações realizadas apenas
no laboratório, como mostra a Fig. 7. Pretende-se estender
essa aplicação para o tratamento de fluxos reais de mı́dia,
entendendo que os resultados a serem obtidos continuarão a
respeitar as configurações do domı́nio. Da mesma forma, a
representação gráfica dos fluxos será inserida na aplicação do
experimento.
VI. C ONCLUS ÕES
(HTTPS) apresenta um solução relativamente simples e bem
estabelecida para segurança. Apesar do protocolo HTTP ser
ineficiente para o transporte de fluxos multimı́dia em tempo
real, esta deficiência é minimizada pelo aumento constante da
capacidade das redes de comunicação.
A disponibilidade limitada de recursos ou ausência de con-
trole de acesso pode ser minimizada pela implementação de
serviços de acesso capazes de coordenar múltiplas instâncias
de um mesmo recurso e oferecer polı́ticas de acesso capazes
de gerenciar uso mediante reserva, papéis, permissões, grupos
e sessões.
Serviços Web eliminam a necessidade de utilização de sis-
temas de software proprietários no terminal do usuário. Além
de empregar padrões 100% abertos, Serviços Web podem ser
acessados a partir de múltiplos terminais, inclusive terminais
móveis como computadores de mão e telefones celulares.
O modelo de referência para Web Labs apresentado neste
artigo teve o objetivo de identificar os principais componentes
que devem ser implementados para a construção de Web
Labs SOA. Neste modelo, os experimentos são designados
através da composição de serviços oferecidos pelo Web Lab,
favorecendo assim a reusabilidade de código para a construção
de novos experimentos ou adaptação dos já existentes para
novos contextos. Está composição reduz drasticamente os
esforços para desenvolver experimentos de acesso remoto.
Finalmente, o maior benefı́cio de computação orientada
a serviço está na possibilidade de utilização de aplicações
de forma federada. No caso de Web Labs, os Serviços
Web utilizados para a construção de experimentos podem
ser disponibilizados para outros Web Labs, aumentando a
abrangência dos experimentos e perfis dos usuários. Para tanto,
os serviços de acesso devem ser capazes de honrar contratos
estabelecidos entre domı́nios administrativos distintos para fins
de autenticação, acesso e uso de serviços.
R EFERENCES
[Bernet 2000] Bernet, Y. (2000). “The Complementary Roles of RSVP
and Differentiated Services in the Full-Service QoS Network.”. IEEE
Commun. Mag., Vol.38(No.2).
[Bueno 2006] Bueno, J. F. e. a. (2006). Modelo de Referência para Arquite-
tura Orientada a Serviço 1.0. Technical Report, Comitê de Especificação
1.
[Cassini et al. 2004] Cassini, M., Prattichizzo, D., and Vicino, A. (2004).
The automatic control lab. In IEEE Control System Magazine.
[Chella 2000] Chella, Marco Túlio e Ferreira, E. C. (2000). Ferramenta
para o desenvolvimento de experimentos remotos com aplicações edu-
cacionais. VII Congresso Iberoamericano de Informática Educativa.
6
[Fernandez et al. 2005] Fernandez, R. O., Borges, A. P., Pérez-Lisboa, M.,
Peixoto, N., and Ramirez-Fernandez, F. J. (Politécnica da Universidade de
São Paulo. 2005). Laboratório Virtual Aplicado à Educação a Distância.
Sensores Integráveis e Microestruturas. IEEE/ACM Transactions on
Networking.
[Guimarães et al. 2003] Guimarães, E., Maffeis, A.and Pinto, R., Miglinski,
C., Cardozo, E., Bergerman, M., and Magalhães, M. (2003). REAL: A
Virtual Laboratory for Mobile Robots Experiments. In Proceedings of
the IEEE.
[Hua and Ganz 2003] Hua, J. and Ganz, A. (Boulder, USA, 2003). Web en-
abled laboratory (R-LAB) framework. ASEE/IEEE Frontiers in Education
Conference.
[Leymann et al. 2002] Leymann, F., Roller, D., and Schmidt, M. T. (2002).
“Web services and business process management.”. IBM Systems Journal,
41(2):198–211.
[MIT 2006] MIT (2006). Projeto iCampus/iLAB. URL at http://
icampus.mit.edu/ilabs.
[Neto 2006] Neto, A. C. (2006). “Web Services em Java com Axis - Teoria e
Prática”. URL at http://www.guj.com.br/java.tutorial.
artigo.159.1.guj.
[Papazoglou 2003] Papazoglou, M. P. (2003). Service-oriented computing:
Concepts, characteristics and directions.
[Roberts 1999] Roberts, L. (1999). “Quality IP”. URL at http://www.
data.com/issue/990421/roberts.html.
[Sicker et al. 2005] Sicker, D. C., Lookabaugh, T., Santos, J., and Barnes,
F. (Indianapolis, USA, 2005). Assessing the effectiveness of remote
netoworking laboratories. ASEE/IEEE Frontiers in Education Conference.
[Sivakumar et al. 2005] Sivakumar, S. C., Robertson, W., Artimy, M., and
Aslam, N. (2005). A web-based remote interative laboratory for internet-
working education. IEEE Transactions on Education., Vol.48.
[Souza 2005] Souza, V. A. S. M. d. (2005). Uma arquitetura orientada a
serviços para desenvolvimento, gerenciamento e instalação de serviços
de rede. Master’s thesis, Instituto de Computação Universidade Estadual
de Campinas, SP.
Lucio Agostinho da Rocha Mestrando em Ciência da Computação
pela Universidade Federal de Uberlândia.
Adriano Fiad Farias Mestrando em Ciência da Computação pela
Universidade Federal de Uberlândia. Atualmente é professor do
Centro Federal de Educação Tecnológica de Petrolina, Pernambuco.
Luı́s Fernando Faina Doutor em Engenharia Elétrica pela Universi-
dade Estadual de Campinas (2000). Atualmente é professor Adjunto
da Universidade Federal de Uberlândia.
Eliane G. Guimarães Doutora em Engenharia Elétrica e de
Computação pela Universidade Estadual de Campinas (2004). At-
ualmente é Tecnologista Senior III do Centro de Pesquisas Renato
Archer.
Paulo R.S.L. Coelho Doutorando em Engenharia Elétrica pela
Universidade Estadual de Campinas.
Eleri Cardozo Doutor em Electrical and Computer Engineering -
Carnegie Mellon University (1987). Atualmente é professor titular
da Universidade Estadual de Campinas.