下载文档原格式
SOAP消息解析及调试技巧SOAP（Simple Object Access Protocol）是一种基于XML的协议，用于在网络上进行分布式计算和交互。
它通过定义消息的格式和传输规范，实现了不同应用和平台之间的通信。
在开发和调试过程中，理解SOAP消息的结构和解析技巧是非常重要的。
本文将介绍SOAP消息的解析原理，并提供一些调试技巧，帮助开发者更好地处理SOAP 消息。
一、SOAP消息的结构SOAP消息通常由以下几个部分组成：1. Envelope（信封）：SOAP消息的根元素，包含了所有SOAP消息的内容。
它定义了命名空间和编码方式。
2. Header（头）：可选的部分，用于传递与消息相关的元数据和处理指令。
例如，可以通过头部添加认证信息、事务处理或其他自定义功能。
3. Body（身体）：包含具体的消息内容，用于传递请求或响应的数据。
应用程序通常关注的是这个部分。
4. Fault（故障）：可选的部分，用于表示消息处理过程中的错误或异常情况。
当请求或响应发生错误时，Fault部分可以提供详细的错误信息。
二、解析SOAP消息解析SOAP消息有多种方式，包括使用第三方库、手动解析XML 等。
下面以使用Java的SAAJ（SOAP with Attachments API for Java）库为例，介绍一种常用的解析SOAP消息的方法。
1. 导入SAAJ库：在Java项目中，需要导入SAAJ库才能使用其提供的API。
可以在项目的构建工具（如Maven或Gradle）中添加SAAJ 的依赖项，或手动导入相关的JAR包。
2. 创建SOAP消息对象：使用SAAJ提供的API，我们可以轻松地创建表示SOAP消息的对象。
```javaMessageFactory factory = MessageFactory.newInstance();SOAPMessage message = factory.createMessage();```3. 解析SOAP消息：通过解析得到的SOAP消息对象，我们可以提取出消息的各个部分。
DOI:10.13954/ ki.hd u.2002.03.005杭州电子工业学院学报 第22卷第3期JOURNAL OF H ANGZH OU I NST ITUT E OF Vol.22,No.3 2002年6月EL ECT RONIC ENGINEERING June.2002 SOAP的原理及实现邓 昱,曾文华(杭州电子工业学院计算机分院,浙江杭州310037)摘要:简单对象访问协议(Simple Object Access Protocol-SOAP)是一个基于扩展标记语言的在分散或分布式环境中实现信息交换的简单协议。
其主要目的是促进不同技术之间的可互用性,真正克服平台和防火墙的限制,使通信各方在互联网上实现畅通无阻的信息交流。
介绍了S OAP产生的技术背景及扩展标记语言、网络服务和网络服务描述语言等相关技术,并通过具体实例说明SOAP消息和SOAP封装等协议规范。
最后描述了SOAP协议在Windows环境下实现的体系结构及客户端和服务器端的实现过程。
关键词:简单对象访问协议;扩展标记语言;网络服务;协议规范中图分类号:TP311 文献标识码:A 文章编号:1001-9146(2002)03-0019-051 背景和相关技术简单对象访问协议(SOAP)定义了用XML和HTTP访问服务、对象和服务器的方法,是一个将不同类型的软件组件连接起来的协议。
其主要目的是促进不同技术之间的可互用性,真正克服平台和防火墙的限制,使通信各方在互联网上实现畅通无阻的信息交流。
随着计算机硬件的发展,尤其是互联网的出现,软件需要完成的工作越来越复杂,其规模也日益扩大,开发人员之间协同合作的必要性已不言而喻。
组件概念的提出与应用,虽然可使完成专门任务的软件块被无限重用,但缺乏统一的组件技术标准则不能保证其兼容性和互换性。
目前已存在的生成软件组件的标准及相应技术有组件对象模型、公共对象请求代理体系结构和远程数据服务等,它们以分布式网络结构为基础,不同组件可通过网络相互调用来构建各自的软件。
SOAP协议规范1. 简介SOAP以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。
SOAP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。
这使SOAP能够被用于从消息传递到RPC的各种系统。
SOAP包括三个部分∙SOAP封装（见第4节）结构定义了一个整体框架用来表示消息中包含什么内容，谁来处理这些内容以及这些内容是可选的或是必需的。
∙SOAP编码规则（见第5节）定义了用以交换应用程序定义的数据类型的实例的一系列机制。
∙SOAP RPC表示（见第7节）定义了一个用来表示远程过程调用和应答的协定。
虽然这三个部分都作为SOAP的一部分一起描述，但它们在功能上是相交的。
特别的，封装和编码规则是在不同的名域中定义的，这种模块性的定义方法增加了简单性在SOAP封装，SOAP编码规则和SOAPRPC协定之外，这个规范还定义了两个协议的绑定，描述了在有或没有HTTP扩展框架[6]的情况下，SOAP消息如何包含在HTTP消息[5]中被传送。
1.1 设计目标SOAP的主要设计目标是简单性和可扩展性，这意味着传统的消息系统和分布对象系统的某些性质不是SOAP规范的一部分。
这些性质包括：∙分布式碎片收集∙成批传送消息∙对象引用（要求分布式碎片收集）∙激活机制（要求对象引用）1.2 符号约定这篇文章中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和"OPTIONAL"的解释在RFC-2119 [2]中。
soap 格式
SOAP（Simple Object Access Protocol）是一种通信协议，基于XML （eXtensible Markup Language）格式，被广泛应用于Web服务的开发中。
它允许应用程序通过HTTP协议在互联网上交换结构化信息。
SOAP协议定义了一种规范，使得应用程序可以通过XML格式的消息进行通信，这些消息可以在不同的传输协议和不同的消息传递机制上传输。
SOAP消息通常由三部分组成：信封（Envelope）、头部（Header）和负载（Body）。
信封是SOAP消息的根元素，包含了消息的所有信息，头部包含了与消息传递相关的信息，如安全性、路由等，负载则包含了实际的应用程序数据。
SOAP协议具有简单性、可扩展性、安全性和可靠性等特点，使得它成为Web服务开发中的重要协议之一。
规范化书写SOAP一．主诉：1.以症状为主，不要出现疾病的名称（如无法用症状描述的可写疾病名称）：如糖尿病、高血压字眼，可写成“发现血压高2年，血糖高4年，冠脉支架术后3年等”，或写症状，如“间断头晕3年，间断胸闷3年，多尿2年”等。
2.主诉多于一项，患有多种慢性病，需进行管理则按发生的先后次序列出，并记录每个症状的持续时间，主诉应简明精炼，每一项不多于20字。
3.格式为：按照时间顺序写成问题一，问题二等，如问题一：间断头晕3年，加重2天问题二：冠脉支架术后2年；说明：目前可将需管理的高血压、糖尿病、冠心病、脑梗塞四种慢性病均写在主诉中，如患有其他慢性病如骨关节病、高脂血症、COPD等虽也需管理，可在既往史中详细描述。
二．现病史：1.就以上的问题详细记录患者①发病时的症状、伴随情况及与鉴别诊断相关的阳性或阴性症状、②诊疗过程（包括诊断疾病的医院，治疗用药、效果、副作用）、③目前疾病控制情况的问题，并发症情况，格式为一个问题一段写，每一段开头错两个字，如：患者3年前出现头痛、头晕，在当地测量血压发现………….患者2年前突然出现剧烈心前区痛疼，在XXX医院就诊，心电图………….2.药品名称要加“”，如“倍他乐克 25mg Bid”,不能用缩写，如ASP。
3.单位及服药次数统一，即写英文全为英文，中文全为中文，如mg 或毫克，Bid 或2次/日.4.患者的检查最好标明日期,如1年前查XXX或2008年查XXXX，若不知日期可写为曾经查过XXXX，近半年或1年未再复查三．生活习惯：与健康问题相关的生活习惯。
如饮食、运动、生活习惯、烟酒嗜好、心理平衡、遵医嘱性等。
如：1. 饮食情况：主食多少，食油多少，但不要写总热量达标，这应该是大夫评估的结果。
2. 运动情况：运动强度包括运动持续时间、运动方式、运动量评估（心率或自我感觉）3. 工作环境、社会环境、家庭环境等四．查体：1. 不能单写正常，无特殊等，要具体写内容，如咽无充血等。
SOAP的四个部分：1协议结构SOAP 消息格式：SOAP 标头：<SOAP-ENV: Envelope Attributes><SOAP-ENV:Body Attributes></SOAP-ENV:Body></SOAP-ENV:Envelope>这种结构目前主要在web服务中运用。
2、语法规则SOAP 消息必须用 XML 来编码SOAP 消息必须使用 SOAP Envelope 命名空间SOAP 消息不能包含 DTD 引用SOAP 消息不能包含 XML 处理指令3、SOAP的核心技术解释SOAP采用了已经广泛使用的两个协议:HTTP 和XML。
HTTP用于实现 SOAP 的RPC 风格的传输, 而XML 是它的编码模式。
采用几行代码和一个XML 解析器, HTTP 服务器( MS 的 IIS 或 Apache) 立刻成为SOAP 的 ORBS。
SOAP 通讯协议使用 HTTP 来发送XML 格式的信息。
HTTP与RPC 的协议很相似,它简单、配置广泛,并且对防火墙比其它协议更容易发挥作用。
HTTP 请求一般由 Web 服务器软件(如 IIS 和Apache)来处理, 但越来越多的应用服务器产品正在支持HTTP。
XML 作为一个更好的网络数据表达方式( NDR)。
SOAP 把 XML 的使用代码化为请求和响应参数编码模式, 并用HTTP 作传输。
具体地讲, 一个SOAP 方法可以简单地看作遵循SOAP编码规则的HTTP请求和响应, 一个 SOAP 终端则可以看作一个基于HTTP 的URL, 它用来识别方法调用的目标。
像CORBA/ IIOP一样, SOAP 不需要具体的对象绑定到一个给定的终端, 而是由具体实现程序来决定怎样把对象终端标识符映像到服务器端的对象。
4、消息格式SOAP在标准化消息格式环境中，可以做所有它能完成的工作。
消息的主体部分是“text/xml”形式的MIME类型，并且包含一个SOAP封套。
SOAP康复治疗记录介绍及书写规范SOAP(Subjective,Objective,Assessment,Plan)评估记录法是目前国际上最常用以问题为导向的医学记录方法，主要用于培养康复治疗专业学生的临床思维能力、提高学生分析、判断和解决临床康复问题的能力，同时SOAP评估记录法的理念在康复组织工程中也能发挥重要的作用。
作为一种治疗记录格式，在美国等西方国家的临床治疗中，是每一位执业治疗师或助理治疗师必备的基本技能。
也就是说这不但是应用于康复治疗学生的教育，也应用于临床评估。
SOAP包含4个方面：主观资料(Subjective，S)，客观资料(Objective，O)，评估(Assessment，A)和计划(Plan，P) (一）主观资料：“S”主要是患者提供的资料，包括患者主诉，一般情况(例如年龄、职业等)、疾病发生发展情况、当前症状、个人病史、家族病史等。
主观资料的获得主要通过临床问诊，临床问诊实质是资料的搜集、思考、质疑并整合患者提供的相关信息以得出康复评估和治疗方案的临床推理过程。
临床推理不仅仅是康复治疗学科需要理解的概念，更是需要康复医师和治疗师学习的临床技能。
康复医务人员在评估时，需明确以下问题：患者的年龄、性别、从事的职业、什么部位出现症状、如何损伤的、症状程度及持续时间、哪些姿势或动作会加重或减轻症状、是否影响生活自理能力、是否影响到睡眠等。
举例一：患者的年龄。
许多疾病是与年龄呈相关性的。
例如，不同年龄导致腰痛疾病的种类不同：①小儿和青少年导致腰痛常见疾病为先天性畸形、脊柱侧弯等。
②中青年导致腰痛常见疾病为腰肌劳损、腰扭伤、腰椎间盘突出症等。
③老年导致腰痛常见疾病为腰椎骨性关节炎、腰椎管狭窄、骨质疏松等。
举例二：患者的职业。
不同职业导致疾病的种类不同。
例如，不同职业与膝关节疼痛：①跑步运动员导致膝关节疼痛常见疾病为“跑步膝”(即髌骨软骨损伤)。
②篮球运动员导致膝关节疼痛常见疾病为“篮球膝”(即髌腱末端病)。
SOAP协议规范1. 简介SOAP以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。
SO AP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。
这使SOAP能够被用于从消息传递到RPC的各种系统。
soap包括三个部分soap封装（见第4节）结构定义了一个整体框架用来表示消息中包含什么内容，谁来处理这些内容以及这些内容是可选的或是必需的。
SOAP编码规则（见第5节）定义了用以交换应用程序定义的数据类型的实例的一系列机制。
SOAP RPC表示（见第7节）定义了一个用来表示远程过程调用和应答的协定。
虽然这三个部分都作为SOAP的一部分一起描述，但它们在功能上是相交的。
特别的，封装和编码规则是在不同的名域中定义的，这种模块性的定义方法增加了简单性在SOAP封装，SOAP编码规则和SOAPRP C协定之外，这个规范还定义了两个协议的绑定，描述了在有或没有HTTP扩展框架[6]的情况下，SOAP 消息如何包含在HTTP消息[5]中被传送。
1.1 设计目标SOAP的主要设计目标是简单性和可扩展性，这意味着传统的消息系统和分布对象系统的某些性质不是SO AP规范的一部分。
这些性质包括：分布式碎片收集成批传送消息对象引用（要求分布式碎片收集）激活机制（要求对象引用）1.2 符号约定这篇文章中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "S HOULD NOT", "RECOMMENDED", "MAY", 和"OPTIONAL"的解释在RFC-2119 [2]中。
这篇文章中用到的名域前缀 "SOAP-ENV" 和"SOAP-ENC"分别与"/soap/envelope/"; 和"http://sc /soap/encoding/";关联。
整篇文档中，名域前缀“xsi”被假定为与URI"/1999/XMLSchema-instance“（在XMLSchema规范[11]定义）相连。
类似的，名域前缀”xsd“被假定为与URI" /1999/XMLSchema";（在[10]中定义）相连。
名域前缀”tns“用来表示任意名域。
所有其它的名域前缀都只是例子。
名域URI的基本形式”some－URI“表示某些依赖于应用程序或上下文的URI[4]。
这个规范用扩展BNF（在RFC－2616[5] 描述）描述某些结构。
1.3 soap消息举例在这个例子中，GetLastTradePrice SOAP 请求被发往StockQuote服务。
这个请求携带一个字符串参数和ti cker符号，在SOAP应答中返回一个浮点数。
XML名域用来区分SOAP标志符和应用程序特定的标志符。
这个例子说明了在第6节中定义的HTTP绑定。
如果SOAP中管理XML负载的规则完全独立于HTTP是没有意义的，因为事实上该负载是由HTTP携带的。
在Appendix A中有更多的例子。
例1 在http请求中嵌入soap消息post /stockquote http/1.1Host:Content-Type: text/xml;charset="utf-8"Content-Length: nnnnSOAPAction:"Some-URI"<SOAP-ENV:Envelopexmlns:SOAP-ENV="/soap/envelope/";SOAP-ENV:encodingstyle="/soap/encoding/";><SOAP-ENV:Body><m:GetLastTradePrice xmlns:m="Some-URI"><symbol>DIS</symbol></m:GetLastTradePrice></SOAP-ENV:Body></SOAP-ENV:Envelope>下面是一条应答消息，包括http消息，soap消息是其具体内容： 例2 在http应答中嵌入soap消息http/1.1 200 okContent-Type: text/xml;charset="utf-8"Content-Length:nnnn<SOAP-ENV:Envelopexmlns:SOAP-ENV="/soap/envelope/";SOAP-ENV:encodingstyle="/soap/encoding/";/><SOAP-ENV:Body><m:GetLastTradePriceResponse xmlns:m="Some-URI"><Price>34.5</Price></m:GetLastTradePriceResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>2. soap消息交换模型SOAP消息从发送方到接收方是单向传送，但正如上面显示的，SOAP消息经常以请求/应答的方式实现。
S OAP实现可以通过开发特定网络系统的特性来优化。
例如，HTTP绑定（见第6节）使SOAP应答消息以HTTP应答的方式传输，并使用同一个连接返回请求。
不管SOAP被绑定到哪个协议，SOAP消息采用所谓的”消息路径“发送，这使在终节点之外的中间节点可以处理消息。
一个接收SOAP消息的SOAP应用程序必须按顺序执行以下的动作来处理消息：识别应用程序想要的SOAP消息的所有部分（见4.2.2节）检验应用程序是否支持第一步中识别的消息中所有必需部分并处理它。
如果不支持，则丢弃消息（见4.4节）。
在不影响处理结果的情况下，处理器可能忽略第一步中识别出的可选部分。
如果这个SOAP应用程序不是这个消息的最终目的地，则在转发消息之前删除第一步中识别出来的所有部分。
为了正确处理一条消息或者消息的一部分，SOAP处理器需要理解：所用的交换方式（单向，请求/应答，多路发送等等），这种方式下接收者的任务，RPC机制（如果有的话）的使用（如第7节中所述），数据的表现方法或编码，还有其它必需的语义。
尽管属性（比如SOAP encodingstyle，见4.1.1节）可以用于描述一个消息的某些方面，但这个规范并不强制所有的接收方也必须有同样的属性并取同样的属性值。
举个例子，某一特定的应用可能知道一个元素表示一条遵循第7节约定的RPC请求，但是另外一些应用可能认为指向该元素的所有消息都用单向传输，而不是类似第7节的请求应答模式。
（译者注：交互双方的SOAP消息并不一定要遵循同样的格式设定，而只需要以一种双方可理解的格式交换信息就可以了）3. 与xml的关系所有的SOAP消息都使用XML形式编码（更多有关XML的信息请见[7]）一个SOAP应用程序产生的消息中，所有由SOAP定义的元素和属性中必须包括正确的名域。
SOAP应用程序必须能够处理它接收到的消息中的SOAP名域（见4.4节），并且它可以处理没有SOAP名域的SOAP消息，就象它们有正确的名域一样。
SOAP定义了两个名域（更多有关XML名域的信息请见[8]）soap封装的名域标志符是"/soap/envelope/";SOAP的编码规则的名域标志符是"/soap/encoding/";SOAP消息中不能包含文档类型声明，也不能包括消息处理指令。
[7] SOAP使用"ID"类型"id"属性来指定一个元素的唯一的标志符，同时该属性是局部的和无需校验的。
SOAP使用"uri-reference"类型的"href"属性指定对这个值的引用，同时该属性是局部的和无需校验的。
这样就遵从了XML规范[7]，XMLSchema规范[11]和XML连接语言规范[9]的风格。
除了SOAP mustUnderstand 属性(见4.2.3节）和SOAPactor属性(见4.2.2节）之外，一般允许属性和它们的值出现在XML文档实例或Schema中（两者效果相同）。
也就是说，在DTD或Schema中声明一个缺省值或固定值和在XML文档实例中设置它的值在语义上相同。
4. soap封装SOAP消息是一个XML文档，包括一个必需的SOAP封装，一个可选的SOAP头和一个必需的SOAP体。
在这篇规范剩余部分中，提到SOAP消息时就是指这个XML文档。
这一节中定义的元素和属性的名域标志符为："/soap/envelope/"; 。
一个SOAP消息包括以下部分：1.在表示这个消息的XML文档中，封装是顶层元素。
2.应用SOAP交换信息的各方是分散的且没有预先协定，SOAP头提供了向SOAP 消息中添加关于这条SOAP消息的某些要素(feature)的机制。
SOAP定义了少量的属性用来表明这项要素（feature）是否可选以及由谁来处理。
（见4.2节）3.SOAP体是包含消息的最终接收者想要的信息的容器（见4.3节）。
SOAP为SOAP体定义了一个Fault元素用来报告错误信息。
语法规则如下所示：封装元素名是 "envelope"在SOAP消息中必须出现。
可以包含名域声明和附加属性。
如果包含附加属性，这些属性必须限定名域。
类似的，"Envelope"可以包含附加子元素，这些也必须限定名域且跟在SOAP体元素之后。
SOAP头（见4.2节）元素名是"header"在SOAP消息中可能出现。
如果出现的话，必须是SOAP封装元素的第一个直接子元素。
SOAP头可以包含多个条目，每个都是SOAP头元素的直接子元素。
所有SOAP头的直接子元素都必须限定名域。
SOAP体（见4.3节）元素名是"body"在SOAP消息中必须出现且必须是SOAP封装元素的直接子元素。
