Interoperabilidade com XML-RPC e Web Services

Prévia do material em texto

ARQUITETURA DA INFORMAÇÃO 1 
 ......................................... 2 Aula 6: Interoperabilidade com XML - RPC e Web Services
 ............................................................................................................................. 2 Introdução
 ................................................................................................................................ 3 Conteúdo
XML-RPC .............................................................................................................................. 3 
Implementação em Java .................................................................................................. 6 
SOAP ..................................................................................................................................... 7 
Web Services ..................................................................................................................... 10 
SOAP Web Services .......................................................................................................... 10 
UDDI ................................................................................................................................... 12 
Criação de SOAP Web Services em Java .................................................................... 13 
Criação de Cliente dotNet ............................................................................................. 14 
Sistemas B2B e B2C ......................................................................................................... 15 
Atividade proposta .......................................................................................................... 16 
........................................................................................................................... 17 Referências
 ......................................................................................................... 18 Exercícios de fixação
Chaves de resposta ..................................................................................................................... 22 
 
 
 ARQUITETURA DA INFORMAÇÃO 2 
Introdução 
Com a popularização da Internet e aumento do comércio eletrônico, torna-se 
comum a necessidade de integração entre sistemas de diferentes plataformas, 
muitas vezes visando às transações financeiras e à logística. 
 
Nesse novo cenário, o uso de XML em plataformas de serviços estilo RPC, 
inicialmente utilizando soluções XML-RPC e posteriormente Web Services, 
apresenta-se como uma grande solução de integração, garantindo a 
interoperabilidade com acoplamento extremamente baixo. 
 
Com esse tipo de solução, novos horizontes se abriram, e sistemas voltados 
para o comércio entre empresas passaram a definir o conceito de B2B, 
posteriormente sendo expandido para o comércio direto com o consumidor, 
denominado B2C. 
 
Objetivo: 
1. Compreender o XML-RPC e o SOAP; 
2. Implementar a interoperabilidade via Web Services. 
 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 3 
Conteúdo 
 
XML-RPC 
Uma solução simples para a criação de aplicativos distribuídos interoperáveis é 
o uso de XML-RPC, opção de arquitetura na qual as chamadas e respostas RPC 
seguem o formato XML para os dados de envio e recepção. Características do 
XML-RPC: 
 
 Criado para ser tão simples quanto possível, definindo as interfaces de 
chamadas remotas, mas não implementando os métodos ouvintes nos 
servidores; 
 Utiliza um vocabulário baseado em XML; 
 Tem uma quantidade limitada de comandos (tags) para descrever 
funções, tipos de parâmetros e tipos de retorno; 
 Utiliza o protocolo HTTP para o transporte na Internet; 
 Voltado para a comunicação computador a computador, e não de 
usuário a computador; 
 O uso do protocolo HTTP e sintaxe XML permite sua passagem livre por 
firewalls; 
 Várias implementações de servidores e clientes XML-RPC podem ser 
encontradas. 
 
Um exemplo de chamada e resposta XML-RPC pode ser observado a seguir: 
 
 
(imagem representativa de chamada e resposta XML-RPC) 
 
 ARQUITETURA DA INFORMAÇÃO 4 
Entre os elementos da sintaxe XML-RPC encontram-se: 
 
 methodCall: 
Chamada de um método remoto a partir do cliente. 
 
 mehodResponse: 
Define a resposta enviada pelo servidor ao cliente. 
 
 methodName: 
Nome do método chamado no servidor. 
 
 Params: 
Setor de parâmetros da chamada ou resposta. 
 
 Param: 
Define um parâmetro, devendo conter seu valor e tipo. 
 
Os tipos aceitos no XML-RPC podem ser observados na seguinte tabela: 
 
 
 
Além desses tipos, podem ser criadas estruturas mais complexas com o uso de 
struct, como no exemplo a seguir: 
 
 
 ARQUITETURA DA INFORMAÇÃO 5 
 
 
 
Cada elemento de struct deve conter nome e valor, onde o valor pode ser outro 
struct, aplicado de forma recursiva. 
 
Também podem ser criadas coleções com o uso de array, podendo ter como 
elementos dessas coleções elementos struct, os quais podem também utilizar 
array nos seus valores (value). 
 
Logo, a combinação de estruturas complexas e coleções (ou vetores), de forma 
dinâmica e recursiva, permite expressar tipos de dados diversos com grande 
facilidade, o que viabiliza a implementação de clientes e servidores nas mais 
diversas plataformas. 
 
É importante observar também que a chamada dos procedimentos está sujeita 
a falhas, e uma resposta indicando que algo errado ocorreu utilizará o elemento 
fault. Esse elemento pode ser definido como uma estrutura composta do código 
do erro (faultCode) e mensagem do erro (faultString). 
 
 
 ARQUITETURA DA INFORMAÇÃO 6 
 
 
Implementação em Java 
Em termos de Java, uma biblioteca muito interessante para trabalhar com XML-
RPC é disponibilizada pelo Apache, sendo seu uso baseado no mapeamento de 
um simples Servlet, um arquivo de propriedades e uma classe de negócios bem 
independente. 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 7 
 
Com esses poucos componentes é criada a parte servidora do XML-RPC, sendo 
o cliente tão simples quanto, como pode ser observado a seguir. 
 
 
 
SOAP 
Em termos gerais, o SOAP (Simple Object Access Protocol) define um protocolo 
de comunicação remota estilo RPC com uso de XML, extensível e amplamente 
utilizado na comunicação com Web Services. Suas características principais são: 
 
1: Objetivar a comunicação entre aplicativos; 
2: Definir um formato padrão para envio de mensagens; 
3: Permitir a comunicação na Internet de forma transparente aos firewalls; 
4: Ser independente de plataforma e de linguagem de programação; 
5: Utilizar sintaxe XML, bastante simples e extensível; 
6: É uma recomendação da W3C desde o dia 24 de junho de 2003. 
 
A sintaxe do SOAP segue algumas regras importantes: 
• A mensagem é criada com uso da sintaxe XML; 
• Precisa utilizar os namespaces soap-envelop e soap-encoding; 
 
 ARQUITETURA DA INFORMAÇÃO 8 
• Não pode ser utilizado um DTD; 
• Não são permitidas instruções de processamento XML. 
 
O esqueleto de uma mensagem SOAP é apresentado a seguir: 
 
A seção Header é opcional e permite a inclusão de informações específicas do 
aplicativo, como autenticação e pagamento, por exemplo. Se essa seção estiver 
presente deverá constar como o primeiro elemento filho do envelope SOAP. 
 
A seção Header é opcional e permite a inclusão de informações específicas do 
aplicativo, como autenticação e pagamento, por exemplo. Se essa seção estiver 
presente deverá constar como o primeiro elemento filho do envelope SOAP. 
 
O elemento Body apresenta a mensagem em si, definindo chamada ouresposta 
de um serviço solicitado. 
 
Os elementos filhos de Body devem ter o namespace qualificado, como no 
exemplo seguinte com a chamada e a resposta. 
 
<?xml version="1.0"?> 
<soap:Envelope 
xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> 
 
<soap:Body xmlns:m="http://www.example.org/stock"> 
 <m:GetStockPrice> 
 <m:StockName>IBM</m:StockName> 
 </m:GetStockPrice> 
</soap:Body> 
 
</soap:Envelope> 
 
<?xml version="1.0"?> 
<soap:Envelope 
xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> 
 
 
 ARQUITETURA DA INFORMAÇÃO 9 
<soap:Body xmlns:m="http://www.example.org/stock"> 
 <m:GetStockPriceResponse> 
 <m:Price>34.5</m:Price> 
 </m:GetStockPriceResponse> 
</soap:Body> 
 
</soap:Envelope> 
 
A seção Fault é opcional e serve para indicar mensagens de erro. Quando 
presente na mensagem, Fault deve se apresentar como um elemento filho de 
Body, e permite apenas uma ocorrência nessa mensagem. 
 
Os subelementos de Fault são apresentados na tabela a seguir. 
 
Subelemento Significado 
<faultcode> Código do erro ocorrido 
<faultstring> Mensagem do erro 
<faultactor> Informações acerca do responsável pela falha 
<detail> Engloba informações específicas do aplicativo referentes ao 
erro. 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 10 
Web Services 
O conceito de serviços não é novidade em termos de programação, tratando de 
componentes independentes de software que podem ser acionados para 
realizar determinadas tarefas, permitindo através de seu conjunto realizar ações 
maiores segundo uma ordem de chamada definida pelo aplicativo solicitante. 
Em termos de Internet, os tipos de serviço mais difundidos são Web Services, 
os quais podem ser classificados em dois tipos distintos: 
 
SOAP Web Services, os quais permitem grande interoperabilidade com o uso do 
protocolo SOAP. 
 
RESTful Web Services, onde é utilizado REST (REpresentational State Transfer), 
e as mensagens podem utilizar sintaxe XML ou JSON (Java Script Object 
Notation). 
 
A grande diferença funcional entre o SOAP e o REST é a de que, enquanto o 
SOAP foca as chamadas de métodos remotos, o REST trabalha com envio e 
recepção de objetos ou recursos. 
 
Várias bibliotecas, como JQuery, apresentam maior facilidade em lidar com 
REST, já que uma característica deste é justamente a simplicidade da 
transferência de informações, sem o uso de grande formalismo, o que viabiliza 
que a resposta seja expressa diretamente em JSON, no entanto, o formalismo 
das mensagens SOAP permite sua utilização facilitada em grandes ferramentas 
corporativas. 
 
SOAP Web Services 
Além do protocolo SOAP, utilizado na comunicação entre aplicativos para Web 
Services desse tipo, será necessário também um descritor de serviços, o WSDL 
(Web Service Description Language). 
 
 
 ARQUITETURA DA INFORMAÇÃO 11 
É através desse WSDL que diversas IDEs, como Visual Studio e NetBeans, 
conseguem criar o cliente com as chamadas corretas, deixando o programador 
com a sensação de que está fazendo uma simples chamada local, e sem 
envolver nenhum esforço para o mesmo na criação dos stubs de comunicação. 
Um documento WSDL define os serviços como coleções de endpoints ou portas. 
Em WSDL, a definição abstrata de endpoints e mensagens é independente de 
sua implantação na rede ou das conversões do formato de dados. Isso permite 
a reutilização de definições abstratas: mensagens, que são descrições abstratas 
dos dados que estão sendo trocados, e os tipos de portas, que são coleções 
abstratas de operações. 
 
As especificações do protocolo e formato de dados concretos para um tipo de 
porta em particular constitui um vinculativo reutilizável. Uma porta é definida 
através da associação de um endereço de rede com um vínculo reutilizável, e 
um conjunto de portas de definir um serviço. Feitas essas considerações, um 
documento WSDL usa os seguintes elementos na definição de serviços de rede: 
 
 Types - Um recipiente para definições de tipo de dados usando algum 
tipo de gramática (como XSD). 
 Message - Uma definição abstrata do formato de dados da 
comunicação. 
 Operation - Uma descrição abstrata de uma ação suportada pelo 
serviço. 
 PortType - Um conjunto abstrato de operações apoiadas por um ou 
mais endpoints. 
 Binding - Um protocolo concreto e especificação do formato de dados 
para um tipo de porta (PortType) particular. 
 Port - Um endpoint simples, definido como uma combinação de um 
binding e um endereço de rede. 
 Service - Uma coleção de endpoints relacionados. 
 
 
 ARQUITETURA DA INFORMAÇÃO 12 
UDDI 
Opcionalmente, esses Web Services podem ser cadastrados em um sistema 
para catalogação de serviços denominado UDDI (Universal Discovery and 
Description Integration), o qual equivale, na prática, a um serviço de nomes e 
diretórios. 
 
A principal função do UDDI é retornar a URL do WSDL de um determinado 
serviço, após uma busca feita nos próprios registros desse catálogo, tendo 
como perfis de pesquisa: 
• White Pages, referindo-se à busca de serviços pelo nome; 
• Yellow Pages, tratando da busca por assunto; 
• Green Pages, baseado em características ténicas. 
 
Finalmente, é feita uma comparação no quadro seguinte entre as diversas 
tecnologias de processamento distribuídas comumente utilizadas no mercado 
em termos de protocolo, descritor de chamadas e serviço de nomes e 
diretórios. 
 
 
 
Para os Web Services do tipo RESTful é utilizado um descritor de serviços 
denominado WADL (Web Application Description Language). 
 
Em termos gerais, os RESTful Web Services não mantinham uma preocupação 
com relação ao registro, como o uso de UDDI para SOAP Web Services; no 
entanto, as versões atuais do UDDI já incorporam elementos de busca para 
serviços REST, e o jUDDI permite que os registros sejam adicionados com 
sintaxe JSON. 
 
 
 ARQUITETURA DA INFORMAÇÃO 13 
A interoperabilidade através de Web Services é garantida pelo uso de 
protocolos modo texto de larga aceitação, como SOAP, e a presença de 
descritores de serviço WSDL para facilitar a criação dos stubs, permitindo a 
plena integração entre diferentes tecnologias e alto nível de reuso dos serviços 
e acoplamento extremamente baixo. 
 
Criação de SOAP Web Services em Java 
A plataforma JEE5 trouxe grandes facilitadores, inclusive para a escrita de Web 
Services, pois ao contrário de diversos arquivos de configuração XML, hoje 
trabalhamos com simples código anotado. 
 
 
 
As anotações utilizadas são: 
 
@WebService – define a classe como um serviço na Web; 
@WebMethod – define um método para esse serviço; 
@WebParam – utilizado para definir parâmetros de chamada de um 
determinado método do Web Service. 
 
Baseado nessas anotações, o servidor (GlassFish, por exemplo) implementa 
toda a infraestrutura para disponibilização do serviço, além de gerar a WSDL do 
mesmo, bem como o XSD (XML Schema), se fazer necessário. 
 
 
 ARQUITETURA DA INFORMAÇÃO 14 
Criação de Cliente dotNet 
Como exemplo de interoperabilidade, pode ser criado um cliente dotNet a partir 
da WSDL do Web Service. 
 
A tela seguinte mostra a opção que deve ser utilizada na criação do código 
necessário para a comunicação de forma automatizada. 
 
Após adicionar a referência ao serviço, este pode ser invocado de forma muito 
simples a partir do código na linguagem escolhida dentro da plataforma dotNet, 
como pode ser observado a seguir, com usoda linguagem C#. 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 15 
É fácil observar, partindo desse exemplo, a grande facilidade com que as duas 
plataformas podem interagir via Web Services, demonstrando de forma simples 
como esse tipo de serviço garante a interoperabilidade. 
 
Sistemas B2B e B2C 
Atualmente, os termos B2B e B2C são amplamente utilizados no mercado, mas 
o que realmente representam? 
 
B2B (Business to Business) é a sigla utilizada no comércio eletrônico para 
definir transações comerciais entre empresas. Em outras palavras, é um 
ambiente onde uma empresa comercializa seus produtos para outras empresas. 
A natureza dessa operação pode ser revenda, transformação ou consumo. 
 
B2C (Business to Consumer) é a sigla que define a transação comercial 
entre empresa e consumidor final através de uma plataforma de e-commerce. A 
natureza dessa operação tende a ser apenas de consumo. 
 
Os Web Services representam um passo à frente para permitir a colaboração 
entre várias entidades na Web e na superação dos problemas de 
interoperabilidade que podem aparecer. Parceiros B2B podem se beneficiar ao 
permitir que as entidades de negócios exponham suas interfaces de modo 
simples e interoperável. 
 
Sistemas de informação baseados em uma arquitetura orientada a serviços que 
são capazes de integrar diferentes funcionalidades e oferecer um modelo de 
componente virtual que abstrai da peculiaridade de implementações específicas 
parecem ser uma solução muito atraente. 
 
O ambiente de execução de Web Services apoia B2B comum e cenários B2C, na 
qualidade de um sistema de informação que representa o ponto central de uma 
arquitetura de hub-and-spoke. Se dois parceiros desejam se comunicar, eles 
 
 ARQUITETURA DA INFORMAÇÃO 16 
simplesmente resumem suas funcionalidades via Web Services, não 
diretamente um para o outro. 
 
É feita uma distinção clara entre a interface e a implementação de um serviço, 
o que permite o registro, descoberta, composição e execução sem o 
conhecimento da localização da sua aplicação e tecnologia de implementação. 
Além disso, essa distinção apoia a definição semântica de um serviço, mesmo 
quando a sua aplicação não é necessariamente baseada em tecnologia 
semântica, mas talvez em um sistema legado. 
 
Em ambientes onde existe a necessidade de comunicação assíncrona entre 
empresas, como no modelo bancário, é também comum o uso de mensagerias 
interfaceando os sistemas de ambas as empresas via mensagens. 
 
Atividade proposta 
Com o uso do NetBeans e servidor GlassFish, implemente em Java um Web 
Service que efetue as quatro operações matemáticas básicas: soma, subtração, 
multiplicação e divisão. 
 
Utilize a opção "Testar Web Service” disponível a partir do NetBeans com o uso 
deste servidor específico, e teste as funcionalidades do serviço criado. 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 17 
Referências 
Laurent, S. Johnston, J. Dumbill, E. Programming Web Services with XML-
RPC. Editora O’Reilly, 2001. 
 
Kidd, E. XML-RPC HOWTO, Source Builders. 2001. 
http://www.tldp.org/HOWTO/pdf/XML-RPC-HOWTO.pdf 
 
Richardson, L. Ruby, S. RESTful Web Services. Editora O’Reilly, 2007. 
 
Englander, R. Java and SOAP. Editora O’Reilly, 2002. 
Saudate, A. SOA aplicado: Integrando com web services e além. Editora Casa 
do Código, 2012. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 18 
Exercícios de fixação 
Questão 1 
Qual das opções abaixo NÃO é uma característica do XML-RPC? 
a) Criado para ser tão simples quanto possível, definindo as interfaces de 
chamadas remotas, mas não implementando os métodos ouvintes nos 
servidores. 
b) Utiliza um vocabulário baseado em JSON. 
c) Tem uma quantidade limitada de comandos (tags) para descrever funções, 
tipos de parâmetros e tipos de retorno. 
d) Utiliza o HTTP para o transporte na Internet. 
e) Voltado para a comunicação computador a computador, e não de usuário a 
computador. 
 
Questão 2 
Em termos de XML-RPC, quando ocorre um erro no atendimento à solicitação, a 
mensagem referente a este erro será retornada em que elemento da resposta? 
a) params 
b) faultCode 
c) faultString 
d) param 
e) methodName 
 
Questão 3 
Com relação à sintaxe do SOAP, qual das opções está INCORRETA? 
a) A mensagem é criada com uso de XML. 
b) Precisa do namespace soap-envelop. 
c) Precisa do namespace soap-encoding. 
d) Pode ser utilizado um DTD. 
e) Não são permitidas instruções de processamento XML. 
 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 19 
Questão 4 
"Para o SOAP a seção _________ é opcional, e permite a inclusão de 
informações específicas do aplicativo, como autenticação e pagamento, por 
exemplo. Se esta seção estiver presente deverá constar como o primeiro 
elemento filho do envelope." 
Qual opção preenche corretamente a lacuna? 
a) Body 
b) Footer 
c) Fault 
d) Header 
e) Tail 
 
Questão 5 
Considere as afirmativas abaixo, com relação ao SOAP: 
I - Objetiva a comunicação entre o servidor e o usuário final. 
II – Permite a comunicação na Internet de forma transparente aos firewalls. 
III – Utiliza sintaxe JSON. 
IV – É independente de plataforma e de linguagem de programação. 
Qual a opção que indica a quantidade de afirmativas corretas? 
a) As quatro estão corretas. 
b) Apenas três estão corretas. 
c) Apenas duas estão corretas. 
d) Apenas uma está correta. 
e) Nenhuma das afirmativas está correta. 
 
Questão 6 
Para Web Services SOAP é utilizado um descritor de serviços denominado: 
a) WSDL 
b) UDDI 
c) XML 
d) SOAP 
e) REST 
 
 ARQUITETURA DA INFORMAÇÃO 20 
Questão 7 
Para definir um Web Service em linguagem Java através de anotações, a classe 
deve ser anotada com _________, cada método que precise ser exposto como 
serviço deve ser anotado com __________, e cada parâmetro presente em 
cada um desses métodos deve ser anotado com _________. 
Qual opção preenche corretamente as lacunas? 
a) @Stateless, @EJB e @Servlet 
b) @Stateless, @EJB e @MessageDriven 
c) @WebParam, @WebMethod e @WebService 
d) @Override, @Remote e @Local 
e) @WebService, @WebMethod e @WebParam 
 
Questão 8 
Um componente de grande relevância nos ambientes de computação distribuída 
é o sistema de registro, normalmente um serviço de nomes e diretórios. Quais 
são, respectivamente, os sistemas de registro para RMI-IIOP, CORBA e Web 
Services? 
a) RMI Registry, COS Naming e UDDI. 
b) JNDI, COS Naming e UDDI. 
c) WSDL, UDDI e SOAP. 
d) JNDI, COS Naming e WSDL. 
e) WSDL, CORBA IDL e RMI Registry. 
 
Questão 9 
Considerando-se os documentos WSDL, qual elemento é relacionado a "um 
conjunto abstrato de operações apoiados por um ou mais endpoints"? 
a) Message 
b) Types 
c) Binding 
d) PortType 
e) Service 
 
 
 ARQUITETURA DA INFORMAÇÃO 21 
Questão 10 
Qual o tipo de Web Service que trabalha com envio e recepção de objetos, e 
permite uso tanto de XML quanto JSON? 
a) SOAP 
b) WADL 
c) WSDL 
d) UDDI 
e) RESTful 
 
 
 
 ARQUITETURA DA INFORMAÇÃO 22 
Aula 6 
Exercícios de fixação 
Questão 1 - B 
Justificativa: A tecnologia XML-RPC utiliza um vocabulário baseado em XML. As 
demais opções estão corretas. 
 
Questão 2 - C 
Justificativa: A chamada dos procedimentos está sujeita a falhas, e uma 
resposta indicando que algo errado ocorreu utilizará o elemento fault. Este 
elemento pode ser definido como uma estrutura composta do código do erro 
(faultCode)e mensagem do erro (faultString). 
 
Questão 3 - D 
Justificativa: A sintaxe do SOAP não permite o uso de DTD. As demais opções 
estão corretas. 
 
Questão 4 - D 
Justificativa: A opção Header preenche corretamente a lacuna. A seção Body 
está relacionada à chamada e resposta do serviço, e a seção Fault refere-se à 
ocorrência de um erro qualquer. Quanto a Footer e Tail, estas opções não 
existem no SOAP. 
 
Questão 5 - C 
Justificativa: As afirmativas II e IV estão corretas, no entanto a I está incorreta, 
pois o foco do SOAP é a comunicação entre aplicativos, e a III está incorreta 
pelo fato de ser utilizado XML, e não JSON. 
 
Questão 6 - A 
Justificativa: Além do protocolo SOAP, utilizado na comunicação entre 
aplicativos para Web Services deste tipo, será necessário também um descritor 
 
 ARQUITETURA DA INFORMAÇÃO 23 
de serviços, o WSDL (Web Service Description Language). É através deste 
WSDL que diversas IDEs, como Visual Studio e NetBeans, conseguem criar o 
cliente com as chamadas corretas, deixando o programador com a sensação de 
que está fazendo uma simples chamada local, e sem envolver nenhum esforço 
para o mesmo na criação dos stubs de comunicação. 
 
Questão 7 - E 
Justificativa: As anotações utilizadas para definir o Web Service são: 
@WebService – define a classe como um serviço na Web. 
@WebMethod – define um método para este serviço. 
@WebParam – utilizado para definir parâmetros de chamada de um 
determinado método do Web Service. 
 
Questão 8 - B 
Justificativa: O quadro seguinte mostra uma síntese das diversas plataformas e 
componentes. 
 
Segundo o quadro, o RMI-IIOP utiliza JNDI, CORBA utiliza COS Naming e os 
Web Services trabalham com UDDI. 
 
Questão 9 - D 
Justificativa: Um documento WSDL usa os seguintes elementos na definição de 
serviços de rede: 
- Types - Um recipiente para definições de tipo de dados usando algum tipo de 
gramática (como XSD). 
- Message - Uma definição abstrata do formato de dados da comunicação. 
- Operation - Uma descrição abstrata de uma ação suportada pelo serviço. 
 
 ARQUITETURA DA INFORMAÇÃO 24 
- PortType - Um conjunto abstrato de operações apoiadas por um ou mais 
endpoints. 
- Binding - Um protocolo concreto e especificação do formato de dados para um 
tipo de porta (PortType) particular. 
- Port - Um endpoint simples, definido como uma combinação de um binding e 
um endereço de rede. 
- Service - uma coleção de endpoints relacionados. 
 
Questão 10 - E 
Justificativa: Para RESTful Web Services, onde REST significa REpresentational 
State Transfer), as mensagens podem utilizar sintaxe XML ou JSON (Java Script 
Object Notation). Diferentemente do SOAP, que foca as chamadas de métodos 
remotos, o REST trabalha com envio e recepção de objetos ou recursos. 
Quanto às demais opções, WADL descreve um Web Service REST, enquanto 
WSDL descreve um do tipo SOAP, e UDDI é o serviço de registro e localização 
de Web Services.