Curso 174518 Aula 11 23a7 Completo

Aula 11
IFRJ (Analista de Tecnologia da

Informação) Engenharia de Software -
2021 (Pós-Edital)
Autor:
Equipe Informática e TI, Fernando
Pedrosa Lopes , Diego Carvalho
Aula 11
15 de Agosto de 2021
15176084732 - Leonardo Silva da Costa Gomes

Equipe Informática e TI, Fernando Pedrosa Lopes , Diego Carvalho
Aula 11
Sumário
Web Services..................................................................................................................................................2
1 – Conceitos Básicos .................................................................................................................................2
2 – SOAP (Simple Object Access Protocol) ................................................................................................7
3 – WSDL (Web Services Description Language) .................................................................................... 10
4 – UDDI (Universal Description, Discovery And Integration) ................................................................ 13
5 – Especificação de Metadados............................................................................................................. 16
6 – WS-Security (WSS) ............................................................................................................................ 20
7 – Protocolo HTTP ................................................................................................................................. 22
REST ............................................................................................................................................................ 30
1 – Conceitos Básicos .............................................................................................................................. 30
Questões Comentadas ................................................................................................................................ 37
Lista de Questões ........................................................................................................................................ 86
Gabarito .................................................................................................................................................... 103
IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

www.estrategiaconcursos.com.br
1
103
15176084732 - Leonardo
1184281
Silva da Costa Gomes
Aula 11
WEB SERVICES
1 – Conceitos Básicos
Com a evolução das redes de computadores, surgiram as aplicações distribuídas.

Inicialmente, todo o processamento era centralizado em apenas um servidor. Com o
surgimento dos middlewares, o processamento começou a ser distribuído entre vários
servidores. Com o avanço da internet e dos protocolos de comunicação, surgiram os Web
Services com a missão de integrar sistemas heterogêneos.
Web Services são componentes de aplicativos baseados em XML, autocontidos e

autodescritivos, que se comunicam usando protocolos abertos. Eles podem ser descobertos
com UDDI (veremos adiante!) e ser utilizados por outras aplicações. O XML é o formato de
mensagem adotado pela W3C para troca de informações entre aplicações distribuídas. Vamos
ver mais detalhes...
Eles são autocontidos, na medida em que não necessitam ou dependem de outros

componentes para existir – eles se bastam. Além disso, eles são considerados autodescritivos,
tendo em vista que não necessitam de informações externas para expor suas funcionalidades.
Por fim, eles utilizam protocolos abertos, i.e., não-proprietários – protocolos padrões da
internet.
Outra definição importante – citada por Heather Kreger – destaca que um Web Service é, na
verdade, uma interface que descreve uma coleção de operações que são acessíveis pela rede
através de mensagens XML padronizadas. Seu uso permite que plataformas heterogêneas de
software e hardware sejam integradas de forma transparente. Vejamos mais definições...
Web Service é a disponibilização de um serviço pela internet que pode ser acessado em qualquer
lugar. Clientes enviam requisições com informações bem definidas e recebem respostas que
podem ser síncronas ou assíncronas. Web Service é essencialmente a interoperabilidade entre
programas e aplicações – especialmente quando eles usam linguagens, ferramentas ou
plataformas diferentes.
Segundo a definição do Gartner, Web Services são componentes de software com baixo fator de
acoplamento, utilizado por meio de padrões de internet. Um Web Service representa uma
função/lógica de negócio ou um serviço que pode ser acessado por uma outra aplicação na
web, sobre redes públicas e, geralmente, disponibilizado por protocolos conhecidos.
A disponibilização de um serviço ocorre por meio de um contrato, que é uma interface que
disponibiliza suas funcionalidades, com uma infraestrutura leve e desacoplada de plataforma
que facilita a integração em diferentes tecnologias. Esta tecnologia possibilita que novas
aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em
plataformas diferentes sejam compatíveis.

2
103
15176084732 - Leonardo
1184281
Aula 11
Um Web Service é um sistema de software projetado para permitir interoperabilidade na

interação entre máquinas através de uma rede. É descrito através de uma interface
padronizada que disponibiliza um serviço em uma rede de computadores, geralmente a
Internet. Uma vez descrito na forma padrão e catalogado, o serviço se torna um componente de
software totalmente reutilizável.
Isso permite a interoperabilidade entre aplicações e plataformas heterogêneas. Eles

representam parte da lógica de negócio, executando em sistemas remotos que os hospedam
e os mantêm distribuídos. Podem ser acessados através de protocolos padronizados da
internet. Essa comunicação permite que qualquer aplicação que utilize estes protocolos acesse e
utilize serviços sem conhecer a implementação.
==121219==
Não, um cliente pode invocá-lo de forma síncrona ou assíncrona. Possibilitar chamadas assíncronas é a chave
para permitir sistemas fracamente acoplados.
Não, eles são baseados em XML (para representação e transporte de dados). Nesse último caso, ele elimina
qualquer dependência com rede e sistema operacional.
Eles são fracamente acoplados. A interface de um serviço web pode mudar durante o tempo sem comprometer
a habilidade do cliente de interagir com o serviço.
Sim, eles são independentes de plataforma, sistema operacional, arquitetura de processador, linguagem de
programação, entre outros.
Eles possuem granularidade grossa, provendo uma maneira natural de definir serviços que acessam a
quantidade correta de lógica de negócio.
Sommerville afirma que um Web Service é uma instância de uma noção mais geral de um serviço.
A plataforma de serviços web é definida através de uma série de padrões da indústria que são
suportados por toda a comunidade de fornecedores. Esta plataforma pode ser dividida em
duas gerações claramente identificáveis , cada uma associada com um conjunto de normas
e especificações:
▪ Web Services de Primeira Geração:
É composta por um núcleo de tecnologias e especificações abertas: WSDL, XSD, SOAP,

UDDI e o WS-I1. Essas especificações estão pelo mercado por um bom tempo e têm sido
adotadas pela indústria de tecnologia da informação. No entanto, a plataforma que eles
1
O WS-I Basic Profile é um conjunto de especificações de serviços da Web não proprietários, juntamente com esclarecimentos e alterações a
essas especificações que promovem a interoperabilidade.

3
103
15176084732 - Leonardo
1184281
Aula 11
coletivamente representam carece de qualidade para executar projetos críticos com

funcionalidades de produção em nível de organização.
▪ Web Services de Segunda Geração:
Uma das maiores lacunas de qualidade dos Web Services de Primeira Geração residia nas áreas
de segurança em nível de mensagem, transações entre serviços e mensageria confiável.
Surgiram, então, diversas extensões e especificações para fornecer um conjunto sofisticado
de componentes construídos sobre os Web Services de Primeira Geração – foram chamados
de WS-*.
O WS-* é composto atualmente por diversas especificações: Segurança (Ex: WS-Security, WS-
Trust, WS-Encryption, WS-SecureConversation); Políticas (Ex: WS-Policy, WS-
PolicyAssertions); Processos de Negócio (Ex: WS-CDL, WS-BPEL); entre outros. Galera, são
dezenas de especificações de diversos tipos – não vale a pena ver todos, vamos ver por
curiosidade apenas alguns deles:

4
103
15176084732 - Leonardo
1184281
Aula 11
Nessa aula, vamos nos ater aos Web Services de Primeira Geração! Utilizar serviços através da
rota dos Web Services basicamente envolve três categorias de participantes: Provedor de
Serviço, Solicitante do Serviço e Agente de Serviço (em inglês, Service Provider, Service
Requester e Service Broker) – basta lembrar do modelo arquitetônico triangular (Find-Bind-
Execute).
Um provedor de serviços seria, por exemplo, uma indústria, negócio ou empresa, capaz de criar
e fornecer serviços baseados em software. Do mesmo modo, um solicitante de serviços seria
uma empresa ou um negócio que gostaria de usar o serviço. Por outro lado, o agente seria um
lugar, entidade ou sistema, que ajuda o solicitante de serviços a descobrir o provedor de serviços.
As interações entre o provedor e o agente são basicamente a publicação dos serviços. A

interação entre o solicitador e o agente é a tarefa de pesquisar os serviços e os provedores de
serviços. Finalmente, a interação entre o provedor e o solicitante é chamada de vínculo (em
inglês, bind). De acordo com Schneider, algumas das vantagens de se utilizar Web Services são:
▪ Permite utilizar as regras de negócio através da rede;

▪ Baixo custo de comunicação (Internet);
▪ Conecta aplicações de diferentes fornecedores;
▪ Protocolo padronizado (SOAP/WSDL/UDDI);
▪ Permite publicação automática (UDDI).
Sabemos que Web Services são sistemas embasados na web que oferecem serviços gerais para
aplicações remotas, não requerendo interações imediatas de usuários finais – em geral a
interação é máquina-máquina ou aplicação-aplicação. Além da definição, é bom saber a
descrição dos três padrões fundamentais que possibilitam as comunicações, isso sozinho
resolve uma pancada de questões:
SOAP (SIMPLE/SINGLE OBJECT ACCESS PROTOCOL)

Baseado em XML, define uma organização para troca estruturada de dados entre Web Services.
WSDL (WEB SERVICES DESCRIPTION LANGUAGE)

Baseado em XML, define como as interfaces dos Web Services podem ser representadas.
UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION):

Baseado em XML, trata-se do padrão de descobrimento que define como as informações podem ser
organizadas.
Eu preciso da atenção de vocês agora! É possível implementar serviços utilizando diversos

paradigmas. O foco dessa aula é o Paradigma SOAP, mas existem outros (Ex: Paradigma REST).

5
103
15176084732 - Leonardo
1184281
Aula 11
No entanto, vocês verão algumas vezes as provas tratarem serviços apenas aqueles que
implementam SOAP, UDDI e WSDL. Não sejam muito rigorosos com isso...

6
103
15176084732 - Leonardo
1184281
Aula 11
2 – SOAP (Simple Object Access Protocol)
Trata-se de uma das formas de comunicação para encapsular dados transferidos no formato XML para Web
Services.
Trata-se de um formato, baseado em XML, para intercâmbio de mensagens – é utilizado para realizar o
encapsulamento e o transporte de dados.
Trata-se de um formato para envio e recebimento de mensagens independentemente de plataforma e
tecnologia.
Trata-se de um protocolo baseado em XML que define uma organização para a troca estruturada de dados
entre Web Services.
Um dos motivos que tornam os Web Services atrativos é o fato de estes serem baseados em
tecnologias padrão, em particular XML e HTTP. Eles são comumente utilizados para
disponibilizar serviços interativos na web, podendo ser acessados por outras aplicações. O
SOAP é o protocolo mais comum para troca de mensagens, já que é escrito em XML e
transportado, via de regra, por HTTP.
SOAP é um protocolo projetado para invocar aplicações remotas em um ambiente

independente de plataforma, linguagem de programação, entre outros. Ele é, portanto, um
padrão normalmente aceito para se utilizar com Web Services. Mas, professor, ele é o único? Não!
Veremos mais adiante... não se preocupem com isso nesse momento.
Bem, o que se pretende é garantir a interoperabilidade e intercomunicação entre diferentes

sistemas, através da utilização de uma linguagem (XML) e de um mecanismo de transporte
(HTTP). Pessoal, é obrigatório utilizar esse protocolo de transporte? Não! Pode-se usar qualquer
um, no entanto esse é o mais comumente utilizado no mercado atualmente.
Entre outras utilizações, SOAP foi desenhado para encapsular e transportar Chamadas RPC
e, para isto, utiliza-se dos recursos e flexibilidade do XML, sob HTTP. Por meio do RPC, pode-
se acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma
chamada local a este objeto. Cada chamada ou requisição exige uma resposta.
Galera, os elementos filhos imediatos do cabeçalho são chamados de blocos de cabeçalho.

Um bloco de cabeçalhos é um elemento XML definido pelo aplicativo e representa um
agrupamento lógicos de dados que pode ser direcionado em nós SOAP que podem ser
encontrados no caminho de uma mensagem de um remetente para um receptor final. Bacana?
Os blocos de cabeçalhos SOAP podem ser processados por nós intermediários SOAP e pelo nó
receptor SOAP final. No entanto, em um aplicativo real, nem sempre cada nó processa cada
bloco de cabeçalhos. Cada nó geralmente é projetado para processar determinados blocos de
cabeçalhos e cada bloco de cabeçalhos é processado por nós específicos.

7
103
15176084732 - Leonardo
1184281
Aula 11
Nós não dissemos ainda se SOAP é um protocolo Stateful ou Stateless, mas antes de
descobrir, temos que saber o que são esses conceitos. Stateful significa que o servidor
armazena informações sobre o cliente e as utiliza em diversas requisições. Stateless é justamente
o contrário, i.e., o estado do serviço não é persistido entre requisições subsequentes. O HTTP e
o SOAP, por default, são protocolos stateless.
O SOAP, definido pela W3C, consiste basicamente dos elementos descritos abaixo:
▪ Envelope (Envolope):
Trata-se do elemento-raiz do documento XML – identifica o documento XML como uma

mensagem SOAP. Ele funciona como um recipiente que contém os demais elementos da
mensagem (Ex: Header, Body, etc). Ele possui dois atributos: namespace, que define o Envelope
como um Envelope SOAP; e encodingStyle, que define os tipos de dados utilizados em um
documento. É obrigatório!
▪ Cabeçalho (Header):
Ele carrega informações adicionais específicas para a aplicação, como Autenticação,

Autorização, Pagamento, etc. Ele pode, por exemplo, especificar assinatura digital para

8
103
15176084732 - Leonardo
1184281
Aula 11
serviços protegidos por senha. Podem ser definidos vários cabeçalhos. Ele é opcional, mas – caso
seja utilizado – deve ser o primeiro elemento do Envelope. Ele tem três atributos:
mustUnderstand, actor e encodingStyle.
▪ Corpo (Body):
Ele contém o payload, i.e., a mensagem SOAP. Trata-se de um elemento obrigatório que é capaz
de empacotar chamadas RPC, reportar erros, enviar operações UDDI, entre outros. O elemento
Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e
mensagens de erros retornadas pelos nós ao processarem a mensagem. É obrigatório! Vejam
abaixo em negrito cada um desses elementos: Envelope, Header e Body.
POST /InStock HTTP/1.1

Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="https://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>

9
103
15176084732 - Leonardo
1184281
Aula 11
3 – WSDL (Web Services Description Language)
Trata-se de uma linguagem de descrição de Web Services, escrita em XML, para descrever serviços web,
especificar as formas de acesso, as operações e os métodos disponíveis.
Trata-se de uma linguagem para descrever serviços de rede como endpoints (ou portas) que operam em
mensagens que contêm informações orientadas à documento/procedimento.
Trata-se efetivamente de especificação que define como descrever serviços web em uma gramática XML.
Trata-se de um protocolo baseado em XML para troca de informações em ambientes distribuídos e

descentralizados (Sim, alguns o consideram um protocolo!).
Vocês já pensaram de que forma um cliente de um Web Service sabe qual formato dos métodos a
serem chamados? Quais os parâmetros que devem ser passados? Como se deve processar uma
requisição específica? Para responder essas questões, criou-se uma linguagem para padronizar
as descrições das funcionalidades oferecidas por um Web Service.
Essa linguagem, baseada em XML, é utilizada para descrever um Web Service e deve,
portanto, definir todas as suas interfaces, operações, métodos, esquemas de codificação, portas
de comunicação, protocolos, formatos de mensagens, entre outros, neste documento. Um
documento WSDL define um XML Schema (XSD) para descrever um Web Service.
Tão logo o cliente tenha acesso à descrição do serviço a ser utilizado, a implementação do Web
Service pode ser feita em qualquer linguagem de programação. Normalmente são utilizadas
linguagens construídas para interação com a Web, como Java Servlets ou ASP, que, em seguida,
chamam um outro programa ou objeto.
Quando o cliente deseja enviar uma mensagem para um Web Service, ele obtém a descrição do
serviço (em geral, por meio da localização do documento WSDL no UDDI), e em seguida constrói
a mensagem, passando os tipos de dados de acordo com a definição encontrada no
documento. Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado,
a fim de que possa ser processada.
O Web Service, quando recebe esta mensagem, valida-a conforme as informações contidas
no documento WSDL. A partir daí, o serviço remoto sabe como tratar e processar a mensagem
e como responder ao cliente. O WSDL possui um elemento-raiz do documento chamado
Description, que se trata de um contêiner de duas categorias de alto nível: WSDL 2.0 e Type
System.
O WSDL 2.0 é formado pelos componentes Interface, Binding e Service; já o Type System é
formado pelos componentes Element Declaration e Type Definition. O Element Declarations
é um conjunto de declarações de elementos, como definido por um XML Schema. Já o Type

10
103
15176084732 - Leonardo
1184281
Aula 11
Definitions é um conjunto de definições de tipos de dados – ele é obrigatório (Não confundam

com o elemento <types>).
Esse componente descreve sequências de mensagens que um serviço envia e/ou recebe. Ele o
faz agrupando mensagens relacionadas em operações (é o antigo <portType>). Interface →
Operações → Mensagens
Esse componente descreve o formato de mensagens e protocolos de transmissão que podem
ser usados para definir um endpoint. Ele define detalhes de implementação necessários para
acessar um serviço.
Esse componente descreve um conjunto de endpoints em uma implementação particular do
serviço que é fornecido. Endpoints são lugares alternativos em que serviços são fornecidos.
Galera, esses três componentes acima são componentes de

alto nível que são também elementos.
Há também o elemento <types>, que define tipos de dados

que serão utilizados nas mensagens e operações.
Há também o elemento <operation>, que se encontra dentro

do elemento <interface> e descreve as ações suportadas por
um serviço.
O WSDL separa a descrição de um serviço em duas perspectivas: Abstrata e Concreta! A

perspectiva abstrata trata da interface do serviço. Em outras palavras, ela descreve o que o
serviço faz – seus tipos, suas operações, suas entradas, suas saídas, suas mensagens fault, entre
outros –, porém sem dizer como o serviço faz o seu trabalho nem mesmo como acessar esse
serviço.
A perspectiva concreta trata da implementação do serviço. Em outras palavras, ela descreve

como realizará o serviço – protocolos de comunicação, codificação de dados, localização,
portas, endereço de rede, etc. A perspectiva concreta contém a perspectiva abstrata e adiciona
informações sobre como o serviço se comunicará e quem pode alcançá-lo. Professor, qual a
vantagem de haver essa separação?
Trata-se de separação de preocupações! A vantagem é que, caso a implementação do serviço

seja modificada por alguma razão, a parte abstrata pode continuar a ser disponibilizada sem
problemas – e até reutilizada para diversas implementações diferentes. Podemos ver, na
imagem acima, os elementos que compõem as perspectivas concretas e abstratas em ambas
as versões da linguagem.
De acordo com George Coulouris, os documentos WSDL completos podem ser acessados por
meio de seus URIs por clientes e servidores, direta ou indiretamente, por intermédio de um

11
103
15176084732 - Leonardo
1184281
Aula 11
serviço de diretório como o UDDI. Estão disponíveis ferramentas para gerar definições WSDL
a partir de informações fornecidas por meio de uma interface gráfica com o usuário.
Elas fazem isso ao eliminar a necessidade de envolvimento dos usuários com os detalhes
complexos e com a estrutura do WSDL. As definições WSDL também podem ser geradas a partir
de definições de interface escritas em outras linguagens, como JAX-RPC. Ele não define
características não-funcionais do serviço (Ex: tempo de resposta, escalabilidade, segurança).
Ademais, define quatro tipos de operações:
A operação pode receber uma mensagem, mas não retornará uma resposta.
A operação pode receber uma requisição e retornará uma resposta.
A operação pode enviar uma requisição e esperará por uma resposta.
A operação pode enviar uma mensagem, mas não esperará por uma resposta.

12
103
15176084732 - Leonardo
1184281
Aula 11
4 – UDDI (Universal Description, Discovery And Integration)
Trata-se de um serviço de diretório, baseado em XML, em que é possível registrar e localizar Web Services.
Trata-se de uma especificação técnica que tem como objetivo descrever, descobrir e integrar Web Services.
Trata-se de um diretório/registro para armazenamento de informações sobre Web Services – é um repositório

de interfaces de Web Services descritas por WSDL.
Trata-se de um protocolo que é um dos maiores blocos de construção requeridos para construir Web Services
com sucesso (Sim, alguns o chamam de protocolo!).
Trata-se de um padrão de descoberta que define como são organizadas as informações de descrição do serviço,
permitindo que os solicitantes descubram os serviços.
Quando se constrói um Web Service, ele deve ser disponibilizado em algum lugar para que seja
acessível por diversas aplicações-cliente. O UDDI é uma especificação técnica para descrever,
descobrir e integrar Web Services (alguns o chamam de protocolo também). Ele contém
informações genéricas sobre a organização que o detém e informações básicas sobre os serviços.
Vocês entenderam?
O UDDI descobre serviços por meio de registries, que são repositórios logicamente centralizados
e fisicamente distribuídos que contêm documentos descritores dos dados do negócio. As
informações capturadas no contexto do UDDI são classificadas em três categorias principais:
Páginas Brancas, Páginas Verdes ou Páginas Amarelas, como mostra a imagem abaixo com
seus respectivos exemplos:

13
103
15176084732 - Leonardo
1184281
Aula 11
As Páginas Brancas contêm informações gerais sobre a organização que está oferecendo o
serviço, tais como: nome do negócio e descrição do negócio (de preferência, em diversas
línguas). Utilizando essas informações, é possível encontrar algum serviço sobre o qual já se
pode conhecer algumas informações. Há também informações de contato do negócio (Ex:
Endereço, Telefone, Fax, Identificadores).
As Páginas Amarelas contêm uma classificação do serviço ou negócio disponíveis baseado

em taxonomias padronizadas (Ex: SIC, NAICS, UNSPSC). Como cada organização pode
fornecer uma série de serviços, pode haver várias páginas amarelas (cada uma descrevendo um
serviço) associadas a uma página branca (dando informações gerais sobre o negócio).
As Páginas Amarelas usam os esquemas de categorização industrial mais aceitos no mercado,

códigos de indústria, códigos de produtos, códigos de identificação comerciais e similares para
tornar mais fácil para as empresas procurarem por meio de listas e encontrarem exatamente o
que elas desejam. As Páginas Amarelas fornecem mais detalhes sobre a empresa.
As Páginas Verdes contêm informações técnicas sobre como acessar um Web Service. Elas
são utilizadas para indicar os serviços oferecidos por cada negócio, incluindo todas as
informações técnicas envolvidas na interação com o serviço. Em geral, essas informações
incluem um ponteiro para uma especificação externa e um endereço para invocar o serviço.

14
103
15176084732 - Leonardo
1184281
Aula 11
A Especificação UDDI fornece duas interfaces importantes: Publisher Interface e Inquiry

Interface. A primeira interface define dezesseis operações para que um provedor de serviços
possa gerenciar e publicar informações sobre um determinado serviço web. Já a segunda
interface define dez operações de busca de registro e informações específicas de registros.
Pessoal, não confundam uma coisa: WSDL não fica efetivamente no UDDI, mas lá existem
referências para ele! Ok? A UDDI 3.0.2 (versão mais recente) possui um Modelo de Informação
Estruturada: Core Data Structure. Ele é composto por uma estrutura hierárquica formada por:
Entidade de Negócio (Business Entity), Serviço de Negócio (Business Service), Template de
Ligação (Binding Template) e tModel.
O Business Entity representa o provedor de Web Services. Essa estrutura contém informações
sobre a organização, incluindo informações de contato, categorias de indústria, identificadores
de negócio e uma lista de serviços fornecidos. O Business Service representa um Web Service
individual fornecido por uma entidade de negócio – define tipo de serviço, conexão,
categorias, entre outros.
O Binding Template é um conjunto de descrições técnicas dos Web Services representados por
uma estrutura de serviços de negócio – ele indica, por exemplo, como se conecta ao serviço. Por
fim, o tModel representa um modelo técnico, i.e., uma maneira de descrever os vários
negócios, serviços, estruturas de template e informações externas (Ex: WSDL) armazenados
dentro de um Registro UDDI.

15
103
15176084732 - Leonardo
1184281
Aula 11
5 – Especificação de Metadados
Os professores e pesquisadores de países em desenvolvimento, que contam com recursos

escassos para a manutenção de suas Universidades e Instituições de Pesquisa, têm dificuldade
de acesso à literatura científica tradicional de sua área, sob a forma de periódicos, muitas vezes
altamente especializados e com assinaturas caras (quem se graduou em faculdade pública sabe
disso!).
Recentemente, com o surgimento dos periódicos eletrônicos, esse problema ainda persiste,
pois muitos só oferecem acesso aos artigos mediante pagamento. A cada dia, surgem
bibliotecas digitais e bases de dados públicas que constituem importante fonte de informação
para pesquisadores. O problema é o tempo que se gasta para reunir informações relevantes a um
dado assunto de pesquisa.
Seja visitando diversos portais de bibliotecas virtuais, seja utilizando a busca convencional
oferecida por sites como Google, Bing, entre outros. A pesquisa através de portais de busca
tradicionais é imprecisa e atinge apenas as páginas HTML, ignorando as bases de dados que se
encontram por trás de algumas destas páginas.
Por outro lado, ao tentar divulgar seus trabalhos através dos periódicos, em busca do impacto de
suas pesquisas, os pesquisadores esbarram em um processo burocrático e demorado, em que,
desde a submissão até a publicação, devido à lenta arbitragem que por vezes ocorre, pode
haver um intervalo de tempo tão longo que os efeitos daquela pesquisa já não tenham valor
quando de sua publicação.
Com a evolução da Internet, várias bibliotecas digitais começaram a surgir – algumas com a
finalidade de expor a produção de teses e dissertações das grandes universidades. Tudo isso
resultou em um grande avanço, em que informações científicas e acadêmicas já poderiam ser
obtidas livremente pela Internet, e disponibilizadas através da publicação nas páginas de seus
autores.
A falta de padrões para disponibilização e pesquisa de informações científicas na Internet

levou à criação da Iniciativa Open Archives (Arquivos Abertos) e ao desenvolvimento de um
protocolo com o intuito de oferecer simplicidade e eficiência na tarefa de unificar as consultas a
bases de dados científicas e/ou acadêmicas.
Com os recursos oferecidos pela iniciativa, é possível melhorar significativamente a precisão das
consultas eletrônicas e reduzir o tempo de procura, graças ao compartilhamento de informações
(metadados) entre os participantes da iniciativa. A interoperabilidade entre bases de dados
tem o objetivo de promover o acesso simultâneo aos dados contidos nestes repositórios de
forma a maximizar a pesquisa.

16
103
15176084732 - Leonardo
1184281
Aula 11
O protocolo OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) vem se
consolidando como a base para a interoperabilidade entre bibliotecas e repositórios digitais
acadêmicos e científicos no mundo todo. Através do OAI-PMH, é possível proporcionar
visibilidade e integração de informações (metadados), com custos acessíveis à realidade de
países em desenvolvimento, como o Brasil.
Então, vamos lá! Em 1999, surgiu a Open Archives Initiative (OAI), que buscava desenvolver e
promover soluções de interoperabilidade que facilitassem uma disseminação eficiente de
conteúdo. Para tal, foi criado um protocolo aberto, independente de conteúdo, chamado
OAI-PMH que faz com que participantes da iniciativa possam compartilhar seus metadados.
Lembrando que metadados são dados sobre dados, isto é, informações que descrevem
informações dos registros dos repositórios (similar a um dicionário) – no caso, documentos
eletrônicos. Para tal, ele segue um padrão que contém, entre outros, título, autor, resumo,
palavras-chaves, etc. Os participantes da Iniciativa são divididos em Provedores de Dados (DP) e
Provedores de Serviços (SP).
Os provedores de dados mantêm repositórios de documentos digitais que implementam o

protocolo OAI-PMH como forma de expor os metadados de seus documentos. Já os provedores
de serviços oferecem buscas a estes metadados ou outros serviços que visam agregar valor
à iniciativa. Galera, esse protocolo trata de um conceito muito importante chamado Harvesting.
O Harvesting (ou Colheita Automática de Metadados) é uma técnica ou processo unilateral para
extrair metadados de repositórios individuais e colocá-los em um catálogo central. Esse
processo é baseado nos metadados produzidos por humanos ou por processos
completamente automáticos ou semiautomáticos suportados por software. Bacana?
Provedores de Serviços (SP) realizam periodicamente uma busca a Provedores de Dados (DP) –
registrados em uma lista na OAI – para colher metadados para exibição sob a forma de consultas
efetuadas pelos usuários. Essa busca pode ser geral ou baseada em alguns critérios, tais como
Date-Based (baseados em data) ou Set-Based (baseados em conjuntos).
Existe outra abordagem chamada Federação (Federation). Trata-se de um mecanismo de busca

paralela, síncrona e simultânea sobre múltiplas fontes, i.e., o usuário faz uma pesquisa, que é
distribuída para motores de busca que participam da federação. Ele, então, agrega os resultados
que são recebidos dos motores para apresentar ao usuário. Vamos ver a imagem abaixo para
entender as diferenças:

17
103
15176084732 - Leonardo
1184281
Aula 11
Na Federation, o usuário faz uma requisição síncrona a um repositório central (representado por
uma Biblioteca Digital) e espera a resposta. O repositório faz diversas requisições a outros
repositórios remotos e as respostas retornam para o repositório central onde são
consolidadas e devolvidas para o usuário. Bacana? Agora vamos ver como funciona a outra
abordagem.
No Harvesting, o usuário faz uma requisição a um motor de busca que procura em um

repositório central de metadados (Harvested Metadata) que contém metadados
anteriormente coletados assincronamente e automaticamente de outros repositórios. Em geral,
os metadados são codificados em XML. Esse método é menos sofisticado e acarreta menor
sobrecarga sobre os repositórios.
Como a busca é executada em uma cópia local dos metadados, resultados podem ser
retornados com baixíssima latência. Além disso, como o harvesting é feito periodicamente,
mesmo que qualquer biblioteca esteja indisponível, ainda é possível buscar seus metadados.
Quanto à especificação de web services, existem diversas categorias de especificações
diferentes.
Estas especificações estão em diferentes graus de maturidade e são mantidas ou apoiadas por
vários órgãos e entidades de normatização. Esta variedade de especificações é a estrutura básica
de web services estabelecido pelos padrões de primeira geração representada por WSDL, SOAP
e UDDI. As especificações podem se complementar, se sobrepor e competir umas com as
outras.
Especificações de web services são ocasionalmente chamadas coletivamente de WS- *, embora

não haja um único conjunto de especificações que seja contemplada consistentemente por
ela, não existe um conjunto específico para eles. Para citar algumas dessas especificações: WS-
Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security e WS-Trust.
Provê um mecanismo pelo qual se pode identificar web services e mensagens

independentemente do protocolo de transporte utilizado.
Define um protocolo de descoberta multicast para localizar serviços em uma rede

local.
Define mecanismos para disparar realms de segurança para intermediar

informações sobre identidade, atributos de identidade e autenticação.
Permite que web services utilizem XML para advertir sobre suas políticas (de
qualidade, segurança, etc) e também para que clientes possam especificar suas
políticas.
Especifica como integridade e confidencialidade podem ser aplicadas em
mensagens e permitir a comunicação com vários formatos de token de segurança.

18
103
15176084732 - Leonardo
1184281
Aula 11
Provê extensões ao WS-Security, especificamente para lidar com emissão,

renovação e validação de tokens de segurança.

19
103
15176084732 - Leonardo
1184281
Aula 11
6 – WS-Security (WSS)
Vamos lá! Pensem comigo: eu falei alguma vez sobre segurança de Web Services? Não, porque o
Protocolo SOAP não prevê a proteção de mensagens, deixando essa tarefa para
especificações estendidas! Ora, mas SOAP é um protocolo que roda (na maioria dos casos2) sobre
o protocolo HTTP! É verdade, você tem razão! Ele é utilizado para troca de mensagens entre dois
nós.
Sobre o HTTP, é possível autenticar o remetente, assinar a mensagem e criptografar os dados.

Em outras palavras, o remetente é conhecido, o destinatário pode confirmar a integridade e
a mensagem se mantém confidencial. No entanto, nem sempre se utiliza esse protocolo; além
disso, ele possui diversas limitações quando a mensagem passa por diversos pontos.
2
O Protocolo HTTP só oferece segurança ponto-a-ponto! Muitas vezes, é necessário
segurança fim-a-fim. Ademais, pode ser necessária mais de uma chave de criptografia ao longo
da rota percorrida e domínios de segurança podem ser cruzados. Logo, para soluções mais
complexas, esse protocolo não satisfaz todos os requisitos de segurança.
O WS-Security utiliza diversos padrões e especificações de segurança pré-existentes. Ora,

para que reinventar a roda? Vamos utilizar o que já existe e está consolidado e evitar definir soluções
de segurança novas! Pode-se utilizar Kerberos e X.509 para fornecer autenticação; XML-
Encryption e XML-Signature para fornecer criptografia e assinatura do conteúdo das mensagens
XML.
O que de fato faz o WS-Security? Ele agrupa um conjunto de especificações em um framework

a ser embutido em uma Mensagem SOAP! Ele é utilizado para estender os mecanismos do
Protocolo SOAP para fornecer segurança (confidencialidade, integridade e não-repúdio) fim-a-
fim. Além das especificações citadas, ele também se associa ao WS-Privacy, WS-Test, WS-
Policy, WS-Trust, ID-WSD, TAS3, etc.
O WS-Privacy determinará de que forma os Web Services serão adotados e implementados.

O WS-Policy define como os recursos e restrições das normas de segurança poderão ser
expressados. Por fim, o WS-Trust descreve um modelo para que se obtenha um relacionamento
de confiança, tanto direto, quanto por meio de agentes (incluindo terceiros e intermediários).
Você pode me perguntar: Professor, por que não é utilizado o Protocolo HTTPS para garantir mais
segurança para Web Services? Faz muito sentido a sua pergunta! Ora, o Protocolo SSL/TLS é
capaz de fornecer diversos mecanismos de segurança. No entanto, ele funciona bem para
fornecer segurança em comunicação ponto-a-ponto, e nós precisamos de segurança em
comunicação fim-a-fim. Bacana?
2
Eventualmente, pode rodar sobre outros protocolos (tais como: JMS e SMTP).

20
103
15176084732 - Leonardo
1184281
Aula 11
O WS-Security define um Header SOAP para carregar dados relacionados à segurança. A

especificação diz: “This header contains security information for an intended recipiente”. Se for
utilizado o XML-Signature, o header pode conter informações que expressam como a mensagem
1
foi assinada, a chave utilizada e o valor resultante da assinatura.

21
103
15176084732 - Leonardo
1184281
Aula 11
7 – Protocolo HTTP
A primeira coisa que vocês podem me perguntar é: professor, isso não é uma disciplina de Redes
de Computadores? Sim, você está certo! No entanto, nosso intuito aqui é dar uma visão muito
mais restrita, sob a perspectiva de desenvolvimento de sistemas. O Protocolo HTTP (HyperText
Transfer Protocol) é um protocolo de comunicação utilizado para transferência de
hipertextos.
O que seria um hipertexto? Trata-se de um texto que pode ser integrado a diversas outras
formas de informação, como imagens, sons e outras mídias, acessíveis por meio de
hiperlinks. Dito isso, o que importa de fato para o desenvolvimento de sistemas? Bem, esse
protocolo define oito métodos (ou verbos), que nós veremos em mais detalhes mais à frente.
Embora tenha sido projetado para utilização na Web, o protocolo foi criado de modo mais geral
que o necessário, visando às futuras aplicações orientadas a objetos. Por essa razão, são aceitas
essas operações chamadas Métodos, diferentes da simples solicitação de uma página da
web. Essa generalidade permitiu que o Protocolo SOAP viesse a existir.
Cada solicitação consiste em uma ou mais linhas de texto ASCII, sendo a primeira palavra da
primeira linha o nome do método solicitado – os métodos internos estão listados abaixo. Para
acessar objetos gerais, também podem estar disponíveis métodos adicionais específicos de
objetos. Os nomes diferenciam letras maiúsculas de minúsculas; portanto, GET é um método
válido, mas get não é.

22
103
15176084732 - Leonardo
1184281
Aula 11
Esse método solicita ao servidor que envie uma página (ou um objeto, no caso mais genérico; na
prática, apenas um arquivo). A grande maioria das solicitações a servidores da web tem a forma de
métodos GET. No CRUD, ele seria o R(ead).
Esse método solicita apenas o cabeçalho da mensagem, sem a página propriamente dita. Esse
método pode ser usado para se obter a data da última modificação feita na página, para reunir
informações destinadas à indexação, ou apenas para testar a validade de uma URL.
Esse método é o inverso do GET, i.e., em vez de ler, ele grava a página. Esse método possibilita a
criação de um conjunto de páginas da web em um servidor remoto – o corpo da solicitação contém
a página. No CRUD, ele seria o U(pdate).
Esse método é semelhante ao PUT – porque também transporta um URL –, no entanto, em vez de
substituir os dados existentes, os novos dados são "anexados" a ele, em um sentido mais genérico.
No CRUD, ele seria o C(reate).
1
Esse método faz exatamente isso: exclui uma página. A exemplo do PUT, a permissão e a
autenticação têm papel fundamental. Não há garantia de que DELETE seja bem-sucedida, pois –
mesmo que o Servidor HTTP Remoto esteja pronto para excluir a página – o arquivo subjacente
pode ter um modo que impeça o Servidor HTTP de modificá-lo ou excluí-lo. No CRUD, ele seria o
D(elete).
Esse método serve para depuração. Ele instrui o servidor a enviar de volta a solicitação. Ele é útil
quando as solicitações não estão sendo processadas corretamente e o cliente deseja saber qual
solicitação o servidor, de fato, recebeu.
Esse método não é utilizado atualmente – ele é reservado para uso futuro.
Esse método fornece um meio para que o cliente consulte o servidor sobre suas propriedades ou
sobre as propriedades de um arquivo específico.
Esse método é bastante parecido com o PUT. No entanto, ele é utilizado para atualizar registros
parcialmente, enquanto o PUT atualiza o registro como um todo.
Galera, se chegar uma URL para o Servidor HTTP requisitando um serviço, o que ele fará? Ora, isso
depende do método utilizado! Quando chega a requisição, o servidor sempre implementará ao
menos dois métodos: HEAD e GET. Nosso interesse é no Método GET: ele é responsável por
solicitar recursos a um Servidor HTTP! Que recurso, professor? Pode ser qualquer coisa:
arquivos, scripts, etc.
Imagine que você faça a requisição acima! O que vem após a interrogação indica o início dos
dados passados através da URL, i.e., pelo Método GET! Observem o seguinte: eu requisitei
algum dado (arquivo, imagem, sons, etc) e para tal eu enviei algumas informações (aquilo após

23
103
15176084732 - Leonardo
1184281
Aula 11
a interrogação)! Vocês podem me perguntar: Professor, as informações são visíveis na URL

mesmo? Pois é, sim!
Vocês percebem como isso é perigoso? Viram que a minha senha está visível? Ela fica visível na URL!
Deiltel já dizia: Uma solicitação get não deve ser utilizada para enviar dados sigilosos porque
os dados do formulário são colocados em uma string de consulta que é acrescentada ao URL
do navegador como texto simples e pode ser interceptada. Lembrando que, por padrão, é
utilizado o GET.
Para resolver esse problema, eu posso utilizar o POST. Ele funciona de modo bastante similar,
entretanto os dados são colocados no corpo da requisição e não aparece diretamente na URL!
Melhor, não? Só isso? Não! GET é utilizado para recuperar informações (em geral, poucas); POST
é utilizado para enviar informações (em geral, muitas – por meio de formulário). Vamos ver
outras diferenças: 9
Sem problemas. Dados deverão ser retransmitidos.
Pode ser adicionado aos favoritos. Não pode ser adicionado aos favoritos.
Pode ser armazenado em Cache. Não pode ser armazenado em Cache.
Parâmetros permanecem no histórico Parâmetros não permanecem no histórico

do browser. do browser.
Limitado a 2048 caracteres (enviado na Sem restrições de tamanho.
URL).
Somente caracteres ASCII. Sem restrições de tipo de dados.
É menos seguro, devido a visibilidade. É mais seguro, devido a visibilidade.
Agora, vamos examinar como as conexões seguras podem ser alcançadas. Quando a web
repentinamente chegou ao público, ela foi usada no início apenas para distribuir páginas
estáticas, mas – em pouco tempo – algumas empresas tiveram a ideia de usá-la para transações
financeiras, como a compra de mercadorias por cartões de crédito; transações bancárias e
mercado de capitais eletrônico.
Essas aplicações criaram uma demanda por conexões seguras. Em 1995, a Netscape, que então
dominava o mercado de fabricantes de navegadores, respondeu introduzindo um pacote de
segurança chamado SSL (Secure Sockets Layer) para atender a essa demanda. Esse software
e seu protocolo agora também são amplamente utilizados por diversos navegadores.

24
103
15176084732 - Leonardo
1184281
Aula 11
A SSL constrói uma conexão segura entre dois soquetes, incluindo: negociação de parâmetros
entre cliente e servidor; autenticação mútua de cliente e servidor; comunicação secreta; e
proteção da integridade dos dados. Efetivamente, trata-se de uma nova camada colocada
entre a camada de aplicação e a camada de transporte, aceitando solicitações do navegador
e enviando-as para o servidor.
Depois que a conexão segura é estabelecida, a principal tarefa da SSL é manipular a

compactação e a criptografia. Quando o HTTP é usado sobre a SSL, ele se denomina HTTPS
(Secure HTTP), embora seja o Protocolo HTTP padrão. Às vezes, ele está disponível em uma
nova porta (443), em lugar da porta padrão (80). Aliás, SSL não se limita ao uso apenas com
navegadores, mas isso é o mais comum.
Por fim, vamos falar rapidamente sobre Idempotência. Méquié, professor? Um Método HTTP
idempotente é aquele que pode ser chamado muitas vezes sem resultados diferentes. Não
importa se o método for chamado apenas uma vez, ou dez vezes mais, o resultado deve ser o
mesmo! Mais uma vez, isso se aplica apenas ao resultado e não ao próprio recurso. Vamos ver
um exemplo bastante simples:
a = 4;
Eu posso executar esse comando 800 vezes e eu vou obter sempre o mesmo resultado – ele é
idempotente. Agora vejam o exemplo abaixo:
a++;
O resultado será sempre diferente: 5, 6, 7, etc – ele não é idempotente. Dito isso, nós
podemos imaginar quais Métodos HTTP são idempotentes:
SIM
NÃO
SIM
SIM
SIM
SIM
NÃO
Ué, professor! Por que o POST não é idempotente? Porque cada vez que eu insiro algum dado em
uma tabela, por exemplo, por meio do POST, eu aumento o tamanho dessa tabela, logo o
resultado não é sempre o mesmo. E quando o resultado não é sempre o mesmo, nós sabemos
que não se trata de um método o quê? Idempotente! Certinho?

25
103
15176084732 - Leonardo
1184281
Aula 11
SIM
NÃO
NÃO
NÃO
SIM
SIM
NÃO
A tabelinha acima mostra também os métodos que são seguros. O que é segurança nesse
contexto, galera? Um método é considerado seguro se ele não modifica os recursos. Logo,
POST, PUT, DELETE e PATCH são inseguros, visto que os recursos são modificados após a
execução desses métodos. Já GET, HEAD e OPTIONS são seguros, visto que não modificam os
recursos.
Sabemos que HTTP é um protocolo Stateless! Isso quer dizer que o Servidor Web, somente com
o que oferece nativamente o HTTP, não sabe se sua requisição de agora e outra daqui a 10s são
pertencentes a mesma sessão ou não. Então, como sempre que entro no Facebook, ele sabe meu
nome? Quando entro num site e parece que estava logado, mesmo eu tendo acabado de ligar o
computador?
Uma forma de trabalhar com dados stateful é justamente utilizar informações armazenadas em
cookies. O cookie HTTP, também chamado de cookie web, cookie de Internet, cookie de

26
103
15176084732 - Leonardo
1184281
Aula 11
navegador ou, simplesmente: cookie; é um pequeno conjunto de dados enviado por um

servidor web e armazenado no computador do usuário pelo navegador, enquanto ele está
navegando.
A especificação de como os cookies funcionam foi publicada como a RFC 6265 e será nossa
grande fonte de informações (somente aquilo que é cobrado nos concursos, obviamente). Os
cookies foram criados como um mecanismo para sites se lembrarem de informações dentro
de uma sessão (Ex: como os itens num carrinho de compras).
Quer outro exemplo? Para armazenar as atividades de navegação do usuário (incluindo cliques
num determinado botão, ação de logar, quais páginas visitou no passado). Os dados
informados em preenchimento de formulários (endereços, senhas e até cartões de crédito)
também podem ser armazenados em cookies para utilização do servidor web.
O Servidor Web utiliza o campo Set-Cookie do cabeçalho HTTP para passar pares de
nome/valor com metadados associados (chamados cookies) para um User Agent
(navegadores em desktops, em celulares, etc). Quando o usuário envia requisições
subsequentes para o servidor, o seu User Agent utiliza os metadados e outras informações para
avaliar se envia ou não os pares nome/valor de volta ao servidor.
Esses dados são repassados no cabeçalho do Cookie. Apesar de parecerem simples na

utilização, os cookies possuem algumas complexidades. Ex: o servidor indica o escopo para
cada cookie quando o envia para o User Agent. O escopo indica o tempo máximo de resposta do
User Agent para envio do cookie solicitado, qual o servidor para enviar o cookie, e esquemas de
URI para os quais o cookie é aplicável.
Por meio do campo Set-Cookie do cabeçalho um servidor pode enviar ao user agent uma
pequena string dentro da resposta HTTP para identificar, por exemplo, um identificador de
sessão, ou SID. Para identificar as próximas requisições como sendo daquela sessão, o usuário
(user agent) envia o SID com o mesmo identificador. Por exemplo:
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
O servidor pode alterar o escopo do cookie para informar que o usuário pode enviar a resposta à
solicitação de cookie para todos as URLs de um certo subdomínio, ex:
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=radiohead.com

27
103
15176084732 - Leonardo
1184281
Aula 11
O servidor pode armazenas inúmeros cookies na máquina do usuário. Ele pode, por exemplo,
armazenar um identificador de sessão bem como o idioma do usuário.
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly

Set-Cookie: lang=en-US; Path=/; Domain=example.com
Cookie: SID=31d4d96e407aad42; lang=en-US
Para isso, basta que envie dois campos Set-Cookie no cabeçalho HTTP. Percebam que o
cabeçalho define dois cookies, um com um identificador de sessão e outro que define o idioma e
o domínio para resposta do User Agent. O atributo Secure limita o escopo do cookie para
somente trafegar em canais seguros (o mais comum é usar o HTTP sobre Transport Layer
Security - TLS).
Apesar do atributo, é possível que um hacker ativo na rede corrompa a integridade do cookie. Já
o atributo HttpOnly limita o escopo do cookie para requisições HTTP somente. Caso o
servidor queira que o User Agent armazene o cookie por mais de uma sessão, ele pode especificar
uma data de expiração a partir do atributo Expires. Entendido isso?
Nada impede que o usuário delete o cookie antes da data de expiração manualmente ou pelo
descarte do navegador por chegar a um limite de cookies:
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
Cookie: SID=31d4d96e407aad42; lang=en-US
Finalmente, para remover um cookie, o servidor deve enviar o Set-Cookie com uma data de
expiração no passado. A remoção só funciona se os atributos Path e Domain forem iguais aos
definidos no momento da criação do cookie.
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

28
103
15176084732 - Leonardo
1184281
Aula 11
Além do atributo Expires, existe o atributo Max-Age que indica quanto tempo deve durar a
vida de um cookie. Sim, você pode controlar isso! Claro que, mais uma vez, isso depende da
“boa vontade” do User Agent de manter esse cookie até o fim. Nem todos os User Agents
suportam esse atributo e, nesse caso, simplesmente a ignoram. Tranquilo?
Cabe ressaltarmos que, no caso de aparecerem os dois atributos: Max-Age e Expires; o

primeiro tem precedência sobre o segundo. Caso nenhum seja definido, o cookie ficará
armazenado até o fim da sessão, pelo tempo que o próprio User Agent definir. Por fim, é sempre
bom lembrar que o servidor pode enviar o cookie, mas cabe ao usuário aceitar ou não os
armazenar.
Vocês já devem ter visto bastante os navegadores web que perguntam se você deseja salvar os
cookies, que podem ser utilizados de forma invasiva por hackers, sim? Pois é, o servidor envia o
cabeçalho Set-Cookie, mas o usuário pode simplesmente ignorar! Sai fora que não quero meus
dados de navegação indo para seu servidor, e minha privacidade?! ;)

29
103
15176084732 - Leonardo
1184281
Aula 11
REST
1 – Conceitos Básicos
O SOA tem seu nome utilizado de maneira bastante errada, eu imagino que isso ocorra devido
ao fato de que muitos ainda fazem uma forte associação entre o conceito abstrato e alto nível de
SOA e a tecnologia de Web Services, que – inicialmente – tornou-se a maneira mais popular de
implementá-lo. Percebam que muitas discussões na internet falam sobre "REST vs SOA"3.
Ora, isso é como comparar maçãs com laranjas! Por isso, vamos dar um passo atrás e olhar
para a motivação original do SOA. Em praticamente qualquer empresa, muitos sistemas
individuais compõem o cenário completo de TI. Eles rodam em diversas tecnologias e foram
construídos usando ferramentas diferentes. Alguns foram adquiridos de fornecedores
comerciais, outros foram desenvolvidos, etc.
Depois de um curto período de tempo, você vai querer conectá-los, porque obviamente há
muito valor em fazê-lo. É possível fazer isso de uma maneira ponto-a-ponto: a exportação de
alguns dados aqui, periodicamente importá-lo de lá; por meio de arquivos; bancos de dados
compartilhados; ou soluções de integração individuais. Essas soluções, em geral, levarão a uma
situação frágil e incontrolável.
Utilizar um middleware de integração centralizado não é uma boa solução (será um gargalo),
embora – em primeiro lugar - possa parecer tentador! Você se torna dependente do único
fornecedor, que pode ser comprado por outra organização, sair do negócio, ou tornar-se legado
após mesclar com um concorrente que tenha comprado outro produto deste tipo mais
recentemente.
Então, o que você faz em vez disso? Você trata o problema de uma forma razoável. Como?
Reduzindo a quantidade de esforço para integrar os sistemas individuais, limitando a quantidade
de diferentes tecnologias utilizadas na camada de interface, escolhendo uma boa interface de
abstração, e – principalmente - modularizando as grandes aplicações em pequenos pedaços.
E essa é a essência da arquitetura orientada a serviços: uma arquitetura de software que não é
aplicada a um sistema individual, mas a um conjunto de sistemas dentro de uma
organização; concentrando-se em interfaces e, não, em implementação; padronizando o que
for necessário para garantir uma comunicação fácil e um reúso casual, mas nada mais.
Bacana! Essa é a motivação do SOA! Nós vimos que é possível comunicar sistemas diferentes
de várias formas e que uma delas é por meio serviços. Você quer dizer Web Service, professor?
3
Uma comparação mais adequada seria entre os estilos: REST x WS-*.

30
103
15176084732 - Leonardo
1184281
Aula 11
Bem, não necessariamente! Você pode implementar serviços com outras tecnologias (Ex:
CORBA ou DCOM), mas – de fato – a implementação mais comum é por meio de Web Services.
É importante que vocês saibam que REST é diferente de SOA! Qual a diferença? SOA é uma
arquitetura e REST é um estilo arquitetural 4. E tem diferença, professor? Sim, meus caros! A
arquitetura é neutra; já o estilo arquitetural, não. REST pode ser visto como o fornecimento de
uma implementação de serviços com requisitos de design específicos para determinadas
tecnologias e arquiteturas.
O SOA pode ser visto como o fornecimento de uma abordagem tecnologicamente neutra ao
design de serviços que pode ser aplicada a um grande número de implementações, incluindo
Web Services e REST. Cada implementação possui sua coleção única de tecnologias, requisitos
de design, e artefatos/propriedades arquiteturais, algumas das quais suportam diferentes
princípios em diferentes níveis.
Grosso modo, podemos comparar com a arte! Se procurarmos a definição de arquitetura, vamos
encontrar: “(...) refere-se tanto ao processo quanto ao produto de projetar e edificar o ambiente
habitado pelo ser humano”. Percebam que não há limitações ou restrições, trata-se de um
conceito bastante amplo. E o que ocorre se procurarmos a definição de estilo arquitetural?
Vamos encontrar: “(...) expressão utilizada com o fim de classificar períodos

da história da arquitetura de acordo com suas caraterísticas formais,
técnicas e materiais”. Observem que esse conceito possui diversas
restrições quanto à forma, à técnica e aos materiais. Por meio dessas
restrições, podemos identificar se determinada construção segue o estilo
arquitetônico barroco, etrusco, bizantino, renascentista, etc. Então, caso
vocês já tenham ido à Catedral de Notre-Dame, em Paris, devem ter
percebido que se trata de uma construção de estilo arquitetural gótico
(com suas gárgulas e seus vitrais).
Ficou mais fácil de entender agora? Essas restrições são correspondentes às

tecnologias/protocolos e ajudam a diferenciar uma arquitetura de um estilo arquitetural.
Professor, mas o que é o REST? REST significa REpresentational State Transfer e se trata de um
estilo arquitetural para projetar aplicações de rede distribuídas. Agora, sim, vamos falar mais a
fundo sobre o assunto da nossa aula...
REST é um estilo arquitetural para construir sistemas fracamente acoplados. Quer um

exemplo? A própria Web (URI/HTTP/HTML/XML) é uma instância desse estilo! E de onde ele
surgiu? Um cara chamado Roy Fielding cunhou esse termo em sua dissertação de doutorado,
propondo seis restrições ou princípios que nós vamos ver em mais detalhes na tabela abaixo:
4
Muitas questões ainda afirmam que REST é uma arquitetura! Apesar de não estar completamente correto, não marquem errado apenas por
conta disso.

31
103
15176084732 - Leonardo
1184281
Aula 11
Responsabilidades devem ser separadas entre clientes e servidores. Isso permite que os
componentes do cliente e do servidor evoluam de forma independente e, por sua vez,
permite que o sistema seja escalável. Em outras palavras, busca-se separar a arquitetura e
responsabilidades em dois ambientes.
Dessa forma, o cliente não se preocupa com tarefas do tipo: comunicação com banco de
dados, gerenciamento de cache, log, etc; e o contrário também é válido, o servidor não se
preocupa com tarefas como: interface, experiência do usuário, etc. Permitindo, assim, a
evolução independente das duas arquiteturas.
A comunicação entre cliente e servidor deve ser stateless. O servidor não precisa lembrar o
estado do cliente. Em vez disso, os clientes devem incluir todas as informações necessárias
na requisição para que o servidor possa entendê-la e processá-la.
Em outras palavras, um mesmo cliente pode mandar várias requisições para o servidor,
porém cada uma delas deve ser independente, ou seja, toda requisição deve conter todas
as informações necessárias para que o servidor consiga entendê-la e processá-la
adequadamente (qualquer informação de estado deve ficar no cliente).
Múltiplas camadas hierárquicas, como gateways, firewalls e proxies podem existir entre o
cliente e o servidor. As camadas podem ser adicionadas, modificadas, reordenadas, ou
removidas de forma transparente para melhorar a escalabilidade – deve ser fácil, então,
manipular camadas (tornando o sistema mais flexível).
O cliente nunca deve chamar diretamente o servidor da aplicação sem antes passar por um
intermediador (Ex: Balanceador de Carga). Isso garante que o cliente se preocupe apenas
com a comunicação com o intermediador e o intermediador fique responsável por distribuir
as requisições aos servidores.
Respostas do servidor devem ser declaradas como cacheable ou noncacheable. Isso

permite que o cliente ou seus componentes intermediários armazenem em cache respostas
e reutilizem-nas para pedidos posteriores. Isto reduz a carga no servidor e ajuda a melhorar
o desempenho.
Isso significa que, quando um primeiro cliente solicita um determinado recurso ao servidor,
esse processa a requisição e o cliente a armazena temporariamente em cache. Quando
houver uma nova requisição, a resposta armazenada já está pronta para ser utilizada.
Todas as interações entre cliente, servidor e componentes intermediários são baseadas na

uniformidade de suas interfaces. Isso simplifica a arquitetura geral, visto que componentes
podem evoluir de forma independente à medida que implementem o que foi acordado em
contrato.

32
103
15176084732 - Leonardo
1184281
Aula 11
É basicamente um contrato para comunicação entre cliente e servidor. São regras para
fazer um componente o mais genérico possível, tornando-o muito mais fácil de ser
refatorado e melhorado. Obedece a quatro princípios: identificação de recursos;
representação de recursos; respostas auto-explicativas; e hypermídia.
Esse princípio é opcional, na medida em que não faz parte da arquitetura em si. Ele trata da
possibilidade de clientes poderem estender suas funcionalidades através do download e
execução do código sob demanda. Exemplos incluem scripts Javascript, Applets Java,
Silverlight, e assim por diante.
Em outras palavras, permite que o cliente possa executar algum código sob demanda, ou
seja, estender parte da lógica do servidor para o cliente, seja através de applets ou scripts.
Assim, diferentes clientes podem se comportar de maneiras específicas mesmo que
utilizando exatamente os mesmos serviços providos pelo servidor.
Aplicações que sigam essas restrições são consideradas Aplicações RESTful. Como vocês
devem ter notado, essas restrições não ditam a tecnologia a ser utilizada para o desenvolvimento
das aplicações. Em vez disso, a adesão a estas orientações e melhores práticas oferece a
oportunidade de uma aplicação escalável, visível, portátil, confiável e capaz de performar
melhor.
Em teoria, é possível que uma aplicação RESTful seja construída utilizando qualquer
infraestrutura de rede ou protocolo de transporte. Na prática, aplicações RESTful levam
vantagem ao utilizar características e recursos da web e o protocolo HTTP (e seus
métodos/verbos: GET, POST, PUT, DELETE5). Grosso modo, esses métodos servem
respectivamente para recuperar, inserir, atualizar e deletar um recurso.
Bem, há um conceito fundamental em REST chamado Recurso (ou Resource). Um recurso é

qualquer coisa que possa ser acessada ou manipulada. Exemplos de recursos incluem vídeos,
entradas de blog, perfis de usuário, imagens, e até mesmo coisas tangíveis, tais como pessoas
ou dispositivos. Os recursos são tipicamente relacionados com outros recursos.
Por exemplo, em um aplicativo de comércio eletrônico, o cliente pode fazer um pedido para
qualquer número de produtos. Neste cenário, os recursos de produtos estão relacionados com
o recurso de pedido correspondente. É também possível que recursos sejam agrupados em
conjuntos. Usando o mesmo exemplo de comércio eletrônico, uma ordem é uma coleção de
recursos individuais de pedidos.
5
O Protocolo HTTP possui diversos métodos (GET, POST, PUT, DELETE, OPTIONS, TRACE, HEAD, CONNECT), no entanto os quatro tem maior
relevância em nosso contexto.

33
103
15176084732 - Leonardo
1184281
Aula 11
E o que é uma URI? Trata-se do Uniform Resource Identifier, que nada mais é que uma string
de caracteres utilizada para identificar unicamente um recurso. Vocês já devem conhecer a
URL (Uniform Resource Locator) – trata-se de uma URI que, além de identificar um recurso da
web, também é capaz de localizá-lo (basta lembrar de endereços de sites). No REST, todo
recurso contém um identificador.
Professor, o formato de representação da informação no SOAP é o XML – qual é o formato de

representação no REST? Bem, excelente pergunta! Os recursos devolvidos aos clientes podem
ter diversas representações, tais como: HTML, JSON, XML, YAML, TXT, ou outros formatos
dependendo da requisição do cliente. Percebem a flexibilidade? Essa é uma grande vantagem!
Já que entramos nesse assunto, vamos falar um pouco sobre WS-* (JAX-WS) e REST (JAX-RS).
Em sua implementação tradicional, desenvolvem-se Web Services utilizando o Protocolo
SOAP e, em geral, com a Linguagem XML – no Java, essa especificação foi denominada JAX-
WS (Java API for XML Web Services), presente a partir do Java EE 5. Tudo certo até aqui?
Em sua implementação alternativa, desenvolvem-se Web Services utilizando os métodos do

Protocolo HTTP e, em geral, com a Linguagem JSON – no Java, essa especificação foi
denominada JAX-RS (Java API for Restful Web Services), presente a partir do Java EE 6. Cada
implementação tem suas vantagens e desvantagens. O fato é que, aqui, nosso intuito é estudar
a implementação alternativa. Bacana?

34
103
15176084732 - Leonardo
1184281
Aula 11
Na imagem acima, podemos ver REST e SOAP! No primeiro caso, se você quiser enviar uma
mensagem a alguém que está em outra cidade, você pode simplesmente subir no cavalo
(HTTP) e cavalgar! Simples assim... agora vejam o SOAP! Para você enviar a mesma mensagem,
você precisa de vários cavalos e uma carruagem imensa e pesada que envolve a mensagem.
Observem outra diferença importante! No SOAP, existe uma especificação que deve ser seguida
para todas as requisições/respostas – trata-se do WSDL. No REST, não existia nenhuma
especificação. Hoje em dia, podemos utilizar o WSDL2 ou WADL para descrever um serviço.
Bacana? Agora percebam a complexidade que é enviar uma mensagem no SOAP x REST! Vejam
o overhead que traz o envelope...
Nesse contexto, gostaria que vocês me respondessem uma

pergunta: Quem é mais simples: REST ou SOAP? Ora, REST! Sob
esse aspecto, ele é bem mais simples. Vejam essa imagem ao
lado: REST é aquele cara mais simples e descolado que sai de calça
jeans e camiseta para trocar informações. Já o SOAP é aquele cara
mais pomposo e equipado que sai de terno, gravata e maleta para
trocar informações.
Quem é o melhor, professor? Isso não existe, cada um é adequado

para um contexto.

35
103
15176084732 - Leonardo
1184281
Aula 11
É um protocolo de comunicação. É um estilo arquitetural ou uma técnica de engenharia

de software.
Utiliza um Envelope (Cabeçalho + Corpo) enviado por Utiliza os recursos oferecidos nativamente pelo HTTP
HTTP (FTP, SMT, etc) para transmitir dados. (apesar de poder utilizar outros protocolos).
Suporta somente o formato XML. Suporta XML, JSON, YAML, TXT, etc
Apresenta desempenho e escalabilidade menor, Apresenta desempenho e escalabilidade maior, devido

devido ao alto overhead. ao baixo overhead.
Não permite fazer Caching. Permite fazer Caching.
JavaScript pode chamar SOAP, mas é difícil de JavaScript pode facilmente chamar REST.
implementar.

36
103
15176084732 - Leonardo
1184281
Aula 11
QUESTÕES COMENTADAS
services
1. (CESPE - 2013 - CNJ) Uma das formas de comunicação para encapsular dados transferidos
no formato XML para aplicações serviço web (Webservice) é o SOAP (Simple Object Access
Protocol).
Comentários:
Services.
Ele realmente é uma forma de comunicação – dado que é um protocolo – para encapsular dados
transferidos no formato XML para aplicações web services.
Gabarito: Correto
2. (CESPE - 2013 - CNJ) A linguagem WSDL é utilizada para descrever web services limitadas ao
tipo request-response.
Comentários:
A operação pode receber uma mensagem, mas não retornará uma resposta.
A operação pode receber uma requisição e retornará uma resposta.
A operação pode enviar uma requisição e esperará por uma resposta.

A operação pode enviar uma mensagem, mas não esperará por uma resposta.
Não está limitada ao tipo request-response – existem quatri tipos diferentes de operações.
Gabarito: Errado
3. (CESPE - 2013 - CNJ) Nos registros de negócio UDDI, a descrição da forma de acesso aos web
services é um procedimento contido nas páginas verdes (green pages).
Comentários:
As Páginas Verdes contêm informações técnicas sobre como acessar um Web Service. Elas são
utilizadas para indicar os serviços oferecidos por cada negócio, incluindo todas as informações

37
103
15176084732 - Leonardo
1184281
Aula 11
técnicas envolvidas na interação com o serviço. Em geral, essas informações incluem um ponteiro
para uma especificação externa e um endereço para invocar o serviço.
Elas contêm descrições técnicas sobre as formas de acesso aos web services.
Gabarito: Correto
4. (CESPE - 2013 - TRE-MS) No que se refere a SOA e webservices, assinale a opção correta.
a) O WS-Security propõe uma série de extensões para aprimorar a segurança dos web
services no UDDI e no WSDL. Por questão de compatibilidade, essas extensões não afetam
os cabeçalhos do envelope SOAP.
b) UDDI é um serviço de diretório em que é possível registrar e localizar web services.
c) WSDL é descrito em formato XML e tem por única função descrever os valores e formatos
dos dados que serão intercambiados entre os sistemas.
d) SOAP é um protocolo do tipo statefull, independente de sistema operacional, embasado

em troca de mensagem one-way e projetado para ser simples e extensível por meio de
tecnologia XML.
e) SOA é uma arquitetura de desenvolvimento cujo objetivo é criar módulos funcionais

denominados serviços, fortemente acoplados e independentes de plataforma. É embasada
em XML e incentiva reutilização de código e interoperabilidades entre sistemas.
Comentários:
(a) Não é tema dessa aula, mas o erro desse item é afirmar que ele aprimora segurança no UDDI
e WSDL, quando ele aprimora a segunrança do SOAP.
É um serviço de diretório em que é possível registrar e localizar Web Services.
(b) UDDI é realmente um serviço de diretório em que é possível registrar e localizar Web Services.
É uma linguagem de descrição de Web Services, escrita em XML, para descrever serviços web, especificar as
formas de acesso, as operações e os métodos disponíveis.
(c) Ele descreve o serviço, especifica como acessá-los e seus métodos e operações disponíveis.

38
103
15176084732 - Leonardo
1184281
Aula 11
Nós não dissemos ainda se SOAP é um protocolo Stateful ou Stateless, mas antes de descobrir,
temos que saber o que são esses conceitos. Stateful significa que o servidor armazena informações
sobre o cliente e as utiliza em diversas requisições. Stateless é justamente o contrário, i.e., o estado
do serviço não é persistido entre requisições subsequentes. O HTTP e o SOAP, por default, são
protocolos stateless.
(d) SOAP é – por default – stateless. Além disso, a questão escreveu statefull, em vez de stateful.
Ele realmente é independente de sistema operacional, mas pode realizar trocas de mensagens
de diversas maneiras – sendo o tipo Request-Response muito mais comum que o tipo One-Way.
Agora que já sabemos o que é uma arquitetura e o que é um serviço, podemos juntá-los! A OASIS6
define Arquitetura Orientada a Serviços como um paradigma para organização e utilização de
recursos distribuídos que estão sob o controle de diferentes domínios proprietários, permitindo
que funcionalidades implementadas sejam disponibilizadas na forma de serviços fracamente
acoplados.
(e) Não é uma arquitetura de desenvolvimento – é uma arquitetura corporativa. Além disso,
serviços devem ser fracamente acoplados.
Gabarito: Letra B
5. (CESPE - 2011 - MEC) O UDDI (Universal Description Discovery and Integration), que
corresponde a um registro de web services, é dividido em páginas brancas, amarelas e verdes,
nas quais são prestadas aos clientes informações sobre a empresa, os serviços por ela
oferecidos e as especificações WSDL desses serviços.
Comentários:
6
OASIS (Organization for the Advancement of Structured Information Standards) é um consórcio global que conduz o desenvolvimento,
convergência e adoção de padrões para e-business e web services.

39
103
15176084732 - Leonardo
1184281
Aula 11
O UDDI descobre serviços por meio de registries, que são repositórios logicamente centralizados e
fisicamente distribuídos que contêm documentos descritores dos dados do negócio. As informações
capturadas no contexto do UDDI são classificadas em três categorias principais: Páginas Brancas,
Páginas Verdes ou Páginas Amarelas, como mostra a imagem abaixo com seus respectivos
exemplos:
A questão trata respectivamente das páginas brancas, amarelas e verdes.
Gabarito: Correto
6. (CESPE - 2011 - BRB) Na estrutura de um documento WSDL, o elemento <portType>

descreve os tipos de dados usados por um web service.
Comentários:
Esse elemento descreve as operações que podem ser realizadas e as mensagens

trocadas (é o antigo <portType>).
O antigo <portType> descreve as operações que podem ser realizadas e as mensagens trocadas.
Gabarito: Errado
7. (CESPE - 2011 - CBM-DF) Embora não tenha publicação automática, um web service permite
a utilização das regras de negócio através da rede e conecta aplicações de diferentes
fornecedores.
Comentários:
As interações entre o provedor e o agente são basicamente a publicação dos serviços. A

interação entre o solicitador e o agente é a tarefa de pesquisar os serviços e os provedores de
serviços. Finalmente, a interação entre o provedor e o solicitante é chamada de vínculo (em inglês,
bind). De acordo com Schneider, algumas das vantagens de se utilizar Web Services são:
Permite utilizar as regras de negócio através da rede;

Baixo custo de comunicação (Internet);
Conecta aplicações de diferentes fornecedores;
Protocolo padronizado (SOAP/WSDL/UDDI);
Permite publicação automática (UDDI).
Ele permite a publicação automática.
Gabarito: Errado

40
103
15176084732 - Leonardo
1184281
Aula 11
8. (CESPE - 2011 - PREVIC) No WSDL (Web Services Definition Language), é prescrito o leiaute
de banco de dados com descrições de serviços, por meio das quais os clientes de web service
podem procurar serviços relevantes.
Comentários:
SOAP (SIMPLE/SINGLE OBJECT ACCESS PROTOCOL)

UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION):
organizadas.
WSDL é Web Service Description Language! Além disso, não se prescreve leiaute de banco de
dados. Essa descrição está mais para UDDI.
Gabarito: Errado
9. (CESPE - 2011 - PREVIC) Web Services são sistemas embasados na Web que oferecem
serviços gerais para aplicações remotas, não requerendo interações imediatas de usuários
finais.
Comentários:
Sabemos que Web Services são sistemas embasados na web que oferecem serviços gerais para
aplicações remotas, não requerendo interações imediatas de usuários finais – em geral a interação
é máquina-máquina ou aplicação-aplicação. Além da definição, é bom saber a descrição dos três
padrões fundamentais que possibilitam as comunicações, isso sozinho resolve uma pancada de
questões:
A maioria das aplicações são desenvolvidas para interagir com usuários; o usuário entra ou
procura um dado por meio de uma interface e a aplicação responde à entrada do usuário. Um
Web Service faz mais ou menos a mesma coisa, no entanto ele se comunica máquina à máquina
ou aplicação à aplicação - em geral, não se tem interação direta do usuário com o Web Service.
Logo, não se exige interação imediata de usuários finais.
Gabarito: Correto
10. (CESPE - 2010 - MPU) A descrição de um web service é feita utilizando-se WSDL (Web
Services Description Language), que é uma linguagem embasada em RPC (Remote

41
103
15176084732 - Leonardo
1184281
Aula 11
Procedure Call) e UDDI (Universal Description Discovery and Integration), com a qual se
descreve a forma de acesso dos serviços e seus parâmetros de entrada e de saída.
Comentários:
Entre outras utilizações, SOAP foi desenhado para encapsular e transportar Chamadas RPC e,
para isto, utiliza-se dos recursos e flexibilidade do XML, sob HTTP. Por meio do RPC, pode-se
acessar os serviços de um objeto localizado em um outro ponto da rede, através de uma chamada
local a este objeto. Cada chamada ou requisição exige uma resposta.
Esse item não faz o menor sentido! WSDL é uma linguagem de descrição – quem realiza
Chamadas RPC é o SOAP.
Gabarito: Errado
11. (CESPE - 2008 – TRT/BA) O UDDI é uma especificação técnica que tem como objetivo
descrever, descobrir e integrar web services; é embasado na tecnologia XML, que fornece
uma plataforma neutra de dados e permite descrever relações hierárquicas de modo natural.
Comentários:
Trata-se de uma especificação técnica que tem como objetivo descrever, descobrir e integrar Web Services.
Pessoal, não confundam uma coisa: WSDL não fica efetivamente no UDDI, mas lá existem
referências para ele! Ok? A UDDI 3.0.2 (versão mais recente) possui um Modelo de Informação
Estruturada: Core Data Structure. Ele é composto por uma estrutura hierárquica formada por:
Entidade de Negócio (Business Entity), Serviço de Negócio (Business Service), Template de
Ligação (Binding Template) e tModel.
Basta lembrar da sigla! UDDI é Universal Description, Discovery and Integration (Integração,
Descoberta e Descrição Universal). Dessa forma, trata-se realmente de uma especificação
técnica que tem como objetivo descrever, descobrir e integrar Web Services. É baseada em XML?
Sim! Permite descrever relações hierárquicas? Sim!
Gabarito: Correto
12. (CESPE - 2008 - STJ) O serviço UDDI fornece uma interface para publicar e atualizar
informações acerca de serviços web; possibilita pesquisar descrições WSDL pelo nome; provê
uma interface que possibilita executar consultas de modo a recuperar uma entidade que
corresponda a uma chave ou recuperar entidades que correspondam a um conjunto de
critérios de busca.

42
103
15176084732 - Leonardo
1184281
Aula 11
Comentários:
A Especificação UDDI fornece duas interfaces importantes: Publisher Interface e Inquiry

Interface. A primeira interface define dezesseis operações para que um provedor de serviços possa
gerenciar e publicar informações sobre um determinado serviço web. Já a segunda interface define
dez operações de busca de registro e informações específicas de registros.
A questão trata das interfaces: Publisher e Inquiry.
Gabarito: Correto
13. (CESPE - 2008 - STJ) O WSDL separa a parte abstrata de uma descrição de serviço da parte
concreta; nessa descrição, a parte concreta contém as definições de tipos usados pelo serviço
e a parte abstrata especifica como e onde o serviço pode ser contatado. Os documentos
WSDL podem ser acessados via um serviço de diretório como o UDDI; as definições WSDL
podem ser geradas a partir de definições de interfaces escritas em outras linguagens.
Comentários:
O WSDL separa a descrição de um serviço em duas perspectivas: Abstrata e Concreta! A

perspectiva abstrata trata da interface do serviço. Em outras palavras, ela descreve o que o serviço
faz – seus tipos, suas operações, suas entradas, suas saídas, suas mensagens fault, entre outros –,
porém sem dizer como o serviço faz o seu trabalho nem mesmo como acessar esse serviço.
A perspectiva concreta trata da implementação do serviço. Em outras palavras, ela descreve como
realizará o serviço – protocolos de comunicação, codificação de dados, localização, portas,
endereço de rede, etc. A perspectiva concreta contém a perspectiva abstrata e adiciona
informações sobre como o serviço se comunicará e quem pode alcançá-lo. Professor, qual a
vantagem de haver essa separação?
Elas fazem isso ao eliminar a necessidade de envolvimento dos usuários com os detalhes complexos
e com a estrutura do WSDL. As definições WSDL também podem ser geradas a partir de definições
de interface escritas em outras linguagens, como JAX-RPC. Ele não define características não-
funcionais do serviço (Ex: tempo de resposta, escalabilidade, segurança). Ademais, define quatro
tipos de operações:
A questão inverteu as bolas! As definições de tipo pertencem à parte abstrata; e como/onde o

serviço pode ser contatado (endereço de rede, portas, etc) pertence à parte concreta. Alguns me
perguntam se as definições WSDL podem ser geradas a partir de definições de interfaces escritas
em outras linguagens. Sim, em teoria, elas podem ser escritas em outras linguagens que, não,
XML.
Gabarito: Errado

43
103
15176084732 - Leonardo
1184281
Aula 11
14. (CESPE - 2008 - STJ) O SOAP encapsula mensagens que podem ser transmitidas via HTTP;
permite o modelo de interação cliente-servidor; define como usar XML para representar
mensagens de requisição e resposta. Um documento XML é transportado no corpo de uma
mensagem SOAP; no modelo cliente-servidor, o corpo de uma mensagem SOAP pode conter
uma requisição, mas não uma resposta.
Comentários:
SOAP encapsula mensagens que podem ser transmitidas via HTTP? Sim, assim como outros
protocolos de comunicação. Permite o modelo de interação cliente-servidor? Define como usar
XML para representar mensagens de requisição e resposta? Sim, utiliza um paradigma de
requisição/resposta, típico de aplicacões cliente-servidor. Um documento XML é transportado no
corpo de uma mensagem SOAP? Sim, ele encapsula um documento XML. O corpo de uma
mensagem SOAP pode conter uma requisição, mas não uma resposta? Não, entre outras
utilizações, SOAP foi desenhado para encapsular em e transportar em seu corpo chamadas de
RPC, que faz uma requisição e exige uma resposta.
Gabarito: Errado
15. (CESPE - 2008 – TRT/BA) No SOA, os web services permitem que os aplicativos se
comuniquem entre si de modo independente da plataforma e da linguagem de programação.
Os web services utilizam WSDL para descrever interfaces de aplicativos na linguagem XML.
Comentários:

Galera, nós vimos insistentemente que a arquitetura orientada a serviços é independente de

implementação e tecnologia. Em outras palavras, há diversas modelos arquitetônicos de
implementação de uma arquitetura orientada a serviços. Veremos agora algumas formas de
implementar essa arquitetura em uma organização. Vamos começar pelo modelo mais primitivo...
Vamos lá! Nessa questão, o sabixão do examinador encontrou – em algum lugar – a seguinte
frase: "Os Web Services utilizam XML para descrever as interfaces de aplicativos em uma linguagem
chamada WSDL". Ele, então, decidiu inverter XML com WSDL e dizer que o item estava errado.
No entanto, ele deu azar, porque mesmo com a inversão o item continua correto. Ora, web
services utilizam WSDL para descrever interfaces de aplicativos na linguagem XML? Sim, porque
WSDL é escrito em XML. Logo, a questão está correta! A banca voltou atrás? Não :(
Gabarito: Errado

44
103
15176084732 - Leonardo
1184281
Aula 11
16. (CESPE - 2008 – TRT/BA) Na visão do SOA, XML e WSDL são padrões abertos que permitem
que os serviços se comuniquem de maneira homogênea, independentemente da plataforma
de hardware, do sistema operacional e da linguagem de programação nos quais o serviço está
implementado.
Comentários:
Galera, nós vimos insistentemente que a arquitetura orientada a serviços é independente de

implementação e tecnologia. Em outras palavras, há diversas modelos arquitetônicos de
implementação de uma arquitetura orientada a serviços. Veremos agora algumas formas de
implementar essa arquitetura em uma organização. Vamos começar pelo modelo mais primitivo...
É realmente independente de tecnologia (plataforma de hardware, sistema operacional,

linguagem de programação, entre outros).
Gabarito: Correto
17. (CESPE - 2009 - ANATEL) Os três padrões fundamentais que possibilitam comunicações
entre web services são: simple object access protocol (SOAP) — protocolo que define uma
organização para a troca estruturada de dados entre web services; web services description
language (WSDL) — protocolo que define como as interfaces dos web services podem ser
representadas; universal description, discovery and integration (UDDI) — padrão de
descoberta que define como são organizadas as informações de descrição do serviço,
permitindo que os solicitantes descubram os serviços. Um desses padrões não utiliza a XML
(extensible mark-up language).
Comentários:
Trata-se de um protocolo que define uma organização para a troca estruturada de dados entre Web Services.
Trata-se de um protocolo baseado em XML para troca de informações em ambientes distribuídos e

descentralizados (Sim, alguns o consideram um protocolo!).
Trata-se de um padrão de descoberta que define como são organizadas as informações de descrição do
serviço, permitindo que os solicitantes descubram os serviços.
Todos esses padrões utilizam XML!
Gabarito: Errado

45
103
15176084732 - Leonardo
1184281
Aula 11
18. (CESPE - 2009 – CEHAP/PB) São padrões de Web services o SOAP, o WSDL e o UDDI, todos
baseados em HTTP.
Comentários:
organizadas.
Todos são baseados em XML!
Gabarito: Errado
19. (CESPE - 2009 - INMETRO) Na SOA, a descrição do serviço é mantida em um repositório

WSDL, em formato UDDI (universal description, Discovery and integration).
Comentários:
O UDDI descobre serviços por meio de registries, que são repositórios logicamente centralizados e
fisicamente distribuídos que contêm documentos descritores dos dados do negócio. As informações
capturadas no contexto do UDDI são classificadas em três categorias principais: Páginas Brancas,
Páginas Verdes ou Páginas Amarelas, como mostra a imagem abaixo com seus respectivos
exemplos:
A descrição é mantida em um repositório UDDI, em formado WSDL.
Gabarito: Errado
20. (CESPE - 2009 - ANTAQ) Nos serviços web, clientes e servidores, direta ou indiretamente,
podem acessar documentos UDDI completos por meio de seus URIs (uniform resource
identifier), usando um serviço de diretório, tal como o WSDL.
Comentários:
De acordo com George Coulouris, os documentos WSDL completos podem ser acessados por meio
de seus URIs por clientes e servidores, direta ou indiretamente, por intermédio de um serviço de
diretório como o UDDI. Estão disponíveis ferramentas para gerar definições WSDL a partir de
informações fornecidas por meio de uma interface gráfica com o usuário.

46
103
15176084732 - Leonardo
1184281
Aula 11
A questão inverteu os conceitos.
Gabarito: Errado
21. (CESPE - 2009 – TCE/TO) Acerca da arquitetura orientada ao serviço (SOA), assinale a opção
incorreta.
a) Os principais conceitos do SOA são a visibilidade, a interação e os efeitos.
b) Na programação orientada a objetos, o foco está no empacotamento de dados com

operações, enquanto que, no SOA, o foco central é a interface entre as aplicações.
c) O SOA se constitui na base mais viável para o desenvolvimento de sistemas de grande

escala.
d) O UDDI (universal description, discovery, and integration) é um protocolo para descrever

componentes de serviços web disponíveis.
e) Nos web services, utiliza-se SOAP sobre HTTP para se realizar a comunicação entre os
serviços.
Comentários:
O Modelo de Referência do SOA apresenta, a partir da perspectiva dinâmica de serviço, três

conceitos-chaves dessa arquitetura: a visibilidade entre provedores de serviços e consumidores; a
interação entre eles; e os efeitos no mundo real da interação com um serviço. Existem outros
conceitos fundamentais, esses são conceitos relacionados à dinâmica dos serviços.
(a) Conforme vimos em aula, a questão está perfeita;
(b) De acordo com o Modelo de Referência OASIS/SOA: “Diferentemente do paradigma de

Programação Orientada a Objeto, onde o foco está no empacotamento de dados com operações, o
foco central da Arquitetura Orientada a Serviço é a tarefa ou função de negócio – obtendo alguma
coisa feita”;
Ele tenta diferenciar POO de SOA – essencialmente trata-se da diferença entre um objeto e um
serviço. O primeiro utiliza operações para empacotar dados em um objeto; e o segundo tenta
oferecer um serviço (que ofereça algum valor ao negócio). Em outros termos, serviços têm
acesso aos métodos dos objetos, mas quem de fato agrega valor é o serviço e, não, o método - o
serviço é o fim, o método é o meio.
O OASIS ainda afirma: "Ambos, a OO e o SOA são como formas de pensar sobre representação de
coisas e ações no mundo referindo-se especificamente sobre a construção de sistemas. A coisa

47
103
15176084732 - Leonardo
1184281
Aula 11
importante é o entendimento e aplicação do paradigma. Portanto a questão não é “o que é um

serviço?” muito mais que isto é “o que é um objeto?”.
Qualquer coisa pode ser um serviço da mesma forma que qualquer coisa pode ser um objeto. O
desafio é aplicar o paradigma para melhorar a clareza e obter as coisas feitas. O SOA oferece a base
mais viável para sistemas de grande escala por que ele se enquadra melhor na forma como as
atividades humanas são gerenciadas – por delegação". Em outras palavras, os serviços são mais
abstratos; são mais próximos das atividades humanas do que os métodos dos objetos.
(c) De acordo com o Modelo de Referência OASIS/SOA: SOA oferece a base mais viável para
sistemas de grande escala por que ele se enquadra melhor na forma como as atividades humanas
são gerenciadas – por delegação.
com sucesso (Sim, alguns o chamam de protocolo!)
(d) Conforme vimos em aula, está perfeito – alguns autores chamam Protocolo UDDI (eu
discordo dessa denominação).
tecnologias padrão, em particular XML e HTTP. Eles são comumente utilizados para disponibilizar
serviços interativos na web, podendo ser acessados por outras aplicações. O SOAP é o protocolo
mais comum para troca de mensagens, já que é escrito em XML e transportado, via de regra, por
HTTP.
(e) Conforme vimos em aula, está perfeito! Esse é um dos motivos de esse modelo ser tão
atrativo é ser baseado em tecnologias padrão, tais como XML e HTTP.
Gabarito: Letra B
22. (CESPE - 2009 - ANTAQ) Um componente importante da arquitetura de serviços web é

formado por um serviço de diretório que armazena descrições de serviços. Esse serviço deve
obedecer ao padrão UDDI (universal description, discovery and integration).
Comentários:
com sucesso (Sim, alguns o chamam de protocolo!)
Conforme vimos em aula, a questão está perfeita.

48
103
15176084732 - Leonardo
1184281
Aula 11
Gabarito: Correto
23. (CESPE - 2010 - INMETRO) Em um sistema que adere a uma arquitetura orientada a serviços
(SOA), vários elementos da arquitetura estabelecem comunicações entre si, e recomenda-se
que adotem vários padrões e recursos para comunicação, como HTTP (hypertext transfer
protocol), WSDL (Web Services Description Language), SOAP (Single Object Acess Protocol),
WS-BPEL (Web Services – Business Processes Execution Language), UDDI (Universal
Description, Discover and Integration) e XML (eXtensible Markup Language), entre outros.
Assinale a opção que formula relação correta entre esses padrões e (ou) recursos.
a) Um documento escrito na linguagem WSDL adota formato com base na linguagem XML e
seu uso depende da existência do serviço UDDI.
b) UDDI é um protocolo para definição das interfaces de serviços ofertadas por um objeto que
presta serviços em uma arquitetura orientada a serviços.
c) Um documento SOAP é formado por um envelope e uma mensagem, sendo escrito em

aderência a esquemas definidos na linguagem XML e transportado usualmente em
mensagens HTTP.
d) WS-BPEL é uma notação para a representação abstrata de arquiteturas orientadas a

serviço, independente de plataforma e tecnologias de suporte.
e) HTTP, WSDL, UDDI, SOAP, WS-BPEL e SOA são tecnologias para a produção de
documentos digitais que adotam o XML como formato padronizado.
Comentários:
(a) Não, seu uso não depende da existência do UDDI; (b) Não, esse item trata do SOAP; (c) Sim,
ele encapsula mensagens que podem ser consideradas um documento XML. Ele é descrito em
WSDL, e WSDL é baseado em XML, logo ele é definido em XML; (d) Não, BPEL é uma linguagem
de execução e, não, uma notação; (e) Não, elas não são tecnologias para produção de
documentos digitais.
Gabarito: Correto
Comentários:

49
103
15176084732 - Leonardo
1184281
Aula 11
Trata-se efetivamente de especificação que define como descrever serviços web em uma gramática XML.
Conforme vimos em aula, ela é embasada em XML.
Gabarito: Errado
25. (CESPE - 2010 – TRE/MT) Com relação a web services, assinale a opção correta.
a) As arquiteturas de aplicação de web services são arquiteturas firmemente acopladas, nas

quais as ligações entre serviços não podem mudar durante a execução.
b) SOAP (Simple Object Access Protocol) é um protocolo com base em HTML que permite
troca de informações entre aplicações em um ambiente distribuído.
c) UDDI (Universal Description, Discovery and Integration) é um diretório para

armazenamento de informações a respeito de web sevices. Essas informações são descritas
em SOAP.
d) A linguagem WSDL (Web Services Description Language) é utilizada para descrever web
services.
e) Segundo o W3C (World Wide Web Consortium), web services são apropriados somente
para aplicações em que componentes de um sistema distribuído são executados em
plataformas semelhantes de um mesmo fornecedor.
Comentários:
Trata-se de uma linguagem de descrição de Web Services, escrita em XML, para descrever serviços web,
especificar as formas de acesso, as operações e os métodos disponíveis.
(a) Errado, são fracamente acopladas; (b) Errado, com base em XML; (c) Errado, são descritas em
WSDL; (d) Correto, é para isso que ela serve; (e) Errado, eles são independente de tecnologias
(plataformas, hardware, etc).
Gabarito: Letra D
26. (CESPE - 2011 – MEC) Web Service é uma solução lógica que oferece a possibilidade de
recuperar informações remotamente por meio de cloud computing. Esse serviço utiliza a
definição WSDL em um ou mais XML Schemas, que são armazenados na UDDI.

50
103
15176084732 - Leonardo
1184281
Aula 11
Comentários:
O Binding Template é um conjunto de descrições técnicas dos Web Services representados por uma
estrutura de serviços de negócio – ele indica, por exemplo, como se conecta ao serviço. Por fim, o
tModel representa um modelo técnico, i.e., uma maneira de descrever os vários negócios,
serviços, estruturas de template e informações externas (Ex: WSDL) armazenados dentro de
um Registro UDDI.
XML Schemas não são armazenados na UDDI! E se ele dissesse que os documentos WSDL são
armazenados na UDDI? Ainda estaria errada, porque o UDDI só aponta para o documento WSDL,
mas não o armazena...
Gabarito: Errado
27. (CESPE - 2012 – PEFO/CE) SOAP é um protocolo leve destinado à troca de informações
estruturadas em um ambiente distribuído e descentralizado. Uma mensagem SOAP, por
exemplo, é um documento XML composto de três partes obrigatórias: envelope, cabeçalho
e corpo.
Comentários:
Ele carrega informações adicionais específicas para a aplicação, como Autenticação,

Autorização, Pagamento, etc. Ele pode, por exemplo, especificar assinatura digital para serviços
protegidos por senha. Podem ser definidos vários cabeçalhos. Ele é opcional, mas – caso seja
utilizado – deve ser o primeiro elemento do Envelope. Ele tem três atributos: mustUnderstand, actor
e encodingStyle.
Não é possível afirmar que SOAP é um protocolo leve ou pesado sem uma referência. Além disso,
cabeçalho é opcional.
Gabarito: Errado
28. (CESPE - 2009 - ANTAQ) Web services é um tipo de arquitetura de sistema distribuído que
se caracteriza pela disponibilidade de serviços abstratos na Logical View, que se orienta pela
troca de mensagens entre requisitantes e provedores, independentemente das suas
plataformas de trabalho via XML.
Comentários:
Segundo a definição do Gartner, Web Services são componentes de software com baixo fator de
acoplamento, utilizado por meio de padrões de internet. Um Web Service representa uma
função/lógica de negócio ou um serviço que pode ser acessado por uma outra aplicação na web,
sobre redes públicas e, geralmente, disponibilizado por protocolos conhecidos.

51
103
15176084732 - Leonardo
1184281
Aula 11
Web Service implementa uma arquitetura distribuída, mas não é uma (por si só). Além disso, a
troca de mensagens ocorre via SOAP e, não, XML. O primeiro é um protocolo de comunicação;
o segundo é apenas uma linguagem de marcação.
Gabarito: Errado
29. (CESPE - 2012 – TJ/RO) Acerca de SOA e web services, assinale a opção correta.
a) Web service é projetado para operar dados entre máquinas, em redes de computadores,
mediante a linguagem UDDI.
b) No caso de implementação de web service, o contrato de serviço entre os agentes

envolvidos na aplicação pode possuir múltiplos esquemas XML (XML schema), com regras
como políticas de nível de serviço acordado (SLA).
c) Acoplamento forte, um princípio dos serviços do SOA, possibilita maior compatibilidade

de comunicação em ambientes heterogêneos, mediante o uso de XML na troca de dados.
d) Representational state transfer (REST), que utiliza o WSDL como linguagem de descrição
de serviços, é uma forma de implementação de SOA na web.
e) SOA é um aplicativo que segue as recomendações definidas na arquitetura web service.
Comentários:
(a) Errado, opera dados mediante a linguagem XML; (b) Correto, o contrato pode ter vários
esquemas, com regras de nível de serviço – por exemplo; (c) Errado, o princípio é de acoplamento
fraco; (d) Errado, não é o tema da aula, mas não utiliza WSDL; (e) Errado, SOA não é um
aplicativo, mas – sim – uma arquitetura, e Web Service não é uma arquitetura, mas – sim – a
implementação de uma arquitetura.
Gabarito: Letra B
30. (CESPE - 2013 – CNJ) Um dos elementos de uma mensagem SOAP é o corpo (body), no qual
devem estar contidas as informações de erro e status.
Comentários:
Ele contém o payload, i.e., a mensagem SOAP. Trata-se de um elemento obrigatório que é capaz de
empacotar chamadas RPC, reportar erros, enviar operações UDDI, entre outros. O elemento Body
pode conter um elemento opcional Fault, usado para carregar mensagens de status e mensagens
de erros retornadas pelos nós ao processarem a mensagem. É obrigatório!

52
103
15176084732 - Leonardo
1184281
Aula 11
A redação torna o item polêmico: um dos elementos de uma mensagem SOAP é o Corpo (Body).
As informações de erro e status devem estar contidas no Fault, que fica dentro do Body. O Body
é obrigatório, mas o Fault é opcional. No entanto, a questão apenas afirma que, se houver as
informações de erro e status, elas devem estar presentes no corpo. Qual o erro da questão,
professor? Nenhum, ela está correta, mas o examinador não voltou atrás :(
Gabarito: Errado
31. (CESPE - 2013 – ANTT) Web Services provêm um meio padrão para interoperação entre
diferentes aplicativos de software, que podem ser executados em uma variedade de
plataformas e(ou) frameworks.
Comentários:
Sim, eles são independentes de plataforma, sistema operacional, arquitetura de processador, linguagem de
programação, entre outros.
Gabarito: Correto
32. (CESPE - 2015 – MPOG/ATI) As informações relativas a formato de protocolo e mensagem

são associadas às operações (elementos operation) por meio de elementos binding.
Comentários:
Esse componente descreve o formato de mensagens e protocolos de transmissão que

podem ser usados para definir um endpoint. Ele define detalhes de implementação
necessários para acessar um serviço.
As informações relativas à formato de mensagens e protocolos de transmissão são associadas às

operações por meio do bindind.
Gabarito: Correto
33. (CESPE - 2013 – TCE/RO) O SOAP permite a troca de mensagens estruturadas em ambiente
distribuído e descentralizado, com o uso de tecnologias XML. Essas mensagens podem ser
trocadas por uma variedade de protocolos subjacentes como, por exemplo, o HTTP.

53
103
15176084732 - Leonardo
1184281
Aula 11
Comentários:
SOAP é um protocolo projetado para invocar aplicações remotas em um ambiente independente

de plataforma, linguagem de programação, entre outros. Ele é, portanto, um padrão normalmente
aceito para se utilizar com Web Services. Mas, professor, ele é o único? Não! Veremos mais adiante...
não se preocupem com isso nesse momento.
Bem, o que se pretende é garantir a interoperabilidade e intercomunicação entre diferentes

sistemas, através da utilização de uma linguagem (XML) e de um mecanismo de transporte
(HTTP). Pessoal, é obrigatório utilizar esse protocolo de transporte? Não! Pode-se usar qualquer um,
no entanto esse é o mais comumente utilizado no mercado atualmente.
Gabarito: Correto
34. (CESPE - 2013 – SERPRO) A comunicação entre sistemas clientes e servidores para troca de
mensagens pode ser realizada por meio de SOAP (simple object access protocol), que é um
protocolo para troca de informações estruturadas independente de linguagem de
programação.
Comentários:
tecnologias padrão, em particular XML e HTTP. Eles são comumente utilizados para disponibilizar
serviços interativos na web, podendo ser acessados por outras aplicações. O SOAP é o protocolo
mais comum para troca de mensagens, já que é escrito em XML e transportado, via de regra, por
HTTP.
SOAP é um protocolo projetado para invocar aplicações remotas em um ambiente independente

de plataforma, linguagem de programação, entre outros. Ele é, portanto, um padrão normalmente
aceito para se utilizar com Web Services. Mas, professor, ele é o único? Não! Veremos mais adiante...
não se preocupem com isso nesse momento.
Conforme vimos em aula, a questão está perfeita!
Gabarito: Correto
35. (CESPE - 2013 – CNJ) Uma das formas de comunicação para encapsular dados transferidos
no formato XML para aplicações serviço web (webservice) é o SOAP (simple object access
protocol).
Comentários:

54
103
15176084732 - Leonardo
1184281
Aula 11
Services.
Gabarito: Correto
36. (CESPE - 2012 – MPE/PI) Em web services, utiliza-se o protocolo SOAP (simple object access
protocol) para a comunicação entre os serviços.
Comentários:
Services.
Gabarito: Correto
37. (CESPE - 2016 – TCE/PR) Em um web service, o termo namespace representa o nome do
elemento principal do maior nível hierárquico em um documento XML utilizado para troca de
mensagens.
Comentários:
No contexto de Web Services, o que é um “documento XML utilizado para troca de mensagens”? É
um Web Service SOAP! Nesse caso, o elemento principal do maior nível hierárquico é o Envelope
– que identifica a Mensagem SOAP. No entanto, um namespace é apenas um nome que
identifica um conjunto de outros nomes! Ele pode representar o nome do elemento de maior
nível hierárquico assim como quaisquer outros.
Gabarito: Errado
38. (CESPE - 2009 - ANTAQ) Em serviços web, o SOAP pode ser transportado por protocolos
como REST, HTTP, SMTP e JMS.
Comentários:
Essa questão foi anulada! REST não é um protocolo, mas um estilo arquitetural! Inclusive, ele
utiliza o Protocolo HTTP.

55
103
15176084732 - Leonardo
1184281
Aula 11
Gabarito: Anulada
39. (CESPE – 2017 – SE/DF) Serviços expressos por meio de contratos web services têm o
potencial de evitar completamente a transformação, objetivo-chave dos contratos de
serviços padronizados.
Comentários:
Galera, essa questão afirma que quando eu ofereço serviços por meio de Web Services e seus
contratos (i.e., suas interfaces), eu tenho um grande potencial de evitar a transformação. Isso é
verdade! Nós sabemos que mudar a implementação do serviço é irrelevante desde que se
mantenha sua interface. No entanto, eventualmente eu posso precisar alterar a interface de um
serviço – e, nesse caso, não dá para evitar a transformação do contrato do serviço.
Logo, o contrato não é imutável, ele realmente muda raramente, mas ele não é imune a
mudanças e não evita completamente transformações. No entanto, a questão afirma que o uso
de contratos tem o “potencial” de evitar completamente a transformação. Ter o potencial
significa ter a capacidade de realização ou execução de algo. E isso é verdadeiro nesse contexto.
Vejam o que diz a especificação:
“Regardless of the development approach you utilize for service development there is no question
that service contracts must be designed in an extensible manner to minimize disruptive versioning
changes. Service contracts should be designed with the assumption that once published, they
cannot be modified—this approach forces developers to build flexibility into their schema designs”.
Gabarito: Errado
40. (CESPE – 2017 – SE/DF) Por oferecerem um framework de comunicação com base em
contratos de serviços fisicamente desacoplados, os web services permitem que um contrato
de serviços seja totalmente padronizado, independentemente de sua implementação.
Comentários:
Um Web Service é um sistema de software projetado para permitir interoperabilidade na interação

entre máquinas através de uma rede. É descrito através de uma interface padronizada que
disponibiliza um serviço em uma rede de computadores, geralmente a Internet. Uma vez
descrito na forma padrão e catalogado, o serviço se torna um componente de software totalmente
reutilizável.
Conforme eu disse na questão anterior, contratos de serviços (interfaces) espalhadas pela rede e
desacopladas, permitindo que o contrato seja padronizado, sendo sua implementação
irrelevante.

56
103
15176084732 - Leonardo
1184281
Aula 11
Gabarito: Correto
41. (CESPE – 2017 – TRE/PE) A respeito de arquitetura orientada a serviços (SOA), assinale a
opção correta.
a) WS – Transaction é um padrão de suporte que garante que uma mensagem seja entregue
uma vez e apenas uma vez.
b) Trata-se de uma forma de desenvolvimento de sistemas distribuídos cujos componentes

são serviços autônomos, executados em computadores geograficamente distribuídos.
c) Um serviço na SOA é agnóstico, ou seja, dependente da aplicação que o utiliza.
d) WSDL (web service definition language) na SOA para Web é uma linguagem utilizada
como padrão para troca de mensagens e para definição de componentes de web services.
e) WS – realiable messaging é um padrão SOA que define como as informações devem ser
representadas em uma mensagem SOAP.
Comentários:
(a) Errado, esse é o WS-Reliable Messaging. O WS-Transaction é uma especificação que

apresenta como as transações através de serviços distribuídos devem ser coordenadas,
garantindo quem uma transação seja atômica, i.e., uma transação é executada integralmente
com sucesso ou é completamente abortada; (b) Correto. Questão retirada da última edição do
Sommerville e que, a princípio, eu discordo. SOA não é uma forma de desenvolvimento, mas já
que foi o Sommerville que disse, a partir de agora passaremos a considerar como referência; (c)
Errado, ele é independente da aplicação que o utiliza, i.e., agnóstico; (d) Errado, WSDL é um
padrão para a definição de interface de serviço; (e) Errado, esse é o WS-Adressing.
Gabarito: Letra B
42. (CESPE – 2017 – TRE/BA) No que se refere a web services, assinale a opção correta.
a) As solicitações e respostas XML trafegam no protocolo HTTP, não sendo possível utilizá-
las nos protocolos FTP e SMTP.
b) Um dos componentes de um Web Service SOAP (Simple Object Access Protocol) é a UDDI
(Universal Description, Discovery and Integration), a qual é um arquivo do tipo XML que
descreve detalhadamente um Web Service, especificando como deve ser o formato de
entrada e saída de cada operação.

57
103
15176084732 - Leonardo
1184281
Aula 11
c) As duas formas de envio de mensagem para que um cliente possa efetuar solicitações a um
Web Service são One-Way Messaging e Request-Response Messaging.
d) O WSDL (Web Services Description Language) é uma linguagem para o desenvolvimento

de Web Services similar ao XML.
e) Os Web Services permitem a integração de sistemas, todavia dependem da linguagem de

programação sob a qual tenham sido desenvolvidos e do sistema operacional do computador
onde esses sistemas forem executados.
Comentários:
(a) Errado. Via de regra, utiliza-se HTTP, mas não obrigatório; (b) Errado. Observem que a
questão não está afirmando que UDDI é um componente do SOAP. Ela afirma que o UDDI é um
componente do Web Service SOAP. Dito isso, quem descreve detalhadamente um serviço é o
WSDL; (c) Correto. Existem quatro tipos de operação: One-Way, Request/Response,
Solicit/Response e Notification. Para que o cliente possa efetuar solicitações, é adequado utilizar
as duas primeiras; (d) Errado, não é para desenvolvimento – é para descrição de Web Services;
(e) Errado, eles são independentes de tecnologia, logo não dependem de linguagem de
programação ou sistema operacional.
Gabarito: Letra C
43. (CESPE - 2013 – TRE/MS) O WS-Security propõe uma série de extensões para aprimorar a
segurança dos web services no UDDI e no WSDL. Por questão de compatibilidade, essas
extensões não afetam os cabeçalhos do envelope SOAP.
Comentários:
Na verdade, ele propõe extensões para aprimorar a segurança dos Web Services no SOAP! Ele
adiciona um elemento de cabeçalho de mensagem SOAP (<wsse:Security>)para anexar as
informações de segurança às mensagens, na forma de tokens, transmitindo diferentes tipos de
solicitações juntamente com informações de criptografia e assinatura digital.
Gabarito: Errado
44. (CESPE – 2013 – SERPRO) Os serviços embasados em colheita automática de metadados

(harvesting) são assíncronos e menos sofisticados que os providos pelas federações, sendo a
sobrecarga sobre os participantes consideravelmente menor.
Comentários:

58
103
15176084732 - Leonardo
1184281
Aula 11
Na Federation, o usuário faz uma requisição síncrona a um repositório central (representado por uma
Biblioteca Digital) e espera a resposta. O repositório faz diversas requisições a outros repositórios
remotos e as respostas retornam para o repositório central onde são consolidadas e devolvidas
para o usuário. Bacana? Agora vamos ver como funciona a outra abordagem.
No Harvesting, o usuário faz uma requisição a um motor de busca que procura em um repositório
central de metadados (Harvested Metadata) que contém metadados anteriormente coletados
assincronamente e automaticamente de outros repositórios. Em geral, os metadados são
codificados em XML. Esse método é menos sofisticado e acarreta menor sobrecarga sobre os
repositórios.
Harvesting é assíncrono e menos sofisticado que Federation – e a sobrecarga sobre os

participantes é menor.
Gabarito: Correto
45. (CESPE - 2008 – MPE/AM) No protocolo HTTP (hypertext transfer protocol), o método GET
é utilizado em solicitações enviadas pelo servidor ao navegador para que este solicite dados
ao usuário de uma página ou para que o próprio navegador forneça os dados solicitados.
Comentários:
prática, apenas um arquivo). A grande maioria das solicitações a servidores da web tem a forma de
métodos GET.
O navegador envia requisições ao servidor e, não, o inverso.
Gabarito: Letra E
46.(CESPE - 2011 – MEC) Em formulários HTML, apenas o método post é suportado; o método
get é utilizado em aplicações JavaScript.
Comentários:
Melhor, não? Só isso? Não! GET é utilizado para recuperar informações (em geral, poucas); POST é
utilizado para enviar informações (em geral, muitas – por meio de formulário). Vamos ver outras
diferenças:

59
103
15176084732 - Leonardo
1184281
Aula 11
Não se enganem com isso! Formulários geralmente utilizam POST, mas nada impede que se
utilize GET.
Gabarito: Letra E
47. (FCC – 2010 – AL/SP) GET e POST são alguns dos principais métodos que determinam o que
o servidor deve fazer com o URL fornecido no momento da requisição de um recurso.
Relacionado a esses métodos, considere:
I. Dados enviados em uma requisição utilizando o método GET ficam visíveis na linha de
endereço do navegador.
II. Se não for especificado um método, o POST é adotado como padrão.
III. O método GET é geralmente utilizado para enviar grandes quantidades de dados por meio
de um formulário.
IV. O método POST não exibe os dados enviados na linha de endereço do navegador.
Está correto o que se afirma APENAS em:
a) I e II.
b) I e IV.
c) II, III e IV.
d) III.
e) IV.
Comentários:
Deiltel já dizia: Uma solicitação get não deve ser utilizada para enviar dados sigilosos porque os
dados do formulário são colocados em uma string de consulta que é acrescentada ao URL do
navegador como texto simples e pode ser interceptada. Lembrando que, por padrão, é utilizado
o GET.
(I) Conforme vimos em aula, está perfeito.
Deiltel já dizia: Uma solicitação get não deve ser utilizada para enviar dados sigilosos porque os
dados do formulário são colocados em uma string de consulta que é acrescentada ao URL do
navegador como texto simples e pode ser interceptada. Lembrando que, por padrão, é utilizado o
GET.

60
103
15176084732 - Leonardo
1184281
Aula 11
(II) Conforme vimos em aula, o padrão é GET.
diferenças:
(III) Conforme vimos em aula, a questão trata do POST.
diferenças:
(IV) Conforme vimos em aula, está perfeito.
Gabarito: Letra B
48.(UFF – 2009 – UFF) No tocante ao protocolo de transferência de hipertexto (HTTP), esse

protocolo da categoria "solicitação e resposta" possui três métodos de solicitação. São eles:
a) HEAD, BODY e INIT;

b) FLAG, TOS e TTL;
c) GET, HEAD e POST;
d) PUT, GET e INIT;
e) PUSH, POST e HEAD.
Comentários:
prática, apenas um arquivo). A grande maioria das solicitações a servidores da web tem a forma
de métodos GET.
Esse método solicita apenas o cabeçalho da mensagem, sem a página propriamente dita. Esse
método pode ser usado para se obter a data da última modificação feita na página, para reunir
informações destinadas à indexação, ou apenas para testar a validade de uma URL.

61
103
15176084732 - Leonardo
1184281
Aula 11
Esse método é semelhante ao PUT – porque também transporta um URL –, no entanto, em vez
de substituir os dados existentes, os novos dados são "anexados" a ele, em um sentido mais
genérico. Na prática, nem PUT nem POST são muito utilizados hoje.
Trata-se do GET, HEAD e POST.
Gabarito: Letra C
49.(MPE/RS - 2012 – MPE/RS) Um formulário em HTML é um modelo de entrada de um

conjunto de dados. O primeiro passo a ser dado para a construção de um formulário é fazer
as etiquetas que desenham as janelas de entrada de dados. Os métodos que transferem
dados do browser para o servidor são denominados ________ e ________.
a) input – output
b) post – get
c) push – pop
d) post – cat
e) push – pull
Comentários:
Trata-se do POST e GET.
Gabarito: Letra B
50. (FUMARC - 2014 – AL/MG) Analise as seguintes afirmativas sobre os métodos HTML:
I. HTML POST é utilizado para enviar dados para serem processados em um servidor Web.
II. HTML GET solicita ao servidor apenas o cabeçalho de uma URL para que o cliente decida
se deve requisitar o conteúdo completo ou não.
III. HTML PUT é utilizado para criar recursos dentro de um servidor Web.
Estão CORRETAS as afirmativas:
a) I e II, apenas.
b) I e III, apenas.
c) II e III, apenas.
d) I, II e III.
Comentários:

62
103
15176084732 - Leonardo
1184281
Aula 11
prática, apenas um arquivo). A grande maioria das solicitações a servidores da web tem a forma
de métodos GET.
Esse método é o inverso do GET, i.e., em vez de ler, ele grava a página. Esse método possibilita a
criação de um conjunto de páginas da web em um servidor remoto – o corpo da solicitação
contém a página.
Esse método é semelhante ao PUT – porque também transporta um URL –, no entanto, em vez
de substituir os dados existentes, os novos dados são "anexados" a ele, em um sentido mais
genérico. Na prática, nem PUT nem POST são muito utilizados hoje.
Todos os itens estão corretos, exceto o segundo! Na verdade, o método que solicita o cabeçalho
de um recurso é o HEAD. Vocês já notaram o vacilo da banca? Pois é, esses métodos são do HTTP
e, não, HTML.
Gabarito: Letra B
51. (FAU - 2016 – JUCEPAR/PR) Que nome é dado aos pequenos arquivos que são gravados em
seu computador quando você acessa sites na Internet e que são reenviados a estes mesmos
sites quando novamente visitados?
a) Planilhas.
b) Cookies.
c) Trojan.
d) Virus.
e) Token.
Comentários:
Muito cuidado para não confundir cookies com algo nativamente inseguro. Qualquer recurso na
web pode conter vulnerabilidades e ser explorado por um hacker. Os cookies são muito
importantes e uma definição bem aceitável é apresentada no enunciado da questão, como vimos
na aula teórica.
Gabarito: Letra B
52. (IESES - 2015 – TRE/MA) Das definições abaixo sobre cookies, assinale a afirmativa correta.

63
103
15176084732 - Leonardo
1184281
Aula 11
a) O cookie ou cookie HTTP é um aplicativo que quando é executado aumenta a segurança

do usuário na Internet.
b) Arquivo gerado pelo servidor WEB que fica armazenado na máquina do usuário e que
permite ao servidor buscar informações realizadas pelo usuário no site.
c) Para o servidor WEB gravar no cookie é necessário realizar o comando

setCookie("nomedocookie").
d) O cookie Web é arquivo que fica armazenado na máquina do usuário e que aumenta a
performance de navegação na WEB.
Comentários:
(a) Errado. É complicado dizer que ter um cookie habilitado reduz a segurança do usuário. Com
certeza reduz a privacidade, pois, no mínimo, eles são usados para enviar informações da
navegação do usuário aos servidores web. O contrário então, não tem como afirmar! Ou seja, os
cookies não aumentam a segurança do usuário; (b) Correto. Uma boa definição de cookies; (c)
Errado. Na verdade, vimos que o servidor web deve enviar, normalmente via HTTP, no cabeçalho
um elemento Set-Cookie; (d) Errado. O cookie não melhora a performance da navegação.
Gabarito: Letra B
53. (FAU - 2016 – JUCEPAR/PR) Assinale a alternativa correta que contenha a definição de
Cookie:
a) Pacote de dados enviado por um website ao navegador e armazenado no computador do

usuário. Esse arquivo contém informações sobre as preferências de navegação do usuário.
b) Vírus que captura informações do usuário digitadas no navegador e as envia por e-mail
para um computador receptor.
c) Permite que aplicativos cliente/servidor possam trocar informações em total segurança,

protegendo a integridade e a veracidade do conteúdo que trafega na Internet.
d) Protocolo responsável por gerenciar a comunicação entre websites e navegadores. Este

protocolo torna esta comunicação altamente confiável através de autenticação dos usuários.
e) Certificado digital enviado por um website ao navegador autenticando a idoneidade da

comunicação estabelecida.
Comentários:

64
103
15176084732 - Leonardo
1184281
Aula 11
(a) Correto. Boa definição para cookies. Ele armazena muito mais que isso, mas também as
preferências do usuário; (b) Errado. Cookies não são vírus; (c) Errado. No máximo um atributo
Secure para dizer ao user agente para que, ele sim, “se vire” com a segurança. O cookie não
garante segurança; (d) Errado. Cookie não é um protocolo, e não garante segurança; (e) Errado.
Cookie não é um certificado digital.
Gabarito: Letra A
54. (FGV - 2016 - COMPESA) Quando um navegador solicita uma página da web, o servidor pode
fornecer informações adicionais junto com a página solicitada. Essas informações podem
incluir um cookie.
Em relação à cookies na arquitetura web, analise as afirmativas a seguir:
I. Uma linha no cabeçalho HTTP iniciada por Cookie: é a forma como os servidores enviam
cookies aos clientes. Espera-se que o cliente grave o cookie e o devolva em solicitações
subsequentes ao servidor.
II. Para remover um cookie do disco rígido do cliente, basta o servidor enviá-lo novamente
com uma data de expiração vencida.
III. Um cookie que não contém a informação de quando irá expirar permanece ativo por
tempo indeterminado.
Está correto o que se afirma em:
a) I, apenas.
b) II, apenas.
c) III, apenas.
d) I e II, apenas.
e) I, II e III.
Comentários:
I – Errado. Na verdade, temos que incluir no cabeçalho Set-Cookie, e não somente Cookie;
II – Correto. Vimos na aula teórica que uma data vencida no atributo Expires faz com que o cookie
seja removido pelo User Agent;
III – Errado. Como vimos na aula teórica, o cookie ficará armazenado até o fim da sessão, pelo
tempo que o próprio User Agent definir. Ou seja, o tempo não é indefinido, mas sim definido pela
sessão do usuário.

65
103
15176084732 - Leonardo
1184281
Aula 11
Gabarito: Letra B
55. (IBFC / EBSERH – 2017) Assinale a alternativa que apresenta o serviço de diretório onde
empresas podem registrar (publicar) e buscar (descobrir) por Serviços Web (Web Services):
a) UDDI
b) NIS
c) WSDL
d) X.500
e) LDAP
Comentários:
Serviço de diretório? Permite registrar/publicar e buscar/descobrir web services? Trata-se do UDDI

(Universal Description, Discovery and Integration).
Gabarito: Letra A
56. (IBFC / EBSERH – 2017) Web service é uma solução utilizada na integração de sistemas. Os
Web services são componentes que permitem às aplicações enviar e receber dados, como
padrão, em formato:
a) NAT
b) ARP
c) XML
d) TLS
e) XDR.
Comentários:
Galera, o formato padrão de Web Services (SOAP) é o XML! As outras opções não fazem o menor
sentido...
Gabarito: Letra C
57. (IBFC / EBSERH – 2017) Conforme o W3C (World Wide Web Consortium) pode-se definir um
Web Service como sendo:
a) uma estrutura conceitual para reger projetos de engenharia de software.

b) técnicas baseadas em formalismos matemáticos para a especificação, desenvolvimento e
verificação dos sistemas de softwares e hardwares.
c) um modelo de referência que contém práticas necessárias à manutenção do software.

66
103
15176084732 - Leonardo
1184281
Aula 11
d) um sistema de software projetado para suportar a interoperabilidade entre máquinas

sobre rede.
e) um modelo de dados que representa um conjunto de conceitos dentro de um domínio e os
relacionamentos entre estes.
Comentários:
(a) Errado, acredito que isso seria um modelo de processo de software; (b) Errado, acredito que
isso seria o processo de software de métodos formais; (c) Errado, acredito que isso seria mais
relacionado ao CMMI; (d) Correto, ele é extremamente útil para suportar interoperabilidade na
troca de informações entre máquinas da rede; (e) Errado, acredito que isso seria mais relacionado
ao modelo entidade relacionamento.
Gabarito: Letra D
58. (IBFC / EMDEC – 2016) Quanto as tecnologias aplicadas em um Web Service temos:
"Para a representação e estruturação dos dados nas mensagens recebidas/enviadas é

utilizado o _______. As chamadas às operações, incluindo os parâmetros de entrada/saída,
são codificadas no protocolo_______. Os serviços (operações, mensagens, parâmetros, etc.)
são descritos usando a linguagem_______. O processo de publicação/pesquisa/descoberta de
Web Services utiliza o protocolo_______."
Assinale a alternativa que complete correta e respectivamente as lacunas:
a) SOAP - WSDL - UDDI - XML

b) WSDL - UDDI - XML - SOAP
c) UDDI-XML-SOAP-WSDL
d) XML - SOAP - WSDL - UDDI.
Comentários:
Para a representação e estruturação dos dados nas mensagens recebidas/enviadas é utilizado o

XML. As chamadas às operações, incluindo os parâmetros de entrada/saída, são codificadas no
protocolo SOAP. Os serviços (operações, mensagens, parâmetros, etc.) são descritos usando a
linguagem WSDL. O processo de publicação/pesquisa/descoberta de Web Services utiliza o
protocolo UDDI.
Gabarito: Letra D

67
103
15176084732 - Leonardo
1184281
Aula 11
59. (CESPE - 2011 – MEC) Um web service pode ser desenvolvido, também, com o uso de REST,
que utiliza o protocolo HTTP para comunicação entre emissor e destinatário, e o SOAP, para
encapsular as mensagens trafegadas.
Comentários:
Em teoria, é possível que uma aplicação RESTful seja construída utilizando qualquer infraestrutura
de rede ou protocolo de transporte. Na prática, aplicações RESTful levam vantagem ao utilizar
características e recursos da web e o protocolo HTTP (e seus métodos/verbos: GET, POST, PUT,
DELETE). Grosso modo, esses métodos servem respectivamente para recuperar, inserir, atualizar e
deletar um recurso.
Um Web Service pode ser desenvolvido de fato com uso de REST. REST realmente utiliza o
protocolo HTTP, mas não utiliza SOAP (que é parte da arquitetura WS-*)!
Gabarito: Errado
60.(CESPE - 2016 – TCE/SC) A JAX-RS 2.0 fornece APIs portáteis para o desenvolvimento de
aplicações Web em conformidade com os princípios do estilo arquitetônico REST.
Comentários:
O JAX-RS – como o próprio nome sugere – fornece APIs portáteis para o desenvolvimento de
aplicações web em conformidade com o REST.
Gabarito: Correto
61. (CESGRANRIO - 2007 – REFAP/ES) O estilo arquitetural REST (Representational State

Transfer) para WEB tem como característica:
a) permitir o uso de RPC diretamente sobre SSL, para aplicações seguras.

b) acelerar a transferência do FTP com a implementação de cache.
c) combater o SPAM, utilizando redes neurais como técnica de aprendizagem.
d) usar SOAP para interoperabilidade entre sistemas heterogêneos.
e) utilizar os métodos HTTP: GET, POST, PUT e DELETE.
Comentários:
deletar um recurso.

68
103
15176084732 - Leonardo
1184281
Aula 11
Galera, a questão falou em REST, vocês têm que lembrar imediatamente de HTTP (e seus
métodos ou operações).
Gabarito: Errado
62. (CESPE - 2015 – MEC) Entre as restrições da REST está a interface uniforme, a qual requer
que um serviço ofereça várias operações e aguarde a solicitação dessas operações pelo
servidor.
Comentários:

contrato.
A questão não trata da restrição de Interface Uniforme. Acredito que a restrição que mais se
aproxima dessa descrição seja o Sistema em Camadas.
Gabarito: Errado
63. (CESPE - 2015 – MEC) A fim de implementar serviços em REST, recomenda-se utilizar os
WSDL já existentes com mínima alteração do cabeçalho, informando somente que o
protocolo a ser utilizado é o REST.
Comentários:
deletar um recurso.
Quem utiliza WSDL é o estilo arquitetural WS-*. O estilo arquitetural REST utiliza o protocolo
HTTP.
Gabarito: Errado

69
103
15176084732 - Leonardo
1184281
Aula 11
64.(MPE/RS - 2012 – MPE/RS) Considere as seguintes afirmações a respeito de REST

(Representational State Transfer).
I. REST é um protocolo para troca de mensagens entre componentes de uma aplicação web.
II. REST é uma arquitetura, onde cada aplicação é um conjunto de recursos sobre os quais
podemos realizar ações.
III. Os formatos dos arquivos utilizados numa aplicação que segue REST são JSON, XML ou
YAML.
Quais estão corretas?
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e III.
e) Apenas II e III.
Comentários:
É importante que vocês saibam que REST é diferente de SOA! Qual a diferença? SOA é uma
arquitetura e REST é um estilo arquitetural. E tem diferença, professor? Sim, meus caros! A
arquitetura é neutra; já o estilo arquitetural, não. REST pode ser visto como o fornecimento de uma
implementação de serviços com requisitos de design específicos para determinadas tecnologias e
arquiteturas.

representação no REST? Bem, excelente pergunta! Os recursos devolvidos aos clientes podem ter
diversas representações, tais como: HTML, JSON, XML, YAML, TXT, ou outros formatos
(I) Errado. REST não é um protocolo, é um estilo arquitetural; (II) Correto. Trata-se de um estilo
arquitetural (termo mais correto) baseado em recursos; (III) Correot. De fato, todos esses
formatos são utilizados.
Gabarito: Letra E
65. (CESPE - 2016 – MEC) A respeito dos conceitos de web services e REST, assinale a opção
correta.
a) O método POST é utilizado na atualização de um recurso existente.

70
103
15176084732 - Leonardo
1184281
Aula 11
b) Pode-se utilizar qualquer meio de transporte existente para o envio de uma requisição,
incluindo HTTP, SMTP e TCP.
c) O modelo REST impõe restrições ao formato da mensagem.
d) Ao desenvolver uma aplicação, o recurso é transferido pela rede.
e) As chamadas às URIs (uniform resource indicator) são feitas por meio de métodos HTTP,
os quais indicam para o serviço a ação a ser realizada com o recurso.
Comentários:
deletar um recurso.
(a) Conforme vimos em aula, PUT é o método utilizado para atualizar recursos;
deletar um recurso.
(b) Conforme vimos em aula, pode-se utilizar diversos meios de transporte, no entanto TCP não
é um meio de transporte (é um conjunto de protocolos).

(c) Conforme vimos em aula, não há restrições ao formato da mensagem.
(d) Na verdade, quando se requisita uma aplicação ao servidor, os recursos são transferidos pela
rede. Da maneira que está escrita, essa questão nem faz sentido.
Bem, há um conceito fundamental em REST chamado Recurso (ou Resource). Um recurso é

qualquer coisa que possa ser acessada ou manipulada. Exemplos de recursos incluem vídeos,
entradas de blog, perfis de usuário, imagens, e até mesmo coisas tangíveis, tais como pessoas ou
dispositivos. Os recursos são tipicamente relacionados com outros recursos.

71
103
15176084732 - Leonardo
1184281
Aula 11
(e) Conforme vimos em aula, a questão está impecável. Percebam que ela não limita o uso ao
HTTP – apenas o menciona.
Gabarito: Letra E
66. (CESPE - 2015 – TRE/MT) Acerca de REST (representational state transfer), assinale a
opção correta.
a) O protocolo REST utiliza SOAP e XML.
b) REST utiliza recurso não identificável baseado em PUT e GET.
c) REST pode ser utilizado para implementar WebServices de baixo overhead.
d) Embora opcionalmente, um recurso REST pode conter uma URI.
e) REST consiste em um estilo de desenvolvimento baseado em complexa interação

cliente/servidor.
Comentários:

(a) Conforme vimos em aula, ele não utiliza esses formatos (além disso, não é um protocolo).
E o que é uma URI? Trata-se do Uniform Resource Identifier, que nada mais é que uma string de
caracteres utilizada para identificar unicamente um recurso. Vocês já devem conhecer a URL
(Uniform Resource Locator) – trata-se de uma URI que, além de identificar um recurso da web,
também é capaz de localizá-lo (basta lembrar de endereços de sites). No REST, todo recurso contém
um identificador.
(b) Conforme vimos em aula, ele utiliza – sim – recursos identificáveis (para isso, temos a URI).
Bacana? Agora percebam a complexidade que é enviar uma mensagem no SOAP x REST! Vejam o
overhead que traz o envelope...

72
103
15176084732 - Leonardo
1184281
Aula 11
(c) Conforme vimos em aula, em relação ao SOAP, o REST tem baixíssimo overhead.
E o que é uma URI? Trata-se do Uniform Resource Identifier, que nada mais é que uma string de
caracteres utilizada para identificar unicamente um recurso. Vocês já devem conhecer a URL
(Uniform Resource Locator) – trata-se de uma URI que, além de identificar um recurso da web,
também é capaz de localizá-lo (basta lembrar de endereços de sites). No REST, todo recurso contém
um identificador.
(d) Conforme vimos em aula, é obrigatório ter uma URI.
permite que o sistema seja escalável. Em outras palavras, busca-se separar a arquitetura
e responsabilidades em dois ambientes.
dados, gerenciamento de cache, log, etc; e o contrário também é válido, o servidor não
se preocupa com tarefas como: interface, experiência do usuário, etc. Permitindo,
assim, a evolução independente das duas arquiteturas.
(e) Conforme vimos em aula, ele – de fato – utiliza uma interação cliente/servidor, no entanto ele
não é um estilo de desenvolvimento e não é uma interação complexa, pelo contrário: é bem
simples.
Gabarito: Letra C
67. (CESPE - 2016– TRE/PI) Acerca de REST (Representational State Transfer), assinale a opção
correta.
a) Na implementação do REST, todos os recursos devem responder a todos os métodos.
b) O método GET permite obter e alterar o estado atual de um recurso.
c) O método EXPUNGE permite excluir um recurso.
d) A arquitetura de comunicação entre aplicações baseia-se em um modelo rígido de recursos

e localizações.
e) O método MODIFY permite alterar um recurso.
Comentários:

73
103
15176084732 - Leonardo
1184281
Aula 11
deletar um recurso.
(a) Errado, claro que não! Você pode não ter permissão para acessar um recurso, por exemplo.
Nem todos os recursos respondem a todos os métodos; (b) Errado, ele permite obter, mas não
alterar o estado atual de um recurso; (c) Errado, esse método não existe; (d) Na minha opinião, é
impossível responder esse item. Modelo rígido em relação ao quê? O REST é um modelo flexível;
a comunicação pode ser considerada rígida ou flexível dependendo da comparação; (e) Errado,
esse método não existe. Portanto, para mim, essa questão deveria ter sido anulada, mas o
gabarito é Letra D.
Gabarito: Letra D
68. (CESGRANRIO - 2008 – PETROBRÁS) A interoperabilidade entre aplicações nos dias

atuais é fortemente baseada no uso de web services. Duas abordagens arquiteturais distintas
para o projeto e implementação de web services têm-se firmado no cenário de tecnologia.
São elas:
a) REST e WS-*
b) SOAP e WSDL
c) RPC e RMI
d) SGML e HTML
e) B2B e B2C
Comentários:
Já que entramos nesse assunto, vamos falar um pouco sobre WS-* (JAX-WS) e REST (JAX-RS). Em
sua implementação tradicional, desenvolvem-se Web Services utilizando o Protocolo SOAP e,
em geral, com a Linguagem XML – no Java, essa especificação foi denominada JAX-WS (Java API
for XML Web Services), presente a partir do Java EE 5. Tudo certo até aqui?
Conforme vimos diversas vezes em aula, trata-se de WS-* e REST.
Gabarito: Letra A
69. (CESPE – 2013 – STF) A World Wide Web (WWW) é a maior implementação de um
sistema em conformidade com a arquitetura REST.
Comentários:

74
103
15176084732 - Leonardo
1184281
Aula 11
REST é um estilo arquitetural para construir sistemas fracamente acoplados. Quer um

exemplo? A própria Web (URI/HTTP/HTML/XML) é uma instância desse estilo! E de onde ele surgiu?
Um cara chamado Roy Fielding cunhou esse termo em sua dissertação de doutorado, propondo seis
restrições ou princípios que nós vamos ver em mais detalhes na tabela abaixo:
Conforme vimos em aula, a web é realmente uma implementação em conformidade com REST.
Por que, professor? Vejamos! Qual o principal protocolo da Web/REST? HTTP. Qual a melhor forma
de identificar um recurso na Web/REST? Por meio de um identificador único (URI). Qual é o formato
dos dados na Web/REST? HTML, JSON, XML, TXT, etc. Como são os estados das aplicações da
Web/REST? Ambos são stataless. Como é caracterizado Cache em Web/REST? Ambos permitem
que as respostas dos servidores sejam cacheable. Como é a divisão em camadas na Web/REST?
Ambos incentivam a utilização de camadas hierárquicas.
Gabarito: Correto
70. (CESPE – 2013 – BACEN) O estilo arquitetural REST define um conjunto de restrições para
uma aplicação, como, por exemplo, utilização de arquitetura par-a-par, manutenção de
informações de estado, não uso de cache no cliente e apresentação de uma interface
uniforme.
Comentários:
permite que o sistema seja escalável. Em outras palavras, busca-se separar a arquitetura
e responsabilidades em dois ambientes.
dados, gerenciamento de cache, log, etc; e o contrário também é válido, o servidor não
se preocupa com tarefas como: interface, experiência do usuário, etc. Permitindo, assim,
a evolução independente das duas arquiteturas.
A comunicação entre cliente e servidor deve ser stateless. O servidor não precisa lembrar
o estado do cliente. Em vez disso, os clientes devem incluir todas as informações
necessárias na requisição para que o servidor possa entendê-la e processá-la.

75
103
15176084732 - Leonardo
1184281
Aula 11

permite que o cliente ou seus componentes intermediários armazenem em cache
respostas e reutilizem-nas para pedidos posteriores. Isto reduz a carga no servidor e ajuda
a melhorar o desempenho.
Isso significa que, quando um primeiro cliente solicita um determinado recurso ao

servidor, esse processa a requisição e o cliente a armazena temporariamente em cache.
Quando houver uma nova requisição, a resposta armazenada já está pronta para ser
utilizada.
A questão deu três chances para acertá-la. As restrições são: utilização de uma arquitetura
Cliente/Servidor (e, não, Par-a-Par); não manutenção de informações de estado, i.e., Stateless;
e utilização de cache no cliente (Cacheable).
Gabarito: Errado
71. (CESPE – 2014 – ANTAQ) Em arquiteturas REST, nenhum contexto de cliente pode ser
mantido em servidor.
Comentários:
REST é statless (sem estado), i.e., o servidor não guarda o estado/conteto do cliente.
Gabarito: Correto
72. (CESPE – 2016 – FUNPRESP) Conexões REST devem conter todas as informações
necessárias para que a conexão seja completada.
Comentários:

76
103
15176084732 - Leonardo
1184281
Aula 11
O “ST” em REST significa “State Transfer”, i.e., as operações devem ser autocontidas e cada
requisição deve carregar consigo (Transferir) toda informação (Estado) que o servidor precisará
para processá-la. Então, de fato, conexões devem conter todas as informações necessárias para
que a conexão seja completada com sucesso.
Gabarito: Correto
73. (CESPE – 2013 – SERPRO) Um web service pode ocorrer sobre o HTTP (hypertext transfer
protocol), utilizando-se os serviços RESTfull (representational state transfer).
Comentários:
Aplicações que sigam essas restrições são consideradas Aplicações RESTfull. Como vocês
devem ter notado, essas restrições não ditam a tecnologia a ser utilizada para o desenvolvimento
das aplicações. Em vez disso, a adesão a estas orientações e melhores práticas oferece a
oportunidade de uma aplicação escalável, visível, portátil, confiável e capaz de performar melhor.
Questão perfeita – um Web Service pode ocorrer sobre HTTP, utilizando os serviços RESTful.
Sabe por que essa questão foi anulada?
"Houve prejuízo do julgamento objetivo do item, pois, onde se lê “RESTfull” deveria ler-se “RESTful”.
Dessa forma,opta-se pela anulação do item."
Galera, quantas questões vocês já viram com erros cavalares e que não foram anuladas? Pois é, e
essa foi por conta de uma letra!
Gabarito: Anulada
74. (CESPE – 2015 – TJDFT) Em um Web Service RESTful, cada método é identificado por uma
URL única. Assim, quando o servidor recebe uma solicitação, ele identifica de forma
inequívoca a operação que será executada.
Comentários:

77
103
15176084732 - Leonardo
1184281
Aula 11
Essa questão é bizarra! Ela afirma que cada método é identificado por uma URL única. Na
verdade, todos os métodos têm a mesma URL. Cada Web Service tem uma URL única e contém
vários métodos. Ao invocar um serviço web, é necessário especificar qual o método pretendido
e os parâmetros necessários para esse método. Cada método de serviço web retorna uma
resposta que contém os resultados da execução do cliente. Honestamente, não entendi esse
gabarito!
Gabarito: Correto
75. (COPEVE-UFAL – 2012 – ALGÁS) REST é uma técnica de engenharia de software utilizada
no desenvolvimento de sistemas hipermídia distribuídos e adequada para a Web.
Comentários:
Eu sei que é estranho falar em REST como uma técnica de engenharia de software, mas não há
nada de errado nisso! Ademais, de fato ele é utilizado no desenvolvimento de sistemas
hipermídia distribuídos e muito adequadra a Web.
Gabarito: Correto
76. (CESPE – 2014 – ANATEL) REST é uma técnica de engenharia de software para sistemas
hipermídia distribuídos. De acordo com essa técnica, o estado da informação deve ser
mantido no cliente, e o servidor não deve guardar o estado da comunicação de nenhum
cliente que se comunique com o servidor, além de uma única requisição.
Comentários:
Novamente eu sei que é estranho falar em REST como uma técnica de engenharia de software,
mas não há nada de errado nisso! Ademais, de fato ele é utilizado no desenvolvimento de
sistemas hipermídia distribuídos. Por outro lado, o servidor não precisa lembrar o estado do
cliente. Em vez disso, os clientes devem incluir todas as informações necessárias na requisição
para que o servidor possa entendê-la e processá-la. Dentro de um mesmo contexto de conexão,

78
103
15176084732 - Leonardo
1184281
Aula 11
não existe mais de uma requisição HTTP, i.e., cada requisição HTTP é única e não reflete estado
no servidor.
Gabarito: Correto
77. (CESPE – 2013 – STF) A REST (Representational State Transfer), protocolo de comunicação
embasado em XML, permite a comunicação de mensagens entre aplicações por meio de
qualquer protocolo de comunicação em rede. Normalmente, esse protocolo é utilizado na
integração de sistemas legados.
Comentários:
REST não é um protocolo! Ele pode ser considerado um estilo arquitetural ou uma técnica de
engenharia de software. Além disso, ele não é embasado em XML – pode-se dizer que ele é
embasado (não obrigatoriamente) em HTTP.
Gabarito: Errado
78. (CESPE – 2015 – FUB) Em REST, os conectores precisam reter o estado das aplicações entre
as requisições, visto que eles dependem de informações de requisições que as antecederam
para entender determinada requisição.
Comentários:
Não é necessário manter o estado das aplicações entre as requisições – essa é uma questão
recorrente.
Gabarito: Errado
79. (CESPE – 2011 – MEC) Um web service pode ser desenvolvido, também, com o uso de REST,

79
103
15176084732 - Leonardo
1184281
Aula 11
Comentários:
A redação da questão a tornou ambígua. Um Web Service pode ser desenvolvido com uso de
REST ou com uso de SOAP, mas não ambos. Para mim, deveria ser anulada, mas a banca a
considerou errada.
Gabarito: Errado
80.(CESPE – 2010 – MPU) REST (Representationals State Transfer) é uma tecnologia que está
sendo utilizada em web services, como substituta das tecnologias SOAP (Simple Object
Access Protocol) e WSDL.
Comentários:
Nesse contexto, gostaria que vocês me respondessem uma pergunta: Quem é

mais simples: REST ou SOAP? Ora, REST! Sob esse aspecto, ele é bem mais
simples. Vejam essa imagem ao lado: REST é aquele cara mais simples e
descolado que sai de calça jeans e camiseta para trocar informações. Já o SOAP
é aquele cara mais pomposo e equipado que sai de terno, gravata e maleta para
trocar informações. Quem é o melhor, professor? Isso não existe, cada um é
adequado para um contexto.
Não há um melhor! Além disso, REST não substitui SOAP – são tecnologias concorrentes e cada
um é utilizado em seu contexto.
Gabarito: Errado
81. (CESPE – 2013 – MPU) Web services é um método de comunicação entre serviços na Web
que aderem estritamente ao XML, como é o caso de serviços cuja comunicação é baseada na
interface da arquitetura REST.
Comentários:

O REST não utiliza estritamente o XML!
Gabarito: Errado

80
103
15176084732 - Leonardo
1184281
Aula 11
82. (CESPE – 2010 – TCU) Uma equipe de desenvolvimento de software recebeu a incumbência
de desenvolver um sistema com as características apresentadas a seguir.
- O sistema deverá ser integrado, interoperável, portável e seguro.

- O sistema deverá apoiar tanto o processamento online, quanto o suporte a decisão e gestão
de conteúdos.
- O sistema deverá ser embasado na plataforma JEE (Java enterprise edition) v.6, envolvendo
servlets, JSP (Java server pages), Ajax, JSF (Java server faces) 2.0, Hibernate 3.5, SOA e web
services.
O líder da equipe iniciou, então, um extenso processo de coleta de dados com o objetivo de
identificar as condições limitantes da solução a ser desenvolvida e tomar decisões
arquiteturais e tecnológicas que impactarão várias características funcionais e não funcionais
do sistema, ao longo de seu ciclo de vida. A partir dessa coleta, o líder deverá apresentar à
equipe um conjunto de informações e de decisões. Com relação às diferentes arquiteturas e
tecnologias que, se escolhidas, impactarão as características do sistema descrito no texto,
julgue o item:
O estilo de arquitetura de software denominado REST (representational state transfer)

demanda mais recursos computacionais que o modelo de desenvolvimento de sistemas
embasado em SOAP (single object access protocol), por isso não é recomendável a adoção
do padrão REST de arquitetura de software no desenvolvimento do sistema em questão.
Comentários:
REST tem um overhead bem menor que o SOAP.
Gabarito: Errado
83. (CESPE – 2015 – MEC) As principais características do REST (representationl state transfer)
são interface uniforme, stateless e cache.
Comentários:

81
103
15176084732 - Leonardo
1184281
Aula 11

permite que o cliente ou seus componentes intermediários armazenem em cache respostas
e reutilizem-nas para pedidos posteriores. Isto reduz a carga no servidor e ajuda a melhorar
o desempenho.
Isso significa que, quando um primeiro cliente solicita um determinado recurso ao servidor,
esse processa a requisição e o cliente a armazena temporariamente em cache. Quando
houver uma nova requisição, a resposta armazenada já está pronta para ser utilizada.

contrato.
São realmente essas três características/restrições.
Gabarito: Correto
84.(FCC – 2014 – CM/SP) Pela sua simplicidade e facilidade de entendimento, praticamente

qualquer cliente ou servidor com suporte aos protocolos ...I.... pode fazer uso do REST. Uma de
suas principais vantagens é o aproveitamento da infraestrutura web existente, mas a baixa
segurança é seu principal ponto fraco. Em situações em que não se faz necessária alta
padronização e alta segurança essa tecnologia funciona bem. Os web services RESTful expõem
recursos para seus clientes, que são identificados através de ...II... . A manipulação dos recursos
se dá através de operações básicas como ...III... .
As lacunas I, II e III são, correta e respectivamente, preenchidas por:
a) TCP/IP - caches - PUT, GET, POST e DELETE

b) XML/JSON/RSS/Atom - URIs - CRUD stateless: Create, Read, Update, Delete

82
103
15176084732 - Leonardo
1184281
Aula 11
c) HTTP/HTTPS - URIs - PUT, GET, POST e DELETE

d) XML/JSON/RSS/Atom - URLs - CRUD stateless: Create, Read, Update, Delete
e) HTTP/HTTPS - caches - CRUD stateless: Create, Read, Update, Delete
Comentários:
Pela sua simplicidade e facilidade de entendimento, praticamente qualquer cliente ou servidor

com suporte aos protocolos HTTP/HTTPS pode fazer uso do REST. Os web services RESTful
expõem recursos para seus clientes, que são identificados através de URIs. A manipulação dos
recursos se dá através de operações básicas como PUT, GET, POST, DELETE.
Gabarito: Correto
85. (CESPE – 2012 – TJ/RO) Representational state transfer (REST), que utiliza o WSDL como
linguagem de descrição de serviços, é uma forma de implementação de SOA na web.
Comentários:
Não se utiliza WSDL. Pode-se utilizar o WSDL2 ou WADL.
Gabarito: Errado
86. (FGV – 2015 – DPE/RO) A REST (Representational State Transfer, em português

Transferência de Estado Representacional) dá ênfase:
a) na multiplicidade de representação de recursos, utilizando apenas os métodos padrão do

protocolo HTTP (GET, POST, PUT, DELETE, etc);
b) na multiplicidade de representação de métodos, utilizando apenas os recursos padrão do

c) em utilizar o protocolo SOAP sobre o protocolo HTTP;
d) na segurança por meio do protocolo HTTPS 2.0;
e) na integração baseada em troca de mensagens assíncronas por meio de web-sockets.

83
103
15176084732 - Leonardo
1184281
Aula 11
Comentários:
deletar um recurso.
A ênfase se dá na multiplicidade de representações de recursos, utilizando apenas os métodos

padrão do protocolo HTTP (GET, POST, PUT, DELETE, etc). Lembrem-se do que significa REST:
Representational State Transfer – portanto, há um foco grande na representação!
Gabarito: Letra A
87. (CESPE – 2017 – TRE/PE) REST (Representational State Transfer) é:
a) um estilo de desenvolvimento que utiliza o protocolo HTTP e se baseia na interação simples

entre cliente e servidor.
b) um software de infraestrutura em um sistema distribuído que auxilia no gerenciamento de

interações entre entidades distribuídas em serviços web.
c) uma linguagem web voltada a definição de predicados que se apliquem a classes de objetos
e de interações em um modelo UML.
d) uma linguagem de programação com tipos dinâmicos, voltada principalmente para

desenvolvimento de aplicações web.
e) um modelo de desenvolvimento de software estruturado e organizado como um conjunto

de classes de objeto e de relações entre essas classes.
Comentários:
Ficou mais fácil de entender agora? Essas restrições são correspondentes às

tecnologias/protocolos e ajudam a diferenciar uma arquitetura de um estilo arquitetural.
Professor, mas o que é o REST? REST significa REpresentational State Transfer e se trata de um
estilo arquitetural para projetar aplicações de rede distribuídas. Agora, sim, vamos falar mais a
fundo sobre o assunto da nossa aula...
Pessoal, essa questão tem quatro itens que não fazem o menor sentido, logo vamos comentar
direto o primeiro item. Notem só o nosso dilema! Eu falei para vocês diversas vezes que o REST
é um Estilo Arquitetural. O gabarito da questão afirma que REST é um Estilo de
Desenvolvimento. Ora, na minha opinião, questão errada e ponto final! Simples assim...

84
103
15176084732 - Leonardo
1184281
Aula 11
Porééééééém esse item foi retirado diretamente da última versão do Sommerville (9ª Ed.) e ele
afirma exatamente assim:
“REST é um estilo de desenvolvimento baseado em interação simples de cliente /servidor e que usa
o protocolo HTTP. REST é baseado na ideia de recurso identificável, o qual possui uma URI. Todas
as interações com recursos são baseadas em HTTP POST, GET, PUT e DELETE. Atualmente é muito
usado para implementar web services de baixo overhead”.
O que isso significa? Isso significa que, a partir de agora, vamos ter que considerar o REST – pelo
menos no contexto de provas de concurso – também como um Estilo de Desenvolvimento. Eu
discordo veementemente, não vejo o menor sentido nessa afirmação. Porém, contudo, todavia,
entretanto, se o Sommerville diz, vira referência! Bacana?
Gabarito: Letra A

85
103
15176084732 - Leonardo
1184281
Aula 11
LISTA DE QUESTÕES
services
1. (CESPE - 2013 - CNJ) Uma das formas de comunicação para encapsular dados transferidos
no formato XML para aplicações serviço web (Webservice) é o SOAP (Simple Object Access
Protocol).
2. (CESPE - 2013 - CNJ) A linguagem WSDL é utilizada para descrever web services limitadas ao
tipo request-response.
3. (CESPE - 2013 - CNJ) Nos registros de negócio UDDI, a descrição da forma de acesso aos web
services é um procedimento contido nas páginas verdes (green pages).
4. (CESPE - 2013 - TRE-MS) No que se refere a SOA e webservices, assinale a opção correta.
a) O WS-Security propõe uma série de extensões para aprimorar a segurança dos web
services no UDDI e no WSDL. Por questão de compatibilidade, essas extensões não afetam
os cabeçalhos do envelope SOAP.
b) UDDI é um serviço de diretório em que é possível registrar e localizar web services.
c) WSDL é descrito em formato XML e tem por única função descrever os valores e formatos
dos dados que serão intercambiados entre os sistemas.
d) SOAP é um protocolo do tipo statefull, independente de sistema operacional, embasado

em troca de mensagem one-way e projetado para ser simples e extensível por meio de
tecnologia XML.
e) SOA é uma arquitetura de desenvolvimento cujo objetivo é criar módulos funcionais

denominados serviços, fortemente acoplados e independentes de plataforma. É embasada
em XML e incentiva reutilização de código e interoperabilidades entre sistemas.
5. (CESPE - 2011 - MEC) O UDDI (Universal Description Discovery and Integration), que
corresponde a um registro de web services, é dividido em páginas brancas, amarelas e verdes,
nas quais são prestadas aos clientes informações sobre a empresa, os serviços por ela
oferecidos e as especificações WSDL desses serviços.
6. (CESPE - 2011 - BRB) Na estrutura de um documento WSDL, o elemento <portType>

descreve os tipos de dados usados por um web service.

86
103
15176084732 - Leonardo
1184281
Aula 11
7. (CESPE - 2011 - CBM-DF) Embora não tenha publicação automática, um web service permite
a utilização das regras de negócio através da rede e conecta aplicações de diferentes
fornecedores.
8. (CESPE - 2011 - PREVIC) No WSDL (Web Services Definition Language), é prescrito o leiaute
de banco de dados com descrições de serviços, por meio das quais os clientes de web service
podem procurar serviços relevantes.
9. (CESPE - 2011 - PREVIC) Web Services são sistemas embasados na Web que oferecem
serviços gerais para aplicações remotas, não requerendo interações imediatas de usuários
finais.
11. (CESPE - 2008 – TRT/BA) O UDDI é uma especificação técnica que tem como objetivo
descrever, descobrir e integrar web services; é embasado na tecnologia XML, que fornece
uma plataforma neutra de dados e permite descrever relações hierárquicas de modo natural.
12. (CESPE - 2008 - STJ) O serviço UDDI fornece uma interface para publicar e atualizar
informações acerca de serviços web; possibilita pesquisar descrições WSDL pelo nome; provê
uma interface que possibilita executar consultas de modo a recuperar uma entidade que
corresponda a uma chave ou recuperar entidades que correspondam a um conjunto de
critérios de busca.
13. (CESPE - 2008 - STJ) O WSDL separa a parte abstrata de uma descrição de serviço da parte
concreta; nessa descrição, a parte concreta contém as definições de tipos usados pelo serviço
e a parte abstrata especifica como e onde o serviço pode ser contatado. Os documentos
WSDL podem ser acessados via um serviço de diretório como o UDDI; as definições WSDL
podem ser geradas a partir de definições de interfaces escritas em outras linguagens.
14. (CESPE - 2008 - STJ) O SOAP encapsula mensagens que podem ser transmitidas via HTTP;
permite o modelo de interação cliente-servidor; define como usar XML para representar
mensagens de requisição e resposta. Um documento XML é transportado no corpo de uma
mensagem SOAP; no modelo cliente-servidor, o corpo de uma mensagem SOAP pode conter
uma requisição, mas não uma resposta.
15. (CESPE - 2008 – TRT/BA) No SOA, os web services permitem que os aplicativos se
comuniquem entre si de modo independente da plataforma e da linguagem de programação.
Os web services utilizam WSDL para descrever interfaces de aplicativos na linguagem XML.

87
103
15176084732 - Leonardo
1184281
Aula 11
16. (CESPE - 2008 – TRT/BA) Na visão do SOA, XML e WSDL são padrões abertos que permitem
que os serviços se comuniquem de maneira homogênea, independentemente da plataforma
de hardware, do sistema operacional e da linguagem de programação nos quais o serviço está
implementado.
17. (CESPE - 2009 - ANATEL) Os três padrões fundamentais que possibilitam comunicações
entre web services são: simple object access protocol (SOAP) — protocolo que define uma
organização para a troca estruturada de dados entre web services; web services description
language (WSDL) — protocolo que define como as interfaces dos web services podem ser
representadas; universal description, discovery and integration (UDDI) — padrão de
descoberta que define como são organizadas as informações de descrição do serviço,
permitindo que os solicitantes descubram os serviços. Um desses padrões não utiliza a XML
(extensible mark-up language).
18. (CESPE - 2009 – CEHAP/PB) São padrões de Web services o SOAP, o WSDL e o UDDI, todos
baseados em HTTP.
19. (CESPE - 2009 - INMETRO) Na SOA, a descrição do serviço é mantida em um repositório

WSDL, em formato UDDI (universal description, Discovery and integration).
20. (CESPE - 2009 - ANTAQ) Nos serviços web, clientes e servidores, direta ou indiretamente,
podem acessar documentos UDDI completos por meio de seus URIs (uniform resource
identifier), usando um serviço de diretório, tal como o WSDL.
21. (CESPE - 2009 – TCE/TO) Acerca da arquitetura orientada ao serviço (SOA), assinale a opção
incorreta.
a) Os principais conceitos do SOA são a visibilidade, a interação e os efeitos.
b) Na programação orientada a objetos, o foco está no empacotamento de dados com

operações, enquanto que, no SOA, o foco central é a interface entre as aplicações.
c) O SOA se constitui na base mais viável para o desenvolvimento de sistemas de grande

escala.
d) O UDDI (universal description, discovery, and integration) é um protocolo para descrever

componentes de serviços web disponíveis.
e) Nos web services, utiliza-se SOAP sobre HTTP para se realizar a comunicação entre os
serviços.
22. (CESPE - 2009 - ANTAQ) Um componente importante da arquitetura de serviços web é

formado por um serviço de diretório que armazena descrições de serviços. Esse serviço deve
obedecer ao padrão UDDI (universal description, discovery and integration).

88
103
15176084732 - Leonardo
1184281
Aula 11
23. (CESPE - 2010 - INMETRO) Em um sistema que adere a uma arquitetura orientada a serviços
(SOA), vários elementos da arquitetura estabelecem comunicações entre si, e recomenda-se
que adotem vários padrões e recursos para comunicação, como HTTP (hypertext transfer
protocol), WSDL (Web Services Description Language), SOAP (Single Object Acess Protocol),
WS-BPEL (Web Services – Business Processes Execution Language), UDDI (Universal
Description, Discover and Integration) e XML (eXtensible Markup Language), entre outros.
Assinale a opção que formula relação correta entre esses padrões e (ou) recursos.
a) Um documento escrito na linguagem WSDL adota formato com base na linguagem XML e
seu uso depende da existência do serviço UDDI.
b) UDDI é um protocolo para definição das interfaces de serviços ofertadas por um objeto que
presta serviços em uma arquitetura orientada a serviços.
c) Um documento SOAP é formado por um envelope e uma mensagem, sendo escrito em

aderência a esquemas definidos na linguagem XML e transportado usualmente em
mensagens HTTP.
d) WS-BPEL é uma notação para a representação abstrata de arquiteturas orientadas a

serviço, independente de plataforma e tecnologias de suporte.
e) HTTP, WSDL, UDDI, SOAP, WS-BPEL e SOA são tecnologias para a produção de
documentos digitais que adotam o XML como formato padronizado.
25. (CESPE - 2010 – TRE/MT) Com relação a web services, assinale a opção correta.
a) As arquiteturas de aplicação de web services são arquiteturas firmemente acopladas, nas

quais as ligações entre serviços não podem mudar durante a execução.
b) SOAP (Simple Object Access Protocol) é um protocolo com base em HTML que permite
troca de informações entre aplicações em um ambiente distribuído.
c) UDDI (Universal Description, Discovery and Integration) é um diretório para

armazenamento de informações a respeito de web sevices. Essas informações são descritas
em SOAP.
d) A linguagem WSDL (Web Services Description Language) é utilizada para descrever web
services.

89
103
15176084732 - Leonardo
1184281
Aula 11
e) Segundo o W3C (World Wide Web Consortium), web services são apropriados somente
para aplicações em que componentes de um sistema distribuído são executados em
plataformas semelhantes de um mesmo fornecedor.
26. (CESPE - 2011 – MEC) Web Service é uma solução lógica que oferece a possibilidade de
recuperar informações remotamente por meio de cloud computing. Esse serviço utiliza a
definição WSDL em um ou mais XML Schemas, que são armazenados na UDDI.
27. (CESPE - 2012 – PEFO/CE) SOAP é um protocolo leve destinado à troca de informações
estruturadas em um ambiente distribuído e descentralizado. Uma mensagem SOAP, por
exemplo, é um documento XML composto de três partes obrigatórias: envelope, cabeçalho
e corpo.
28. (CESPE - 2009 - ANTAQ) Web services é um tipo de arquitetura de sistema distribuído que
se caracteriza pela disponibilidade de serviços abstratos na Logical View, que se orienta pela
troca de mensagens entre requisitantes e provedores, independentemente das suas
plataformas de trabalho via XML.
29. (CESPE - 2012 – TJ/RO) Acerca de SOA e web services, assinale a opção correta.
a) Web service é projetado para operar dados entre máquinas, em redes de computadores,
mediante a linguagem UDDI.
b) No caso de implementação de web service, o contrato de serviço entre os agentes

envolvidos na aplicação pode possuir múltiplos esquemas XML (XML schema), com regras
como políticas de nível de serviço acordado (SLA).
c) Acoplamento forte, um princípio dos serviços do SOA, possibilita maior compatibilidade

de comunicação em ambientes heterogêneos, mediante o uso de XML na troca de dados.
d) Representational state transfer (REST), que utiliza o WSDL como linguagem de descrição
de serviços, é uma forma de implementação de SOA na web.
e) SOA é um aplicativo que segue as recomendações definidas na arquitetura web service.
30. (CESPE - 2013 – CNJ) Um dos elementos de uma mensagem SOAP é o corpo (body), no qual
devem estar contidas as informações de erro e status.
31. (CESPE - 2013 – ANTT) Web Services provêm um meio padrão para interoperação entre
diferentes aplicativos de software, que podem ser executados em uma variedade de
plataformas e(ou) frameworks.

90
103
15176084732 - Leonardo
1184281
Aula 11
32. (CESPE - 2015 – MPOG/ATI) As informações relativas a formato de protocolo e mensagem

são associadas às operações (elementos operation) por meio de elementos binding.
33. (CESPE - 2013 – TCE/RO) O SOAP permite a troca de mensagens estruturadas em ambiente
distribuído e descentralizado, com o uso de tecnologias XML. Essas mensagens podem ser
trocadas por uma variedade de protocolos subjacentes como, por exemplo, o HTTP.
34. (CESPE - 2013 – SERPRO) A comunicação entre sistemas clientes e servidores para troca de
mensagens pode ser realizada por meio de SOAP (simple object access protocol), que é um
protocolo para troca de informações estruturadas independente de linguagem de
programação.
35. (CESPE - 2013 – CNJ) Uma das formas de comunicação para encapsular dados transferidos
no formato XML para aplicações serviço web (webservice) é o SOAP (simple object access
protocol).
36. (CESPE - 2012 – MPE/PI) Em web services, utiliza-se o protocolo SOAP (simple object access
protocol) para a comunicação entre os serviços.
37. (CESPE - 2016 – TCE/PR) Em um web service, o termo namespace representa o nome do
elemento principal do maior nível hierárquico em um documento XML utilizado para troca de
mensagens.
38. (CESPE - 2009 - ANTAQ) Em serviços web, o SOAP pode ser transportado por protocolos
como REST, HTTP, SMTP e JMS.
39. (CESPE – 2017 – SE/DF) Serviços expressos por meio de contratos web services têm o
potencial de evitar completamente a transformação, objetivo-chave dos contratos de
serviços padronizados.
40. (CESPE – 2017 – SE/DF) Por oferecerem um framework de comunicação com base em
contratos de serviços fisicamente desacoplados, os web services permitem que um contrato
de serviços seja totalmente padronizado, independentemente de sua implementação.
41. (CESPE – 2017 – TRE/PE) A respeito de arquitetura orientada a serviços (SOA), assinale a
opção correta.
a) WS – Transaction é um padrão de suporte que garante que uma mensagem seja entregue
uma vez e apenas uma vez.
b) Trata-se de uma forma de desenvolvimento de sistemas distribuídos cujos componentes

são serviços autônomos, executados em computadores geograficamente distribuídos.
c) Um serviço na SOA é agnóstico, ou seja, dependente da aplicação que o utiliza.

91
103
15176084732 - Leonardo
1184281
Aula 11
d) WSDL (web service definition language) na SOA para Web é uma linguagem utilizada
como padrão para troca de mensagens e para definição de componentes de web services.
e) WS – realiable messaging é um padrão SOA que define como as informações devem ser
representadas em uma mensagem SOAP.
42. (CESPE – 2017 – TRE/BA) No que se refere a web services, assinale a opção correta.
a) As solicitações e respostas XML trafegam no protocolo HTTP, não sendo possível utilizá-
las nos protocolos FTP e SMTP.
b) Um dos componentes de um Web Service SOAP (Simple Object Access Protocol) é a UDDI
(Universal Description, Discovery and Integration), a qual é um arquivo do tipo XML que
descreve detalhadamente um Web Service, especificando como deve ser o formato de
entrada e saída de cada operação.
c) As duas formas de envio de mensagem para que um cliente possa efetuar solicitações a um
Web Service são One-Way Messaging e Request-Response Messaging.
d) O WSDL (Web Services Description Language) é uma linguagem para o desenvolvimento

de Web Services similar ao XML.
e) Os Web Services permitem a integração de sistemas, todavia dependem da linguagem de

programação sob a qual tenham sido desenvolvidos e do sistema operacional do computador
onde esses sistemas forem executados.
43. (CESPE - 2013 - TRE-MS) O WS-Security propõe uma série de extensões para aprimorar a
segurança dos web services no UDDI e no WSDL. Por questão de compatibilidade, essas
extensões não afetam os cabeçalhos do envelope SOAP.
44. (CESPE – 2013 – SERPRO) Os serviços embasados em colheita automática de metadados

(harvesting) são assíncronos e menos sofisticados que os providos pelas federações, sendo a
sobrecarga sobre os participantes consideravelmente menor.
45. (CESPE - 2008 – MPE/AM) No protocolo HTTP (hypertext transfer protocol), o método GET
é utilizado em solicitações enviadas pelo servidor ao navegador para que este solicite dados
ao usuário de uma página ou para que o próprio navegador forneça os dados solicitados.
46.(CESPE - 2011 – MEC) Em formulários HTML, apenas o método post é suportado; o método
get é utilizado em aplicações JavaScript.

92
103
15176084732 - Leonardo
1184281
Aula 11
47. (FCC – 2010 – AL/SP) GET e POST são alguns dos principais métodos que determinam o que
o servidor deve fazer com o URL fornecido no momento da requisição de um recurso.
Relacionado a esses métodos, considere:
I. Dados enviados em uma requisição utilizando o método GET ficam visíveis na linha de
endereço do navegador.
II. Se não for especificado um método, o POST é adotado como padrão.
III. O método GET é geralmente utilizado para enviar grandes quantidades de dados por meio
de um formulário.
IV. O método POST não exibe os dados enviados na linha de endereço do navegador.
Está correto o que se afirma APENAS em:
a) I e II.
b) I e IV.
c) II, III e IV.
d) III.
e) IV.
48.(UFF – 2009 – UFF) No tocante ao protocolo de transferência de hipertexto (HTTP), esse

protocolo da categoria "solicitação e resposta" possui três métodos de solicitação. São eles:
a) HEAD, BODY e INIT;

b) FLAG, TOS e TTL;
c) GET, HEAD e POST;
d) PUT, GET e INIT;
e) PUSH, POST e HEAD.
49.(MPE/RS - 2012 – MPE/RS) Um formulário em HTML é um modelo de entrada de um

conjunto de dados. O primeiro passo a ser dado para a construção de um formulário é fazer
as etiquetas que desenham as janelas de entrada de dados. Os métodos que transferem
dados do browser para o servidor são denominados ________ e ________.
a) input – output
b) post – get
c) push – pop
d) post – cat
e) push – pull
50. (FUMARC - 2014 – ALMG) Analise as seguintes afirmativas sobre os métodos HTML:

93
103
15176084732 - Leonardo
1184281
Aula 11
I. HTML POST é utilizado para enviar dados para serem processados em um servidor Web.
II. HTML GET solicita ao servidor apenas o cabeçalho de uma URL para que o cliente decida
se deve requisitar o conteúdo completo ou não.
III. HTML PUT é utilizado para criar recursos dentro de um servidor Web.
Estão CORRETAS as afirmativas:
a) I e II, apenas.
b) I e III, apenas.
c) II e III, apenas.
d) I, II e III.
51. (FAU - 2016 – JUCEPAR/PR) Que nome é dado aos pequenos arquivos que são gravados em
seu computador quando você acessa sites na Internet e que são reenviados a estes mesmos
sites quando novamente visitados?
a) Planilhas.
b) Cookies.
c) Trojan.
d) Virus.
e) Token.
52. (IESES - 2015 – TRE/MA) Das definições abaixo sobre cookies, assinale a afirmativa correta.
a) O cookie ou cookie HTTP é um aplicativo que quando é executado aumenta a segurança

do usuário na Internet.
b) Arquivo gerado pelo servidor WEB que fica armazenado na máquina do usuário e que
permite ao servidor buscar informações realizadas pelo usuário no site.
c) Para o servidor WEB gravar no cookie é necessário realizar o comando

setCookie("nomedocookie").
d) O cookie Web é arquivo que fica armazenado na máquina do usuário e que aumenta a
performance de navegação na WEB.
53. (FAU - 2016 – JUCEPAR/PR) Assinale a alternativa correta que contenha a definição de
Cookie:
a) Pacote de dados enviado por um website ao navegador e armazenado no computador do

usuário. Esse arquivo contém informações sobre as preferências de navegação do usuário.

94
103
15176084732 - Leonardo
1184281
Aula 11
b) Vírus que captura informações do usuário digitadas no navegador e as envia por e-mail
para um computador receptor.
c) Permite que aplicativos cliente/servidor possam trocar informações em total segurança,

protegendo a integridade e a veracidade do conteúdo que trafega na Internet.
d) Protocolo responsável por gerenciar a comunicação entre websites e navegadores. Este

protocolo torna esta comunicação altamente confiável através de autenticação dos usuários.
e) Certificado digital enviado por um website ao navegador autenticando a idoneidade da

comunicação estabelecida.
54. (FGV - 2016 - COMPESA) Quando um navegador solicita uma página da web, o servidor pode
fornecer informações adicionais junto com a página solicitada. Essas informações podem
incluir um cookie.
Em relação à cookies na arquitetura web, analise as afirmativas a seguir:
I. Uma linha no cabeçalho HTTP iniciada por Cookie: é a forma como os servidores enviam
cookies aos clientes. Espera-se que o cliente grave o cookie e o devolva em solicitações
subsequentes ao servidor.
II. Para remover um cookie do disco rígido do cliente, basta o servidor enviá-lo novamente
com uma data de expiração vencida.
III. Um cookie que não contém a informação de quando irá expirar permanece ativo por
tempo indeterminado.
Está correto o que se afirma em:
a) I, apenas.
b) II, apenas.
c) III, apenas.
d) I e II, apenas.
e) I, II e III.
55. (IBFC / EBSERH – 2017) Assinale a alternativa que apresenta o serviço de diretório onde
empresas podem registrar (publicar) e buscar (descobrir) por Serviços Web (Web Services):
a) UDDI
b) NIS
c) WSDL
d) X.500
e) LDAP

95
103
15176084732 - Leonardo
1184281
Aula 11
56. (IBFC / EBSERH – 2017) Web service é uma solução utilizada na integração de sistemas. Os
Web services são componentes que permitem às aplicações enviar e receber dados, como
padrão, em formato:
a) NAT
b) ARP
c) XML
d) TLS
e) XDR.
57. (IBFC / EBSERH – 2017) Conforme o W3C (World Wide Web Consortium) pode-se definir um
Web Service como sendo:
a) uma estrutura conceitual para reger projetos de engenharia de software.

b) técnicas baseadas em formalismos matemáticos para a especificação, desenvolvimento e
verificação dos sistemas de softwares e hardwares.
c) um modelo de referência que contém práticas necessárias à manutenção do software.
d) um sistema de software projetado para suportar a interoperabilidade entre máquinas
sobre rede.
e) um modelo de dados que representa um conjunto de conceitos dentro de um domínio e os
relacionamentos entre estes.
58. (IBFC / EMDEC – 2016) Quanto as tecnologias aplicadas em um Web Service temos:
"Para a representação e estruturação dos dados nas mensagens recebidas/enviadas é

utilizado o _______. As chamadas às operações, incluindo os parâmetros de entrada/saída,
são codificadas no protocolo_______. Os serviços (operações, mensagens, parâmetros, etc.)
são descritos usando a linguagem_______. O processo de publicação/pesquisa/descoberta de
Web Services utiliza o protocolo_______."
Assinale a alternativa que complete correta e respectivamente as lacunas:
a) SOAP - WSDL - UDDI - XML

b) WSDL - UDDI - XML - SOAP
c) UDDI-XML-SOAP-WSDL
d) XML - SOAP - WSDL - UDDI.
59. (CESPE - 2011 – MEC) Um web service pode ser desenvolvido, também, com o uso de REST,

96
103
15176084732 - Leonardo
1184281
Aula 11
60.(CESPE - 2016 – TCE/SC) A JAX-RS 2.0 fornece APIs portáteis para o desenvolvimento de
aplicações Web em conformidade com os princípios do estilo arquitetônico REST.
61. (CESGRANRIO - 2007 – REFAP/ES) O estilo arquitetural REST (Representational State

Transfer) para WEB tem como característica:
a) permitir o uso de RPC diretamente sobre SSL, para aplicações seguras.

b) acelerar a transferência do FTP com a implementação de cache.
c) combater o SPAM, utilizando redes neurais como técnica de aprendizagem.
d) usar SOAP para interoperabilidade entre sistemas heterogêneos.
e) utilizar os métodos HTTP: GET, POST, PUT e DELETE.
62. (CESPE - 2015 – MEC) Entre as restrições da REST está a interface uniforme, a qual requer
que um serviço ofereça várias operações e aguarde a solicitação dessas operações pelo
servidor.
63. (CESPE - 2015 – MEC) A fim de implementar serviços em REST, recomenda-se utilizar os
WSDL já existentes com mínima alteração do cabeçalho, informando somente que o
protocolo a ser utilizado é o REST.
64.(MPE/RS - 2012 – MPE/RS) Considere as seguintes afirmações a respeito de REST

(Representational State Transfer).
I. REST é um protocolo para troca de mensagens entre componentes de uma aplicação web.
II. REST é uma arquitetura, onde cada aplicação é um conjunto de recursos sobre os quais
podemos realizar ações.
III. Os formatos dos arquivos utilizados numa aplicação que segue REST são JSON, XML ou
YAML.
Quais estão corretas?
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e III.
e) Apenas II e III.
65. (CESPE - 2016 – MEC) A respeito dos conceitos de web services e REST, assinale a opção
correta.
a) O método POST é utilizado na atualização de um recurso existente.

97
103
15176084732 - Leonardo
1184281
Aula 11
b) Pode-se utilizar qualquer meio de transporte existente para o envio de uma requisição,
incluindo HTTP, SMTP e TCP.
c) O modelo REST impõe restrições ao formato da mensagem.
d) Ao desenvolver uma aplicação, o recurso é transferido pela rede.
e) As chamadas às URIs (uniform resource indicator) são feitas por meio de métodos HTTP,
os quais indicam para o serviço a ação a ser realizada com o recurso.
66. (CESPE - 2015 – TRE/MT) Acerca de REST (representational state transfer), assinale a
opção correta.
a) O protocolo REST utiliza SOAP e XML.
b) REST utiliza recurso não identificável baseado em PUT e GET.
c) REST pode ser utilizado para implementar WebServices de baixo overhead.
d) Embora opcionalmente, um recurso REST pode conter uma URI.
e) REST consiste em um estilo de desenvolvimento baseado em complexa interação

cliente/servidor.
67. (CESPE - 2016– TRE/PI) Acerca de REST (Representational State Transfer), assinale a opção
correta.
a) Na implementação do REST, todos os recursos devem responder a todos os métodos.
b) O método GET permite obter e alterar o estado atual de um recurso.
c) O método EXPUNGE permite excluir um recurso.
d) A arquitetura de comunicação entre aplicações baseia-se em um modelo rígido de recursos

e localizações.
e) O método MODIFY permite alterar um recurso.
68. (CESGRANRIO - 2008 – PETROBRÁS) A interoperabilidade entre aplicações nos dias

atuais é fortemente baseada no uso de web services. Duas abordagens arquiteturais distintas
para o projeto e implementação de web services têm-se firmado no cenário de tecnologia.
São elas:
a) REST e WS-*

98
103
15176084732 - Leonardo
1184281
Aula 11
b) SOAP e WSDL
c) RPC e RMI
d) SGML e HTML
e) B2B e B2C
69. (CESPE – 2013 – STF) A World Wide Web (WWW) é a maior implementação de um
sistema em conformidade com a arquitetura REST.
70. (CESPE – 2013 – BACEN) O estilo arquitetural REST define um conjunto de restrições para
uma aplicação, como, por exemplo, utilização de arquitetura par-a-par, manutenção de
informações de estado, não uso de cache no cliente e apresentação de uma interface
uniforme.
71. (CESPE – 2014 – ANTAQ) Em arquiteturas REST, nenhum contexto de cliente pode ser
mantido em servidor.
72. (CESPE – 2016 – FUNPRESP) Conexões REST devem conter todas as informações
necessárias para que a conexão seja completada.
73. (CESPE – 2013 – SERPRO) Um web service pode ocorrer sobre o HTTP (hypertext transfer
protocol), utilizando-se os serviços RESTfull (representational state transfer).
74. (CESPE – 2015 – TJDFT) Em um Web Service RESTful, cada método é identificado por uma
URL única. Assim, quando o servidor recebe uma solicitação, ele identifica de forma
inequívoca a operação que será executada.
75. (COPEVE-UFAL – 2012 – ALGÁS) REST é uma técnica de engenharia de software utilizada
no desenvolvimento de sistemas hipermídia distribuídos e adequada para a Web.
76. (CESPE – 2014 – ANATEL) REST é uma técnica de engenharia de software para sistemas
hipermídia distribuídos. De acordo com essa técnica, o estado da informação deve ser
mantido no cliente, e o servidor não deve guardar o estado da comunicação de nenhum
cliente que se comunique com o servidor, além de uma única requisição.
77. (CESPE – 2013 – STF) A REST (Representational State Transfer), protocolo de comunicação
embasado em XML, permite a comunicação de mensagens entre aplicações por meio de
qualquer protocolo de comunicação em rede. Normalmente, esse protocolo é utilizado na
integração de sistemas legados.
78. (CESPE – 2015 – FUB) Em REST, os conectores precisam reter o estado das aplicações entre
as requisições, visto que eles dependem de informações de requisições que as antecederam
para entender determinada requisição.

99
103
15176084732 - Leonardo
1184281
Aula 11
79. (CESPE – 2011 – MEC) Um web service pode ser desenvolvido, também, com o uso de REST,
80.(CESPE – 2010 – MPU) REST (Representationals State Transfer) é uma tecnologia que está
sendo utilizada em web services, como substituta das tecnologias SOAP (Simple Object
Access Protocol) e WSDL.
81. (CESPE – 2013 – MPU) Web services é um método de comunicação entre serviços na Web
que aderem estritamente ao XML, como é o caso de serviços cuja comunicação é baseada na
interface da arquitetura REST.
82. (CESPE – 2010 – TCU) Uma equipe de desenvolvimento de software recebeu a incumbência
de desenvolver um sistema com as características apresentadas a seguir.
- O sistema deverá ser integrado, interoperável, portável e seguro.

- O sistema deverá apoiar tanto o processamento online, quanto o suporte a decisão e gestão
de conteúdos.
- O sistema deverá ser embasado na plataforma JEE (Java enterprise edition) v.6, envolvendo
servlets, JSP (Java server pages), Ajax, JSF (Java server faces) 2.0, Hibernate 3.5, SOA e web
services.
O líder da equipe iniciou, então, um extenso processo de coleta de dados com o objetivo de
identificar as condições limitantes da solução a ser desenvolvida e tomar decisões
arquiteturais e tecnológicas que impactarão várias características funcionais e não funcionais
do sistema, ao longo de seu ciclo de vida. A partir dessa coleta, o líder deverá apresentar à
equipe um conjunto de informações e de decisões. Com relação às diferentes arquiteturas e
tecnologias que, se escolhidas, impactarão as características do sistema descrito no texto,
julgue o item:
O estilo de arquitetura de software denominado REST (representational state transfer)

demanda mais recursos computacionais que o modelo de desenvolvimento de sistemas
embasado em SOAP (single object access protocol), por isso não é recomendável a adoção
do padrão REST de arquitetura de software no desenvolvimento do sistema em questão.
83. (CESPE – 2015 – MEC) As principais características do REST (representationl state transfer)
são interface uniforme, stateless e cache.
84.(FCC – 2014 – CM/SP) Pela sua simplicidade e facilidade de entendimento, praticamente

qualquer cliente ou servidor com suporte aos protocolos ...I.... pode fazer uso do REST. Uma de
suas principais vantagens é o aproveitamento da infraestrutura web existente, mas a baixa
segurança é seu principal ponto fraco. Em situações em que não se faz necessária alta
padronização e alta segurança essa tecnologia funciona bem. Os web services RESTful expõem

100
103
15176084732 - Leonardo
1184281
Aula 11
recursos para seus clientes, que são identificados através de ...II... . A manipulação dos recursos
se dá através de operações básicas como ...III... .
As lacunas I, II e III são, correta e respectivamente, preenchidas por:
a) TCP/IP - caches - PUT, GET, POST e DELETE

b) XML/JSON/RSS/Atom - URIs - CRUD stateless: Create, Read, Update, Delete
c) HTTP/HTTPS - URIs - PUT, GET, POST e DELETE
d) XML/JSON/RSS/Atom - URLs - CRUD stateless: Create, Read, Update, Delete
e) HTTP/HTTPS - caches - CRUD stateless: Create, Read, Update, Delete
85. (CESPE – 2012 – TJ/RO) Representational state transfer (REST), que utiliza o WSDL como
linguagem de descrição de serviços, é uma forma de implementação de SOA na web.
86. (FGV – 2015 – DPE/RO) A REST (Representational State Transfer, em português

Transferência de Estado Representacional) dá ênfase:
a) na multiplicidade de representação de recursos, utilizando apenas os métodos padrão do

b) na multiplicidade de representação de métodos, utilizando apenas os recursos padrão do

c) em utilizar o protocolo SOAP sobre o protocolo HTTP;
d) na segurança por meio do protocolo HTTPS 2.0;
e) na integração baseada em troca de mensagens assíncronas por meio de web-sockets.
87. (CESPE – 2017 – TRE/PE) REST (Representational State Transfer) é:
a) um estilo de desenvolvimento que utiliza o protocolo HTTP e se baseia na interação simples

entre cliente e servidor.
b) um software de infraestrutura em um sistema distribuído que auxilia no gerenciamento de

interações entre entidades distribuídas em serviços web.
c) uma linguagem web voltada a definição de predicados que se apliquem a classes de objetos
e de interações em um modelo UML.
d) uma linguagem de programação com tipos dinâmicos, voltada principalmente para

desenvolvimento de aplicações web.

101
103
15176084732 - Leonardo
1184281
Aula 11
e) um modelo de desenvolvimento de software estruturado e organizado como um conjunto

de classes de objeto e de relações entre essas classes.

102
103
15176084732 - Leonardo
1184281
Aula 11
GABARITO
1. CORRETO 30. ERRADO 59. ERRADO

2. ERRADO 31. CORRETO 60. CORRETO
3. CORRETO 32. CORRETO 61. ERRADO
4. LETRA B 33. CORRETO 62. ERRADO
5. CORRETO 34. CORRETO 63. ERRADO
6. ERRADO 35. CORRETO 64. LETRA E
7. ERRADO 36. CORRETO 65. LETRA E
8. ERRADO 37. ERRADO 66. LETRA C
9. CORRETO 38. ANULADO 67. LETRA D
10. ERRADO 39. ERRADO 68. LETRA A
11. CORRETO 40. CORRETO 69. CORRETO
12. CORRETO 41. LETRA B 70. ERRADO
13. ERRADO 42. LETRA C 71. CORRETO
14. ERRADO 43. ERRADO 72. CORRETO
15. ERRADO 44. CORRETO 73. ANULADA
16. CORRETO 45. LETRA E 74. CORRETO
17. ERRADO 46. LETRA E 75. CORRETO
18. ERRADO 47. LETRA B 76. CORRETO
19. ERRADO 48. LETRA C 77. ERRADO
20. ERRADO 49. LETRA B 78. ERRADO
21. LETRA B 50. LETRA B 79. ERRADO
24. ERRADO 53. LETRA A 82. ERRADO
25. LETRA D 54. LETRA B 83. CORRETO
26. ERRADO 55. LETRA A 84. CORRETO
27. ERRADO 56. LETRA C 85. ERRADO
28. ERRADO 57. LETRA D 86. LETRA A
29. LETRA B 58. LETRA D 87. LETRA A

103
103
15176084732 - Leonardo
1184281

Curso 174518 Aula 11 23a7 Completo

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso 174518 Aula 11 23a7 Completo

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 11

IFRJ (Analista de Tecnologia da

15176084732 - Leonardo Silva da Costa Gomes

1 – Conceitos Básicos .................................................................................................................................2

2 – SOAP (Simple Object Access Protocol) ................................................................................................7

3 – WSDL (Web Services Description Language) .................................................................................... 10

4 – UDDI (Universal Description, Discovery And Integration) ................................................................ 13

6 – WS-Security (WSS) ............................................................................................................................ 20

7 – Protocolo HTTP ................................................................................................................................. 22

1 – Conceitos Básicos .............................................................................................................................. 30

Questões Comentadas ................................................................................................................................ 37

Lista de Questões ........................................................................................................................................ 86

Gabarito .................................................................................................................................................... 103

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

Com a evolução das redes de computadores, surgiram as aplicações distribuídas.

Web Services são componentes de aplicativos baseados em XML, autocontidos e

Eles são autocontidos, na medida em que não necessitam ou dependem de outros

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

Um Web Service é um sistema de software projetado para permitir interoperabilidade na

Isso permite a interoperabilidade entre aplicações e plataformas heterogêneas. Eles

▪ Web Services de Primeira Geração:

É composta por um núcleo de tecnologias e especificações abertas: WSDL, XSD, SOAP,

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

coletivamente representam carece de qualidade para executar projetos críticos com

▪ Web Services de Segunda Geração:

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

As interações entre o provedor e o agente são basicamente a publicação dos serviços. A

▪ Permite utilizar as regras de negócio através da rede;

SOAP (SIMPLE/SINGLE OBJECT ACCESS PROTOCOL)

WSDL (WEB SERVICES DESCRIPTION LANGUAGE)

UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION):

Eu preciso da atenção de vocês agora! É possível implementar serviços utilizando diversos

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

2 – SOAP (Simple Object Access Protocol)

SOAP é um protocolo projetado para invocar aplicações remotas em um ambiente

Bem, o que se pretende é garantir a interoperabilidade e intercomunicação entre diferentes

Galera, os elementos filhos imediatos do cabeçalho são chamados de blocos de cabeçalho.

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

Trata-se do elemento-raiz do documento XML – identifica o documento XML como uma

Ele carrega informações adicionais específicas para a aplicação, como Autenticação,

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

POST /InStock HTTP/1.1

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

3 – WSDL (Web Services Description Language)

Trata-se de um protocolo baseado em XML para troca de informações em ambientes distribuídos e

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

Definitions é um conjunto de definições de tipos de dados – ele é obrigatório (Não confundam

Galera, esses três componentes acima são componentes de

Há também o elemento <types>, que define tipos de dados

Há também o elemento <operation>, que se encontra dentro

O WSDL separa a descrição de um serviço em duas perspectivas: Abstrata e Concreta! A

A perspectiva concreta trata da implementação do serviço. Em outras palavras, ela descreve

Trata-se de separação de preocupações! A vantagem é que, caso a implementação do serviço

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

4 – UDDI (Universal Description, Discovery And Integration)

Trata-se de um diretório/registro para armazenamento de informações sobre Web Services – é um repositório

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

As Páginas Amarelas contêm uma classificação do serviço ou negócio disponíveis baseado

As Páginas Amarelas usam os esquemas de categorização industrial mais aceitos no mercado,

IFRJ (Analista de Tecnologia da Informação) Engenharia de Software - 2021 (Pós-Edital)

A Especificação UDDI fornece duas interfaces importantes: Publisher Interface e Inquiry