soap的四大要素,SOAP的主要内容

Soap接口和webservice接口的区别是什么

SOAP ： 简单对象访问协议（Simple Object Access Protocol，SOAP），是一种轻量的、简单的、基于XML的协议，它被设计成在WEB上交换结构化的和固化的信息。

SOAP跟HTTP、SMTP等一样 是一种传输协议。

webservice接口的实现 就是 采用SOAP协议的。

webService三要素：SOAP 、 WSDL、UDDI

Delphi的实训心得体会

用Delphi编写WebService的心得体会

Dispatch: 派遣,分派 Invoke: 调用 Invokable: 可调用接口

TReomtable: WebService中自定义类都是继承自该类 TSOAPAttachment: Attachment:附件,一种流类型,可以返回流数据 CGI:（EXE）

ISAPI:（DLL） Base64编码: uses EncdDecd; s := EncodeString(s); //加 base64 编码 s := DecodeString( str ); //解码 UTF8: UTF8 是8位的UNICODE字符，而ASCII是7位 ,gb2312和unicode是2字节/字，utf8是3字节/字utf8类似以前的8位转7位的编码，是为 了 在网络间不同系统的通讯方便而作的转换。 几乎所有用.Net写的WebService只支持DOC方式、Delphi写的只支持RPC方式；J2ME目前对Web Service的支持仅限于RFC172，而 RFC172要求必须为DOC方式（sun怎么偏袒MS？）！

为了在设计中减少障碍，下面还介绍几个概念。

1) SOAP：SOAP是一种简单有效的数据传输协议，用于分布式网络环境下数据信息交换，它以XML 作为数据传输的格式，搭配Internet上标准的传输协议HTTP、SMTP、TCP等来传送信息。从本质上看，SOAP事实上只是将Request和Response经由XML格式把数据打包，达到双方沟通的目的。

2) WSDL:WSDL(Web Service Description Language)是一种以XML格式描述的Web Service语言，当Web Service Provider 要对外公布提供的 Web Service，就需要通过WSDL来构建描述语言。 在WSDL中有两个非常重要的要素： ：此WSDL文件所要描述的Web Service集合； 每一个Port代表外界Client可以和此Service沟通的一个进入点，一个Port会指定一个Binding方式。

3):处理中文乱码的问题: 将HttpRio的 Converter 的 Options 的 soUTF8InHeader 设为 True 将生成soap消息的HTTPSoapDispatcher控件，添加encoding为gb2312 HTTPRIO.HTTPWebNode.UseUTF8InHeader := True;

4)在Delphi中，能够传递的自定义类型的对象要继承TRemotable,

5:修正一个服务器端的一个Bug:将ISAPIThreadPool和ISAPIApp的次序变一下:ISAPIApp必须在ISAPIThreadPool之前： uses ... ISAPIApp, ISAPIThreadPool 解决如下错误: Received content of invalid Content-Type setting:text/html -SOAP"expects"text/xml" 6:"XML document must have a top level element. Line: 0" 错误，我该如何解决？？ 哈纳斯 (2002-08-05 17:26:00) 我也曾碰到同样的问题 解决方法是：别设httprio的wsdllocation,设它的url 如 mydir是你的可执行的虚拟目录，IFIRST是你定义的接口名 ***********************************************************************************************

Delphi中WebService包含的组件解释(有7个)

(1) THTTPRIO-------:使用Http消息来调用远程使用SOAP的接口对象

(2) THTTPReqResp---:给服务器发送一个SOAP消息, THTTPReqResp在可调用接口上执行一个方法请求.

(3) TOPToSoapDomConvert ----:TOPToSoapDomConvert处理Soap方法请求的组合与分发

(4) TSoapConnection:TSoapConnection在客户端的多层数据库应用中创建并维护客户端和作为WebService 的远程应用服务器间的连接

(5) THTTPSoapDispatcher -----:通过将Soap消息转发给调用者,THTTPSoapDispatcher对Soap消息做出响应.

(6) TWSDLHTMLPublish -----:TWSDLHTMLPublish发布描叙webService应用的Wsdl文档

(7) THTTPSoapPascalInvoker -----:THTTPSoapPascalInvoker解释Soap的请求信息,并执行相应的可调用接口. ***********************************************************************************************

WSDL 说明:

(Web Services Description Language) 规范是一个描述接口，语义以及Web服务为了响应请求需要经常处理的工作的XML文档。这将使 简单地服务方便，快速地被描述和记录。以下是一个WSDL的样例： My first service

它包含了以下的关键信息： 消息的描述和格式定义可以通过XML文档中的和 标记来传送。 标记中表示了消息传送机制。 (e.g. request-only, request-response, response-only) 。 标记指定了编码的规范 。 标记中表示服务所处的位置 (URL)。 WSDL在UDDI中总是作为一个接口描述文档。因为UDDI是一个通用的用来注册WSDL规范的地方，UDDI的规范并不限制任何类型或者格式描述文档 。这些文档可能是一个WSDL文档，或者是一个正规的包含导向文档的Web页面，也可能只是一个包含联系信息的电子邮件地址。现在Java提供了一个 Java API for WSDL (JWSDL)规范。它提供了一套能快速处理WSDL文档的方法，并且不用直接对XML文档进行操作，它会比 JAXP更方便，更快速。 ***********************************************************************************************

SOAP说明

(Simple Object Access Protocal)。 我们先简单了解WebServices运作模式。服务端生成服务描述文件WSDL(Web Services Description Language，类似COM的Interface Description Language)，如果接收客户端的SOAP请求消息（XML格式数据），解析其调用和参数，根据WSDL和WSML（Web Services Meta Language，Microsoft为描述WSDL里提供的方法与实现该方法的COM对象之间的映射关系而特地设立），调用相应COM对象完成指定功能，并返回 到SOAP消息遣至用户；客户端取得并解析服务端的服务描述文件从而得知服务端的服务内容及调用方式，生成SOAP请求消息（指定调用的方法 名称和参数）送往服务端。 ***********************************************************************************************

TReomtable说明

: WebService中自定义类都是继承自该类 //自己定义一个继承自TRemotable的类 (注意只有属性定义,没有方法) TSpeciesInfo = class(TRemotable) private FLength: Integer; FSpeciesName: string; FCategory: string; FCommonName: string; FmoreInfo: string; published property Category: string read FCategory write FCategory; property CommonName: string read FCommonName write FCommonName; property SpeciesName: string read FSpeciesName write FSpeciesName; property Length: Integer read FLength write FLength; property MoreInfo: string read FmoreInfo write FMoreInfo; end;

TSOAPAttachment说明

:一种Soap的流类型数据.跟平时的integer等等一个意思 //比如

(1):服务器端建立一个流输出(result:) GrapStream:=TMemoryStream.create; try SoapAttachment:=TSoapAttachment.create; TBolbField(frmdm.adoqury.fields[0]).SaveToStream(GrapStream); SoapAttachment.SetSourceStream(GraphStream,soReference); result:=SoapAttachment; except if assigned(GrapStream) then GrapStream.free; if assigned(SoapAttchament) then SoapAttchment.free; end

(2):客户端接受一个流输入 var src:string; begin if not Assigned(SoapAttachment) then exit; Src:=SoapAttachment.CacheFile; ....

例子,基于Soap和webService的分布式网络程序实例

//编写服务器端 --ok

1:File ---New----Other-----WebService---Soap WebService Application 后生成3个组件 一个是调用者组件:THTTPSoapPascalInvoker:完成Soap消息和.... 一个是调度者组件:THTTPSoapDispatcher:自动响应送入的soap消息,并且把他们传递给调用者,可以使用他的 WebDispatch属性来识别应用程序响应的http请求.包括设置PathInfo属性来指明指向应用 程序的任何URL的路径部分,设置MethodType属性来指明请求消息的方法头. 一个是WSDL发布者:TWSDLHTMLPublisher:WSDL发布者发布描叙接口以及如何调用他们的wsdl文档,使用非delphi 编写的客户端程序也可以调用WebService应用程序.

2:在接口中添加方法和在实现该接口的类中实现该方法. (1):接口中自定义的类都是继承自TRemotable类,该类只能有属性,没有方法 (2):

3:将生成的Dll文件拷贝到 C:\InetPub\Scripts目录下面.

//编写客户端 --ok

(1):File---New---other----WebSerice---Wsdl Importer: 对话框1:WsDl Source:输入==http://服务器名/scripts/应用程序名/wsdl/相应接口 ,然后Next下步.然后点finish

(2):添加一个普通的窗体,上面放WebService中的控件:HTTPRIO,编写它的OnAfterExecute ,OnBeforeExecute事件 连接服务: ***请注意是Soap/接口 FAttachService为WebService的接口 if FAttachService = nil then begin FAttachService := GetiMyWeb(False, EditUrl.Text); (FAttachService as IRIOAccess).RIO.OnBeforeExecute := HTTPRIO1BeforeExecute; (FAttachService as IRIOAccess).RIO.OnAfterExecute := HTTPRIO1AfterExecute; end; Result := FAttachService; ******************************************************************************* (HTTPRIO1 as ITest).TestFunction(aParam, bParam);

(3):注意在IIS中设置Script的是否有执行权限.

编写一个基于Soap DataModule的三层数据库应用

服务器端:

建立一个Web App Debugger executable类型,不需要接口,添加一个Soap Data Module,放上AdoCon,AdoDataSet,DataSetProvider1 设置数据好连接,利用AdoDataSet打开一个数据集,然后编译运行,打开Web App Debugger查看是否正确.

客户端:

(1)建立一个普通的应用程序,添加SoapConnection1组件,设置他的url:格式为:

(2)添加一个ClientDataSet 设置它的RemoteServer=SoapConnection1,provideName=DataSetProvider1 (注意将Web App Debugger打开) (3)Active就可以看到数据了.

WebService的服务器端的调试

(1):编写服务器时选择:Web App Debugger executable类型

(2):编写完成后运行一次服务器,则系统将把该webservice的类注册

(3):启动Tool---Web App Debugger,设置servers的options port============1024 default url===== 其中demo3为exe程序的名字, wadSoapDemo3为建立服务器的时 候填写的类名称,可在主Form的initialization中找到:TWebAppSockObjectFactory.Create('wadSoapDemo3')

(4)打开ie,在地址输入:就可以查看接口了

Spring Boot 开发 SOAP 服务

本文介绍 Spring Boot 2 开发 SOAP 服务的方法。

SOAP，Simple Object Access Protocol，简单对象访问协议，是一种基于 XML 实现网络中数据交换的通信协议。

一条 SOAP 消息就是一个普通的 XML 文档，包含以下元素：

语法规则：

SOAP 是 Web Service 三要素之一，是用来描述传递信息的格式，另外两个元素：

jaxb2-maven-plugin 能够实现 Java 类和 XML Schema 间的转换，配置说明：

完整的 pom 文件如下：

Web Service 领域模型定义在 XML Schema(XSD) 文件中，Spring-WS 会自动导出 WSDL。

说明：

注意：必须为 MessageDispatcherServlet 和 DefaultWsdl11Definition 实例指定名称，通过指定名称确定 WSDL URL。本文示例中 MessageDispatcherServlet 实例名称为 ws ， DefaultWsdl11Definition 实例名称为 user ，因此 WSDL URL 是 ;host:port/ws/user.wsdl 。

说明：

从 WSDL 文件中可以看出：

Spring Boot 开发 SOAP 服务的步骤：

soap有哪些常用的协议和规范

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-ENV"

和"SOAP-ENC"分别与""

和""关联。整篇文档中，名域前缀“xsi”被假定为与

URI"“（在XMLSchema规范[11]定义）相连。类似

的，名域前缀”xsd“被假定为与URI""（在[10]中定义）相连。名域前

缀”tns“用来表示任意名域。所有其它的名域前缀都只是例子。

名域URI的基本形式”some－URI“表示某些依赖于应用程序或上下文的URI[4]。这个规范用扩展BNF（在RFC－2616[5] 描述）描述某些结构。

1.3 SOAP消息举例

在这个例子中，GetLastTradePrice SOAP

请求被发往StockQuote服务。这个请求携带一个字符串参数和ticker符号，在SOAP应答中返回一个浮点数。XML名域用来区分SOAP标志

符和应用程序特定的标志符。这个例子说明了在第6节中定义的HTTP绑定。如果SOAP中管理XML负载的规则完全独立于HTTP是没有意义的，因为事实

上该负载是由HTTP携带的。在Appendix A中有更多的例子。

例1 在HTTP请求中嵌入SOAP消息

POST /StockQuote HTTP/1.1

Host:

Content-Type: text/xml;

charset="utf-8"

Content-Length: nnnn

SOAPAction:

"Some-URI"

SOAP-ENV:Envelope

xmlns:SOAP-ENV=""

SOAP-ENV:encodingStyle=""

SOAP-ENV:Body

m:GetLastTradePrice xmlns:m="Some-URI"

symbolDIS/symbol

/m:GetLastTradePrice

/SOAP-ENV:Body

/SOAP-ENV:Envelope

下面是一条应答消息，包括HTTP消息，SOAP消息是其具体内容 ：

例2 在HTTP应答中嵌入SOAP消息

HTTP/1.1 200 OK

Content-Type: text/xml;

charset="utf-8"

Content-Length:

nnnn

SOAP-ENV:Envelope

xmlns:SOAP-ENV=""

SOAP-ENV:encodingStyle=""/

SOAP-ENV:Body

m:GetLastTradePriceResponse xmlns:m="Some-URI"

Price34.5/Price

/m:GetLastTradePriceResponse

/SOAP-ENV:Body

/SOAP-ENV:Envelope

. SOAP消息交换模型

SOAP消息从发送方到接收方是单向传送，但正如上面显示的，SOAP消息经常以请求/应答的方式实现。SOAP实现可以通过开发特定网络系统的特

性来优化。例如，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的编码规则的名域标志符是""

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消息包括以下部分：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封装元素的直接子元素。它必须直接跟在SOAP头元素（如果有）之后。否则它必须是SOAP封装元素的第一个直接子元素。

SOAP体可以包括多个条目，每个条目必须是SOAP体元素的直接子元素。SOAP体元素的直接子元素可以限定名域。SOAP定义了SOAPFault元素来表示错误信息。

4.1.1 SOAP encodingStyle属性

EncodingStyle全局属性用来表示SOAP消息的序列化规则。这个属性可以在任何元素中出现，作用范围与名域声明的作用范围很相似，为这

个元素的内容和它的所有没有重载此属性的子元素。SOAP消息没有定义缺省编码。属性值是一个或多个URI的顺序列表，每个URI确定了一种或多种序列化

规则，用来不同程度反序列化SOAP消息，举例如下：

""

" "

""

第5节中定义的序列化规则由URI""

确定。使用这个特定序列化规则的消息应该用encodingStyle属性说明这一点。另外，所有

以""开头的URI中的序列化规则与第5节中定义的SOAP编码规

则相一致。一个零长度的URI（""）明确显示所含元素没有任何编码形式。这可以用来取消上一级元素的所有编码声明。

4.1.2 封装版本模型

SOAP没有定义常规的基于主版本号和辅版本号的版本形式。SOAP消息必须有一个封装元素与名

域""关联。如果SOAP应用程序接收到的SOAP消息中的

SOAP封装元素与其他的名域关联，则视为版本错误，应用程序必须丢弃这个消息。如果消息是通过HTTP之类的请求/应答协议收到的，应用程序必须回答一

个SOAP VersionMismatch 错误信息（见4.4节）。

4.2 SOAP头

SOAP为相互通信的团体之间提供了一种很灵活的机制：在无须预先协定的情况下，以分散但标准的方式扩展消息。可以在SOAP头中添加条目实现这种

扩展，典型的例子有认证，事务管理，支付等等。头元素编码为SOAP封装元素的第一个直接子元素。头元素的所有直接子元素称作条目。条目的编码规则如下：

一个条目有它的完整的元素名（包括名域URI和局部名）确定。SOAP头的直接子元素必须有名域限制。

SOAP encodingStyle属性可以用来指示条目所用的编码形式（见4.1.1节）

SOAP mustUnderstand属性（见4.2.3节）和SOAPactor属性（见4.2.2节）可以用来指示如何处理这个条目以及由谁来处理。（见4.2.1节）

4.2.1 使用头属性

这一节中定义的SOAP头属性确定了SOAP消息的接收者应该怎样按第2节中所述的方式处理消息。产生SOAP消息的SOAP应用程序，应该仅仅在

SOAP头元素的直接子元素中使用这些SOAP头属性。SOAP消息的接收者必须忽略所有不在SOAP头元素的直接子元素中SOAP头属性。下面的例子是

一个SOAP头，包括一个元素标志符"Transaction"，"mustUnderstand"取值为"1"和数值5。这应该以如下方式编码：

SOAP-ENV:Header

t:Transaction

xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1"

5

/t:Transaction

/SOAP-ENV:Header

4.2.2 SOAP actor属性

一个SOAP消息从始节点到终节点的过程中，可能沿着消息路径经过一系列SOAP中间节点。一个SOAP中间节点是一个可以接收转发SOAP消息的

应用程序。中间节点和终节点由URI区分。可能SOAP消息的终节点并不需要所有部分，而在消息路径上的一个和几个中间节点可能需要这些内容。头元素的接

收者扮演的角色类似于一个过滤器，防止这些只发给本接受者的消息部分扩散到其它节点。即一个头元素的接收者必须不转发这些头元素到SOAP消息路径上的下

一个应用程序。同样的，接收者可能插入一个相似的头元素。SOAP actor全局属性可以用于指示头元素的接收者。SOAP

actor属性的值是一个URI。

URI

""指出了第一个处理这个消息的SOAP应用程序需要这个头元

素。这类似于HTTP头中用Connection域表示hop-by-hop范围模型。省略SOAP

actor属性表示接收者是SOAP消息的终节点。如果这个属性要生效，它必须出现在SOAP消息实例中。（见第3节和4.2.1节）

4.2.3 SOAP mustUnderstand属性

SOAP mustUnderstand全局属性用来指示接受者在处理消息时这个条目是否必须处理。条目的接收者由SOAP

actor属性定义（见4.2.2节）。MustUnderstand属性的值是"1" 或 "0"。缺少SOAP

mustUnderstand属性在语义上等同于它的值为"0"。如果一个头元素的SOAP

mustUnderstand属性的值是"1",那么条目的接受者必须或者遵守语义（如以元素的全名传送）并按照语义正确的处理，或者放弃处理消息（见

4.4节）。SOAP mustUnderstand 属性考虑了消息演变的准确性（robust evolution）。必须假定包含SOAP

mustUnderstand属性且值为"1"的元素以某种方式修改了它们的父元素或同层元素的语义。以这种方式连接元素确保了语义上的变化不会被那些不

能完全理解它的接收者忽略。如果这个属性要生效，它必须出现在SOAP消息实例中。（见第3节和4.2.1节）

4.3 SOAP体

SOAP体元素提供了一个简单的机制，使消息的最终接收者能交换必要的信息。使用体元素的典型情况包括配置RPC请求和错误报告。体元素编码为

SOAP封装元素的直接子元素。如果已经有一个头元素，那么体元素必须紧跟在头元素之后，否则它必须是SOAP封装元素的第一个直接子元素。体元素的所有

直接子元素称作体条目，每个体条目在SOAP体元素中编码为一个独立的元素。条目的编码规则如下：

一个条目由它的元素全名（包括名域URI和局部名）确定。SOAP体元素的直接子元素可能是名域限制的。

SOAP encodingStyle属性可能用来指示条目（见4.1.1节）的编码方式。

SOAP定义了一个Fault条目用来报告错误信息。（见4.4节）

4.3.1 SOAP头和体的关系

虽然头和体定义为独立的元素，它们实际上是有关系的。体条目和头条目的关系如下：体条目在语义上等同于actor属性为缺省值且mustUnderstand属性值为"1"的头条目。不使用actor属性则表示缺省的actor。

Web Service

Web Service 技术是原来的组件技术思想在 Internet 时代中的进一步发展，更准确地说，Web Service 是封装成单个实体发布到网络上，并提供 API 以提供其他程序使用的功能集合，是在 Internet 上进行分布式计算的基本构造块，是可用 URL 定位服务资源。简言之，Web Service 是可远程调用的应用程序组件。Web Service 的本质目的是提供一个与操作系统、程序设计语言、机器类型、运行环境均无关的平台，实现 Internet 中应用程序的共享。Web Service 基于一系列的标准协议，其协议构架如图 4.4 示。

图 4.4 Web Service 协议架构

统一描述、发现与集成协议 UDDI(UniversalDescription，Discovery and Integration )用 于 构 建Web Service 的服务注册中心，实现服务发现功能。Web 服务描述语言 WSDL(Web Service DescriptionLanguage)驻 留 在 服务 容 器 中， 定义 了 一 种提供Web 服务 描述 的 标 准化 方 式。简 单 对 象 访 问协议SOAP(Simple Object Access Protocol)提供传输数据的标准方式，充当在服务提供方和服务请求方之间激活服务的消息交换服务。可扩展标记语言 XML(Extensible Markup Language)是 Internet 上数据交换的标准，在 Web Service 中实现信息表达，用于 SOAP，WSDL 和 UDDI。超文本传输协议 HTTP(Hyper Text Transfer Protol)是 Web Service 最流行的传输协议。Web Service 体系结构是一种面向服务的结构，典型的Web Service 组件架构如图 4.5 示。

Web Service 体系结构主要由服务请求者、服务注册中心和服务提供者三部分组成。其实现过程包括服务发布与注册、服务查询与发现、服务绑定与调用三个过程。服务请求者指查询、调用服务的客户端程序; 服务提供者即服务的所有者和部署服务的平台; 服务注册中心指用来存储服务信息的信息库，服务提供者在这里发布、注册服务、而服务请求者在这里查询、绑定服务，最终实现调用服务提供者的服务。

图 4.5 Web Service 组件架构

Web Service 有两大核心优势，即分布性和互操作性。在 Web Service 架构下，服务提供者和服务请求者都可以是分布式的，一个服务请求者可以远程调用多个服务提供者的服务，服务提供者也可以同时为多个服务请求者提供服务，这为服务共享提供了一个最佳的方式。

互操作性也是服务共享的关键问题。Web Service 的信息表达基于标准通用的 XML 语言，在 XML 语言的基础上，使用 WSDL 和 UDDI 实现服务注册与发现，使用 SOAP 实现服务调用。基于这些标准的协议，Web Service 实现了服务的跨平台、跨语言的共享。XML、SOAP、WSDL 和 UDDI 是用于构建和使用 Web Service 的核心标准和技术。以下将分别介绍这四种标准和技术。

4.2.2.1 XML

XML 是一种数据描述语言，为 Internet 上数据交换的标准。XML 定义了应用系统间传递数据的结构，而且这种结构的描述不是基于二进制的、只能由程序去判读的代码，而是一种简单的、能够用通用编辑器读取的文本。XML 的基本概念包括元素、属性、DTD，Schema 和命名空间等。元素是 XML 文档内容的基本单元。语法上而言，一个元素包括一个起始标记、结束标记以及标记之间的数据内容。形式上为: tag 数据内容 tag 。元素内容可以为其他的元素或未处理文本或两者的混合，还可以是空的。元素的嵌套使得文档的层次结构很容易表示。一个元素可以有多个属性。属性是一个名称数据对，表示为字符串。用户可以根据需要自己定义。一个元素不能有同名的两个属性。

XML 的精髓是允许文档编写者制定基于信息描述、体现数据间逻辑关系的自定义标记。如果不对文档标记作明确定义，而是任意地使用它们，则生成的文档是无法识别的。DTD 是对文档结构的一个清晰描述，定义了特定文档中允许出现的元素类型、属性和实体，给出了文档的整体结构和语法。XML Schema 是定义 XML 的数据定义文件。XMLSchema 也规定了一套特定文档的结构，这是与 DTD 的相同之处。与 DTD 相比，最大的不同在于它本身也是 XML 文档。此外还有以下的不同: XML Schema 可以用 XML 解析器来解析; 允许使用全局性元素(在整个 XML 文档中用相同的方式使用元素)和局部元素(特定的上下文中元素有不同的含义); 提供丰富的数据类型(整型、布尔型、日期类型等)，且元素的数据类型可以自定义。

XML 命名空间是一组可以用作 XML 文档的元素或属性名称的名称集，就是将元素或属性的名称归类。因为 XML 的开放性，允许任何人创建属于他们自己的元素或属性名称，这样就不可避免地出现不同的人或组织定义的元素名称或属性名称重复，使得相同的名称表达不同的语义。为了避免元素之间出现相同名称的冲突，命名空间限定这些元素或属性名称在命名空间内是唯一的。一般命名空间由这些统一资源标识符 URI(Universal Resource Identifier)来识别。URI 在 Internet 上是全球唯一的，用 URI 来限定 XML 元素名称或属性名称也就确保是全球唯一的。XML 主要具有四大优势:

(1)XML 用文本格式表示数据，方便在 Internet 上的传输。这一点使 XML 数据可以方便地利用现有的 Internet 上基于文本的各种传输协议(如 HTTP)进行传输，可以安全的穿越防火墙。

(2)XML 是可扩展的。XML 是一个元语言(MetaLanguage)，它使用了标准化的方法定义其他语言。它只是为结构文档提供了一个数据格式，而没有深入该数据本身，定义它的词汇列表。这使自定义标记语言成为可能，每个行业，每个部门，甚至每个人都可以定义自己的标记语言。

(3)XML 可以对信息进行很好的层次描述。它基于信息内容的描述，对信息的表达清晰。

(4)XML 可以进行数据完整性的自动检验。XML DTD 和 Schema 机制使得 XML 解析器可以检验 XML 文档是否与 DTD 或 Schema 相配。

4.2.2.2 SOAP

SOAP 通过定义一个关于远程组件如何请求信息和如何递交信息的标准，实现 Internet中不同应用之间的集成和交互。SOAP 是一个基于 HTTP 和 XML 的请求、响应 RPC 协议。SOAP 把 XML 使用代码化为请求和响应参数编码模式，并用 HTTP 传输。SOAP 本身没有定义任何应用程序语义，如编程模型或特定语义的实现，实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。这使得 SOAP 能够被用于从消息系统到 RPC(远程进程调用)的各种应用中。

SOAP 规范主要由信封(Envelop)、编码规则(Encoding Rules)和 RPC 表示(RPC Representation)三部分组成。①SOAP 信封构造定义了一个整体的 SOAP 消息表示框架，可以用于表示消息中的内容是什么，是谁发送的，谁接受并处理它，以及这些处理操作是可选的还是必需的等。②SOAP 编码规则定义了一个数据的编码机制，通过这样一个编码机制来定义应用程序中需要使用的数据类型，并可用于交换由这些应用程序定义的数据类型所衍生的实例。③SOAP RPC 表示定义了一个用于表示远程过程调用和响应的约定，例如，如何使用 HTTP 或 SMTP 协议于 SOAP 绑定，如何传输过程调用，在具体传输协议的哪个部分传输过程响应，如可以在 HTTP 的响应的时候传递过程响应。这三部分在功能上是彼此独立的。特别的，信封和编码规则是被定义在不同的 XML 命名空间中，这样有利于通过模块化获得定义和实现的简明性。

SOAP 消息是 SOAP 应用中的主体要素。SOAP 为在一个松散的、分布的环境中使用XML 对等地交换结构化地和类型化的消息提供了一个简单的轻量级机制。SOAP 消息的描述框架格式是以 SOAP 信封为根元素，内含 SOAP Header 和 SOAP Body 子元素的一个XML 文档。所有的 SOAP 消息都是使用 XML 格式来编码的。SOAP 消息必须不包含 DTD与 PI(Processing Instructions)。除 SOAP must understand attribute 和 SOAP actor attribute外，一般允许属性及属性值自由地选择是在 XML 实例中描述还是在 XML Schema 中描述。SOAP 是一种基于 XML 的轻量级消息交换协议，它是建立在现有行业标准之上的，所以在支持这些标准的平台上运行的应用程序可以通过 SOAP 消息与其他平台上运行的应用程序有效地进行通信，而且能够穿越防火墙，因而得到了业界的广泛支持。

4.2.2.3 WSDL

Web 服务描述语言 WSDL(Web Services Description Language)是基于 XML 模式的规范，用于将 Web 服务描述为操作集，并将数据输入/输出参数描述为消息。WSDL 还定义使用绑定机制将任何传输协议、数据格式或结构附加到抽象消息、操作或终端的通信模型。

WSDL 将 Web 服务描述为一组服务访问点，或称为一组 “端口”，客户端可以通过这些端口对包含面向文档信息或面向过程调用的服务进行访问。一个端口定义了一个 “服务”项目的提供地点。一个服务可以有多个提供地点，但只能对一组事先定义好的 “信息”做出响应。“信息”是对通信数据的描述，每条信息由一组数据组成，这些数据必须定义为收、发双方都能识别的 “类型”。端口和信息结合在一起代表了一组 “操作”，并定义了这个服务访问点的 “端口类型”。把一种协议和一种数据格式关联在一起就定义出了一种可重复使用的 “绑定”。把一个网址和一个绑定关联在一起就定义了一个端口，相关的具体部署的端点通过组合就成为抽象的 Web 服务。综上所述，WSDL 文档的根元素是 definitions 元素，该元素又包含 6 个子元素:

(1)Types: 包含可由服务器收发的消息的架构定义。最常见的表示架构的方法是使用 XML 架构;

(2)Message: 充当一个将架构中的消息与消息的定义关联起来的交叉引用。简单地说，就是定义通信中的数据，包括数据输入和输出。

(3)PortType: 定义一组 Web 服务可公开的接口。一个接口与一个或多个消息关联。

(4)Operation: 它是对服务端所实现功能的抽象定义。

(5)Binding: 将 PortType 定义与某个特定的协议关联。

(6)Service: 定义 Web 服务公开的相关端点(端口)的集合。

4.2.2.4 UDDI

统一描述、发现和集成协议 UDDI(Universal Description，Discovery and Integration)是一套基于 Web 的、分布式的、为 Web 服务提供信息注册中心的实现标准规范，同时也包含一组使不同的人或组织能将自身提供的 Web 服务注册以使得他人或其组织能够发现的访问协议的实现标准。UDDI 注册的工作流程如图 4.6。

UDDI 注册中心是 Web 服务注册、用户集中管理的地方，通过它可以发布、查询、调用 Web Service，也可以查询特定服务的描述信息，并动态绑定到该服务上。UDDI 注册中心同时还提供服务结点管理、用户管理、权限管理、计费管理等功能。服务提供者提供服务需要到 UDDI 注册中心进行服务的注册、登记，这样用户就可以通过 UDDI 注册中心获取所需要服务的基本信息与技术细节信息，再通过对服务的绑定得到服务和产品。

图 4.6 UDDI 注册工作流程

什么是SOAP？

SOAP是一种报文格式，用于网络中两个实体之间的消息传递。它是Web服务中最重要的要素之一，另一个是WSDL。网络中的两个异质实体之间需要通信的话，一个比较好的办法就是两个异质实体间认同同一种格式的XML文档，SOAP报文就是这样一种符合XML标准的报文。

不知道你想了解的是不是计算机Web服务领域的SOAP报文