SOAP e Web Services
Web Services são identificados por uma URI(Unique Resource Identifier), e são descritos e definidos usando XML. Um dos motivos que tornam Web Services atrativos é o fato deste modelo ser baseado em tecnologias standards, em particular XML e HTTP. Web Services são usados para disponibilizar serviços interativos na WEB, podendo ser acessados por outras aplicações. SOAP (Simple Object Access Protocol) está se tornando padrão para a troca de mensagens entre aplicações e Web Services, já que é uma tecnologia construída com base em XML e HTTP.
SOAP é um procolo projetado para invocar aplicações remotas através de RPC (Remote Procedure Calls - Chamadas Remotas de Procedimento) ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação. SOAP é, portanto, um padrão normalmente aceito para utilizar-se com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões.
Características de SOAP
* Definido pelo consórcio W3C. Veja maiores detalhes da versão atual SOAP 1.1.
* Protocolo baseado em XML para a troca de informações em um ambiente distribuído;
* Padrão de utilização com Web Services;
* Normalmente utiliza HTTP como protocolo de transporte;
* Uma mensagem SOAP (veja fig.1) consiste basicamente dos seguintes elementos:
o Envelope: Toda mensagem SOAP deve contê-lo. É o elemento raiz do documento XML.
O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação (encoding style).
Um "encoding style" define como os dados são representados no documento XML.
o Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário (É importante lembrar que, ao trafegar pela rede, a mensagem normalmente passa por diversos pontos intermediários, até alcançar o destino final). Quando utilizado, o Header deve ser o primeiro elemento do Envelope.
o Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem.
fonte:http://devedge-temp.mozilla.org/viewsource/2002/soap-overview/index_pt_br.html
http://www.w3.org/TR/soap12-part1/#targettingblocks
2.4 Understanding SOAP Header Blocks
It is likely that specifications for a wide variety of header functions (i.e., SOAP modules) will be developed over time (see 3.3 SOAP Modules), and that some SOAP nodes might include the software necessary to implement one or more such extensions. A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics specified for the XML expanded name of the outer-most element information item of that header block.
A SOAP header block MAY carry a mustUnderstand attribute information item (see 5.2.3 SOAP mustUnderstand Attribute). When the value of such an attribute information item is "true", the SOAP header block is said to be mandatory.
Mandatory SOAP header blocks are presumed to somehow modify the semantics of other SOAP header blocks or SOAP body elements. Therefore, for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault). Tagging SOAP header blocks as mandatory thus assures that such modifications will not be silently (and, presumably, erroneously) ignored by a SOAP node to which the header block is targeted.
The mustUnderstand attribute information item is not intended as a mechanism for detecting errors in routing, misidentification of nodes, failure of a node to serve in its intended role(s), etc. Any of these conditions can result in a failure to even attempt processing of a given SOAP header block from a SOAP envelope. This specification therefore does not require any fault to be generated based on the presence or value of the mustUnderstand attribute information item on a SOAP header block not targeted at the current processing node. In particular, it is not an error for an ultimate SOAP receiver to receive a message containing a mandatory SOAP header block that is targeted at a role other than the ones assumed by the ultimate SOAP receiver. This is the case, for example, when a SOAP header block has survived erroneously due to a routing or targeting error at a preceding intermediary.