Web service Soap vs Restful, http://carledwinj.wordpress.com/

1. Web Services
Web Services com
SOAP e REST

2. Introdução
Por volta de 1999, surgiu a necessidade de se padronizar a comunicação entre
diferentes plataformas (PC, Mainframe, Mac, Windows, Linux entre outros) e
linguagens de programaçao (PHP, C#, Java, etc).
Diversos padrões foram propostos, RPC,DCOM, CORBA, etc, mas nenhum
obteve êxito suficiente, tanto pela independencia de plataforma como pelo modelo
proposto.
É neste contexto que sujem os WEB SERVICES, como solução para uma
melhor comunicação entre os sistemas distribuídos.
Nesta apresentação falaremos sobre dois padrões para desenvolvimento
de web services o SOAP e o Rest.

3. Modelos de computação
Os web services surgiram na segunda metade da década de 90 como a evolução dos
modelos de computação, podemos citar entre eles:
● RMI (Remote Method Invocation) Invocação Remota de Métodos.
● DCOM (Distributed Component Object Model)
● CORBA (Common Object Request Broker Architecture)

4. RMI
Remote Method Invocation – Invocação de Método Remoto
É uma Interface que permite a
programas escritos em Java chamar
certos métodos em um servidor remoto.
A interface RMI permite que objetos
Java em hosts diferentes comuniquem-
se entre si.
Cada objeto remoto implementa uma
interface remota que especifica quais de
seus métodos podem ser invocados
pelos clientes. Os clientes podem
invocar métodos de um objeto remoto
quase exatamente da mesma maneira
que eles invocam métodos locais.

5. DCOM
Distributed Component Object Model –
Modelo de Componentes Objetos Distribuídos
É uma tecnologia proprietária da Microsoft
para a criação de componentes de software
distribuídos em computadores interligados
em rede.
Utiliza o RPC mecanismo de
transparência para enviar e receber
informações entre os componentes COM
(isto é, clientes e servidores ) na mesma
rede. Sua primeira versão surgiu em 1995
com o Windows NT 4.
Seu tipo de comunicação é cliente –
servidor.
Pode utilizar n protocolos de transporte,
como NetBios, TCP/IP, IPX/SPX e UDP.

6. CORBA
Common Object Request Broker Architecture –
Arquitetura de Objetos Distribuídos
É um padrão criado pela OMG (Object
Management Group) para permitir a integração
entre aplicações heterogêneas(diferentes) com
linguagens e em ambientes também
heterogêneos.
O DCE (Distributed Computer Environment) foi
o começo dessa tendência de computação
distribuída em empresas, porém o DCE não é
orientado a objetos, assim surgiu o CORBA, que
é uma arquitetura de objetos para computação
distribuída.
Utiliza ORM(request/response) módulo
intermediario entre o objeto e o cliente, e IDL
para interoperabilidade entre sistemas.

7. Origem dos web services
As tecnologias citadas anteriormente tiveram sucesso na integração de software em
ambientes de redes locais e homogêneos.
Quando a internet avançou para o mercado corporativo, surgiu também a necessidade de
integrar aplicações além das redes locais, por consequencia em ambientes heterogêneos, é
neste contexto que surge a tecnologia que chamamos de web services, proveniente de um
consórcio formado por grandes empresas como IBM, Microsoft e a BEA entre outras
pertencentes ao W3C.

8. Interoperabilidade
Não podemos falar de webservices sem falarmos sobre
interoperabilidade, que é:
A capacidade que componentes dentro de uma infraestrutura de TI
tem de conversar entre si. Assim, com interoperabilidade garante-se
que aplicações possam conversar de forma a trocar e processar dados
geridos por outras aplicações.
● Uma nova forma de trabalhar e disponibilizar serviços.
● Permite que qualquer aplicação acesse os serviços, independente da
linguagem.
● Acesso local(intranet) ou distribuído(internet).

9. Orientação a Objetos Vs Orientação a
Serviços
Orientação a objetos
Aproveita objetos e o mas o objeto pode não ser útil novamente dentro do contexto sendo
utilizado, pode ser necessário alterar o código e validar novamente.
Orientação a serviços
O serviço é totalmente aproveitável e não existe a necessidade de testá-lo novamente o mesmo já
foi validado. Processo de reutilização mais abrangente.

10. O que é Web Service
Web Service (Serviço Web)
É um conjunto de protocolos e padrões que servem para trocar dados entre aplicações.
Técnologia utilizada para integrar sistemas, impregada principalmente em ambientes
heterogêneos. Podemos desenvolver aplicações, softwares ou componentes capazes de
interagir, com outros softwares enviando ou recebendo informações, independente da
linguagem de programação, do sistema operacional ou hardware utilizado.
A única premissa é que para se comunicar com os web services deve-se usar o formato
XML.
Exitem atualmente dois padrões principais para desenvolvimento de web services: SOAP e
REST.

11. XML
eXtensible Markup Language - Linguagem Extensível de Marcação
Linguagem de marcação é um agregado de códigos que podem ser aplicados a dados
ou textos para serem lidos por computadores ou pessoas. Exemplos:HTML, XHTML e XML.
É uma linguagem de marcação recomendada pela W3C para a criação de documentos com
dados organizados hierarquicamente, tais como textos, banco de dados ou desenhos vetoriais.
A linguagem XML é classificada como extensível porque permite definir os elementos de
marcação.
O XML traz uma sintaxe básica que pode ser utilizada para compartilhar informações entre
diferentes computadores e aplicações.
Auxilia os sistemas de informação no compartilhamento de dados (especialmente via
internet), codificar documentos e inserir seriais nos dados comparando o texto com o de outras
linguagens baseadas em serialização.
Uma das suas principais características é sua portabilidade, pois, por exemplo, um banco
de dados pode escrever um arquivo XML para que outro banco consiga lê-lo.

12. XML - Sintaxe
<?xml version="1.0"?>
<raiz>
<filho1>
<filho2>
</filho2>
</filho1>
</raiz>

13. XML
Exemplo: Envio de mensagem de aviso.
<?xml version="1.0"?>
<aviso date="12/11/99">
<para>Janice</para>
<de>Jefferson</de>
<cabecalho>Lembre-se</cabecalho>
<corpo>Amanha voce tem prova de matematica</corpo>
</aviso>

14. XML
Exemplo: Envio de mensagem de aviso.

15. SOAP
Simple Object Access Protocol - Protocolo Simples de Acesso a
Objetos
É Protocolo Simples de Acesso a Objetos, é um protocolo de comunicação baseado em
XML que permite a comunicação de mensagens entre aplicações via HTTP, normalmente
utilizado em WebServices.
Uma das grandes qualidades desse protocolo é sua independência de plataforma e
linguagem além de ser simples e extensível por utilizar XML.

16. Arquitetura para web services
SOAP criada pela W3C
● WSDL (Descreve o WevService)
É um arquivo XML, que descreve detalhadamente um web
service, especificando suas operações e fomatos de entrada e saída R
de cada operação. eg
ser es
WSDL
vice
o istr
web açõ
● UDDI (Registra, Publica e Descobre Serviços do WS) 2 we a 1
b ep
re o form
É um mecânismo que armazena arquivos WSDL e fornece ao
3 se u
rv blic
provedor meios para que os web services sejam registrados e ic a
sob ém in
publicados, permitindo que os ws sejam pesquisados e localizados INTERNET e
pelos clientes.
t
Ob
● CLIENTE (Software consumidor de Serviços)
3 WSDL
É um software que consome as operações do web service e faz Efetua download
solicitações e recebe resultados do web service via XML. do WSDL
4 Envia solicitação XML
● PROVEDOR DE WEB SERVICES
5 Recebe resposta XML
É um componente que corresponde a um servidor de aplicações CLIENTE PROVEDOR DE
ou web container, dependendo do caso, em que o web service ficará WEB SERVICES
armazenado. O provedor de WS pode também armazenar o arquivo
WSDL.

17. SOAP na prática
O funcionamento dos web services na prática
não ocorre exatamente foi especificado.
Normalmente, a figura do UDDI não existe. Isso
faz com que a comunicação entre o Cliente e o
Provedor de web service ocorra sem WSDL
intermediações, conforme ilustrado ao lado. 1 Efetua download do WSDL
Outra questão prática que não pode ser
esquecida é que a W3C especifica que as 2 Envia solicitação XML
solicitações e respostas XML possam trafegar por 3 Recebe resposta XML PROVEDOR DE
CLIENTE
meio de qualquer protocolo como HTTP, FTP, SMTP, WEB SERVICES
TCP puro etc. INTERNET / INTRANET
O que vemos na prática é a utilização do XML
trafegando somente sobre HTTP, devido ser um
protocolo dominante já há muito tempo.

18. Formas de envio de
Mensagens ao web service
Exitem duas forma de envio de mensagem para que o cliente possa enviar solicitações
para web services:
● One Way Messaging: ● Request-Response Messaging:
Envio de mensagens unilateral, onde Envio de mensagens bilateral, onde o
o cliente envia uma solicitação se cliente envia uma solicitação ao web service,
preocupar com aresposta. que executa o processamento da solicitação
e envia resposta ao cliente.
O web service executa o
processamento da solicitação e não
enviará resposta ao cliente. Solicitação
Solicitação XML Web Service
Web Service Web Service Web Service
Client XML Client
Resposta
Sender - Remetente Receiver - Recebedor Sender - Remetente XML Receiver - Recebedor

19. RESTful
● Baseado na arquitetura Rest
● Crescente adoção

20. O que é REST
Roy Fielding, 2000
● Architectural Styles and the Design of Network-based Software Architectures
● Representational State Transfer (Transferência do Estado Representativo)
● Enfoque para Web
● Estilo arquitetural com foco nos recursos

21. Foco nos Recursos
● Tudo que é importante para aplicação
● Substantivos Alunos, Livros, Clientes
● Identidade de um recurso
● URI (Uniform Resource Identifier)
http://unip.br/alunos
http://unip.br/alunos/1234

22. Princípios do REST
● HTTP provê recursos suficientes para as transações
● Interface Uniforme

23. Verbos do HTTP
● GET – Obter
● POST - Inserir
● PUT - Alterar
● DELETE – Excluir

24. Representações
● Os recursos estão desassociados de suas representações.
Exemplos:
– text/html
– application/XML
– application/Json
– application/x-java-serialized-object

25. STATELESS
● Não mantêm o estado da transaçao.
● Requisições independentes.
● Facilita a escalabilidade.

26. Status Code
Cada requisição gera uma resposta contendo um status code.

27. Exemplo 1

28. Exemplo 2

29. Exemplo 3

30. SOAP Vs Rest
SOAP REST
● Protocolo de comunicação; ● Estilo de arquitetura de software;
● Maior complexidade e especificações bem ● Abordagem mais simples e menos
definidas burocrática
● Utiliza HTTP como meio de transporte; ● Fortemente relacionado e utilização
efetiva do protocolo HTTP.
● Permite diferentes protocolos para
transporte de solicitações e respostas; ● Não necessita de um contrato formal,
embora possa ser utilizado WSDL ou
● Utiliza WSDL para definir um conjunto de WADL
métodos do servidor
● Muitos recursos (URIs), métodos
● Poucas URIs, muitos métodos customizados uniformes

31. SOAP Vs REST

32. Conclusão
Depois desta apresentação nos perguntamos qual é o melhor SOAP ou REST?
A resposta é simples, DEPENDE de qual problema precisa ser resolvido. A cada artigo, livro ou
apostilas lidas sobre o assunto aumenta a dúvida, pois ambas arquiteturas oferecem condições
suficientes para resolver problemas. SOAP pode transportar informações por vários protocolos e
REST utiliza somente o HTTP, porém é mais fácil de implementar.....

33. Dúvidas

35. Referências 1
O que é RMI:
● http://www.ime.uerj.br/~alexszt/cursos/topesp_inter/trabs/992/g6/
DCOM:
● http://pt.wikipedia.org/wiki/DCOM
CORBA:
● http://tinyurl.com/cym3kcn
Como funciona o SOAP – Protocolo Simples de Acesso a Objetos
● http://zarelli.wordpress.com/tag/o-que-e-soap/
ARQUITETURA REST E O SERVIÇO WEB 'RESTFUL'.
● http://sao-paulo.pm.org/artigo/2010/RESTful
● RESTful Web Service tutorial: An Introduction for beginners
● http://tinyurl.com/c7rqnux

36. Referências 2
Livro : web Services SOAP em Java
● Autor: Daniel Adorno Gomes - Editora Novatec
O debate SOAP vs REST:
● http://www.inospito.net/2007/10/o-debate-soap-vs-rest/
Diferenças entre: XML-RPC, SOAP e REST:
● http://tinyurl.com/cokf2h3
Como funciona um web service REST
● http://www.matera.com/br/2012/10/como-funciona-um-webservice-rest/
AR
● http://sao-paulo.pm.org/artigo/2010/RESTful
● RE
● http://tinyurl.com/c7rqnux