Em Mashups: The New Breed of Web Applications, Duane Merrill propõe que, em termos de arquitetura, uma aplicação mashup é constituída pelos seguintes elementos:
- Provedores de conteúdo (ou de APIs),
- o mashup site,
- a aplicação cliente (tipicamente, um navegador).
Os provedores de conteúdo normalmente publicam seu conteúdo através de APIs, que implementam protocolos ou paradigmas de interação baseados nos princípios REST, tais como RSS, Atom ou SOAP. Em alguns casos, o provedor de conteúdo não foi necessariamente preparado para ser utilizado por outra aplicação. Ou seja, seu conteúdo é utilizado na composição de um mashup, sem que o criador do site ou aplicação o tenha concebido para tal tipo de interação. Nestes casos, como não há uma API previamente definida, os construtores de mashup podem utilizar uma técnica chamada de screen scraping para obter conteúdo desses sites.
Uma outra forma de publicar conteúdo para a construção de mashups é através de widgets, que são pedaços de códigos que podem ser incorporados pelas aplicações mashup.
O mashup site é onde reside a lógica da aplicação. Não necessariamente a execução da aplicação (ou de parte dela) ocorrerá no servidor do mashup site. Isto porque várias partes da aplicação poderão ser executadas no provedor de conteúdo ou na aplicação cliente (browser).
Um dos principais exemplos de mashup site é o http://chicagocrime.org/. Neste caso, Google Maps (fornecendo os mapas) e o Departamento de Polícia de Chicago (fornecendo os dados das ocorrências de crime) são os fornecedores de conteúdo.
De fato, pode-se entender que o grande diferencial desse tipo de aplicação está na possibilidade de combinar dados resultantes de computação em vários pontos (nos três elementos da arquitetura) para obter o resultado final do mashup.
A aplicação cliente tipicamente é um navegador sendo executado no computador do usuário. Nele executa-se a lógica para a apresentação do conteúdo. Muitas vezes, utiliza-se alguma lógica rodando no cliente para compor e agregar o conteúdo, além da apresentação propriamente.
Ao analisar a arquitetura proposta, percebe-se que essa baseia-se num paradigma que, de certa forma, já era utilizado pelos protocolos e padrões da web. Ao utilizar pequenos “pedaços” de software, como os antigos contadores de acesso, ou mesmo pedaços de client-side code (como os códigos em JavaScript), os criadores de sites já estavam, de certa forma, montando mashup applications.
Assim, não seria errado entender que os mashups são, na verdade, uma natural evolução dos paradigmas anteriores, com a possibilidade de agregar conteúdo mais dinâmico (extraídos de bases de dados), e de apresentá-los em formatos distintos, combinados com outras informações.
Neste ponto, é interessante apresentar algumas das tecnologias e padrões que suportam o conceito de mashups. Tome-se como base os três elementos considerados os componentes de uma aplicação mashup.
Os provedores de conteúdo publicam serviços ou APIs para que outras aplicações obtenham informações de seus sites. De maneira ideal, esses serviços ou APIs devem funcionar de acordo com os princípios de arquitetura conhecidos como REST.
REST é definido por Roy Thomas Fielding como “um estilo de arquitetura para sistemas distribuídos de hipermídia”. REST define um conjunto de propriedades com ênfase na escalabilidade, uso de interfaces genéricas, implantação de componentes independentes, além do uso de componentes intermediários para reduzir latência, prover segurança e encapsular sistemas legados.
Mas, além dessas tecnologias básicas da web, pode-se identificar outras tecnologias mais recentes (ou seria melhor dizer, modelos de aplicações), cuja evolução permitiu o surgimento e a disseminação dos mashups. Não se pretende que a lista a seguir seja extensiva, dada a diversidade e o dinamismo da web, mas podemos citar Web feeds, Ajax, Web Services, SOAP, Screen Scrapping e Web semântica RDF.
Nenhum comentário:
Postar um comentário