Roberta está desenvolvendo um determinado serviço na rede. Foi exigida a adoção de JMS na camada de transporte, e ela recebeu um arquivo WSDL para instruí-la acerca da utilização do serviço. Roberta logo notou que se tratava de um serviço do tipo:
- A)REST;
Errada, porque REST não é descrito tipicamente por WSDL e costuma usar recursos e endpoints, não contratos formais nesse estilo.
- B)GraphQL;
Errada, porque GraphQL trabalha com schema e consultas flexíveis, mas não é o modelo indicado por WSDL e JMS no enunciado.
- C)gRPC;
Errada, porque gRPC usa contratos via Protobuf e comunicação remota própria, não o padrão clássico sugerido pela questão.
- D)Web Socket;
Errada, porque WebSocket é um protocolo de comunicação em tempo real, não um serviço web descrito por WSDL.
- E)SOAP.
Certa, porque SOAP usa contrato formal de serviço e é frequentemente associado a WSDL e integração com mensageria como JMS.
Gabarito: E
Quando voce vê um arquivo WSDL, já acende a luzinha: isso é linguagem de descrição de serviços web. O WSDL informa como o serviço é chamado, quais operações existem e quais mensagens são trocadas. Em provas, essa pista costuma apontar para serviços no estilo SOAP, que usam contrato formal e padrão bem estruturado. A outra pista decisiva do enunciado é o uso de JMS na camada de transporte. JMS significa Java Message Service, isto é, um mecanismo de mensageria muito associado a integrações orientadas a mensagens, algo bem compatível com o ecossistema SOAP em vários cenários corporativos. SOAP pode trabalhar com diferentes protocolos de transporte e é comum em ambientes mais formais, com mensageria, contrato e forte padronização. Por isso o gabarito é a letra E. REST normalmente não depende de WSDL nem tem esse grau de contrato formal; GraphQL tem outro modelo de consulta; gRPC usa Protobuf e contratos diferentes; WebSocket é um canal bidirecional em tempo real, não um serviço descrito por WSDL. Em resumo: viu WSDL, pense em SOAP antes de qualquer aventura.