Aluno: Simião Lúcio Leal Queiroz
Professor: Vinícius
Ciência da Computação
Trabalho Final PSCD
SOAP
Características
Defini...
Aluno: Simião Lúcio Leal Queiroz
Professor: Vinícius
Ciência da Computação
REST
Cliente/Servidor
Sistema em Camadas
Cache
...
Aluno: Simião Lúcio Leal Queiroz
Professor: Vinícius
Ciência da Computação
Objetivo do Trabalho
1) Apresentar as principai...
Aluno: Simião Lúcio Leal Queiroz
Professor: Vinícius
Ciência da Computação
2) Apresentar os pontos negativos e positivos d...
Aluno: Simião Lúcio Leal Queiroz
Professor: Vinícius
Ciência da Computação
REST
Pontos Positivos
Linguagem e plataforma ag...
Próximos SlideShares
Carregando em…5
×

Trabalho Final PSDC - Simião

197 visualizações

Publicada em

Trabalho de Faculdade

Publicada em: Tecnologia
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
197
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Trabalho Final PSDC - Simião

  1. 1. Aluno: Simião Lúcio Leal Queiroz Professor: Vinícius Ciência da Computação Trabalho Final PSCD SOAP Características Definido pelo consorcio W3C. Protocolo baseado em XML para troca de informações em ambientes distribuídos. Padrão de utilização para WebServices. Normalmente utiliza HTTP como protocolo de transporte. Formato de mensagem Envelope: é o elemento principal do XML que representa a mensagem. Header: é o mecanismo genérico que permite a adição de características à mensagem SOAP de forma descentralizada, sem acordo anterior entre as partes comunicantes. Body: este elemento contém a informação a ser transportada. Especificação SOAP Envelope: Define o que há na mensagem e como processá-la. É a única parte do protocolo que é obrigatória SOAP Encoding Rules: Define um mecanismo de serialização que poder ser usado para troca de instâncias de tipos definidos pela aplicação SOAP RPC Style: Define uma convenção que pode ser usada para representar as chamadas e respostas remotas aos procedimentos. LINK SOAP HTTP: Define um protocolo que liga o SOAP e o HTTP. Ele descreve como as mensagens SOAP são transmitidas via HTTP. Envelope Cabeçalho SOAP
  2. 2. Aluno: Simião Lúcio Leal Queiroz Professor: Vinícius Ciência da Computação REST Cliente/Servidor Sistema em Camadas Cache Sem estado
  3. 3. Aluno: Simião Lúcio Leal Queiroz Professor: Vinícius Ciência da Computação Objetivo do Trabalho 1) Apresentar as principais diferenças conceituais e arquiteturais existentes entre a utilização do SOAP e do REST. SOAP x REST - Um webservice é uma maneira de uma aplicação comunicar com um servidor Web. Tradicionalmente, quem interage com um servidor web é um ser humano, através de um browser. Se trocarmos o ser humano por uma aplicação, a integração passa a ser por webservices. - Podem-se implementar webservices de várias maneiras. Duas delas ganharam notoriedade, por diferentes razões: SOAP e REST - SOAP é pegar numa mensagem XML, metê-la num envelope e enviá-la 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. Devido a utilização de alguns headers especiais, como tal precisam de uma biblioteca especifica. - REST é usar o HTTP como ele foi concebido, com GET, POST, PUT e DELETE (estes últimos dois quase não são utilizados). 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 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. Isto, porque ninguém no seu perfeito juízo implementa a comunicação SOAP à mão. 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 (muitas delas pagas, está claro). Teoricamente a idéia é boa. Pego num WSDL (que é a definição do webservice em XML) e gero uma molhada de código que sabe tratar aquilo. Desde que não se tenha que olhar para o código gerado, está tudo bem. Mas a law of leaky abstractions diz-nos que mais cedo ou mais tarde vamos ter que olhar para o código. E nessa altura, vamos chamar bastantes nomes ao SOAP e aos seus geradores de código. Um padrão recorrente em aplicações Web é a disponibilização da mesma funcionalidade via HTML e via Webservice. Se o WebService for REST podemos reutilizar tudo menos a apresentação, que no primeiro caso é em HTML e no segundo em XML. Isto porque o request HTTP são exatamente iguais. Se for 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 tem algumas semelhanças) e ir consumindo ao ritmo que entendermos. Por outro lado, juntando o peso de envelopar/desenvelopar as mensagens SOAP ao fato de os mecanismos de caching na Web não se aplicarem, temos um caso bicudo se planejarmos receber mais de algumas dezenas de pedidos Webservice por minuto. Visto isto, por vezes 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.
  4. 4. Aluno: Simião Lúcio Leal Queiroz Professor: Vinícius Ciência da Computação 2) Apresentar os pontos negativos e positivos de se utilizar uma ou outra tecnologia. SOAP Pontos Positivos 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 indepentente. Pontos negativos Diversos padrões. Complexidade dos padrões. Performance. Mensagens podem ficar muito extensas, por serem codificadas com XML
  5. 5. Aluno: Simião Lúcio Leal Queiroz Professor: Vinícius Ciência da Computação REST Pontos Positivos 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 infra-estrutura, 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. Pontos negativos 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.

×