WebService《JavaEE6权威指南 基础篇第4版》

 

---

【Web服务】

为运行在不一样平台和框架之上的软件提供了互操做的标准方式。良好的互操做性和可扩展性。消息采用自包含文档的形式。

——解决异构系统之间交互。 解决异构系统通讯问题： 

1.经过XML，JSON，字符串进行多语言的通信。

2.共享数据库。

3.共享文件。

4.使用消息中间件。

 

Axis互通讯比较好，对其余语言访问的兼容性比较多；

CXF很是容易的整合到Spring架构中；

 

【REST风格】

Representational State Transfer，表述性状态转移。Web应用：多使用JAX-RS服务类型。

 

随着云技术的发展，JAX-RS将会变得更加剧要。

 

【JAX-WS】

调用与应答经过HTTP协议，以SOAP消息（XML文件）的形式在服务器端与客户端之间传输。

javax.jws.WebService注解将类声明为Web服务端点。

【对JAX-WS端点的要求】

实现类的业务方法必须是公有类型，且不能声明为static或final。

实现类不能声明为final或avstract。

实现类必须有一个默认的公有构造函数。

实现类不能定义finalize方法。

 

 

 

第13章 用JAX-RS构建REST式Web服务

---

REST风格实际上是指一种架构风格，设定诸如统一接口之类的约束条件。

 

性能，可扩展性，可修改性等方面的提高。 

在这种架构风格中，数据和功能都被视为资源。能够用URL（统一资源描述符）来访问。

必须使用无状态的通讯协议，典型的例子就是HTTP协议。

在REST架构风格里，客户端和服务器经过标准化的接口和协议来操做资源。

 

如下特性使得REST式应用简单、轻量化、开发速度也快：

---

1.经过URI识别资源。URI还能够用于服务发现。

2.统一接口。经过使用4个固定的操做来使用资源。PUT建立资源，GET读取资源，POST更新资源，DELETE删除资源。

3.自描述的消息。资源和它们的展现是松耦合的。与资源相关的元数据能够用于诸如控制缓存机制、检测传输错误、协商合适的展示格式、以及执行身份验证或者访问控制。

4.经过超连接实现有状态的交互。

 

建立一个REST式根资源类

---

根资源类（root resource class）使用@Path注解。或者POJO类使用“请求方法指示符”注解如@GET@POST@PUT@DELETE。

资源方法（resource method）是指在资源类中使用了请求方法指示符注解的方法。

本节内容讲述如何使用JAX-RS来注解Java类，以建立REST式Web服务。

 

JAX-RS 是Java提供的API，使用Java语言提供的注解功能。

定义资源、及可以用在资源上的操做。

 

JAX-RS注解是运行时的注解，所以运行时的反射功能能会为资源生成辅助类以及中间文件。

JavaEE应用归档文件包含：JAX-RS资源类、配置的资源、辅助类以及和中间文件、还有暴露给客户端的资源。

 

《JAX-RS注解总结》

---

@Path：注解的值是一个相对URI路径，/helloworld，/helloworld/{username}

@Produces("text/plain") 指定资源能够生成并发送给客户端的MIME媒体类型。

 

要获得用户输入的名字，能够在请求的方法参数里使用@PathParam注解。

 

@Path("/user/{username}") public class UserResource{     @GET     @Produces("text/xml")     public String getUser(@PathParam("username") String userName){         ...     } }

响应HTTP资源

1.请求方法指示符注解

 

 

参考博客讲解

---

《使用JAX-RS建立RESTful Web Service》

 

《SOA，微服务与Docker》
 继面向对象编程思想又一种较新的编程思想面向服务编程，这样咱们就不用顾虑语言的差异，提供规范的服务接口，咱们不管使用什么语言，就均可以访问使用了，大大提升了程序的复用率。

 

 

 

---

《主流Web Service框架介绍：CXF和Axis2》

CXF和Axis2是目前java平台上最主流的两个框架，虽然两个项目都隶属ASF，但倒是基于不一样思想和风格实现的，所以也各有所长。

 

CXF：http://cxf.apache.org/

是由过去的Celtix和XFire两个框架合并而来，CXF在java社区有普遍的接受度是得益于它能很好的集成Spring。我认为CXF最突出的两个优点是：

1.对JAX-WS规范的完整实现。 做为java平台上的WebService标准，过去既有的WebService产品必然会向这一标准靠拢，而JAX-WS标准自己大大地下降了开发WebService的工做量，对于开发人员来讲，是很是受欢迎的。

2.对Spring的友好支持。 CXF从Xfire继承而来，对Spring有着很是友好的支持。鉴于Spring的普遍应用，对不少团队来讲这是很是有吸引力的一点。

 

Axis2: http://axis.apache.org/axis2/java/core/

与CXF这类嵌入式的框架相比，Axis2更像是一种是WS容器，它要求应用程序以aar包的形式部署到本身里面，这对于既有系统，特别是那些基于servlet容器的web应用来讲，改造的代价可能会很大。Axis2的优点在于一方面它对WS-*协议族的支持比较全面，另外一方面是它还支持C平台，这是一个值得咱们关注的优点。

 

总得来讲，若是是新生项目，选择CXF或Axis2在工做量上不会有太大的差异，对于那些使用了Spring的既有项目来讲，CXF应该是首选，由于CXF是基于注解的。所以对于那些基于jvm1.4构建陈旧系统可能并不适用。Axis2的优点是支持C平台和比较全的WS-*协议族。（以上的考量都尚未考虑ESB的因素。）

 

 

【WebService优缺点】

 

From : http://blog.csdn.net/chaobeyond/article/details/2247117

 

最近作的几个项目都用到了webservice，经过本身的实践和网上资料的汇总，如今作个小结：        当前WebService是一个热门话题。可是，WebService到底是什么？，WebService有什么优势和缺点，什么状况下应该用WebService？什么状况下不该该用WebService？是须要咱们正确认识的。实际上，WebService的主要目标是跨平台的可互操做性。为了达到这一目标，WebService彻底基于XML（可扩展标记语言）、XSD （XMLSchema）等独立于平台、独立于软件供应商的标准，是建立可互操做的、分布式应用程序的新平台。由此能够看出，在如下三种状况下，使用 WebService会带来极大的好处。优势一：跨防火墙的通讯若是应用程序有成千上万的用户，并且分布在世界 各地，那么客户端和服务器之间的通讯将是一个棘手的问题。由于客户端和服务器之间一般会有防火墙或者代理服务器。在这种状况下，使用DCOM就不是那么简 单，一般也不便于把客户端程序发布到数量如此庞大的每个用户手中。传统的作法是，选择用浏览器做为客户端，写下一大堆ASP页面，把应用程序的中间层暴 露给最终用户。这样作的结果是开发难度大，程序很难维护。举个例子， 在应用程序里加入一个新页面，必须先创建好用户界面(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 集成的一个关键部分，还须要许多其它的部分才能实现集成。用WebService来实现B2B集成的最大好处在于能够轻易实现互操做 性。只要把商务逻辑“暴露”出来，成为WebService，就可让任何指定的合做伙伴调用这些商务逻辑，而无论他们的系统在什么平台上运行，使用什么 开发语言。这样就大大减小了花在B2B集成上的时间和成本，让许多本来没法承受EDI的中小企业也能实现B2B集成。优势四：软件和数据重用软件重用是一个很大的主题，重用的形式不少，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另外一种形式是二进制形式的组件重用。当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。缘由在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会常常变化的静态数据。WebService在容许重用代码的同时，能够重用代码背后的数据。使用WebService，不再必像之前那样，要先从第三方购买、安装软件组 件，再从应用程序中调用这些组件；只须要直接调用远端的WebService就能够了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接 发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区 域。WebService的提供商能够按时间或使用次数来对这项服务进行收费。这样的服务要经过组件重用来实现是不可能的，那样的话你必须下载并安装好包 含街道地址、城市、省区和邮政编码等信息的数据库，并且这个数据库仍是不能实时更新的。另外一种软件重用的状况是，把好几个应用程序的 功能集成起来。例如，要创建一个局域网上的门户站点应用，让用户既能够查询联邦快递包裹，查看股市行情，又能够管理本身的日程安排，还能够在线购买电影 票。如今Web上有不少应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都经过WebService“暴露”出来，就能够很是容易地把所 有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。未来，许多应用程序都会利用WebService，把当前基 于组件的应用程序结构扩展为组件/WebService的混合结构，能够在应用程序中使用第三方的WebService提供的功能，也能够把本身的应用程 序功能经过WebService提供给别人。两种状况下，均可以重用代码和代码背后的数据。从以上论述能够看出，WebService在经过Web进行互操做或远程调用的时候是最有用的。不过，也有一些状况，WebService根本不能带来任何好处。缺点一：单机应用程序  目前，企业和我的还使用着不少桌面应用程序。其中一些只须要与本机上的其它程序通讯。在这种状况下，最好就不要用WebService，只要用本地的 API就能够了。COM很是适合于在这种状况下工做，由于它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来 进行应用程序间的调用。固然WebService也能用在这些场合，但那样不只消耗太大，并且不会带来任何好处。缺点二：局域网的同构应用程序  在许多应用中，全部的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，有两个服务器应用程序须要相互 通讯，或者有一个Win32或WinForm的客户程序要链接局域网上另外一个服务器的程序。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。 与此相相似，若是一个.NET程序要链接到局域网上的另外一个.NET程序，应该使用.NETremoting。有趣的是，在.NETremoting中， 也能够指定使用SOAP/HTTP来进行WebService调用。不过最好仍是直接经过TCP进行RPC调用，那样会有效得多。