Trabalho final psdc

186 visualizações

Publicada em

Trabalho final psdc

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
186
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Trabalho final psdc

  1. 1. CENTRO UNIVERSITÁRIO DO TRIÂNGULO INSTITUTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE CIÊNCIA DA COMPUTAÇÃO Trabalho PSDC Alunos: Plínio Ferreira da Silva Professor: Vinícius de Paula Uberlândia, 23 de junho de 2014.
  2. 2. 2 Sumário Diferenças conceituais e arquiteturais existentes entre a utilização do SOAP e do REST..................3 Pontos positivos e negativos...............................................................................................................5
  3. 3. 3 Diferenças conceituais e arquiteturais existentes entre a utilização do SOAP e do REST O SOAP e o REST são duas alternativas para fazer uma aplicação comunicar com um servidor Web. Nos padrões WS-*, as mensagens trocadas entre serviço e cliente consumidor devem ser armazenadas em envelopes SOAP. Este protocolo de comunicação dita um formato de envio de mensagens entre aplicações, o qual é descentralizado e distribuído, ou seja, qualquer plataforma de comunicação pode ser utilizada, seja ela proprietária ou não. SOAP utiliza uma mensagem xml, coloca em um envelope e envia por HTTP (embora o SOAP permita diferentes protocolos de transporte, na prática é HTTP). A resposta vem igualmente num envelope, em xml. Apesar de utilizar HTTP, esqueçam quaisquer mecanismos pré-existentes na linguagem/framework para comunicar em SOAP. Aquilo utiliza uns headers especiais, como tal precisam de uma biblioteca especializada. Mensagem SOAP REST é usar o HTTP como ele foi concebido, com GET, POST, PUT e DELETE (estes últimos dois quase não são utilizados mas estão na especificação desde o início). Ou seja, se sabem fazer submit de forms, sabem usar REST. A diferença é que o submit de um form devolve uma página em html, e um webservice REST devolve uma página em xml. O termo é geralmente usado para descrever qualquer interface que transmita dados de um domínio específico sobre HTTP sem uma camada adicional de mensagem como SOAP ou session tracking via cookies HTTP. Estes dois conceitos podem entrar tanto em conflito como em sobreposição. É possível desenvolver um sistema de software de acordo com as restrições impostas pelo estilo arquitetural REST sem usar HTTP e sem interagir com a Web. Também se torna possível projetar interfaces HTTP + XML que não condizem com os princípios REST de
  4. 4. 4 Fielding. Sistemas que seguem os princípios REST são referenciados também como “RESTful”. O SOAP não foi desenhado para resolver um problema, mas sim para vender ferramentas, ou não estivessem big players como a Microsoft ou a Oracle envolvidos. Pois não se implementa a comunicação SOAP manualmente. Quem definiu o standard, garantiu que o formato era suficientemente críptico e complexo para ser utilizável apenas recorrendo a bibliotecas/ferramentas de terceiros. Teoricamente a ideia é boa. Pego num WSDL (que é a definição do webservice em XML) e gero uma molhada de código que sabe tratar aquilo. Um padrão recorrente em aplicações Web é a disponibilização da mesma funcionalidade via HTML e via Webservice. Se o WebService fôr REST podemos reutilizar tudo menos a apresentação, que no primeiro caso é em HTML e no segundo em XML. Isto porque o request HTTP é exatamente igual. Se fôr em SOAP, praticamente temos que refazer/duplicar a componente servidor. Se pensarmos em aplicações Web de grande escala, o SOAP é a morte do artista. Primeiro porque as ferramentas insistem que se carregue sempre toda a mensagem para memória num DOM de objetos. Não podemos ir processando incrementalmente (streaming), tem que ir tudo para memória. Em REST, fazer streaming é limpinho: é só obter um InputStream para a HttpConnection (em Java, noutras linguagens há-de ser semelhante) e ir consumindo ao ritmo que entendermos. Por outro lado, juntando o peso de envelopar/desenvelopar as mensagens SOAP ao facto de os mecanismos de caching na Web não se aplicarem, temos um caso bicudo se planearmos receber mais do algumas dezenas de pedidos Webservice por minuto. Neste caso temos necessidade de implementar webservices em SOAP, seja por que o cliente comprou a ferramenta X, ou porque as aplicações clientes querem usar SOAP, etc. Por isso, seria melhor uma ferramenta do tipo do enunciate que garante que sem esforço adicional temos webservices para todos os gostos.
  5. 5. 5 Pontos positivos e negativos REST Pontos Positivos Pontos Negativos  Linguagem e plataforma agnóstica.  Simplicidade, interface imutável.  Interação assíncrona, não possui estado.  Facilidade de adoção, pois não requer uma grande infraestrutura, muito menos um middleware para WS-* ou camada intermediária adicional.  Utiliza a própria web como meio de transporte, sendo assim uma carga baixa para a rede.  Utilizada por grande parte das aplicações Web 2.0. (Google, Flickr, Amazon, etc..). Portanto, ótimo para mashups.  Curva de aprendizagem baixa.  Faltam padrões.  Falta de segurança (dados sigilosos não deveriam ser enviados como parâmetros na URI).  Não é indicado para trafegar grandes volumes de parâmetros via URI, no caso de PUT/POST para inclusão de dados, por exemplo.  Em muitas empresas apenas os métodos GET e POST do HTTP são liberados em proxies e firewalls. Dentro desta limitação, muitos preferem utilizar os métodos GET para requisições de consulta e POST para todo o resto.  Não há mecanismos de transação (Do it yourself)  Não existe um padrão como UDDI para service discovery. SOAP Pontos Positivos Pontos Negativos  Diversas ferramentas de desenvolvimento.  Tipagem forte e um vocabulário bem definido.  Quando utilizado sobre HTTP, dificilmente é bloqueado por proxies e firewalls.  Permite o uso de diferentes tipos de protocolos.  Plataforma independente.  Linguagem independente.  Diversos padrões.  Complexidade dos padrões.  Performance.  Mensagens podem ficar muito extensas, por serem codificadas com XML

×