Qual é a diferença entre estilo de documento e comunicação de estilo RPC?

Alguém pode me explicar as diferenças entre os webservices estilo Document e RPC? Além de JAX-RPC, a próxima versão é JAX-WS, que suporta os estilos Documento e RPC. Também entendo que os serviços da Web em estilo de documento são destinados à comunicação assíncrona, em que um cliente não bloqueia até que a resposta seja recebida.

De qualquer forma, usando JAX-WS eu atualmente anoto o serviço com @Webservice , gere o WSDL e a partir desse WSDL eu gerei os artefatos do lado do cliente.

Depois que os artefatos são recebidos, em ambos os estilos, invoco o método na porta. Agora, isso não difere no estilo RPC e no estilo do documento. Então, qual é a diferença e onde essa diferença é visível?

Da mesma forma, de que maneira o SOAP sobre HTTP difere do XML sobre HTTP? Afinal SOAP também é documento XML com namespace SOAP.

Algum corpo pode me explicar as diferenças entre um estilo de documento e serviços da web de estilo RPC?

Existem dois modelos de estilo de comunicação que são usados ​​para converter uma ligação WSDL em um corpo de mensagem SOAP. São eles: Documento e RPC

A vantagem de usar um modelo de estilo de Documento é que você pode estruturar o corpo SOAP da maneira que desejar, desde que o conteúdo do corpo da mensagem SOAP seja qualquer instância XML arbitrária. O estilo do documento também é conhecido como estilo orientado para mensagens .

No entanto, com um modelo de estilo RPC , a estrutura do corpo da solicitação SOAP deve conter o nome da operação e o conjunto de parâmetros do método. O modelo de estilo RPC assume uma estrutura específica para a instância XML contida no corpo da mensagem.

Além disso, existem dois modelos de uso de codificação que são usados ​​para converter uma ligação WSDL em uma mensagem SOAP. Eles são: literal e codificado

Ao usar um modelo de uso literal , o conteúdo do corpo deve estar em conformidade com uma estrutura de esquema XML definida pelo usuário (XSD) . A vantagem é dupla. Por um lado, você pode validar o corpo da mensagem com o esquema XML definido pelo usuário, além disso, você também pode transformar a mensagem usando uma linguagem de transformação como XSLT.

Com um modelo de uso codificado (SOAP) , a mensagem deve usar tipos de dados XSD, mas a estrutura da mensagem não precisa estar em conformidade com nenhum esquema XML definido pelo usuário. Isso torna difícil validar o corpo da mensagem ou usar transformações baseadas em XSLT no corpo da mensagem.

A combinação dos diferentes estilos e modelos de uso nos fornece quatro maneiras diferentes de converter uma ligação WSDL em uma mensagem SOAP.

Document/literal
Document/encoded
RPC/literal
RPC/encoded

Eu recomendo que você leia este artigo intitulado Qual estilo de WSDL devo usar? por Russell Butek que tem uma boa discussão sobre os diferentes estilos e modelos de uso para traduzir uma vinculação WSDL em uma mensagem SOAP e seus pontos fortes e fracos.

Depois que os artefatos são recebidos, em ambos os estilos de comunicação, invoco o método na porta. Agora, isso não difere no estilo RPC e no estilo do documento. Então, qual é a diferença e onde essa diferença é visível?

O lugar onde você pode encontrar a diferença é na "RESPOSTA"!

Estilo RPC:

package com.sample;

import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style=Style.RPC)
public interface StockPrice { 

    public String getStockPrice(String stockName); 

    public ArrayList getStockPriceList(ArrayList stockNameList); 
}

A mensagem SOAP para a segunda operação terá uma saída vazia e será semelhante a:

Resposta de estilo RPC:

<ns2:getStockPriceListResponse 
       xmlns:ns2="http://sample.com/">
    <return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>

Estilo do documento:

package com.sample;

import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style=Style.DOCUMENT)
public interface StockPrice {

    public String getStockPrice(String stockName);

    public ArrayList getStockPriceList(ArrayList stockNameList);
}

Se executarmos o cliente para o SEI acima, a saída será:

123 [123, 456]

Esta saída mostra que os elementos ArrayList estão sendo trocados entre o serviço da web e o cliente. Essa alteração foi feita apenas pela alteração do atributo de estilo da anotação SOAPBinding. A mensagem SOAP para o segundo método com tipo de dados mais rico é mostrada abaixo para referência:

Resposta ao estilo do documento:

<ns2:getStockPriceListResponse 
       xmlns:ns2="http://sample.com/">
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xsi:type="xs:string">123</return>
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xsi:type="xs:string">456</return>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>

Conclusão

• Como você deve ter notado nas duas mensagens de resposta SOAP, é possível validar a mensagem de resposta SOAP no caso do estilo DOCUMENT, mas não nos serviços da web no estilo RPC.
• A desvantagem básica de usar o estilo RPC é que ele não suporta tipos de dados mais ricos e o estilo de usar Documento é que ele traz alguma complexidade na forma de XSD para definir os tipos de dados mais ricos.
• A escolha de usar um desses depende dos requisitos de operação / método e dos clientes esperados.

Da mesma forma, de que maneira o SOAP sobre HTTP difere do XML sobre HTTP? Afinal SOAP também é documento XML com namespace SOAP. Então, qual é a diferença aqui?

Por que precisamos de um padrão como o SOAP? Ao trocar documentos XML por HTTP, dois programas podem trocar informações ricas e estruturadas sem a introdução de um padrão adicional como SOAP para descrever explicitamente um formato de envelope de mensagem e uma maneira de codificar conteúdo estruturado.

O SOAP fornece um padrão para que os desenvolvedores não tenham que inventar um formato de mensagem XML customizado para cada serviço que desejam disponibilizar. Dada a assinatura do método de serviço a ser chamado, a especificação SOAP prescreve um formato de mensagem XML inequívoco. Qualquer desenvolvedor familiarizado com a especificação SOAP, trabalhando em qualquer linguagem de programação, pode formular uma solicitação XML SOAP correta para um serviço específico e entender a resposta do serviço obtendo os seguintes detalhes do serviço.

• Nome do Serviço
• Nomes de métodos implementados pelo serviço
• Assinatura do método de cada método
• Endereço da implementação do serviço (expresso como um URI)

O uso de SOAP agiliza o processo de exposição de um componente de software existente como um serviço da Web, pois a assinatura do método do serviço identifica a estrutura do documento XML usada para a solicitação e a resposta.

Um serviço da web de estilo RPC usa os nomes do método e seus parâmetros para gerar estruturas XML que representam a pilha de chamadas de um método. O estilo do documento indica que o corpo SOAP contém um documento XML que pode ser validado em relação ao documento de esquema XML predefinido.

Um bom ponto de partida: Vinculação SOAP: Diferença entre documentos e serviços da Web de estilo RPC

Na definição WSDL, as ligações contêm operações, aí vem o estilo de cada operação.

Documento: No arquivo WSDL, ele especifica os detalhes dos tipos com documentos XSD embutidos ou importados, que descreve a estrutura (isto é, o esquema) dos tipos de dados complexos sendo trocados por aqueles métodos de serviço que são fracamente acoplados. O estilo do documento é o padrão.

• Vantagem :
  • Usando este estilo de documento, podemos validar mensagens SOAP em relação ao esquema predefinido. Suporta padrões e tipos de dados xml.
  • fracamente acoplada.
• Desvantagem : é um pouco difícil de entender.

No elemento de tipos WSDL tem a seguinte aparência:

<types>
 <xsd:schema>
  <xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/>
 </xsd:schema>
</types>

O esquema está sendo importado de uma referência externa.

RPC : no arquivo WSDL, ele não cria esquemas de tipos, dentro dos elementos da mensagem ele define os atributos de nome e tipo que o tornam fortemente acoplado.

<types/>  
<message name="getHelloWorldAsString">  
<part name="arg0" type="xsd:string"/>  
</message>  
<message name="getHelloWorldAsStringResponse">  
<part name="return" type="xsd:string"/>  
</message>  

• Vantagem : Fácil de entender.
• Desvantagem :
  • não podemos validar mensagens SOAP.
  • fortemente acoplado

RPC: nenhum tipo no
documento WSDL : a seção de tipos estaria disponível no WSDL

O cenário principal em que JAX-WS RPC e estilo de documento são usados ​​da seguinte maneira:

• O padrão Remote Procedure Call (RPC) é usado quando o consumidor visualiza o serviço da web como um único aplicativo lógico ou componente com dados encapsulados. As mensagens de solicitação e resposta são mapeadas diretamente para os parâmetros de entrada e saída da chamada de procedimento.

  Exemplos desse tipo de padrão RPC podem incluir um serviço de pagamento ou um serviço de cotação de ações.

• O padrão baseado em documento é usado em situações em que o consumidor vê o serviço da web como um processo de negócios de execução mais longa, em que o documento de solicitação representa uma unidade completa de informações. Este tipo de serviço da Web pode envolver interação humana, por exemplo, como um documento de solicitação de aplicativo de crédito com um documento de resposta contendo propostas de instituições de crédito. Como os processos de negócios de execução mais longa podem não ser capazes de retornar o documento solicitado imediatamente, o padrão baseado em documento é mais comumente encontrado em arquiteturas de comunicação assíncrona. A variação Documento / literal de SOAP é usada para implementar o padrão de serviço da web baseado em documento.

Acho que o que você está perguntando é a diferença entre os serviços da Web RPC Literal, Document Literal e Document Wrapped SOAP.

Observe que os serviços da Web do Document são delineados em literais e também agrupados e são diferentes - uma das principais diferenças é que o último é compatível com BP 1.1 e o primeiro não.

Além disso, em Document Literal, a operação a ser chamada não é especificada em termos de seu nome, enquanto em Wrapped, é. Isso, eu acho, é uma diferença significativa em termos de descobrir facilmente o nome da operação para a qual a solicitação se destina.

Em termos de RPC literal versus Document Wrapped, a solicitação de Document Wrapped pode ser facilmente examinada / validada em relação ao esquema no WSDL - uma grande vantagem.

Eu sugeriria o uso de Document Wrapped como o tipo de serviço da Web escolhido devido às suas vantagens.

SOAP em HTTP é o protocolo SOAP vinculado ao HTTP como portadora. O SOAP também pode ser por SMTP ou XXX. SOAP fornece uma forma de interação entre entidades (cliente e servidores, por exemplo) e ambas as entidades podem empacotar argumentos de operação / valores de retorno de acordo com a semântica do protocolo.

Se você estava usando XML sobre HTTP (e pode), entende-se simplesmente como carga útil de XML em solicitação / resposta HTTP. Você precisaria fornecer a estrutura para empacotar / desempacotar, tratamento de erros e assim por diante.

Um tutorial detalhado com exemplos de WSDL e código com ênfase em Java: SOAP e JAX-WS, RPC versus Document Web Services

Documento As
mensagens de estilo de documento podem ser validadas em relação ao esquema predefinido. No estilo de documento, a mensagem SOAP é enviada como um único documento. Exemplo de esquema:

  <types>  
   <xsd:schema> <xsd:import namespace="http://example.com/" 
    schemaLocation="http://localhost:8080/ws/hello?xsd=1"/>  
   </xsd:schema>  
  </types>

Exemplo de mensagem de corpo de sabão de estilo de documento

  <message name="getHelloWorldAsString">   
     <part name="parameters" element="tns:getHelloWorldAsString"/>   
  </message> 
  <message name="getHelloWorldAsStringResponse">  
     <part name="parameters"> element="tns:getHelloWorldAsStringResponse"/>   
  </message>

A mensagem do estilo do documento é fracamente acoplada.

RPC As mensagens de estilo RPC usam o nome do método e parâmetros para gerar a estrutura XML. as mensagens são difíceis de serem validadas em relação ao esquema. No estilo RPC, a mensagem SOAP é enviada como muitos elementos.

  <message name="getHelloWorldAsString">
    <part name="arg0"> type="xsd:string"/>   
   </message> 
  <message name="getHelloWorldAsStringResponse">   
    <part name="return"
   > type="xsd:string"/>   
  </message>

Aqui, cada parâmetro é especificado discretamente, a mensagem de estilo RPC é fortemente acoplada, é normalmente estática, exigindo alterações para o cliente quando a assinatura do método muda. O estilo rpc é limitado a tipos XSD muito simples, como String e Integer, e o WSDL resultante não até tem uma seção de tipos para definir e restringir os parâmetros

Literal por estilo padrão. Os dados são serializados de acordo com um esquema, o tipo de dados não especificado nas mensagens, mas uma referência ao esquema (namespace) é usado para construir mensagens soap.

   <soap:body>
     <myMethod>
        <x>5</x>
        <y>5.0</y>
     </myMethod>
   </soap:body>

Tipo de dados codificado especificado em cada parâmetro

   <soap:body>
     <myMethod>
         <x xsi:type="xsd:int">5</x>
         <y xsi:type="xsd:float">5.0</y>
     </myMethod>
   </soap:body>

Esquema livre