在电影fight club（“战争俱乐部”）中，brad pitt和edward norton是一对密友？？心理上对立的两个极端？？两个小伙子尝试互相 通信，但十分艰难。令人感兴趣的是？？没有给出提示台词？？影片中 的大部分剧情都围绕着肥皂的生产进行，看上去像是把多个角色以独一 无二的、令人意想不到的方式绑在了一起。
现在快进到一种不同类型的剧情，microsoft和sun这两个软件密友 在internet也出演了这段剧情，他们每一方都用经过良好定义的视点， 试图弥合彼此间的差异，并与另一方之间建立一条通信线路。进入soap ，即简单对象访问协议。
简介SOAP，简单地讲，就是允许Java对象和COM对象在分布式、分散的、 基于Web的环境中彼此通话。更一般地讲，SOAP允许任何类型的对象（或 代码）？？在任何平台上，以任何一种语言？？相互通信。目前，已在2 0多个平台上，以60多种语言实现了SOAP.突然之间，任何地方的对象， 无论本地或远程的，无论大或小，都可以互操作。Brad Pitt和Edward Norton，就像两种截然不同的对象，最终能够通信。
回顾一下这种技术，我最开始将在web服务的大环境下介绍soap， soap作为一种协议，它与uddi（通用描述、发现和集成）一起提供了业 务间注册和消息传递服务。我还将讨论揭示“发布-查找-绑定”范例的 基于web的基础，并介绍soap包装、传输和发送机制。
web服务的发展先把所有大肆张扬的宣传放在一边，SOAP仅仅只是一种组件？？虽然 是一种中心组件？？用于把Web的蓝图描述成用于业务操作的、基于标准 的、语言与平台中性的架构。这些业务操作通常被标上了“Web 服务” 的通用标签，但是Web服务自身也只是一种支持它们的良好的基础。相应 地，Internet有一种快捷的n层基础。
网络分层在Web服务的发展过程中，有3种网络层是显而易见的：TCP/IP、 HTTP/HTML和XML.现在这3个层相继构建在彼此的顶上，并保持相互之间 的兼容性。
第1层，tcp/ip协议，主要关注的是以分组形式通过线缆传输数据。 作为一种确保通过公共网络传输的协议，tcp/ip强调数据传输的可靠性 和物理连通性。起初是把专用网络粘合在一起，现在则是用web中枢协议 来连接网络，更高层次的标准协议如http就是依赖于这种中枢协议的。
第2层，http上的html，它是一个显示层，自身关注的是基于浏览器 的搜索、检索和信息共享。它强调的是基于gui（图形用户界面）的导航 和显示格式的处理。在许多方面，html更多地是用于显示，而不是转到 别的网页上，并且在可扩展性和真正的编程能力上有所欠缺。虽然如此， 在浏览器环境中共享超文本链接的文档使人们用基于文本的信息与他人 通信的方式引发了革命。网络桌面环境，受专用操作系统和依赖于平台 的软件所限，速度缓慢，毫无疑问会让路于基于标准的，对系统开放的 internet.
把这种责任引导到这个勇敢的、新的、基于标准的世界的是xml，它 是internet的第3层，也可能是最引人注目的一层。xml，一种强类型数 据交换格式，它为http/html层提供了一个新范围。在xml层中，机器到 机器的通信有可能通过标准接口来进行。xml层？？有多种不同的描述， 如a2a（应用程序到应用程序）、b2b（业务到业务）、或c2c（计算机到 计算机）？？允许程序在平台上交换数据格式？？和显示？？独立于编 程的方式。xslt样式表可以作为一种可选用的显示和/或可传输的组件予 以添加。
xml：描述web服务的关键把这种可能变为现实的关键是实现机器到机器的通信，这是XML力所 能及的。作为一种描述数据的词法，XML是定义驱动的（通过使用DTD和 架构），并允许以编程方式处理信息。这意味着大多数可考虑到的工作 都可以从B2B通信中取出来。可以有一致的标记，可以定义接口，处理也 可以是标准化的。Web服务是可重用的组件程序，它们把XML用作一种标 准的、可扩展的通信架构，以方便机器到机器类型的通信。
web服务为通过http传输的组件数据和业务逻辑提供接口。大量的数 据被放置在服务器端脚本后面的一个传统的位置，等待着被web浏览器或 客户程序访问。web服务承诺使许多企业领域的、处于闲置状态的公司软 件资源获得新生。
在把驻留于web中的数据集成到企业应用程序中和协调用于组件片固 定的业务逻辑方面，xml起了至关重要的作用。特定的业务逻辑和服务 （包括工作流程逻辑、业务逻辑、组件序列逻辑、交易逻辑等）可以封 装在xml文档中，并集成到现有的业务环境中去。这允许业务在内部资源 和web服务之间，简化业务交易逻辑和通过web提供链条式交互之间起到 杠杆作用。
由于xml是人们可阅读的和基于文本的，使之可理想地用作传输松耦 合的web服务的架构。最低限度是：自动化的交易可提高生产率、减少费 用和改善服务。网络标准的存在使自动化交易成为可能、使所有成员的 生产率都能得到提高。
soap是一种源于更早的基于xml标准的技术，早期xml标准在某种意义 是指一种称为 ebxml（电子商务xml）的显示标准。ebxml具有一种依次进行的连续 逻辑，它在贸易合作者间提供了一种共享业务消息的综合定义。soap适用 的范围更普遍，也更容易实现。
松耦合的系统Web服务把对象从管理它们的平台上分离开来，也就是说，Web服务使 独立于平台的对象之间的交互更容易，对象可以访问Web上任何地方的数 据。作为脱离专用平台的一部分，Web服务依赖于松散而不是紧密耦合的 Web组件。根据Brian Travis（SOAP顾问和作者）的观点，“依赖于专用 对象的系统被认为是耦合紧密的，因为它们依赖一种定义良好但很脆弱 的接口。如果应用程序与服务对象间通信的任何部分被打断，或者如果 调用不完全正确，将会发生不可预料的结果。”EDI就是一个用于执行电 子商务的耦合紧密的架构的例子。松耦合的系统允许在开放的、分布式 Web环境中进行灵活的和动态的交换。
corba第二次降临网络上的公司？？IBM、BEA、Sun，仅举几个例子？？同时在与他们 竞争的公司合作。标准化的网络传输协议，独立于平台的编程语言如： Java、XML和特定行业的专业用语，及开放的基于组件的服务器体系结构 使每个人都能免费享用非专用的资源。现在，Web服务，带着其对包含广 泛的应用程序互操作性的承诺，就像一种最终的“胶水”，使这些技术 交互作用，即使不是无缝的，至少也不会超过以前技术如CORBA和RMI所 带来的累赘。
在某种意义上，web服务代表着corba的第二次降临。但是corba是一 种面向对象的、基于iiop的二进制通信架构，是由基础、骨架和特定于 供应商的orb装载而成的；而web服务则是轻型的、基于http的、xml驱动 的及平台和语言完全中性的。如果说corba是一只重达600磅的大猩猩， 那么web服务就是一只小羚羊，在辽阔的internet禁区里自由地蹦跳。
发布、绑定和查找Web服务的架构由发布-查找-绑定这个周而复始的循环组成，它通过 服务提供程序使数据、内容和服务能为注册的服务请求者所用，服务请 求者通过定位和绑定到服务来使用资源。请求应用程序使用 WSDL（Web服务描述语言）把请求者转到Web服务上。WSDL为想要的 服务提供了一种低层次的技术信息，并授权访问关于数据编码的XML架构 信息、及通过正确的协议确保调用正确的操作。
发布、绑定和查找机制，在3个独立（但有些等同）的协议中有它们 各自的副本，这3个协议是wsdl、soap和uddi（通用描述和发现接口）， 它们组成了web服务网络栈。
对corba作更深层次的类推可以发现，soap起到了corba中iiop（或rmi 中的jrmp）的作用。它是对立的端点间的绑定机制。另一方面，wsdl起 到了idl（接口描述语言）的作用。在这种功能上，wsdl把web服务定义 成端口和操作的集合。wsdl端口是模拟接口的，而wsdl操作则是模拟方 法的。wsdl 把web服务接口发布给那些对跨越不同平台通信感兴趣的各 方。
但是，wsdl已经超越了一种接口定义语言；它还包含允许给想发布的 web服务描述地址和协议信息的构造。关于wsdl的令人感兴趣的事情是它 为web服务描述了一个抽象接口，同时还允许您？？以难以忍受的细节 ？？绑定web服务给特定的传输机制，如http.通过使接口抽象化，wsdl 可用作一种可重用的web服务技术。通过绑定到特定的传输机制，wsdl生 成了抽象的类聚。如果这看上去有些自相矛盾，可以想一下航天飞机： 它是可重复使用的、但要把全机能太空舱完全绑定到专用的、但不可重 复使用的助力器火箭上。传输机制可能会改变，但有效载荷会保留下来 .
最后，uddi是用于注册发布和查找web服务的。在基于web的注册中， 通过显示服务信息和绑定接口，uddk为业务和客户提供了一个共享目录 以查找别人的web服务。
构建web服务SOAP可通过远程调用对象上的方法，让您构建应用程序。SOAP消除 了两种系统必须运行于同一平台上、且必须是用同一种编程语言编写而 成的要求。SOAP包不是通过专用的二进制协议调用方法，而是使用XML 这种基本文本的词法来调用方法。请求应用程序与接收对象之间的所有 信息，是作为XML流中的标记数据通过HTTP发送的。从Web服务的角度来 看，SOAP可以看作一种客户端或服务器实现。
soap客户端和服务器SOAP客户端是一种创建XML文档的程序，该XML文档包含在分布式系 统远程调用方法所需的信息。SOAP客户端不是传统意义上的程序，它除 了用作普通的桌面应用程序外，还可以是一种Web服务器或基于服务器 的应用程序。
来自soap客户端的消息和请求一般是通过http发送的。因而，soap 文档可以穿过几乎所有的防火墙，从而能跨越不同的平台交换信息。
soap服务器只是用于监听soap消息的特殊代码，它可用作soap文档的 分配器和解释器。外部web服务可以与基于j2ee技术的应用程序服务器交 互，这种应用程序服务器可以处理多种客户端的soap请求。
soap服务器确保通过http连接接收的文档被转换成可以被另一端对 象理解的语言。由于所有的通信都采用xml格式，某种语言（比如说 java）中的对象可以通过soap与另一种语言（如c++）中的对象通信。 soap服务器的工作就是确保各端都能理解？？并且满意？？为它们提供 服务的soap.
soap和java技术根据SOAP 1.1规范，SOAP是“一种用于在分散的、分布式环境中交换 信息的轻型协议”。SOAP不会委托单一的编程模型？？也不会为特定的 编程语言定义语言绑定。在Java编程语言环境中，它取决于Java团队来 定义特定的语言绑定。现在Java语言绑定通过JAX-RPC来集中定义。
在最近的javaone开发人员讨论会上对soap的讨论中，sun公司的工程 师roberto chinnici和rahul sharma把jax技术家庭的作用定义成“使用 熟悉的、用于java平台的jsp和ejb组件技术创建web服务”。servlets 和无状态会话bean被引用作两种最可能用于封装web服务的java技术。
什么是soap？真的吗？
我们已经彻底设置好了SOAP舞台，并描述了其在Web服务中至关重要的作用， 现在进一步看看SOAP到底是什么，它执行什么任务，以及是怎样执行的？
soap是一种可扩展的、基于文本的架构，它允许在不同角色之间通信，这里的 角色一般是指对象，它们先前并不了解对方或对方所在的平台。从网络对象的角 度来看，soap是它们的最后不可见形式。客户端应用程序可以在松耦合的环境中 互操作，以发现和动态地连接到服务，而这并不需要事先在应用程序与服务之间 建立一种协定。
soap是可扩展的，这是因为无需中断已有的应用程序，soap客户端、服务器和 协议自身都能发展。而且soap能极好地支持中间介质和层次化的体系结构。这意 味着处理节点可以把请求的路径置于客户端与服务器之外。中间节点通过使用报 头（用于标识哪个节点处理哪部分消息）来处理soap指定的各部分消息。这种类 型的中间报头处理是通过客户端应用程序与中间处理节点之间的私人契约来执行 的。soap为报头提供了一个mustunderstand属性，它允许客户端将 处理指定为是必须执行的还是可选的。如果mustunderstand被设置 为1，服务器必须执行报头指定的中间处理或给出错误。
soap还定义了数据编码规则，称为基准编码或“section 5（第5节）”编码， 它是出自soap规范中描述数据编码规则的那一节内容。应当指出soap编码的内容 占了soap 1.1规范40页中的大部分篇幅。不必深入到xml数据类型细节？？它仍然 是xml架构制定组的专家们研究的范畴？？soap编码可以简短地描述成简单值或复 合值的集合。
简单值可以是简单类型，如整型、浮点型和字符型，或者是xml架构规范第2部 中定义的内置类型，包括各种数据类型，如字节型数组和枚举。
复合值包括结构、数组和xml架构制定组定义的复杂类型。最后，当然不是至 少，soap数据编码指定了对象序列化规则，即通过网络排列和分散数据流的机制。 这些“section 5”编码在任何情况下都不是强制性的，注意这点很重要，这样客 户端和服务器可以自由地使用不同的数据编码规范，只要它们符合格式就行。但 是这样做的话，就会毁灭soap在网络上提供标准化服务所起的推动作用，并且会 带来一个常见的警告：已偏离航线太远，单独的客户端和服务器可以选择较短的 旅行路线。
最后，soap建立了一组规则，它允许客户端和服务器把soap用作一种通信架构 来执行远程过程调用。soap？？作为一种面向消息的协议？？可以使用这些规范 像rpc类型的型一样良好地工作。对象序列化的机制给soap-rpc提供了活力。
消息格式SOAP在标准化消息格式环境中，可以做所有它能完成的工作。消息的主体部分 是“text/xml”形式的MIME类型，并且包含一个SOAP封套。该封套是一个XML文 档。封套包含了报头（可选的）和报文（必须有的）。封套的报文部分总是用于 最终接收的消息，而报头项目可以确定执行中间处理的目标节点。附件、二进制 数字及其他项目可以附加到报文上。