下面就是这一个跨越多个Service的调用的SOAP消息示例：
POST /AccountAuthen
tication HTTP/1.1
Host: port.CA.com.cn
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<uniB2B:RequestAuthen
tication xmlns:uniB2B=”Some-URI”>
<AccountName>DealEasy</AccountName>
<AccountPassword>12345</AccountPassword>
</uniB2B:RequestAuthen
tication>
<uniB2B:RequestProductInfo xmlns:uniB2B=”Some-URI”
targetEMarketplace=”http://service.eMarketplace.com.cn/ProductQuote”>
<ProductID>Jaguar_X_Type</ProductID >
<FinalUsage function="RequestPurchaseOrder" />
</uniB2B:RequestProductInfo>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<uniB2B:RequestPurchaseOrder xmlns:uniB2B ="Some-URI">
<ProductID>Jaguar_X_Type</ProductID >
</uniB2B:RequestPurchaseOrder >
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
我们来看看这个SOAP到底有一些什么内容。
开头部分：
POST /AccountAuthen
tication HTTP/1.1
Host: port.CA.com.cn
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
是基本的HTTP发送协议，其实这不是必须的，只是当你选用HTTP作为你的SOAP载体时才需要的。这里我们跳过不说，
如果想知道具体的HTTP协议内容，可以参考相关资料。
接下来一大块就是我们所关心的SOAP消息内容了。我们看到，这个消息是由<SOAP-ENV:Envelope .......> 和
</SOAP-ENV:Envelope> 两个标志符括起来的。其中：
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
这里指定了两个命名空间。所有的SOAP消息都是使用XML格式来编码的。SOAP应用程序在生成由SOAP定义的所有
元素和属性的时候，应该包含恰当的SOAP的命名空间。SOAP应用程序必须能处理其收到的消息中的SOAP命名空
间。它必须丢弃那些包含不正确命名空间的消息，并且可以处理那些不包含SOAP命名空间的SOAP消息，就好象
他们包含了正确的命名空间一样。关于什么叫做命名空间以及相关的Schema、XML语法，可以查看XML相关资料。
接下来我们看到两部分：Header和Body。一个SOAP必须包含Body,而Header是可选的。Body是最终接收者所想
要得到消息部分。而Header是用于“附加”处理的消息部分。在本例里，最终接收者想知道ProductID的资料，而
想知道这些资料，则必须经过：Authen
tication服务的AccountName和AccountPassword，也就是：
<uniB2B:RequestAuthen
tication xmlns:uniB2B=”Some-URI”>
<AccountName>DealEasy</AccountName>
<AccountPassword>12345</AccountPassword>
</uniB2B:RequestAuthen
tication>
这一部分。然后再经过ProductInfo服务，获得ProductID和FinalUsage相关资料。也就是：
<uniB2B:RequestProductInfo xmlns:uniB2B=”Some-URI”
targetEMarketplace=”http://service.eMarketplace.com.cn/ProductQuote”>
<ProductID>Jaguar_X_Type</ProductID >
<FinalUsage function="RequestPurchaseOrder" />
</uniB2B:RequestProductInfo>
这一部分。这样，一个SOAP消息在到达最终目的地时，会先经过两个不同的服务，取得相关的信息资料后，在
到达最后目的地。这就是最后部分Body的内容了：
<SOAP-ENV:Body>
<uniB2B:RequestPurchaseOrder xmlns:uniB2B ="Some-URI">
<ProductID>Jaguar_X_Type</ProductID >
</uniB2B:RequestPurchaseOrder >
</SOAP-ENV:Body>
注意到uniB2B这个东西了吗？这个标志没有特殊的意义，在XML里，元素标志是由人任意定制的，事实上，完全可以
把uniB2B这个标志换成我们喜欢的东西如：mydog 等等。
到此，我们对一个SOAP消息有了个感性地认识，总结一下：
1 一个SOAP消息由下面成员组成：
* Envelope --- 用来表示该消息的XML元素
* Header --- 用来处理为消息增加附加特定内容的部分
* Body --- 用来交给最终用户处理的部分
2 是否必须出现：
* Envelope --- 是，可以有下级元素，需要命名空间修饰
* Header --- 否，可以有下级元素
* Body --- 是，可以有下级元素
3 SOAP可以使用各种现成协议作为载体，象本例使用了HTTP协议作为载体。而程序员完全可以通过SOCKET，自己
定义一套发送、接收SOAP的处理机制。
因此，我们完全可以认为，SOAP就是一套定义了特定格式的XML数据。就象SOCKET一样，当一个SOCKET有了某种
特定的格式之后，也就成为了某种协议，如HTTP、FTP等等。但是SOAP又有些不同，因为SOAP是基于XML的，因此在
定义时，又会有很大的灵活性，这也要求定义SOAP具体格式时，收发双方要有一个互通的定义。例如上面说的
uniB2B，如果事先不定义好有这个标识符，可能对方就难以解析这个SOAP消息。
以下是回应SOAP消息的答复：
HTTP/1.1 200 OK
Content-Type: text/xml;
charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<uniB2B:ResponsePurchaseOrder xmlns:uniB2B ="Some-URI">
<OrderID>AJR786503</OrderID>
<Authen
ticatedID>76E4#12A@-98JA#V5GQ</Authen
ticatedID>
<ProductID>Jaguar_X_Type</ProductID >
<ProductPrice>243900.00</ProductPrice>
<ProductNumber>1</ProductNumber>
<IssueDate>2001-4-1</IssueDate>
</uniB2B:ResponsePurchaseOrder >
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
在DELPHI6推出后，很多朋友纷纷都开始学用DELPHI的各种控件来学习SOAP。其实个人认为还是应该先了解一下
SOAP的协议比较好。否则，很可能成为一个能“写”SOAP程序的，却不知道SOAP协议是什么的人。这种例子已经
很多了，在RAD发达的今天，很多人顺手拿个HTTP的控件就开始写HTTP程序了，但却压根不知道HTTP协议是啥样子
的。
试试看，不依靠DELPHI6的那组控件，我们要写个SOAP的程序，该怎么下手。以下是我的一点体会：
SOAP就是一个传送数据的协议，所以可以与各种应用无关。SOAP并非就一定要用在WEBSERVICE上面，也并非
就必须用HTTP协议来传送。而不管用什么协议接收到SOAP消息后，都可以使用DOM的API进行XML数据解析。我们
再回过头来看看刚才的例子，假设这样一个场景： 有4台机器，一个客户端，3台服务器。互相之间使用SOCKET
作为通信手段：
客户机 -----------> 权限验证服务器 ------> 产品信息服务器 -------> 数据处理服务器
客户端仍然是发送刚才那个SOAP消息，权限验证服务器接到消息后，查看：
<uniB2B:RequestAuthen
tication xmlns:uniB2B=”Some-URI”>
<AccountName>DealEasy</AccountName>
<AccountPassword>12345</AccountPassword>
</uniB2B:RequestAuthen
tication>
然后调用DOM的API，指向<AccountName>和<AccountPassword>节点，分别获得相关数据。通过验证后，把消息
再转发给产品信息服务器。产品信息服务器收到消息后，再查看：
<uniB2B:RequestProductInfo xmlns:uniB2B=”Some-URI”
targetEMarketplace=”http://service.eMarketplace.com.cn/ProductQuote”>
<ProductID>Jaguar_X_Type</ProductID >
<FinalUsage function="RequestPurchaseOrder" />
</uniB2B:RequestProductInfo>
再调用DOM，获得<ProductID>和<FinalUsage ...>的信息，再次转发给数据处理服务器。数据处理服务器读取
Body部分，将<ProductID>信息读取，进行运算，得到结果，然后把SOCKET发回给客户机。客户机根据DOM，把
相关的各部分：<OrderID>、<Authen
ticatedID>、<ProductID>、<ProductPrice>等读取出来，然后显示给客户。
好了，一次简单的SOAP之旅就完成了。：）
当然，在实际运用中，可能会碰到复杂得多的情况。可是不管怎么样，知道基本的原理，也就有了破解困难的
最终钥匙。所以：
SOAP is so easy! ^_^
