Spring 框架 优势 1.提供了一种管理对象的方法,能够把中间层的对象有效地组织起来 2.采用了分层结构,能够增量引入到项目中。 3.代码测试较容易 4.非侵入性,应用程序对Spring API的依赖能够减至最小 5.轻量级的架构解决方案 6.一致的数据访问界面 缺点 1.由于spring使用了控制反转技术,因此应用程序的逻辑被中断,代码变得不完整,但看代码没法把握全部行为,不能了解整个系统流程。 2.流程控制由不少xml配置文件来实现,增长了出错的机会,以及开发人员的要求 3.维护阶段须要维护配置文件或者配置文件+代码的混合体,这比单纯地维护代码要困难的多 4.spring的性能通常,由于存在不少配置文件,须要读取这些文件来实现控制,性能略有损失。因此对于简单的应用,不推荐使用spring。Spring用于较复杂的应用 5.调试不直观,后期的Bug对应阶段不容易判断问题所在 XFire是一个开源的框架,能够很是容易得与spring集成。能够很简单地发布一个Web Service。能够将Web 服务绑定到POJO,XMLBeans。 支持基于HTTP、JXS等多种协议访问Web服务。 支持多种Web服务业界重要标准,例如SOAP、WSDL、Web服务寻址。 高性能的SOAP实现 服务器客户端代码辅助生成 Xfire使得WebService开发变得十分简单 Xfire使用Stax解析XML,性能有了质的提升。 XFire是基于SOAP/WSDL协议的,没法用于开发RESTful风格的Web Service Axis本质上就是一个SOAP引擎,提供客户端,服务器端和网管SOAP操做的基本框架。但Axis并不彻底是一个SOAP引擎,它仍是一个独立的SOAP服务器和一个嵌入Servlet引擎(例如Tomcat)的服务器。 Axis支持WSDL,提供转化WSDL为Java类的工具。提供例子程序。 Axis是与XFire并列的新一代Web Service框架,经过简单的API支持Web Service各项标准协议。 XFire与Axis相比,优势明显。 支持一系列Web Service的新标准 使用Stax解释XML,性能有了质的提升 容易上手,能够方便快速地从pojo发布服务 支持Spring 、Pico、Loom等容器 高性能SOAP栈设计 XFire比Axis1.3快2-6倍; XFire的响应时间是Axis1.3的1/2到1/5。 因此XFire比Axis相对受欢迎。 CXF 以上列举的都是传统的SOAP/WSDL模式的Web Service框架,接下来介绍几种实现了RESTful风格的一些Web Service框架 Spring3.0之后已经实现了对RESTful的支持。主要表如今: 1.注释,如@RequestMapping和@PathVariable,支持资源标识和URL映射 2.ContentNegotiatingViewResolver支持为不一样的MIME内容类型,并使用不一样的表示方式。 3.使用类似的编程模型无缝地整合到原始的MVC层 @Controller publicclass EmployeeController { @RequestMapping(method=RequestMethod.GET, value="/employee/{id}") public ModelAndView getEmployee(@PathVariable String id) { Employee e = employeeDS.get(Long.parseLong(id)); return new ModelAndView(XML_VIEW_NAME, "object", e); } } 如上@RequestMapping注释是Spring REST特性的关键所在。它指定所注释的方法将处理哪一个HTTP方法(RequestMethod.GET)和哪一个URI(/employee/{id})。注意: 1.对于{id}占位符,使用@PathVariable注释能够将{}内的值注入到函数的参数。 2.XML_VIEW_NAME为employees,这是在<servlet-name>-servlet.xml中定义的 对于其余方法是相似的。经过使用@RequestMapp注释的功能,处理不一样方法的代码是很是类似的 @RequestMapping(method=RequestMethod.POST, value="/employee") public ModelAndView addEmployee(@RequestBody String body) { Source source = new StreamSource(new StringReader(body)); Employee e = (Employee) jaxb2Mashaller.unmarshal(source); employeeDS.add(e); return new ModelAndView(XML_VIEW_NAME, "object", e); } @RequestMapping(method=RequestMethod.PUT, value="/employee/{id}") public ModelAndView updateEmployee(@RequestBody String body) { Source source = new StreamSource(new StringReader(body)); Employee e = (Employee) jaxb2Mashaller.unmarshal(source); employeeDS.update(e); return new ModelAndView(XML_VIEW_NAME, "object", e); } @RequestMapping(method=RequestMethod.DELETE, value="/employee/{id}") public ModelAndView removeEmployee(@PathVariable String id) { employeeDS.remove(Long.parseLong(id)); List<Employee> employees = employeeDS.getAll(); EmployeeList list = new EmployeeList(employees); return new ModelAndView(XML_VIEW_NAME, "employees", list); } 在上面的代码中,经过使用@RequestBody,HTTP请求的主体能够做为一个参数注入。 Spring3.0实现的RESTful Web Service仍然是基于MVC模型的,Control类中使用注释来处理对应的请求,返回的结果仍是要提交到View层渲染输出。在<servlet-name>-servlet.xml要配置内容协商服务。 <bean class="org.springframework.web.servlet.view .ContentNegotiatingViewResolver"> <property name="mediaTypes"> <map> <entry key="xml" value="application/xml"/> <entry key="html" value="text/html"/> </map></property> <property name="viewResolvers"> <list> <bean class="org.springframework.web.servlet.view .BeanNameViewResolver"/> <bean class="org.springframework.web.servlet.view .UrlBasedViewResolver"> <property name="viewClass" value= "org.springframework.web.servlet.view.JstlView"/> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean> </list> </property> </bean> 定义了两个视图解析器。BeanNameViewResolver是负责处理的application/xml的,而另外一个UrlBasedViewResolver则负责处理text/html。 用Spring3.0实现Restful Web Service的优缺点 1.拥有Spring的全部优势以及缺点 2.URl的映射在Control类中实现,不容易看出整个URI的结构(Restful Web Service的核心就在于URI的设计),也不利于修改,耦合度高 3.返回内容的协商在View层中实现,由view层调用相应的页面渲染,效率太低,而且意义不大,我认为应该在Control类中直接调用便可。 在编写Web Service时,我认为View层能够忽略,由于Web Service传输地都是数据,不是很须要View渲染。 Restlet也支持REST。 特色:彻底抛弃了Servlet API,做为替代,本身实现了一套API。可以支持复杂的REST架构设计。 缺点: 1.虽然也能够运行于Web容器中,可是难以利用Servlet和JSP等资源。还有由于须要另一套API和概念,学习成本较高。 2.彻底不支持服务器端的HTTP Session,强制彻底基于无状态服务器模型来作开发。对于基于浏览器的应用来讲,开发难度较高。 3.自身没有包括与Spring的集成,可使用第三方代码与Spring集成,集成难度较大。 4.文档不丰富,学习起来较困难。 5.没有内建的国际支持 优势: 1.有内建的HTTP认证机制,不须要另外开发安全机制 2.灵活性较高,支持更多的REST概念,支持透明的内容协商,适合于开发更强大的REST组件 3.零配置文件,所有配置经过代码完成 Cetia4是一个对REST提供完善支持的Web开发框架 特色:基于Servlet API开发,能够运行于全部的Web容器中 优势: 1.能够充分利用Servlet API和JSP等资源,须要额外学习的概念较少,学习成本较低。 2.对于传统的Web应用,可使用服务器端的HTTP Session;对于Web服务类应用,不使用HTTP Session,基于无状态服务器模型作开发。 3.自身包括了对于Web MVC的支持 4.内建了本身特有的导航对象栈的概念,对于传统的Web应用开发很是有帮助。 5. 提供了JSP标签库,对于传统的基于HTML表单的Web开发很是有帮助。 6. 支持与SiteMesh相配合,由SiteMesh来支持页面布局的重用。 7. 内建有与Spring的集成,集成起来很是容易。 8. 配置文件彻底基于标准的web.xml,不须要额外的配置文件。大量使用默认配置,通常状况下足以知足常见的需求。 9. 拥有很好的文档。 10. 有内建的国际化支持。 缺点: 1.没有内建的HTTP认证机制,须要本身开发安全机制。 2.对于内容协商的支持比较弱,仅支持HTML和XML格式的数据。须要加以扩展才能支持其它格式的表现 Axis2,同时支持SOAP和REST风格的Web Service。但缺点很明显, 1.仅仅支持GET与POST方法 2.仅仅是以REST风格暴露出Web服务,数据格式仍然是包含SOAP封装的XML 3.只支持同步的调用方式 4.仅仅提供了以SOAP方式暴露Web服务的最小化支持,不支持全面的REST架构设计。 sqlREST,特色:1.为任何能够经过JDBC访问的数据库提供Web服务访问接口,自动将REST风格的HTTP请求转换成数据库SQL语句。2.基于Servlet API开发 缺点: 1.由于是REST风格的HTTP请求到SQL语句的直接映射,所以强制使用以SQL和关系数据库为中心的数据建模设计方法,不支持面向对象的设计。 2.由于资源的定义仅限于数据库的表,难以实现更高层次的抽象,必然会致使很是细粒度的API。应用的性能以及可伸缩性都难以保证。 Sun正在致力于创建REST风格Web服务的规范,JAX—RS(Java API for RESTful Web Service) JAX-RS提供一些标注将一个资源类,一个 POJO Java类,封装成Web资源。 @Path,标注资源类或方法的相对路径 @GET,@PUT,@POST,@DELETE,标注方法是用的HTTP请求的类型 @Produces,标注返回的MIME媒体类型 @Consumes,标注可接受请求的MIME媒体类型 @PathParam,@QueryParam,@HeaderParam,@CookieParam。@MatrixParam,@FormParam分别标注方法的参数来自于HTTP请求的不一样位置,例如@PathParam来自于URL的路径,@QueryParam来自于URL的查询参数,@HeaderParam来自于HTTP请求的头信息,@CookieParam来自HTTP请求的Cookie。 Jersey是JAX-RS的参考实现,即Jersey不是基于Servlet API的,而是采用了JAX-RS API。 1.Jersey采用了Annotation机制,全部的HTTP相关的参数设置都采用标注实现,所以,在编程的时候咱们针对的仍然是POJO,体会不到分布式或J2EE编程的痛苦,只须要了解一些关键的Annotation便可。 2.Jersey是一个开发的平台,咱们能够扩展本身的需求,好比在消息格式上,虽然Jersey已经提供了Java基本数据类型、JSON、XML等类型,咱们仍是能够很容易地扩展本身的格式。 3.Jersey创建的服务能够很简单地部署到JDK6自带的轻量级Server上,过程极其简单 4.Jersey创建的服务能够很是容易地部署为Servlet,支持各类J2EE容器 5.Jersey能够为咱们编写的服务自动生成WADL 6.支持Spring。