WebService

• 什么是Webservice？
  • Web Service是自包含的、模块化的应用程序，它可以在Web中被描述、发布、查找以及调用。
  • webservice是基于网络的，分布式的模块化组件，他执行特定的任务，遵守具体的技术规范，这些规范使得webservice能与其他兼任的组件进行操作。
  • 由企业发布的完成其特别商务需求的在线应用服务，其他公司或软件通过Internet来访问并使用这项应用服务

WebService，顾名思义就是基于Web的服务。它使用Web(HTTP)方式，接收和响应外部系统的某种请求。从而实现远程调用.

• 学习WebService可以将你的服务(一段代码)发布到互联网上让别人去调用,也可以调用别人机器上发布的WebService,就像使用自己的代码一样.。

• W3C组织对其的定义：他是一个软件系统，为了支持跨网络的机器间来相互操作交互而设计。webService服务通常被定义为一组模块化的API，可以通过网络进行调用，来执行远程系统的请求服务。

• WebService即Web服务，它是一种跨编程语言和跨操作系统平台的远程调用技术

• 实现一个完整的Web服务包括以下步骤：

  ◆ Web服务提供者**(服务端)**1.设计实现Web服务，并将2.调试正确后的Web服务通过Web服务中介者发布，并在3.UDDI注册中心注册； （发布）

  ◆ Web服务***请求者***(**客户端)**向Web服务中介者请求特定的服务，中介者根据请求查询UDDI注册中心，为请求者寻找满足请求的服务； （发现）

  ◆ Web服务中介者向Web服务请求者返回满足条件的Web服务描述信息，该描述信息用WSDL写成，各种支持Web服务的机器都能阅读**；（发现）**

  ◆ 利用从Web服务中介者返回的描述信息生成相应的SOAP消息，发送给Web服务提供者，以实现Web服务的调用；（绑定）

  ◆ Web服务提供者按SOAP消息执行相应的Web服务，并将服务结果返回给Web服务请求者。（绑定）

WebService三要素

• SOAP (Simple Object Access Protocol)：简易对象访问协议，soap用来描述传递信息的格式。
• WSDL (WebServices Description Language)：Web服务描述语言，用来描述WebService、以及如何访问WebService
• UDDI (Universal Description Discovery and Integration)：**通用描述、发现及整合，用来管理、分发、查询webService。**c

Webservice服务发布之后，通过浏览器访问发布的+?wsdl即可获得wsdl文档。

什么是WSDL文档？

• 一个WSDL文档的根元素是definitions元素，WSDL文档包含7个重要的元素：types, import, message, portType, operations, binding和service元素。
  • definitions元素中一般包括若干个XML命名空间；
  • Types元素用作一个容器，定义了自定义的特殊数据类型，在声明消息部分（有效负载）的时候
  • messages定义使用了types元素中定义的数据类型与元素；
  • Import元素可以让当前的文档使用其他WSDL文档中指定命名空间中的定义；
  • Message元素描述了Web服务的有效负载。相当于函数调用中的参数和返回值；
  • PortType元素定义了Web服务的抽象接口，它可以由一个或者多个operation元素，每个operation元素定义了一个RPC样式或者文档样式的Web服务方法；
  • Operation元素要用一个或者多个messages消息来定义它的输入、输出以及错误；
  • Binding元素将一个抽象的portType映射到一组具体的协议（SOAP或者HTTP）、消息传递样式（RPC或者document）以及编码样式（literal或者SOAP encoding）；
  • Service元素包含一个或者多个Port元素
• 每一个Port元素对应一个不同的Web服务，port将一个URL赋予一个特定的binding，通过location实现。可以使两个或者多个port元素将不同的URL赋给相同的binding。

SOAP是什么?

​ SOAP是simple object access protocal的缩写，即简单对象访问协议。 是基于XML和HTTP的一种通信协议,是webservice所使用的一种传输协议,webservice之所以能够做到跨语言和跨平台，主要是因为XML和HTTP都是独立于语言和平台的.Soap的消息分为请求消息和响应消息，一条SOAP消息就是一个普通的XML文档，包含下列元素：

• 必需的 Envelope 元素，可把此XML文档标识为一条SOAP消息
• 可选的 Header 元素，包含头部信息
• 必需的 Body 元素，包含所有的调用和响应信息
• 可选的 Fault 元素，提供有关在处理此消息所发生错误的信息,soap请求消息,soap响应消息.

怎么理解UDDI?

​ UDDI是Universal Description Discovery and Integration的缩写，即统一描述、发现和整合规范。用来注册和查找服务，把web services收集和存储起来，这样当别人访问这些信息的时候就从UDDI中查找，看有没有这个信息存在。

Webservice的SEI指什么？

WebService EndPoint Interface（webservice终端[Server端]接口）就是 WebService服务器端用来处理请求的接口.

Java开发WebService最重要的两个规范：
JSR-224 (JAX-WS：Java API for XML-Based Web Services ) ，主要使用soap协议，使用wsdl来描述；

JSR-311 (JAX-RS：The Java API for RESTful Web Services)，使用wadl描述；

其中:JAX-WS是针对WebService。而JAX-RS是针对RESTful HTTP Service。

JAX-WS是面向消息的，每次请求的时候指定了请求的方法。JAX-RS是面向资源的。后则将网络上的东西当做一种资源，每次请求都是对该资源进行操作，比如对资源的增删查改。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YJ5NCUcN-1608386281286)(C:\Users\asus\Desktop\java面试\webservice.png)]

SOAP WS 和RESTful Web Service之间有什么不同呢？

• SOAP WS支持既远程过程调用（例如，RPC）又支持消息中间件（MOM）方式进行应用集成。而Restful Web Service仅支持RPC集成方式。
• SOAP WS是传输协议无关的。它支持多种协议，比如，HTTP(S)、 Messaging、TCP、UDP SMTP等等。而REST是协议相关的，只支持HTTP或者HTTPS协议。
• SOAP WS仅允许使用XML数据格式。定义的操作通过POST请求发送。其重点是通过操作名来获取服务，并将应用逻辑封装为服务。而REST方式则允许多种数据格式，例如，XML、JSON、文本、HTML等等。而且由于REST方式采用标准GET、PUT、PSOT和DELETE 方法，因此所有的浏览器都可以支持。其重点是通过资源名来获取服务，并将数据封装为服务。AJAX支持REST方式，它可以使用XMLHttpRequest对象。无状态CRUD操作（创建、读、更新和删除）更加适合这种方式。
• 无法缓存SOAP方式读取的内容。而REST方式的则可以，而且性能和可扩展性都更好一些。
• 即便是要通过SOAP的第三方程序，SOAP通过内置的重试逻辑也可以提供端到端可靠性。REST没有一个标准的消息系统，因而寄希望于客户通过重连去解决通信失败问题。

*如何选择采用哪种Web service？SOAP WS还是REST？*

基于REST的Web service的优势在于其简单、性能不错、可扩展性好，并且也支持多种数据格式。而SOAP则适用于安全性和事务处理可靠性方面要求比较高的服务中。

考虑依据是设计者对功能性和非功能性需求的要求：

• 所提供的服务会暴露数据或者业务逻辑吗？（如果会暴露数据的话可以选择REST方式，如果会暴露业务逻辑的话可以选择SOAP WS）。客户或者服务提供商需要一个正式的契约（contract）吗？（SOAP可以通过WSDL（Web Service Description Language）提供一个正式契约）
• 需要支持多种数据格式吗？
• 需要进行AJAX调用吗？（REST可以采用XMLHttpRequest来发送AJAX调用）
• 同步调用还是异步调用？
• 有状态调用还是无状态调用？（REST适合无状态CRUD操作）
• 对于安全性的要求？（SOAP WS对于安全性的支持更好些）
• 对于事务处理的要求？（SOAP WS这方面更有优势）
• 有带宽限制吗？（SOAP消息比较冗长）
• 哪种方式更适合开发者呢呢？（REST更好实现，也更好测试和维护）

常见的Webservice框架，他们都有什么特点？

Webservice常用框架有JWS、Axis2、XFire以及CXF（JAX-WS）

• JWS是Java语言对WebService服务的一种实现，用来开发和发布服务。而从服务本身的角度来看JWS服务是没有语言界限的。但是Java语言为Java开发者提供便捷发布和调用WebService服务的一种途径。

• Axis2是Apache下的一个重量级WebService框架，准确说它是一个Web Services / SOAP / WSDL 的引擎，是WebService框架的集大成者，它能不但能制作和发布WebService，而且可以生成Java和其他语言版WebService客户端和服务端代码。这是它的优势所在。但是，这也不可避免的导致了Axis2的复杂性，使用过的开发者都知道，它所依赖的包数量和大小都是很惊人的，打包部署发布都比较麻烦，不能很好的与现有应用整合为一体。但是如果你要开发Java之外别的语言客户端，Axis2提供的丰富工具将是你不二的选择。

• CXF是Apache旗下一个重磅的SOA简易框架，它实现了ESB（企业服务总线）。CXF来自于XFire项目，经过改造后形成的，就像目前的Struts2来自WebWork一样。可以看出XFire的命运会和WebWork的命运一样，最终会淡出人们的视线。CXF不但是一个优秀的Web Services / SOAP / WSDL 引擎，也是一个不错的ESB总线，为SOA的实施提供了一种选择方案，当然他不是最好的，它仅仅实现了SOA架构的一部分。

• 如何抉择：
  1、如果应用程序需要多语言的支持，Axis2应当是首选了；
  2、如果应用程序是遵循 spring哲学路线的话，Apache CXF是一种更好的选择，特别对嵌入式的Web Services来说；
  3、如果应用程序没有新的特性需要的话，就仍是用原来项目所用的框架，比如 Axis1，XFire，Celtrix或BEA等等厂家自己的Web Services实现，就别劳民伤财了。

webService使用场景

跨越防火墙的通信

如果你的应用程序有成千上万的用户，而且他们都分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。那是因为客户端和服务器之间通常都会 有防火墙或者代理服务器。在这种情况下，你想使用DCOM就不是那么简单了，而且，通常你也不愿意把你的客户端程序发布到如此庞大数量的每一个用户手中。 于是，你最终选择了用浏览器作为客户端，写下一堆ASP页面，把应用程序的中间层暴露给最终用户。结果呢?运气好的话，只是开发难度大了一些，运气不好的 话，就会得到一个根本无法维护的应用程序。

想象一下你应该怎么在你的应用程序里面加入一个新的页面：你必须先建立好用户界面(Web 页面)，以及在这个页面后面，包含相应商业逻辑的中间层组件。这还不够，你还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结 果格式化为HTML形式，最后还要把"结果页"送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程不就简单多了吗?还有，建立ASP页 面的那一步可以省略掉吗?

当然。如果你的中间层组件是Web service的话，你完全可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web service，你可以直接使用Microsoft SOAP Toolkit或。NET这样的SOAP客户端，也可以使用你自己开发的SOAP客户端，然后把它和你的应用程序连接起来。这样做，不仅可以缩短开发周 期，还可以减少代码的复杂度，并增强整个应用程序的可维护性。同时，你的应用程序也不再需要在每次调用中间层组件时，都跳转到相应的"结果页"了。

以我的经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web service这种结构，可以轻松的节省花在用户界面编程上的20%的开发时间。这样做还有另一个好处，就是你将得到一个由Web service组成的中间层，这一层是完全可以在应用程序集成或其他场合下被重用的。最后，通过Web service把你的应用程序的逻辑和数据暴露出来，还可以让其它平台上的客户重用你的应用程序。

应用程序集成

企业级的应用程序开发者都知道**，企业里经常都要把用不同语言写成的在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发的力量**。你的应用程序 经常都需要从运行在古老的IBM主机上的程序中获取数据; 或者再把数据发送到主机或UNIX应用程序中去。即使是在同一个平台上，不同的软件厂商生产的各种软件也常常需要集成起来。通过Web service，应用程序可以用标准的方法把功能和数据暴露出来，供其它的应用程序使用。

例如，你有一个订单登录程序，用于登录从客 户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等信息。同时，你还有一个订单执行程序，用于实际货物发送的管理。这两个程序是来自不同软件 厂商的。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web service，订单执行程序可以把"AddOrder"函数暴露出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。进而通 过Web service集成应用程序

B2B的集成

用Web service集成应用程序，可以使你公司内部的商务处理更加自动化。但当交易跨越了你的供应商和客户，突破了公司的界线时又会怎么样呢?跨公司的商务交易集成通常叫做B2B集成。

Web service是B2B集成成功的关键。通过Web service，你的公司可以把关键的商务应用暴露给指定的供应商和客户。例如，把你的电子下单系统和电子发票系统暴露出来，你的客户就可以以电子的方式 向你发送购货订单，而你的供应商则可以以电子的方式把原料采购的发票发送给你。当然，这并不是一个新的概念：电子文档交换(EDI)早就是这样了。Web service和EDI之间的主要区别在于，Web service的实现要比EDI简单得多，而且Web service是运行在Internet上的，在世界任何地方都可轻易实现，这样其运行成本就相对较低。不过，Web service并不像EDI那样，是文档交换或B2B集成的一套完整的解决方案。Web service只是B2B集成的一个关键部分，还需要许多其它的部分才能完成这个集成。

用Web service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把你的商务逻辑暴露出来，成为Web service，你就可以让任何指定的合作伙伴轻松的调用你的商务逻辑，而不管他们的系统在什么平台上运行，使用的是什么开发语言。这样就大大减少了花在 B2B集成的上的时间和成本。这样的低成本让许多原本无法承受EDI的投资成本的中小企业也能实现B2B集成。

软件重用

软件重用是一个很大的主题，它有很多的形式和程度。最基本的形式是源代码模块或者类一级的重用。另一种形式是二进制形式的组件重用。当前，像表格控件或 用户界面控件这样的可重用软件组件在市场上都占有很大的份额。但这类软件的重用都有一个很严重的限制：重用仅限于代码，而数据不能被重用。原因在于你可以 很轻易的发布组件甚至源代码，但要发布数据就没那么容易了，除非那些数据都是不会经常变化的静态数据。

而Web service允许你在重用代码的同时，重用代码后面的数据。使用Web service，你不再像以前那样，要先从第三方购买、安装软件组件，再从你的应用程序中调用这些组件。你只需要直接调用远端的Web service就可以了。举个例子，你想在你的应用程序中确认用户输入的邮件地址，那么，你只需把这个地址直接发送给相应的Web service，这个Web service 就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址的确在相应的邮政编码区域。Web service 的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不现实的，因为那样的话你必须下载并安装好包含街道地址、城市、省 区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。

另一种软件重用的情况是**把好几个应用程序的功能集成起来。**例如，你 想要建立一个局域网上的门户站点应用，让用户既可以查询他们的联邦快递包裹，察看股市行情，又可以管理他们的日程安排，还可以在线购买电影票。现在Web 上有很多应用程序供应商，都在其应用中实现了上面的这些功能。一旦他们把这些功能都通过Web service 暴露出来，你就可以非常轻易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。

用Web service来集成各种应用中的功能，为用户提供一个统一的界面许多应用程序都会利用Web service，把当前基于组件的应用程序结构扩展为组件和Web service 的混合结构。你也可以在应用程序中使用第三方的Web service 提供的功能。你还可以把你自己的应用程序的功能通过Web service 提供给别人。所有这些情况下，你都可以重用代码和代码后面的数据。总之，Web service 将是软件重用的一种非常有力的形式。

什么时候不应该使用Web Service

一个对Web service的完整介绍还应该包括什么时候不该用Web service.经过前面的介绍，我们知道了Web service 在通过Web进行互操作或远程调用的时候是最有用的。不过，还有许多情况，Web service根本不能给你带来任何好处。

• 单机应用程序

目前，我们还有很多桌面应用程序是供商用和个人使用的。其中一些只需要与运行在本机上的其他程序通信。在这种情况下，我们最好就不要再用Web service ，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在一台服务器上的服务器软件也是这样：最好直接用COM或其他本 地的API来进行应用程序间的调用。当然Web service 也能用在这些情况下，但那样不仅消耗太大，而且不会给你带来任何好处。

• 局域网上的同构应用程序

在许多应用中，你所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，你有两个服务器应用程序需要 相互通信，或者你有一个Win32或WinForm的客户程序要连接到局域网上的另一个服务器程序。在这些程序里使用DCOM会比SOAP/HTTP有效 的多。类似的，如果你的一个。NET程序要连接到LAN上的另一个。NET程序，那么你应该使用。NET remoting.有趣的是，在。NET remoting中，你也可以指定使用SOAP/HTTP来进行Web service 调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。总之，只要你从应用程序结构的角度看来，有别的方法比Web service 更有效，更可行，那就不要再用Web service.

不想向外暴露的接口

webService 是系统对外的接口，如果你的接口仅是对内使用的，千万不要使用 Web Service，只将那些想提供给外界使用的接口通过Web service实现。

总结

Web service是创建可互操作的分布式应用程序的新平台。Web service 的主要目标是跨平台的可互操作性。为了达到这一目标，Web service 是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。

Web service在应用程序跨平台和跨网络进行通信的时候是非常有用的。Web service适用于应用程序集成、B2B集成、代码和数据重用，以及通过Web进行客户端和服务器的通信的场合。

当然，Web service也不是万能的，你不能到处滥用Web service.在有些情况下，Web service 会降低应用程序的性能，而不会带来任何好处。例如，一台机器或一个局域网里面运行的同构应用程序就不应该用Web service 进行通信。