soap服务器是什么

1. soap是什么牌子，

SOAP
求助编辑网络名片
SOAP：简单对象访问协议，简单对象访问协议（SOAP）是一种轻量的、简单的、基于 XML 的协议，它被设计成在 WEB 上交换结构化的和固化的信息。 SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（ HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。

目录

简介四个部分
协议结构
语法规则
SOAP 核心技术
SOAP 的优点
php SOAP实例
消息格式
剖析SOAP封套
SOAP-RPC
SOAP用例
小结简介 四个部分
协议结构
语法规则
SOAP 核心技术
SOAP 的优点
PHP SOAP实例
消息格式
剖析SOAP封套
SOAP-RPC
SOAP用例小结展开 编辑本段简介
简单对象访问协议含义 这里之所以说是简单，是因为它是基于已经广泛使用的两个协议：HTTP和XML，所以业界把这种技术称为“它是第一个没有发明任何新技术的技术"，之所以说是对象，是因为把访问的Web服务称为对象，既然服务是对象，那么服务肯定有相关的属性和调用行为，这些属含拿性和行为是通过WSDL来描述的。如果按“简单的对象访问协议”来理解，相比“简单对象访问协议”要容易些。
四个部分
soap。n.(英文)肥皂 SOAP：简单对象访问协议 （SOAP：Simple Object Access Protocol） SOAP 包括四个部分： SOAP 封装：它定义了一个框架 , 该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。 SOAP 编码规则：它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。 SOAP RPC 表示：它定义了用于表示远程过程调用和应答的协定。 SOAP 绑定：定义了一种使用底层传输协议来完成在节点间交换SOAP封装的约定。 SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求 / 应答的模式。所有的 SOAP 消息都使用 XML 编码。一条 SOAP 消息就是一个包含有一个必需的 SOAP 的封装包，一个可选的 SOAP 标头和一个必需的 SOAP 体块的 XML 文档。 把 SOAP 绑定到 HTTP 提供了同时利用 SOAP 的样式和分散的灵活性的特点以及 HTTP 的丰富的特征库的优点。在HTTP上传送 SOAP 并不是说 SOAP 会覆盖现有的 HTTP 语义，而是 HTTP 上的 SOAP 语义会自然的映射到 HTTP 语义。在使用 HTTP 作为协议绑定的场合中， RPC 请求映射到 HTTP 请求上，而 RPC 应答映射到 HTTP 应答。然而亏老晌，在 RPC 上使用 SOAP 并不仅限于 HTTP 协议绑定。 SOAP也可以绑定到TCP和UDP协议上。
协议结构
SOAP 消息格式： SOAP 标头 <SOAP-ENV: Envelope Attributes> <SOAP-ENV:Body Attributes> </SOAP-ENV:Body> </SOAP-ENV:Envelope>目前主要在web服务中运用。
编辑本段语法规则
这里是一些重要的语法规则： SOAP 消息必须用 XML 来编码 SOAP 消息必须使用 SOAP Envelope 命名空间 SOAP 消息必须使用 SOAP Encoding 命名空间 SOAP 消息不能包含 DTD 引用 SOAP 消息不能包含 XML 处理指令
编辑本段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不需要具体的对象绑定到一个给定的终端, 而是由具体实现程序来决定怎样把对象终端标识符映像到服务器端的对象。
编辑本段SOAP 的优点
(1) SOAP 是可扩展的。SOAP 无需中断已有的应用程序, SOAP 客户端、 服务器和协议自身都能发展。 而且SOAP 能极好地支持中间介质和层次化的体系结构。 (2) SOAP 是简单的。客户端发送一个请求,调用相应的对象, 然后服务器返回结果。这些消息是XML 格式的,并且封装成符合HTTP 协议的消息。因此,它符合任何路由器、 防火墙或代理服务器的要求。 (3) SOAP 是完全和厂商无关。SOAP可以相对于平台、 操作系统、 目标模型和编程语言独立实现。另 外,传输和语言绑定以及数据编码的参数选择都是由具体的实现决定的。 (4) SOAP 与编程语言无关。SOAP 可以使用任何语言来完成, 只要客户端发送正确SOAP 请求( 也就 是说, 传递一个合适的参数给一个实际的远端服务器)。SOAP 没有对象模型, 应用程序可以捆绑在任何 对象模型中。 (5) SOAP 与平台无关。SOAP 可以在任何操作系统中无需改动正百分比法办法常运行。
编辑本段PHP SOAP实例
php提供了一个专门用于soap操作的扩展库，使用该扩展库后 可以直接在php中进行soap操作。下面将介绍soap的基本操作。 一、soap扩展的使用方法 php的soap扩展库通过soap协议实现了客服端与服务器端的 数据交互操作。从php5.0后，php就自带了soap的支持。使用 soap扩展库首先需要修改php安装目录下的配置文件php.ini 来激活soap扩展库。 在php.ini文件中找到如下所示的一行代码，去掉前面的注释(;)。 ;extension=php_soap.dll 修改后，重启web服务器即可激活soap扩展。在soap扩展库中，主要 包括三种对象。 1、SoapServer SoapServer用于创建php服务器端页面时定义可被调用的函数及返回 响应数据。创建一个SoapServer对象的语法格式如下: $soap = new SoapServer($wsdl,$array); 其中，$wsdl为soap使用得wsdl文件，wsdl是描述Web Service的一种 标准格式，若将$wsdl设置为null，则表示不使用wsdl模式。$array是 SoapServer的属性信息，是一个数组。 SoapServer对象的addFunction方法是用来声明哪个函数可以被客户端调用， 语法格式如下： $soap->addFunction($function_name); 其中，$soap是一个SoapServer对象，$function_name是需要被调用的函数名。 SoapServer对象的handle方法用来处理用户输入并调用相应的函数，最后返回 给客户端处理的结果。语法格式如下: $soap->handle([$soap_request]); 其中，$soap是一个SoapServer对象,$soap_request是一个可选参数，用来表示 用户的请求信息。如果不指定$soap_request，则表示服务器将接收用户的全部 请求。 2、SoapClient SoapClient用于调用远程服务器上的SoapServer页面，并实现了对相应函数的调用 。创建一个SoapClient对象的语法格式如下: $soap = new SoapClient($wsdl,$array); 其中，参数$wsdl和$array与SoapServer相同。 创建SoapClient对象后，调用服务端页面中的函数相当于调用了SoapClient的方法， 创建语法如下: $soap->user_function($params); 其中，$soap是一个SoapClient对象，user_function是服务器端要调用的函数，$params 是要传入函数的参数。 3、SoapFault SoapFault用于生成soap访问过程中可能出现的错误。创建一个soapFault对象的语法格式 如下： $fault = new SoapFault($faultcode,$faultstring); 其中，$faultcode是用户定义的错误代码，$faultstring是用户自定义的错误信息。soapFault 对象会在服务器端页面出现错误时自动生成，或者通过用户自行创建SoapFault对象时生成。对于 Soap访问时出现的错误，客户端可通过捕捉SoapFalut对象来获得相应的错误信息。 在客户端捕获SoapFault对象后，可以通过下面的代码获得错误代码和错误信息。 $fault->faultcode;//错误代码 $fault->faultstring;//错误信息 其中，$fault是在前面创建的SoapFault对象。 已删除无关的内容。
编辑本段消息格式
SOAP在标准化消息格式环境中，可以做所有它能完成的工作。消息的主体部分 是“text/xml”形式的MIME类型，并且包含一个SOAP封套。该封套是一个XML文 档。封套包含了 报头（可选的）和报文（必须有的）。封套的报文部分总是用于 最终接收的消息，而报头项目可以确定执行中间处理的目标节点。附件、二进制 数字及其他项目可以附加到报文上。 SOAP提供了一种让客户端指定哪个中间处理节点必须处理报头项目的方法。由 于报头与SOAP消息的主体内容是互不相关的，所以可用它们给消息添加信息，而 不会影响对消息报文的处理。 例如，报头可用于为报文中包含的请求提供数字签名。在这种情形下，身份验 证/授权服务器可以处理报头项目独立于报文可以剥离信息以验证签名。 一旦通过验证，封套的其余部分将被传递给SOAP服务器，它将对消息的报文进行 处理。深入研究一下SOAP封套，有助于明了SOAP报头和报文元素的位置和用途。
编辑本段剖析SOAP封套
SOAP 1.1规范提供了下面的封套示例：SOAP-ENV:mustUnderstand="1" 5DEF 在这个例子中，GetLastTradePrice请求被传送给网络上某个位置的一个存储 -引用服务。 该请求带有一个字符型参数，一个订单符号，并在SOAP响应中返回一 个浮点数。SOAP封套是表示SOAP消息的XML文档的顶层元素。XML命名空间用于将SOAP标识 符与应用程序的特定标识符区分开。XML命名空间在SOAP中使用很频繁，以把消息 的元素的作用域限制在一个特定的领域。理解SOAP命名空间有助于熟悉XML命名空 间规范。如果您没有理解命名空间，也可以简单地把它看作一种邻近的标识符， 它通过把SOAP元素与特定的位置（真实的或想象的）相关联，从而有助于惟一地 标识SOAP元素。 命名空间 上面例子中的第一个命名空间参照了在SOAP消息中定义元素和属性的SOAP模式。 第二个命名空间参照了SOAP编码，即前文中讨论过的“Section 5”数据类型。 由于没有指定额外的通用元素编码，这种编码将适用于整篇文档。 报头 在SOAP封套报头示例中标识的第一个元素是一个transaction（交易）元素，它 带有一个命名空间属性和一个值为1的mustUnderstand属性。既然mustUnderstand的属性值设为1 ，接受该消息的服务器必须在该transaction节点上执行中间处理。您可以对此 作这样的解释：服务器与客户端事先已就管理该报头元素处理的语义达成了一 致，因而服务器确切地知道要处理的元素的内容，本例中元素的内容是“5”。 如果接收消息的服务器不理解transaction报头的语义，它就会拒绝请求并抛出 一个错误。错误元素是SOAP报文和定义良好的机制的一个特殊部分，用于把错误信 息送回给客户端。 像这样的中间处理节点是SOAP可扩展性的一个例子。客户端在SOAP消息中包含 这样的节点，以在可以处理消息的报文内容前，指示要发生的特殊的处理需要。 要保证向后兼容不能提供这种处理的现有的服务器，只需把mustUnderstand 属性设置为0，它使操作是可选的。除了定义像上例中所示的transaction节点外，SOAP消息还可包含报头项目， 它们用于指定节点执行身份验证处理、加密、状态的永久性、业务逻辑处理等。 报头有助于把SOAP构建成一种可扩展的模态包模型。只需记住报头处理是完全独 立于SOAP消息的报文的。 报文 上面例子中的SOAP报文包含一个XML载荷，我们可以推测RPC没有为我们对其作 详细解释。SOAP不仅是一种模态包模型，它还是一种相当神秘的包模型。没有什么迹象清楚地显示RPC将要开始做什么。我们在报文中所看到的是几个 XML元素，其中一个用命名空间进行了限制。它取决于SOAP服务器理解文档语义并 执行正确的处理。事实上，服务器提供了一种架构，以有意义的方式处理XML载 荷。这里的“有意义”意味着服务器在某些后台数据库上调用远程过程，以为消 息报文中包含的股票-符号元素接收股票价格。所有这些魔术般的操作都是在SOAP RPC幕后发生的。
编辑本段SOAP-RPC
SOAP消息本质上是一种从发送方到接收方的单向传输，但是SOAP经常组合到实 现请求/响应机制中。要让RPC使用SOAP，必须遵循几条规则。首先，请求和响应 消息必须被编码成结构类型。对一个操作的每一个输入参数，都必须有一个同名 元素（或输入结构的成员）作为参数。对每一个输出参数，都必须有一个名称匹 配的元素（或输出结构的成员）。 基于RPC的观点，会省略一些更早一点显示的SOAP消息。只带有报文部分的 SOAP请求与响应封套如下所示： 请求 DEF响应 22.50请求要调用GetLastTradePrice方法。注意响应定义了 GetLastTradePriceResponse操作。对附加响应到响应操作尾部的 一个常用的SOAP调用规则是：创建响应结构。这种输出结构包含一个名称为 price的元素，它返回方法调用的结果，假定为浮点型。 在SOAP封套中没有什么地方的数据类型是显式声明的，注意到这一点很重要， 这样如果只查看SOAP消息，就不会知道符号类型或结果参数price（价格）的类 型。客户端应用程序一般通过“Section 5”编码定义数据类型，或通过与服务器 私下达成的协议来定义数据类型。在任何一种情况下，这些包含在SOAP消息中的 定义都不是显式的。 最后，为了进行RPC，需要一种低级协议如HTTP。尽管SOAP 1.0规范强制要求 使用HTTP作为传输协议，但SOAP 1.1规范（及其姊妹规范“带有附件的SOAP消息” ）允许使用FTP、SMTP、甚至（可能）原始的TCP/IP套接字。所有这些对SOAP通用 的序列化和编码规则，也适用于RPC参数。
编辑本段SOAP用例
Internet上某些地方的客户端应用程序使用Web服务。 Web服务（通过SOAP）显示对象方法。 对象方法访问Web上任意位置的远程数据。 对这些网络命题应用传递逻辑，我们可以为Web服务和SOAP下一个总的结论： 某些位置的客户端可以使Web上任意位置的数据。这就是所要证明的。 下面是更加详细一点的用例。 SOAP客户端使用UDDI注册来查找Web服务。不用直接操作WSDL，大多数情况下SOAP应用程序将硬连接到使用特定类型的端口和特定样式的绑定，并且它将 通过UDDI动态配置要调用的、与发现的Web服务匹配的服务地址。 客户端应用程序创建SOAP消息，它是一个可执行想要的请求/响应操作的 XML文档。 客户端把SOAP消息传送给监听SOAP请求的Web服务器上的JSP或ASP页面。 SOAP服务器解析SOAP包并在其领域调用合适的对象方法，在SOAP文档中包 含的参数中传递。在SOAP服务器接收消息之前，中间处理节点可以执行SOAP报 头指示的特殊功能，可视情况确定是否执行这步操作。 请求对象执行指示的功能，并返回数据给SOAP服务器，它把响应打包到 SOAP封套中。服务器把SOAP封套包裹在要发送回请求机器的响应对象中，如 servlet或COM对象。 客户端接收对象，剥离出SOAP封套并把响应文档发送给最初发出请求的程 序，完成请求/响应循环。
编辑本段小结
SOAP是一种基于XML的协议，它用于在分布式环境中发送消息，并执行远程过 程调用。使用SOAP，不用考虑任何特定的传输协议（尽管通常选用HTTP协议）， 就能使数据序列化。用SOAP来构建平台与语言中性的互操作系统是一个好的选择。总之，SOAP和 Web服务已为在XML上构建分布式应用程序基础结构所需的一切都考虑好了。通过解决COM和java组件对象模型之间的冲突，SOAP把多个平台在访问数据时所出现的 不兼容性问题减至最少。先把这些讨论放在一边，SOAP是一种适用于所有类型的对象实体的理想的媒介 即使对于像Brad Pitt和Edward Norton之类的好莱坞电影角色也可用作 一种通信媒介。就像在电影中一样，期待着这种新技术带来震撼世界的效果。

2. server 中的soap是什么

中文名：简单面向对象访问协议
SOAP 是微软 .net 架构的关键元素，用于未来的因特网应用程序开发。
对于应用程序开发来说，使程序之间进行因特网通信是很重要的。

目前的应用程序通过使用远程过程调用（RPC）在诸如 DCOM 与 CORBA 等对象之间进行通信，但是 HTTP 不是为此设计的。RPC 会产生兼容性以及安全问题；防火墙和代理服务器通常会阻止此类流量。

通过 HTTP 在应用程序间通信是更好的方法，因为 HTTP 得到了所有的因特网浏览器及服务器的支持。SOAP 就是被创造出来完成改昌盯这个任务的。

SOAP 提供了一种标准的方法，使得运行在不同的操作系统并使用不同的技术和编程语言的应用程序可以互相进行通信。

在微软的这项技术中，最核和直接的表现就是webservice，基于跨平台访问。在服务端建立相应的方法，在因特网上进行访问，双方运用xml进行数据交迅岁互

在.net 3.0之后，新的技术逐渐由面向对象编程转向面向服务编程。如WCF,ADO.NET Dataservice等等，都是基于服务，与平台无关的分布式数据访问模式。

3. 初步理解一下：SOA, SOAP, Web Service, WSDL等

什么是SOA、SOAP?

SOA到底是什么？

SOA（Service-Oriented Architecture）的定义是面向服务的架构，就是说将软件按照功能设计成一个个服务，这些服务用标准的方式定义接口、并通过标准的协议进行调用。 SOA所定义的接口和调用方式是独立于编程语言和运行平台的，广义上讲SOA可以基于不同的底层技术实现，比如CORBA和Web Services。但CORBA由于过于复杂和臃肿已很少使用，所以目前所说的SOA绝大多数是基于Web Services技术实现。在Web Services的实现方式下，SOA服务的接口用XML进行定义。

在SOA架构下，软件开发从业务流程分析开始，使用组件化业务建模的方法识别和分析各种业务模型，将各种实践融入其中，在这个基础上建立用例，用例直接产 生BPEL，这些BPEL则可以被融入一个服务整合框架中，其描述了各种服务的信息，从而把ESB上的各个模块统一起来，形成一个巨大的服务仓。

将中间层再进行抽离，在中间层作一个跨技术架构的元数据和业务逻辑，使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产，也就 是面向服务的组件库，而且这个服务组件库也可以被其它企业复用，且不依赖于任何一种技术架构。夸张一点说，如果所有软件企业都使用SOA架构，那么世界软 件业将会发生彻底的改变。显然，这样一个框架不是一种产品，也不仅仅是一种技术，而是一种解决问题的方法论。

SOA可能应用于两个场景：第一种是业务互通互联；第二种是封闭交易系统，即将元数据和业务逻辑抽离，形成可复用。举个例子，在第一种场景中，当不同企业 之间的业务需要相互调用，这时就可能采用SOA技术；在第二种场景中，在企业内部需要将系统进行迁移时，利用SOA技术定义的原有数据和业务流程，可以很 快完成。

SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。SOA的目标在于让IT 变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-Time Enterprise，这是Gartner为SOA描述的愿景目标）。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户 化和人员技能的投入等方面取得了不错的成绩。

SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计 应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可 替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式 而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。

SOA也不仅仅是一种开发的方法论--它还包含管理。例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模 块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理 人员或应用架构师迭代地优化他们的企业业务流程、应用系统。

SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户 的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应 用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基 于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术 所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应 用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。

企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方 法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务 组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。

有利于企业业务的集成传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集 成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。

SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。

不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。

SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。

Soap是什么？

SOAP 是Simple Object Access Protocol（简单对象访问协议）的缩写。

SOAP是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议.

对于Soap的理解：

第一步理解：SOAP＝HTTP＋XML

第二步理解：SOAP把XML的使用代码化为请求和响应参数编码模式，并用HTTP作传输。

SOAP是把成熟的基于HTTP的WEB技术与XML的灵活性和可扩展性组合在了一起。

第三步理解：具体地讲，一个SOAP实现可以简单地看作遵循SOAP编码规则的HTTP请求和响应。

注意：SOAP 是一个协议，与编程语言无关。实际上，许多语言已经开始支持 SOAP，如：Java，C，C＋＋以及JavaScript。

Soap的起源？Soap解决的问题？

SOAP最初由微软发起研究，用以解决MTS/COM资源消耗大，不够轻巧等问题，后逐渐被IBM等巨头接纳并加入研究，现已提交W3C，成为Web Service应用传输标准。SOAP技术主要用于实现大量异构程序和平台之间的互操作性，从而使存在的应用能够被广泛的用户所访问。

SOAP意思是简单对象访问协议（Simple Object Access Protocol）。的确如它的名字一样，SOAP是很简单的。它是一个基于XML的协议，允许程序组件和应用程序彼此使用一种标准的Internet协 议--HTTP来通讯。SOAP是一种独立的平台，它不依赖程序语言，它是简单的，弹性的，很容易扩展的。目前，应用程序能够彼此使用一种基于DCOM和 CORBA技术的远程过程调用（RPC）来进行相互通讯，但HTTP不被设计为这个目的。RPC在Internet上应用是非常困难的，它们会出现许多兼 容性和安全性的问题，因为防火墙和代理服务器通常都会阻断（block）这些类型的流量。应用程序之间最好的通讯方式是通过HTTP协议，因为HTTP是 支持所有Internet浏览器和服务器的。基于这个目的，SOAP协议被创建出来。

SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议，它包括四个部分：SOAP封装(envelop)，封装定义 了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。

虽然这四个部分都作为SOAP的一部分，作为一个整体定义的，但他们在功能上是相交的、彼此独立的。特别的，信封和编码规则是被定义在不同的XML命名空间(namespace)中，这样使得定义更加简单。

什么是CXF？

Apache CXF = Celtix + XFire，Apache CXF 的前身叫 Apache CeltiXfire，现在已经正式更名为 Apache CXF 了，以下简称为 CXF。CXF 继承了 Celtix 和 XFire 两大开源项目的精华，提供了对 JAX-WS 全面的支持，并且提供了多种 Binding 、DataBinding、Transport 以及各种 Format 的支持，并且可以根据实际项目的需要，采用代码优先（Code First）或者 WSDL 优先（WSDL First）来轻松地实现 Web Services 的发布和使用。目前它仍只是 Apache 的一个孵化项目。

Apache CXF 是一个开源的 Services 框架，CXF 帮助您利用 Frontend 编程 API 来构建和开发 Services ，像 JAX-WS 。这些 Services 可以支持多种协议，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，并且可以在多种传输协议上运行，比如：HTTP、JMS 或者 JBI，CXF 大大简化了 Services 的创建，同时它继承了 XFire 传统，一样可以天然地和 Spring 进行无缝集成。

CXF 包含了大量的功能特性，但是主要集中在以下几个方面：

支持 Web Services 标准：CXF 支持多种 Web Services 标准，包含 SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging 和 WS-Security。

Frontends：CXF 支持多种“Frontend”编程模型，CXF 实现了 JAX-WS API （遵循 JAX-WS 2.0 TCK 版本），它也包含一个“simple frontend”允许客户端和 EndPoint 的创建，而不需要 Annotation 注解。CXF 既支持 WSDL 优先开发，也支持从 Java 的代码优先开发模式。

容易 使用： CXF 设计得更加直观与容易使用。有大量简单的 API 用来快速地构建代码优先的 Services，各种 Maven 的插件也使集成更加容易，支持 JAX-WS API ，支持 Spring 2.0 更加简化的 XML 配置方式，等等。

支持二进制和遗留协议：CXF 的设计是一种可插拨的架构，既可以支持 XML ，也可以支持非 XML 的类型绑定，比如：JSON 和 CORBA。

我们来利用cxf创建一个简单的webservice吧。

首先cxf 所需要的包：更具网站说明以下的包都是必须的，但是在我的实际项目中红色部分的包并没有用到。

大家可更具自己需求来添加适应的包。

cxf.jar

commons-logging.jar

geronimo-activation.jar (Or the Sun equivalent)//

geronimo-annotation.jar (Or the Sun equivalent)//

geronimo-javamail.jar (Or the Sun equivalent)//

neethi.jar

jaxb-api.jar

jaxb-impl.jar

stax-api.jar//

XmlSchema.jar

wstx-asl.jar

xml-resolver.jar

分布式应用程序和浏览器

研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为 它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。

传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的 工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是 一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问 你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。

关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。

许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上， 那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前 还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任 务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以 前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

什么是WebService?

Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。

Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面 (interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。

Web Service 是一种新的web应用程序分支，他们是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Service应用程序可以发现并调用它部署的服务。

Web Service是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。

1 历史

web广泛用到的技术：

◆TCP/IP：通用网络协议，被各种设备使用

◆HTML：通用用户界面，可以使用HTML标签显示数据

◆Java：写一次可以在任何地方运行的通用编程语言

◆XML ：通用数据表达语言，在web上传送机构化数据的容易方法

他们的特点是其开放性，跨平台性，开放性正是Web services的基础。

2 Web发展的趋势

内容更动态化

◆带宽Bandwidth更便宜，易于获得

◆存储器Storage更便宜，更易获得

◆普遍式计算变得更加重要：大量的设备，例如移动电话，页面，电脑，pc，已经在Internet上变得普遍，平台变得更多元化，象XML这样的跨平台技术变得更重要

3 Web Services扮演什么角色？

上述的这些趋势意味着，更加智能的处理，操作和汇总内容变得十分重要。让我们看看按照Web services角度所预示的四个趋势：

◆内容更加动态：一个web service必须能合并从多个不同源来的内容，可以包括股票，天气，新闻等，在传统环境中的内容，如存货水平，购物订单或者目录信息等，都从后端系统而来

◆带宽更加便宜：web services可以分发各种类型的内容（音频，视频流等）

◆存储更便宜: web services必须能聪明地处理大量数据，意味着要使用数据库，LDAP目录，缓冲，和负载平衡软件等技术保持可扩展能力

◆普遍式计算更重要：web services不能要求客户使用某一版本的windows的传统浏览器，必须支持各种设备，平台，浏览器类型，各种内容类型。

4 两种重要技术

要达到这样的目标，Web services要使用两种技术：

◆XML XML是在web上传送结构化数据的伟大方式，Web services要以一种可靠的自动的方式操作数据，HTML不会满足要求，而XML可以使web services十分方便的处理数据，它的内容与表示的分离十分理想

◆SOAP SOAP使用XML消息调用远程方法，这样web services可以通过HTTP协议的post和get方法与远程机器交互，而且，SOAP更加健壮和灵活易用。

其他象UDDI和WSDL技术与XML和SOAP技术紧密结合用于服务发现。</SPAN>

组成Web service平台的这三个技术。

XML和XSD

可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。

XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是 64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换 过程。

WSDL

你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具 既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。

4. REST和SOAP Web Service的区别比较

restful是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动。

SOAP：简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。

客户端和服务器端的通讯方式

总结：

REST对敏历于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。成熟度SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通。

5. soap和rest简单比较整理

讨论该问题的原因是之前有一次开会，讨论到webservice的实施，我直接给出的结论是应该使用rest替换掉原来的soap接口，原因是soap"太重量级了"(其实我内心想的是rest的实现比soap简单)但是当被问到怎么"重量级"的时候又是说不出来的。因为这个词'也是之前随便搜搜得到的答案。因为好像很多人就是这么阐述他们的去别的。所以究竟他们有什么不同呢，我简单说一下我的理解。

1. 从定义上他们就是完全不同的，soap是一个协议，restful是一种架构风格，是直接基于http协议实现的。所以直接可以看出当你想实现webservice的时候，后者的实现是相对简单的。soap相当于将要传输的内容又包了一层，都封装在envelope里面进行传输，而restful可以理解为发送的就是请求本身，是透明的。

2. 安全校验: 通常的做法是当有从客户端 Client2 发出的 HTTP 请求都经过代理服务器 (Proxy Server)。代理服务器制定安全策略：所有经过该代仿并理的访问 User 和 User List 资源的请求只具有读取权限，即：允许 GET/HEAD 操作，而像具有写权限的 PUT/DELTE 是不被允许的。那么如果是使用soap，那么代理是没有办法确定它的请求类型的，因为之前讲到的，soap的请求是被封装过的，很难解析envelope里面的请求类型。

3. 关于缓存，REST 的应用可以充升枣分地挖掘 HTTP 协议对缓存支持的能力。当客户端第一次发送 HTTP GET 请求给服务器获得内容后，该内容可能被缓存服务器 (Cache Server) 缓存。当下一次客户端请求同样的资源时，缓存可以直接给出响应，而吵大拆不需要请求远程的服务器获得。而这一切对客户端来说都是透明的。而soap还是我们提到的那个问题，无法知道请求类型。(默认soap使用的是post)。这一点在我们新要使用的webservice上极为重要，因为我们只提供一个get接口供用户得到信息，且信息内容不会经常改变。而且更重要的事get比post要快。

参考文章:

http://www.importnew.com/24695.html

https://blog.csdn.net/wdeng2011/article/details/78274683

https://blog.csdn.net/yanbober/article/details/45308935

https://blog.csdn.net/zzk220106/article/details/78595108/(get vs post)

6. 什么是 RESTful 到底 REST 和 SOAP，RPC 有何区别

第一个问题：什么是RESTful？

REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。有兴趣可以看看这里论文`，谁是Fielding?点击前面名字了解。

那RESTful到底是什么呢？简单的讲，它是：一种架构设计风格，提供了设计原则和约束条件，而不是架构。而满足这些约束条件和原则的应用程序或设计就是 RESTful架构或服务。

推荐阅读：
张善友博客——REST 入门介绍

infoq——深入浅出REST

第二个问题：到底 REST 和 SOAP、RPC 有何区别？

这个问题比较大，要知道他们有什么区别首先需要明白，他们分别是什键老么？

REST上面已经简单的说明了它是什么。

SOAP(简单对象访问协议)是什么？SOAP是一种数据交换协议规范，是一种轻量的、简单的、基于XML的协议的规范。它有什么优点？简单总结为： 易用，灵活，跨语言，跨平台。

易用：是因为它的消息是基于xml并封装成了符合http协议，因此,它符合任何路由器、 防火墙或代理服务器的要求。

灵活：表现在极具拓展性，SOAP 无需中断已有的应用程序, SOAP 客户端、 服务器和协议自身都能发展。而且SOAP 能极好地支持中间介质和层次化的体系结构。

跨语言：soap可以使用任何语言来完成，只要发送正确的soap请求即可。

跨平台：基于soap的服务可以在任何平台无需修改即可稿哪升正常使用。

RPC(远程调用框架) 是一种允许分布式应用程序调用网络上不同计算机的可用服务的机制。涉猎不多，一下省略256个字。有熟悉的朋友可以在评论补充，然后我会修改到该内容中去

从上面我们可以看出，REST 和 SOAP、RPC 有何区别呢？没什么太大区别，他们的本质都是提供可支持分布式的基础服务，最大的区别在于他们各自的的特点所带来的不同应用场缓庆景。

REST可以看着是http协议的一种直接应用，默认基于json作为传输格式，使用简单，学习成本低效率高，~~但是安全性较低~~，而SOAP可以看着是一个重量级的协议，基于xml，SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持 。这是REST薄弱的地方。

7. soap 和webservice的区别

SOAP简单的理解，就是这样的一个开放协议SOAP=RPC+HTTP+XML：采用HTTP作为底层通讯协议；RPC作为一致性的调拆档中用途径，XML作为数据传送的格式，允许服务提供者和服务客户经过防火墙在INTERNET进行通讯交互。RPC的描叙可能不大准确，因为SOAP一开始构思就是要实现平台与环境的无关性和独立性，每一个通过网络的远程调用都可以通过SOAP封装起来，包括DCE（Distributed Computing Environment ）RPC CALLS，COM/DCOM CALLS, CORBA CALLS, JAVA CALLS，etc。

SOAP 使用 HTTP 传送 XML，尽管HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件解析（parse），两者使得交易的速度大大低于其它方案。但是XML 是一个开放、健全、有语义的讯息机制，而 HTTP 是一个广泛又能避免许多关于防火墙的问题，从而使SOAP得到了广泛的应用。但是如果效率对你来说很重要，那么你应该多考虑其它的方式，而不要用 SOAP。

为了更好的理解SOAP,HTTP,XML如何工作的，不妨先考虑一蠢世下COM/DCOM的运行机制，DCOM处理网络协议的低层次的细节问题旅山，如PROXY/STUB间的通讯，生命周期的管理，对象的标识。在客户端与服务器端进行交互的时候，DCOM采用NDR（Network Data Representation）作为数据表示，它是低层次的与平台无关的数据表现形式。