SOAP消息架构

为什么80%的码农都做不了架构师？>>>   

从发送者到接收者，SOAP消息的传输过程是单向的，因此可以说，SOAP的基本消息交换模式（MEP）是单向的。基于SOAP的web服务应用通过不同的方式对单向消息模式进行组合，可以很自由地建立多种会话模式。在基于SOAP的web服务中，请求/响应消息交换模式可以看作是一个简短的会话，在这个会话中，以一个请求发起，以一个响应结束。请求/响应和要求/响应消息交换模式可以通过适当的方式，根据需要组合在一起以适合不同的会话模式。

尽管SOAP消息的目标是最终接收者，但是SOAP消息架构允许有多个SOAP中介，这些中介是沿发送者到最终接收者路径中的非端点接收者或节点。每一个消息中介都可能在把收到的SOAP消息以自身特有的方式发送到最终接收者之前，对这些SOAP消息进行检查甚至进行一些特定操作。看下图，描绘了一个SOAP发送者、两个消息中介和一个最终接收者：

回顾前面，一个SOAP信封必须拥有一个内容可能为空的报体（Body），以及一个可选的报头（Header）。消息中介应该只对SOAP报头做检查和处理，不应该对SOAP报体做任何操作和更改。对比之下，说明SOAP报头只包括一些适合于最终接收者和中介的元数据信息。比如，SOAP报头可能包括一个发送者作为凭证的数字签名信息，或者包括一个消息体内容何时失效的时间戳。在SOAP中包括在可选报头部分的XML元素通常称之为SOAP报头块（SOAP header block）。下面示例显示了一个SOAP消息，其中包括一个标签为”uuid“的报头块：

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Header>
        <uuid xmlns="http://ch03.fib"
            xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
            SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next">
            cal2fd33-16e1-4a95-b17e-3ef6744babdc
        </uuid>
    </S:Header>
    <S:Body>
        <ns2:countRabbits xmlns:ns2="http://ch03.fib">
            <arg0>45</arg0>
        </ns2:countRabbits>
    </S:Body>
</S:Envelope>

标签为uuid的报头块包括一个通用唯一标识符（UUID），一个以十六进制格式化的字符串所表示的拥有128位长度的数字。顾名思义，UUID代表一个可以计数的唯一标识符。这个例子中，假定每一个服务请求都拥有一个属于请求本身的UUID，这个UUID可能被记录下来作为后续分析。

上面这个uuid报头块包括一个“SOAP-ENV:actor”属性，属性值以"next"单词结尾。在这个模式中，下一个参与者其实就是在消息发送者到最终接收者之间的路径上的下一个“接收者”，因此，每一个消息中介（包括最终接收者）都扮演着一个向下一个接收者传递消息的角色。每一个参与者都期望通过应用程序本身合适的方式检查SOAP报头块。如果节点不能处理报头块，那么这个节点应该抛出一个报错。在SOAP1.2中，通过将一个报头块的"mustUnderstand"属性设置为"true"，表示当一个节点不能够处理报头块时必须抛出一个异常。

转载于:https://my.oschina.net/fhd/blog/221338