DESENVOLVIMENTO DE UMA ARQUITETURA DE INTEGRAÇÃO ENTRE SERVIÇOS WEB PARA CRIAÇÃO DE APLICAÇÕES HÍBRIDAS E SOCIAIS

FATEC - FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS

JOSÉ TELES MACIEL, WILLIAM ANTÔNIO SIQUEIRA

DESENVOLVIMENTO DE UMA ARQUITETURA DE INTEGRAÇÃO ENTRE SERVIÇOS WEB PARA CRIAÇÃO DE APLICAÇÕES HÍBRIDAS E SOCIAIS

SÃO JOSÉ DOS CAMPOS 2009

JOSÉ TELES MACIEL, WILLIAM ANTÔNIO SIQUEIRA

DESENVOLVIMENTO DE UMA ARQUITETURA DE INTEGRAÇÃO ENTRE SERVIÇOS WEB PARA CRIAÇÃO DE APLICAÇÕES HÍBRIDAS E SOCIAIS

Trabalho de graduação apresentado à faculdade de tecnologia de São José dos Campos, como parte dos requisitos necessários para obtenção do título de tecnólogo em informática.

Orientador: Giuliano Araujo Bertoti, Msc

SÃO JOSÉ DOS CAMPOS 2009

ii

JOSÉ TELES MACIEL, WILLIAM ANTÔNIO SIQUEIRA

DESENVOLVIMENTO DE UMA ARQUITETURA DE INTEGRAÇÃO ENTRE SERVIÇOS WEB PARA CRIAÇÃO DE APLICAÇÕES HÍBRIDAS E SOCIAIS

________________________________________________________ FERNANDO MASANORI ASHIKAGA , Msc ________________________________________________________ EDUARDO SAKAUE, Msc ________________________________________________________ GIULIANO ARAUJO BERTOTI , Msc ___/___/___ DATA DE APROVAÇÃO

iii

Dedicamos este trabalho aos nossos amigos incentivadores e entusiastas da primeira turma de banco de dados da FATEC de São José dos Campos.

iv

AGRADECIMENTOS Agradecemos ao professor e orientador Giuliano Bertoti pelo apoio, encojaramento e pelo tempo empregado na qualidade deste trabalho tanto quanto empregado na discussão, sempre aberta estimulante, de novas idéias. Também agradecemos a todo corpo docente da FATEC São José dos Campos, por incutir em nós a necessidade de aprender sempre.

v

RESUMO Apresenta-se neste trabalho uma arquitetura para integração entre serviços web para criação de aplicações híbridas e sociais. Esta arquitetura é vista como um símbolo de mudança de paradigma no que se refere a desenvolvimento de aplicações para web. Hoje as aplicações relevantes para as pessoas são híbridas, pois misturam em sua estrutura conteúdo de mais de uma fonte de dados, e sociais, pois dizem respeito a atividades e perfis pelos quais as pessoas criam suas vidas virtuais na web. Inseparável desta arquitetura, também é apresentada uma ferramenta voltada ao desenvolvedor de aplicações que retira de sua agenda as horas gastas com programação repetitiva e adequação às especificações de serviços e o oferece em troca a possibilidade de, visualmente, lidar com a grande massa de dados sociais disponíveis na web. Acredita-se num desgaste do termo usuário e na web feita de pessoas e idéias, algumas destas idéias, espera-se, serão mais facilmente colocadas em prática com ajuda deste trabalho. Palavras-chave: web 2. 0, mashups, aplicações híbridas, redes sociais, computação nas nuvens, desenvolvimento web.

vi

ABSTRACT We present in this work an architecture for integration between web services in order to create hybrid and social applications. We see this architecture as a paradigm change concerning web application development. Today, people relevant applications are hybrid since they mix within their structure contents from more than one data source, and social, as they are related to activities and profiles from which people create their social web lives. Bound to this architecture we also present a tool for the applications developer who can take out of his agenda hours spent with repetitive programming and service’s specification adequation in order to offer the possibility of visually deal with the large mass of social data on the web. We believe in the wear of the term user and on a web made by people and ideas, some of those ideas, we hope, will be easier concretized with the help of this work. Keywords: web 2. 0, mashups, social networks, cloud computing, web development.

vii

SUMÁRIO 1.

INTRODUÇÃO...............................................................................................................11

1.1.Objetivos.............................................................................................................................12 1.1.1.Objetivo geral.............................................................................................................................................12 1.1.2.Objetivos específicos..................................................................................................................................12

1.2. Metodologia.....................................................................................................................12 1.3.Organização do trabalho.....................................................................................................13 2.WEB 2.0................................................................................................................................15 2.1.Inteligência coletiva......................................................................................................................................16 2.2.Usuário como centro da web.........................................................................................................................17 2.3.Centralizadores de conteúdo.........................................................................................................................17 2.4.O desenvolvimento de software para web 2.0...............................................................................................18 2.4.1.Otimização de buscas.............................................................................................................................18 2.4.2.O “beta” perpétuo...................................................................................................................................18 2.5.A web como plataforma................................................................................................................................19

2.6.Computação nas nuvens e suas tecnologias........................................................................19 2.6.1.As camadas arquiteturais de serviços.........................................................................................................20 2.6.2.Computação sob demanda (ou on-demand computing).............................................................................21 2.6.3.IaaS – Infraestrutura como serviço.............................................................................................................21 2.6.4.PaaS – Plataforma como serviço................................................................................................................22 2.6.5.SaaS – Software como serviço...................................................................................................................22 2.6.6.Um manifesto para uma nuvem aberta (Open cloud manifesto)................................................................24 2.6.6.1.Objetivos do manifesto........................................................................................................................25 2.6.6.2.A perspectiva SAP sobre o manifesto.................................................................................................26 2.6.6.3.Princípios para uma nuvem aberta......................................................................................................26 2.6.7.A computação nas nuvens e as suas tecnologias........................................................................................27 2.6.7.1.HTML..................................................................................................................................................27 2.6.7.2.Folhas de Estilo CSS...........................................................................................................................28 2.6.7.3.Javascript.............................................................................................................................................28 2.6.7.4.AJAX...................................................................................................................................................29 2.6.8.Tecnologias do lado servidor.....................................................................................................................32 2.6.9.RESTful......................................................................................................................................................32

2.7.Serviços web.......................................................................................................................34 2.7.1.SOA – Arquitetura orientada à serviços.....................................................................................................35 2.7.2.SOAP – Um contrato formal para acesso...............................................................................................36 2.7.3.WSDL – Um contrato formal para descrição.........................................................................................37 2.7.4.UDDI – Um contrato formal para descoberta e descrição.....................................................................38 2.7.5.A visão estratégica de SOA ...................................................................................................................39 8

2.7.6.Misturando serviços...................................................................................................................................39

2.8.Mashups..............................................................................................................................40 2.8.1.As diversas classes de mashups.................................................................................................................41 2.8.2.Arquitetura para Mashups..........................................................................................................................41 2.8.3.Como construir uma mashup......................................................................................................................42

3.

ANÁLISE DE EDITORES DE MASHUPS NA WEB........................................44

3.1.OpenMashups Studio..........................................................................................................45 3.1.1.Características da Ferramenta....................................................................................................................45 3.1.2.Fontes de dados disponíveis.......................................................................................................................46 3.1.3.Conhecimentos necessários ao desenvolvedor ..........................................................................................46 3.1.4.Documentação............................................................................................................................................47 3.1.5.Comunidade ..............................................................................................................................................47

3.2.IBM Mashups Center..........................................................................................................47 3.2.1.Características da ferramenta ....................................................................................................................48 3.2.2.Fontes de dados acessíveis ........................................................................................................................49 3.2.3.Criando e disponibilizando uma mashup ..................................................................................................51 3.2.4.Conhecimentos necessários ao desenvolvedor...........................................................................................52 3.2.5.Documentação............................................................................................................................................52 3.2.6.Comunidade...............................................................................................................................................52

3.3.Yahoo! Pipes.......................................................................................................................53 3.3.1.Características da ferramenta.....................................................................................................................54 3.3.2.Fontes de dados acessíveis ........................................................................................................................55 3.3.3.Criando e disponibilizando uma mashup ..................................................................................................55 3.3.4.Conhecimentos necessários ao desenvolvedor...........................................................................................56 3.3.5.Documentação ...........................................................................................................................................57 3.3.6.Comunidade...............................................................................................................................................57

3.4.Comparação entre os editores.............................................................................................57 3.5.Considerações Finais sobre a análise..................................................................................57 4.ARQUITETURA PARA A GERAÇÃO DE SERVIÇOS WEB .....................................59 4.1.Arquitetura Global .............................................................................................................59 4.2.Arquitetura banco de dados ................................................................................................60 4.3.Arquitetura OO ..................................................................................................................62 4.4.Persistência de objetos..................................................................................................................................63 4.5.Buscando e tratando dados .............................................................................................................................................................................65 4.6.MVC .............................................................................................................................................................69 4.7.Arquitetura Web ...........................................................................................................................................69

4.8.Modelo de interface gŕafica com usuário............................................................................71 9

4.9.Visão geral do funcionamento da ferramenta.....................................................................75 5.CONSIDERAÇÕES FINAIS..............................................................................................77 5.1.Conclusões..........................................................................................................................77 5.2.Contribuições .....................................................................................................................78 5.3.Publicação.....................................................................................................................................................78

5.4.Trabalhos futuros................................................................................................................78 6.REFERÊNCIAS...................................................................................................................80

10

1.

INTRODUÇÃO A difusão da web como meio de comunicação e a democratização do acesso

proporcionando que cada usuário seja escritor ativo dessa mídia aliada as tecnologias emergentes de arquitetura de software compõe o cenário perfeito para o desenvolvimento de aplicações híbridas compostas de vários módulos. Além disso, o desenvolvimento ágil de aplicações e a disponibilização dos ativos de TI como serviços torna-se uma realidade e uma necessidade da área, indispensável para a agregação de valor ao produto final de informática. O desenvolvimento web se concentra em pontos estratégicos, tais como: Reusabilidade, centralização, padronização e outros, a arquitetura aqui exposta faz uso de todos esse pontos e os fortalece. Os Mashups propõe uma solução para aproveitamento de serviços, dados e recursos que minimiza o tempo de implementação na criação de aplicações que atendem as necessidades dinâmicas. Agregar conteúdo traz a tona uma nova necessidade que as ferramentas para desenvolvimento de aplicações híbridas (editores de Mashup) tem como foco. O cenário de desenvolvimento hoje é cada vez mais ágil e menos preocupado com questões já resolvidas. Frameworks para todas as linguagens e todas as necessidades são fáceis de encontrar. Em alguns casos. criar uma aplicação sem regras de negócio, mas com telas iniciais e banco de dados, se limita a poucas linhas de comando e nenhuma programação. O desenvolvedor se encontra no meio de um mar de utilidades e ferramentas, porém sem saber no que apostar, este trabalho propõe que o desenvolvedor aposte em criatividade, idéias e aproveitamento de dados sociais ao invés de se focar em uma tecnologia específica ou outra. O foco em lógica, é claro, é sempre presente. Num nível empresarial os mashups vem ganhando um grande espaço, prova-se isso com o esforço de diversas empresas de importância como a IBM em disponibilizar soluções que misturam serviços e dados dentro do cenário da empresa. 11

Criar mashups é barato, rentável, rápido e promissor, certamente uma aposta para um novo modelo de negócio de software nas empresas de vanguarda. Deve ser dito também, que a mudança de paradigma que este trabalho propõe, desgastando o termo usuário da web e o promovendo a desenvolvedor potencial, vem para o bem e só tem a trazer benefícios , mesmo àqueles que já tem toda uma grande bagagem com desenvolvimento de aplicações para web. Além disso, desenvolver , criar e editar mashups, extrair e filtrar dados de redes sociais é uma tarefa divertida que explora a web e o que ela oferece para devolver em troca novas aplicações. 1.1.

Objetivos Serão expostos os Objetivos gerais e específicos para este trabalho.

1.1.1. Objetivo geral Desenvolver uma arquitetura de integração entre serviços web para criação de aplicações híbridas e sociais.

1.1.2. Objetivos específicos a)

O desenvolvimento deste trabalho possui os seguintes objetivos específicos:

b)

Propor uma solução nova para criação de mashups.

c) Escolher o âmbito da

solução entre: extensão de uma ferramenta existente, ou

ferramenta inteiramente nova ou editor extensível de serviços sociais mixáveis. d) Desenvolver uma ferramenta para extração e filtragem de dados de redes sociais usando inicialmente uma API social de exemplo. e) Tornar essa ferramenta capaz de incorporar novas APIs. f) Garantir requisitos funcionais. g) Garantir requisitos não funcionais com foco principal em extensibilidade. 1.2.

Metodologia 12

Adota-se neste trabalho a seguinte metodologia: a)

Analisar o cenário de desenvolvimento atual para Mashups e serviços sociais .

b) Definir os assuntos pertinentes ao cenário de pesquisa. c) Reunir referências bibliográficas relevantes do cenário de pesquisa. d)

Conhecer as API de plataformas sociais, tais como Orkut e Facebook .

e) Analisar ferramentas de edição de mashups . f) Modelar o banco de dados relacional utilizado na solução. g) Modelar a solução, contendo diagramas de caso de uso, diagramas de classe e fluxos de dados da aplicação. h) Análise de frameworks aplicáveis aos requisitos funcionais da solução. i) Criar o protótipo da solução onde, entre outros, aplicam-se: a. Aplicar conhecimentos de orientação à objetos e padrões de projeto para que a solução seja adaptável a novas plataformas e necessidades. b. Codificação dos requisitos principais e da versão pronta da arquitetura web. c. Classes de acesso à dados reutilizáveis. d. Implementação de frameworks pesquisados. 1.3.

Organização do trabalho

Os demais capítulos deste trabalho são: Capítulo 2, WEB 2.0, Neste capítulo se discute web 2.0, seus conceitos e tecnologias, apresenta-se a computação nas nuvens e o software como serviço, conceitos fundamentais para realização deste trabalho, é aqui também que mashups são explicadas inicialmente; Capítulo 3, ANÁLISE DE EDITORES DE MASHUPS NA WEB. Neste capítulo é trazida a tona uma análise de 03 dos principais editores de mashups disponíveis para os desenvolvedores, suas vantagens, comunidade, documentação; Capítulo 4, ARQUITETURA PARA A GERAÇÃO DE SERVIÇOS WEB, aborda a arquitetura e a modelagem da ferramenta proposta neste trabalho, incluindo arquitetura de banco de dados, arquitetura OO, e projeto visual; 13

Capítulo 5, CONSIDERAÇÕES FINAIS, concluí o trabalho, apresenta contribuições e trabalhos futuros.

14

2.

WEB 2.0 Web 2.0 é uma reunião de conceitos, paradigmas, e principalmente atitudes que geram

e mantém uma web participativa e dinâmica que se contrapõe a geração anterior da web 1.0 de conteúdo estático e expositivo (O'REILLY,2005). O Termo web 2.0 foi introduzido pela primeira vez numa conferência ocorrida em 2001 e que contava com os pioneiros da web: Dale Dougherty e O'Reilly VP durante um brainstorming. A popularização deste conceito ocorreu de tal forma que em um ano e meio após esta conferência, 9.5 milhões de buscas pelo tema foram feitas no site da Google (O'REILLY, 2005). Este capítulo está dividido como segue: A seção 2.1. “ O que é web 2.0 e porque ela é interessante” mostra uma visão geral das motivações em se trabalhar com o tema web 2.0 e os conceitos que o compõe, a Seção 2.2. “Computação nas nuvens e suas tecnologias” expõe o tema computação nas nuvens suas tecnologias e impactos para desenvolvedor e empresas, bem como assuntos relativos, A Seção 2.3 “Serviços web” trata de serviços web e suas especificações para desenvolvimento de aplicações, a Seção 2.4 “Mashups” apresenta o conceito de aplicações híbridas para internet. Apesar de parecer que o termo web 2.0 se refere a uma técnica, na verdade o coração da web 2.0 pode ser compreendido quando analisados um grupo de idéias que mudaram e continuam mudando o modo como as pessoas interagem na web (ANDERSON, 2009). Os principais apelos que compõe este grupo de idéias são: a) A participação ativa e decisória do usuário com opiniões e modificações de conteúdo, o que torna o usuário o centro da web 2.0; b) O software é oferecido como serviço e acessado pela web, independente de sistema operacional e sem a necessidade de instalação, precisando apenas de conexão à rede; c) O desenvolvimento de software é colaborativo e todas as fontes são compartilhadas e visíveis, o que ajuda na detecção de erros e provém a melhoria contínua; d) A organização de conteúdo não é hierarquizada, mas feita por tagging, o que cria na web um ambiente associativo, que funciona de maneira mais aproximada ao cérebro humano (GRUBER,2009) ; 15

e) A criação de conteúdo confiável e relevante por meio de comunidades fortes, classificações e tagging (conceito melhor detalhado ainda nessa seção) fazem com que indivíduos agindo de forma independente produzam resultados relevantes para a coletividade; (ANDERSON, 2009) f) O conteúdo vai até o usuário através de RSS, Atom e sites centralizadores de conteúdo se tornam populares e muito úteis; g) A web 2.0 explora o potencial da rede, seu alcance massivo e mundial e a inteligência coletiva dos usuários ( tratada em uma subseção próxima ) fazendo da rede um espaço vivo e interessante. 2.1.

Inteligência coletiva Durante o período conhecido como “Estouro da Bolha.com” (O'REILLY, 2005) os

sites mantidos na internet mudavam seu foco de conteúdo para apresentação. Animação, efeitos sonoros sobrecarregavam páginas para trazer ao usuário uma experiência que suponhase mais atraente. Ficou claro, no entanto, passada essa fase que os maiores sucessos da web vinham de sites que apostavam em conteúdo e participação. Com o tempo o nível de participação do usuário como escritor da web aumentou consideravelmente dando vida ao fenômeno da inteligência coletiva como uma maneira de organizar, manter, acessar, atualizar, reutilizar e qualificar informação relevante na web. Iniciativas como filtros de spam colaborativos, a expansão da quantidade de programas disponibilizados de graça no SourceForge (SOURCEFORGE, 2009) , ou a competência da Wikipedia (WIKIPEDIA, 2009) em se manter como fonte confiável de consulta são exemplos de inteligência coletiva gerada a partir de comunidades fortes na rede. Na mesma linha de pensamento, o tagging (ação de “etiquetar” conteúdo web através de palavras chaves na web) e as classificações de conteúdo ajudam a popularizar informação de interesse massivo. A figura 1 mostra uma nuvem de tags, muito comum em diversos sites, esta nuvem especificamente é composta por tags referentes a este capítulo do trabalho: 16

Figura 1 Um exemplo de nuvem de tags usando palavras deste capítulo do trabalho. Gerada usando http://wordle.net (WORDLE, 2009)

2.2.

Usuário como centro da web Na web 1.0 a interação do site (e quem o publica) com o visitante acontecia, na

maioria das vezes por ferramentas de fóruns e ambientes de respostas assíncronas (ou seja, uma mensagem era postada e se esperava um bom tempo até ter uma resposta de outro usuário). A web 2.0 prevê como um dos seus principais atrativos, senão o maior deles o usuário como criador da web e o desgaste do termo “visitante” . Na web 2.0 os sites pessoais foram substituídos por blogs atualizados e comentados, especulações em torno de nomes de domínio deram lugar a busca por melhores mecanismos de pesquisa, álbuns de foto online foram trocados por redes de amigos baseados em postagens de fotos e o email perdeu espaço para as redes sociais como Facebook (FACEBOOK, 2009) e Orkut (ORKUT, 2009). Nesses casos, o site oferece a infra-estrutura e os usuários o tornam dinâmico e atualizado (O'REILLY, 2005) . Na antiga web 1.0, o usuário tinha participação estática, suas ações não tinham influência direta no mapa dos sites, hoje temos sites completamente customizados, que reconhecem o perfil do visitante e não podem existir sem a atualização constante do usuário. 2.3.

Centralizadores de conteúdo 17

Sites centralizadores de conteúdos se tornam atrativos e uma parte essencial no atual paradigma 2.0, em alguns pontos são mais requisitados que os próprios sites portadores do conteúdo original. Pode-se citar, como exemplo, o InfoBlogs (INFOBLOGS, 2009) , um site que centraliza postagens recentes dos mais famosos blogs de informática do Brasil. Isso ocorre devido a grande massa de conteúdo espalhado pela web onde as vezes é melhor visualizar todo conteúdo de uma determinado assunto num só lugar que ter que sair em sites generalistas procurando o que se deseja. 2.4.

O desenvolvimento de software para web 2.0 Com toda uma revolução acontecendo fica óbvio que o cenário para desenvolvimento

web 2.0 também muda. Novas tecnologias e conceitos passam a fazer parte do processo de desenvolvimento. 2.4.1. Otimização de buscas A busca é indispensável! Mecanismos incorporados aos sites fazem com que estes apresentem melhorias para que as buscas o encontrem. Sites de busca, como o Google (GOOGLE, 2009) , utilizam-se de robôs (algoritmos que varrem as páginas disponíveis na web) e para procurar por páginas. Sites de compartilhamento de mídia, como o Flickr (FLICKR, 2009) , precisam exclusivamente de classificação por tags para tornar possíveis as buscas de suas imagens. Essas técnicas de otimização para que o site seja visível para as buscas, garantem que seu conteúdo terá mais chances de ser encontrado. A não previsão desses pontos acaba por ocultar um sistema, por melhor que seja o conteúdo (LEDFORD,2009). 2.4.2. O “beta” perpétuo Os sistemas web 2.0 tem que se adaptar a novas funcionalidades e estar sempre abertos a possíveis mudanças, tendências. Por isso, tornou-se comum encontrar sistemas cujo status 18

não é uma versão, mas sim a definição de "beta perpétuo”, sem necessitar de versões definidas como finais. Um exemplo é o Gmail, declaradamente beta desde sua criação em 2004 até Julho deste ano, sempre adicionando novas funcionalidades para se manter a frente de seus concorrentes. (GMAIL,2009) . 2.5.

A web como plataforma A perspectiva de Tim O'Reilly de que “a cada momento uma plataforma supera uma

aplicação” representa uma verdade web 2.0 . (O'REILLY, 2005) Aplicativos online e até mesmo sistemas operacionais online são comuns na web, vide o exemplo do sistema eyeOs (EYEOS, 2009). O acesso a estas ferramentas não é dependente de tecnologias específicas presentes na máquina cliente, ou seja, não e necessário baixar nenhum pacote, nem instalar software no cliente, o que cria uma nova perspectiva para o desenvolvimento e programação de aplicações web. Esta nova experiência torna a web um ambiente cada vez mais parecido com o desktop do usuário, abrindo uma nova visão sobre interfaces de comunicação com o usuário. A web como plataforma é um assunto especialmente tratado nas seções seguintes que tratam de computação nas nuvens. 2.6.

Computação nas nuvens e suas tecnologias Computação nas nuvens, do inglês cloud computing, é uma arquitetura e um

paradigma com definições em aberto que está sendo amplamente discutido no cenário global da computação. Institutos de pesquisa como o IDC BRASIL (IDC BRASIL, 2009) e o Gartner (GARTNER, 2009) revelam números de crescimento cada vez maiores para a tendência da computação nas nuvens (COMPUTER WORLD, 2009). Uma previsão feita pelo Gartner revela que os gastos com computação nas nuvens devem ultrapassar os 56 bi no ano de 2009 (COMPUTER WORLD, 2009). 19

Ao contrário de qualquer tendência criada recentemente no cenário da tecnologia da informação para introduzir um conceito totalmente novo ou sem grande histórico de pesquisas realizadas, computação nas nuvens é um passo natural na evolução da computação distribuída, serviços de software e principalmente virtualização (MLADEN,2008). Como aspecto fundamental da computação nas nuvens, virtualização é o conceito que se refere a abstração dos recursos de hardware e software que permite alocá-los e requisitálos de forma flexível. (SUN, 2009) Computação nas nuvens, como arquitetura, é um novo modelo de estrutura da computação, onde armazenamento, aplicativos e processamento são acumulados em servidores com alto desempenho, ligados à redes de alta velocidade e o acessados pelo cliente de forma remota (HP, 2009). Em suma, a arquitetura nas nuvens prevê que recursos de hardware e software possam existir remotamente havendo deslocamento geográfico da computação. (HAYES, 2009) Em termos de Gestão de TI, computação nas nuvens é um tema explorado pelas maiores empresas da área no mundo, e uma aposta de vários CIOs que vem nela uma forma eliminar uma camada de complexidade da organização e se concentrar na criação de outros valores (MENDES, 2009). 2.6.1. As camadas arquiteturais de serviços Como dito, computação nas nuvens impacta em muitos aspectos, tanto na questão de hardware como em software, envolvendo diversas partes e departamentos de tecnologia da informação (INFO PROFESSIONAL, 2009). Na questão de arquitetura, pode-se ver que a computação nas nuvens se divide em três camadas de serviços. A mais baixa é a camada de hardware, onde existem os dispositivos de armazenamento, processamento, redes e servidores que disponibilizam a base para que aconteça a computação nas nuvens. Acima desta há a camada de plataforma, a base para os aplicativos e que oferece soluções adaptadas a cada negócio. Pode-se comparar, no atual modelo, essa base ao sistema operacional desktop. A terceira camada é a mais próxima do usuário, é nela onde acontece de fato o uso dos aplicativos, geração de aplicações híbridas, 20

misturando fontes para gerir um só aplicativo de acordo com a necessidade do negócio e do usuário (CAPGEMINI e HP, 2009). 2.6.2. Computação sob demanda (ou on-demand computing) Computação sob demanda, On-Demand Computing e Utility Computing são termos relacionados ao uso de recursos a medida do necessário, pagando-se por utilização. É semelhante ao que se faz hoje com outros serviços como gás, luz e água (TURBAN, 2005). Utility computing é uma forma de negócio em crescimento,

adotada por muitas

empresas, seja no oferecimento de serviços de hardware, como a Amazon EC2 (AMAZON, 2009), de software como serviço como a SalesForce (SALESFORCE, 2009) ou plataforma como Azure da Microsoft , Open Cloud da Sun ou o Goggle App Engine da Google (GOOGLE, 2009). Todas estas plataformas fazem uso de Utility Computing (HENSCHEN -INFORMATION WEEK, 2009) . O surgimento da computação nas nuvens esteve fortemente relacionado a necessidade de negócios on-demand, pois praticamente todos os recursos de TI podem ser vendidos como serviços (SUN, 2009). Pode-se dividir os serviços em três camadas de disponibilidade que serão melhor abordadas nas seções a seguir. 2.6.3. IaaS – Infraestrutura como serviço IaaS, do inglês Infraestructure as a Service, ou infraestrutura como serviço, trata-se do oferecimento de recursos de TI relacionados a Hardware como um serviço on-demand. Ao contrário do cliente comprar grandes plataformas de servidores, ou montar Data Centers corporativos, ela paga pelo uso desses recursos de acordo com sua necessidade (BLUELOCK , 2006 ). Duas grandes ofertas de Iass atualmente se destinam a armazenamento e processamento, onde o custo de uso dos serviços é medido de acordo com a quantidade de uso dos mesmos. 21

As empresas oferecedoras desses serviços possuem uma uma grande quantidade de dispositivos de hardware de alta potência de processamento e armazenamento operando como somente um serviço para o cliente. Isso é possível através de níveis de virtualização dos recursos, sendo que os mesmos são liberados de acordo com a necessidade de uso .(SUN, 2009). Esse tipo de serviço atualmente é oferecido pela Amazon com o nome de EC2, mas muitas empresas estão montando sua infra-estrutura para o oferecimento de IaaS (HENSCHEN -INFORMATION WEEK, 2009). Os resultados do uso de IaaS são rápidos e muito vantajosos. Empresas quando tem pico de demanda de trabalho e não precisam mais atualizar o seu hardware para o pico, podem disponibilizar comercialmente seus recursos nas nuvens (MENDES,2009). Esse conceito é o que chamamos de elasticidade, permitindo que qualquer um tenha um supercomputador instantaneamente (COMPUTER WORLD EXECUTIVE BRIEFING, 2009). 2.6.4. PaaS – Plataforma como serviço PaaS, do inglês Platform as a Service, ou Plataforma como serviço, é a camada arquitetural intermediária e trata do oferecimento de sistemas web para desenvolvimento de aplicações, que provê ao desenvolvedor ambientes completos de desenvolvimento, acompanhando as várias etapas do desenvolvimento da edição de código a manutenção e fácil escalabilidade (SUN, 2009). No PaaS, o sistema fornece o ambiente contendo a API (interface para programação de aplicativos, que promove extensibilidade de um sistema) de desenvolvimento com funcionalidades base embutidas, a serem usadas on demand, a medida em que são requisitadas. O sistema web que provê a plataforma se torna encarregado de determinar comportamento da aplicação em diferentes sistemas operacionais, lidar com linguagem de programação e acesso a recursos específicos eliminando do desenvolvedor a tarefa de decidir sobre estas particularidades (IEEE - LAWTON, 2009). 2.6.5. SaaS – Software como serviço 22

Saas, do inglês Software as a Service ou Software como Serviço, representa a terceira camada da computação nas nuvens, onde usa-se o recurso da plataforma para construir os aplicativos. São aplicações que rodam em servidores web e são acessados via internet e que têm sido um grande atrativo, principalmente para a área de negócios (DEITEL, 2009). Essa idéia pode ser encontrada com várias nomenclaturas, mas todas estão apontando para um mesmo conceito. Muitos analistas acreditam que esse modelo, impulsionado pela onda da internet, irá extinguir o software empacotado. SaaS atinge com impacto todos os lados da industria de software (SIIA, 2009). Atualmente, tem crescido muito e está sendo aderido por muitas empresas, incialmente as pequenas e médias, mas muitas grandes empresas estão aderindo ao modelo (OPSOURCE, 2009). O instituto Gartner apresentou recentemente uma pesquisa dizendo que 5 bilhões globais foram movimentados em 2006 e Saas tem apresentado crescimento anual de 30% (NAVISITE, 2009). Diversas caracteristicas abrangem o conceito de Saas: a) O software é entregue sob demanda (on demand) , ou seja, você paga pelo quanto usou, e não mais por uma licença vitalícia. b) O usuário não precisa mais se preocupar com a manutenção de software e hardware. c) Fim da cultura de retalhos de softwares, pacotes de atualização. d) O Usuário só se preocupa com as partes básicas de hardware, o vendedor do software se encarrega dos requistos de software (OPSOURCE, 2009). e) O software oferecido na web como serviço se parece muito com aplicações desktop (que rodam inteiramente na máquina cliente) , com a exibição de elementosantes presentes apenas nos dos softwares offline. O SaaS apresenta muitas vantagens em relação ao atual modelo de software empacotado, alguma diretamente ligadas a definição, outras mais implícitas, mas que fazem que o software como serviço seja uma tendência dominadora sem volta. Ao usuário final destacam-se as seguintes vantagens (NAVISITE, 2009):

23

a) Baixo custo com tecnologia e atualização de hardware: O hardware para softwares empacotados é mais exigente e replicado a cada ponto onde se deseja realizar o acesso. b) O software como serviço oferece menos custos nesse sentido pelo processamento ser centralizado. c) Software global: Saas pode ser acessado em qualquer lugar, em qualquer dispositivo que tenha acesso a internet (COMPUTER WORLD, 2009) . d) Facilidade de implantação: Grandes empresas olham para SaaS como uma solução rápida no questão de implantação em determinados setores, não necessitando de uma equipe especializada de TI para realizar esta operação. e) Escalabilidade: SaaS acompanha o crescimento das empresas, uma vez que com o espalhamento geográfico não haverá a necessidade de adaptação e implantação, pois será necessário somente aumentar a funcionalidade do SaaS utilizado. f) Monitoramento e gerenciamento 24/7: Com o crescimento do negócio no modelo atual, aumenta o nível de monitoramento e gerenciamento do mesmo. Com SaaS esse monitoramento e gerenciamento são realizados pela empresa que oferece o serviço. g) Segurança: Muitas empresas, principalmente as pequenas e médias, muitas vezes não tem capacidades de garantir a integridade e a segurança do software. No modelo de software como serviço essa segurança é centralizada, sendo de responsabilidade da empresa que oferece os serviço (NAVISITE, 2009). As tecnologias envolvidas no desenvolvimento de SaaS no lado cliente são basicamente javascript e HTML (Hyper Text Markup Language) . O banco de dados tem a sua linguagem nativa de SQL (Structured Query Language) e no servidor de aplicação, entre o cliente e o banco de dados existe a maior variação de linguagem como java (SUN, 2009) , python (PYTHON, 2009) , php (PHP, 2009) e outras (HAYES,2009). Essas tecnologias serão discutidas detalhadamente nas seções seguintes sobre serviços web. 2.6.6. Um manifesto para uma nuvem aberta (Open cloud manifesto) Com a intenção de garantir o acesso de todos aos recursos de computação na nuvens e garantir que esses recursos sejam abertos, foi proposto e aceito recentemente o Cloud Computing Manifesto (Manifesto pela computação nas nuvens) , com o apoio de grandes instituições . 24

O objetivo do documento não é propor novos padrões e nem uma análise sobre arquitetura, mas sim propor uma discussão, ainda que cedo, sobre os princípios da computação nas nuvens livre.(OPEN CLOUD MANIFESTO,2009) 2.6.6.1. Objetivos do manifesto Alguns objetivos foram levantados no documento afim de mostrar o que será feito num modelo de livre de computação nas nuvens, são eles: a) Escolhas: A escolha de modelo e arquitetura tem que ser livre e simples para que as empresas possam se adaptar a diferentes demandas e novas parcerias. Os custos aplicados numa migração/adaptação podem ser aplicados em inovações; b) Flexibilidade: Independente da arquitetura ou do vendedor do serviço de computação na nuvens, a nuvem livre fará com que as operações possam ser realizadas com qualquer provedor de serviço; c) Velocidade e agilidade: Os recursos de software e hardware podem ser alocados de acordo com a necessidade do cliente. A computação nas nuvens livre deverá prever serviços ágeis e rápidos mesmo com uma alocação dinâmica de recursos; d) Habilidades estimuladas: Uma carência que o estouro da bolha da web 2.0 trouxe é a falta de profissionais habilidosos para determinadas tecnologias se estas forem fechadas, proprietárias. Como acredita-se no manifesto, a abertura da nuvem aumentas as chances das empresas

encontrarem

profissionais

eficientes

e

criativos

(OPEN

CLOUD

MANIFESTO,2009 ). 25

2.6.6.2. A perspectiva SAP sobre o manifesto Na rede de desenvolvedores SAP houve uma preocupação especial sobre o manifesto, levantada por Vishal Sikka (VISHAL, 2009). Alguns outros objetivos foram levantados: a) Portabilidade de dados e de aplicativos: Sem padrões comuns, as formas de comunicação serão limitadas por bases privadas, fazendo com que uma migração se torne cara e lenta; b) Governança e gerenciamento: Com o crescimento de sistemas nas nuvens, um desafio que surgirá será relacionado ao gerenciamento e a governança de assuntos ligados a computação na nuvens; c) Medição e monitoramento: Os líderes de negócios utilizarão diversos vendedores de serviços para seus objetivos, consequentemente, serviços de monitoramento de desempenho serão necessários. As empresas de serviço deverão adotar um meio comum para garantir que esses serviços aconteçam (SAP SDN WIKI,2009). 2.6.6.3. Princípios para uma nuvem aberta O manifesto sugere pontos chaves para garantir a sustentabilidade conforme o crescimento do modelo de negócios nas nuvens, são estes: a) Vendedores de serviços precisam trabalhar juntos paras para garantir que pontos importantes na adoção da computação nas nuvens estejam crescendo da colaboração e do uso dos padrões existentes; b) Não usar posição de mercado para "segurar" clientes em suas plataformas e limitar as suas escolhas; c) Sempre adotar padrões existentes. Ajuda na padronização geral e elimina custo. Aderindo a corrente de pensamento que diz que não há motivo de investir em padrões 26

novos se alguém, ou um grupo de pessoas já investiu muito para construir um padrão aberto; d) Padrões novos tem que ser analisados de forma rígida para garantir que estes realmente sejam inovadores e um passo a frente, não inibidores do avanço; e) Todos os esforços da comunidade devem ser direcionados para solucionar problemas do cliente. Verificações sobre os ajustes, modificações deverão ser feitas para garantir que o cliente será beneficiado; f) Padrões, grupos de advocacia e as comunidades devem trabalhar juntos evitando divergência e conflito (SAP SDN WIKI, 2009). 2.6.7. A computação nas nuvens e as suas tecnologias Sendo computação nas nuvens um conceito inseparável da internet, suas tecnologias são as predominantes na web atualmente. 2.6.7.1. HTML HTML, do inglês Hyper Text Markup Language, é a linguagem de marcação utilizada para a construção de páginas para a internet. Códigos escritos em HTML são interpretados pelos navegadores. O HTML nasceu das linguagens HyTime e SGML (W3C, 2009). A montagem de um documento HTML é feita através de etiquetas (tags), que são delimitadas por “” (sinal de menor e maior) . A figura 2 exibe um exemplo de código para página HTML:

Figura 2 Exemplo de código em linguagem de marcação HTML

Com a evolução do HTML nascerão novos tipos de HTML, dois principais são: 27

a) XHTML: eXtended HTML é uma extensão de HTML com uma sintaxe mais rigorosa baseada em XML. Em termos de código, a escrita de XHTML é mais rigorosa e limpa do que HTML (W3SCHOOLS, 2009). b) DHTML – Dynamic HTML. Não é uma linguagem e nem uma especificação, mas de acordo com W3C: O “DHTML é um termo usado por alguns vendedores para descrever a combinação de HTML como folhas de estilo e scripts que permitem os documentos serem animados” (W3SCHOOLS, 2009). De forma geral, DHTML é a combinação de HTML com AJAX, que será abordado a seguir. 2.6.7.2. Folhas de Estilo CSS Documentos HTML simplesmente definem os elementos com as etiquetas, gerando parágrafos, botões e demais elementos. CSS do inglês Cascading Style Sheet é a parte de uma página que permite que desenvolvedores controlem o estilo do documento. Antes do CSS todos os controles de uma página eram feitos através dos atributos das etiquetas, como “color” na etiqueta “”. O código de estilo pode estar dentro do documento ou em arquivos separados. A sintaxe do CSS é simples: elemento { propriedade: valor } (W3SCHOOLS, 2009) A figura 3 mostra um exemplo de uso:

Figura 3 Exemplo de folha de estilos CSS

2.6.7.3. Javascript

28

Javascript é uma linguagem de script orientada a objeto criada pela Netscape e usada em milhões de página web. Além de interpretada, Javascript pode ser procedural ou orientada a objeto sendo executada no lado do cliente (MOZILLA DEVELOPER CENTER, 2009) . Assim como CSS, javascript pode ser incorporado em páginas HTML através das etiquetas “” ou em arquivos externos, ligados a página, através do atributo “src” da etiqueta “” . O uso de Javascript é livre, qualquer um pode usar sem ter uma licença. (W3SCHOOLS, 2009).A figura 4 mostra uma função simples construída com javascript puro:

Figura 4 Um exemplo simples de Javascript, como saída este código exibe uma janela com a mensagem "Olá mundo, mashups são legais".

2.6.7.4. AJAX AJAX( Assyncronous Javascript and XML) não é uma tecnologia isolada, mas sim um uso de tecnologias já existentes como javascript e XML. AJAX tem como característica o uso de XHTML com CSS na apresentação, uso de DOM (Document Object Model) para a interação e resposta com o usuário, XML entre a troca de dados, requisições assíncronas e javascript como a linguagem que une e realiza todas essas tecnologias (AJAXPATTERNS , 2009). Com essa tecnologia, não é necessário carregar a página inteiramente a cada interação do usuário, mas sim em partes, pois é baseado em requisições feitas através do protocolo HTTP (W3SHOOLS ,2009).

29

Algumas bibliotecas e frameworks foram criados para facilitar a escrita de código que implementasse AJAX, permitindo melhor acesso a elementos e muitos pontos prontos: a) JQuery: JQuery é uma biblioteca Javascript de código aberto e com licença livre criada por John Resign da Mozilla Foundation. Seu principal foco, segundo o próprio criador é a simplicidade (BIBEAULT, 2009) . É possível escrever códigos com a biblioteca JQuery sem ter conhecimentos profundos de Javascript. Enquanto com Javascript códigos confusos e ilegíveis eram criados para acessar os componentes de uma página e manipulá-los, JQuery trouxe a elegância e visibilidade com a simples manipulação dos componentes do documento e a possibilidade de, com poucas linhas, realizar grandes feitos (SAMY,2008) . Outra vantagem é a possibilidade de manipular mais de um componente com somente uma linha de código, JQuery contém métodos prontos para acesso aos elementos filhos de um determinado nó do documento (podemos entender como nó todo ponto gerado por uma tag como ). Uma outra capacidade incrível é a de encadear o elemento, com isso com uma linha faz-se o que seria feito com muitas em Javascript. (WELLMAN, 2009). Abaixo, um exemplo de acesso a um único nó com Javascript, logo em seguida com Jquery (JQUERY,2009) : Javascript: document.getElementById(“nome”).PROPRIEDADE Sendo que para acessar mais de um nó é necessário manipular o vetor que é retornado pela função. JQUERY: $(“id do nó, estilo ou nome do elemento”).propriedade(“valor”); Conforme visto, JQuery facilita muito o desenvolvimento de página HTML dinâmicas, possibilitando o acesso aos componentes de forma simples. 30

b) Dojo Dojo é um kit de ferramentas Javascript para construção de grandes aplicações web. Além de rápido e sólido, possui um conjunto de ferramentas para manipulação DOM. Dojo é completamente livre (isto é, de código aberto, além de ser livre de taxas para utilização). Além de todos os métodos e funções presentes na biblioteca padrão, Dojo ainda prevê a inclusão de outros adicionais com ferramentas especificas para sua necessidade. Podemos carregar esses adicionais dinamicamente no nosso projeto. Um desses adicionais, o adicional Dijit, que vem com a biblioteca padrão, permite que você construa seus próprios elementos de interface (SITEPEN, 2009). Conforme visto, Dojo é uma biblioteca de grande apoio a desenvolvimento de grandes sites por possuir elementos prontos. c) Scriptacoulous Scriptacolous é uma biblioteca javascript voltada para a apresentação. Contém diversos efeitos prontos para serem aplicados aos componentes contidos na página principal. Junto com o uso de scriptacolous, carregasse a prototype, que é utilizada por ele. Scriptacolous pode ser carregado em módulos, ou seja, não é preciso alterar o sistema de arquivos para ter uma ou outra biblioteca adicionada a página (GITHUB, 2009). Uma das vantagens de scriptacolous é sua integração com o famoso Rails (framework escrito na linguagem Ruby), onde existe uma facilidade no uso da biblioteca no meio do código Ruby (DEITEL, 2008). Scriptacolous é um biblioteca especifica para uso na interface com o usuário, focando nesse ponto.

d) YUI YUI (Yahoo! User Interface) é um conjunto de ferramentas e utilitários para construção de páginas web dinâmicas. Contém componentes para solucionar problemas em diversos aspectos, desde um simples efeito de arrastar componentes até editores de texto prontos para 31

serem incorporados a página. É mantido pelo Yahoo! (YAHOO!, 2009) E tem uma forte comunidade associada (YUI LIBRARY, 2009). YUI é uma biblioteca muito completa para a construção de sites, ao contrário das anteriores, onde cada uma focou um ponto, YUI mostra uma visão geral para a construção de aplicativos. 2.6.8. Tecnologias do lado servidor No lado servidor, as tecnologias utilizadas são as clássicas atualmente, como JSP,Python, PHP, ASP e outras. A comunicação entre as camadas são feitas através de XML, na forma de serviços em muitas das vezes, isso faz com que o que é escrito no lado servidor fique oculto, não sendo visível a quem requisita um serviço. 2.6.9. RESTful REST acrônimo de Representational State Transfer, é um estilo de arquitetura de software para mídias distribuídas como o WWW (World Wide Web). O termo Representational State Transfer foi apresentado e definido por Roy Fielding em 2000 na sua tese de doutorado (FIELDING, 2000). O funcionamento é basicamente uma arquitetura cliente servidor, onde os clientes fazem requisições para o servidor. O servidor trata essas requisições e devolve uma resposta adequada a requisição. A requisição e a resposta são o que representações de um recurso. Recurso é basicamente tudo que contém um endereço para acesso (FIELDING, 2000). Uma aplicação cliente deve conhecer o endereço do recurso, não necessariamente conhecendo os detalhes do oferecimento do recursos pelo servidor e/ou como o servidor trata a requisição. O cliente deve conhecer simplesmente o endereço da requisição e o formato de retorno pelo servidor (XML, JSON ou outros) . O mesmo recurso pode receber um número infinito de requisições e diversos cliente podem acessá-lo.

32

Um recurso deve ter um conjunto de operações bem definidas e uma sintaxe bem definida para acesso a eles. No protocolo HTTP usamos as operações POST, GET, DELETE e PUT e os recursos são identificados através de URL. A figura 5, a seguir, esclarece um pouco mais sobre RESTful:

Figura 5 Diagrama REST

Usos de REST: Um uso conhecido e bastante difundido atualmente de RESTful são os acessos a blogs e suas mensagens, onde cada post pode ser acessado através de alimentadores no formato RSS ou ATOM. (INFOWESTER, 2009). Grandes provedores de serviços, como a Google e Yahoo! oferecem parte de seus serviços em RESTful. O Twitter (TWITTER, 2009) , microblog muito utilizado atualmente, deve parte de seu sucesso em de sua API baseada em RESTful. Muitas tecnologias contém recursos para que desenvolvedores possam construir suas próprias aplicações usando REST, Java, por exemplo, contém uma especificação para implementação sobre a programação da arquitetura REST (JAVA, 2009). Na próxima seção chamada Serviços Web temos um detalhamento maior da arquitetura orientada a serviço e de suas características. 33

2.7.

Serviços web Serviços web ou “web services” é um termo usado para se referir a qualquer serviço de

software disponível na internet que usa XML como linguagem padrão para troca de mensagens e cujo uso não depende de plataformas ou linguagens de programação específicas (CERAMI, 2002). Serviços web provêem funcionalidades de integração entre sistemas, e comunicação não dependente de software, hardware ou mesmo linguagem de programação usando uma rede específica (na maioria dos casos, a internet) (BRAUER, 2008) Pode-se descrever um serviço web pela junção de várias características, como: a) Promover reusabilidade de código e aproveitamento de componentes: Com a disponibilização de serviços web muitas implementações comuns e recorrentes não precisam ser reescritas para cada nova aplicação, utilizando-se nesses casos um serviço web já disponível e que pode ser encontrado na internet (W3SCHOOLS, 2009); b) Independência de sistema operacional e linguagem de programação: Do lado cliente, tudo que é necessário para se acessar um serviço web é suporte a XML e a um protocolo de envio e recebimento de mensagens (ECLIPSE FOUNDATION

,

2009); A figura 6 a seguir ilustra esta independência:

Figura 6 Serviços web possibilitam o trafego de requisições entre sistemas operacionais diferentes.

34

c) Serviços web são auto descritivos: Toda a meta informação fica contida no próprio serviço.Especificações de tipo mensagens trafegam junto com o código do serviço dispensando que ferramentas sejam instaladas no lado cliente (ECLIPSE FOUNDATION, 2009); d) Serviços web podem ser combinados: Essa combinação gera novas aplicações online com o mínimo de programação, algumas vezes até mesmo sem a necessidade de escrever uma linha de código (veja a seção 2.4 Mashups); e) Todos os serviços web são disponíveis em servidores e acessados através de chamadas remotas de método: Basicamente isso significa dizer que qualquer método em aplicação web pode chamar um serviço web esperando assim uma resposta pertinente e legível para a aplicação do lado cliente (DEITEL, 2009). 2.7.1. SOA – Arquitetura orientada à serviços SOA do inglês Service Oriented Architeture ou Arquitetura Orientada a Serviços é uma especificação para arquitetura de software que visa disponibilizar as funcionalidades das aplicações em forma de serviços auto descritivos e padronizada por contratos formais baseando-se nos princípios da computação distribuída (TANEMBAUM, 2009) Além disso, SOA é dentro de uma empresa de TI, uma estratégia de negócios que pode mostrar diversos pontos positivos e vantagens competitivas. ( UOL, 2009 ) Dentro deste ponto de vista empresarial SOA pode ser entendida como um pacote de serviços que provê diversos princípios arquiteturais e

padronização como, por exemplo: modularidade,

encapsulamento e reuso. (IBM, 2009) SOA é uma evolução natural da arquitetura de software proposta como solução para que haja baixo acoplamento nas aplicações (referente a capacidade de criar módulos independentes de aplicações)(AQUELE BLOG DE SOA, 2009). 35

2.7.2. SOAP – Um contrato formal para acesso Cada serviço, entendido como módulo de aplicação, deve possuir contratos formais, uma série de documentos que descrevem propósito e funcionalidade deste serviço.Estes contratos tornam os serviços mais fáceis de serem encontrados e reutiizados (AQUELE BLOG DE SOA, O que é SOA, 2009). SOAP, do inglês Simple Object Access Protocol ou Protocolo Simples de acesso a objetos é um contrato formal de SOA, um protocolo para comunicação (transferência de mensagens) entre serviços baseado em XML, independente de plataforma e seguindo as especificações da W3C (W3C, 2009). Para Serviços Web, SOAP define como melhor protocolo de comunicação o HTTP (Hyper Text Transfer Protocol), já que este pode ser lido por qualquer navegador internet. SOAP visa facilitar as chamadas remotas feitas por clientes de serviços web e estes serviços. Quando uma requisição é feita, a mensagem SOAP é empacotada, enviada ao servidor onde se encontra o serviço web requisitado, que analisa esta mensagem extraindo os argumentos e métodos que ele deseja utilizar, e retorna uma nova mensagem SOAP ao cliente (DEITEL, 2009). As mensagens SOAP são compostas por blocos de Cabeçalho (header) e Corpo (body), o cabeçalho pode incluir diversos blocos de cabeçalho, ou nenhum carregando informações específicas das aplicações (por exemplo, autenticação) enquanto o corpo da mensagem é obrigatório e contém informações a serem lidas no servidor incluindo argumentos passados aos serviços. A figura abaixo ilustra uma transferência de mensagens SOAP:

36

Figura 7 Exemplo de tráfego de mensagens SOAP para uma transação bancária.

2.7.3. WSDL – Um contrato formal para descrição Web Services Description Language, em português Linguagem de Descrição para Serviços web, como o nome sugere é uma especificação sobre a estrutura de um documento XML descritor de um serviço web e um padrão reconhecido pela W3C e proposto pelas empresas: Ariba, IBM e Microsoft (W3C, 2009). A melhor forma de entender essa linguagem é analisando os componentes que a formam, descritos na figura 8:

37

Figura 8 Um exemplo comentado sobre a estrutura de um WSDL

Algumas informações presentes na figura 8: a) Define quais os tipos de dados usados no serviço web, com a sintaxe do XML Schema ( XML Schema é uma linguagem descritora de XML). b) Representa uma definição dos dados a serem transmitidos, divididos em partes lógicas, cada uma delas associada a um tipo. c) É considerado o elemento mais importante do WSDL, representando as operações (como funções ou métodos) que podem ser requisitados. d) Define os protocolos e suas portas específicas. e) Especifica a localização real do serviço. Muitos destes componentes podem ser relacionados a namespaces específicos, cada namespace é composto de um prefixo e uma URI, por exemplo, wsdl é uma prefixo que referencia a URI (XML SCHEMA,2009) . 2.7.4. UDDI – Um contrato formal para descoberta e descrição

38

UDDI, do inglês Universal Description, Discovery, and Integration ou Descrição Universal, Descoberta e integração é o contrato formal que define um padrão XML para que os serviços sejam reutilizáveis provendo um mecanismo que facilita a a publicação e a busca por serviços. O protocolo UDDI foi reconhecido como padrão pela OASIS e o seu serviço de registros consiste em um grupo de serviços web com a finalidade de representar metadata de serviços através de um padrão que permite criar catálogos e classificações destes. A metadata (informação que explica a informação) contida no registro de um serviço por UDDI incluí ,entre outras informações, informação sobre a organização que está publicando o serviço, detalhes técnicos relevantes como especificações de determinada API, além de metadatas variadas como assinaturas digitais (XML.ORG, 2009). Para descrição das interfaces de serviços , o UDDI usa o WSDL (já discutido em subseção anterior) como padrão. 2.7.5. A visão estratégica de SOA Como já dito anteriormente, serviços de software possuem grande impacto nas estratégias de uma grande empresa, esse quadro não é diferente com serviços web e as transações Bussiness-to-Bussiness (KRISHNAMURTHY, 2009). Empresas grandes como Google, Amazon, eBay e outras grandes estão disponibilizando seus serviços para uso por parceiros de negócio, o valor que isso agrega aos negócios permite que menos tempo seja gasto com desenvolvimento e mais tempo seja gasto com inovação nos produtos (DEITEL, 2009) . Muitas empresas podem ver serviços web como ferramenta de integração de aplicações internas, porém o encapsulamento de funcionalidades necessárias aos negócios em serviços pode tornar tais funcionalidades muito mais legíveis para reuso, e são aceitas como aplicações confiávies e seguras (SEYBOLD, 2009). 2.7.6. Misturando serviços 39

Uma aplicação pode consumir mais de um serviço ao mesmo tempo, criando, muitas vezes com editores visuais e sem linhas de código aplicações customizadas e novas. Ferramentas como o Yahoo! Pipes (YAHOO! PIPES, 2009) disponibilizam recursos para que várias fontes RSS sejam usadas sob a mesma interface de criação. Graças ao SOA, pode-se combinar na mesma aplicação diversos serviços, criando mashups, tema central deste trabalho e que será melhor discutido na próxima seção chamada Mashups . 2.8.

Mashups Com a explosão dos dados na web, a maior dificuldade para o desenvolvedor é saber

utilizar os mesmos, e não se enganar achando estar fazendo algo novo, quando na verdade se está reinventando a roda. Com essa intenção foram criadas diversas novas formas de aplicações que visam o uso corretos dos dados e funcionalidades disponíveis na web. Essas novas formas de aplicativos e construção de aplicativos foram trazidas na web 2.0 (O’REILLY, 2005 ). Mashup é o resultado da evolução da internet. Novas aplicações podem ser criadas com facilidade utilizando o que há de pronto na web (YEE, 2008). Mashups são aplicativos híbridos cujo conteúdo é composto por uma ou mais fonte de dados.O termo Mashup foi adaptado da música pop, que significa uma música com diversas fontes misturadas e re-misturadas (YEE, 2008). Nasceu da necessidade de unir a quantidade de informações na web e reaproveitar algumas fontes prontas, como os mapas do google, ou as imagens do Flickr. Mashups propõe aplicações para usuários comuns e empresas (MASTER NEW MEDIA,2009). Novas aplicações são criadas com o uso de fontes já existentes. O Housingmaps.com (HOUSINGMAPS, 2009) , por exemplo, reúne dados imobiliários do site Craigslist.org 40

(CRAIGLIST, 2009) e mapas do maps.google.com (GOOGLE, 2009). O aplicativo gerado não é de autoria do Google e nem da Craiglist, mas sim do desenvolvedor, pois se trata de um aplicativo separado (YEE, 2008). 2.8.1. As diversas classes de mashups Mashups dividem-se em classes de uso, são elas: a) Vídeo e Foto: Através de geotaggings (tags com informações geográficas), é possível, com as API’s oferecidas

reunir conteúdos de sites que oferecem mídia social

(PROGRAMMABLE WEB, 2009); b) Mapeamento: É uma das classes mais famosas e uma das mais usadas API’S são de mapas (PROGRAMMABLE WEB, 2009) . Transformar a visualização de fotos em algo mais completo e sofisticado com mapa foi já foi proporcionado pelo mashup GMiF (YUAN.CC, 2009) proporcionou antes da existência desse recurso no Flickr (YEE, 2008) ; c) Compras e pesquisas: Essas classes são as mais antigas, existem antes do termo Mashup vir a tona. Para facilitar a incorporação de dados em outros sites, grandes empresas ofereciam API’s. d) Notícias: Grandes sites de notícias oferecem acesso a seu conteúdo através de RSS e ATOM, o que permite que aplicações hibridas sejam geradas por terceiros. 2.8.2. Arquitetura para Mashups Existem duas formas para definição da arquitetura de mashups: Baseados em web, e baseados em serviços, mas as duas rodam normalmente em um navegador da internet. A arquitetura baseadas em serviços é baseada em serviços web para a geração da aplicações híbridas, sendo que a arquitetura em si é baseada em serviços (SOA). Arquitetura baseadas em web são aquelas que utilizamos fontes na web de diversos lugares e buscamos os dados através da varredura do DOM página, ou através de alimentadores. É menos elegante que as soluções orientadas a serviços, pois não há um padrão de captura dos dados em muitas vezes. (LESSIG, 2009) 41

As duas arquiteturas têm três camadas (partes envolvidas): a) Oferecedor de serviço: São da onde retiram-se os dados pertencentes a mashup. Essa transição de dados pode ser feito utilizando protocolos como REST ou SOAP, RSS, ou varredura da página. b) Página da mashup: é onde está o resultado da união dos dados, o local a ser acessado para utilização da aplicação hibrida, ou o código para ser rodado no lado cliente como Flash (ADOBE, 2009) , Applets e AJAX (RIA , Rich Internet Applications, refere-se a aplicações online com comportamento e responsividade de aplicações offline). c) Navegador do cliente: Onde são montados os dados, onde o acesso será feito. O local que se aplica a lógica para a utilização da Mashup (IBM, 2009) 2.8.3. Como construir uma mashup Para a construção de mashups existem 5 passos importantes que ajudam quando não se sabe por onde começar e garantir a consistência geral durante o processo de criação e finalização do mesmo, estes passos são: a) Escolher um tema: Escolha um tem bem definido para sua Mashup e esboce o quais recursos ele deverá oferecer como fotos, vídeos e etc. Quanto mais claro for o tema, melhor será o andamento da construção. Dúvidas sobre tema devem surgir e desaparecer no início do projeto. b) Definir fonte(s) de dados: Com a definição clara do que se deve fazer, é hora de procurar fonte(s) de dados. A definição neste ponto da fonte de dados é importante, pois outros passos dependerão de como será a troca de informação (REST, SOAP, RSS, etc...). Procurar sempre por fontes confiáveis e bastante usadas é importante para garantir que futuramente o sistema não páre. c) Definir habilidades de programação: Este é o momento de definir a parte técnica,

os

aspectos ligados a programação em si. Embora existam ferramentas que praticamente extinguem o uso de programação, a presença da programação se faz necessária principalmente quando temos API’S com protocolos não muito conhecidos, que dependem de uma solução especial para a comunicação com a mashup. Levantar a quantidade de programação e quão importante está deverá ser, embora pareça simples se revela um processo a ser criterioso do desenvolvimento já que algumas API’S exigem mais complexidade na extração de dados. 42

d) Definir a linguagem usada: É importante colocar na mesa as linguagens de domínio do desenvolvedor e escolher qual deverá ser a mais apropriada, caso esse passo não seja seguido da forma correta, ou

podem ocorrer limitações da linguagem escolhida

futuramente no projeto. e) Cadastrar-se no uso das API’s: muitas API’s necessitam de login para acesso, ou um ID para cada acesso a API. Muito importante liberar as questões de acesso antecipadamente para que na aplicação já haja algo prevendo como será feito cada acesso a API envolvida. f) Iniciar a codificação: aqui começa a construção da mashup: É importante estar por dentro de todos as tecnologias envolvidas no processo, tendo um amplo domínio de todos os processos envolvidos na mashup. Caso não haja uma familiaridade com programação por parte dos interessados na construção de mashups,existem ferramentas voltadas para a construção dos mesmos sem conhecimento de protocolos de API’s e nem mesmo de programaçãoAlgumas dessa ferramentas são do tipo WYSIWYG( What You See Is What You Get), que propõe a criação de mashups de forma mais simples e ágil (ATPM, 2009). Uma maior análise de ferramentas para criação de mashups estará detalhada no próximo capítulo desse trabalho.

43

3.

ANÁLISE DE EDITORES DE MASHUPS NA WEB Neste capítulo será apresentada uma análise de algumas ferramentas existentes para

criação e edição de mashups e as suas peculiaridades.Dentre os editores de mashups disponíveis foram selecionados o Open Mashup Studio (3.1), IBM Mashups Center (3.2) e Yahoo! Pipes (3.3). O uso de um editor de mashups permite a composição de soluções inteiramente novas em pouco tempo de implementação, reduzindo o trabalho do desenvolvedor que pode focar cada vez mais na idéia sem ter que refazer o que já foi feito, como discutimos no seção 2.3 sobre serviços web.Todos esses editores possuem versões gratuitas para serem usadas, além uma vasta documentação de suporte. Estas ferramentas foram escolhidas por possuírem características similares, como: serem independentes de sistema operacional, serem ferramentas de uso gratuito (à exceção do IBM Mashups Center, por ter uma vocação empresarial) e número considerável de aplicações criadas e comunidade de usuários.O uso e estudo destas ferramentas foi um guia no processo de modelagem da ferramenta proposta neste trabalho e na busca de inovações. A utilização de um destes editores de mashup proporciona criação, edição e publicação de aplicações híbridas totalmente novas ou edição de fontes de dados existentes em pouquíssimo tempo e com poucas (ou nenhuma!) linha de código. Nos casos em que foi necessário, empregou-se como ambiente de testes os navegadores Mozilla Firefox 3.0.10 e o Internet Explorer, responsáveis pela maior parte da navegação feita na web atualmente. Este capítulo está dividido como segue: A seção 3.1. “OpenMashups Studio” trata do editor de mashups Open Mashups Studio, um complemento para Firefox de código livre e suas características, A seção 3.2. “IBM Mashups Center” trata do editor de mashups IBM Mashups Center um, editor da IBM com finalidade empresarial para extração e mistura de dados, e suas características, a seção 3.3. “Yahoo! Pipes” trata do editor do Yahoo! e suas características, a seção 3.4. 44

“Comparação entre os editores” apresenta após cada um dos editores uma comparação entre eles, a seção 3.5. “Considerações Finais sobre a análise” apresenta as conclusões e a decisão sobre a criação de um editor de serviços. 3.1.

OpenMashups Studio Open Mashups Studio é um complemento para Firefox disponível gratuitamente em

http://www.open-mashups.org e Open-Source (código aberto e disponível para mudanças). O Open Mashups Studio (tratado daqui para frente como OMS) é uma ferramenta visual para criação de aplicações híbridas que libera o desenvolvedor da necessidade de escrever sequer uma linha de código. Toda a interface do programa baseia-se no modelo arrastar e soltar componentes e ligá-los gerando uma nova aplicação. Como dito, O OMS é uma iniciativa Open Source sob a licença GPL (GNU General Public License) que disponibliza o código fonte aos interessados em estudar e redistribuir o software sem custo algum. 3.1.1. Características da Ferramenta Atualmente não existe previsão de uma versão do OMS para outros de uma versão da ferramenta como complemento de outro navegador ou como serviço disponível em nuvem (caso do Pipes, tratado na seção 3.3) o que não a torna dependente de um sistema operacional específico, mas de um navegador. A figura 9 ilustra a ferramenta:

45

Figura 9 Interface do OMS no Firefox 3.0

3.1.2. Fontes de dados disponíveis As aplicações criadas com OMS são compostas de diversos recursos como imagens, sons, e folhas de estilo personalizáveis (CSS na maioria dos casos) o que possibilita que os mashups criados tenham interfaces de usuário mais distintas, gerando aplicações finais desassociadas visualmente do editor. Quanto as fontes, o OMS suporta diversas API disponíveis e destaca na própria ferramenta a API do Twitter e o Pikeo (PIKEO, 2009) (sistema de compartilhamento de fotos similar ao Flickr), além de suporte à web semântica através da implementação do protocolo SPARQL e RDF. Segundo o site www.open-mashups.com, o screen scraping (técnica que "varre" o DOM de paginas para transformá-las em fontes de dados) também é suportado pela ferramenta que possui uma linguagem própria, chamada OMM (Open Mashups Modeling) para descrever suas aplicações, possibilitando certa extensão de fontes utilizáveis. 3.1.3. Conhecimentos necessários ao desenvolvedor

46

O desenvolvedor não precisa de conhecimentos específicos na utilização da ferramenta podendo se focar na solução proposta como idéia, sendo indispensável que entenda apenas as variáveis, a ligação entre os componentes da mashup e a relação entre comportamento e interface do projeto. 3.1.4. Documentação O editor OMS possui um bom conteúdo de ajuda em tempo de execução para cada componente e uma documentação disponível no site oficial contendo um User Guide com exemplos de aplicações simples com sua última atualização em novembro de 2008. 3.1.5. Comunidade Na data em que esta parte do trabalho foi escrito, Agosto de 2009, as estatísticas de download disponíveis na página de complementos do Firefox (ADDONS FOR FIREFOX, 2009) do complemento Open Mashups Studio contava com pouco mais de 2100 downloads, com uma média de pouco mais de 300 downloads semanais. O projeto ainda não tem previsão de ser extendido para uma plataforma independente de navegador, ao mesmo tempo em que as novidades no site não são atualizadas com frequência, é possível navegar no repositório de aplicações, porém a comunidade atualmente não é tão ativa quanto comunidades como Yahoo! Pipes. 3.2.

IBM Mashups Center IBM Mashup center é um produto da IBM para criação de mashups corporativos. Os

dados que vem das fontes da empresa como o banco de dados ou outras fontes podem ter diversas operações aplicadas a ele para a criação de aplicações hibridas. O resultado dessa transformação é uma mashup que pode ser acessada pelo protocolo HTTP padrão ou apresentado num navegador. O produto é composto por várias ferramentas utilizadas para propósitos especificos, como criar "feeds" e "feeds mashups" (feed resultado de mais uma fonte de dados), criação de páginas que mostram os feeds gerados pela ferramenta anterior usando componentes de uma 47

página pré prontos, e ainda com uma ferramentas de criação de widgets (widgets são aplicações focadas, normalmente disponíveis para serem agregadas a sistemas maiores, como páginas web ou áreas de trabalho) para serem utilizadas na ferramenta anterior. Ao contrário do produto analisado anteriormente, o IBM Mashups Center é proprietário e pago. 3.2.1. Características da ferramenta A ferramenta é própria para uso em negócios. Permite a criação de fontes de dados costumizáveis e com os dados da empresa, simplesmente pela interface gráfica, sem códigos. É um produto vendido pela IBM, pago e que tem uma versão trial de 60 dias. Roda em servidor.Além da versão paga, possui uma versão trial para testes por 60 dias ferramenta roda diretamente do servidor. A disponibilização pode ser pública, pela web ou somente como um feed, ou XML comum, visando a geração de outras fontes mistas (mashup de mashup).A criação de interfaces gráficas com o usuário pode ser feita pela segunda ferramenta oferecida, a Lotus Mashup, que permite a criação de widgets. Componentes costumizáveis também podem ser criados. A ferramenta Lotus Mashup, parte do produto IBM Mashups Center, permite que favoritos possam ser adicionados, permitindo que o usuário deixe a ferramenta adaptada a suas necessidades diárias específicas. Abaixo a figura 10 mostra a ferramenta Lotus Mashup, retirada do vídeo de demonstração:

48

Figura 10 Lotus Mashup

As características especificamente dependem da ferramenta, sendo que a IBM oferece diversas ferramentas para a criação, publicação e integração de mashups. 3.2.2. Fontes de dados acessíveis As fontes de dados seriam as disponíveis pela organização, como o banco de dados, um serviço pronto ou até arquivos do Excel. A figura 11, retirada do site da IBM, mostra as fontes disponíveis:

49

Figura 11 Entre as fontes disponíveis encontram-se serviços web, arquivos csv, planilhas excel, e outros

Para a criação de uma fonte de dados de banco de dados é necessário especificar o banco de dados que se deseja usar e os dados para acesso do mesmo. Logo em seguida é necessário montar o comando de busca, usando as colunas do banco de dados selecionado, tudo de uma forma visual, sequer uma linha de código é escrita. Após a montagem do comando, o próximo passo é selecionar algumas configurações. A configuração de uma fonte de dados vindo de uma planilha do excel também é simples. Consiste de mostrar a localização do arquivo da planilha no disco de armazenamento, selecionar as colunas que irão compor a fonte e mais algumas configurações sobre a localização dos dados na planilha. 50

Após selecionar e configurar os dados, estes estarão disponíveis para aplicação de filtros e construção de mashups. 3.2.3. Criando e disponibilizando uma mashup A criação de mashups é feita utilizando qualquer fonte de dados criadas na seção anterior. A disponibilização da mashup é feita numa ferramenta que consiste de uma interface onde arrasta-se as fontes para o “palco” e defiem-se ações sobre essa, podendo aplicar filtros que permitem realizar cache de dado, ordenação, união, e etc. As figuras 12 e 13 mostram as formas de criação:

Figura 12 Criação de mashup pelo IBM Mashups Center, esta forma é programática .

Figura 13 Criação de mashup pelo IBM Mashups Center, esta forma é visual.

A disponibilização se faz através de uma interface gráfica ou um XML do que foi gerado. Assim, uma mashup gerada pode estar envolvida na criação de outra mashup, ou seja, pode-se agregar dados de fontes de dados já agregadas. 51

A ferramenta Lotus Mashup permite a criação com interface arrastar e soltar, e publicação com somente um clique. De forma geral,

a disponibilização

depende da

finalidade. 3.2.4. Conhecimentos necessários ao desenvolvedor O usuário deverá conhecer as fontes de dados bem como a criação de acesso para as mesmas. Quanto a ferramenta, um bom conhecimento sobre os filtros disponíveis e as formas de publicação e utilização do Mashup. Os conhecimentos são mais relacionados a ferramenta e não tecnicamente, focando a regra aplicada. 3.2.5. Documentação A documentação está contida no site oficial do produto.Neste site temos tutoriais e uma Wiki. Existe um documento referente a utilização no formato PDF para download, onde temos disponíveis em diversos idiomas. O site ainda conta com FAQ's e muitos outros recursos, como por exemplo, vários artigos sobre o editor. 3.2.6. Comunidade Por ser um software proprietário, a comunidade não é tão ativa, pois a o proprietário oferece grande parte do que é necessário para utilização do produto; A IBM oferece um fórum para os usuários e desenvolvedores do produto e um blog onde desenvolvedores podem trocar experiências e sugerir soluções para determinados problemas. Já pela ferramenta Lotus Mashups é mostrado um link para que o desenvolvedor entre diretamente em contato com a comunidade de desenvolvedores para sanar dúvidas ou receber conselhos sobre o seu objetivo. 52

3.3.

Yahoo! Pipes Yahoo!Pipes (YAHOO, 2009) é uma ferramenta acessada online que permite criação

com dados mixados através um editor visual. O Pipes para rodar seus próprios projetos web, ou publicar e compartilhar seus próprios serviços web sem sequer escrever uma linha de código.O acesso através da internet proporciona todas as vantagens de computação nuvens, vistas no capítulo 2. Para utilizar o serviço é necessário ter uma conta no Yahoo. Imediatamente após o acesso, é possível realizar a criação de mashups, que ficam associados à conta no Yahoo, ou seja, é possível salvar os projetos e editar posteriormente. A publicação se faz com um clique. Podem-se executar o projeto para visualização, salvar ou publicar. Os componentes oferecidos são os mais utilizados, como entrada de texto e um container para saída. As fontes de dados são diversificadas. São utilizadas a busca de imagem do Flickr, busca do Google, YQL (Yahoo Query Language), entre outras. Existem mecanismos para utilização de feeds RSS como fonte de dados, bastando somente o usuário indicar a URL do site onde deseja realizar a busca.A figura 14 mostra a tela inicial do editor:

53

Figura 14 Tela principal do Yahoo! Pipes

3.3.1. Características da ferramenta Para começar a criar mashups com Pipes é necessário uma conta de usuário Yahoo! . Não é necessário instalar nenhum pacote em sua máquina, nem add-on (complemento) para o seu navegador e o serviço roda totalmente nas nuvens. Os recursos da ferramenta são disponbilizados em inglês até a presente data. A primeira visita em que o desenvolvedor resolver criar uma mashup acessando a seção "Create a Pipe" podendo optar por um tutorial simples em flash que mostra a criação de um primeiro Pipe. A navegação entre o painel principal e o painel de módulos é muito simples os componentes podem ser arrastados com o mouse para a aŕea principal. A interface é intuitiva baseada nos modelos das ferramentas WYSIWYG (What You See Is What You Get ) para desktop, não é necessária a utilização de linguagem de programação e vários elementos são disponibilizados prontos ao usuário, como operadores lógicos, funções matemáticas e de formatação de datas. 54

3.3.2. Fontes de dados acessíveis O Yahoo! Pipes reúne as fontes de dados mais populares e permite que, de certa forma, seja possível adicionar novas fontes de dados, através da extensão do mesmo. Algumas das fontes de dados são os famosos Fickr, Yahoo! Maps, Google Maps, entre outros. 3.3.3. Criando e disponibilizando uma mashup A criação de uma mashup é simples e nenhuma linha de código é necessária. Simplesmente através de uma interface what you see is what you get, arrastando e ligando componentes e utilizando elementos prontos que o Pipes oferece para apoio a criação dos aplicativos, como campos de entrada de texto, formatação de String, URL, operadores entre muitos outros. A criação de Mashups ocorre somente ligando pontos entre a entrada e a saída do mesmo. Cada fonte de dados pode ter alguns pontos como entradas com campos utilizando recursos do próprio Pipes, exemplo, é possível utilizar uma busca de imagens com entradas do termo da busca através de um campo de string do pipes e a entrada de números de imagens através de uma campo de números do Pipes. A figura 15 exemplifica:

55

Figura 15 Pipes e as áreas que o compõe

A publicação da mashup é feita da forma mais simples possível. Ao salvar um projeto já é possível visualizar o resultado, pois um link aparece no topo da página: "Execute Pipe". Ao clicar neste link você haverá a visualização da mashup. Na própria tela de visualização estará um botão disponível para a publicação do mesmo, ou re-publicação, caso seja um mashup salvo e já tenha publicado. A criação de mashups é simples e intuitiva. A publicação também é trivial, sendo que ao usuário resta somente realizar alguns cliques. 3.3.4. Conhecimentos necessários ao desenvolvedor Primeiro o desenvolvedor deve saber adquirir o acesso para a ferramenta, utilizando um registro nas bases do Yahoo!, após isso, o maior conhecimento necessário ao utilizar o Yahoo! Pipes é o próprio objetivo para o que deseja fazer, além dos conhecimentos básicos para utilização dos componentes prontos que o Pipes oferece. Pois a utilização é intuitiva e direta, não restando muito aprendizado relacionado ao editor em si. 56

3.3.5. Documentação O Yahoo! Pipes disponibiliza uma documentação bem acessível. Por mais simples que seja uma operação, ela está documentada. É oferecido também um bom suporte aos módulos implementados no Pipes, tanto para utilização quanto para expansão. 3.3.6. Comunidade O próprio Yahoo! disponibiliza sistema de fóruns e lista de discussões, no entanto pode-se perceber o grande fluxo de informação na web, tanto para tutoriais básicos quanto para tópicos avançados. O Yahoo dá suporte para criação de aplicativos e compartilhamento de mashups criados, fortalecendo a comunidade e dando força para que outros mashups sejam utilizados em diversos projetos. 3.4.

Comparação entre os editores Comparando as ferramentas Open Mashups Editor, IBM Mashups Editor e Yahoo!

Pipes foram estabelecidas conclusões que nortearam o modelo da ferramenta proposta por este trabalho (ver cap 4). O entendimento e análise destas ferramentas parte de alguns princípios. Primeiro, admiti-se a web como o melhor ambiente de desenvolvimento de mashups por promover interoperabilidade, independência de plataforma e a computação nas nuvens, neste caso o Yahoo! Pipes se destaca por fornecer seu editor em ambiente web diretamente no seu site sem necessidade de nenhuma instalação adicional e independente de navegador enquanto o OMS peca por se limitar ao Firefox e o IBM mesmo rodando diretamente de servidores é uma ferramenta paga. O Yahoo! Pipes mostrou ser dentre todas as ferramentas, atualmente, a que possui a maior comunidade de colaboradores com vários artigos e extensa documentação, além de ser o projeto mais estável, gratuito com maior número de mashups já feitas. 3.5.

Considerações Finais sobre a análise 57

Neste capítulo foram analisadas três dentre diversos editores de mashups disponíveis atualmente, alguns bons editores não foram analisados neste capítulo para restringir o campo de pesquisa até um ponto em que fosse feita a análise entre ferramentas com diferenciais entre sí e bons apelos quanto à facilidade de uso e customização, dois pontos tratados como primordiais para o editor proposto nesse trabalho. Entre os editores não expostos neste capítulo destacam-se o Google Mashup Editor, projeto interessante da Google para edição de mashups baseado principalmente numa interface modo texto encerrado pela própria Google no começo do ano e o Microsoft Popfly (MICROSOFT, 2009), projeto usando o Silver Light da Microsoft para criação de mashups e de jogos interativos,a ferramenta é mais voltada para criação de jogos e teve seu projeto de suporte e desenvolvimento descontinuado pela Microsoft em Agosto de 2009. Foi também analisada a possibilidade de extensão de um desses editores, com tendência a extensão do Yahoo! Pipes, no entanto, o trabalho revelou-se mais útil ao abordar o tema de maneira ainda não abordada por nenhum desses editores, com foco em mashups sociais e filtro de dados sociais. O capítulo 4 mostra a arquitetura de para geração de serviços web.

58

4.

ARQUITETURA PARA A GERAÇÃO DE SERVIÇOS WEB

O objetivo deste capítulo é apresentar a arquitetura para geração de serviços web, bem como os processos envolvidos no desenvolvimento da solução final que será disponibilizada ao usuário final como uma ferramenta visual de criação e edição de serviços web sociais. Este capítulo está dividido como segue: A seção 4.1. “Arquitetura Global” apresenta uma visão geral da arquitetura da ferramenta, a seção 4.2. “Arquitetura de banco de dados” expõe o modelo de dados e o esquema de banco de dados usado , a seção 4.3. “Arquitetura OO” mostra os diagramas de classes e os tópicos relevantes como frameworks e padrões de projeto envolvidos, a seção 4.4. “Modelo de interface gŕafica com usuário” mostra as telas do protótipo da ferramenta, e a seção 4.5.“Visão geral do funcionamento da ferramenta” mostra uma visão da ferramenta e do papel desta na criação de mashups.

4.1.

Arquitetura Global O objetivo é transformar fontes de dados até então não acessíveis como serviços para

que o desenvolvedor possa construir mashups. Esses serviços deverão ser disponibilizados com a arquitetura RESTful (FIELDING, 2000) e o aplicativo deve disponibilizar ao desenvolvedor realizar filtro dos dados que serão disponibilizados. Bases de dados não acessíveis são as oferecidas por APIs ou que necessitam de algum tipo de chave (por exemplo, Google Maps). O protótipo irá prever o acesso a essas bases sanando as necessidades do usuário quanto há requisitos de acesso aos dados (chave, autenticação) ou requerimentos técnicos (programação, conhecimento de tipo de dados). O gerenciamento de usuários e de seus serviços gerados será feito pelo sistema. Os usuários deverão acessar o sistema através de um identificador único que permita a autenticação. Deverá existir uma base para que os serviços gerados pelos usuários sejam armazenados e disponibilizados. A identificação do serviço será fornecida pelo sistema. 59

O serviço deverá ser gerado através de uma interface simples e intuitiva que permitirá a aplicação de filtros para que os dados estejam dentro de critérios que o usuário escolher. A seleção do usuário nessa interface será persistida em um banco de dados para futuramente ser acessada. A arquitetura global do protótipo baseia-se em três importantes partes: O acesso aos dados, o editor e o gerenciador geral, cuja função é a gerência dos serviços gerados e dos usuários. 4.2.

Arquitetura banco de dados O banco de dados deverá conter informações sobre os usuários, serviços e dados para

permitir o funcionamento da aplicação. Será utilizado um banco de dados relacional de código fonte aberto, gratuito e escalável, ideal para a necessidade do sistema, o MySQL. Para alcançar o objetivo do protótipo, propõe-se um modelo de dados que suporte todas as necessidades de funcionamento do sistema.Utilizou-se o padrão de trigramação (CUNHA, 2009) para identificação das entidades que permite que cada campo seja identificado de acordo com a entidade que ele pertence. Para gerenciamento do usuário será utilizado uma tabela que contém um identificador único, uma chave para o usuário ingressar no sistema, o identificador único no sistema, não relacionado com o usuário em si. A figura abaixo exibe a estrutura da tabela de identificação do usuário do sistema:

Figura 16 Estrutura da tabela usuario (Usuário).

Para a base de dados dos serviços será utilizada uma entidade chamada “servico”, que conterá a descrição, nome, identificador único, endereço de acesso ao serviço, referência para 60

o sistema que será a base de dados e o usuário que é o criador do serviço. A figura 17 apresenta a estrutura desta tabela:

Figura 17 Estrutura da tabela servico (Serviço).

Para guardar as informações que o desenvolvedor colocou no serviço usa-se uma tabela chamada “filtro”, que contém dados dos campos, condições e a qual serviço ela está atrelada, além do valor que aplicamos o filtro. Para um serviço pode-se ter diversos filtros atuando sobre os dados. A figura 18 apresenta a tabela filtro:

Figura 18 Estrutura da tabela filtro (Filtro).

Junto com o filtro existem diversas tabelas atuando na função de fornecer os metadados (informações que descrevem informações) de acordo com o filtro que o desenvolvedor monta no protótipo. A seleção de condições a ser aplicada nesses filtros é feita através do tipo do campo sobre o qual o filtro está atuando. Os campos, por sua vez, dependem do provedor de serviço. A aplicação de condição é feita por tipo. Exemplo: Caso o campo seja texto, as condições aplicadas deverão ser específicas para campos de texto. A figura 19 mostra a visão do esquema de banco de dados como um todo:

61

Figura 19 Esquema de banco de dados.

4.3.

Arquitetura OO Para o desenvolvimento do sistema usou-se Java (JAVA, 2009) como linguagem de

programação, pois é amplamente adotada e possui diversas soluções implementadas e é Orientada a Objetos. Unindo Java e seus frameworks, podemos construir aplicações robustas, reutilizáveis com simplicidade na criação. São utilizadas soluções pré-implementadas em Java nos mais diversos aspectos: persistência, injeção de dependência, criação e gerenciamento de serviços. A solução OO (Orientada a Objetos) deverá ser capaz de permitir a persistência dos dados, a aplicação dos filtros para o serviço e a conexão com o provedor dos dados base para o serviço. Como existe um grande variação no que diz respeito a aplicação dos filtros e na seleção de um provedor de dados, o sistema deverá ter uma arquitetura flexível que permita a aplicação atuar com perfeição nas mais variadas situações de utilização. Para chegar a um sistema flexível, foram utilizados diversos padrões de projeto (GAMMA, 1999) e o sistema está desenvolvido sob o padrão MVC (FOWLER, 2009).

62

A seguir serão abordados os tópicos mais notáveis da arquitetura OO do sistema: Persistência, busca e tratamento de dados, e MVC. 4.4.

Persistência de objetos Para

a

persistência

de

objetos

será

usado

o

Framework

Hibernate

(HIBERNATE.ORG, 2009), que permite fazer a persistência de objetos e o mapeamento ORM (Object-Relational Mapping , técnica que modela objetos para serem persistidos em bases de dados relacionais) (HEJLSBERG,2009). A versão do Hibernate utilizada é a 3, que permite que o mapeamento seja feito através de anotações (também chamadas annotations ) (HIBERNATE.ORG, 2009), onde identificam-se as classes e as tabelas do banco de dados na própria classe. Para persistir objetos existem as classes POJO (RICHARDSOM, POJO in Action, 2006), devidamente anotadas com as respectivas tabelas do banco de dados. Implementou-se uma classe POJO para cada tabela do banco de dados, como exemplificado na figura 20:

Figura 20 Um exemplo de classe POJO implementada com anotações. 63

No Hibernate usa-se uma classe chamada sessão, que é a interface entre o Java Runtime e Hibernate. Com a sessão executa-se as operações com objetos de salvar, apagar, atualizar entre outras. Com Hibernate, precisa-se de uma classe que gerencia as sessões,neste caso ConnectionFactory (Fábrica de Objetos de Conexão), que servirá como uma fábrica de sessões (GAMMA, 1999). A fábrica deve ser única no sistema, para isso usa-se um Singleton que será servido pela classe HibernateUtil. A figura 21 mostra um diagrama da classe HibernateUtil:

Figura 21 Estrutura da classe HibernateUtil.

Focando em isolar as operações de banco de dados para o restante do sistema, utilizouse o padrão de projeto DAO (SUN, 2009), que permite a abstração das operações do banco de dados para métodos de alto nível, permitindo a flexibilidade para possível futura troca de método de acesso a dados. O DAO é definido por uma interface, onde são definidos os métodos gerais e abstratos de acesso a dados, a figura 22 mostra uma implementação genérica de DAO:

Figura 22 Interface DAO implementada em java, com operações básicas de banco de dados.

64

Implementando a interface diretamente tem-se uma classe DAO genérica, ou seja, aplicável a qualquer entidade. Para operações específicas, classes DAO que herdam do DAO genérico são implementadas. Essa prática caracteriza o padrão Bridge (GAMMA, 1999), onde a abstração não está diretamente ligada a classe concreta final e específica, permitindo a variação individual de ambos. A figura 23 mostra como o padrão bridge é modelado no sistema:

Figura 23 Interface DAO e classes de implementação.

4.5.

Buscando e tratando dados Essa parte da arquitetura é crítica com relação a flexibilidade, pois depende das

seleções do usuário e da fonte de dados, que pode variar drasticamente. Para a coleta de dados, criou-se uma padronização buscando encapsular as variações da fonte. Para aplicação dos filtros usa-se a delegação de responsabilidade de aplicação a uma interface, caracterizando o padrão estratégia. Como podem haver dados vindo de fontes variáveis, criou-se um encapsulamento (SCOTT, 2009) da busca de dados de acordo com os provedor (fonte) que o usuário selecionar. Um protocolo de dados foi estabelecido. Toda classe que implementar a interface que define o servidor de dados, deverá construir os dados no padrão do sistema. Assim, independente do tipo de dados que o provedor oferecer (XML, JSON ou outros), tem-se uma estrutura de dados única que permitirá o tratamento dos mesmos no sistema. Essa estrutura não pode ser específica a uma classe, pois há a variação. Definiu-se a estrutura como sendo uma lista de mapa, estruturas que fazem parte das Collections (SUN, 2009) de Java 6.

65

As Collections de Java estão disponíveis a partir da versão 5 do Java, tendo sido usado neste trabalho a versão 6. O servidor de dados deverá ser escolhido será de acordo com o serviço gerado pelo usuário. A figura 24 mostra o modelo do servidor de dados:

Figura 24 Modelo do Servidor de dados .

O filtro é um ponto que exige uma arquitetura de certa forma ousada, pois é impossível aplicar os filtros que o usuário seleciona sem utilizar-se das artes de OO unidas aos conhecimentos dos padrões de projeto. A responsabilidade de aplicar o filtro ficou sob responsabilidade do próprio POJO, onde temos um método que não estará relacionado com os atributos persistidos, mas sim com a aplicação sendo executada. Esse método deverá receber um atributo, lista de mapa, que representa os dados. Para cada filtro salvo no banco de dados, e que anteriormente o usuário tinha selecionado, teremos um comportamento diferente. Por esse motivo, não é possível determinar de forma final a ação do filtro, sendo que essa tarefa será delegada a uma interface, cuja implementação irá variar de acordo com os dados que estão salvos no banco. A figura 25 a seguir ilustra o modelo para filtros:

66

Figura 25 Modelo OO de Filtros no sistema.

Alguns parâmetros devem ser considerados quando utiliza-se o filtro: O campo que recebe o filtro e o valor pelo qual baseamos a aplicação do filtro. Para qual filtro, tem-se a condição a ser aplicada e são nestas condições que se aplicam as nossas classes concretas. O filtro é dependente do tipo de dados e a condição a qual é aplicada, sendo assim, ele é parametrizado de acordo com a condição e instanciado de acordo com o campo ao qual ele se aplica. A condição é parametrizada através de enumeradores (enums de Java), que são definidos no próprio filtro concreto. A partir do filtro mais o provedor iremos montasse o serviço. Para tal objetivo o serviço deverá saber qual provedor buscar e os filtros, no entanto, se aplicados diretamente essa quantidade de operações para a classe de serviço diretamente, tem-se um problema que é o alto acoplamento entre as classes específicas do filtro e as classes específicas do serviço. Isso é evitado utilizando o padrão fachada (GAMMA, 1999), onde somente um interface simples é vista pela classe responsável pela chamada do serviço, a fachada se encarrega de buscar os filtros, os dados e aplicar, retornando um tipo de dado específico para a classe de serviço. Isso traz um baixo acoplamento e o encapsulamento das peculiaridades da montagem do

serviço. A figura 26 a seguir mostra o diagrama OO para o servidor de recursos:

67

Figura 26 Servidor de recursos usando padrão fachada.

Como não é conhecido o tipo de filtro e nem o tipo de provedor de serviço, deve-se determinar um mecanismo que permita a instanciação das classes de acordo com os parâmetros que estão no banco de dados, previamente selecionados pelo usuário. Em outras palavras, se o usuário utilizou os dados X, classes respectivas a X deverão ser instanciadas. Uma forma de utilizar a classes para conseguir esse objetivo é através de fábricas e fábricas abstratas (GAMMA, 1999), mas a variação é alta e podemos ter infinitas combinações de classes para satisfazer os filtros. Outra forma, que é atual e bastante utilizada em sistema, é usando injeção de dependência (GAMMA, 1999), onde essas classes dependentes podem ser injetadas. Um framework leve e bastante difundido que, entre outras, disponibiliza essa funcionalidade é o Spring (SPRINSOURCE.ORG, 2009). Usando Spring é possível préprogramar as dependências e, por parâmetros, escolher a dependência necessária de acordo com os dados que dizem respeito a determinado serviço. O uso das classes de Spring será na classe de fachada, e os arquivos de configuração serão usados de acordo com os dados do sistema. Para as operações que não obtiverem sucesso, deverá ser lançada uma exceção. O tratamento da exceção deverá sempre ser minucioso, causando menor impacto possível para o usuário. Para identificar claramente os problemas ocorridos no processo, exceções personalizadas foram implementadas. 68

4.6.

MVC O sistema está estruturado em Model View Controller. O model (modelo) são as

classes que representam o negócio, a idéia, basicamente resume-se o model nas classes POJO. O controller (controlador) são as classes que acessam o banco de dados, controlam o fluxo, aplicam certas regras e então retorna os dados para a view. A view (camada de visualização) tem a função de interface com o usuário, de exibir informações e permitir que o usuário modifique. No sistema a view se apresenta como páginas JSP (SUN, 2009) e o controller como Servlets (SUN, 2009). 4.7.

Arquitetura Web A arquitetura web está intimamente ligada a tecnologia que é utilizada, Java. Para

executar Java em um servidor, necessita-se de um servidor de aplicação. O utilizado pelo sistema é o TOMCAT 6 (APACHE, 2009 ), pois permite o uso de expresion language (SUN, 2009) e suporta JSTL (SUN, 2009), permitindo que não exista código Java em páginas de interface com o usuário. Os dados são exibidos através de página JSP (SUN, 2009). Não há código Java nas páginas JSP, utilizou-se JSTL, conjunto de bibliotecas de tags para manipulação dos dados em páginas JSP, permitindo maior flexibilidade e visibilidade das páginas JSP. Toda requisição gerada em página JSP é enviada para uma servlet que se encarrega de fazer as modificações

necessárias

nos

dados

e

encaminhando

para

a

JSP

correta.

A figura 27 apresenta uma visão geral dos componentes principais JEE, Servlets e JSP:

69

Figura 27 Modelo das JSP e Servlets.

As páginas restritas são filtradas através dos filtros (filters de Java) (SUN, 2009) . Há um filtro que verifica se o desenvolvedor está devidamente no sistema e direciona para uma página de erro caso ele não esteja. As paginas que devem ser restritas a usuários que estão no sistema ficam dentro de uma pasta sobre a qual o filtro atua. A autenticação e os dados ficam em uma sessão, onde as servlets colocam e removem objetos de acordo com a necessidade. Quando o usuário ingressa no sistema e não há autenticação, a servlet de entrada se encarrega de buscar os dados para o usuário e verificar a presença do mesmo no banco de dados. A figura 28 apresenta este fluxo:

Figura 28 Fluxo do usuário (desenvolvedor) no sistema.

O serviço e o oferecimento são feitos usando a arquitetura RESTful, onde recursos são acessados por um identificar único. A API utilizada para conseguir disponibilização dos serviços foi a Jersey(JERSEY, 2009), que implementa o padrão da Sun para disponibilização 70

de serviços. Jersey possibilita através de anotações identificar e implementar o necessário para a construção e disponibilização de serviços.O identificador para acesso o serviço é basicamente: "/servico/{id do Serviço}/{formato}", onde o ID do serviço é o qual identifica os mesmo no banco de dados e formato é o formato que se deseja o serviço, pode ser JSON ou XML, mas esse parâmetro não é obrigatório. Jersey também permite identificar o formato que será o serviço através de anotação. 4.8.

Modelo de interface gŕafica com usuário Esta seção descreve modelos para interação com usuário, suas entradas esperadas e o

fluxo de ações do usuário pelo sistema.A extensão do Pipes proposta neste trabalho usando OpenSocial(OPENSOCIAL, 2009) possui a peculiaridade de necessitar de um recipiente para que seja implementada, assim aqui tem-se a idéia da entrada de dados do usuário através de um widget (também chamado gadget) para Orkut: um dos recipientes OpenSocial. Abaixo um modelo para interface gráfica descreve objetos presentes no gadget que pode ser implementado no recipiente no caso específico do OpenSocial mas também é válido como modelo para interface de aplicação lado cliente que é capaz de gerar um serviço padronizado em XML. A figura 29 mostra a tela inicial do sistema, uma vez que o usuário (desenvolvedor) decida criar um novo filtro:

71

Figura 29 Tela de criação de filtro

A funcionalidade desta tela, uma vez apresentada ao usuário é especificar com maior exatidão uma saída XML definindo parâmetros que o restringem. Onde nota-se escrito "Relacionamentos" "Métodos" "Onde:" "Condição" e "Valor" haverão apenas etiquetas indicativas de conteúdo."Visualizador", "Listar Amigos", "Idade" e "Maior que" são menus drop down preenchidos dinamicamente um após o outro, isto é, uma vez que o usuário selecione como valor para "Métodos" a opção "Listar Amigos" os valores possíveis para "Onde" serão carregados utilizando-se de uma requisição Ajax,os campos "Amigos" e "Amigos de Amigos" em branco indicam que o menu referente a "Relacionamento" foi aberto."Valor" e "25" simulam uma entrada digitada pelo usuário com o Valor 25."Gerar Resposta" é o botão de submissão do formulário.Os sinais de + acima de "Onde" e "Condição" indicam que pode-se adicionar mais destes campos. E o aviso dentro do balão é uma ajuda automática que aparece com o evento mouse over com uma pequena dica. O ícone em forma de lupa exibirá uma mensagem que será discutida mais à frente e o sinal de interrogação abre uma ajuda.

72

A lista de opções exposta em Relacionamento se limitará a "Visualizador" e "Amigos", assim para selecionar todos os amigos do perfil em que se encontra a aplicação seleciona-se Visualizador seguido de "Listar Amigos" como método em "Métodos". Os campos "Onde" e "Condição" visam limitar o campo de busca e o tamanho do serviço gerado. Em "Onde" ficará exposta uma grande Lista com vários parâmetros vindos da rede social e "Condição", define a possibilidade de inserção de um valor para limtar ainda mais o retorno, podendo contér para valores inteiros "Maior que", "Igual", "Menor que", etc... para Strings "Contém", "Não Contém", para booleanos "Falso" "Verdadeiro" (sem o campo Valor neste caso). A figura a seguir 30 ilustra como pode-se aumentar a quantidade de campos "Onde" e "Condição":

Figura 30 Adição lógica de condições.

A novidade nesta figura é a presença dos botões tipo radio E e OU, conectivos lógicos entre os campos.Neste exemplo supõe-se que o usuário tenha aumentado o campo "Onde" 73

limitando seu campo de busca com o conectivo E e buscando por Fotos cujos títulos contenham a palavra Viagem. A figura 31 a seguir mostra um exemplo de janela de alerta que exibe linhas de pseudo-comando dando uma idéia dos limites do serviço que será gerado:

Figura 31 Mensagem de alerta que aparece antes da confirmação de envio do filtro.

Nesta tela com alerta é possível notar a presença de todos os elementos definidos pela usuário de forma textual facilitando a compreensão imediata do resultado esperado.Nas linhas deste pseudo-código, bem semelhante aos códigos para busca em banco de dados, nota-se a divisão entre os tipos de dados e os campos diferenciadas pelas cores de fontes tentando facilitar ainda mais o entendimento. O "X" permite fechar o alerta. Uma vez que o usuário tenha feito o processo de seleção dos dados acima e clicado em Gerar Resposta ele receberá um serviço, uma fonte XML com uma URL que poderá incorporar ao Pipes pelo módulo Fetch Data.

74

A figura 32 , retirada da própria documentação do Yahoo! Pipes, apresenta a seguir algumas das conexões possíveis de outros módulos com Fetch Data, e a maneira de inserção de um serviço neste módulo:

Figura 32 Yahoo! Pipes e o módulo Fetch Data.

Os modelos de interface com usuário do widget propõe uma interface intuitiva e os menus drop down que limitam a ação do usuário prevenindo erros e forçando o uso correto dos métodos da API, a limitação de resultados diminui o tamanho dos XML consequentemente possibilitando que o repositório de XML seja bem mais sucinto e específico, facilitando inclusive a atualização dos mesmos, lembrando sempre que um dos focos principais deste trabalho é possibilitar a criação de mashups sem escrita de código fonte. 4.9.

Visão geral do funcionamento da ferramenta Para finalizar, esta visão geral do funcionamento da ferramenta expõe graficamente os

conceitos de mashup, redes sociais, valorização da idéia do desenvolvedor e uso da ferramenta intermediando idéia, dados e aplicação final. A ferramenta, aqui chamada Visual WebSocial, porém sem nome ainda definido sendo para fins de modelagem outrora chamada apenas de “Gerador de Serviço Social para Criação de Aplicações Híbridas” é capaz de integrar, neste caso em particular, mapa com dados de pessoas, relacionamentos de atualizações de uma rede social gerando uma aplicação totalmente nova e simples, para exibição de amigos no mapa. 75

As possibilidades de novas aplicações, no entanto, superam em criatividade este exemplo didático dos amigos no mapa, atingindo os mais variados temas usando dados sociais. A figura 33 a seguir mostra a visão geral do funcionamento da ferramenta.

Figura 33 Uma visão geral e prática do ponto de vista do Desenvolvedor, esclarece o papel da ferramenta.

76

5. CONSIDERAÇÕES FINAIS Este trabalho apresentou o desenvolvimento de uma arquitetura de integração entre serviços web para criação de aplicações híbridas e sociais. Este capítulo está organizado como segue: Seção 5.1 Conclusões , trata das conclusões gerais e objetivos alcançados; Seção 5.2 Contribuições trata de contribuições alcançadas com este trabalho, e a Seção 5.3 dos trabalhos futuros que se espera possam ser realizados a partir deste trabalho. 5.1.

Conclusões Conclui-se que a arquitetura aqui proposta, juntamente com a ferramenta visual para

edição e criação de aplicações sociais reduz tempo de desenvolvimento de aplicações, valoriza a idéia do desenvolvedor, colocando-a em um nível de importância maior do que a codificação.Com isto, não só o desenvolvedor é beneficiado, como também o usuário da aplicação gerada, uma vez que participará de uma web mais viva e que representa de forma mais fiel o que entendemos por sociedade. A grande massa de dados disponíveis na internet ficará mais facilmente manipulável, dando origem a inúmeras idéias, que dificilmente sem o uso desta arquitetura chegariam a um protótipo utilizável, o escopo destas idéias atinge a web, mas também as pessoas e grupos sociais, podendo dar origem a aplicações de censo, marketing, e uma infinidade de outras. O paradigma web foi mudado com o estouro da bolha e o usuário deixou de ser um mero leitor de páginas estatísticas, acredita-se que o paradigma esteja mudando novamente e agora além de leitor e escritor da web, o usuário tem potencial para ser desenvolvedor de aplicações sociais para web. Os ganhos durante o processo de desenvolvimento do trabalho excederam a expectativa inicial ao fazer com que fossem encaradas constantes mudança de requisitos e adaptações a novas idéias, ao mesmo tempo em que cumpríamos uma agenda de entregas incrementais do trabalho e do protótipo de ferramenta, uma nova forma de misturar o jeito extreme programming (XP) com o método tradicional e sua larga documentação. 77

A decisão de criar uma ferramenta nova, foi acima de tudo, desafiadora, enquanto uma extensão do pipes, apesar de interessante poderia incorrer em trabalho menos inovador ou na resolução de um problema que viria a ser sanado antes da publicação deste trabalho. Criar uma nova ferramenta requisitou uma grande quantidade de confiança e também de conhecimentos multidisciplinares, pondo em prática todas as tecnologias citadas em cada uma das seções do capítulo 2 e várias outras, como o RPX (RPX, 2009) e o Jersey, citados no capítulo anterior. 5.2.

Contribuições O processo de desenvolvimento desta arquitetura possibilitou a criação da ferramenta

visual para aplicações sociais que será disponibilizada para ser usada e estudada. A diversidade de assuntos abordados durante o processo de desenvolvimento se mostrou grande e abordando os mais variados assuntos, de banco de dados, à tecnologias de lado cliente como o CSS, do estudo e análise de outras ferramentas existentes à proposta de uma nova arquitetura, de fato, os conhecimentos vistos durantes as aulas de graduação estão presentes neste trabalho juntamente com a pesquisa de novos conhecimentos focados em web e especialmente mashups. 5.3.

Publicação Este trabalho resultou na publicação de um artigo “MACIEL, José Teles; SIQUEIRA,

William Antônio; BERTOTI, Giuliano Araujo . DESENVOLVIMENTO VISUAL DE APLICAÇÕES SOCIAIS PARA WEB Boletim Técnico da Faculdade de Tecnologia de São Paulo, v. 25, 2009.” apresentado no 11º Simpósio de Iniciação Científica e Tecnológica de São Paulo no mês de outubro de 2009. 5.4.

Trabalhos futuros As contribuições alcançadas com este trabalho não se encerram aqui, novas

oportunidades relacionadas serão abertas, tais como: 78

a) Desenvolvimento de testes de fluxo de trabalho (workflow) para análise dos objetos e requisições feitas na ferramenta; b) Melhoria gráfica da ferramenta; c) Implantação de plano de testes e casos de uso direcionados a desenvolvedores de mashups; d) Desenvolvimento de mashups sociais; e) Desenvolvimento de ferramentas com acesso a bases de dados empresariais; f) Adequação do sistema a novas realidades e usando novas fontes de dados ainda não previstas, como dados de censo; g) Aproveitamento

da

ferramenta

em

cenários

de

Business

Intelligence

e

DataWarehouse.

79

6.

REFERÊNCIAS

AJAXPATTERNS, Main Page - Ajax Patterns, Disponivel em: , Acessado em: 23 de Julho de 2009 ANDERSON, Paul, Technology & Standards Watch What is Web 2.0? Ideas, technologies and implications for education, Disponivel em: , Acessado em: 27 de Março de 2009 APACHE, Tomcat 6 Welcome!, Página Inicial, Disponivel em: , Acessado em: 23 de Agosto de 2009 AQUELE

BLOG

DE

SOA,

O

que

é

SOA

,

Disponivel

em:

, Acessado em: 01 de Agosto de 2009 ATPM, ATPM 4.12 - Paradigm: WYSIWYG: Is it What You Want?, Disponivel em: , Acessado em: 13 de Julho de 2009 Bear BIBEAULT; Katz YEHUDA, jQuery in Action , Editora: Manning Publication, EUA, 2009, 400pgs, ISBN: 1933988355 BLUELOCK,

What

is

Infrastructure

as

a

Service,

Disponivel

em:

, Acessado em: 29 de Maio de 2009 BRAUER,

Bob,

So

What

is

a

Web

service

Anyway?

,

Disponivel

em:

, Acessado em: 14 de Agosto de 2009 CAPGEMINI; HP, The Cloud and SOA: creating an Architecture for Today and for the Future , Disponivel em: , Acessado em: 22 de Maio de 2009 Ethan CERAMI, Web Services Essentials - Distributed Applications with XML-RPC, SOAP, UDDI & WSDL , Editora: O'Reilly, 2002, 500pgs, ISBN: 0596002246 80

COMPUTER WORLD, COMPUTER WORLD EXECUTIVE BRIEFING: Desvendando o Computação nas nuvens , Disponivel em: , Acessado em: 28 de Junho de 2009 CUNHA, ADilson Marques da; ITA, Notas de Aula de “CE-240 Projeto de Sistemas de Bancos

de

Dados”

no

Primeiro

Período

de

2009

Disponivel

em:

, Acessado em: 04 de Agosto de 2009 Paul J. DEITEL, Harvey M DEITEL, Ajax, Rich Internet Applications e Desenvolvimento Web para Programadores. São Paulo: Pearson, 2009 ECLIPSE

FOUNDATION,

Web

Services

Overview,

Disponivel

em:

, Acessado em: 02 de Agosto de 2009 Roy Thomas FIELDING, Architectural Styles and the Design of Network-based Software Architectures, Ph.D. Thesis, University da California, Irvine, California EUA, 2000. Flickr, Página Inicial, Disponivel em: , Acessado em: 17 de Março de 2009 FOWLER,

Martin,

GUI

Architectures

,

Disponivel

em:

, Acessado em: 21 de Julho de 2009 Erich GAMMA; John ULISSIDES; Ralph JOHNSON; Richard HELM, Padrões de projeto : Soluções reutilizáveis para software orientado à objeto, 1ed, porto alegre, 1999, editora: artmed isbn: 8573076100 GITHUB, Scriptaculous, Disponivel em: , Acessado em: 18 de Julho de 2009 GMAIL BLOG, GMAIL leaves beta, launches Back to Beta,Labs , Disponivel em: , GRUBER,Tom, Ontologies, Web 2.0 and Beyond, Disponivel em: , Acessado em: 14 de Março de 2009 81

HAYES, Brian, Cloud computing, Disponivel em: , Acessado em: 23 de Maio de 2009 HEJLSBERG,

Anders,

Object-Relational

Mappings,

Disponivel

em:

, Acessado em: 28 de Julho de 2009 HENSCHEN, Doug, INFORMATION WEEK: Demystifying The Cloud, Disponivel em: , Acessado em: 28 de Maio de 2009 HP, The Cloud and SOA Creating an Architecture for Today and for the Future, Disponivel em: , Acessado em: 22 de Maio de 2009 IBM, IBM Systems Journal,Vol. 44, No. 4, 2005 - Service-Oriented Architecture , Disponivel em: , Acessado em: 01 de Agosto de 2009 IBM, Defining SOA as an architectural style, Disponivel em: , Acessado em: 03 de Agosto de 2009 IBM, Mashups: The new breed ofWeb app , Disponivel em: , Acessado em: 14 de Agosto de 2009 IBM

Mashups

center,

Página

Inicial,

Disponivel

em:

, Acessado em: 01 de Julho de 2009 IEEE; LAWTON, George,,Developing Software Online With Platform-as-a-Service Technology, Disponivel em: , Acessado em: 15 de Julho de 2009 INFO PROFESSIONAL, O Futuro da computação está nas nuvens?, Disponivel em: , Acessado em: 25 de Maio de 2009 INFOBLOGS , Página Inicial, Disponivel em: , Acessado em: 14 de Março de 2009 82

INFOWESTER, O que é RSS?, Disponivel em: , JAVA, JSR 311: JAX-RS: The JavaTM API for RESTful Web Services, Disponivel em: , Acessado em: 18 de Agosto de 2009 JAVA, Página Inicial, Disponivel em: , Acessado em: 12 de Fevereiro de 2009 JERSEY, Página Inicial, Disponivel em: , Acessado em: 25 de Agosto de 2009 JQUERY, Main page, Disponivel em: , Acessado em: 14 de Julho de 2009 Jerry LEDFORD, SEO OTIMIZAÇÃO PARA MECANISMOS DE BUSCA BÍBLIA – 1ed, RIO DE JANEIRO, Editora: ALTA BOOKS, 2009, 400pg, ISBN: 978-85-76082262 LESSIG, Lawrence,The Future of Ideas , Disponivel em: , Acessado em: 07 de Agosto de 2009 MASTER NEW MEDIA, Mashups: O Que São? Conheça Os Seus Tipos E Tecnologias De Suporte, Disponivel em: , Acessado em: 06 de Agosto de 2009 MENDES, André , O que é cloud computing?, Disponivel em: , Acessado em: 23 de Maio de 2009 MLADEN, A. V. Cloud Computing – Issues, Research and Implementations. North Carolina State University, EUA, 2008 Microsoft Popfly, Página Inicial, Disponivel em: , Acessado em: 01 de Julho de 2009

83

MOZILLA

DEVELOPER

CENTER

,

About

Javascript,

Disponivel

em:

, Acessado em: 24 de Abril de 2009 MYSQL.com , Página Inicial, Disponivel em: , Acessado em: 13 de Agosto de 2009 NAVISITE, Software as a Service: The next- Generation Software Aplication Delivery Model for ISVs., Disponivel em: , Acessado em: 06 de Julho de 2009 O REILLY, Tim, Whats web 2.0, Disponivel em: , Acessado em: 12 de Fevereiro de 2009 OPEN

CLOUD

MANIFESTO,About

page

,

Disponivel

em:

, Acessado em: 24 de Julho de 2009 Open Mashups Studio,Página Inicial, Disponivel em: , Acessado em: 09 de Julho de 2009 OPSOURCE,Why Software as a Service? Helping Our Customers Reduce Costs and Increase Revenue, Disponivel em: , Acessado em: 8 de Julho de 2009 PROGRAMMABLE WEB,How-to, Disponivel em: , Acessado em: 14 de Agosto de 2009 PROGRAMMABLE WEB,APIs, Disponivel em: , Acessado em: 14 de Agosto de 2009 RPX,RPX - Instant OpenID and Data Portability, Disponivel em: , Acessado em: 25 de Agosto de 2009 SAP SDN WIKI ,Cloud computing wiki, Disponivel em: , Acessado em: 22 de Maio de 2009 84

SEYBOLD ,SOA A case study, Disponivel em: , Acessado em: 07 de Agosto de 2009 SIIA,Software as a Service: Strategy Backgrounder, Disponivel em: , Acessado em: 7 de Julho de 2009 Maurício Samy SILVA, Jquery – A BIBLIOTECA DO PROGRAMADOR JAVASCRIPT, 1ed, Editora: Nova Teca, São Paulo, 2008, 432pgs, ISBN: 9788575221785 SITEPEN ,Dojo Quick Start Guide, Disponivel em: , Acessado em: 29 de Julho de 2009 SPRINSOURCE.ORG,Página Inicial, Disponivel em: , Acessado em: 27 de Agosto de 2009 SUN,Take Your Bussiness to a higher level., Disponivel em: , Acessado em: 27 de Maio de 2009 SUN,Expression Language , Disponivel em: , Acessado em: 24 de Agosto de 2009 SUN,JSTL- JavaServer Pages Standard Tag Library, Disponivel em: , Acessado em: 24 de Agosto de 2009 SUN,JSP – JavaServer Pages Technology, Disponivel em: , Acessado em: 24 de Agosto de 2009 UOL CIO ,Abc da SOA , Disponivel em: , Acessado em: 23 de Julho de 2009 VISHAL SIKKA ,The Open Cloud Manifesto, Disponivel em: , Acessado em: 22 de Maio de 2009

85

W3C,W3C

XHTML2

Working

Group

Home

Page

,

Disponivel

em:

, Acessado em: 15 de Julho de 2009 W3C,Standards, Disponivel em: , Acessado em: 04 de Agosto de 2009 W3C,Web

Service

Definition

Language

(WSDL),

Disponivel

em:

, Acessado em: 23 de Agosto de 2009 W3SCHOOLS ,XHTML Tutorial , Disponivel em: , Acessado em: 22 de Abril de 2009 W3SCHOOLS ,DHTML Tutorial , Disponivel em: , Acessado em: 22 de Abril de 2009 W3SCHOOLS ,Introduction to CSS , Disponivel em: , Acessado em: 22 de Abril de 2009 W3SCHOOLS ,Introduction to Javascript, Disponivel em: , Acessado em: 24 de Abril de 2009 W3SCHOOLS ,AJAX tutorial, Disponivel em: , Acessado em: 23 de Julho de 2009 W3SCHOOLS ,Web Services , Disponivel em: , Acessado em: 01 de Agosto de 2009 XML SCHEMA,WSDL, Disponivel em: , Acessado em: 11 de Agosto de 2009 XML.ORG ,UDDI 101, Disponivel em: , Acessado em: 03 de Agosto de 2009 Yahoo! Pipes ,Página Inicial, Disponivel em: , Acessado em: 26 de Março de 2009 86

Raymond YEE, Pro Mashups Web 2.0: Remixando Dados e Serviços da Web, 1ed, RIO DE JANEIRO, Editora: ALTA BOOKS, 2009,512pg, ISBN: 9788576082286 YUILIBRARY ,Página Inicial, Disponivel em: , Acessado em: 19 de Julho de 2009

87