对于实际的SOAP消息来说，Listing 12和Listing 10没有什么不同。但请求头中有一些不同的地方，例如，现在我们发出的不是POST请求，而是一个M-POST请求。正如前面所介绍的，象M-POST这样的强制请求至少有一个强制扩充声明。这里我们就有一个:Man域描述了一个强制性的端到端扩充声明，把头前缀01映射到了名称空间http://schemas.xmlsoap.org/soap/envelope/。请注意这个前缀关联到SOAPAction域的方式。

　　一旦服务器处理完该请求，它将返回一个应答给客户。应答内容类如(假设没有出现错误):

　　Listing 13

HTTP/1.0 200 OK
Ext:
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi_type="xsd:string">Hello John, How are
you doing?</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

　　同样地，Listing 13显示的应答类似于对普通POST请求的应答(如Listing 11所示)，两者的不同之处在于Ext域。

　　在通过HTTP使用SOAP的过程中，我们欣喜地看到，实际的SOAP消息(SOAP信封和它里面的所有内容)总是保持不变，就如消息尚未加载HTTP协议时一样。根据这一事实可以推断出，HTTP不是能够与SOAP协作的唯一协议。例如，SOAP可以方便地和SMTP协议或者其他定制的私有协议一起运行。唯一的要求是两者——客户端和服务器端——都理解该协议。

　　五、SOAP的特点:简单

　　至此为止，我们讨论了SOAP定义的方方面面，但有许多领域的问题SOAP没有定义。SOAP规范的创立者明确地排除了一些关系密切的领域，比如构造对象模型，还有其他许多已经确立的标准。

　　造成这种现象的原因可以从分析SOAP的目标理解。SOAP的目标除了扩展性之外，另一个主要的设计目标是简单。为了保持SOAP简单，SOAP规范的创立者决定，只定义那些对于创建一个轻型协议来说绝对必须的东西。例如，SOAP没有定义/指定任何有关分布式垃圾收集、类型安全或版本控制、双向HTTP通信、消息盒(Message-box)运输或管道处理、对象激活等方面的内容。SOAP的目标就是成为一种简单的协议——一种在任何操作系统上，单个开发者能够用任何语言化数天时间实现的协议。考虑到这一点，SOAP在许多方面没有作出明确定义实际上是一件好事，因为在构造分布式系统时，所有现有的技术都可以方便地采用SOAP，即使不同技术之间的差异象CORBA和DCOM的差异那样明显。