Processamento web no cliente: o \"downsizing\" da arquitetura web

PROCESSAMENTO WEB NO CLIENTE O “DOWNSIZING” DA ARQUITETURA WEB ∗

Lucas Maurício Castro e Martins

‡

Orientador: Prof. MsC. Marco Antônio Lucinda Ribeiro da Silva

§

Abstract This paper describes a Web architecture with processing on the client-side in contrast to the widely used Web architecture that focuses on processing on the server-side. The growth in use of processingment on the client is similar to the downsizing of the computing platform occurred from the 1970s in which part of the computing utilities migrated from mainframe to personal computers. Held a brief discussion subsidiary on the Web architecture, HTTP, URI, REST, HTML5, CSS3, JavaScript and Ajax as the basis for the presentation of this architecture with the processing on client. In addition to its description, its structure, its operation and its positive and negative points are raised, not so exhausted in this work. Finally, are presented some examples of building software in this architecture. Key-words: Client-side web processing. Downsizing. REST. HTML5. Ajax. JavaScript. Web platform. Client-server architecture.

Resumo Este trabalho descreve a arquitetura web com processamento no lado do cliente em contraposição à arquitetura largamente utilizada na web que foca o processamento, quase exclusivamente, no lado do servidor. O crescimento da utilização do processamento no cliente é similar ao movimento de downsizing de plataforma da computação ocorrido a partir dos anos 1970, onde parte da computação migrou da plataforma de grande porte para os microcomputadores pessoais. Realiza-se uma rápida discussão subsidiária sobre a arquitetura web, HTTP, URI, REST, HTML5, CSS3, JavaScript e Ajax como base para a apresentação desta arquitetura com processamento no cliente. Além de sua descrição, são levantados, de forma não exaurida neste trabalho, sua estrutura, seu funcionamento e seus pontos positivos e negativos. Por fim, são apresentados exemplos de construção de softwares nesta arquitetura. Palavras-chaves: Processamento web no cliente. Downsizing. REST. HTML5. Ajax. JavaScript. Plataforma web. Arquitetura cliente-servidor. ∗

‡

§

Artigo apresentado em Outubro/2014 como trabalho de conclusão do curso (TCC) de pós-graduação lato sensu em Engenharia de Software com Ênfase em Qualidade e Produtividade do Centro Univers. Inst. de Educação Superior de Brasília - IESB, Brasília (DF), Brasil, com financiamento parcial de estudos concedido pelo Supremo Tribunal Federal, processo administrativo STF no 351.499/2013. Atua no desenvolvimento de sistemas desde 1999, tendo participado de projetos nas áreas de engenharia civil, jurídica, planejamento e gestão, gestão contratual, recursos humanos, agropecuária e preservação ambiental. Atualmente faz parte da equipe de desenvolvimento de sistemas do Supremo Tribunal Federal. Coordenador do curso de pós-graduação em Engenharia de Software com Ênfase em Qualidade e Produtividade.

1

1 Introdução Esse trabalho se propõe a descrever a migração de processamento das aplicações web do servidor para o lado do cliente. Resguardadas as devidas proporções, essa migração se parece com o downsizing de plataforma de hardware que ocorreu na computação a partir do lançamento do IBM PC nos anos 1970. A discussão sobre esse movimento é importante porque, além da tecnologia da informação e a internet estarem cada vez mais presentes no cotidiano das pessoas e das organizações e essa mudança ter grande impacto no desenvolvimento de sistemas web, ela ainda é tratada de forma tímida porque os poucos trabalhos existentes focam apenas em alguma tecnologia ou técnica específica. Inicialmente, é necessário esclarecer o uso dos termos web e interface ao longo do texto. O termo web é algumas vezes tratado como sinônimo de internet, mas é importante ressaltar que ambos os termos se referem a conceitos diferentes, apesar de similares e integrados. Essa diferença será explicada na seção 2.2. O termo interface é utilizado, na grande maioria das vezes, como sinônimo de interface do usuário, ou seja, meio ou mecanismo de interação com o utilizador do software. Para alcançar o objetivo proposto, um breve histórico da computação e da internet é relatado na seção 2, alguns conceitos sobre fundamentos da internet, protocolos e padrões, na seção 3 e, na seção 4, são apresentados exemplos de como uma aplicação pode ser construída nesta arquitetura. É importante salientar que o trabalho não é uma revisão bibliográfica, nem se propõe a exaurir conceitos e a estrutura da internet, nem seus protocolos e convenções, sendo que essa discussão é apresentada apenas para subsidiar a descrição do processamento no lado do cliente. Por fim, as considerações finais são apresentadas na seção 5.

2 Breve histórico Essa seção relata brevemente a história da computação e da internet, visando trazer à luz o cenário no qual ambos surgiram e evoluíram. O foco dado nesta seção visa embasar o correlacionamento entre os dois movimentos de downsizing.

2.1 Do grande porte ao microcomputador Tanenbaum e Woodhull (2008, p. 25-32) descrevem que surgiram os primeiros computadores com aplicação fora do meio científico na segunda e terceira gerações dos computadores e sistemas operacionais. Chamados de computadores de grande porte, em inglês mainframe, eles eram acessíveis apenas às entidades governamentais e às grandes empresas porque eram grandes (alguns ocupavam salas inteiras), caros (custavam milhares de dólares) e complexos (eram manuseados apenas por técnicos especializados e por programadores). Nesse cenário, para otimizar a utilização dos computadores, utilizava-se processamento em lote e de forma compartilhada. O processamento em lote (batch), normalmente de forma desconectada (off-line), era a forma de executar várias atividades de forma sequencial e sem a intervenção do usuário. O compartilhamento do sistema computacional fazia com que esse sistema fosse dividido de forma gerenciada para mais de um usuário

2

e/ou que os recursos não utilizados pelo usuário principal fossem direcionados para outros usuários ou aplicações. (TANENBAUM; WOODHULL, 2008, p. 27-30) A partir do final dos anos 1970, surgiu a quarta geração dos computadores com os microcomputadores e os computadores pessoais - PC, do inglês personal computer. Tal geração se caracteriza pelo barateamento dos equipamentos, tornando-os acessíveis às pequenas empresas e até mesmo às pessoas. Essa possibilidade, já no período embrionário das redes e da internet, abriu à computação outras finalidades como, por exemplo, pequenos negócios, entretenimento e comunicação. Dessa forma, este panorama propiciou o surgimento de inúmeros equipamentos e ferramentas, impulsionando a computação para avanços ainda inimagináveis. (CZELUSNIAK, 2013, p. 56-57) Os avanços trazidos pela utilização nas pequenas organizações foram incorporados pelas grandes, dando início ao downsizing que é um processo de migração da plataforma de grande porte para os microcomputadores. Leiróz, Gaio e Souza (1997, p. 3) definem que o downsizing “envolve a migração de aplicações existentes em uma arquitetura de mainframe para uma baseada em plataformas de menor porte, bem como a transferência das funções referentes aos sistemas de informação para os usuários finais.” Eles afirmam ainda que, mais do que um processo tecnológico, é um processo de descentralização das informações de uma organização e isso também engloba a alteração dos sistemas e processos de trabalho envolvidos. Deve-se destacar que os computadores de grande porte não foram abandonados em detrimento da microcomputação, apenas algumas de suas funcionalidades se transferiram, especialmente aquelas realizadas próximas aos usuários finais. Czelusniak (2013, p. 57) pondera que o computador de grande porte continua a ter seu lugar de destaque atualmente “exercendo a função de computador central da rede, [sic] ou servidor.” Além da influência relacionada à questão tecnológica, o downsizing tem, no âmbito empresarial, motivação como a redução de custos e a busca por eficiência. Nesse sentido, a pluralidade de plataforma de hardware e de software propiciou a diversificação de fornecedores e de parcerias comerciais, bem como a diminuição do risco de aprisionamento tecnológico (vendor lock-in). Dessa forma, favoreceu a estratégia corporativa de descentralização que, junto com uma maior departamentalização das operações organizacionais, levou a descentralização dos sistemas de informação e a uma maior autonomia dos usuários finais. (LEIRÓZ; GAIO; SOUZA, 1997; LEIRÓZ; GAIO; SOUZA, 1998; PEREIRA; ERDMANN, 1998, p. 4, p. 1, 4, p. 1-2) Esse processo trouxe grandes avanços à sociedade moderna, principalmente a partir da desmistificação dos computadores para os menos familiarizados com tecnologia, fazendo com que eles se tornassem equipamentos do cotidiano já no final do século XX. Outro impacto positivo proporcionado pelo downsizing foi a possibilidade de que qualquer pequena empresa ou profissional liberal possa ter seu negócio apoiado por ferramentas computacionais, assim como o fomento à criação de novos negócios e nichos de mercado pelas pessoas comuns (BABA, 1988 apud LEIRÓZ; GAIO; SOUZA, 1998, p. 2-3).

2.2 As redes e a web Um dos marcos iniciais das redes de computadores foi o esforço do Departamento de Defesa dos Estados Unidos da América - EUA, nos anos 1950, para criar uma rede de comunicação que sobrevivesse a uma guerra nuclear. O resultado dessa iniciativa foi a ARPANET que era uma rede que utilizava alguns princípios presentes na internet de 3

hoje como, por exemplo, a descentralização. Outras redes surgiram nos anos seguintes, com destaque a NSFNET que era uma rede de pesquisa científica estadunidense, criada no final dos anos 1970. Quando o protocolo TCP/IP1 se tornou o único protocolo oficial da ARPANET, ela cresceu exponencialmente na quantidade de máquinas e usuários conectados. A partir de 1983, quando a NSFNET e a ARPANET foram interconectadas e o TCP/IP se firmou, muitas outras redes regionais dos EUA foram integradas, bem como redes do Canadá, da Europa e do Pacífico. Dessas “inter-redes”, em inglês inter-nets, surgiu a rede mundial de computadores que conhecemos hoje como internet (TANENBAUM, 2003, p. 53-62). Portanto, segundo Tanenbaum (2003, p. 53), “[a] Internet não é de modo algum uma rede, mas sim um vasto conjunto de redes diferentes que utilizam certos protocolos comuns e fornecem determinados serviços comuns.” Neste período, esse conjunto de redes foi marcado por uma diversidade de protocolos e suas principais utilizações eram correio eletrônico (e-mail), newsgroup, autenticação remota (Telnet, rlogin, SSH) e transferência de arquivos (FTP). A Web, World Wide Web ou simplesmente WWW, é a teia de alcance mundial, que interliga documentos através de vínculos de hipertexto (WWW, 2009). Surgiu em 1989 quando o físico Tim Berners-Lee do CERN2 propôs um padrão de troca de informação para facilitar a colaboração com outros cientistas na pesquisa de aceleração de partículas. Sua proposta se baseava no tráfego de documentos autorreferenciados que foram idealizados em 1945 por Vannervar Bush, professor de engenharia elétrica do Instituto de Tecnologia de Massachusetts - MIT. Esses documentos são o que conhecemos hoje como hipertextos. (TANENBAUM, 2003, p. 652-653) No primeiro momento, a web era composta por documentos estáticos em formato HTML, exibidos em softwares chamados de navegadores web (em inglês, web browsers). No final dos anos 1990, surgiram alguns recursos que permitiram mais interatividade especialmente com a geração de algum conteúdo dinâmico (essa evolução será discutida com mais detalhes na seção 3.5). Ao longo de seu contínuo desenvolvimento, algumas técnicas foram introduzidas para melhorar o desempenho e a confiabilidade da internet e dos sistemas construídos nela. Dentre eles, destacam-se caches e replicação de servidores: • Cache, também chamado cachê, é uma técnica na computação utilizada para acelerar o acesso a uma informação ou para evitar a repetição do consumo de algum recurso mais caro. No caso da internet, o cache é a replicação de informações em um local que permita o acesso mais rápido e/ou com maior banda de comunicação. Geralmente se usa servidores localizados em redes mais próximas (essa proximidade pode ser tanto 1

2

O termo TCP/IP se refere à combinação dos protocolos que são a base da comunicação na internet: o Protocolo de Controle de Transmissão - TCP (do inglês Transmission Control Protocol) e o Protocolo de Internet - IP (do inglês Internet Protocol). O primeiro é um protocolo de transporte orientado à conexão que provê a transferência confiável de dados enquanto o segundo provê a comunicação de pacotes de dados entre dispositivos de uma rede através de roteamento (escolha da melhor rota) dinâmicos e não preparados. Eles atuam de forma conjunta, onde o IP, próximo da camada física, realiza o transporte dos dados e o TCP, próximo das aplicações, gerencia e garante a consistência dessa comunicação. (TANENBAUM; STEEN, 2007; KUROSE; ROSS, 2010, p. 72; p. 4, 143-144) CERN é uma organização europeia para pesquisa nuclear. O acrônimo vêm do seu antigo nome: Conselho Europeu para Pesquisa Nuclear, em francês Conseil Européen pour la Recherche Nucléaire.

4

física quanto lógica). (FIELDING, 2000; TANENBAUM, 2003; KUROSE; ROSS, 2010, p. 44; p. 700-702; p. 81-84) • A replicação de servidores, também chamada de espelhamento, é uma técnica aplicada no lado do servidor na qual seu conteúdo é copiado em outras máquinas ou até mesmo em locais separados. A escolha de qual servidor deve ser acessado pelo cliente é configurável e depende da necessidade: pode-se fazê-lo por critérios geográficos ou por balanceamento da carga dos acessos. (TANENBAUM, 2003, p. 702-703) Especialmente nos últimos dez anos, a web se tornou na grande plataforma dentro da internet, tornando-se o meio mundialmente integrado com as mais diversas finalidades, como comunicação, entretenimento, comércio e educação. Essa questão é ainda mais intensa com a integração dos dispositivos móveis como telefones e tablets nessa rede.

3 Conceitos envolvidos Assim como nas demais redes de computadores, a web se fundamenta em um conjunto de padrões e protocolos que definem seus mais diversos aspectos, sendo que algumas dessas definições são mantidas pela IETF/W3C3 . Como exemplo, alguns protocolos e padrões são citados e categorizados abaixo: • Endereçamento: DNS, IP e URI; • Comunicação: FTP, HTTP, IP, SMTP, TCP e UDP; • Formato de conteúdo: MIME e codificação de caracteres4 . Nesta seção, alguns protocolos e conceitos são exibidos com o objetivo de facilitar o entendimento da arquitetura descrita na seção 4.

3.1 Arquitetura web A web funciona na internet, aproveitando-se dos recursos providos por ela como, por exemplo, a comunicação física e o mecanismo de endereçamento. É baseada na arquitetura cliente-servidor5 , implementada em rede de forma distribuída e descentralizada, do mesmo modo que a própria internet. Assim, a web necessita apenas de softwares para atuarem como cliente e como servidor na comunicação em um mesmo protocolo, o HTTP. Geralmente esse papel é desempenhado por um navegador e por um servidor web. Os clientes localizam os servidores desejados e fazem solicitações por conteúdo ou ações por parte do servidor. Os servidores respondem às requisições com conteúdo ou o resultado das ações sobre algum conteúdo. A figura 1 ilustra esse funcionamento: o navegador web do cliente apresenta um conteúdo que tem uma hiperligação para o servidor abcd.com que, por sua vez, contém uma página que aponta para outro servidor, 3

4 5

IETF (The Internet Engineering Task Force) e W3C (World Wide Web Consortium) são duas organizações internacionais com objetivo de levantar e solucionar problemas relacionados à internet, bem como padronizar a utilização da internet.(IETF, 2014; W3C, 2014) Tradução livre de charset encoding. Tanenbaum e Steen (2007, p. 22) lembram que “[...] a interação cliente-servidor também é conhecida como comportamento de requisição-resposta.”

5

Figura 1 – As partes do modelo da web (Fonte: Tanenbaum (2003, p. 654)).

o xyz.com. Quando o usuário aciona alguma hiperligação, o navegador inicia o processo de comunicação com o servidor que responde pelo endereço da ligação. Essa forma livre de hiperligação entre recursos e servidores foi a inspiração para que recebesse o nome de web, em português teia. É importante destacar que a arquitetura web foi concebida para ser leve e escalável. Essa característica permite que ela seja implementada, tanto como cliente quanto como servidor, até mesmo em dispositivos com poucos recursos de processamento e de memória, como, por exemplo, câmeras e aparelhos eletrodomésticos.

3.2 Protocolo URI O URI é um protocolo que define o nome ou o endereçamento de recursos em uma rede. O acrônimo vem do inglês Uniform Resource Identifier, Identificador Uniforme de Recursos. (BERNERS-LEE; FIELDING; MASINTER, 2005; RICHARDSON; RUBY, 2007, p. 7, p. 67) O protocolo foi estabelecido pela IETF/W3C na RFC 3986 com o objetivo de definir uma sintaxe simples e única para o endereçamento de recursos. A RFC é o resultado da junção dos conceitos de URL (acrônimo do inglês Uniform Resource Locators, LocalizadorPadrão de Recursos) da RFC 1738, URL relativo (expressão do inglês relative URLs para Relative Uniform Resource Locators, Localizador-Padrão Relativo de Recursos) da RFC 1808 e URN (acrônimo do inglês Uniform Resource Name, Nome Uniforme de Recurso) da RFC 2141. (BERNERS-LEE; FIELDING; MASINTER, 2005) Um URI pode ser um URL, que é uma referência a um recurso que depende da sua localização atual para encontrá-lo, ou um URN (Uniform Resoure Name), que, conforme Tanenbaum e Steen (2007, p. 344), “age como verdadeiro identificador”. (BERNERS-LEE; FIELDING; MASINTER, 2005; TANENBAUM; STEEN, 2007, p. 7, p. 344) Pode-se caracterizar URI pelos seus termos: • Identificador: “[...] personifica a informação requerida para caracterizar o que está sendo identificado das outras coisas no escopo da identificação.” Essa definição não 6

se preocupa em como seu propósito será alcançado; (BERNERS-LEE; FIELDING; MASINTER, 2005, p. 5) • Uniformidade: implica em padronização na identificação dos recursos na rede, proporcionando facilidades como na interpretação semântica dos identificadores dos recursos e na extensão onde novos tipos e cenários (seja pela adição de novos tipos de identificadores, seja na introdução de novas aplicações e protocolos) não interferem na utilização dos já existentes; (Id., 2005, p. 3) • Recurso: é utilizado de forma geral para algo que precisar ser identificado. Além de arquivos, equipamentos e serviços computacionais, pode também representar itens abstratos (por exemplo, um operador matemático ou uma relação de parentesco entre pessoas) e itens não-eletrônicos (por exemplo, uma pessoa ou uma cidade). (Ibid., p. 5)

Figura 2 – Componentes da URI (Fonte: Berners-Lee, Fielding e Masinter (2005, p. 16) com adaptações).

Conforme figura 2, uma URI consiste em uma sequência de caracteres com uma sintaxe genérica que combinam uma estrutura, uma hierarquia e um padrão de notação. Essa sintaxe consiste na sequência hierárquica de componentes chamados de protocolo (scheme), domínio (authority), caminho, consulta (query) e fragmento. (Ibid., p. 15-24) Uma característica importante das URIs é que elas devem permitir que seres humanos possam informá-las em um computador, mesmo com as limitações impostas por dispositivos de entrada e suas configurações de língua e localização. (Ibid., p. 7) Normalmente as pessoas precisam se lembrar das URIs, então, para facilitar isso, as URIs devem ser compostas por partes com significado ou que as pessoas se familiarizem facilmente. (Ibid., p. 7)

3.3 Protocolo HTTP O Protocolo de Transferência de Hipertexto - HTTP, do inglês Hypertext Transfer Protocol, é um protocolo da camada de aplicação para sistemas de informação hipermídia distribuídos e colaborativos (FIELDING et al., 1999, p. 7). O protocolo é implementado por meio de dois programas, um cliente e outro servidor, que conversam por troca de mensagens. (KUROSE; ROSS, 2010, p. 72-73) É usado como um protocolo genérico de comunicação entre clientes, proxies 6 /gateways 7 e provedores de serviços, permitindo o acesso aos recursos hipermídia disponíveis 6

7

Proxy é um sistema computacional intermediário que atua na mediação de requisições de clientes procurando por recursos em outros servidores. Nesse processo, pode fazer a tradução da requisição de acordo com a necessidade. (FIELDING et al., 1999, p. 9) Gateway é um sistema computacional intermediário que atua para traduzir protocolos e organizar redes, separando-as e interligando-as. Diferentemente dos proxies, os gateways recebem as conexões como se fossem o servidor de destino da comunicação final. (FIELDING et al., 1999, p. 9)

7

pelas mais diversas aplicações, incluindo as suportados por outros protocolos como SMTP, NNTP, FTP, Gopher e WAIS. (FIELDING et al., 1999, p. 7) Especifica a comunicação hipermídia da web desde o início de sua utilização em 1991. Na sua primeira versão, chamada de HTTP/0.9, era um protocolo para a transferência de dados brutos pela internet. O destaque da versão 1.0, de 1996, é a inclusão do suporte a outros tipos de dados com o uso de MIME8 , bem como a transmissão de metainformação sobre os dados comunicados. O HTTP/1.1, versão corrente especificada em 1999 pela RFC9 2616 IETF/W3C, se destaca pelas otimizações na compactação das mensagens e nos mecanismos de cache e pelo conceito de conexões persistentes para permitir o reuso de uma conexão. Pode-se resumir o HTTP como um protocolo de comunicação em estado não persistente no formato cliente-servidor de requisição e resposta que define como um cliente deve solicitar suas páginas e como os servidores devem transferir essa página para o cliente (KUROSE; ROSS, 2010, p. 73-74). O cliente faz uma requisição (request) a um servidor em uma rede e este, por sua vez, responde a solicitação recebida com o conteúdo e a situação que entender adequada (response)10 . Nesse processo, há uma negociação de conteúdo entre cliente e servidor para que a comunicação seja realizada segundo condições (formato de conteúdo, linguagem, etc.) que ambos aceitam. A descrição apresentada acima, representada na figura 1, traz uma visão simplista da comunicação HTTP. Existem outros elementos que fazem parte desse processo como proxies, gateways, caches, firewalls 11 e túneis12 , como também existe uma diversidade de arquiteturas e configurações desses elementos ao longo da internet. A figura 1 exemplifica um cenário simplista de comunicação. O protocolo define também a estrutura das mensagens utilizadas na comunicação, que são estruturadas em cabeçalho e corpo: o primeiro é o espaço para metacomunicação e o segundo, para o conteúdo da comunicação. O cabeçalho da requisição deve conter a ação desejada, expressa por um dos oito métodos HTTP listados a seguir: (FIELDING et al., 1999, p. 34-37) • OPTIONS: obter informações sobre as opções disponíveis na cadeia de comunicação de uma determinada URI. Essa opção permite ao cliente determinar os métodos 8

9

10

11

12

MIME: Extensões Multifuncionais para Mensagens de Internet, do inglês Multipurpose Internet Mail Extensions, é uma especificação da internet que define o formato de manipulação de conteúdo não textual e em padrões de codificação de caracteres não-ASCII. Essa definição é necessária porque, em geral, os protocolos e ferramentas da internet foram inicialmente projetados para utilizar o padrão de caracteres estadunidense ASCII. O MIME foi proposto na RFC 1341 e atualizado nas RFCs 2045 e 2049. (TANENBAUM, 2003, p. 635-641) RFC é um acrônimo em inglês de Request for Comments, Requisição por Comentários. Trata-se de um documento do IETF em formato de memorando que contém notas técnicas e organizacionais sobre a internet, incluindo protocolos, procedimentos, programas. Esses documentos possuem períodos de discussão e votação e, quando aprovados, definem um padrão da internet. Cabe destacar que, na comunicação HTTP, os termos cliente e servidor descrevem o papel que cada aplicação desempenha na conexão onde o primeiro a inicia por meio de uma requisição e o segundo a responde. (FIELDING et al., 1999, p. 8) Firewall é um componente de software e/ou hardware que funciona como um monitor, separando a rede do mundo externo e assim permitindo que o administrador controle o seu tráfego e o acesso a seus recursos por meio de filtros de pacotes de rede. (KUROSE; ROSS, 2010, p. 535-536) Túnel, ou modo de túnel, é uma forma de criação de uma comunicação privada entre dois dispositivos na internet, que é tipicamente uma rede pública. Assim, a comunicação ocorre de forma segura como se fosse na mesma rede. (TANENBAUM, 2003; KUROSE; ROSS, 2010, p. 822, p. 526-527)

8

suportados pelo servidor para a URI informada; • GET: obter do servidor o conteúdo de um recurso especificado pela URI. Pode funcionar de forma condicional com conteúdo em cache (por exemplo, If-Modified-Since) ou com o particionamento do conteúdo (If-Range); • HEAD: obter o cabeçalho de um conteúdo sem incluí-lo na resposta. Ele deve ser igual à resposta dada pelo método GET para um mesmo conteúdo. Este método é útil para diagnóstico de hiperligações, acessibilidade e controle de cacheamento de recursos; • POST: enviar um novo conteúdo subordinado ao recurso identificado pela URI da requisição para que seja armazenado no servidor. Neste método, o novo recurso não corresponderá exatamente à URI informada na requisição, visto que se trata de um “repositório” genérico de uma determinada classe de recursos; • PUT: enviar conteúdo para um recurso especificado pela URI e, caso já exista um recurso na URI especificada, a solicitação deve ser tratada como uma atualização deste conteúdo; • DELETE: excluir o conteúdo especificado pela URI. Caso o servidor deseje aceitála, essa operação não implica necessariamente que a exclusão será feita de forma automática ou física, uma vez que o servidor pode implementá-lo, por exemplo, com a participação humana (seja na aprovação, seja na exclusão propriamente dita); • TRACE: solicitar que o servidor devolva essa requisição por completo. Assim, o cliente pode analisar, para fim de diagnóstico da comunicação, as modificações e acréscimos que ocorreram na requisição por ação de servidores intermediários; • CONNECT: é utilizado para que proxies criem conexões seguras. Vale destacar que os métodos HTTP descritos acima são solicitações ao servidor e não implicam que suas operações serão realmente realizadas, pois a sua execução dependerá do tratamento dado pelo servidor, considerando as autorizações e as regras de negócio associadas à operação. Código Descrição 1xx Informação

2xx 3xx 4xx 5xx

Utilização Resposta provisória utilizada para enviar informações para o cliente de que sua requisição foi recebida e está sendo processada. Sucesso Indica que a requisição do cliente foi bem sucedida: recebida, entendida e aceita. Redirecionamento Informa que uma ação adicional deve ser tomada pelo cliente para completar a requisição. Erro do cliente Sinaliza ao cliente que há algum erro na sua requisição e que, por isso, ela não será atendida. Erro no servidor Avisa ao cliente que o servidor está ciente que ocorreu algum erro no processamento da requisição ou que ele não foi capaz de cumpri-la.

Tabela 1 – Classes de código de retorno do protocolo HTTP definidas na RFC 2616.

9

Por sua vez, o cabeçalho das respostas deve conter o código de retorno (status code) que indica o resultado da solicitação efetuada. Os códigos de retorno contém três dígitos e o primeiro dígito representa a sua classe. A tabela 1 lista as classes de código de retorno definidas para o protocolo. (FIELDING et al., 1999, p. 37-45)

3.4 HTML e CSS O HTML (HyperText Markup Language) é uma linguagem de marcação utilizada na internet para disponibilização de conteúdo em hipermídia, normalmente exibido no navegador do cliente. Sommerville (2007, p. 244) destaca que, além da exibição de conteúdo, o HTML é usado como base para a interação de interfaces baseadas na web. Sua notação permite a exibição de texto, imagens, áudio e vídeo, porém seu maior destaque é a capacidade de referenciar outros documentos por meio de hiperligações, em inglês hyperlinks (TANENBAUM, 2003, p. 652-654). Combinado com o protocolo HTTP, tem sido a base da disponibilização de conteúdo na web desde seu princípio. Na sua versão inicial, contemplava apenas os hipertextos, mas a linguagem evoluiu incorporando recursos como formulários de envio de dados do cliente para o servidor (versão 2.0), a exibição de tabelas (versão 3.0) e recursos de acessibilidade, objetos embutidos e scripts 13 , versão 4.0 (Ibid., p. 675). A versão 5 traz recursos para a exibição de multimídia e gráficos nativamente, sem a necessidade da utilização de plug-ins, e mais recursos de uso desconectado (off-line). Os arquivos HTML, normalmente com a extensão *.html ou *.htm, têm o formato de texto puro com os comandos padronizados de marcação da linguagem junto com o conteúdo textual do documento hipermídia. Essas marcações, chamadas de tags, são apresentadas entre os símbolos matemáticos de desigualdade < (menor) e > (maior). Cada página HTML, contendo um arquivo-base HTML, pode ser composta por diversos outros arquivos e objetos, referenciados por endereços URI. (KUROSE; ROSS, 2010, p. 73) O CSS (Cascading Style Sheets) é uma linguagem de definição de estilos utilizada para definir a aparência e o comportamento de documentos escritos em linguagens de marcação. Assim como o HTML, seu conteúdo é escrito em texto puro dentro dos próprios arquivos *.html ou em arquivos próprios com a extensão *.css. Quando utilizado em conjunto com o HTML, permite uma clara separação entre o conteúdo e sua formatação, tornando sua escrita e manutenção mais fácil.

3.5 Geração dinâmica de conteúdo Apesar da capacidade de formatação rica (especialmente quando combinado com CSS), o HTML apresenta apenas conteúdo estático nas páginas web. Por isso, outros componentes são necessários para dinamizar o conteúdo. Inicialmente se adicionou aos servidores web a capacidade de gerar conteúdo dinâmico por meio de recursos como CGI (Common Gateway Interface) e linguagens de script. Como destacam Tanenbaum e Steen (2007, p. 332-333), CGI é uma interface que determina como um servidor web pode executar um programa, fornecendo a requisição do usuário como entrada (comumente um formulário HTML) e o resultado do processamento como saída para o usuário. Essa extensibilidade permitiu a utilização de ferramentas e 13

Script é o código-fonte, em formato textual, de um programa para ser executado pelo interpretador da sua respectiva linguagem interpretada.

10

linguagens como C, C++ e Delphi. Já as linguagens de script, como Perl, PHP (Personal Home Page), Python e Ruby, incluíram a capacidade dos servidores web em executar scripts junto com HTML e CSS. A figura 3a exibe a configuração que um software servidor web pode ter.

(a) Componentes do servidor

(b) Componentes do cliente

Figura 3 – Componentes do cliente e do servidor (Fonte: Tanenbaum e Steen (2007, p. 693) com adaptações).

O processamento do lado do servidor satisfez necessidades básicas como a manipulação de formulários e a interação com o banco de dados (armazenamento e recuperação de informação). Porém, não permitia resolver questões de interação com o usuário como, por exemplo, responder a movimentos do mouse e utilização de dispositivos de hardware do usuário (TANENBAUM, 2003, p. 689). Essa limitação impacta fortemente na usabilidade nas páginas e nos sistemas desenvolvidos com esses recursos. Sommerville (2007, p. 182) relata que a solução para essa restrição foi o advento do código móvel, por meio da incorporação da capacidade de execução de scripts e objetos no navegador do usuário, conforme sugere a figura 3b. De forma análoga a própria linguagem HTML, esses scripts são transferidos para o navegador que tem a responsabilidade de executá-los. O resultado de sua execução é oferecido ao usuário no formato de eventos e alterações sobre o conteúdo HTML apresentado. O exemplo mais comum desse tipo de script é o JavaScript, já descrito na seção 3.6. (TANENBAUM, 2003, p. 689-691) Os objetos executáveis são miniaplicativos incorporados nas páginas HTML e são interpretados por alguma extensão do navegador. Os exemplos mais comuns são Java Applets, ActiveX e Adobe Flash: • Os Applets são miniaplicativos escritos e compilados em Java e executados pela JVM (Java Virtual Machine) do cliente por meio de um plug-in 14 do navegador. (Ibid., p. 692) • O Controle ActiveX, às vezes chamados de complementos, são pequenos programas escritos e compilados na plataforma Windows e executados pelo próprio sistema operacional do cliente, quando acionados pelo navegador. (Ibid., p. 692) • O Flash é um software que gera arquivos binários que podem ser executados por plugin no navegador ou por um software específico a ser instalado no cliente. Suporta 14

Plug-in é um módulo instalado no computador do cliente para estender as funcionalidades do seu navegador. Uma vez habilitado, ele funciona de forma integrada ao navegador quando o usuário acessa um conteúdo web. (TANENBAUM, 2003, p. 656)

11

gráfico vetorial, imagens, áudio e vídeo e são muito utilizados para criação de interações multimídias ao cliente como animações, vídeos, jogos e banners animados. Uma vez que não são parte da especificação da web, tanto a alternativa dos scripts quanto dos objetos executáveis possuem alguma fragilidade visto que apresentam algum tipo de incompatibilidade ou necessidade de configuração do ambiente do cliente (no navegador, no sistema operacional ou em ambos). Um exemplo ainda mais restritivo é o ActiveX que exige um sistema operacional da família de produtos Windows da Microsoft. Existem também questionamentos no que tange a segurança dessas três opções, visto que elas implicam na execução de código estranho na máquina do cliente. Esse assunto é tema de alguns estudos e debates, mas, neste trabalho limita-se a citar que os navegadores permitem configurar o nível de segurança aplicado ao código executado na máquina cliente. (Ibid., p. 869)

(a) Execução web no servidor

(b) Execução web no cliente

(c) Execução web no servidor com CGI

Figura 4 – Processamento no cliente versus no servidor (Fonte: 4a e 4b de Tanenbaum (2003, p. 691) e 4c de Tanenbaum e Steen (2007, p. 333) com adaptações).

Na figura 4a, a requisição a uma página PHP ou que contém parte PHP é feita ao servidor que, por sua vez, utiliza o seu módulo PHP para produzir o conteúdo HTML que é devolvido ao cliente. Neste cenário, todo o processamento é realizado no lado do servidor, com o cliente se restringindo somente à exibição do conteúdo HTML, como já faz na exibição de conteúdo estático. Diferente da execução de módulos como o PHP, quando se utiliza CGI, o servidor web faz a chamada ao programa CGI e, após seu retorno, repassa o resultado ao cliente. Esse cenário é caracterizado pela figura 4c. A figura 4b exemplifica o tratamento dado a um script JavaScript após ser carregado no cliente: o evento ou requisição é tratado localmente no próprio navegador por seu interpretador de JavaScript que realiza alterações no HTML o qual está sendo apresentado ao usuário. Observa-se que não há qualquer envolvimento do servidor. É possível que o script faça alguma requisição remota ao servidor, fato que caracterizaria os esquemas da figuras 4a ou 4c. Apesar dessa separação didática, é importante observar que, conforme destaca Tanenbaum (2003, p. 689-690), o processamento no cliente e o no servidor são geralmente usados de forma combinada. Além disso, embora pareçam semelhantes, são executados por componentes totalmente diferentes, conforme ilustra a figura 4. 12

3.6 JavaScript, JSON e AngularJS JavaScript é uma linguagem de programação interpretada, fracamente tipada e orientada à objetos lançada em 1995. A linguagem foi projetada com base em ideias da linguagem Java, porém com objetivo de permitir a interação direta do usuário com o navegador sem a necessidade de submeter o script para o servidor e, dessa forma, fazendo com que os navegadores web executem scripts do lado do cliente, como demonstrado na figura 4b. O programa escrito em JavaScript faz essencialmente a manipulação do documento web, bem como alguns outros eventos dos navegadores. Esses programas são encontrados em arquivos do tipo texto comumente com a extensão *.js ou nos próprios arquivos HTML. (TANENBAUM, 2003, p. 689) Tornou-se a linguagem de script web mais popular, incorporada nos mais diversos navegadores e presente na grande maioria das páginas web existentes. Contudo, a linguagem não é padronizada e muda com rapidez o que dificulta o desenvolvimento de programas compatível com as mais diversas plataformas. (Id., 2003, p. 689) O JSON, acrônimo do inglês JavaScript Object Notation, é um formato de intercâmbio de dados baseado na notação dos objetos literais de JavaScript. Os dados são escritos no formato de texto puro em forma de uma coleção de dados no formato chave e valor e deve respeitar a codificação de caracteres combinada entre o cliente e servidor. O principal objetivo do JSON é permitir que seu conteúdo disponibilizado possa ser lido por humanos ou máquinas. (CROCKFORD, 2008, p. 136) Em relação ao XML15 , uma vantagem do JSON é que ele dispensa a necessidade de interpretadores e validadores, dado que é escrito em formato JavaScript puro. De forma muito simplista, pode-se dizer que um conjunto de dados em JSON é um programa JavaScript limitado que pode ser “analisado” por funções nativas da linguagem. (RICHARDSON; RUBY, 2007, p. 37) AngularJS é um arcabouço16 escrito em JavaScript que implementa o padrão de projeto Model-View-Controller - MVC17 e é totalmente executado em um navegador web no lado do cliente. (KOZLOWSKI; DARWIN, 2013, p. 8) . . . AngularJS is 100% JavaScript, 100% client side and compatible with both desktop and mobile browsers. So it’s definitely not a plugin or some other native browser extension. (ANGULAR. . . , 2014)

Uma característica importante do Angular.js é a ligação bidirecional18 , também chamada de ligação em dois sentidos19 , entre os objetos da controladora e da visão. Essa bidirecionalidade é uma sincronização automática entre as camadas, fazendo com que qualquer alteração feita no objeto na camada controladora seja refletida na sua representação na camada de visão. (ANGULAR. . . , 2014) 15

16

17

18 19

XML (eXtensible Markup Language) é uma linguagem de marcação extensível que proporciona maior flexibilidade na definição dos elementos que marcam um documento por meio de uma metamarcação. (TANENBAUM; STEEN, 2007, p. 331) Arcabouço, em inglês framework, “é uma estrutura genérica que pode ser ampliada para criar um subsistema ou aplicação específica.” (SOMMERVILLE, 2007, p. 283) MVC, acrônimo em português para Modelo-Visão-Controlador, é um padrão de projeto implementado em camadas para projetos de interface com o usuário. (SOMMERVILLE, 2007, p. 283) Tradução livre de bi-directional data binding. Tradução livre de two-way data binding.

13

Um dos mecanismos mais úteis do Angular.JS é, na medida do possível, possibilitar que o desenvolvedor delegue ao arcabouço a responsabilidade pelo fornecimento do código compatível com o navegador do cliente que o acessa. Para isso, ele mantém uma interface estável e única para os desenvolvedores utilizarem em seus programas e, na camada que interage diretamente com o navegador, possui código compatível com os principais navegadores do mercado, incluindo as suas diversas versões.

3.7 Ajax Originalmente, AJAX era um acrônimo para JavaScript e XML Assíncronos, do inglês Asynchronous JavaScript And XML. Tratava-se de uma forma de construir aplicações web que executavam ações de forma assíncrona utilizando JavaScript e XML, com o objetivo de reduzir a necessidade de efetuar a atualização completa das páginas a fim de melhorar a sua usabilidade. Atualmente, o Ajax pode ser visto como um estilo arquitetural no qual aplicações web consomem serviços de forma assíncrona. Mantém-se toda a ideia original de funcionamento e resultado esperado, mas permite que outras tecnologias possam ser utilizadas no lugar do JavaScript (algum script do lado do cliente) ou do XML (formato de representação de dados). (RICHARDSON; RUBY, 2007, p. 257-258) Richardson e Ruby (2007, p. 258) descrevem a arquitetura Ajax segundo seu funcionamento: 1. O usuário acessa a URI principal da aplicação pelo navegador; 2. O servidor fornece a página com o script embutido; 3. O navegador exibe a página e executa o script; 4. O usuário interage com as funcionalidades da página; 5. A cada interação, o navegador executa a função correspondente no script e, caso necessário, faz chamadas assíncronas aos serviços remotos; 6. O servidor processa a requisição e fornece o resultado ao cliente. Normalmente essa resposta é fornecida em JSON ou XML; 7. A cada resposta recebida, o script no navegador analisa sintaticamente a resposta e utiliza seus dados para alterar a interface. Na perspectiva do usuário, a aplicação oferece uma melhor experiência de utilização, visto que a interface muda gradualmente de acordo com as ações do usuário. Em geral, essa gradualidade ocorre porque as alterações são aplicadas em partes específicas do documento HTML pelo próprio navegador, sem que seja necessário que o desenvolvedor crie e manipule componentes de tela na aplicação. Esse comportamento é semelhante ao das aplicações que são executadas do lado do cliente. (Id., 2007, p. 258, 261)

3.8 REST Transferência de Estado Representacional (REST), do inglês REpresentational State Transfer, é um estilo arquitetural para a construção de sistemas hipermídia distribuídos (PAUTASSO; ZIMMERMANN; LEYMANN, 2008, p. 807). 14

Foi conceituado por Fielding em 2000, quando ele defendeu a utilização da internet como ela fora definida nos seus primórdios, baseada na simplicidade de especificações básicas da internet como a do HTTP e a da URI. Xavier (2011, p. 39) afirma que o REST tem se popularizado com o crescimento da Web 2.0, especialmente a partir de 2006. A distinção central de REST para os demais estilos arquiteturais baseados em rede é a sua ênfase na uniformidade da integração dos componentes. Para isso, aplica o princípio da generalidade da Engenharia de Software20 na interface dos componentes, resultando na simplificação da arquitetura do sistema e na explicitação das interações entre esses componentes. (FIELDING, 2000, p. 81-82) Uma revisão bibliográfica em Martins (2012, p. 20-21) destaca os seguintes princípios REST: • Identificação de recursos por meio de URI: utilização de URIs para a identificação (e manipulação) de recursos. Para isso, essas URIs devem ser significativas e endereçáveis a fim de permitirem que o usuário as manipule e também seja capaz de entendê-las e se lembrar delas. (RICHARDSON; RUBY, 2007; XAVIER, 2011, p. 68-69, p. 41); • Interface uniforme: baseada nos métodos básicos do protocolo HTTP e cada um deve ser utilizado para um tipo de operação CRUD21 específica: HTTP PUT para inserção de um novo recurso (create), HTTP GET para recuperação do estado corrente (read), HTTP POST para alteração de estado de um recurso existente (update) e HTTP DELETE para exclusão de um recurso (delete)(PAUTASSO; ZIMMERMANN; LEYMANN, 2008; XAVIER, 2011, p. 807, p. 41-42). Mais os métodos para metacomunicação: HTTP HEAD para recuperar metadados de um recurso e HTTP OPTIONS para obter as operações permitidas pelo recurso. (RICHARDSON; RUBY, 2007, p. 79) • Mensagens autodescritivas: Fielding (2000, p. 121) sustenta que REST “exige que as mensagens entre componentes sejam autodescritivas para suportar o processamento imediato das interações.” Ele destaca que esse conceito foi evoluído a partir de algumas ausências de especificação do protocolo HTTP, como, por exemplo, a falta de identificação do host entre requisições; • Estado não-persistente: cada interação entre os recursos deve ser isolada, completa e atômica. Portanto, em toda comunicação, o cliente deve passar todas as informações necessárias para o servidor lhe satisfazer e o servidor responde com o recurso e sua representação, quando for o caso, sem contar com requisições anteriores ou posteriores (RICHARDSON; RUBY, 2007; FERREIRA, 2009, p. 70, p. 22-23). Contudo, Pautasso, Zimmermann e Leymann (2008, p. 807) e Xavier (2011, p. 42) salientam que existem técnicas como cookies, campos hidden em formulários e reescrita de URI que podem ser utilizadas para transferir estados nessas interações. Assim, “os estados podem ser embutidos nas mensagens de resposta para garantir a futura interação com estes.” 20

21

O princípio da generalidade recomenda que, para o problema apresentado, seja utilizada uma solução mais genérica porque ela pode ser mais simples, ter maior probabilidade de ser reutilizada e possuir alguma solução pronta de prateleira. (GHEZZI; JAZAYERI; MANDRIOLI, 2003, p. 52-53) CRUD é um acrônimo das palavras Create, Read, Update e Delete, em inglês, que representa as quatro operações básicas (criar, ler, alterar e excluir) utilizadas em bancos de dados relacionais ou em interface de sistemas para usuários. (KOZLOWSKI; DARWIN, 2013, p. 8)

15

• Conectividade e interações de estado através de hiperligações: utilização de hiperligações na representação do recurso para sua interação com outros recursos. Essa forma pode ser observada no comportamento das páginas web que contém hiperligações para outras páginas web e é uma característica fundamental em uma ambiente heterogêneo e descentralizado como a web (FERREIRA, 2009, p. 24). As hiperligações também são utilizadas para alterações de estados de recursos, apoiadas na semântica oferecida pelos endereços URI.

Figura 5 – Exemplos de requisições HTTP (Fonte: Richardson e Ruby (2007, p. 98-99, 145-147) com adaptações).

É importante frisar que a arquitetura definida por Fielding (2000) e reforçada por Richardson e Ruby (2007) dá um salto significativo na direção da simplificação da forma como a web é construída e utilizada. Primeiro na construção, essa intenção é evidenciada pela utilização de padrões e protocolos já existentes e largamente utilizados na internet. Em seguida para os usuários, o esforço pela simplificação da interface e pela identificação dos recursos tornam a interação compreensível até mesmo para os leigos, permitindo a eles inferir o significado de cada uma das requisições HTTP exibidas na figura 5.

4 Arquitetura web com processamento no cliente Como propósito principal deste trabalho, essa seção descreve uma arquitetura web com maior processamento no cliente para a geração dinâmica de conteúdo. Essa arquitetura é apresentada nas subseções a seguir, junto com o detalhamento das ferramentas e tecnologias utilizadas e os exemplos de implementação.

4.1 Estratégia arquitetural Para explorar o processamento no cliente, a estratégia utilizada é separar a aplicação em duas partes: a interface e o tratamento de dados. Nessa separação, sugere-se utilizar um modelo intermediário à dualidade dos modelos cliente-magro e cliente-gordo definidos por Sommerville (2007, p. 180). Assim, a interface (front-end) deve ser projetada para ser executada no cliente, junto com as regras de apresentação e o controle do fluxo de execução da aplicação. Do outro lado, o servidor deve ter a camada de dados (back-end) no sentido mais amplo, incluindo a implementação das regras de negócio, a persistência de dados e a integração com outras aplicações. Para implementar esse estratégia, decidiu-se combinar a arquitetura em camadas22 22

A arquitetura em camadas, chamada de multidivididas por Tanenbaum e Steen (2007), é caracterizada pela divisão física e/ou lógica de um software em camadas com responsabilidades específicas e claras. (TANENBAUM; STEEN, 2007; SOMMERVILLE, 2007, p. 24-26, p. 180, 201-202)

16

com a arquitetura Ajax. Assim, toda a interface com o usuário é construída segundo a arquitetura Ajax que, por sua vez, consome diversos serviços web desenvolvidos na quantidade de camadas necessárias. Essa decisão implica em duas consequências positivas: a primeira é que favorece a geração dinâmica de conteúdo no lado do cliente e isso, por consequência, permite a elaboração de uma melhor interação usuário-sistema. A segunda é que a utilização de serviços web simples e concisos incentiva o reuso e subsidia a sua escalabilidade. É importante destacar que não há necessariamente uma relação de exclusividade entre a aplicação Ajax e os serviços que ela consome. Isso implica que tanto a aplicação pode ser cliente de outros serviços, como os serviços podem ser consumidos por outras aplicações e serviços. Esse é o grande benefício dessa arquitetura e o que a torna tão flexível e escalável. Assim, o comportamento do sistema é similar ao descrito na seção 3.7 no qual o usuário acessa um conteúdo web que, junto com scripts embutidos, compõem uma aplicação que é executada completamente no navegador do usuário. Na medida do necessário, essa aplicação interage assincronamente com os serviços web necessários, especialmente quando precisar apresentar ou alterar alguma informação. Beneficiando-se da mecânica Ajax, a informação é apresentada na interface desse aplicativo sem a necessidade de recarregar por completo o conteúdo ou a aplicação. Esse modelo de aplicação composta por serviços é descrito por Sommerville (2007, p. 502-504).

4.2 As tecnologias envolvidas Tanenbaum e Steen (2007, p. 2-11) argumentam que a execução de software no cliente é um problema comum e esse desafio é agravado em ambientes heterogêneos como a internet. Ghezzi, Jazayeri e Mandrioli (2003, p. 36) detalham isso acentuando que os sistemas distribuídos requerem “a capacidade de componentes [de software] serem carregados e executados em diferentes máquinas”. Para lidar com isso, optou-se pela utilização de padrões e protocolos estabelecidos pela IETF/W3C e amplamente adotados na web porque, como realçam Richardson e Ruby (2007, p. 261), o navegado web é o cliente HTTP mais usado da internet. O conteúdo web nativo foi escolhido para a implementação da aplicação com a geração dinâmica da interface no cliente com código móvel, conforme discutido na seção 3.5. Assim, o processamento no servidor é reduzido visto que entrega ao cliente apenas a aplicação composta somente por HTML, CSS e JavaScript. Tanenbaum e Steen (2007, p. 332) destacam que a combinação de HTML com JavaScript proporciona um meio poderoso de expressar informação. Na ligação entre a interface e os serviços, Richardson e Ruby (2007, p. 217) recomendam a utilização do JSON para o intercâmbio de dados porque “é um formato de serialização para estrutura de dados em geral” e “é muito mais leve e legível que o documento XML equivalente”. Outras linguagens de marcação são utilizadas na internet e podem ser utilizadas nessa arquitetura. Porém elas não serão descritas neste trabalho visto que não serão utilizadas nos exemplos da arquitetura. Dentre elas, destacam-se XML, XSL (eXtensible Style Language), XHTML (eXtended HyperText Markup Language). Nos serviços web, os servidores continuam com o processamento de regras de negócio, 17

persistência de dados e integração com outras aplicações e, para isso, utilizam o padrão arquitetural REST de forma que estes serviços se tornam interoperáveis e independentes da tecnologia e da infraestrutura na qual são implementados e executados. Dessa forma, os serviços REST ligam a interface do usuário com os dados que ela manipula. É importante destacar que essa separação caracteriza um grande desacoplamento entre a interface e os serviços que ela consome. Esse desacoplamento permite até mesmo que eles sejam vistos como dois softwares distintos: um é a interface com o usuário final e consumidor de serviços, enquanto o outro, um provedor de serviços REST.

Figura 6 – Arquitetura com processamento no cliente (Fonte: o autor).

Neste trabalho, assim como o recomendado para aplicações reais e conforme explicita a figura 6, a interface e os serviços se tornam desacoplados ao extremo, separados logicamente e fisicamente em servidores e plataformas distintas. A interface dos exemplos apresentados no presente trabalho é construída com o arcabouço Angular.JS e hospedada em um servidor web Apache. Os serviços são construídos na plataforma Java, utilizando o arcabouço Spring MVC e executados no Jetty, que é um leve servidor web e servlet contêiner23 .

4.3 Recuperando e alterando dados Para ilustrar a arquitetura, foram escolhidos alguns cenários de CRUD, comuns em aplicações reais, nos quais a figura 7 ilustra: a figura 7a contém uma lista de clientes; a figura 7b, a exclusão de um cliente; a figura 7c, um cadastro de cliente; e a figura 7d, a atualização de dados de um cliente. O código-fonte desses exemplos pode ser acessado no endereço . O primeiro exemplo ilustra a visualização de uma lista de clientes. A listagem 1 contém o código do serviço REST responsável por recuperar a lista de clientes. Por questão 23

Sommerville (2007, p. 296) define que um contêiner é um conjunto de interfaces usado para fornecer acesso aos serviços de apoio. Tanenbaum e Steen (2007, p. 333) esclarece que um Servlet contêiner é um componente de um servidor web que, implementado segundo a especificação Java Enterprise Edition - JEE, interage com pequenos programas Java chamados servlets.

18

(a) Listagem de clientes cadastrados

(b) Exclusão de cadastro do cliente

(c) Cadastro de cliente

(d) Alteração de cadastro do cliente

Figura 7 – Interfaces da aplicação (Fonte: o autor).

de simplicidade, os detalhes da recuperação dos clientes foram abstraídos no método clienteService.listarTodosClientes(), mas se trata da implementação normal de dados de algum repositório. Por fim, a lista de clientes é transformada no formato JSON pela classe ListJsonFormatter para em seguida ser colocada no corpo da resposta (objeto response). Em casos reais, recomenda-se a utilização de alguma das diversas bibliotecas disponíveis na internet para realizar a conversão de dados entre os formatos JSON e Java. As listagens 2 e 5 contém trechos da interface web. Essa interface faz uma requisição HTTP GET para o serviço remoto na URL http://localhost:8080/clientes/ (linha 3 da listagem 2). Segundo o princípio da URI endereçável (ver seção 3.8), esta requisição significa: obter todos os clientes do servidor localhost. Quando o serviço REST devolve a lista de clientes no formato JSON, esta é exibida ao usuário pelos componentes HTML (linhas 6 a 9 da listagem 5), conforme a figura 7a.

19

Junto com a resposta da da requisição, a situação do resultado da operação é informada pelo serviço conforme códigos de retorno do HTTP: 404 (caso não a URL esteja incorreta), 500 (caso algum erro interno ocorra no servidor) e 200 (caso os dados sejam recuperados conforme esperado). As respostas implementadas neste trabalho estão listadas de forma resumida na tabela 2. Funcionalidade

Método HTTP

URL

Listagem dos clientes Carregar dados de cliente cadastrado Cadastrar novo cliente Alterar cliente cadastrado Excluir cliente cadastrado

GET GET

/clientes /cliente/{id}/

Código de retorno 200 200, 404

POST PUT DELETE

/clientes/cadastrar/ /cliente/{id}/ /cliente/{id}/excluir/

201, 400 200, 400, 404 200, 404

Tabela 2 – Resumo dos exemplos

No exemplo apresentado, a relação de clientes permite alguma interação. Observa-se na figura 7a que a relação de clientes apresenta duas opções: uma hiperligação e um botão X. A hiperligação carrega a opção de alterar dados de um cliente e o botão X aciona a exclusão do registro do cliente correspondente. A linha 9 da listagem 5 contém a chamada para a função JavaScript excluirCliente (listagem 4) que, por sua vez, aciona o serviço REST responsável por realizar a exclusão (listagem 3). 1

2

3 4 5

6 7

8

@RequestMapping ( value = " / clientes " , method = RequestMethod .←GET , produces = " application / json " ) public @ResponseBody void l i st a r To d o sC l i en t e s (←Ht tp S e rv l e tR e s po n s e response ) { response . setStatus ( HttpStatus . OK . value () ) ; try { response . getWriter () . print ( new Lis tJsonF ormatt er (←clienteService . l is t a rT o d os C l ie n t es () ) ) ; } catch ( IOException e ) { response . setStatus ( HttpStatus . I N T E R N A L _ S E R V E R _ E R R O R .←value () ) ; e . printStackTrace () ; } } Listagem 1 – Serviço REST para recuperação de clientes

Na interface, o cadastro de um novo cliente e a alteração de dados de um cliente já cadastrado são parecidos, diferindo-se apenas pela apresentação do identificador do registro. As figuras 7c e 7d evidenciam essa questão. A listagem 8 apresenta a interface do caso mais complexo, a saber, a alteração de dados. Neste caso, o botão de enviar aciona a função alterarCadastroCliente, descrita na listagem 6. No caso do cadastro de um novo cliente, o botão enviar aciona a função cadastrarNovoCliente, transcrita simplificadamente na listagem 7. Por fim, as listagens 9 e 10 exemplificam os serviços REST responsáveis, respectivamente, pelo cadastro e alteração de dados de um cliente. 20

1 2 3 4 5 6 7 8

9

$scope . carregarClientes = function () { var url = ’ http :// localhost :8080/ clientes / ’; $http . get ( url ) . success ( function ( data ) { $scope . clientes = data ; }) e x e m p l o _ l i s t a _ c l i e n t e s . error ( function ( exception ) { $scope . mensagem_erro = ’ Ocorreu um erro ao←tentar recuperar os clientes . ’ + ←exception ; }) ; }; Listagem 2 – Cliente para serviço de recuperação de clientes

1

2

3 4 5 6 7 8 9

@RequestMapping ( value = " / cliente /{ id }/ excluir " , method = ←RequestMethod . DELETE ) public @ResponseBody void excluirCliente ( H tt p S er v l et R e sp o n se ←response , @PathVariable String id ) { try { response . setContentType ( " application / json " ) ; response . s e t C h a r a c t e r E n c o d i n g ( " ISO -8859 -1 " ) ; clienteService . excluirCliente ( Long . parseLong ( id ) ) ; response . setStatus ( HttpStatus . OK . value () ) ; } catch ( N u m b e r F o r m a t E x c e p t i o n e ) { response . setStatus ( HttpStatus . BAD_REQUEST . value () ) ; } } Listagem 3 – Serviço REST para exclusão de um determinado cliente

1 2 3 4 5 6 7

8

$scope . excluirCliente = function ( _cliente ) { var url = ’ http :// localhost :8080/ cliente / ’; $http . delete ( url + _cliente . id + ’/ excluir ’) . success ( function ( data , status ) { $scope . carregarClientes () ; }) . error ( function ( exception ) { $scope . mensagem_erro = ’ Ocorreu um erro ao tentar ←excluir o cliente ’ + _cliente . id + ’: ’ + ←exception ; }) ; }; Listagem 4 – Cliente para serviço de exclusão de clientes

É importante destacar que, conforme descrito na seção 3.3 e, em especial, na tabela 1, as requisições HTTP esperam respostas significativas dos seus servidores. Por sua vez, os serviços podem (e devem) utilizar os códigos que forem necessários para dar significado ao seu processamento. Outros códigos comumente utilizados são: 202 “aceito”, 301 “movido”, 304 “não modificado”, 401 “não autorizado”, 405 “método não permitido” e 501 “não implementado”.

21

1 2 3 4 5

6 7 8 9

10 11

< h4 > Lista de clientes < table class = " table table - striped table - hover " > < thead > < tr > < th > Nome < th >e - mail < th > Renda < th > < tbody > < tr data - ng - repeat = " cliente in clientes | orderBy : ’←nome ’ " > < td > {{ cliente . nome }} < td > {{ cliente . email }} < td > {{ cliente . renda }} < button confirmed - click = " excluirCliente ( cliente ) " ng -←confirm - click = " Tem certeza que deseja excluir o ←cadastro do cliente ’{{ cliente . nome }} ’? " >x Listagem 5 – Interface de listagem de clientes

1 2

3 4 5 6

7 8

9

$scope . a l t e r a r C a d a s t r o C l i e n t e = function ( _cliente ) { $http . put ( ’ http :// localhost :8080/ cliente / ’ + _cliente . id , ←_cliente ) . success ( function ( data , status ) { $scope . resultado = data ; if ( status == 200) { $scope . resultado = ’ Cliente alterado com sucesso ! ’; ←}; }) . error ( function ( exception , status ) { $scope . resultado = ’ Ocorreu um erro ao tentar alterar os←dados do cliente ’ + _cliente . id + ’: ’ + exception ; }) ; }; Listagem 6 – Cliente para serviço de alteração de cliente

1 2 3 4 5 6 7

8 9 10

11 12

$scope . c a d a s t r a r N o v o C l i e n t e = function ( _novoCliente ) { var url = ’ http :// localhost :8080/ clientes / cadastrar ’; $http . post ( url , _novoCliente ) . success ( function ( data , status ) { $scope . resultado = data ; if ( status == 201) { $scope . resultado = ’ Cliente cadastrado com ←sucesso ! ’; }; }) . error ( function ( exception ) { console . log ( " error : " + exception ) ; $scope . resultado = ’ Ocorreu um erro ao tentar ←cadastrar um novo cliente : ’ + exception ; }) ; }; Listagem 7 – Cliente para serviço de cadastro de clientes

22

1

2

3

4

5

6 7 8

9 10 11

12

< form role = " form " > < div class = " form - group " > < label for = "←inputNome1 " > ID : {{ cliente . id }} < div class = " form - group " > < label for = " inputNome1 " > Nome < input type = " text " class = " form - control " id = " inputNome1 " ng ←- model = " cliente . nome " > < div class = " form - group " > < label for = " inputEmail1 " >E - mail < input type = " email " class = " form - control " id = " inputEmail1 " ←ng - model = " cliente . email " > < div class = " row " > < div class = " form - group col - xs -10 " > < label for = " i n p ut F a ix a S al a r ia l 1 " > Renda < select class = " form - control " id = " i n p ut F a ix a S al a r ia l 1 " ng -←model = " cliente . renda " > ... < button type = " submit " class = " btn btn - default btn - primary " ng ←- click = " a l t e r a r C a d a s t r o C l i e n t e ( cliente ) " > Salvar altera &←ccedil ;& atilde ; o de cadastro < button type = " reset " class = " btn active " > Cancelar altera &←ccedil ;& otilde ; es Listagem 8 – Interface de cadastro e alteração de clientes

1

2

3 4 5 6 7 8

9 10 11 12 13 14

15 16

17

@RequestMapping ( value = " / clientes / cadastrar " , method = ←RequestMethod . POST , consumes = " application / json " ) public @ResponseBody void cadastrarCliente ( @RequestBody ←Cliente novoCliente , H t tp S e rv l e tR e s po n s e response , ←WebRequest request ) { response . setContentType ( " application / json " ) ; response . s e t C h a r a c t e r E n c o d i n g ( " ISO -8859 -1 " ) ; try { Long novoId = clienteService . cadastrar ( novoCliente ) ; response . setStatus ( HttpStatus . CREATED . value () ) ; response . setHeader ( " Location " , request . getContextPath () + ←" / cliente / " + novoId ) ; } catch ( C l i e n t e C a d a s t r o I n v a l i d o E x c e p t i o n e ) { response . setStatus ( HttpStatus . BAD_REQUEST . value () ) ; try { response . getWriter () . print ( e . getMessage () ) ; } catch ( IOException e1 ) { response . setStatus ( HttpStatus . I N T E R N A L _ S E R V E R _ E R R O R .←value () ) ; } } catch ( Exception e ) { response . setStatus ( HttpStatus . I N T E R N A L _ S E R V E R _ E R R O R . value←() ) ; } } Listagem 9 – Serviço REST para cadastrar clientes

23

1

2

3 4 5

6 7 8 9 10 11 12 13 14

@RequestMapping ( value = " / cliente /{ id } " , method = ←RequestMethod . PUT , consumes = " application / json " , produces ←= " application / json " ) public @ResponseBody void alterarCliente ( @RequestBody Cliente ←cliente , H t tp S e rv l e tR e s po n s e response , @PathVariable String←id ) { try { response . setContentType ( " application / json " ) ; response . s e t C h a r a c t e r E n c o d i n g ( " ISO -8859 -1 " ) ; clienteService . alterarCliente ( Long . parseLong ( id ) , cliente )←; response . setStatus ( HttpStatus . OK . value () ) ; } catch ( N u m b e r F o r m a t E x c e p t i o n e ) { response . setStatus ( HttpStatus . BAD_REQUEST . value () ) ; } catch ( C l i e n t e C a d a s t r o I n v a l i d o E x c e p t i o n e ) { response . setStatus ( HttpStatus . BAD_REQUEST . value () ) ; try { response . getWriter () . print ( e . getMessage () ) ; } catch ( IOException e1 ) { response . setStatus ( HttpStatus . I N T E R N A L _ S E R V E R _ E R R O R .←value () ) ; } } } Listagem 10 – Serviço REST para recuperação de um cliente especificado

5 Considerações finais Este trabalho discorreu sobre o aumento da distribuição da utilização de recursos das estações cliente no ambiente da internet, especialmente o uso do processamento. Observase que há uma grande semelhança dessa descentralização do processamento web com o downsizing de plataforma computacional ocorrido a partir dos anos 1970. Para auxiliar essa comparação e a avaliação das suas vantagens e desvantagens, o presente trabalho inicialmente apresentou alguns conceitos, técnicas e, de forma tangencial, ferramentas e arcabouços. Também exemplificou algumas situações corriqueiras no desenvolvimento de sistemas para esta plataforma. O tema foi tratado de forma simplificada, mas já permite as conclusões apresentadas nesta seção. O desacoplamento entre interface e serviços sugerido pela arquitetura Ajax favorece a sua manutenção e evolução. Essa flexibilidade permite que os serviços sejam construídos de forma gradativa e com a infraestrutura na qual for necessária em cada momento do seu ciclo de vida. Os clientes veem os serviços na forma de seus contratos, abstraindo toda a complexidade que os compõem. A figura 8 representa as interfaces e a abstração possível de sua infraestrutura, caracterizando a sua flexibilidade. Percebe-se que o servidor HTTP pode utilizar recursos de balanceamento de carga de forma transparente aos seus clientes. Por sua vez, os serviços REST também podem se utilizar de outros recursos, como balanceamento de carga e repositórios para armazenamento de dados, sem que seus clientes tenham qualquer conhecimento a esse respeito. Qualquer componente desses pode ser alterado de forma transparente aos seus clientes, desde que os seus contratos sejam mantidos. A utilização pura do padrão arquitetural REST e consequentemente do protocolo HTTP facilita a interoperabilidade de forma transparente: desde que se respeitem os contratos definidos, os serviços e os clientes se comunicam, não importando em qual 24

Figura 8 – Interfaces e abstrações da arquitetura com processamento no cliente (Fonte: o autor).

tecnologia ou plataforma são construídos ou executados. Outro ponto que merece destaque é que, como a web é um ambiente aberto, tendo tanto usuários quanto desenvolvedores como atores, é comum o surgimento e a disponibilização de algum serviço ou ferramenta baseada nesse ambiente como ferramentas de busca e notificadores de conteúdo (RSS feeds). A facilidade da utilização de serviços de terceiros tem impulsionado o mercado de software e facilitado a construção de aplicações. Há um crescente movimento de disponibilização de serviços na web a cada momento, sendo que vários deles gratuitos. São serviços das mais diversas áreas e finalidades: a gestão de identidade de usuários, a localização de postos de gasolina em uma coordenada geográfica, o fornecimento de informações sobre filmes e a cotação de preços de produtos. Assim, seguindo o processo de Engenharia de Software Baseada em Componentes descrito por Sommerville (2007, p. 298299), a construção de aplicações passa pela identificação e composição de componentes existentes de maneira que é possível construí-las com recursos funcionais avançados, sem que isso implique necessariamente no empreendimento de um grande esforço de programação. Esse efeito, causado principalmente pelas estratégias adotadas na arquitetura apresentada na seção 4, tem impelido o mercado de software de forma análoga ao que ocorreu com a computação em razão do microcomputador, a partir dos anos 1980. A utilização de ferramentas e técnicas em prol do aumento de disponibilidade e confiabilidade do sistema é posta ao alcance dos arquitetos da solução por essa abstração de infraestrutura. Neste cenário, a adoção de técnicas de tolerância a defeitos preconizadas por Avizienis ( apud SOMMERVILLE, 2007, p. 319-321), como redundância e reexecução (retry on failure), se torna menos complexa. Do mesmo modo, também se torna mais acessível a utilização da escalabilidade oferecida por serviços de computação em nuvem (cloud computing). A separação utilizada nessa arquitetura permite que a volatilidade da interface seja tratada com a pluralidade de interfaces, sendo até mesmo de forma imperceptível para seus clientes. Dessa forma, um projeto pode segmentar a interface de seu produto por tipo de dispositivo cliente (telefones, tablets e computadores), enquanto outro projeto pode segmentá-la de acordo com a região geográfica da qual o usuário acessa o sistema. Nesse sentido, uma vantagem derivada é a possibilidade de lidar com versões legadas de interface 25

com maior tranquilidade, uma vez que portar a interface não se torna mais uma tarefa impeditiva para os demais clientes. Essa possibilidade é importante porque a interface é a parte mais suscetível de um sistema, tendo que se compatibilizar com os novos navegadores, assim como as novas versões dos navegadores já existentes, novos tipos de equipamentos como telefones e tablets e também com novos padrões e convenções como, por exemplo, o padrão tableless que, a partir do meio da década de 2000, pregava o desenvolvimento de páginas HTML sem a utilização de tabelas para formatação. É importante ressaltar que, mesmo com toda essa liberdade, os mecanismos de persistência de dados, tratamento de regras de negócio e validações estão presentes do lado do servidor, fazendo com que qualquer interface cliente do serviço se beneficie da mesma infraestrutura. Um aspecto negativo é o possível aumento de tráfego de rede e do consumo de serviços uma vez que a aplicação está distribuída e o serviço REST não guarda estado. Porém, Fielding (2000, p. 79-81) sugere a utilização de técnicas e ferramentas já presentes na internet como o cache para remediar esse problema. Assim, o tráfego seria evitado quando a informação ainda não tivesse sido alterada. Pautasso, Zimmermann e Leymann (2008, p. 807) acrescentam que, além de cache, existem outras técnicas que podem ser utilizadas para transferir estados nas interações como campos hidden em formulários e reescrita de URI. Assim, eles sugerem que “os estados podem ser embutidos nas mensagens de resposta para garantir a futura interação com estes.” (PAUTASSO; ZIMMERMANN; LEYMANN, 2008; XAVIER, 2011, p. 807,p. 42) Outro ponto desfavorável é que, como a informação é transitada em formatos padronizados como JSON ou XML, há uma perda de desempenho em necessidades específicas das aplicações em comparação com a utilização dos formatos próprios. Por exemplo, a transferência de vídeos em formatos como o Audio Video Interleave - AVI ou o Moving Picture Experts - MPEG tem melhor desempenho do que quando algum padrão genérico é utilizado. Porém, essa troca se justifica na utilização em larga escala da transferência de hipermídia, que é um formato otimizado na web, fazendo com que se beneficie dos padrões, do ecossistema e da escalabilidade da web. (FIELDING, 2000, p. 81) Como trabalhos futuros, sugere-se um aprofundamento do estudo do downsizing web, especialmente sobre os seguintes aspetos: 1. avaliação do impacto desse movimento sobre o ambiente da internet; 2. avaliação do desempenho e do consumo de recursos locais e remotos dos sistemas construídos com a interface executada no cliente; 3. comparação do desempenho dos sistemas construídos nesta estratégia com os sistemas com a interface processada no servidor; e 4. impacto causado na produtividade do desenvolvimento com a separação do desenvolvimento entre interface e serviços web. Nos mesmos moldes do downsizing de plataforma computacional, o downsizing do processamento web traz um avanço significativo no ecossistema da web, sobretudo porque auxilia no aumento de flexibilidade e agilidade no desenvolvimento e manutenção de produtos e serviços ofertados na web para os usuários finais. Essa agilidade é fundamental, especialmente pela grande dependência de sistemas nos dias atuais, conforme destacam 26

Martins (2012, p. 1-2) e Leiróz, Gaio e Souza (1997, p. 7), e também, como lembra Czelusniak (2013, p. 56-60), pelo papel desempenhado pela internet na propaganda das grandes empresas e no comércio eletrônico. Neste cenário, qualquer facilidade obtida pelos envolvidos se transforma em vantagem competitiva, fazendo a diferença dos negócios que prosperam para os demais.

Referências

ANGULAR JS: Miscellaneous : FAQ. 2014. Disponível em: . Acesso em: 06 abr. 2014. Citado na página 13. BERNERS-LEE, T.; FIELDING, R.; MASINTER, L. RFC 3986 : Uniform resource identifier (uri): Generic syntax. [S.l.], 2005. 61 p. Disponível em: . Citado 2 vezes nas páginas 6 e 7. CROCKFORD, D. JavaScript: The Good Parts. 1. ed. Sebastopol, CA, EUA: O’Reilly, 2008. 155 p. ISBN 978-0-596-51774-8. Citado na página 13. CZELUSNIAK, D. J. Arquitetura de Software Baseada em Agentes para Gerenciamento de Portfólio de Fontes de Informação Existentes na Web. 176 p. Tese de Doutorado em Engenharia de Produção — Universidade Federal de Santa Catarina, Florianópolis, 2013. Disponível em: . Citado 2 vezes nas páginas 3 e 27. FERREIRA, F. O. F. Serviços Semânticos: Uma abordagem RESTful. 103 p. Dissertação (Mestrado em Engenharia Elétrica) — Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Computação e Sistemas Digitais, São Paulo, 2009. Disponível em: . Citado 2 vezes nas páginas 15 e 16. FIELDING, R. et al. RFC 2616 : Hypertext transfer protocol – http/1.1. [S.l.], 1999. 176 p. Disponível em: . Citado 3 vezes nas páginas 7, 8 e 10. FIELDING, R. T. Architectural Styles and the Design of Network-based Software Architectures. 162 p. Tese (Doctor of Philosophy in Information and Computer Science) — University of California, Irvine, Irvine, CA, EUA, 2000. Disponível em: . Citado 4 vezes nas páginas 5, 15, 16 e 26. GHEZZI, C.; JAZAYERI, M.; MANDRIOLI, D. Fundamentals of software engineering. 2. ed. Upper Saddle River, NJ, EUA: Prentice Hall, 2003. 604 p. ISBN 9780133056990. Citado 2 vezes nas páginas 15 e 17. KOZLOWSKI, P.; DARWIN, P. B. Mastering Web Application Development with AngularJS. 1. ed. Birmingham: Packt Publishing, 2013. ISBN 978-1-78216-182-0. Citado 2 vezes nas páginas 13 e 15.

27

KUROSE, J. F.; ROSS, K. W. Redes de computadores e a internet: uma abordagem top-down. 5. ed. São Paulo: Pearson, 2010. 615 p. ISBN 9788588639973. Citado 5 vezes nas páginas 4, 5, 7, 8 e 10. LEIRÓZ, M. d. G. K.; GAIO, F. J.; SOUZA, J. M. d. A relação do produtor/usuário na adoção do "downsizing"no setor financeiro brasileiro. In: ASSOCIAÇÃO BRASILEIRA DE ENGENHARIA DE PRODUÇÃO (ABEPRO), XVII., 1997, Gramado, RS. Anais do XVII Encontro Nacional de Engenharia de Produção (ENEGEP). Gramado, RS: Associação Brasileira de Engenharia de Produção (ABEPRO), 1997. XVII. Disponível em: . Citado 2 vezes nas páginas 3 e 27. LEIRÓZ, M. da G. K.; GAIO, F. J.; SOUZA, J. M. de. A importância da parceria cliente/fornecedor e a participação dos profissionais como fatores estratégicos na adoção do "downsizing"no setor financeiro brasileiro. In: XVIII Encontro Nacional de Engenharia de Produção (ENEGEP). Niterói, RJ: Associação Brasileira de Engenharia de Produção (ABEPRO), 1998. XVIII. Disponível em: . Citado na página 3. MARTINS, L. M. C. e. Protótipo de implementação de workflow com REST : independência entre as tarefas do processo. 53 p. Monografia (Graduação em Sistemas de Informação), Taguatinga, Brasília, 2012. Citado 2 vezes nas páginas 15 e 27. PAUTASSO, C.; ZIMMERMANN, O.; LEYMANN, F. RESTful web services vs. “big” web services: Making the right architectural decision. In: THE INTERNATIONAL WORLD WIDE WEB CONFERENCES STEERING COMMITTEE (IW3C2), 17th., 2008, Beijing (China). Proceedings of the 17th International World Wide Web Conference (WWW2008). New York, NY, EUA: ACM, 2008. p. 805–814. ISBN 978-1-60558-085-2. Disponível em: . Citado 3 vezes nas páginas 14, 15 e 26. PEREIRA, E. C. O.; ERDMANN, R. H. Tendências em tecnologia de gestão com vistas à competitividade. In: XVIII Encontro Nacional de Engenharia de Produção (ENEGEP). Niterói, RJ: Associação Brasileira de Engenharia de Produção (ABEPRO), 1998. XVIII. Disponível em: . Citado na página 3. RICHARDSON, L.; RUBY, S. RESTful Serviços Web. 1. ed. Rio de Janeiro: AltaBooks O’Reilly, 2007. 340 p. ISBN 9788576081715. Citado 6 vezes nas páginas 6, 13, 14, 15, 16 e 17. SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Addison-Wesley, 2007. 552 p. ISBN 9788588639287. Citado 7 vezes nas páginas 10, 11, 13, 16, 17, 18 e 25. TANENBAUM, A. S. Redes de computadores. 4. ed. Rio de Janeiro: Elsevier, 2003. 945 p. ISBN 9788535211856. Citado 8 vezes nas páginas 4, 5, 6, 8, 10, 11, 12 e 13. TANENBAUM, A. S.; STEEN, M. v. Sistemas distribuídos: princípios e paradigmas. 2. ed. São Paulo: Pearson Prentice Hall, 2007. 402 p. ISBN 9788576051428. Citado 10 vezes nas páginas 4, 5, 6, 10, 11, 12, 13, 16, 17 e 18.

28

TANENBAUM, A. S.; WOODHULL, A. S. Sistemas Operacionais: Projeto e implementação. 3. ed. Porto Alegre: Bookman Companhia Ed, 2008. 990 p. ISBN 9788577800575. Citado 2 vezes nas páginas 2 e 3. THE INTERNET ENGINEERING TASK FORCE. The Internet Engineering Task Force (IETF). 2014. Disponível em: . Acesso em: 12 abr. 2014. Citado na página 5. THE WORLD WIDE WEB CONSORTIUM. About W3C. 2014. Disponível em: . Acesso em: 12 abr. 2014. Citado na página 5. WWW. In: MICHAELIS Moderno Dicionário da Língua Portuguesa. São Paulo: Melhoramentos, 2009. Disponível em: . Acesso em: 27 abr. 2014. Citado na página 4. XAVIER, O. C. Serviços Web Semânticos Baseados em RESTful: Um estudo de caso em redes sociais online. 136 p. Dissertação (Mestrado em Ciência da Computação) — Instituto de Informática - Universidade Federal de Goiás, Goiânia, 2011. Disponível em: . Citado 2 vezes nas páginas 15 e 26.

29