Embed Size (px)
Citation preview
Capítulo
1
Desenvolvimento de Sistemas Sensíveis ao
Contexto usando Web Services
Carlos E. Cirilo, Alexandre Bellini, Antonio F. do Prado, e Luciana A. M. Zaina
Abstract
In this times when people need to process more information to perform their tasks in less
time, new challenges for software engineers arise: how to reduce the need for users’
explicit interactions to obtain what they need? How to provide users only the relevant
information at a given time? How to adapt applications to different devices that support
users in carrying out their tasks? These and other questions have led to the development of
Context-Sensitive Systems (CSS), which are capable of adapting their operations in order
to improve usability and efficiency by using information taken out of the environment in
which they operate. However, CSS development is not a trivial task, mainly due to the need
to manipulate heterogeneous sources for acquisition of contextual information for use in
application. In this sense, this mini-course introduces the concepts related to CSS
development from a service-oriented perspective.
Resumo
Em uma época em que as pessoas necessitam processar mais informação para
desempenhar suas tarefas em menos tempo, novos desafios surgem para os engenheiros de
software: como reduzir a necessidade de interações explícitas dos usuários com a
aplicação a fim de obterem o que precisam? Como fornecer aos usuários somente as
informações que lhes são relevantes em um dado momento? Como adaptar as aplicações
aos diferentes dispositivos que apoiam os usuários na execução de suas tarefas? Essas e
outras questões têm levado ao desenvolvimento dos Sistemas Sensíveis ao Contexto (SSCs),
os quais são capazes de adaptar suas operações com o intuito de melhorar a usabilidade e
eficiência usando informações extraídas do ambiente em que operam. O desenvolvimento
de SSCs, no entanto, não é uma tarefa trivial, principalmente devido à necessidade de
manipular fontes heterogêneas para aquisição das informações contextuais para uso na
aplicação. Neste sentido, este minicurso apresenta os conceitos relacionados ao
desenvolvimento de SSCs a partir de uma perspectiva orientada a serviços.
1.1. Introdução
Desde o surgimento da ciência da computação, talvez uma das maiores mudanças que se
pôde testemunhar tenha sido o grau com que os computadores tornaram-se essenciais na
vida das pessoas (Lucrédio, 2009). Ao longo dos anos, os computadores passaram a estar
cada vez mais presentes nas tarefas cotidianas e mais próximos dos usuários. Seja em casa
ou no trabalho, para acessar os e-mails, editar textos, comunicar-se com outras pessoas, ver
as notícias do dia ou acessar a conta bancária, é difícil imaginar o mundo sem a presença
dessas incríveis máquinas.
Nos primórdios da computação, em torno da década de 1940, surgiram os
computadores de grande porte, denominados mainframes. Esses computadores geralmente
ocupavam um grande espaço e possuíam acesso restrito. Com o surgimento dos primeiros
computadores pessoais (PCs), entre as décadas de 1970 e 1980, houve uma popularização
dos computadores. Os PCs possibilitaram aos usuários a realização de tarefas diversas, tais
como processamento de texto, navegação na Internet, jogos e programação. O advento da
Internet e dos ambientes de computação distribuída permitiu a interconexão dos
computares para compartilhamento de informações, o que ampliou os serviços oferecidos e
aumentou a complexidade das aplicações desenvolvidas.
Nos anos recentes, com a evolução das tecnologias de comunicação sem fio, dos
microprocessadores e dos dispositivos eletrônicos digitais de uso pessoal, tornou-se possível
fornecer aos usuários, de qualquer lugar, a qualquer hora e usando qualquer tipo de
dispositivo, o fácil acesso a serviços e aplicações. Essas capacidades levaram ao surgimento
do conceito de ubiquidade na computação (Araújo, 2003). A Computação Ubíqua (Weiser,
1999), a qual tem sido considerada a nova era da computação, compreende um universo
formado por uma grande variedade de dispositivos computacionais que permeiam cada vez
mais o cotidiano das pessoas, como telefones celulares, PDAs (Personal Digital Assistants),
smartphones, dentre outros. Um dos propósitos desse novo paradigma computacional é
ampliar as atividades humanas com novos serviços que possam se adaptar às circunstâncias
em que serão utilizados (Coutaz et al., 2005).
Neste cenário, uma classe de sistemas, chamados de Sistemas Sensíveis ao
Contexto (SSCs), utilizam de informações extraídas do contexto da interação para fornecer
serviços adaptados e relevantes na realização das tarefas do usuário (Baldauf; Dustdar;
Rosenberg, 2007). O desenvolvimento de software neste cenário apresenta uma série de
desafios, dentre os quais a necessidade de suporte a diferentes dispositivos em contextos
distintos (Viana e Andrade, 2008).
Neste sentido, um dos aspectos críticos para o desenvolvimento de SSCs que
operam em ambientes ubíquos é a premissa de que os mesmos devem ser capazes de
executar e se adaptar à heterogeneidade dos dispositivos computacionais do usuário e do
ambiente no qual ele está imerso. Desenvolver um SSC, no entanto, pode ser uma tarefa
complexa e cara, principalmente devido à necessidade de manipular diferentes fontes para
aquisição das informações contextuais para uso nas aplicações (Santos, 2008; Vieira;
Tedesco; Salgado, 2009).
Além disso, devido à infinidade de adaptações possíveis e muitas vezes necessárias,
implementar todas elas pode demandar muito tempo de desenvolvimento. Por outro lado,
utilizar as funcionalidades de adaptação na forma de serviços surge com uma alternativa
que pode facilitar e agilizar o processo de desenvolvimento de aplicações adaptativas. Os
serviços também favorecem o baixo acoplamento e interoperabilidade entre diferentes
plataformas. Embora as Arquiteturas Orientadas a Serviço (SOA) (Erl, 2007) tenham suas
origens há mais de uma década, voltaram a ganhar destaque recentemente como um padrão
e uma tecnologia capaz de melhorar consideravelmente a interoperabilidade entre
aplicações de software. E foi neste escopo que os Web Services assumiram uma posição
central como a tecnologia que melhor viabiliza o desenvolvimento de SOA.
Dessa forma, o objetivo deste minicurso é apresentar aos participantes os
conceitos relacionados ao desenvolvimento de Sistemas Sensíveis ao Contexto e SOA, de
forma que, ao término do minicurso, os participantes sejam capazes de identificar e
planejar como a análise e o tratamento do contexto podem ser aplicados para desenvolver
soluções de software que se adaptam a múltiplos contextos com o uso de serviços.
1.2. Sistemas Sensíveis ao Contexto
A sensibilidade ao contexto está relacionada com a adaptação da aplicação de acordo com
sua localização de uso, as pessoas ou objetos circundantes, bem como as mudanças que
ocorrem nesses objetos ao longo do tempo (Coutaz et al., 2005; Dey, 2001; Schilit e
Theimer, 1994). Um SSC é capaz de adaptar suas operações sem a necessidade de
intervenção explícita do usuário, fornecendo informações e/ou serviços que são relevantes
para o usuário realizar suas tarefas considerando as informações extraídas do contexto da
interação (Baldauf; Dustdar; Rosenberg, 2007; Dey, 2001).
O contexto desempenha um papel primordial para permitir que os sistemas refinem a
informação disponível em informação relevante, escolham ações apropriadas a partir de uma
lista de possibilidades, ou determinem o melhor método para a disponibilização da informação.
O contexto guia as variações do comportamento do SSC, enriquecendo a interação do usuário
tanto por influenciar recomendações ou por executar adaptações de qualquer tipo (Santos,
2008). Por exemplo, entre as ações realizadas por um SSC pode-se mencionar a adaptação de
conteúdo, na qual um conteúdo original é convertido em uma série de novos formatos
compatíveis com o contexto de entrega. Essa adaptação pode ser, por exemplo, uma
transformação, onde a linguagem de marcação de uma interface Web é modificada para se
ajustar mais apropriadamente ao perfil do dispositivo, e/ou uma transcodificação, pela qual
imagens são convertidas ou redimensionadas (Forte; de Souza; Prado, 2008).
Desenvolver um SSC, contudo, é uma tarefa complexa e cara. Ao projetar um
sistema sensível ao contexto deve-se lidar com questões associadas com qual tipo de
informação pode ser considerado como contexto, como representar essa informação, como
adquirir e processar essa informação uma vez que pode ser oriunda de fontes heterogêneas,
e como integrar o uso do contexto no sistema. Além disso, por ser uma área de estudo
recente dentro da Ciência da Computação e ainda não haver um consenso dos conceitos
associados ao contexto (Dourish, 2001; Santos, 2008), existe uma dificuldade entre os
desenvolvedores para distinguir os aspectos relacionados aos requisitos de negócio da
aplicação daqueles referentes à manipulação do contexto, o que indica a ausência de
suporte de Engenharia de Software (e.g. processos, métodos, ferramentas) que apoie os
projetistas desse tipo de sistema no desenvolvimento de suas aplicações (Santos, 2008).
1.2.1. Contexto Computacional
Muitas definições para contexto já foram propostas para torná-lo um conceito operacional
em termos computacionais. Bazire e Brézillon (2005) catalogaram mais de 150 definições
para o termo contexto e concluíram que sua definição varia fortemente à medida que se
transita entre diferentes domínios. Apesar da variedade de definições, os pesquisadores, em
geral, concordam que: o contexto está sempre associado com alguma entidade (e.g. tarefas,
agente, interação); o contexto é um conjunto de itens associados a uma entidade (e.g.
conceitos, regras e proposições); e um item é considerado como parte de um contexto se for
útil para apoiar na realização da tarefa a ser desempenhada (Santos, 2008).
Segundo o Dicionário Merriam-Webster1, contexto é definido como “condições
inter-relacionadas nas quais alguma coisa existe ou ocorre”. O contexto é o que fundamenta
a habilidade de identificar o que é e o que não é relevante em um dado momento (Santos,
2008). Uma definição operacional para contexto amplamente referenciada declara que o
contexto é qualquer informação que pode ser usada para caracterizar a situação de uma
entidade. Essa entidade pode ser uma pessoa, um lugar, ou um objeto que é considerado
relevante para a interação do usuário com a aplicação, inclusive eles próprios (Dey, 2001).
De maneira similar, Brézillon (1999) considera o contexto como um conjunto de
condições relevantes e influências que possibilitam a compreensão de uma situação, onde
tais condições e influências atuam diretamente sobre entidades do domínio considerado.
Além disso, Brézillon e Pomerol (1999) introduzem a noção de foco, declarando que o
contexto não é um conceito isolado, mas que está sempre relacionado a um foco que
determina o que deve ser considerado como relevante. Esse foco representa uma tarefa a
ser executada ou uma etapa na resolução de um problema ou tomada de decisão.
Uma definição mais recente, derivada das definições anteriores, propõe que para
um melhor entendimento do que é contexto e como utilizá-lo nas aplicações deve-se
estabelecer a distinção entre contexto e elemento contextual. Essa definição declara que um
elemento contextual (EC) é qualquer dado ou informação que permite caracterizar uma
entidade em um domínio, e que o contexto de uma interação entre um agente (humano ou
software) e uma aplicação, com foco em alguma tarefa, é o conjunto de ECs instanciados
que são necessários para apoiar a tarefa a ser executada (Vieira; Tedesco; Salgado, 2009).
Essa definição torna mais fácil para um desenvolvedor enumerar o contexto de um dado
cenário de aplicação. Neste caso, se determinada informação que caracteriza uma entidade
em uma interação for útil para apoiar a tarefa a ser executada (foco), então essa informação
é um elemento contextual, que por sua vez compõe o contexto daquela interação.
Por exemplo, suponha uma aplicação Web que adapta sua interface gráfica conforme
o perfil do dispositivo de acesso, fornecendo interfaces que não se distorcem quando
visualizadas em diferentes dispositivos. A tarefa a ser desempenhada, neste caso, é adaptar a
interface da aplicação. Para este foco, se for considerada a resolução de tela do dispositivo,
percebe-se que tal informação é útil, pois fornece subsídios para redimensionar o conteúdo da
página Web de forma que se encaixe na tela do dispositivo do usuário. Logo, de acordo com a
definição precedente, esse elemento contextual faz parte do contexto da interação. Por outro
lado, se for considerada a temperatura do ambiente em que o usuário encontra-se atualmente,
descobre-se que tal informação, apesar de fazer parte da situação, não é relevante para a tarefa
em questão e, portanto, não compõe o contexto daquela interação.
1.2.2. Arquitetura de um SSC
Sistemas sensíveis ao contexto podem ser implementados de diversas maneiras. A
arquitetura do sistema depende de requisitos e condições especiais, dentre os quais o
método de aquisição dos elementos contextuais exerce bastante influência na definição do
estilo arquitetural do sistema (Baldauf; Dustdar; Rosenberg, 2007).
1 http://www.merriam-webster.com/.
Chen (2004) apresenta três diferentes abordagens para aquisição dos elementos
contextuais:
Acesso direto às fontes de contexto2: nesta abordagem, a aplicação cliente obtém
os elementos contextuais diretamente das fontes de contexto disponíveis. Não há
uma camada adicional para tratamento do contexto, de forma que o código para
aquisição e processamento dos elementos contextuais fique atrelado ao código das
regras de negócio da aplicação.
Infraestrutura intermediária: esta abordagem incorpora uma arquitetura
intermediária aos SSCs que encapsula a manipulação do contexto, ocultando os
detalhes de baixo nível de obtenção dos elementos contextuais de suas fontes de
origem. Esta abordagem favorece a extensibilidade, uma vez que o código da
aplicação cliente não necessita ser modificado caso haja alterações na forma de
aquisição dos elementos contextuais.
Servidor de contexto: esta abordagem estende a arquitetura baseada em infraestrutura
intermediária, introduzindo um componente remoto de gerenciamento de acesso às
fontes de contexto. A obtenção dos elementos contextuais é realizada em um servidor,
chamado servidor de contexto, para facilitar múltiplos acessos simultâneos. Esta
abordagem alivia as aplicações clientes das operações intensivas para obtenção dos
elementos contextuais de suas fontes de origem, o que é um aspecto importante
considerando SSCs que executam em dispositivos com recursos limitados.
Dentre as abordagens apresentadas, o emprego da infraestrutura intermediária para
gerenciar o contexto introduz uma arquitetura em camadas ao SSC, o que possibilita
projetar uma camada específica para gerenciar o contexto. Ao contrário de uma abordagem
de acesso direto às fontes de contexto, a infraestrutura intermediária, além de permitir uma
maior extensibilidade ao sistema, possibilita o reúso da camada de gerenciamento de
contexto em diferentes aplicações (Baldauf; Dustdar; Rosenberg, 2007).
Fontes de Contexto
Consumidores de
Contexto
Aquisição
Processamento
Disseminação
Ge
ren
cia
do
r
de
Co
nte
xto
Figura 1.1. Modelo de arquitetura em camadas para um SSC (adaptado Santos, 2008)
A Figura 1.1 apresenta um modelo conceitual de arquitetura em camadas para um
SSC. A camada de gerenciamento de contexto posiciona-se entre as fontes e os
consumidores de contexto, de modo a fornecer os elementos contextuais adquiridos a partir
dessas fontes aos consumidores interessados. As fontes de contexto são elementos de
2 Na literatura, as fontes de contexto, sejam elas um hardware (e.g., um termômetro, um sensor de
movimento, uma câmera de vídeo) ou uma entidade lógica (e.g., uma base de dados, uma agenda
eletrônica) são também referenciadas como “sensores”. Uma vez que a palavra “sensor” usualmente
remete a uma entidade física, neste texto é utilizado o termo “fonte de contexto” para evitar
ambiguidades.
software (e.g. perfis armazenados, bases de dados externas, drivers de câmeras sensores)
que fornecem informações atualizadas sobre as entidades consideradas no domínio do SSC.
Os consumidores de contexto, por sua vez, são elementos de software que usam os
elementos contextuais relevantes para desempenhar algum comportamento sensível ao
contexto, como por exemplo, adaptação de conteúdo. Tanto as fontes quanto os
consumidores de contexto estão ligados ao gerenciador de contexto através de interfaces
(Santos, 2008).
A maioria das arquiteturas em camadas de SSCs existentes diferem entre si em
aspectos relacionados às funcionalidades fornecidas, à localização e nomeação das
camadas, dentre outras questões arquiteturais. Apesar disso, é possível identificar aspectos
comuns na arquitetura dos SSCs modernos (Baldauf; Dustdar; Rosenberg, 2007).
Conforme ilustrado na Figura 1, a camada de gerenciamento de pode englobar módulos
com funções para adquirir os elementos contextuais de suas fontes de contexto, processá-
los e disseminá-los aos consumidores de contexto. As funcionalidades presentes em cada
um desses módulos podem ser descritas como segue (Santos, 2008):
Aquisição: gerencia as fontes de contexto e recupera os elementos contextuais por
meio do uso de drivers e Application Programming Interfaces (APIs) que permitem
acesso às funcionalidades internas de cada fonte de contexto.
Processamento: raciocina e interpreta os elementos contextuais e transforma-os
em um formato ou em um nível de abstração adequado para que sejam utilizados
pelos consumidores de contexto. Além disso, este módulo realiza a combinação ou
agregação de diferentes elementos contextuais provenientes de múltiplas fontes de
contexto. Conflitos entre valores divergentes para um mesmo elemento contextual
obtidos de fontes distintas também são solucionados neste módulo.
Disseminação: organiza os elementos contextuais e os disponibiliza aos
consumidores de contexto através de uma interface pública. O consumidor pode
invocar o gerenciador de contexto para: obter o valor atual de um elemento contextual
específico, obter todos os elementos contextuais relacionados a uma determinada
entidade, ou verificar quais elementos contextuais são relevantes para um dado foco.
Nota-se, portanto, que a camada de gerenciamento de contexto é uma entidade que
envolve a definição de soluções que permitem separar as operações relacionadas à
manipulação de contexto das funcionalidades de negócio da aplicação (Vieira; Tedesco;
Salgado, 2009).
1.2.3. Exemplos de SSCs
“Um geólogo do Instituto Americano de Pesquisas em Geologia foi enviado a um local
remoto no oeste dos EUA para examinar os efeitos de um terremoto recente. Com auxílio
de um PC, e um software denominado MANNA3, que suporta as atividades do geólogo em
diferentes dispositivos, o geólogo faz o download de mapas e relatórios a respeito da
região afetada de modo a preparar-se para a visita. O PC impõe poucas restrições de
interface gráfica para visualização dos mapas, no entanto, é um equipamento inadequado
3 Aplicação multimídia que pode executar em diferentes plataformas e ser utilizada de forma colaborativa
pela Internet, permitindo que geologias, engenheiros e militares criem mapas anotados de áreas
geográficas utilizando texto, áudio e vídeo.
para ser carregado durante a viagem. O geólogo, então, transfere os documentos para um
laptotp e pega um avião até o local onde ocorreu o terremoto.
No avião não há conexões de rede, de forma que o laptop desabilita todos os
comandos que dependem de conexões. Quando o geólogo examina os vídeos do local, a
interface do usuário altera-se automaticamente para monitor preto e branco, e reduz a
taxa de quadros por segundo, para ajudar a conservar a bateria do dispositivo. Além
disso, componentes da interface gráfica são ajustados para suportar a interação através
de toque mais apropriada no laptop. Ao chegar ao aeroporto, o geólogo aluga um carro e
dirige-se ao local. Ele recebe uma mensagem através do sistema MANNA em seu celular,
alertando-o para examinar um local em particular. Como o celular oferece um espaço de
tela extremamente limitado, o mapa da região não é mostrado. Em vez disso, o celular
mostra a localização geográfica, orientações de direção para chegar ao local, e a posição
atual do geólogo em coordenadas latitude e longitude. Um recurso que permite ao geólogo
responder a mensagem também é oferecido pelo software.
Chegando ao local, o geólogo usa o seu palmtop para tomar notas sobre a região.
Como o palmtop conta com uma caneta de toque para interação, cliques duplos e cliques
com botão direito são desabilitados. Além disso, já que o tamanho de tela do laptop é
reduzido, um leiaute mais conservador da interface é utilizado pelo MANNA. Ao completar a
investigação, o geólogo prepara uma apresentação em dois formatos. Primeiro, uma
apresentação do seu percurso pelo local, com anotações, é feita para o HUD (heads-up
display). Como o HUD possui capacidades limitadas para entradas de texto, a aplicação
MANNA fornece interação baseada em voz. Outra apresentação, mais convencional, é
preparada para ser visualizada em monitores de alta resolução. Uma vez que esta se trata de
uma apresentação final, e os usuários não irão mais adicionar informações, mecanismos de
interação são removidos” (adaptado de Eisenstein; Vanderdonckt; Puerta, 2000).
O cenário narrado nos parágrafos anteriores e muitos outros podem ser concebidos
quando se pensa em sistemas que são cientes do contexto atual e podem realizar ações com
base nessas informações. Algumas questões associadas ao comportamento dos SSCs na
Computação Ubíqua, que podem ser observadas nesse cenário, são (Araújo, 2003):
A informação é acessada através de múltiplos dispositivos heterogêneos;
A aplicação segue o usuário em movimento;
Os dispositivos interagem entre si;
Algumas tarefas são executadas de forma autônoma;
Dispositivos diferentes apresentam visões diferentes da mesma aplicação;
O ambiente troca informações com os dispositivos e vice-versa;
A aplicação responde a mudanças no ambiente.
A seguir são apresentados alguns exemplos de SSCs que possuem tais
características.
Os guias turísticos móveis (Grün et al., 2008) têm por objetivo auxiliar o turista
durante suas viagens, fornecendo informações e serviços baseados na localização e
preferências do usuário. Os serviços fornecidos podem ser categorizados por diferentes
fatores, tais como: acomodação, emergência, entretenimento, gastronomia, navegação e
orientação, páginas amarelas, notícias, compras, esportes, atrações turísticas, transporte e
condições climáticas. Esses sistemas podem apresentar um mapa da localização corrente do
usuário contendo informações úteis do local visitado (Figura 1.2).
Figura 1.2. Ilustração de um guia turístico móvel (Fernandes, 2009).
O Enhanced 911 ou E-911 (E9-1-1 Institute, 2010) é um sistema baseado em
telecomunicações norte-americano que associa automaticamente o endereço físico do
usuário ao número telefônico de uma chamada de emergência, direcionando-a para uma
central de atendimento (Public Safety Answering Point - PSAP) mais apropriada àquele
endereço. As informações sobre o chamador e seu endereço são mostradas ao atendente do
PSAP imediatamente após a chegada da chamada, o que possibilita aos atendentes obterem
a localização da ocorrência sem a necessidade do usuário ter que informá-la. Esse sistema
apenas funciona na América do Norte quando o número de emergência 911 é discado.
O Call Forwarding (Want et al., 1992) é outro exemplo de SSC, o qual redireciona
as chamadas telefônicas destinadas a um usuário para um telefone próximo à localização
atual do usuário. Outro SSC, denominado Teleporting (Bennett; Richardson; Harter,
1994), mapeia dinamicamente a interface de uma aplicação mostrada no dispositivo do
usuário para os recursos disponíveis de outros dispositivos computacionais circundantes.
O Shopping Assistant (Asthana; Cravatts; Krzyzanowski, 1994) guia os usuários
durante suas compras em determinada loja, fornecendo detalhes dos itens, auxiliando na
localização dos mesmos dentro da loja, realizando análises comparativas de preços, e assim
por diante. O Conference Assistant (Dey et al., 1999) trata-se de outro SSC que usa uma
variedade de informações contextuais para auxiliar os participantes de uma conferência.
Esse sistema examina a agenda da conferência, os tópicos das apresentações, a localização
dos participantes e seus interesses de pesquisa para sugerir as apresentações mais
apropriadas. Assim que um participante entra em uma sala de apresentação, o sistema
automaticamente mostra o nome do palestrante, o título da apresentação, e outras
informações pertinentes.
Outros exemplos de sistemas sensíveis ao contexto podem ser encontrados no
trabalho de Chen e Kotz (2000).
1.3. Arquitetura Orientada a Serviços
O desenvolvimento de aplicações para diferentes domínios tem demandado a adoção de
tecnologias que agilizem as tarefas de desenvolvimento, tornando o desenvolvimento mais
eficiente e alinhado aos processos de negócio das organizações. A diversidade de
organizações, a variedade de serviços ofertados e a popularização da Internet levaram à
necessidade de oferecer serviços de forma mais flexível, padronizada e extensível, com a
finalidade de simplificar a relação entre clientes e fornecedores. Para as corporações que
trabalham com grandes sistemas distribuídos, a flexibilização da Tecnologia da Informação
(TI) é de extrema importância. A interoperabilidade dos sistemas corporativos pode ser
simplificada com a utilização da Arquitetura Orientada a Serviços (SOA).
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 considerados atualmente os mais promissores na área de computação distribuída.
Esse paradigma prega a interoperabilidade e o fraco acoplamento entre elementos
básicos 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 simples método ou um grande processo envolvendo múltiplos
colaboradores (Papazolou, Georgakopoulos, 2003).
SOA representa a mais recente confluência de modelos arquiteturais. Nos últimos
anos, SOA tem sido pauta de inúmeros debates e a opção preferida da indústria do setor de
TI. Desenvolver aplicações interoperáveis é uma necessidade de muitas empresas, devido
ao crescimento e expansão de seus serviços em diversos mercados de atuação. A riqueza
desse modelo manifesta-se pela noção de serviço, que transforma as referências da
modelagem do software, enfatizando aspectos mais próximos da perspectiva de valores de
negócios.
Os serviços web é uma tecnologia projetada para suportar interações máquina-
máquina interoperáveis sobre uma rede. O serviço web possui uma interface descrita em
um formato passível de processamento pela máquina, conhecido como Web Service
Description Language (WSDL). Outros sistemas interagem com o serviço web da
maneira definida na sua interface usando mensagens do Simple Object Access Protocol
(SOAP), tipicamente transportadas usando o HiperText Transfer Protocol (HTTP ) com
serialização da Extensible Markup Language (XML) e em conjunto com outros padrões
relacionados à web (W3C, 2004a).
1.3.1. SOA: Definição
Primeiramente, SOA é um conceito. Existem diversas definições para SOA na literatura,
mas é importante deixar claro algumas definições de SOA que não procedem. SOA não é
uma tecnologia, não pode ser reduzido a produtos de software, não é uma solução, não
atende todos os desafios tecnológicos aos quais estão submetidos os negócios de hoje, mas
sim da forma que a aplicação deve ser construída. A computação orientada a serviço é o
paradigma de computação que utiliza serviços como elementos fundamentais para o
desenvolvimento de aplicações (Papazoglou e Georgakopoulos, 2003).
Service Oriented Computing é um conceito bastante amplo que representa uma nova
geração de plataforma de computação distribuída. Englobam vários elementos como
princípios de design, padrões de projeto, linguagens de programação, hardware, frameworks,
processos e estratégias organizacionais. SOA é, basicamente, um modelo de arquitetura de
software na qual toda funcionalidade de negócio é construída com base em funções e
processos individualizados, denominados serviços. SOA define que os serviços sejam
desenvolvidos, implantados e integrados independentemente da aplicação e da plataforma
computacional na qual os serviços serão executados. O serviço deve funcionar de forma
independente do estado de outros serviços, além de possuir uma interface bem definida (Erl,
2007).
SOA tem o propósito de tratar os requisitos de baixo acoplamento,
desenvolvimento baseado em padrões, computação distribuída independente de protocolo,
mapeamento dos sistemas de informação da organização para todos os seus fluxos de
processos de negócios, integração de aplicações, gerência de transações, políticas de
segurança e coexistência de sistemas em múltiplas plataformas e também sistemas legados
(Papazoglou, Heuvel, Willem-jan, 2007). Apesar da abordagem orientada a serviços
requerer mais disciplina e planejamento, o retorno de investimento é elevado (Marks e Bell,
2006).
SOA se relaciona também com determinadas políticas e conjuntos de práticas que
pretendem criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os
serviços disponibilizados. SOA permite que às organizações realizarem seus negócios e
obtenham vantagens tecnológicas por meio da combinação de inovação de processos,
estratégia de tecnologia e governança eficaz, as quais giram em torno da definição e
reutilização de serviços. O modelo de arquitetura de software beneficia a eficiência,
agilidade e produtividade no desenvolvimento de aplicações e esta alinhado com os
objetivos de Service Oriented Computing.
A adoção da arquitetura SOA provê vantagens no processo de desenvolvimento de
software (Erl, 2005). Entre elas destacam-se: Fraco acoplamento, Interoperabilidade,
Composição, Reusabilidade, Alta granularidade e Ubiquidade que devem prover as
seguintes funcionalidades:
Fraco acoplamento: é um conceito fundamental de SOA e dos grandes sistemas
distribuídos. Consiste em garantir que cada serviço seja o mais independente
possível de outros. Desta forma, ao se modificar um determinado serviço, os outros
não deverão ser afetados;
Interoperabilidade: Os serviços idealmente dever ser implementados com uso de
tecnologias padronizadas e disponíveis a um grande número de plataformas de
software. A utilização de protocolos e aplicação independente de plataforma resulta
em Interoperabilidade entre os serviços. Protocolos proprietários e fracamente
padronizados apresentam problemas de interoperabilidade entre softwares
desenvolvidos por diferentes fabricantes;
Composição: é a capacidade dos serviços possibilitar a execução de
funcionalidades complexas e completas dentro de um determinado negócio. Os
serviços podem ser compostos para formar novos serviços com um nível maior de
abstração e provendo funcionalidades agregadas.
Reusabilidade: é um elemento fortemente adotado na arquitetura orientada a
serviços. Por serem módulos independentes de código e fracamente acoplados à
aplicação os serviços podem ser facilmente reutilizados, resultando em um alto
nível de produtividade no desenvolvimento de software. O reúso de código gera
redução no tempo de desenvolvimento de aplicações, bem como redução nos
custos.
Alto Grau de Granularidade: o encapsulamento de funcionalidades no nível de
serviço evoca um Alto Grau de Granularidade nos componentes básicos da
arquitetura. Um objeto individual apresenta operações muito finas para prover
funcionalidades significativas no nível corporativo. Para o desenvolvimento de
aplicações complexas e extensas a alta granularidade traz vantagens na medida em
que detalhes de implementação são deixados à equipe de desenvolvimento
responsável por aquele serviço.
Ubiquidade: os serviços devem ser acessíveis a partir de qualquer lugar e a
qualquer momento facilitando a composição de serviços entre empresas.
1.3.2. SOA e os Web Services
A arquitetura orientada a serviços revigora a possibilidade para se incorporar avanços e
posicionar a tecnologia da informação no patamar de sofisticação condizente com o mundo
que cerca. Os sistemas baseados em serviços e tecnologia Internet, permitem a criação de
modelos simples e de alta escala, permitindo novos patamares para os ambientes
computacionais. Os Web Services surgem como uma evolução dos modelos de computação
distribuída. A adesão da Internet no mercado corporativo como fator de negocio surgiu à
necessidade de integrar aplicações além das redes locais e, por consequência, em ambientes
heterogêneos. A tecnologia Web Service é empregada nesse contexto com o objetivo de
integrar os sistemas de informação (W3C, 2004a).
Web Services são uma excelente ideia que temos hoje de implementar SOA (Erl,
2005). Existem ideias de que Web Services e SOA são sinônimos e que é impossível
desenvolver aplicações com arquitetura orientada a serviços sem o uso de Web Services.
Isso não é verdade, pois é possível implementar aplicações SOA usando tecnologias como
Java RMI, CORBA ou DCOM (Erl, 2007), mas essas tecnologias apresentam algumas
dificuldades. A Java RMI é muito ligada à linguagem Java e dificilmente se comunica com
outras linguagens de programação. A tecnologia CORBA tem o problema de possuir
protocolos complexos. A DCOM é uma tecnologia dependente da plataforma e totalmente
proprietária. Por esses motivos Web Services se tornou popular, pois tenta resolver esses
problemas criando protocolos de comunicação abertos que possam ser facilmente
integrados a diferentes plataformas e possui dois requisitos fundamentais: comunica-se via
protocolos Internet e o envio e recebimento de dados em formatados de documentos XML.
O conceito de Web Services teve seu início em meados de 2000 com a introdução da
primeira versão do protocolo Simple Object Access Protocol (SOAP), Web Services
Description Language (WSDL) versão 1.1 e de uma versão inicial do servidor Universal
Description, Discovery and Integration (UDDI). O Web Service é definido pela publicação de
um documento WSDL para descrever o serviço, e o cliente acessa esse documento publicado
através do UDDI ou no provedor de Web Services. Após o cliente receber as informações do
serviço é desenvolvido o software que realizará a troca de informações com o envio de
mensagens utilizando o protocolo SOAP através da chamada dos Web Services (W3C,
2004a).
A plataforma Web Services de segunda geração (extensões WS-*) proporcionar
eliminar algumas brechas relacionadas a serviços de qualidade na plataforma de primeira
geração. As áreas de segurança no nível de mensagens, transações de serviços cruzados e
troca de mensagens confiável são fornecidas pela plataforma de segunda geração.
Consistindo de inúmeras especificações que aprimoram o framework fundamental da troca
de mensagens, esse conjunto de tecnologias Web Services fornece um rico conjunto de
recursos muito mais complexo, tanto em termos de tecnologia quanto de design (Erl, 2007).
A identificação desses serviços, no entanto, não é uma tarefa simples e imediata. Em
geral são utilizadas duas abordagens para resolver esse problema: top-down e bottom-up. A
abordagem top-down permite que um processo ou sistema seja gradativamente decomposto
em partes menores até atingir um nível de serviços básicos. Por outro lado, a abordagem
bottom-up parte dos serviços já identificados ou oferecidos pelos sistemas da organização,
compondo-os gradativamente em serviços mais complexos e generalizados (Perepletchikov et
al., 2005).
1.3.3. Classificação de Serviços
Ao modelar serviços, fica claro que eles podem ser classificados dependendo do modelo de
lógica que encapsulam, do potencial de reúso que esta lógica possui e de como ela se
relaciona com os domínios existentes dentro do ambiente empresarial (Erl, 2007). Desta
forma, existem três classificações comuns de serviços, cujas camadas lógicas são ilustras na
Figura 1.3, os quais definem os modelos de serviços primários:
Serviços de Utilidade;
Serviços de Entidade; e
Serviços de Tarefa.
Os Serviços de Utilidade, também conhecido como serviços de aplicação, serviços
de infraestrutura, ou serviços de tecnologia, constituem nos serviços que contém lógica
independente de negócio, ou seja, são responsáveis por realizar atividades que podem ser
aplicadas a diversos tipos de negócio. Desta forma, possuem um potencial de reúso
bastante elevado. Algumas funcionalidades que estes serviços podem contemplar seriam
tratamento de exceções, ou autenticação de usuários.
Os Serviços de Entidade são os serviços relacionados às entidades envolvidas no
negócio, como, por exemplo, produtos, clientes, funcionários, fornecedores, entre outros.
Estes serviços também possuem um alto grau de reuso, porém menor do que os Serviços de
Utilidade, devido à sua relação mais próxima com o negócio.
Os Serviços de Tarefas tratam-se de serviços responsáveis pelos processos
específicos de cada negócio, como, por exemplo, uma análise das vendas. Nestes serviços,
pode ser necessário obter informações das várias entidades do negócio, bem como realizar
tarefas atividades mais genéricas, de forma que serviços de Entidade e de Utilidade podem
ser orquestrados para auxiliar na execução da Tarefa.
Figura 1.3. Camada de abstração dos Serviços (adaptada de Erl, 2007)
1.3.4. Principais Padrões utilizados pelos Web Services
Para que se possa construir uma arquitetura orientada a serviços são utilizados as
tecnologias envolvidas, baseados em eXtensible Markup Language (XML), na provisão da
arquitetura SOA no contexto dos Web Services.
O XML, acrônimo de Extensible Markup Language, trata-se de uma
metalinguagem, ou seja, uma linguagem utilizada para descrever outras linguagens (Daily,
2010). Tal linguagem descreve documentos XML, que são documentos em um formato de
texto simples e bastante flexível elaborado originalmente para atender aos desafios da
publicação eletrônica de larga escala (W3C, 2010). Estes documentos são constituídos de
tags, que por sua vez podem encapsular tags ou outros dados. A extensibilidade e a
natureza estruturada de XML permitem sua utilização na comunicação entre diferentes
sistemas, que de outra forma não poderiam se comunicar (Daily, 2010). Devido
principalmente a estas características, Web Services normalmente são implementados
utilizando XML como formato padrão de troca de dados. Para padronizar o formato das
mensagens XML, faz-uso de estruturas bem definidas chamadas Esquemas. O formato
mais comum de esquemas é o XSD, acrônimo de XML Schema Definition.
A Linguagem de Descrição dos Serviços Web aborda a necessidade de definir uma
gramática eXtensible Markup Language (XML) com o objetivo de descrever os Web
Services. A função do WSDL é fornecer uma documentação e detalhes técnicos dos Web
Services que além de descrever o serviço, especifica como acessá-lo e quais são as
operações ou métodos disponíveis para a chama e o desenvolvimento do serviço. A
implementação do serviço pode-se dar utilizando qualquer linguagem de programação e
plataforma. Pode-se utilizar ferramentas para geração de código que, a partir da
especificação da interface, geram os stubs e os skeletons do serviço, na linguagem de
programação desejada. Resumidamente, um documento WSDL usa os seguintes elementos
XML na definição do serviço:
Tipo (Type): contêiner para definições de tipos de dados. Usa algum sistema de
definição de tipos como por exemplo XML Schema Definition (XSD).
Operação (Operation): descrição abstrata de uma funcionalidade suportada pelo
serviço.
Associação (Binding): protocolo de comunicação concreto e especificação da
formatação dos dados para um tipo de porta específico.
Porta (Port): um único endpoint definido como a combinação de uma associação e
um endereço de rede.
Serviço (Service): uma coleção de portas agrupadas logicamente.
A linguagem WSDL (W3C, 2007a) define quatro tipos de interações entre o provedor
e o cliente do serviço, baseado na quantidade e direção das mensagens trocadas. É possível
que haja somente o recebimento de uma mensagem pelo provedor do serviço, caracterizando
uma interação em sentido único (one-way). Outra possibilidade é que exista o recebimento e o
envio de uma mensagem pelo provedor do serviço, caracterizando uma interação requisição-
resposta (request-response). Ainda, pode-se ter o envio e recebimento de uma mensagem
(solicit-response) ou apenas o envio de uma mensagem (notification) por parte do servidor.
O SOAP (W3C, 2007b) é um protocolo de comunicação no nível de aplicação que
define a formatação e codificação de mensagens XML a serem enviadas pela rede. O
protocolo define um mecanismo leve e simples para troca de informações estruturadas
entre pares em um ambiente descentralizado e distribuído (Walsh, 2002). É um protocolo
projetado para comunicação na Internet, podendo utilizar outros protocolos (e.g., HTTP ou
SMTP) para transporte de suas mensagens. O objetivo desse protocolo é prover um meio
de comunicação entre aplicações com diferentes tecnologias, executando em diferentes
sistemas operacionais e linguagens de programação. Ao utilizar protocolos padrões da
Internet ele não é bloqueado por firewalls nem por roteadores como outros protocolos de
aplicação (e.g., Internet Inter-ORB Protocol - IIOP).
A mensagem SOAP deve necessariamente conter um elemento envelope. Este por
sua vez possui um elemento cabeçalho (header) opcional e um elemento corpo (body)
mandatório. O elemento corpo representa os parâmetros de entrada e saída do serviço, ou
seja, a informação em si sendo transmitida. A mensagem ainda pode conter um elemento de
falha (fault) que provê informações sobre erros ocorridos durante o processamento da
mensagem.
O UDDI (OASIS, 2004) é um mecanismo que visa atender tanto ao cliente de Web
Service quanto ao provedor. A sua tarefa é fornecer ao provedor de Web Services os
protocolos necessários para que os Web Services sejam registrado, descobertos e
publicados na rede (Walsh, 2002; Newcomer, 2002). Funciona como uma agência de
registro de Web Services, similar às páginas amarelas de uma lista telefônica. Dado um
conjunto de parâmetros de especificação de um serviço (nome, qualidade, localização, entre
outros) a agência é responsável por encontrar serviços cadastrados que satisfaçam os
parâmetros fornecidos. A agência mantém um banco de dados centralizado dos serviços
web disponíveis na rede classificados por tipo de serviço, informações do provedor,
qualidade dos serviços e assim por diante. O protocolo para requisição dessas informações
também é definido, sendo este independente de plataforma, pois utiliza SOAP para
codificação das mensagens.
1.3.5. Composição Web Services
Os Web Services devem ser projetados a fim de permitir que possam ser utilizados por
outros serviços ou aplicações. As novas funcionalidades ou os novos padrões podem ser
adicionados aos serviços sem quebrar o contrato com os consumidores atuais do serviço,
mantendo as funcionalidades existentes anteriormente e a interoperabilidade (Erl, 2007). A
orquestração é um mecanismo de agregação ou composição de serviços visando à obtenção
de um novo serviço com funcionalidades mais complexas. É um componente importante da
arquitetura orientada a serviços, pois encapsula logicamente serviços de forma transparente
ao cliente. A orquestração permite que o desenvolvimento de novos serviços seja realizado
de forma adaptável, flexível e dinâmica as necessidades de negócios que se alteram
frequentemente (Chris, 2003).
A orquestração de serviços define um fluxo de execução de um processo, ou seja,
através de um arquivo de orquestração que é processado por um programa denominado
máquina de orquestração gerencia as chamadas e os fluxos da composição dos serviços.
Nesse arquivo são definidas as chamadas dos serviços componentes necessários à obtenção
do novo serviço. Como qualquer linguagem de programação, as linguagens de orquestração
possuem atribuição de variáveis, interações, e fluxos condicionais. Como a tecnologia mais
compatível com a arquitetura orientada a serviços é a de Web Services as linguagens e
tecnologias para composição de serviços que mais se desenvolveram foram aquelas que
compõem os serviços (Milanovic, Malek, 2004).
O objetivo da orquestração é descrever um processo do ponto de vista de quem
executa, ou seja, somente um ponto de vista de execução do processo é conhecido. A
menos que se tenha acesso ao código dos serviços componentes é impossível saber qual é o
fluxo de execução de cada um deles, pois somente as suas interfaces são conhecidas. A
função das interfaces é mostrar o comportamento estático do serviço enquanto que a
orquestração mostra o comportamento dinâmico do serviço.
A coreografia é um mecanismo de especificação de um protocolo de troca de
mensagens entre duas entidades participando em uma interação. A coreográfica esta inserida
no contexto em que as interações entre os serviços são tipicamente de troca de mensagens
ponto a ponto, síncronas e assíncronas, envolvendo duas ou mais partes, possivelmente de
longa duração e com manutenção de estado. O seu objetivo é especificar o contrato entre duas
entidades independentes de software localizadas em ambientes distintos. O desacoplamento é
a principal característica, pois possibilita que o serviço seja especificado sem revelar qualquer
detalhe sobre sua implementação e provê liberdade quanto à mudança de aspectos privados
do serviço sem afetar o protocolo já estabelecido (BEA Systems, 2003).
Os conceitos de coreografia e orquestração são bem próximos, o que causa algumas
divergências quanto à aplicação de cada um. Primeiro, os nomes em si já levam à analogia de
uma dança coreografada versus uma orquestra controlada por um condutor onde os
participantes reagem às influências externas como música e comportamento dos seus pares. A
coreográfica tem uma natureza colaborativa, isto é, na coreografia é definido um contrato de
interação em que ambas as partes colaboram para atingir um objetivo comum. Já a
orquestração revela o ponto de vista de uma única entidade interagindo com outras entidades.
1.4. Estudo de Caso
Os Web Services podem ser empregados para diferentes propósitos em diversos domínios de
aplicação. Em particular, o uso de Web Services que fornecem funcionalidades para a
adaptação de conteúdo de interfaces gráficas pode contribuir para agilizar o desenvolvimento
de SSCs que realizam adaptação de suas interfaces conforme o contexto da interação. Dessa
maneira, ao invés dos desenvolvedores criarem suas próprias bibliotecas de funções para
adaptação de conteúdo, os mesmos podem reutilizar serviços prontos e validados.
Com o intuito de ilustrar o emprego de Web Services para adaptação de conteúdo,
apresenta-se a seguir a descrição de uma aplicação como estudo de caso. Nas subseções
seguintes são apresentados os componentes de software utilizados no desenvolvimento do
protótipo dessa aplicação, os quais fornecem as funcionalidades de manipulação do
contexto e adaptação de conteúdo com o uso de Web Services.
Ambulance Space Positioning System (ASPS) (MARCONDES et al., 2010) é um
sistema que possibilita a visualização em tempo real da distribuição de ambulâncias no
mapa de uma cidade, podendo ser acessado a partir de diferentes dispositivos. Tal sistema
permite que a equipe de gerenciamento da frota possa monitorar a mobilidade das
ambulâncias e direcionar determinada ambulância para o atendimento de emergência em
um local próximo à região em que a mesma encontra-se atualmente.
Esse sistema, de natureza ubíqua, é composto por três aplicações distintas. O
posicionamento das ambulâncias é feito por meio da triangulação de antenas de telefonia
celular próximas às ambulâncias, a qual é realizada por um terminal Global System for
Mobile Communications (GSM) fixado em cada uma delas. A cada 10 segundos, os dados de
posicionamento são calculados e transmitidos pelo terminal GSM, via Hypertext Transfer
Protocol (HTTP), a uma central de processamento, onde são processados e armazenados em
uma base de dados. Uma aplicação Web disponibiliza uma interface para visualização do
mapa do município com as posições mais recentes das ambulâncias recuperadas da base de
dados. Em pequenos intervalos de tempo, a aplicação Web efetua requisições assíncronas ao
servidor usando AJAX para recuperar e atualizar no mapa a posição das ambulâncias.
A possibilidade de acesso à aplicação Web do ASPS a partir de diferentes
dispositivos leva à necessidade de adaptar suas interfaces gráficas, conforme o perfil do
dispositivo de acesso utilizado pelo gerenciador da frota.
1.4.1. Web Context Framework (WCF)
O Web Context Framework (WCF) abstrai as funcionalidades da camada de gerenciamento
de contexto associadas à aquisição, processamento e disseminação dos elementos contextuais
(Vieira; Tedesco; Salgado, 2009), de forma a facilitar a implementação de SSCs baseados na
Web. O WCF é incorporado tanto aos Web Services de adaptação de conteúdo quanto ao
módulo adaptador de conteúdo da própria aplicação para obter as informações do perfil do
dispositivo que guiarão a adaptação a ser realizada. A implementação do WCF foi feita em
Java. A Figura 1.4. mostra o modelo de componentes do WCF, o qual foi estruturado em três
módulos: Aquisição, Processamento e Disseminação.
Figura 1.4. Modelo de componentes do WCF
O Módulo de Aquisição abrange os componentes que acessam diretamente as
fontes de contexto para obter os elementos contextuais em sua forma original, ou seja, no
formato entregue por essas fontes. Esses componentes são chamados de adaptadores
(Santos, 2008), pois encapsulam os detalhes de acesso às diferentes fontes de contexto e
fornecem métodos abstratos para recuperação dos elementos contextuais implementando a
interface ICtxSrcAdapter. Essa interface contém os métodos
getContextualElement(ContextualElement ce) e getContextualElements(), que recuperam,
respectivamente, um elemento contextual específico e o conjunto de todos os elementos
contextuais disponíveis na fonte de contexto manipulada pelo adaptador correspondente.
As fontes de contexto são, por natureza, heterogêneas, autônomas e dinâmicas,
devido ao fato de existirem independentemente do CSS. Cada qual fornece um conjunto
específico de elementos contextuais que podem ser úteis para diferentes aplicações (Vieira;
Tedesco; Salgado, 2009). Dessa forma, no WCF existe um adaptador apropriado associado
a cada fonte de contexto, o qual utiliza drivers e APIs específicos da fonte de contexto a
qual está vinculado para acessar suas funcionalidades internas e recuperar os elementos
contextuais que são disponibilizados por essa fonte. Essa granulosidade torna o WCF mais
extensível, pois facilita a inclusão de novas fontes de contexto ou a remoção de fontes que
deixaram de existir ou tornaram-se desnecessárias.
Conforme se observa na Figura 1.4, atualmente encontra-se construído no WCF o
adaptador WURFLAdapter para acesso ao arquivo de configuração XML chamado
Wireless Universal Resource File (WURFL) (WURFL, 2010), o qual contém os perfis de
milhares4 de dispositivos de diferentes marcas e modelos existentes. O WURFL é utilizado
por desenvolvedores de software para guiar a criação de soluções apropriadas para
dispositivos específicos. Por ser um arquivo público, o WURFL recebe atualizações diárias
de desenvolvedores espalhados ao redor do mundo interessados em contribuir para a
completude e correção das informações nele contidas. Pelo fato de receber atualizações e
correções contínuas pela própria comunidade de desenvolvimento, o WURFL foi adotado
como fonte de contexto principal para obtenção dos perfis dos dispositivos no WCF.
A Figura 1.5 mostra um trecho de código do componente WURFLAdapter. É
possível notar na linha 3 a importação da API Java do WURFL, a qual permite recuperar os
perfis de dispositivos contidos no arquivo de configuração XML usando como parâmetro o
campo User-Agent da requisição Hypertext Transfer Protocol (HTTP) originada pelo
dispositivo de acesso. Nas linhas 25-35 tem-se a declaração dos objetos que manipulam o
WURFL. A partir da linha 52 em diante, é implementado o método para a obtenção dos
elementos contextuais associados ao perfil do dispositivo.
Figura 1.5. Trecho de código do WURFLAdapter.
Devido à natureza extensível pela qual o WCF foi projetado, outras fontes de
contexto, tais como User Agent Profile (UAProf) (OMA, 2001) e bases de dados de perfis
podem ser acrescentadas futuramente para complementar a obtenção dos elementos
contextuais associados ao perfil do dispositivo, o que implica na implementação dos
adaptadores específicos para acesso a essas fontes de contexto conforme ilustrado na
Figura 1.4. Além disso, fontes de contexto que fornecem elementos contextuais associados
ao usuário (e.g. base de dados que armazenam os perfis de usuário, câmeras de vídeo que
captam a localização atual do usuário), à rede de acesso (e.g. agentes de software que
monitoram as condições de tráfego da rede), dentre outros, também podem ser
incorporados ao WCF para torná-lo mais abrangente.
4 Na última atualização do WURFL disponível em 25/04/2010 foram contabilizados cerca de 13.120
perfis de dispositivos
O Módulo de Processamento engloba os componentes que manipulam os
elementos contextuais e os agrupam de acordo com as entidades do domínio que
caracterizam. Por esse motivo, esses componentes são chamados de agregadores. Cada
agregador é, portanto, uma abstração de uma determinada entidade do domínio que fornece
todos os elementos contextuais relacionados à entidade a qual está vinculado (Dey, 2001).
Por exemplo, na Figura 1.4 o componente DeviceAggregator representa o dispositivo de
acesso e interage diretamente com os adaptadores que acessam as fontes de contexto que
fornecem os elementos contextuais associados ao perfil do dispositivo.
No WCF, cada agregador é construído aplicando o padrão de projeto Façade
(Gamma et al., 1994). Dessa forma, os agregadores atuam como uma fachada que oculta a
complexidade inerente à manipulação dos diversos adaptadores do Módulo de Aquisição e
fornece uma interface única, chamada IAggregator, para obtenção dos elementos
contextuais de determinada entidade. As tarefas de decidir em que fonte(s) de contexto
recuperar um elemento contextual, transformar os elementos contextuais em um nível de
abstração apropriado quando necessário e solucionar os conflitos entre os valores de um
dado elemento contextual obtido de diferentes fontes são encapsuladas pelos agregadores.
Conforme ilustrado na Figura 1.4, além do agregador DeviceAggregator que
representa o dispositivo, agregadores que representam outras possíveis entidades do
domínio, tais como o usuário, a rede de acesso, etc., podem ser construídos para estender o
WCF na medida em que fontes de contexto que fornecem elementos contextuais associados
a essas entidades são acrescentadas ao framework.
Por fim, o Módulo de Disseminação do WCF é composto por um único
componente, chamado ContextManager, que disponibiliza os elementos contextuais
tratados no módulo de processamento aos consumidores de contexto por meio da interface
ICtxManager. Em relação aos consumidores de contexto, o ContextManager atua também
como uma fachada, pois oculta a manipulação dos diversos agregadores e fornece uma
interface única para obtenção dos elementos contextuais. A tarefa de determinar a partir de
qual agregador requisitar um dado elemento contextual é encapsulada pelo
ContextManager.
1.4.2. Adaptador de Conteúdo
O módulo adaptador de conteúdo, chamado ContentAdapter, consome os elementos
contextuais associados ao perfil do dispositivo adquiridos pelo WCF e realiza a adaptação
dinâmica da interface conforme o perfil do dispositivo obtido. Sua implementação foi
realizada utilizando a linguagem Java. Algumas das funcionalidades de adaptação de
conteúdo foram implementadas como Web Services, o que possibilita o reúso dessas
funcionalidades em diferentes aplicações. A Figura 1.6. apresenta o modelo de classes para
o ContentAdapter. A interface IContentAdaptation fornece os métodos abstratos para
adaptação dinâmica da interface da página Web.
Conforme se observa nas importações do modelo de classes Figura 1.6, para a construção
do ContentAdapter foram utilizadas as APIs Java Document Object Model (DOM) e
TagSoup. Essas APIs permitem, em tempo de execução, manipular e transformar
documentos eXtensible Markup Language (XML) que suportam a recomendação DOM do
World Wide Web Consortium (W3C), tais como XHTML e HTML.
Neste trabalho, empregou-se uma estratégia de adaptação híbrida para as interfaces.
Nessa estratégia tem-se a construção de algumas poucas versões mais genéricas da interface
adequadas para um determinado grupo de dispositivos (adaptação estática), e adequação de
alguns trechos do código durante a execução (adaptação dinâmica) para atender às
peculiaridades do perfil do dispositivo de acesso extraído do contexto da interação.
Figura 1.6. Modelo de classes para o ContentAdapter.
O funcionamento do ContentAdapter é ilustrado na Figura 1.7, considerando uma
aplicação Web desenvolvida com o framework Java Server Faces (JSF). Quando uma página
Web é requisitada (1), o Servlet da aplicação invoca o método dynamicAdapt() do
Servlet
ContentAdapter
WCF
WebContent
Mobile
index.jsp about.jsp
Desktop
index.jsp about.jsp
1
2
3
4
5
6
7
8
9
10
Requisição
HTTP
dynamicAdapt()
Resposta
Adaptação
dinâmica utilizando
Web Services
Seleção
da versão
Obtenção do
perfil do dispositivo
Busca do perfil
do dispositivo
Web Services de
adaptação de
conteúdo
Busca do perfil
do dispositivo
Figura 1.7. Funcionamento do ContentAdapter.
ContentAdapter (2), o qual requisita o perfil do dispositivo ao WCF (3). O WCF usa como
parâmetro o campo User-Agent da requisição HTTP para a obtenção do perfil do dispositivo a
partir das fontes de contexto disponíveis, neste caso, o WURFL (4). O perfil do dispositivo é
retornado ao ContentAdapter (5), que seleciona a página Web requisitada da versão genérica
da interface mais adequada ao perfil do dispositivo recuperado (6). Em seguida, o
ContentAdapter cria uma cópia da página escolhida na memória e identifica os trechos do
código que necessitam ser refinados para ajustarem-se ao tamanho de tela específico do
dispositivo e ao suporte fornecido pelo mesmo para componentes como imagens, tabelas,
campos de formulários, dentre outros (7). O ContentAdapter verifica as divergências entre os
trechos de código analisados e o perfil do dispositivo recuperado pelo WCF e aplica as
adaptações necessárias (8). Nessas adaptações, além de utilizar métodos próprios, o
ContentAdapter também invoca os Web Services de adaptação de conteúdo implementados.
A cópia adaptada da página é escrita pelo ContentAdapter no buffer de saída da resposta
HTTP (9) e finalmente enviada ao dispositivo do usuário por intermédio do Servlet (10).
A Figura 1.8 mostra um trecho do método adaptInput() do ContentAdapter, onde é
realizada a invocação do Web Service que realiza a adaptação de campos de entrada de
texto (<input type=”text”/> e <input type=”password”/>). Essa adaptação envolve o
redimensionamento desses campos conforme a largura de tela do dispositivo de acesso.
Conforme se observa na Figura 1.7, o nó <input> representado em um objeto do tipo Node
da API DOM é serializado em uma cadeia de caracteres (linha 359) e passado como
parâmetro ao Web Service juntamente com o valor do campo User-Agent da requisição
HTTP (linha 361). Este último parâmetro permite ao Web Service, o qual pode estar
hospedado em um servidor remoto, obter do WCF o perfil do dispositivo onde a requisição
foi efetuada para realizar a adaptação.
Figura 1.8. Método adaptInput() do ContentAdapter com a invocação do WebService.
A Figura 1.9 mostra um trecho do código do Web Service que realiza a adaptação
de campos de entrada de texto. Nas linhas 29-32 o nó <input> passado como parâmetro é
desserializado em um objeto Node. Em seguida, na linha 33, é instanciado um objeto
ContextManager do WCF, parametrizado com o campo User-Agent recebido pelo Web
Service. Nas linhas 34-36 é obtido o número de colunas da tela do dispositivo através do
WCF. Na linha 40 recupera-se o valor do atributo “size” do nó <input>. Por fim, nas linhas
44-45, o atributo “size” do campo de texto é reduzido caso seja maior que o número de
colunas da tela do dispositivo.
Figura 1.9. Trecho de código do WebService adaptInput.
Além do Web Service para adaptação de campos de entrada de texto, também foi
implementado um Web Service para adaptação de nós <div>, os quais representam uma
região de conteúdo dentro da interface Web. A adaptação desempenhada, neste caso,
envolve o redimensionamento desses nós de forma que seu conteúdo possa ajustar-se à
largura de tela do dispositivo de acesso utilizado. Além disso, no próprio ContentAdapter
foi implementado um método para adaptação de imagens, o qual redimensiona as imagens
de forma compatível à resolução de tela do dispositivo, bem como as transforma em um
formato adequado para visualização no mesmo, conforme o perfil recuperado.
1.4.3. Desenvolvimento do ASPS
O protótipo da aplicação Web do ASPS foi desenvolvido com a utilização dos
componentes de software apresentados anteriormente. A Figura 1.10 apresenta o código do
Servlet da aplicação, chamado ContextServlet, onde o ContentAdapter é empregado. É
possível observar na figura que o ContentAdapter é importado ao Servlet na linha 3 e
instanciado em um objeto chamado ca na linha 22. A linha 24 atualiza o objeto ca com os
Figura 1.10. Código do Servlet da aplicação.
novos objetos de requisição e resposta HTTP caso o objeto ca já tenha sido instanciado. A
invocação ao método dynamicAdapt() do ContentAdapter é realizada na linha 26. A partir
daí, o ContentAdapter realiza as adaptações necessárias à interface Web utilizando dos
Web Services, bem como de seus métodos próprios.
O protótipo foi executado nos emuladores do smartphone HTC G1 e do iPhone,
bem como em um desktop. A Figura 1.11 mostra o resultado das execuções nesses
dispositivos. A Figura 1.11 (a) e (b) mostra a execução da interface na tela do HTC G1 e do
iPhone, respectivamente. Em ambos os casos, a versão da interface entregue foi a versão
construída para dispositivos móveis. Para tornar visível a diferença obtida com a adaptação
dinâmica desempenhada pelos adaptadores de conteúdo contidos no ContentAdapter, são
mostradas a interface adaptada e sua correspondente sem adaptação. Na Figura 1.11 (a) é
mostrado o topo da interface que contém o logotipo da aplicação. É possível observar que
(a) Visualização no HTC G1:
com adaptação
da interfacesem adaptação
da interface
(b) Visualização no iPhone:
(c) Visualização em um desktop:
com adaptação
da interface
sem adaptação
da interface
Figura 1.11. Testes da execução da aplicação em três dispositivos distintos.
com a adaptação da interface o logotipo foi redimensionado para encaixar-se à tela do HTC
G1. A Figura 1.11 (b) mostra a parte inferior da mesma interface, onde se tem um painel de
abas que contém um mashup do Google Maps. É possível notar que através da adaptação
da interface, o painel de abas foi ajustado de forma a não extrapolar a largura de tela do
iPhone. A Figura 1.11 (c), por sua vez, mostra a interface visualizada num desktop. Neste
caso, a versão da interface entregue foi a construída para desktops.
1.5. Considerações Finais
O uso de Web Services na construção de SSCs torna mais ágil o processo de
desenvolvimento, uma vez que a reutilização de serviços prontos que fornecem
funcionalidades para adaptação de conteúdo e outros comportamentos sensíveis ao
contexto, elimina a necessidade da implementação dessas funcionalidades a partir do zero.
Além disso, os Web Services fornecem uma infraestrutura que permite a interoperabilidade
entre diferentes plataformas de execução, de forma que os diversos dispositivos usualmente
presentes em ambientes ubíquos possam usufruir dos serviços providos.
Referências
Advancing open standards for the information society. Inc.: UDDI Version 3.0.2. February
2010, http://uddi.org/pubs/uddi_v3.htm
Araújo, R. B. Araújo. (2003) “Computação ubíqua: princípios, tecnologias e desafios,” In: Proc.
XXI Simpósio Brasileiro de Redes de Computadores, Minicurso: Livro Texto, Natal, RN,
Brazil, 2003, p. 45-115.
Asthana, A., Cravatts, M., e Krzyzanowski, P. (1994). “An indoor wireless system for
personalized shopping assistance”. In: Proceedings of IEEE Workshop on Mobile
Computing Systems and Applications, Santa Cruz, California, IEEE Computer Society
Press, p. 69-74.
Baldauf, M., Dustdar, S., e Rosenberg, F. (2007) “A survey on context-aware systems”, In: Int.
J. Ad Hoc Ubiquitous Comput., Geneva, Switzerland, Inderscience Publishers, p. 263-277.
Bazire, M., e Brézillon, P. (2005) “Understanding Context Before Using It”, In: Proc. of the 5th
Int. and Interdisciplinary Conference, Paris, France, Springer Verlag, p. 29-40.
BEA Systems, International Business Machines Corporation, Microsoft Corporation,
SAP AG, Siebel Systems. Business Process Execution Language for Web Services
Version 1.1, Maio 2003.
Bennett, F., Richardson, T., e Harter, A. (1994). “Andy Harter. Teleporting - making
applications mobile”. In: Proceedings of IEEE Workshop on Mobile Computing Systems
and Applications, Santa Cruz, California, IEEE Press, p. 82-84.
Brézillon, P. (1999) “Context in Problem Solving: A Survey”, In: The Knkowledge Engineering
Review, vol. 18, n. 2, p. 1-40.
Brézillon, P., e Pomerol, J.-C. (1999) “Contextual Knowledge Sharing and Cooperation in
Intelligent Assistant Systems”, In: Le Travail Humain, PUF, Paris, v. 62, n. 3, p. 223-246.
Chen, H. An Intelligent Broker Architecture for Pervasive Context-Aware Systems, PhD
Thesis, University of Maryland, Baltimore County, 2004.
Chen, G., Kotz, D., A Survey of Context-Aware Mobile Computing Research, Relatório
Técnico TR2000-381, Dept. of Computer Science, Dartmouth College, 2000.
Coutaz, J., Crowley, J. L., Dobson, S., e Garlan, D. (2005) “Context is Key”, In:
Communications of the ACM, vol. 48, issue 3, New York, USA, ACM, p. 49-53.
Chris Peltz. Web Services Orchestration and Choreography. Computer, 2003.
Daily, P. G., “XML Basics and Benefits”. Disponível em
<http://www.intranetjournal.com/articles/200312/ij_12_08_03a.html>. Acesso em: 07 Maio
2010.
Dey, A. K. (2001) “Understanding and Using Context”, In: Personal Ubiquitous Computing,
vol. 5, issue 1, London, UK, Springer-Verlag, p. 4-7.
Dey, A. K., Futakawa, M., Salber, D., e Abowd, G. D. (1999). “The Conference Assistant:
Combining Context-Awareness with Wearable Computing”. In: Proceedings of the 3rd
International Symposium on Wearable Computer, San Francisco, CA, IEEE Computer
Society Press, p. 21-28.
Dourish, P. Where the action is: the foundation of embodied interaction. MIT Press, Cambridge,
2001.
E9-1-1 Institute. Disponível em: < http://www.e911institute.org/>. Acesso: Abril 2010.
Eisenstein, J., Vanderdonckt, J., e Puerta, A. (2000). “Adapting to mobile contexts with user-
interface modeling”. In: Proceedings of the 3rd IEEE Workshop on Mobile Computing
Systems and Applications, Monterey, California, p. 83-92.
Erl, T.: SOA Principles of Service Design. The Prentice Hall Service-Oriented Computing
Series from Thomas Erl. Prentice Hall PTR, 2007.
Erl, T.: Service-Oriented Architecture: Concepts, Technology & Design. The Prentice Hall
Service-Oriented Computing Series from Thomas Erl. Prentice Hall PTR, 2005.
Fernandes, P. C. C. UBIFEX: Uma Abordagem para Modelagem de Características de Linha de
Produtos de Software Sensíveis ao Contexto. Dissertação de Mestrado, Universidade Federal
do Rio de Janeiro, RJ, 2009.
Forte, M., de Souza, W. L., e do Prado, A. F. (2008) “Using Ontologies and Web Services for
Content Adaptation in Ubiquitous Computing”. In: Journal of Systems and Software, vol. 81,
n. 3, New York, USA, Elsevier Science, p. 368-381.
Gamma, E., Helm, R., Johnson, R., e Vlissides, J. M.. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley Professional, 1994.
Grün, C., Werthner, H., Pröll, B., et al. (2008) “Assisting Tourists on the Move - An Evaluation
of Mobile Tourist Guides”, In: Proc. of the 7th International Conference on Mobile Business,
Barcelona, Spain, IEEE Computer Society, p. 171-180.
Lucrédio, D. Uma Abordagem Orientada a Modelos para Reutilização de Software, Tese de
Doutorado, Universidade de São Paulo. Instituto de Ciências Matemáticas e de Computação,
São Carlos, SP, 2009.
Marks, E. A. e Bell, M., 2006, “Service-Oriented Architecture: a planning and
implementation guide for business and techonology”, John Willey & Sons Inc.
Newcomer, Eric. Understanding Web Services - XML, WSDL, SOAP, and UDDI. Addison
Wesley, 2002.
Nikola Milanovic e Miroslaw Malek. 2004. “Current Solutions for Web Service
Composition”. IEEE Internet Computing.
OASIS, Advancing open standards for the information society. Inc.: UDDI Version 3.0.2. 2004.
Disponível em: <http://uddi.org/pubs/uddi_v3.htm>. Acesso em: 07 Mario 2010.
OMA. 2001. WAG UAProf. Disponível em: http://www.openmobilealliance.org. Acesso:
Fevereiro, 2010.
Papazoglou M. P. e Georgakopoulos D. “Service-oriented computing: Introduction”.
Communications of the ACM, 46(10):24–28, Outubro 2003.
Papazoglou, M. P., Heuvel, e Willem-jan, 2007. “Service oriented architectures:
approaches, technologies and research issues”, VLDB Journal, Springer-Verlag.
Perepletchikov, M., Ryan, C., e Tari, Z. 2005. “The Impact of Software Development
Strategies on Project and Structural Software Attributes in SOA”. In: Proc. of On the
Move to Meaningful Internet Systems 2005: OTM Workshops, p. 442-451.
Santos, V.V., CEManTIKA: A Domain-Independent Framework for Designing Context-
Sensitive Systems, Tese de Doutorado, Universidade Federal de Pernambuco, PE, 2008.
Schilit, B., e Theimer M. (1994) “Disseminating Active Map Information to Mobile Hosts”, In:
IEEE Network, vol. 8, p. 22-32.
Viana, W., e Andrade, R. M. C. (2008) “XMobile: a MB-UID environment for semi-automatic
generation of adaptive applications for mobile devices”. In: Journal of Systems and Software,
vol. 81, n. 3, p. 382-394.
Vieira, V., Tedesco, P., e Salgado, A. C. (2009) “A Process for the Design of Context-Sensitive
Systems”, In: Proc. of the Int. Conference on Computer Supported Cooperative Work in
Design, IEEE, p. 143-148.
W3C. Web Services Architecture. 2004a. Disponível em: < http://www.w3.org/TR/ws-arch>
Acesso em: 07 Maio 2010.
W3C. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. 2007.
Disponível em: http://www.w3.org/TR/wsdl20>. Acesso em: 07 Maio 2007.
W3C. Simple Object Access Protocol (SOAP) Version 1.2 Part 1: Messaging Framework
(Second Edition). April 2007, http://www.w3.org/TR/soap12-part1/.
Walsh A. E., editor. UDDI, SOAP, and WSDL: The Web Services Specification Reference
Book. Prentice Hall, 2002.
Want, R,, Hopper, A., Falcão, V., e Gibbons, J. (1992) “The Active Badge location system”. In:
ACM Transactions on Information Systems, vol. 10, n. 1, p. 91-102.
Weiser, M. (1999) “The computer for the 21st century”. In: ACM SIGMOBILE Mobile
Computing and Communications Review - Special issue dedicated to Mark Weiser, vol. 3, n.
3, p. 3-11.
WURFL. Wireless Universal Resource File. Disponível em: <http://wurfl.sourceforge.net>.
Acesso: Fevereiro, 2010.
