Ch09 SOAP

• SOA架构：

• 

• SOAP是一种基于xml的消息结构，是stateless的，而且是单向的，不像http有request和response

  • 是有header和body组成的

  • SOAP不是依赖一个传输协议的，不像rest依赖于http或者https

  • example：普通的传输，中间的node都能知道消息的内容，所以必须是可信任的

    

    • 但是soap规定, 中间的node只能知道特定的消息内容而不是整个消息

    • 中间的node也可以加消息内容，比如发送的是邮编，但是收到的可以包括city name等等

  • SOAP的消息结构：

    

    • 通常header是给中间的node看的，而body是给最终收到消息的destination看的

    • 但是有时候中间的node也会改变body的内容，比如加密（intermediate用ultimate receiver的public key加密body，然后在body中告诉ultimate receiver，之后ultimate receiver就可以用自己的private key来解密）

    • destination也有时候会看header，比如消息的结构是怎么组织的

    • soap消息的 schema：header可以没有，但是body至少一个

    • header，body的内容可以来自任何的namespace，有一些通用的attributes

• Processing logic

  • attribute：Role定义了谁可以处理这个header

    • 可以自定义role，也可以使用SOAP中预先定义好的三种role

      • next表示所有的intermediate node可以处理

      • ultimateReceiver表示只有最终的节点可以处理（默认是这个）

    • node可以读取到所有的header来找到哪个header需要它处理

      • 如果‘mustUnderstand’字段是true，那么它must process这个header

      • 如果‘mustUnderstand’字段是false，那么它may process这个header

    • 例子：

  • 在一个node收到消息并且处理时候的逻辑（重要）

    • 1. 先知道自己的role是什么，比如我可以处理login和next
    • 2. 遍历所有的header，找到自己的目标header，也就是和自己的role对应的，并且这些header的‘mustUnderstand’是true
    • 3. 如果有header是这个node不能understand的，那么马上终止消息的传输，不能做下一步的处理
    • 4. 如果没有第三步的情况，那么处理header中的信息，如果是ultimate node，就处理body中的消息
    • 5. node也可以自己选择‘mustUnderstand’是false的header进行处理
    • 6. 在处理完之后，node会删除所有和自己的role所对应的header（默认）不管处理了没有他的信息

      • 也可以在处理完之后再把header加进去，做进一步的修改

      • 但是如果该relay参数是true，并且这个node没有处理他的信息，那么就必须把这个header加回去

    • 7. 如果一个node处理完之后message还需要进一步的处理，那么发送给下一个node

  • 例子：

• Document style message change：只是发送文件，接收者要自己寻找what to do

  

  

  • request和response可以用reference来标记匹配，比如response中包含了request的uuid

  • 例子：请求

  • 例子：回复

• RPC style message change

  

  • 在payload中写清楚了要接受者做哪些操作，因为包含了method name

  • ！并不是实现了RPC调用，只是一种消息交换的方式（clearly specifies what to do）

  • 例子：请求

  • 例子：回复

• SOAP binding

  • SOAP信息是基于xml的

  • protocol binding：描述了信息如何在下层的协议中传输(在传递的过程中可能会变)，其中规定了

    • 序列化规则

    • 消息传递模式（RPC，message...）

      • Message exchange pattern：制定一个文件，大家都根据这个文件来处理信息

      • 例子：

  • SOAP的三种用法：

• 通过http来传输soap message：

  

  • 例子：

  • SOAP也可以扩展

• XOP：xml传输二进制文件

  • 比如图片：因为在传输的时候可能会有xml关键字，导致解析器解析错误，所以可以用Base64来编码

  • Base64

    

    • 有overhead，因为ASCII码是8位标识一个字符

  • Reliable messaging：

    

    • model

      

      • Fundamental Processing Model：每个消息都有一个uuid，接受消息一方必须在收到消息后发送ack，否则发送方会再次发送，并且规定最大发送次数

      • Persistence Model：发送方会把消息存储到磁盘上，直到

        • 1. 最终的接收人收到了消息
        • 2. 消息的存活时间到了
        • 3. 重传次数达到上限

      • Order model：每个message有一个编号，且以+1递增，当receiver收到消息后，会给sender发送ack，如果sender没有收到ack，则重传。Receiver会把控发送消息给app的顺序

    • message structure:

• Addressing: 标记一个service

  • endpoint：一个service所在的具体位置，message发送的target

  • endpoint reference：如何找到合适的endpoint

    • 包含哪些元素：

    • W3C合并了一些元素，叫做metadata

    • 例子1：规定了服务的地址和接口的名称

    • 例子2：规定了服务的地址和一些属性来标识唯一的资源

    • 例子3：address和servicename标识唯一一个service之后（Properties标识了唯一一个资源），还可以加上Parameters对它进一步说明

• 重要！！！Endpoint References

  

  • address是用来识别一个container的，它可能有很多service

  • 端口和端口类型是用来唯一识别一个service，port-->binding-->port type

  • policies是用来表示在处理信息的时候的规则，比如要以事务来处理

  • Reference properties和parms是传到service里的参数，用来找到特定的资源