SOAP12规范Word格式.docx
《SOAP12规范Word格式.docx》由会员分享，可在线阅读，更多相关《SOAP12规范Word格式.docx（57页珍藏版）》请在冰豆网上搜索。
一个作为描述在消息中的内容以及如何处理消息的信息框架的信封（envelope），一组用于表示应用定义的数据类型的编码规则（encodingrules），一个用于表示远程过程调用和返回的约定以及一个使用底层协议进行消息交换的绑定（binding）约定。
潜在地，SOAP可以与很多其他的协议绑定使用；
不过，在本文档中，只定义了SOAP与HTTP已经SOAP与HTTPExtensionFramework的绑定。
StatusofthisDocument
Thissectiondescribesthestatusofthisdocumentatthetimeofitspublication.Otherdocumentsmaysupersedethisdocument.ThelateststatusofthisdocumentseriesismaintainedattheW3C.
ThisisthefirstW3CWorkingDraftoftheSOAPversion1.2specificationforreviewbyW3Cmembersandotherinterestedparties.IthasbeenproducedbytheXMLProtocolWorkingGroup（WG）,whichispartoftheXMLProtocolActivity.
TheXMLProtocolProtocolWorkingGrouphas,inkeepingwithitscharter,producedasetofrequirementsandusagescenariosthathavebeenpublishedasaWorkingDraft.TobetterevaluateSOAP/1.1againsttheserequirementsandusagescenarios,theWorkingGrouphasproducedanabstractmodelandaglossaryoftermsandconceptsusedbytheWorkingGroup.Inaddition,theWorkingGrouphasproducedanissueslistthatdescribesissuesandconcernsraisedbymappingitsrequirementsandtheXMLPabstractmodelagainsttheSOAP/1.1specificationaswellasissuesraisedonthe<
xml-dist-app@w3.org>
mailinglistagainstSOAP/1.1.
ThecurrentnameforthisspecificationisSOAPversion1.2,thisfirstWorkingDraftbeingbasedonSOAP/1.1aspertheWorkingGroup'
scharter（seechangeloginappendixD）
Commentsonthisdocumentshouldbesenttoxmlp-comments@w3.org（publicarchives）.Itisinappropriatetosenddiscussionemailstothisaddress.
Discussionofthisdocumenttakesplaceonthepublic<
mailinglist（Archives）pertheemailcommunicationrulesintheXMLProtocolWorkingGroupCharter.
ThisisapublicW3CWorkingDraft.Itisadraftdocumentandmaybeupdated,replaced,orobsoletedbyotherdocumentsatanytime.ItisinappropriatetouseW3CWorkingDraftsasreferencematerialortocitethemasotherthan"
workinprogress"
.AlistofallW3Ctechnicalreportscanbefoundathttp:
//www.w3.org/TR/.
1.引言
SOAPv1.2为在一个松散的、分布的环境中使用XML对等地交换结构化的和类型化的信息提供了一个简单且轻量级的机制。
SOAP本身并不定义任何应用语义，如编程模型或特定语义实现，它只是定义了一种简单的机制，通过一个模块化的包装模型和对模块中特定格式编码的数据的重编码机制来表示应用语义。
SOAP的这项能力使得它可被很多类型的系统用于从消息系统到RPC（RemoteProcedureCall）的延伸。
SOAP由四部分组成:
1.SOAPenvelop（SOAP信封，参阅section4），它构造定义了一个整体的表示框架，可用于表示在消息（message）中的是什么，谁应当处理它，以及这是可选的还是强制的。
2.SOAPencodingrules（SOAP编码规则，参阅section5），定义了一个编序机制用于交换应用程序定义的数据类型的实例。
3.SOAPRPCrepresentation（SOAPRPC表示，参阅section7），定义了一个用于表示远端过程调用和响应的约定。
4.SOAPbinding（SOAP绑定，参阅section6）定义了一个使用底层传输协议来完成在结点间交换SOAP信封的约定。
为了简化本规范，这四部分在功能上是正交的。
特别的，信封和编码规则是被定义在不同的命名空间（namespace）中，这样有利于通过模块化获得简明性。
本规范还定义了两种SOAP绑定（binding），用于描述SOAP消息（message）如何通过带或不带HTTP扩展框架[6]（HTTPExtensionFramework）的HTTP[5]消息（message）进行传输。
1.1设计目标
SOAP的主要设计目标是简明性和可扩展性。
这就意味着有一些传统消息系统或分布式对象系统中的特性将不包含在SOAP的核心规范中。
这些特性包括：
∙分布式垃圾收集（distributedgarbagecollection）;
∙批量消息传输/处理（boxcarringorbatchingofmessages）;
∙对象引用（objects-by-reference,需要分布式垃圾收集的支持）;
∙对象激活（activation,需要对象引用的支持）。
1.2符号约定
本文中的关键词“MUST”,“MUSTNOT”,“REQUIRED”,“SHALL”,“SHALLNOT”,“SHOULD”,“SHOULDNOT”,“RECOMMENDED”,“MAY”,“OPTIONAL”的语义应当参阅RFC-2119[2]。
在本中文版规范中被翻译成：
“必须”、“必须不”，“需要的”，“将”，“将不”，“应该”，“应该不”，“被推荐的”，“可以”，“可选的”。
本文中使用的命名空间前缀“env”和“enc”等关联的SOAP命名空间分别位于以下位置：
"
//www.w3.org/2001/06/soap-envelope"
和"
//www.w3.org/2001/06/soap-encoding"
。
在本文的全部内容中，命名空间前缀"
xs"
和"
xsi"
总假定是与"
//www.w3.org/2001/XMLSchema"
//www.w3.org/2001/XMLSchema-instance"
相关联的，这是由XMLSchemas规范[10,11]所定义的。
值得注意的是其他的对命名空间前缀的使用都是比较随意的而并没有显著语义的约束的。
若命名空间的URI使用"
//example.org/..."
或"
本规范使用扩充BNF（Backus-NaurForm）作为构造语言，可参阅RFC-2612[5]。
编辑的注解将使用黄色背景标识（也许无法在所有的媒介上显示），并使用前缀"
Ednote"
1.3SOAP消息示例
第一个例子展示了一个使用SOAP表示的简单的通知消息。
该消息包含了一个消息头"
alertcontrol"
和消息体"
alert"
，这两部分都是由应用程序定义的，而而并不是由SOAP定义的。
消息头包含了两个参数"
priority"
expires"
，用于消息传输中介和消息接受者对消息的处理。
而消息体中则包含是实际传送的消息。
Example0
<
env:
Envelopexmlns:
env="
>
<
Header>
n:
alertcontrolxmlns:
n="
//example.org/alertcontrol"
priority>
1<
/n:
expires>
2001-06-22T14:
00:
00-05:
00<
alertcontrol>
/env:
Body>
m:
alertxmlns:
m="
//example.org/alert"
msg>
PickupMaryatschoolat2pm<
/m:
alert>
Envelope>
SampleSOAPMessagecontainingaheaderblockandabodyblock
SOAP消息能够与不同的底层协议进行绑定，同时可以在很多种消息传输模式中使用。
下面的例子则展示了SOAP是如何在HTTP的连接中使用的，其中充分使用了HTTP提供的请求/相应机制（参阅section6）。
Example1和Example2展示了一个SOAP/HTTP请求的例子和一个SOAP/HTTP响应的例子。
SOAP/HTTP请求包含了一个获取最后交易价格（GetLastTradePrice）的信息块，其中包含了一个简单的参数，指明需要报价的股票代号。
同样，与先前的例子相似，GetLastTradePrice这个XML元素也并不是由SOAP自身定义的。
该请求的服务响应也包含了一个简单的参数，股票的价格。
SOAP信封元素是表示SOAP消息的XML文档的顶级元素。
XML命名空间则用来消除SOAP标识符与应用定义的标识符之间可能存在的歧义。
Example1
POST/StockQuoteHTTP/1.1
Host:
Content-Type:
text/xml;
charset="
utf-8"
Content-Length:
nnnn
SOAPAction:
"
//example.org/2001/06/quotes"
>
GetLastTradePrice
env:
encodingStyle="
xmlns:
symbol>
DIS<
/symbol>
GetLastTradePrice>
SampleSOAPMessageembeddedinanHTTPRequest
Example2展示了StockQuote服务响应由Example1描述的请求消息而返回的SOAP消息。
Example2
HTTP/1.1200OK
GetLastTradePriceResponse
Price>
34.5<
/Price>
GetLastTradePriceResponse>
SampleSOAPMessageembeddedinanHTTPResponse
在AppendixA中提供了更多的例子。
1.4SOAP术语
1.4.1协议概念
SOAP
关于SOAP消息的格式和处理规则、为沿着SOAP消息路径交换信息而需要的不同应用程序之间生成和接收SOAP消息的交互过程的简单控制机制等的一整套规范和约定。
SOAP绑定
为传输的需要而将SOAP消息在另一个底层协议之上或之内传输的一整套规范和规则。
典型的SOAP绑定包括在HTTP消息中传送SOAP消息或在TCP之上传送SOAP消息等。
SOAP结点
SOAP结点根据SOAP定义的整套规范来处理SOAP消息。
SOAP结点有责任遵守SOAP消息交换的规则以及提供通过依赖底层协议的SOAP绑定来访问的服务。
任何不符合SOAP约定的情况都将导致SOAP结点产生一个SOAP错误（可参阅SOAP接受者和SOAP发送者）。
1.4.2数据封装概念
SOAP消息
SOAP消息（message）是在对等SOAP结点（SOAPnodes）间通讯的基本单位。
SOAP信封
SOAP信封（envelope）是SOAP规范中定义的SOAP消息（SOAPmessage）在句法上的最外层结构。
在句法上，它包含了所有其他的元素。
SOAP条目
SOAP条目是一个句法上的结构，它用于包含一个逻辑上的单一元素，这一元素是需要被SOAP结点处理的。
一个SOAP条目是由该条目最外层元素的完整修饰名所标识的，这个完整修饰名是由一个局部名和一个命名空间URI组成的。
封装在SOAPheader中的SOAP条目成为Header条目，而封装在SOAPbody中的SOAP条目为Body条目。
SOAPheader
能够被SOAP消息路径中任意的SOAP接受者处理的一组SOAP条目（0个或多个）。
SOAPbody
能够被SOAP消息路径中的最终SOAP接受者处理的一组SOAP条目（0个或多个）。
SOAPfault
SOAP结点产生的用于包含错误信息的特殊的SOAP条目。
以下的图表演示了一个SOAP消息是如何组成的。
Figure1:
EncapsulationmodelillustratingthepartsofaSOAPmessage
1.4.3消息发送者和接收者概念
SOAP发送者
SOAP发送者是发出SOAP消息的SOAP结点。
SOAP接收者
SOAP接收者是接受SOAP消息的SOAP结点。
SOAP消息路径
为传送一个简单的SOAP消息而要经过的一组SOAP发送者和SOAP接受者。
其中包含了初始SOAP发送者、零个或多个SOAP中介以及最终SOAP接受者。
初始SOAP发送者
SOAP消息的最初产生者，同时也是SOAP消息路径的第一个结点。
SOAP中介
SOAP中介即是SOAP接收者也是SOAP发送者，是SOAP消息可到达的某一个应用程序。
当SOAP消息沿着SOAP消息路径传输时，SOAP中介将处理一组确定的SOAP条目，然后它将消息转发给消息路径的下一个SOAP结点，直至传送到最终SOAP接收者。
最终SOAP接收者
由初始SOAP发送者指定的通过SOAP消息路径传送SOAP消息的最终SOAP接收者。
如果在SOAP消息路径中有SOAP结点产生了SOAP错误，那么SOAP消息将不会到达最终接收者。
1.4.4数据编码概念
SOAP数据模型
一组抽象的构造约定，用于描述通用的数据类型和数据中的链接关系。
SOAP数据编码
在SOAP消息中使用一个或多个SOAP条目，按照SOAP数据模型完成句法上的数据表示。
2.SOAP消息交换模型
从根本上来看，SOAP消息是从发送方到接受方的一种传输方法，但就象前面例子中阐述的那样，SOAP消息一般会和实现模式结合，例如请求/响应。
SOAP的实现可以为特殊网络系统的特有特征来优化。
例如，在section6中描述的HTTPbinding将SOAP响应消息通过HTTP响应来传输，使用与相对应请求的同一HTTP连接。
2.1SOAP结点
SOAP结点可以是初始SOAP发送者，可以是最终SOAP接收者，也可以是同时作为SOAP发送者和接收者的SOAP中介。
SOAP并不提供一个路由机制，曾因此SOAP需要识别SOAP发送者产生的SOAP消息应当通过哪些零个或多个SOAP中介被发送到一个最终SOAP接收者。
接收到SOAP消息的SOAP结点必须能够实施处理、产生必要的SOAP错误和SOAP响应，如果合适的话还应当根据本规范的后续描述生成额外的SOAP消息。
2.2SOAP角色与SOAP结点
当处理一个SOAP消息的时候，SOAP结点将被告知应当以一个或多个SOAP处理角色来处理，这些SOAP角色由SOAPactor名来标识，SOAPactor的名字是一个URI。
每个SOAP结点都必须以一个指定的角色来处理，这个角色使用命名为"
//www.w3.org/2001/06/soap-envelope/actor/next"
的SOAPactor来表示，同时可以按照需要应用零个或多个其他SOAPactor表示的额外角色。
SOAP结点可以通过以匿名SOAPactor的角色来实施处理以使得自己成为最终SOAP接收者。
当SOAP结点在处理一个SOAP消息的时候，其表现出的SOAP角色在整个处理过程中不得更改。
这是因为本规范只涉及如何处理单个SOAP消息而无需考虑状态，因此是否允许在处理单个SOAP消息的时候转换角色是没有意义的。
SOAPactor名字是用来识别SOAP结点的，并没有与路由或者消息交换的语义相联系。
举例来说，一个SOAPactor可以被命名为一个用来发送SOAP消息给适当SOAP结点的URI。
相反，也有这样一些SOAP处理角色的名字，这些名字或者直接和消息路由相联系（例如,http:
//example.org/banking/anyAccountMgr），或者和路由没有联系（例如，当一个消息头被用来携带一个指示，该指示用来告知任何有关的软件该SOAP消息是长期不变的，是能够被安全的缓存和重用的，在这种SOAP消息头中，一个URI可以用于标识“所有缓存管理软件”），通过名字使用这些SOAP处理角色也是合适的。
2.3定位SOAPHeader条目
SOAPheader条目包含可选的env:
actor属性（参阅section4.2.2）用来把他们定位到合适的SOAP结点。
没有该属性的SOAPHeader隐含地定位到一个匿名的SOAPactor，这意味着他们被处理为最终的SOAP接收者。
我们把SOAPactor属性的值（隐含的或者直接指明的）作为相应SOAP条目（SOAPHeader条目或者SOAPBody条目）的SOAPactor。
如果SOAP条目中SOAPactor（如果出现的话）匹配了一个SOAP结点的角色，或者是SOAP条目没有actor属性（包括SOAPBody条目）而该SOAP结点已经假设为匿名SOAP处理角色，这时我们就说SOAP条目被指向一个SOAP结点。
2.4理解SOAPHeader
我们认为随着时间的过去，会有大量的SOAPHeader函数规范出现，而且每个SOAP结点都可以包含一个或多个处理这些扩展所必须的软件。
如果SOAP结点的软件是完全兼容的而且实现了那些由条目中完整修饰的最外层元素名所传递的语义，我们说这个SOAPHeader被一个SOAP结点理解。
当定位到一个SOAP结点的SOAPHeader块的mustUnderstand属性为“1”，被指向的SOAP结点必须：
或者依照由条目中完整修饰的最外层元素名传递的语义来处理SOAP块，或者更本不处理SOAP消息而失败（参见section4.4）.。
2.5处理消息
本节陈述了SOAP消息处理规则。
除非另外规定，处理必须在语义上等同于分别执行下述的步骤，同时还必须按照给定的顺序。
注意到，无论如何在这个规范中都没有阻止使用如并行、回滚或者其他可以在处理中提高灵
升级会员 