Web Service, SOAP和WSDL的关系

2024-05-09 20:43

1. Web Service, SOAP和WSDL的关系

 最近项目做的东西比较多,一个不做Web的人也要开始看各种Web相关的东东了,hohoho...这几个概念最近一直在用,记录一下。总结和分析了各种的材料来源有这里的园子,WIKIPEDIA,百度百科,ESRI的文档库,还有身边有经验的同事。有些来自WIKI或者文档库的文章就不翻译了,原文表达的已经很到位了。
    Web Service 
   Web services provide the ability for applications to communicate using messaging over many different protocols. Because web services provide a means to communicate between applications that are written both in the same programming language as well as in different programming languages, a language neutral means of communication was needed. XML is the format used to hold the information carried between the applications. The XML message is carried using SOAP (Simple Object Access Protocol). SOAP defines the headers and the valid means for passing messages. That passing of messages usually takes place over HTTP but it can actually be over any well know protocol, such as SMTP, FTP, or DCOM. SOAP takes the xml message and wraps it so that it can be routed to the receiving application and appropriaptely processed.
    SOAP 
   简单对象访问协议,简单对象访问协议(SOAP)是一种轻量的、简单的、基于 XML 的协议,它被设计成在 WEB 上交换结构化的信息。 SOAP 可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议( HTTP),简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME)。它还支持从消息系统到远程过程调用(RPC)等大量的应用程序。
   WIKIPEDIA : SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on XML for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
   简单对象访问协议(SOAP)是W3C组织的一个Note, 它描述了一种在分散的或分布式的环境中如何交换信息的轻量级协议。SOAP是一个基于XML的协议,它包括三个部分:SOAP封装(Envelop),封装定义了一个描述消息中的内容是什么,是谁发送的,谁应当接受并处理它以及如何处理它们的框架;SOAP编码规则(Encoding Rules),用于表示应用程序需要使用的数据类型的实例;SOAP RPC表示(RPC Representation),表示远程过程调用和应答的协定;SOAP可以和多种传输协议绑定(Binding),使用底层协议交换信息。
   SOAP 消息基本上是从发送端到接收端的单向传输,但它们常常结合起来执行类似于请求 / 应答的模式。所有的 SOAP 消息都使用 XML 编码。一条 SOAP 消息就是一个包含有一个必需的 SOAP 的封装包,一个可选的 SOAP 标头和一个必需的 SOAP 体块的 XML 文档。
   SOAP在HTTP协议的基础上时,把编写成XML的REQUEST参数, 放在HTTP BODY上提交给WEB SERVICE服务器(SERVLET,ASP什么的) 处理完成后,结果也写成XML作为RESPONSE送回用户端, 为了使用户端和WEB SERVICE可以相互对应,可以使用WSDL作为这种通信方式的描述文件,利用WSDL工具可以自动生成WS和用户端的框架文件,SOAP具备把复杂对象序列化捆绑到XML里去的能力。
   SOAP也可以绑定到TCP和UDP协议上。
    WSDL 
   WSDL describes what a web service does, what methods it contains, what parameters and types it knows how to use, and which ports it is using for communication. The WSDL defines the valid contents of the XML messages to be passed over SOAP. The WSDL acts as a specification, like IDL, to describe the interfaces and parameters on a web service. The methods available are usually grouped together in a "port", which can be thought of as a view to web services where different operations are exposed. A WSDL can contain one or more ports.
    关系总结 
   总之SOAP是一个结构化数据交换的一个协议规范,用于WebService。SOAP基于XML,由于HTTP协议的应用广泛支持(协议支持和80端口可达),多数SOAP应用是基于HTTP的。
   SOAP是消息栈中位于HTTP协议之上的一层,Service调用达服务器后,TCP/IP层面,HTTP层面,SOAP协议层面依次逐级获取各自的Payload,程序结合WSDL描述的WebService结构信息,最终生成/得到相应的对象,发起调用。

Web Service, SOAP和WSDL的关系

2. 什么是SOAP?WebService的原理和过程是怎样的

  Web Service 是一种新的web应用程序分支,他们是自包含、自描述、模块化的应用,可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后,其他Web Service应用程序可以发现并调用它部署的服务。
  实际上,WebService的主要目标是跨平台的可互操作性。为了达到这一目标,WebService完全基于XML(可扩展标记语言)、XSD(XMLSchema)等独立于平台、独立于软件供应商的标准,是创建可互操作的、分布式应用程序的新平台。由此可以看出,在以下三种情况下,使用WebService会带来极大的好处。
  长项一:跨防火墙的通信
  如果应用程序有成千上万的用户,而且分布在世界各地,那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下,使用DCOM就不是那么简单,通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是,选择用浏览器作为客户端,写下一大堆ASP页面,把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大,程序很难维护。
  图1通过WebService集成应用程序
  举个例子,在应用程序里加入一个新页面,必须先建立好用户界面(Web页面),并在这个页面后面,包含相应商业逻辑的中间层组件,还要再建立至少一个ASP页面,用来接受用户输入的信息,调用中间层组件,把结果格式化为HTML形式,最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单,客户端的编程就简单多了。
  如果中间层组件换成WebService的话,就可以从用户界面直接调用中间层组件,从而省掉建立ASP页面的那一步。要调用WebService,可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端,也可以使用自己开发的SOAP客户端,然后把它和应用程序连接起来。不仅缩短了开发周期,还减少了代码复杂度,并能够增强应用程序的可维护性。同时,应用程序也不再需要在每次调用中间层组件时,都跳转到相应的“结果页”。
  从经验来看,在一个用户界面和中间层有较多交互的应用程序中,使用WebService这种结构,可以节省花在用户界面编程上20%的开发时间。另外,这样一个由WebService组成的中间层,完全可以在应用程序集成或其它场合下重用。最后,通过WebService把应用程序的逻辑和数据“暴露”出来,还可以让其它平台上的客户重用这些应用程序。
  长项二:应用程序集成
  企业级的应用程序开发者都知道,企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来,而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据;或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上,不同软件厂商生产的各种软件也常常需要集成起来。通过WebService,应用程序可以用标准的方法把功能和数据“暴露”出来,供其它应用程序使用。
  例如,有一个订单登录程序,用于登录从客户来的新订单,包括客户信息、发货地址、数量、价格和付款方式等内容;还有一个订单执行程序,用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后,订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService,订单执行程序可以把“AddOrder”函数“暴露”出来。这样,每当有新订单到来时,订单登录程序就可以调用这个函数来发送货物了。
  长项三:B2B的集成
  用WebService集成应用程序,可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢?跨公司的商务交易集成通常叫做B2B集成。
  WebService是B2B集成成功的关键。通过WebService,公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如,把电子下单系统和电子发票系统“暴露”出来,客户就可以以电子的方式发送订单,供应商则可以以电子的方式发送原料采购发票。当然,这并不是一个新的概念,EDI(电子文档交换)早就是这样了。但是,WebService的实现要比EDI简单得多,而且WebService运行在Internet上,在世界任何地方都可轻易实现,其运行成本就相对较低。不过,WebService并不像EDI那样,是文档交换或B2B集成的完整解决方案。WebService只是B2B集成的一个关键部分,还需要许多其它的部分才能实现集成。

3. SOA 和webservice 的区别

SOA是一个组件模型,他将应用程序的不同功能单元(服务)通过这些服务之间定义良好的接口和契约联系起来。SOA整合发布平台将完全无关的平台所提供的各种服务整合起来发布给外界,客户端不知道真正的服务发布者是谁。Webservice只是实现soa的一种途径。Webservice服务接口需要绑定具体实现的服务组件来实现服务,并且对具体的服务实现完成了封装,他本身知道服务是如何实现的,客户端调用webservice组件时,需要知道webservice的具体位置和传输协议。但是soa架构平台只和服务接口进行绑定,实现了服务接口的透明化,服务位置的透明化,服务传输协议的透明化。Soa本身也不知道服务具体是如何实现的。SOA实现了更高程度的抽象。

SOA 和webservice 的区别

4. SOA 和webservice 的区别

对 SOA的定义和理解分两类
一类认为: SOA主要是一种架构风格
另一类认为: SOA是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境,涵盖服务的整个生命周期:建模——开发——整合 ——部署 ——运行 ——管理
 
 
       Service-architecture.com将 SOA定义为:本质上是服务的集合。服务间彼此通信,这种通信可能是简单的数据传送,也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。
所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数
 
       虽然不同厂商或个人对 SOA有着不同的理解,
但是我们仍然可以从上述的定义中看到 SOA的几个关键特性:一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型
 
由此可以得出,只要某个软件系统符合了SOA的架构,就可以说它是基于SOA的
如,我们完全可以把word这个软件,设计成一个个组件,并让其符合SOA架构。
所以SOA不一定需要web service来实现。
Web service 简单来说就是一个向外界暴露出的能够通过internet进行调用的api和应用程序, 是基于SOA松耦合等思想开发出来的一套framework(个人观点),但是它并一定完全符合SOA的架构。 比如你自己写的基于ws的一个小函数。
 
现阶段,我们能看到的大部分SOA系统好像都是 用web service实现的,
因为某个软件如果不开源让所有人一起开发,你就不知道它到底是不是基于SOA的,
你想用别人的服务,一般需要到网上去搜索,搜到以后是直接使用,而不是下载下来,这些正是web service给我们提供的功能。
但一定要明确,那些把自己能提供的服务包装一下,对外提供一个ws接口,就声称自己是SOA,肯定是错误的,因为他的系统并不一定符合SOA架构。

5. SOA 和webservice 的区别

一、SOA是一个组件模型,他将应用程序的不同功能单元(服务)通过这些服务之间定义良好的接口和契约联系起来。SOA整合发布平台将完全无关的平台所提供的各种服务整合起来发布给外界,客户端不知道真正的服务发布者是谁。Webservice只是实现soa的一种途径。
二、ebservice服务接口需要绑定具体实现的服务组件来实现服务,并且对具体的服务实现完成了封装,他本身知道服务是如何实现的,客户端调用webservice组件时,需要知道webservice的具体位置和传输协议。但是soa架构平台只和服务接口进行绑定,实现了服务接口的透明化,服务位置的透明化,服务传输协议的透明化。Soa本身也不知道服务具体是如何实现的。SOA实现了更高程度的抽象。

SOA 和webservice 的区别

6. SOA 和webservice 的区别

对 SOA的定义和理解分两类

一类认为: SOA主要是一种架构风格

另一类认为: SOA是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境,涵盖服务的整个生命周期:建模——开发——整合
——部署 ——运行 ——管理

 

 

       Service-architecture.com将 SOA定义为:本质上是服务的集合。服务间彼此通信,这种通信可能是简单的数据传送,也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。

所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数

 

       虽然不同厂商或个人对 SOA有着不同的理解,

但是我们仍然可以从上述的定义中看到 SOA的几个关键特性:一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型

 

由此可以得出,只要某个软件系统符合了SOA的架构,就可以说它是基于SOA的

如,我们完全可以把word这个软件,设计成一个个组件,并让其符合SOA架构。

所以SOA不一定需要web service来实现。

Web service 简单来说就是一个向外界暴露出的能够通过internet进行调用的api和应用程序, 是基于SOA松耦合等思想开发出来的一套framework(个人观点),但是它并一定完全符合SOA的架构。 比如你自己写的基于ws的一个小函数。

 

现阶段,我们能看到的大部分SOA系统好像都是 用web service实现的,

因为某个软件如果不开源让所有人一起开发,你就不知道它到底是不是基于SOA的,

你想用别人的服务,一般需要到网上去搜索,搜到以后是直接使用,而不是下载下来,这些正是web service给我们提供的功能。

但一定要明确,那些把自己能提供的服务包装一下,对外提供一个ws接口,就声称自己是SOA,肯定是错误的,因为他的系统并不一定符合SOA架构。

7. SOA 和webservice 的区别

服务接口都是基于开发的。 
服务接口和服务的具体实现都是分离的。 
Web Service服务接口需要绑定具体实现服务的服务组件来实现服务,它对具体的服务实现完成了封装,实现了服务的透明化,客户端不需要知道服务是如何实现的,但是Web Service组件本身是知道服务是如何实现的, 

另外客户端调用Web Service组件时,需要知道Web Service的具体位置和传输协议,这些都会造成一定的不灵活性,它只是实现了一定程度上的抽象。 

SOA架构只和服务接口进行绑定,对服务接口实现了封装,实现了服务接口的透明化,服务位置的透明化,服务传输协议的透明化。SOA本身也不知道服务具体是如何实现的。当客户端通过SOA调用服务时,不需要知道真正的服务提供者是谁,具体的服务位置在哪里和具体的传输协议是什么。SOA实现了最高程度上的抽象化,为实现具有最高灵活性的服务建立了架构基础。 

SOA架构的要点: 

SOA架构所提供的服务之间是松散耦合的。 

SOA架构应该按更接近于实际业务本身的粗粒度的角度来对服务进行划分,发布服务接口方法。这就要求设计和开发人员直接从业务的角度来构建SOA所提供的服务,而不仅仅从模块和技术的角度来构建SOA服务。 

SOA架构中的所有服务的具体实现、位置和传输协议对调用者来说都是透明的。

SOA 和webservice 的区别

8. SOA只是个概念,思想,而webservice是实现SOA的方式吗

WebService是一个SOA(面向服务的编程)的架构,它是不依赖于语言,不依赖于平台,可以实现不同的语言间的相互调用,通过Internet进行基于Http协议的网络应用间的交互。
WebService实现不同语言间的调用,是依托于一个标准,webservice是需要遵守WSDL(web服务定义语言)/SOAP(简单请求协议)规范的。
WebService=WSDL+SOAP+UDDI(webservice的注册)
Soap是由Soap的part和0个或多个附件组成,一般只有part,在part中有Envelope和Body。
Web Service是通过提供标准的协议和接口,可以让不同的程序集成的一种SOA架构。
Web Service的优点
(1) 可以让异构的程序相互访问(跨平台)(2) 松耦合
(3) 基于标准协议(通用语言,允许其他程序访问)
Web Service的基本原理
(1) Service Provider采用WSDL描述服务
(2) Service Provider 采用UDDI将服务的描述文件发布到UDDI服务器(Register server)
(3) Service Requestor在UDDI服务器上查询并 获取WSDL文件
(4) Service requestor将请求绑定到SOAP,并访问相应的服务。

Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性,Web Service平台必须提供一套标准的类型系统,用于沟通不同平台、编程语言和组件模型中的不同类型系统。这些协议有:
XML和XSD
可扩展的标记语言(标准通用标记语言下的一个子集)是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外,XML主要的优点在于它既与平台无关,又与厂商无关。XML是由万维网协会(W3C)创建,W3C制定的XML SchemaXSD 定义了一套标准的数据类型,并给出了一种语言来扩展这套数据类型。
Web Service平台是用XSD来作为数据类型系统的。当你用某种语言如VB. NET或C# 来构造一个Web Service时,为了符合Web Service标准,所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递,还需要用某种东西将它包装起来。这种东西就是一种协议,如 SOAP。
xml web service[2]
SOAP
SOAP即简单对象访问协议(Simple Object Access Protocol),它是用于交换XML(标准通用标记语言下的一个子集)编码信息的轻量级协议。它有三个主要方面:XML-envelope为描述信息内容和如何处理内容定义了框架,将程序对象编码成为XML对象的规则,执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如,你可以使用 SMTP,即因特网电子邮件协议来传递SOAP消息,这可是很有诱惑力的。在传输层之间的头是不同的,但XML有效负载保持相同。
Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用,打破了软件应用、网站和各种设备之间的格格不入的状态,实现“基于Web无缝集成”的目标。
WSDL
Web Service描述语言WSDL 就是用机器能阅读的方式提供的一个正式描述文档而基于XML(标准通用标记语言下的一个子集)的语言,用于描述Web Service及其函数、参数和返回值。因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的。
UDDI
UDDI 的目的是为电子商务建立标准;UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的Web Service注册,以使别的企业能够发现的访问协议的实现标准。
调用RPC与消息传递
Web Service本身其实是在实现应用程序间的通信。我们有两种应用程序通信的方法:RPC远程过程调用 和消息传递。使用RPC的时候,客户端的概念是调用服务器上的远程过程,通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性:服务器暴露出远程对象的接口,而客户端就好像在本地使用的这些对象的接口一样,这样就隐藏了底层的信息,客户端也就根本不需要知道对象是在哪台机器上。
软件支持
操作系统离不开丰富的应用软件的支持。同样,Web Service这项技术只有通过日益广泛的应用才能体现出其价值,比较流行的实现方法是使用.NET 和 Java两种技术,并且两种实现方法可以互相操作;如今我们已经可以看到使用微软、Oracle、SUN、Borland等不同厂商的Web Service构建工具建立的Web Service应用。
微软.NET
微软的.NET技术应该算是时下最为流行的Web Service 开发技术。首先因为其公司在以前相应的产品就占有相当大的市场份额,以至使新推出的.NET得以有比较稳定的用户群;其次也是更重要的是 .NET平台不仅延续了微软一贯的编程风格,而且还增加了许多支持Web 服务的关键性技术,使得.NET在操作的简单性和执行的稳定性,高效性上达到了一个非常好的结合。
微软的Visual Studio. NET便是一个便于 Web 服务的开发工具。微软的目标是,将其新编程语言——C#作为Web Service的首选语言。虽然C#看起来与Java类似,但是还有一些Java中没有的独特的功能。.NET技术中用于Web Service 开发的主要工具是ASP. NET。从技术上说,ASP. net  提供了一些超出ASP以前版本的优点(例如:代码和HTML(标准通用标记语言下的一个应用)的分离,与脚本语言相比较,对“真正”的编程语言如 C# 的支持)。
IBM的WebSphere
IBM公司是业界第一家能够提供全面支持Web服务的电子商务基础设施中间件的公司。通过多年来与W3C(The World Wide Web Consortium)的共同努力,包括DB2、Lotus、Tivoli 和WebSphere在内的所有IBM软件都实现了对SOAP、WSDL、UDDI、Linux、XML(标准通用标记语言下的一个子集)、J2EE等开放技术和标准的全面支持。
IBM公司的WebSphere也是比较好的基础架构软件开发平台。WebSphere软件平台及开发工具包括WebSphere Studio Application DeveloperWSAD  基于J2EE、XML 和Web服务等开放标准,并具备 IBM 在可靠性、扩展性和安全性上的主要优势。WebSphere 是 IBM 在 Web Services策略中的核心平台,它支持所有开发、发布、部署 Web Services应用所必需的开放标准和技术,包括 UDDI,SOAP,J2EE,WSDL,和对 XML 技术集成的增强,这使得它在全球有很多用户。
Borland的JBuilder
Borland公司在 JBuilder7中,用户可以用其Borland Web Services Kit for Java和Borland JBuilder MobileSet 3进行更快捷地开发Web Service和无线应用。这样将使开发者能够在同一个开发环境中轻松地创建和集成Web Service。新推出的JBuidler8更是针对Web Service开发更提供了方便和高效的方法。
总之,在Web Service开发上,.NET 和Java都是很好的选择,尽管两者都有一些需要完善的地方,但是它们还是最好的开发手段和技术。具体选择哪种开发工具,也是仁者见仁,智者见智的问题。从根本上说,这两种方法没有孰优孰劣的问题,只是根据使用者对这两种方法的掌握程度和对具体语言的偏爱程度来决定。
最新文章
热门文章
推荐阅读