Começando com sabonete

Informações gerais

SOAP é um acrônimo para Simple Object Access Protocol que define um protocolo que é usado para trocar dados por meio de uma Chamada de Procedimento Remoto (RPC) com outros serviços ou clientes SOAP. Está disponível em duas versões:

SOAP 1.2 obsoleto SOAP 1.1, portanto, é recomendável usar SOAP 1.2, se possível.

Geralmente é construído em cima de HTTP/S e raramente em SMTP ou FTP, embora o suporte de acordo com o protocolo. Embora o HTTP seja frequentemente usado como protocolo de transporte subjacente, o SOAP usa apenas um subconjunto limitado dele. Para enviar solicitações, ele depende quase completamente da operação POST do HTTP. Invocações GET são teoricamente possíveis desde 1.2, embora o documento tenha que ser passado como parâmetro URI e, portanto, pode exceder um limite de aproximadamente 3000 caracteres que é rejeitado pela maioria dos frameworks. Além disso, as configurações relacionadas à segurança geralmente são definidas em um cabeçalho SOAP especial.

Embora SOAP e REST sejam chamados de webservices, eles são muito diferentes por natureza. Algumas estruturas distinguem entre WS (para serviços baseados em SOAP) e RS (para serviços baseados em REST).

A tabela a seguir fornece uma breve visão geral das diferenças entre os dois tipos de serviço da web.

Aspecto SABÃO RESTAR
Padrão SOAP, WSDL Sem padrão, apenas um estilo arquitetônico
Endereçamento de recursos Operações indiretas via SOAP por meio de identificadores exclusivos de recursos (URIs)
Tratamento de erros Mensagem de falha SOAP Códigos de resposta de erro HTTP e opcionalmente corpo de resposta
Representação de dados XML todas as codificações disponíveis em HTTP
Uso HTTP Como protocolo de transporte Ações em recursos (CRUD) mapeados em métodos HTTP (GET, POST, PUT, DELETE, …)
Suporte transacional via cabeçalho SOAP modelando uma transação como um recurso
Estado Stateful (ação SOAP faz parte do aplicativo) Stateless (solicitações independentes)
Descoberta de serviço UDDI / WSDL Nenhum na verdade; Start-URI da API deve retornar uma lista de subAPIs embora
Método Dentro do corpo do SOAP Método HTTP
Argumentos do método Definido pelo esquema XML no WSDL Por meio de cabeçalhos HTTP ou parâmetros de caminho/consulta ou matriz dentro do URI
Transição de estado Difícil de determinar por não se basear diretamente em dados Próxima invocação de URI
Suporte a cache Cache muitas vezes não desejado, Simples conforme definido por HTTP

SABÃO

Uma solicitação SOAP consiste em um envelope SOAP que deve conter um elemento body e pode conter um elemento header opcional. O elemento de cabeçalho é usado para passar certas configurações para o serviço como, por exemplo, WS-Security pode definir que a mensagem é criptografada ou WS-Coordination/WS -Transaction pode definir que a mensagem deve ser executada dentro de uma transação.

Uma requisição SOAP 1.2 simples via HTTP que adiciona dois valores pode ter esta aparência:

POST /calculator HTTP/1.1
Host: http://example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 224

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Body>
  <m:AddValues xmlns:m="http://example.org/calculator">
   <m:FirstValue>1</m:FirstValue>
   <m:SecondValue>2</m:SecondValue>
  </m:AddValues>
 </env:Body>
</env:Envelope>

Uma resposta à solicitação de amostra acima pode ter esta aparência

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 329

<?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:Body xmlns:m="http://www.example.org/calculator">
  <m:AddValuesResponse>
   <m:Result>3</m:Result>
  </m:AddValuesResponse>
 </soap:Body>
</soap:Envelope>

O exemplo acima definiu uma solicitação que invocou o método AddValues com dois argumentos, FirstValue definido como 1 e SecondValue definido como 2. A solicitação resultou em uma execução deste método no servidor SOAP remoto que calculou um valor de 3 como resultado que é encapsulado em um elemento de resposta separado, que por convenção é frequentemente o nome do método invocado mais uma string Response à direita para que qualquer pessoa que esteja inspecionando a resposta possa concluir que isso é a resposta de uma chamada anterior do método AddValue.

Diferenças entre SOAP 1.1 e 1.2

O SOAP 1.2 permite outros protocolos de transporte além do HTTP, desde que a estrutura de ligação seja suportada pelo protocolo.

O SOAP 1.1 é baseado no XML 1.0, enquanto o 1.2 é baseado no XML Infoset que permite serializar as mensagens SOAP com outros serializadores, então o serializador padrão XML 1.0 usado pelo SOAP 1.1. Isso permite, ou seja, serializar mensagens como mensagens binárias e, portanto, evitar alguma sobrecarga da natureza XML da mensagem. Além disso, o mecanismo de serialização do protocolo subjacente usado pode ser determinado por meio da vinculação de dados.

O aspecto de interoperabilidade também foi fomentado com o SOAP 1.2, definindo um modelo de processamento mais específico que seu antecessor, o que eliminou muitas possibilidades de interpretação. SOAP com API de anexos (SAAJ), que permite operar em mensagens SOAP 1.1 e 1.2, ajudou muitos implementadores de framework a processar e criar mensagens.

W3C lançou uma breve visão geral sobre as principais mudanças entre SOAP 1.1 e 1.2

Interoperabilidade de serviços da Web

Interoperabilidade de serviço da Web (também conhecido como WS-I) é uma diretriz de interoperabilidade regida por algumas empresas bem conhecidas, como IBM, Microsoft, Oracle e HP, para citar apenas um pouco. Essas diretrizes, entre outras, recomendam o uso de apenas um único elemento raiz no corpo SOAP, embora o SOAP permita conter vários elementos no corpo.

O WS-I consiste em

  • Perfil Básico WS-I a.k.a WSI-BP
  • Perfil de segurança básico WS-I
  • Perfil de encadernação de sabão simples

WSI-BP está disponível em 4 versões diferentes v1.0 (2004), v1.1 ( 2006), [v1.2 (2010)](http://ws-i.org/profiles/BasicProfile-1.2- 2010-11-09.html), v2.0 (2010) e define as diretrizes de interoperabilidade para o serviço web principal especificações como SOAP, WSDL e UDDI. Por meio do uso da Web Services Description Language (WSDL), os serviços SOAP podem descrever suas operações e métodos suportados em um conjunto coeso para outros terminais. O WSI-BP faz uso do WSDL para definir um conjunto mais restrito do que o esquema completo WSDL ou SOAP definiria e, assim, elimina parte da ambiguidade dentro da própria especificação e, assim, melhora a interoperabilidade entre os terminais.

#WSDL

Para anunciar as operações SOAP disponíveis, seus parâmetros, bem como os respectivos terminais a serem invocados para os clientes, um documento baseado em XML adicional é usado chamado ‘Web Services Description Language’ ou WSDL.

O WSDL descreve o terminal de serviço, a ligação das mensagens SOAP às operações, a interface das operações, bem como seus tipos aos clientes. O WSDL está, como o SOAP, disponível em 2 versões que diferem ligeiramente em sua sintaxe, embora expressem quase a mesma semântica para o cliente.

##WSDL 1.1

Uma descrição WSDL 1.1 contém uma seção service, uma binding, uma portType e uma message. Ele pode ainda importar ou definir esquemas dentro do arquivo WSDL, como pode ser visto em um arquivo WSDL de amostra que corresponde ao exemplo de calculadora mostrado acima:

<wsdl:definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
                  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                  xmlns:calc="http://example.org/calculator"
                  xmlns:tns="http://example.org/calculatorService"
                  targetNamespace="http://example.org/calculatorService">

    <!--
      Abstract type definitions
    -->

    <wsdl:types>
        <!--
        <xs:schema>
            <xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
        </xs:schema>
        -->
        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:tns="http://example.org/calculator"
                   targetNamespace="http://example.org/calculator"
                   elementFormDefault="qualified"
                   attributeFormDefault="qualified">

            <xs:element name="AddValuesRequest" type="tns:AddValuesType" />
            <xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />

            <xs:complexType name="AddValuesType">
                <xs:sequence>
                    <xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                    <xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                </xs:sequence>
            </xs:complexType>

            <xs:complexType name="AddValuesResponseType">
                <xs:sequence minOccurs="1" maxOccurs="1">
                    <xs:element name="Result" type="xs:int" />
                </xs:sequence>
            </xs:complexType>

            <xs:attribute name="Timestamp" type="xs:dateTime" />
            <xs:element name="CalculationFailure">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="ErrorCode" type="xs:int" />
                        <xs:element name="Reason" type="xs:string" />
                    </xs:sequence>
                    <xs:attribute ref="tns:Timestamp" use="required" />
                </xs:complexType>
            </xs:element>

        </xs:schema>
    </wsdl:types>

    <!--
        Abstract message definitions
    -->

    <wsdl:message name="AddValuesRequest">
        <wsdl:part name="in" element="calc:AddValuesRequest" />
    </wsdl:message>
    <wsdl:message name="AddValuesResponse">
        <wsdl:part name="out" element="calc:AddValuesResponse" />
    </wsdl:message>
    <wsdl:message name="CalculationFault">
        <wsdl:part name="fault" element="calc:CalculationFailure" />
    </wsdl:message>

    <!--
        Abstract portType / interface definition
    -->

    <wsdl:portType name="CalculatorEndpoint">
        <wsdl:operation name="AddValues">
            <wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
            <wsdl:input message="tns:AddValuesRequest" />
            <wsdl:output message="tns:AddValuesResponse" />
            <wsdl:fault name="CalculationFault" message="tns:CalculationFault" />
        </wsdl:operation>
    </wsdl:portType>

    <!--
      Concrete binding definition
    -->

    <wsdl:binding name="CalculatorBinding" type="tns:CalculatorEndpoint">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="AddValues">
            <soap:operation soapAction="http://example.org/calculator/AddValuesMessage" />
            <wsdl:input>
                <soap:body parts="in" use="literal" />
            </wsdl:input>
            <wsdl:output>
                <soap:body parts="out" use="literal" />
            </wsdl:output>
            <wsdl:fault name="CalculationFault">
                <soap:fault name="CalculationFault" use="literal" />
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>

    <!--
        Concrete service definition
    -->

    <wsdl:service name="CalculatorService">
        <wsdl:port name="CalculatorServicePort" binding="tns:CalculatorBinding">
            <soap:address location="http://localhost:8080/services/calculator" />
        </wsdl:port>
    </wsdl:service>

</wsdl:definitions>

Uma seção service define os endpoints concretos que o serviço escutará para solicitações recebidas. A seção binding vincula uma operação a um estilo concreto e define quais formatos de mensagem o servidor espera ou o cliente pode esperar.

A seção abstrata é composta por um bloco portType que define as operações oferecidas pelo serviço e quais mensagens são trocadas. As mensagens são especificadas em seu bloco on e vinculadas aos tipos de esquema dos quais os argumentos e valores de retorno são instâncias. As mensagens podem declarar parâmetros ou retornar valores como in, out ou inout. Enquanto os dois primeiros são bastante simples de entender, o último imita o comportamento dos argumentos passados ​​por referência. Como o pass-by-ref não é suportado em algumas linguagens, esse efeito geralmente é simulado por meio de determinados manipuladores.

##WSDL 2.0

A mesma calculadora pode ser descrita no WSDL 2.0 assim:

<?xml version="1.0" encoding="utf-8" ?>
<wsdl:description xmlns:xs="http://www.w3.org/2001/XMLSchema"
                  xmlns:wsdl="http://www.w3.org/ns/wsdl"
                  xmlns:soap="http://www.w3.org/ns/wsdl/soap"
                  xmlns:calc="http://example.org/calculator"
                  xmlns:tns="http://example.org/calculatorService"
                  targetNamespace="http://example.org/calculatorService">

    <!--
      Abstract type definitions
    -->

    <wsdl:types>
        <!--
        <xs:schema>
            <xs:import namespace="http://example.org/calculator" schemaLocation="calc/calculator.xsd" />
        </xs:schema>
        -->
        <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                   xmlns:tns="http://example.org/calculator"
                   targetNamespace="http://example.org/calculator"
                   elementFormDefault="qualified"
                   attributeFormDefault="qualified">

            <xs:element name="AddValuesRequest" type="tns:AddValuesType" />
            <xs:element name="AddValuesResponse" type="tns:AddValuesResponseType" />

            <xs:complexType name="AddValuesType">
                <xs:sequence>
                    <xs:element name="FirstValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                    <xs:element name="SecondValue" type="xs:int" minOccurs="1" maxOccurs="1" />
                </xs:sequence>
            </xs:complexType>

            <xs:complexType name="AddValuesResponseType">
                <xs:sequence minOccurs="1" maxOccurs="1">
                    <xs:element name="Result" type="xs:int" />
                </xs:sequence>
            </xs:complexType>

            <xs:attribute name="Timestamp" type="xs:dateTime" />
            <xs:element name="CalculationFault">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="ErrorCode" type="xs:int" />
                        <xs:element name="Reason" type="xs:string" />
                    </xs:sequence>
                    <xs:attribute ref="tns:Timestamp" use="required" />
                </xs:complexType>
            </xs:element>

        </xs:schema>
    </wsdl:types>

    <!--
        Abstract interface
    -->

    <wsdl:interface name="CalculatorInterface">
        <wsdl:fault name="fault" element="calc:CalculationFault" />
        <wsdl:operation name="AddValues" pattern="http://www.w3.org/ns/wsdl/in-out" style="http://www.w3.org/ns/wsdl/style/iri" wsdl:safe="true">
            <wsdl:documentation>Adds up passed values and returns the result</wsdl:documentation>
            <wsdl:input messageLabel="in" element="calc:AddValuesRequest" />
            <wsdl:output messageLabel="out" element="calc:AddValuesResponse" />
            <wsdl:outfault messageLabel="fault" ref="tns:fault" />
        </wsdl:operation>
    </wsdl:interface>

    <!--
        Concrete binding definition
    -->

    <wsdl:binding name="CalculatorBinding" interface="tns:CalculatorInterface" type="http://www.w3.org/ns/wsdl/soap" soap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
        <wsdl:operation ref="tns:AddValues" soap:mep="http://www.w3.org/2003/05/soap/mep/soap-response" />
        <wsdl:fault ref="tns:fault" soap:code="soap:Sender" />
    </wsdl:binding>

    <!--
        Concrete service definition
    -->

    <wsdl:service name="CalculatorService" interface="tns:CalculatorInterface">
        <wsdl:endpoint name="CalculatorEndpoint" binding="tns:CalculatorBinding" address="http://localhost:8080/services/calculator" />
    </wsdl:service>

</wsdl:description>

Diferenças entre WSDL 1.1 e 2.0

Uma visão geral gráfica sobre as diferenças entre as duas versões pode ser vista na imagem abaixo.

insira a descrição da imagem aqui(Fonte)

Como pode ser visto na imagem, a seção message foi removida, que agora está contida na seção interface. Além disso, alguns dos elementos foram renomeados, outros têm uma sintaxe diferente, mas em geral ambas as versões WSDL fazem basicamente o mesmo com a versão 2.0, exigindo um pouco menos de sobrecarga de escrita em comparação com 1.1.

Além da menor pegada na definição de serviços baseados em SOAP via WSDL 2.0, a versão mais recente também fornece capacidades para definir serviços REST através do WSDL 2.0 ou mesmo O WADL NÃO é recomendado para serviços RESTful, pois contradiz a ideia real por trás dele.

Qual estilo preferir

A seção de ligação WSDL descreve como o serviço está ligado ao protocolo de mensagens SOAP. O exemplo acima usou document como estilo de ligação, o que permite estruturar o corpo SOAP da maneira queremos, desde que a saída resultante seja uma instância XML válida. Este é o estilo de ligação padrão e muitas vezes referido como ‘Estilo orientado a mensagens’.

Em contraste com o estilo document, os corpos de solicitação do estilo RPC devem conter o nome da operação e o conjunto de parâmetros do método. A estrutura da instância XML é, portanto, predefinida e não pode ser alterada.

Além do estilo de vinculação, a seção de vinculação também define um modelo de tradução para vinculações a mensagens SOAP no nome de literal ou encoded. A diferença entre os dois é que o modelo literal precisa estar em conformidade com uma estrutura XSD definida pelo usuário, que pode ser usada para validar as solicitações e respostas, enquanto o modelo codificado precisa usar tipos de dados XSD como xs:integer ou xs:string, mas em troca, portanto, não precisa estar em conformidade com nenhum esquema definido pelo usuário. No entanto, isso dificulta a validação do corpo da mensagem ou a transformação da mensagem via XSLT para outro formato.

A combinação do estilo de vinculação com o modelo de uso permite, na verdade, 4 resultados de mensagens diferentes. Uma quinta entrada é adicionada à lista que é comumente usada (embora não faça realmente parte do padrão).

  • RPC / codificado
  • RPC / literal
  • Documento / codificado
  • Documento / literal
  • Documento/literal (embrulhado)

No estilo documento/literal de mensagens, existe um padrão que é conhecido como documento/literal encapsulado. Este é apenas um padrão e não faz parte da especificação WSDL. Esse padrão é mencionado no JSR 224 (JAX-WS: Java API for XML based web services). (Fonte)

A seção abaixo fornece uma visão geral sobre as diferenças em relação ao WSDL ou declaração de esquema e seu impacto no formato de mensagem SOAP resultante ao alterar o estilo de ligação ou as definições do modelo de uso.

RPC / codificado

WSDL:

...
<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" type="xsd:int" />
  <wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" type="xsd:int" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'RPC' and use to 'encoded' -->
...

Solicitação de SOAP

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue xsi:type="xsd:int">1</FirstValue>
      <SecondValue xsi:type="xsd:int">2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

Resposta SOAP

<soap:envelope>
  <soap:body>
    <AddValuesResponse>
      <Result xsi:type="xsd:int">3</Result>
    </AddValuesResponse>
  </soap:body>
</soap:envelope>

Prós

  • WSDL direto
  • Nome da operação e elementos disponíveis na solicitação e resposta

Contras

  • Declaração explícita de tipos XSI
  • Difícil de validar
  • Não compatível com WS-I

RPC / literal

WSDL:

...
<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" type="xsd:int" />
  <wsdl:part name="SecondValue" type="xsd:int" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" type="xsd:int" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'RPC' and use to 'literal' -->
...

Solicitação de SOAP

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue>1</FirstValue>
      <SecondValue>2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

Resposta SOAP

<soap:envelope>
  <soap:body>
    <AddValuesResult>
      <Result>3</Result>
    </AddValuesResult>
  </soap:body>
</soap:envelope>

Prós

  • WSDL direto
  • Nome da operação e elementos disponíveis na solicitação e resposta
  • Nenhuma especificação do tipo XSI necessária
  • Compatível com WS-I

Contras

  • Difícil de validar

Documento / codificado

Não faz sentido, portanto, omitido.

Documento / literal

WSDL:

...
<types>
  <schema>
    <element name="FirstValueElement" type="xsd:int" />
    <element name="SecondValueElement" type="xsd:int" />
    <element name="ResultValueElement" type="xsd:int" />
  </schema>
</types>

<wsdl:message name="AddValues">
  <wsdl:part name="FirstValue" element="FirstValueElement" />
  <wsdl:part name="SecondValue" element="SecondValueElement" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="Result" element="ResultValueElement" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'Document' and use to 'literal' -->
...

Solicitação de SOAP

<soap:envelope>
  <soap:body>
    <FirstValueElement>1</FirstValueElement>
    <SecondValueElement>2</SecondValueElement>
  </soap:body>
</soap:envelope>

Resposta SOAP

<soap:envelope>
  <soap:body>
    <ResultElement>3</ResultElement>
  </soap:body>
</soap:envelope>

Prós

  • Sem codificação de tipo XSI
  • Capaz de validar o corpo
  • WS-I compatível com restrições

Contras

  • WSDL é mais complicado devido à definição XSD adicional
  • O nome da operação foi perdido
  • WS-I só permite um filho no corpo SOAP

Documento/literal (embrulhado)

WSDL:

...
<types>
  <schema>
    <element name="AddValues">
      <complexType>
        <sequence>
          <element name="FirstValue" type="xsd:int" />
          <element name="SecondValue" type="xsd:int" />
        </sequence>
      </complexType>
    </element>
    <element name="AddValuesResponse">
      <complexType>
        <sequence>
          <element name="ResultValue" type="xsd:int" />
        </sequence>
      </complexType>
    </element>
  </schema>
</types>

<wsdl:message name="AddValues">
  <wsdl:part name="in" element="AddValues" />
</wsdl:message>
<wsdl:message name="AddValuesResponse">
  <wsdl:part name="out" element="AddValuesResponse" />
</wsdl:message>

<wsdl:portType name="CalculatorEndpoint">
  <wsdl:operation="AddValues">
    <wsdl:input message="AddValues" />
    <wsdl:output message="AddValuesResponse" />
  </wsdl:operation>
</wsdl:portType>

<!-- binding style set to 'Document' and use to 'literal' -->
...

Solicitação de SOAP

<soap:envelope>
  <soap:body>
    <AddValues>
      <FirstValue>1</FirstValue>
      <SecondValue>2</SecondValue>
    </AddValues>
  </soap:body>
</soap:envelope>

Resposta SOAP

<soap:envelope>
  <soap:body>
    <AddValuesResponse>
      <Result>3</Result>
    </AddValuesResponse>
  </soap:body>
</soap:envelope>

Prós

  • Sem codificação de tipo XSI
  • Capaz de validar o corpo
  • Nome da operação e elementos disponíveis na solicitação e resposta
  • Compatível com WS-I

Contras

  • WSDL é mais complicado devido à definição XSD adicional

#UDDI

O Universal Description, Discovery and Integration (UDDI) é uma iniciativa aberta da indústria criada em 2000 que atua como um registro de páginas amarelas baseado em XML para serviços da web que ajuda a encontrar serviços que resolvem tarefas específicas. Para encontrar um serviço apropriado, um serviço precisa ser registrado primeiro em um Web Service Registry, como o UDDI.

O UDDI funciona na troca de mensagens SOAP e fornece acesso a documentos WSDL que podem ser usados ​​para invocar o serviço web real.

O UDDI fornece critérios de pesquisa como

*identificador comercial

  • nome da empresa *localização da empresa
  • categoria de negócio
  • tipo de serviço por nome
  • URLs de descoberta

No entanto, uma grande desvantagem do UDDI atual é que ele só permite usar um único critério em uma instrução de pesquisa. Certos implementadores, portanto, modularizaram suas implementações de UDDI para permitir que consultas gerem vários UDDIs simultaneamente e, em seguida, agregam os resultados retornados.

Na prática, no entanto, o UDDI não é usado com tanta frequência. Alguns estão até dizendo que o UDDI está morto desde que a IBM, Microsoft e SAP [encerraram seus serviços UDDI em 2005](https://web.archive.org/web/20070704154230/http://www.theserverside.net/news/ thread.tss?thread_id=38136).

Notas adicionais:

O SOAP/WSDL fornece uma ampla gama de suporte a ferramentas e também permite gerar dinamicamente classes de stub para clientes e servidores, pois o tipo de mensagens e dados trocados é bem definido por meio dos esquemas XSD integrados ou vinculados.

Embora o WSDL 2.0 tenha menos sobrecarga na definição de serviços da Web, algumas linguagens ainda não adotaram o novo padrão. Ou seja em Java, ferramentas populares como wsimport (da Oracle/Sun) ou wsdl2java (do Apache CXF) não são capazes de lidar com descrições WSDL 2.0 corretamente. Portanto, por motivos de compatibilidade, ainda é recomendável usar o WSDL 1.1. Se você precisar desenvolver um serviço SOAP baseado em WSDL 2.0 em Java, dê uma olhada em wsdl2java do projeto Apache Axis2.

Mais populares hoje em dia, no entanto, são os serviços de API baseados em HTTP, que misturam invocações de operação HTTP com URIs limpos e compreensíveis por humanos e certas personalizações no protocolo para realizar seu trabalho, serviços baseados em REST, que cumprem totalmente às recomendações reais ou aos próprios protocolos de nível de byte, como OFTP2.

SOAP ainda é útil hoje em dia se você não puder mapear sua tarefa diretamente para recursos, como os serviços de base HTTP/REST fazem, pois a tarefa a ser cumprida representa naturalmente uma ação ou precisa definir certa semântica de transação. Além disso, se você não tiver recursos para definir ou implementar seu próprio protocolo, provavelmente será melhor usar SOAP. SOAP é especialmente útil se você tiver que lidar com orquestração, pois a descrição WSDL em combinação com UDDI permite combinar serviços dinamicamente.

2: https://www.wikiod.com/pt/rest/comecando-com-o-descanso#REST sobre HTTP

Criando um Web Service Simples e Clientes com JAX-WS (Documento/literal)

Este é o diretório do projeto.

Diretório de projetos

  1. Uma interface de endpoint de serviço

Primeiro, criaremos uma interface de terminal de serviço. A anotação javax.jws.WebService @WebService define a classe como um terminal de serviço da web.

<pré> <código> import javax.jws.WebMethod; importar javax.jws.WebService; import javax.jws.soap.SOAPBinding; import javax.jws.soap.SOAPBinding.Style; import javax.jws.soap.SOAPBinding.Use;

// Interface de serviço com customização de targetNamespace @WebService(targetNamespace = “http://hello-soap/ws”) @SOAPBinding(style = Style.DOCUMENT, use=Use.LITERAL) //opcional interface pública HelloSoap {

@WebMethod String getHelloSoap(String name);

}

  1. Implementação de endpoint de serviço (SEI)

Em seguida, criaremos a implementação do terminal de serviço. Vamos criar uma interface explícita adicionando o elemento endpointInterface à anotação @WebService na classe de implementação. Aqui estão alguns conjuntos de regras 28.1.1 Requisitos de um endpoint JAX-WS que os endpoints JAX-WS devem seguir. O método getHelloSoap retorna uma saudação ao cliente com o nome passado para ele.

<pré> <código> importar javax.jws.WebService;

// Implementação de serviço personalizado (portName,serviceName,targetNamespace são opcionais)

@WebService(portName = “HelloSoapPort”, serviceName = “HelloSoapService”, endpointInterface = “com.wonderland.hellosoap.HelloSoap”, targetNamespace = “http://hello-soap/ws”) public class HelloSoapImpl implementa HelloSoap {

@Override
public String getHelloSoap(String name) {
    return "[JAX-WS] Hello : " + name;
}

}

  1. Editor de endpoint de serviço da Web

<pré> <código> import javax.xml.ws.Endpoint;

classe pública HelloSoapPublisher {

public static void main(String[] args) {
    // creating web service endpoint publisher
    Endpoint.publish("http://localhost:9000/ws/hello-soap", new HelloSoapImpl());
}

}

  1. Nas próximas etapas, executaremos o HelloSoapPublisher.java como aplicativo java. Em seguida, visualizaremos o arquivo WSDL solicitando a URL http://localhost:9000/ws/hello-soap?wsdl em um navegador da web.
 http://localhost:9000/ws/hello-soap?wsdl 

Se o formato de dados XML for exibido no navegador da Web, estamos prontos para a próxima etapa.

hello-soap?wsdl

Observação: Se você receber algum tipo de mensagem de erro, talvez precise usar a ferramenta wsgen para gerar os artefatos portáteis JAX-WS necessários. Nós não são abordados sobre a ferramenta wsgen aqui.

  1. Cliente de serviço da Web

Etapa final, criaremos um cliente que acessa nosso serviço publicado.

<pré> <código> importar java.net.URL;

importar javax.xml.namespace.QName; importar javax.xml.ws.Service;

classe pública HelloSoapClient {

public static void main(String[] args) throws Exception {

    // create wsdl url
    URL wsdlDocumentUrl = new URL("http://localhost:8000/ws/hello-soap?wsdl");
    QName helloSoapService = new QName("http://hello-soap/ws", "HelloSoapService");
    // create web service
    Service service = Service.create(wsdlDocumentUrl, helloSoapService);
    // get object of pointed service port
    HelloSoap helloSoap = service.getPort(HelloSoap.class);
    // testing request
    System.out.println(helloSoap.getHelloSoap("Soap "));

}

}

Resultado: [JAX-WS] Olá: Soap

Observação: o número da porta mudou para 8000 em nosso cliente de serviço da web. A razão aqui é que eu usei o Eclipse IDE, ferramenta interna TCP/IP monitor para rastrear mensagens (Mais informações: [Como rastrear mensagens SOAP no Eclipse IDE](http://www.mkyong.com/webservices/ jax-ws/how-to-trace-soap-message-in-eclipse-ide/)). Para fins de teste funcional, tente SoapUI | Testes funcionais para APIs SOAP e REST.

Java Client for Weather service webservice open source disponível em http://www.webserviceX.NET

  package com.test.ws.example;

 import javax.xml.soap.MessageFactory;
 import javax.xml.soap.MimeHeaders;
 import javax.xml.soap.SOAPBody;
 import javax.xml.soap.SOAPConnection;
 import javax.xml.soap.SOAPConnectionFactory;
 import javax.xml.soap.SOAPElement;
 import javax.xml.soap.SOAPEnvelope;
 import javax.xml.soap.SOAPMessage;
 import javax.xml.soap.SOAPPart;
 import javax.xml.transform.Source;
 import javax.xml.transform.Transformer;
 import javax.xml.transform.TransformerFactory;
 import javax.xml.transform.stream.StreamResult;

 /*
  * WSDL url :  http://www.webservicex.com/globalweather.asmx?WSDL
  * Endpoint URL: http://www.webservicex.com/globalweather.asmx   */

    public class WSClient {

   public static void main(String args[]) {

    try {
        SOAPConnectionFactory soapConnectionFactory = SOAPConnectionFactory.newInstance();
        SOAPConnection soapConnection = soapConnectionFactory.createConnection();

        // Generate SOAP request XML

        MessageFactory messageFactory = MessageFactory.newInstance();
        SOAPMessage soapMessage = messageFactory.createMessage();
        MimeHeaders header = soapMessage.getMimeHeaders();
        header.setHeader("SOAPAction", "http://www.webserviceX.NET/GetCitiesByCountry");
        SOAPPart soapPart = soapMessage.getSOAPPart();
        SOAPEnvelope envelope = soapPart.getEnvelope();
        envelope.addNamespaceDeclaration("web", "http://www.webserviceX.NET");
        SOAPBody soapBody = envelope.getBody();
        SOAPElement soapBodyElem = soapBody.addChildElement("GetCitiesByCountry", "web");
        SOAPElement soapBodyElem1 = soapBodyElem.addChildElement("CountryName", "web");
        soapBodyElem1.addTextNode("INDIA");
        soapMessage.saveChanges();
        soapMessage.writeTo(System.out);
        
                    
        // Call webservice endpint
        String url = "http://www.webservicex.com/globalweather.asmx";
        SOAPMessage soapResponse = soapConnection.call(soapMessage, url);
        Source sourceContent = soapResponse.getSOAPPart().getContent();

        // Print SOAP response
        TransformerFactory transformerFactory = TransformerFactory.newInstance();
        Transformer transformer = transformerFactory.newTransformer();
        System.out.println("Response SOAP Message \n");
        StreamResult result = new StreamResult(System.out);
        transformer.transform(sourceContent, result);
        soapConnection.close();

    } catch (Exception e) {

        e.printStackTrace();
    }
}

}