没有合适的资源?快使用搜索试试~ 我知道了~
简单对象访问协议_SOAP_初级指南.pdf
4星 · 超过85%的资源 需积分: 9 12 下载量 21 浏览量
2010-09-16
17:52:35
上传
评论
收藏 374KB PDF 举报
温馨提示
试读
18页
简单对象访问协议_SOAP_初级指南,适合对XML,SOAP有一定认识的朋友学习
资源推荐
资源详情
资源评论
简单对象访问协议(SOAP)初级指南
总结:
(本文假设读者对 COM 和 XML 技术已经很熟悉。)
SOAP(Simple Object Access Protocal) 技术有助于实现大量异构程序和平台之间
的互操作性,从而使存在的应用能够被广泛的用户所访问。SOAP 是把成熟的
基于 HTTP 的 WEB 技术与 XML 的灵活性和可扩展性组合在了一起。
这篇文章带你全面回顾对象远程进程调用(ORPC)技术的历程,以帮助你理
解 SOAP 技术的基础,以及它克服存在技术(如 CORBA 和 DCOM)的许多缺
陷的方法。随后讲述详细的 SOAP 编码规则,并把焦点放在 SOAP 是怎样映射
到存在的 ORPC 概念上的。
引言:
当我在 1984 年开始把计算作为我的职业的时候,大多数程序员并不关心网络协
议。但是在九十年代网络变得无所不在,现在如果有谁使用计算机却不使用某
种形式网络连接是很难以想象的。今天,一般的程序员对建立可扩展的分布式
应用表现出更大的兴趣,而不再只是关注于用 MFC 实现个性化的可浮动半透明
非矩形的 Coolbars 了。
程序员通常喜欢用编程模型来思考问题,而很少考虑网络协议。尽管这样做通
常是很好的,但在这篇文章中我将讨论的 SOAP 是一个没有明显的编程模型的
网络协议。这并不意味着 SOAP 的体系结构从根本上会改变你编程的方式。相
反,SOAP 的一个主要目标是使存在的应用能被更广泛的用户所使用。为了实
现这个目的,没有任何 SOAP API 或 SOAP 对象请求代理(SOAP ORB),
SOAP 是假设你将使用尽可能多的存在的技术。几个主要的 CORBA 厂商已经
承诺在他们的 ORB 产品中支持 SOAP 协议。微软也承诺在将来的 COM 版本中
支持 SOAP。DevelopMentor 已经开发了参考实现,它使得在任何平台上的任何
Java 或 Perl 程序员都可以使用 SOAP。
在 SOAP 后面的指导理念是“它是第一个没有发明任何新技术的技术”
。SOAP
采用了已经广泛使用的两个协议:HTTP 和 XML。HTTP 用于实现 SOAP 的
RPC 风格的传输,而 XML 是它的编码模式。采用几行代码和一个 XML 解析
器,HTTP 服务器(如 MS 的 IIS 或 Apache)立刻成为了 SOAP 的 ORBs。 因为
目前超过一半的 Web 服务器采用 IIS 或 Apache, SOAP 将会从这两个产品的广泛
而可靠的使用中获取利益。这并不意味着所有的 SOAP 请求必须通过 Web 服务
器来路由,传统的 Web 服务器只是分派 SOAP 请求的一种方式。因此 Web 服
务如 IIS 或 Apache 对建立 SOAP 使能的应用是充分的,但决不是必要的。
正如这篇文章将要描述的,SOAP 简单地用 XML 来编码 HTTP 的传输内容。
SOAP 最常用的应用是作为一个 RPC 协议。为了理解 SOAP 怎样工作,有必要
简要回顾一下 RPC 协议的历史。
RPCs 的历史
建立分布式应用的两个主要通信模型是消息传送(经常与队列组合在一起)和
请求/响应。消息传递系统允许通信任何一方在任何时间发送消息。请求/响应协
议把通信模式限制在请求/响应的双方。基于消息的应用强烈地意识到它们正在
与外部的并行进程进行通信,并且需要一个显式的设计风格。基于请求/响应的
应用更象一个单进程的应用,因为发送请求的应用或多或少被阻塞直至收到来
自另一个进程的响应。这使得请求/响应通信自然地适合于 RPC 应用。
尽管消息通信和请求/响应各有他们的优点,他们都是可以用对方来实现的。消
息系统可以用较底层的请求/响应协议来建立。如微软的 Message Queue Server
(MSMQ)内部采用了 DCE RPC 来建立大多数的控制逻辑。RPC 系统也可以采用
较底层的消息系统来建立。MSMQ 提供的关联 ID 正是为了这个目的。不管评
价如何,大多数的应用仍趋向于使用 RPC 协议,因为它们广泛的使用,它们更
简单的设计,以及更自然的到传统的编程技术的映射。
在八十年代,两个主要的 RPC 协议是 Sun RPC 和 DCE RPC。最流行的 Sun
RPC 应用是大多数 UNIX 系统所使用的 Network File System (NFS)。最流行的
DCE RPC 应用则是 Windows NT?,它采用 DCE RPC 协议来实现许多系统服
务。这两个协议被证明适用于很大范围的应用。但是,在八十年代末期,面向
对象技术的风靡使软件界沉迷于在面向对象语言和基于 RPC 的通信之间建立一
个纽带。
在九十年代产生的对象 RPC (ORPC) 协议正是试图把面向对象和网络协议联系
起来。ORPC 和 RPC 协议的主要不同是 ORPC 代码化了从通信终端到语言级对
象的映射。在每个 ORPC 请求的头中都有一个 cookie,服务器端的程序能用它
来定位在服务器进程中的目标对象。通常这个 cookie 只是一个对数组的索引,
但其它技术也经常被使用,如用符号名作为 Hash 表的键。
图 1 ORPC 请求与响应
图 1 表示一个典型的 ORPC 请求和响应。有几个请求头组件被服务器端的处理
程序用于分发调用。对象端点 ID 被用于定位在服务器进程中目标对象。接口标
识符和方法标识符用于决定在目标对象中哪一个方法被调用。传输体用于传递
请求中的[in]和[in,out]参数的值(在响应中是[out]和[in,out])。要注意的是任选
的协议扩展可以出现在头文件和传输体之间。这是在协议设计中的惯例,因为
它允许新的服务搭载在 ORPC 的请求和服务上。大多数 ORPC 系统用这个区域
传递附加的上下文信息(如事务信息和因果关系标识符)。
目前两个主要的 OPRC 协议是 DCOM 和 CORBA 的 Internet Inter-ORB Protocol
(IIOP) 或更一般的 General Inter-ORB Protocol (GIOP)。DCOM 和 IIOP/GIOP 的
请求格式非常相似。两个协议都用一个对象端点 ID 来确定目标对象,用方法标
识符来决定调用哪个方法。
这两个协议主要有两点不同:主要的一点不同是采用 IIOP/GIOP 时,接口标识
符是隐含的,因为一个给定的 CORBA 对象只实现一个接口(尽管 OMG 当前
正在进行每个对象有多个接口支持的标准化工作)。DCOM 与 IIOP/GIOP 请求
的另一个细微差别是在传输体中参数值的格式。在 DCOM 中,传输体用网络数
据表达(NDR)的格式来写,在 IIOP/GIOP 中,传输体用公共数据表达
(CDR)的格式来写。NDR 和 CDR 分别处理在各种平台上的不同的数据表
达。但是在这两种格式之间有一些小的差别,这使它们相互之间并不兼容。
在 ORPC 与 RPC 协议之间的另一个重要的不同是通信端点的命名方式。在
ORPC 协议中,对于 ORPC 端点的一些可传递的表达方式被要求在网络之间传
递对象引用。在 CORBA/IIOP,这个表达方式被称为可交互的对象引用
(IOR)。IORs 包含用紧凑格式表达的寻址信息,使用了它任何 CORBA 产品
都可以决定一个对象端点。在 DCOM 中,这种表达方式被称为 OBJREF,它组
合了分布的引用计算和端点/对象标识。CORBA 和 DCOM 都提供了在网络上寻
找对象端点的高级机制,但最终这些机制都映射回到了 IORs 或 OBJREFs。图 3
是表示一个 IOR/OBJREF 怎样与在 IIOP/DCOM 请求消息中的寻址信息关联起
来的。
目前的技术存在的问题?
尽管 DCOM 和 IIOP 都是固定的协议,业界还没有完全转向其中任何一个协
议。没有融合的部分原因是文化的问题所致。而且在当一些组织试图标准化一
个或另一个协议的时候,两个协议的技术适用性就被提出质疑。传统上认为
DCOM 和 CORBA 都是合理服务器到服务器端的通信协议。但是,二者对客户
到服务器端的通信都存在明显的弱点,尤其是客户机被散布在 Internet 上的时
候。
DCOM 和 CORBA/IIOP 都是依赖于单个厂商的解决方案来最大优势地使用协
议。尽管两个协议都在各种平台和产品上被实现了,但现实是选定的发布需要
采用单一厂商的实现。在 DCOM 的情况下,这意味着每个机器要运行在
Windows NT。(尽管 DCOM 已经被转移到其它平台,但它只在 Windows?上获
得了广泛的延伸)。在 CORBA 情况下,这意味着每个机器要运行同样的 ORB
产品。的确让两个 CORBA 产品用 IIOP 相互调用是有可能的,但是许多高级的
服务(如安全和事务)此时通常不是可交互的。而且,任何专门厂商为同样的
机器的通信所作的优化很难起作用,除非所有的应用被建立在同一个 ORB 产品
上。
DCOM 和 CORBA/IIOP 都依赖于周密管理的环境。两个任意的计算机使得
DCOM 或 IIOP 在环境之外被成功调用(calls out of the box)的几率是很低的。
特别是在考虑安全性的时候尤其是这样。尽管写一个能成功地运用 DCOM 或
IIOP 的紧缩包(shrink-wrap)应用是可能的,但这样做要比基于 socket 的应用
要更多地关注细节。这对于乏味但必需的配置和安装管理任务特别适用。
DCOM 和 CORBA/IIOP 都依赖于相当高技术的运行环境。尽管进程内的 COM
似乎特别简单,但 COM/DCOM 远程处理程序绝对不只是几天就解决的事情。
IIOP 是一个比 DCOM 更容易实现的协议,但两个协议都有相当多的深奥的规
则来处理数据排列、类型信息和位操作。这使得一般的程序员在没有领会 ORB
产品或 OLE32.DLL 的情况下去构造一个简单的 CORBA 或 DCOM 调用也变得
很困难。
也许对 DCOM 和 CORBA/IIOP 来说,最令人难以忍受的一点是它们不能在
Internet 上发挥作用。对 DCOM 来说,一般用户的 iMac 或廉价的运行 Windows
95 的 PC 兼容机要想使用你的服务器执行基于领域认证几乎是不可能的。更糟
的是,如果防火墙或代理服务器分隔开了客户和服务器的机器,任何 IIOP 或
DCOM 包要通过的可能性是很低的,主要是由于大多数 Internet 连接技术对
HTTP 协议的偏爱所致。尽管一些厂商如 Microsoft, Iona 和 Visigenic 都已经建
立了通道技术,但这些产品很容易对配置错误敏感而且它们是不可交互的。
在一个服务器群落中这些问题并不能影响 DCOM 或 IIOP 的使用。因为在服务
器群落中主机的数量很少(一般是成百上千,而不是成千上万),这就抵消了
DCOM 基于 ping 的生命周期管理的成本。在服务器群落中,所有主机被一个公
共管理域管理的机率很大,使得统一的配置变得可能。相对少量的机器也能保
持商业 ORB 产品可控制使用的成本,因为只需要更少量的 ORB 许可权。如果
只有 IIOP 在服务器群落中被使用,就只需要少量的 ORB 许可权。最后,在服
务器群落中所有主机有直接的 IP 连接也是可能的,这就消除了与防火墙相关的
DCOM 和 IIOP 问题。
HTTP 作为一个更好的 RPC
在服务器群落中使用 DCOM 和 CORBA 是通用的做法,但客户机则使用 HTTP
进入服务器群落。HTTP 与 RPC 的协议很相似,它简单、配置广泛,并且对防
火墙比其它协议更容易发挥作用。HTTP 请求一般由 Web 服务器软件(如 IIS
和 Apache)来处理,但越来越多的应用服务器产品正在支持 HTTP 作为除
DCOM 和 IIOP 外的又一个协议。
象 DCOM 和 IIOP 一样,HTTP 层通过 TCP/IP 进行请求/响应通信。一个 HTTP
的客户端用 TCP 连接到 HTTP 服务器。在 HTTP 中使用的标准端口号是 80,但
任何其它端口也能被使用。在建立 TCP 连接后,客户端可以发送一个请求消息
到服务器端。服务器在处理请求后发回一个 HTTP 响应消息到客户端。请求和
响应消息都可以包含任意的传输体的信息,通常用 Content-Length 和 Content-
Type 的 HTTP 头来标记。下面是一个合法的 HTTP 请求消息:
POST /foobar HTTP/1.1
Host: 209.110.197.12
Content-Type: text/plain
Content-Length: 12
Hello, World
你可能已经注意到 HTTP 头只是一般文本。这使得用包检查程序或基于文本的
Internet 工具(如 telnet)来诊断 HTTP 问题变得更容易。HTTP 基于文本的属性
也使得 HTTP 更容易适用于在 Web 开发中流行的低技术水平的编程环境。
HTTP 请求的第一行包含三个组件:HTTP 方法,请求-URI,协议版本。在前面
的例子中,这些分别对应于 POST, /foobar, 和
HTTP/1.1。Internet 工程任务组
(IETF)已经标准化了数量固定的 HTTP 方法。GET 是 HTTP 用来访问 Web 的方
法。 POST 是建立应用程序的最常用的 HTTP 方法。和 GET 不一样,POST 允
许任意数据从客户端发送到服务器端。请求 URI (Uniform Resource Identifier)是
一个 HTTP 服务器端软件,它用来识别请求的目标的简单的标识符(它更象一
个 IIOP/GIOP object_key 或一个 DCOM IPID)。关于 URIs 更多的信息请参照
"URIs, URLs, and URNs"。在这个例子中协议的版本是 HTTP/1.1, 它表示遵守
RFC 2616 的规则。HTTP/1.1 比 HTTP/1.0 多增加了几个特性,包括对大块数据
传输的支持以及对在几个 HTTP 请求之间保持 TCP 连接的支持。
请求的第三行和第四行指定了请求体的尺寸和类型。Content-Length 头指定了体
信息的比特数。Content-Type 类型标识符指定 MIME 类型为体信息的语法。
HTTP (象 DCE 一样) 允许服务器和客户端协商用于编制信息的传输语法。大多
数 DCE 应用采用 NDR.。大多数 Web 应用采用 text/html 或其它基于文本的语
法。
注意在上面样例中 Content-Length 头与请求体之间的空行。不同的 HTTP 头被
carriage-return/行码序列划定界限。这些头与体之间用另外的 carriage-return/行
码序列来划定界限。请求接着包括原始字节,这些字节的语法和长度由
Content-Length 和 Content-Type HTTP 头来识别。在这个例子中,内容是十二字
节的普通文本字符串"Hello, World"。
在处理了请求之后,HTTP 服务器被期望发回一个 HTTP
响应到客户端。响应
必须包括一个状态代码来表示请求的结果。响应也可以包含任意的体信息。下
面是一个 HTTP 响应消息:
200 OK
剩余17页未读,继续阅读
资源评论
- 爱吃鱼的莞尔猫2013-03-26很好,很适合我
cwfreebird
- 粉丝: 9
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功