<?xml version='1.0' ?>
            <env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
            <env:Header>
            </env:Header>
            <env:Body>
            </env:Body>
            </env:Envelope>
            

在本例中，获得了一个简单的 Envelope，其命名空间指定为 SOAP 1.2 版本。其中包含两个子元素 Header 和 Body。让我们了解一下这两个子元素所起的作用。

SOAP 消息中的 Header 用于提供有关消息本身的信息，与用于应用程序的信息相对。例如，Header 可以包括路由信息。

 Header 中的路由信息

<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope"> <env:Header> <wsa:ReplyTo xmlns:wsa= "http://schemas.xmlSOAP.org/ws/2004/08/addressing"> <wsa:Address> http://schemas.xmlSOAP.org/ws/2004/08/addressing/role/anonymous </wsa:Address> </wsa:ReplyTo> <wsa:From> <wsa:Address> http://localhost:8080/axis2/services/MyService</wsa:Address> </wsa:From> <wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID> </env:Header> <env:Body> </env:Body> </env:Envelope>

本例中有一个 WS-Addressing 元素，其中包含有关消息将送达何处以及应将应答送达何处的信息。Header 可包含关于消息本身的所有类型的消息。事实上，SOAP 规范中使用了大量篇幅说明哪些元素可以放入 Header以及应由“SOAP 中间层”如何对其进行处理。也就是说，SOAP 规范并不假定消息将直接从一个点传递到另一个点（从客户机到服务器）。规范考虑了 SOAP 消息在送达最终目的地的过程中可能实际由多个中间层处理的情况，很清楚地说明了中间层应如何对待在 Header 中找到的信息。不过，对此的讨论不在本教程的范围之内。因此，目前只要知道 Header 可以提供许许多多的功能（如果您需要）即可。

发送 SOAP 消息时，都是有目的性的。您在尝试告诉接收者执行某种操作，或尝试向服务器传递相关信息。此信息称为“有效负载”。有效负载位于 Envelope 的 Body 中。它还具有自己的命名空间，在本例中其命名空间与内容管理系统对应。在此情况下，可以完全随意地选择命名空间。只需要与 SOAP 命名空间相异即可。

有效负载示例

<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope"> <env:Header> ... </env:Header> <env:Body> <cms:addArticle xmlns:cms="http://www.daily-moon.com/cms"> <cms:category>classifieds</category> <cms:subcategory>forsale</cms:subcategory> <cms:articleHeadline></cms:articleHeadline> <cms:articleText>Vintage 1963 T-Bird. Less than 300 miles. Driven by my daughter until I took it away. Serious inquires only. 555-3264 after 7 PM.</cms:articleText> </cms:addArticle> </env:Body> </env:Envelope>

Web 服务规范通常归为两类：基本 Web 服务规范和扩展 Web 服务规范。

基本 Web 服务规范

• SOAP：SOAP 规范是所有基于 SOAP 的 Web 服务的基础，详细说明了实际消息的格式。其中还详细说明了应用程序应如何对待消息的特定方面（如“Header”中的元素），从而可以创建特定类型的应用程序，使其中的消息在达到最终的目的地前在多个中间层之间进行传递。
• WDSL：Web 服务描述语言是详细说明描述基于 SOAP 的 Web 服务的标准方式的规范，包括消息应采用的形式以及应将其发送到何处。其中还详细说明了此类消息的响应。当与相应的工具结合使用时，WSDL 允许以编程方式创建对 Web 服务的调用，甚至不用知道所查找的 Web 服务是什么；应用程序可以从 WSDL 文件中提取这些详细信息，并提供要使用的编程接口。
• UDDI：统一描述、发现和集成 (Universal Description, Discovery and Integration) 是一项从最初提出后发生了一系列变化的标准。其最初的目的是为了给各个公司提供在全球注册中心中注册服务并在此注册中心中搜索可能想使用的服务的机制。不过，由于很多公司对于将其系统对外开放的问题上都相当保守，这个目标并没有完全实现。但是，很多公司已将 UDDI 作为内部的服务及服务信息注册中心使用。

扩展 Web 服务规范

总共有数十种 WS-* 规范，其中几种对企业尤为有用。即：

• WS-Security：此规范处理加密和数字签名，允许创建特定类型的应用程序，以防止窃听消息，且能实现不可否认功能。
• WS-Policy：此规范对 WS-Security 进行了扩展，允许更具体地说明谁可以采用何种方式使用服务。
• WS-I：尽管 Web 服务应设计成具有互操作性，但在实际中，各个规范对不同实现的解释的灵活性常常足以导致出现问题。WS-I 提供了一组可用于防止出现各种问题的标准和实践，并提供了标准化测试来检查问题。
• WS-BPEL：单个服务很好处理，但应用程序在大多数情况下则较难处理。企业级计算要求至少将多个服务组合为一个完整的系统，而 WS-BPEL 提供了用于指定创建此类系统所必需的交互（如分支和并发处理）。

在 Web 服务中扮演重要角色的其他规范还包括 WS-ReliableMessaging（允许确定检索一个且仅一个消息副本）、Web 服务资源框架 (WSRF)（允许使用在无状态环境中非常重要的状态）和 Web 服务分布式管理 (WSDM)（讨论 Web 服务的管理和使用问题）。