java后台框架以及协议报告.docx
《java后台框架以及协议报告.docx》由会员分享，可在线阅读，更多相关《java后台框架以及协议报告.docx（17页珍藏版）》请在冰豆网上搜索。
java后台框架以及协议报告
基于soa架构的主要应用框架之间的对比
一、目前很多公司常用的框架大致有以下几种，本报告主要罗列出这些框架的优缺点，并进行对比分析，从而进行择优使用。
二、框架的优缺点
1、Spring框架的优点：
Spring框架的缺点：
2、Hibernate框架的优点：
Hibernate框架的缺点：
3、Struts框架的优点：
Struts框架的缺点：
4、SpringMVC框架的优点：
SpringMVC框架的缺点：
5、Tapestry的优点：
Tapestry的缺点：
6、Stripes的优点：
Stripes的缺点：
7、maven的优点：
Maven的缺点：
8、Augularjs的优点：
Augularjs的缺点：
9、Wicket的优点：
Wicket的缺点：
10、Mybatis的优点：
Mybatis的缺点：
三、对比分析：
1、关于SSH与SpringMVC的对比：
Ssh三大框架和springMvc的对比
Ssh
springMVC
1、ssh中的spring充当的是MVC中的Model的职能，他也可以集成hibernate等，但它不提供hibernate的功能，仅为集成。
2、SpringMVC是MVC架构的整体实现，包括了MVC三项框架，有了它你就不需要再去集成struts和hibernate了，都是由它自己提供。
springMvc和Srtuts2的对比
SpringMVC
Struts2
1.springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应
2.spring3mvc开发效率高于struts
3.spring3mvc可以认为已经100%零配置
4.从架构本身上spring3mvc就容易实现restfulurl
5.spring3mvc的方法之间基本上独立的，独享requestresponse数据
请求数据通过参数获取，处理结果通过ModelMap交回给框架
方法之间不共享变量
1、struts2是类级别的拦截，一个类对应一个request上下文
2、struts2的架构实现起来要费劲
3、struts2action的一个方法可以对应一个url
而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了
4、struts2虽然方法之间也是独立的，但其所有Action变量是共享的
5、由于Struts2需要针对每个Request进行封装，把Request，Session等Servlet生命周期的变量封装成一个一个Map，
供给每个Action使用，并保证线程安全。
所以在原则上，是比较耗费内存的
因此：
原则上来说，SpringMVC可以替代掉原始的SSH框架
四、关于java后台通信的协议和规范：
基本原理
要实现网络机器间的通讯，首先得来看看计算机系统网络通信的基本原理，在底层层面去看，网络通信需要做的就是将流从一台计算机传输到另外一台计算机，基于传输协议和网络IO来实现，其中传输协议比较出名的有http、tcp、udp等等，http、tcp、udp都是在基于Socket概念上为某类应用场景而扩展出的传输协议，网络IO，主要有bio、nio、aio三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用，各种语言通常都会提供一些更为贴近应用易用的应用层协议
应用级协议
远程服务通讯，需要达到的目标是在一台计算机发起请求，另外一台机器在接收到请求后进行相应的处理并将结果返回给请求端，这其中又会有诸如onewayrequest、同步请求、异步请求等等请求方式，按照网络通信原理，需要实现这个需要做的就是将请求转换成流，通过传输协议传输至远端，远端计算机在接收到请求的流后进行处理，处理完毕后将结果转化为流，并通过传输协议返回给调用端。
原理是这样的，但为了应用的方便，业界推出了很多基于此原理之上的应用级的协议，使得大家可以不用去直接操作这么底层的东西，通常应用级的远程通信协议会提供：
1、为了避免直接做流操作这么麻烦，提供一种更加易用或贴合语言的标准传输格式；
2、网络通信机制的实现，就是替你完成了将传输格式转化为流，通过某种传输协议传输至远端计算机，远端计算机在接收到流后转化为传输格式，并进行存储或以某种方式通知远端计算机。
传输协议则通常都是可选的，在java领域中知名的有：
RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS
（一）各协议的概念：
（1）RMI
RMI是个典型的为java定制的远程通信协议，我们都知道，在singlevm中，我们可以通过直接调用javaobjectinstance来实现通信，那么在远程通信时，如果也能按照这种方式当然是最好了，这种远程通信的机制成为RPC（RemoteProcedureCall），RMI正是朝着这个目标而诞生的。
（2）XML-RPC
XML-RPC也是一种和RMI类似的远程调用的协议，它和RMI的不同之处在于它以标准的xml格式来定义请求的信息（请求的对象、方法、参数等），这样的好处是什么呢，就是在跨语言通讯的时候也可以使用。
来看下XML-RPC协议的一次远程通信过程：
1、客户端发起请求，按照XML-RPC协议将请求信息进行填充；
2、填充完毕后将xml转化为流，通过传输协议进行传输；
3、接收到在接收到流后转换为xml，按照XML-RPC协议获取请求的信息并进行处理；
4、处理完毕后将结果按照XML-RPC协议写入xml中并返回。
（3）Binary-RPC
Binary-RPC看名字就知道和XML-RPC是差不多的了，不同之处仅在于传输的标准格式由XML转为了二进制的格式。
（4）SOAP
SOAP原意为SimpleObjectAccessProtocol，是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议，可以认为SOAP是XMLRPC的高级版，两者的原理完全相同，都是http+XML，不同的仅在于两者定义的XML规范不同，SOAP也是Webservice采用的服务调用协议标准，因此在此就不多加阐述了。
（5）JMS
JMS是实现java领域远程通信的一种手段和方法，基于JMS实现远程通信时和RPC是不同的，虽然可以做到RPC的效果，但因为不是从协议级别定义的，因此我们不认为JMS是个RPC协议，但它确实是个远程通信协议，在其他的语言体系中也存在着类似JMS的东西，可以统一的将这类机制称为消息机制，而消息机制呢，通常是高并发、分布式领域推荐的一种通信机制，这里的主要一个问题是容错（详细见ErLang论文）。
（6）JBoss-Remoting
Jboss-remoting是由jboss编写的一个java领域的远程通讯框架，基于此框架，可以很简单的实现基于多种传输协议的java对象的RPC。
（7）Spring-Remoting
Spring-remoting是Spring提供java领域的远程通讯框架，基于此框架，同样也可以很简单的将普通的springbean以某种远程协议的方式来发布，同样也可以配置springbean为远程调用的bean。
（8）Hessian
Hessian是由caucho提供的一个基于binary-RPC实现的远程通讯library。
（9）Burlap
Burlap也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC协议的。
（10）XFire、Axis
XFire、Axis是Webservice的实现框架，WebService可算是一个完整的SOA架构实现标准了，因此采用XFire、Axis这些也就意味着是采用webservice方式了。
（11）ActiveMQ
ActiveMQ是JMS的实现，基于JMS这类消息机制实现远程通讯是一种不错的选择，毕竟消息机制本身的功能使得基于它可以很容易的去实现同步/异步/单向调用等，而且消息机制从容错角度上来说也是个不错的选择，这是Erlang能够做到容错的重要基础。
（12）Mina
Mina是Apache提供的通讯框架，在之前一直没有提到网络IO这块，之前提及的框架或library基本都是基于BIO的，而Mina是采用NIO的，NIO在并发量增长时对比BIO而言会有明显的性能提升，而java性能的提升，与其NIO这块与OS的紧密结合是有不小的关系的。
（13）EJB
EJB最突出的在于其分布式，EJB采用的是ORMI协议，和RMI协议是差不多的，但EJB在分布式通讯的安全控制、transportpool、smartproxy等方面的突出使得其在分布式领域是不可忽视的力量。
（二）通信原理：
问题
名称
传输的标准格式是什么？
怎么样将请求转化为传输的流？
怎么接收和处理流？
传输协议是？
RMI
JavaObjectStream
基于Java串行化机制将请求的javaobject信息转化为流
根据采用的协议启动相应的监听端口，当有流进入后基于Java串行化机制将流进行反序列化，并根据RMI协议获取到相应的处理对象信息，进行调用并处理，处理完毕后的结果同样基于java串行化机制进行返回。
4、传输协议是？
Socket
XML-RPC
标准格式的XML
将XML转化为流
通过监听的端口获取到请求的流，转化为XML，并根据协议获取请求的信息，进行处理并将结果写入XML中返回。
Http
Binary-RPC
标准格式的二进制文件
将二进制格式文件转化为流
通过监听的端口获取到请求的流，转化为二进制文件，根据协议获取请求的信息，进行处理并将结果写入二进制文件中返回
Http
SOAP
JMS
JMS规定的Message
将参数信息放入Message中
轮训JMSQueue来接收Message，接收到后进行处理，处理完毕后仍然是以Message的方式放入Queue中发送或Multicast
不限。
基于JMS也是常用的实现远程异步调用的方法之一
JBoss-Remoting
JBoss-Remoting是个通讯框架，因此它支持多种协议方式的通信，例如纯粹的socket+io方式、rmi方式、http+io方式等
在JBoss-Remoting中，只需将需要发起的请求参数对象传入jboss-remoting的InvocationRequest对象即可，也可根据协议基于InvocationRequest封装符合需求的InvocationRequest对象
JBoss-Remoting基于Java串行化机制或JBoss自己的串行化实现来将请求转化为对象字节流
支持多种传输协议，例如socket、http等
-Spring-Remoting
和JBoss-Remoting一样，作为一个远程通讯的框架，Spring通过集成多种远程通讯的library，从而实现了对多种协议的支持，例如rmi、http+io、xml-rpc、binary-rpc等
在Spring中，由于其对于远程调用的bean采用的是proxy实现，发起请求完全是通过服务接口调用的方式
Spring按照协议方式将请求的对象信息转化为流，例如SpringHttpInvoker是基于Spring自己定义的一个协议来实现的，传输协议上采用的为http，请求信息是基于java串行化机制转化为流进行传输
支持多种传输协议，例如rmi、http等等
Hessian
基于Binary-RPC协议实现
需通过Hessian本身提供的API来发起请求
Hessian通过其自定义的串行化机制将请求信息进行序列化，产生二进制流
Hessian基于Http协议进行传输
Burlap
基于XML-RPC协议实现
根据Burlap提供的API
将请求信息转化为符合协议的XML格式，转化为流进行传输。
Http协议
XFire、Axis
基于SOAP协议
获取到远端service的proxy后直接调用
将请求信息转化为遵循SOAP协议的XML格式，由框架转化为流进行传输
Http协议
ActiveMQ
基于JMS协议
遵循JMSAPI发起请求
二进制流
支持多种传输协议，例如socket、http等等
Mina
基于纯粹的Socket+NIO
通过Mina提供的ClientAPI
Mina遵循java串行化机制对请求对象进行序列化
支持多种传输协议，例如socket、http等等
EJB
基于ORMI协议
EJB调用
遵循java串行化机制对请求对象进行序列化
Socket
（三）比较RMI，Hessian，Burlap，Httpinvoker，Webservice等5种通讯协议的在不同的数据结构和不同数据量时的传输性能。
1.简介
RMI是java语言本身提供的远程通讯协议，稳定高效，是EJB的基础。
但它只能用于JAVA程序之间的通讯。
Hessian和Burlap是caucho公司提供的开源协议，基于HTTP传输，服务端不用开防火墙端口。
协议的规范公开，可以用于任意语言。
Httpinvoker是SpringFramework提供的远程通讯协议，只能用于JAVA程序间的通讯，且服务端和客户端必须使用SpringFramework。
Webservice是连接异构系统或异构语言的首选协议，它使用SOAP形式通讯，可以用于任何语言，目前的许多开发工具对其的支持也很好。
2.测试结果
测试结果显示，几种协议的通讯效率依次为：
RMI>Httpinvoker>=Hessian>>Burlap>>Webservice
RMI不愧是JAVA的首选远程调用协议，非常高效稳定，特别是在大数据量的情况下，与其他通讯协议的差距尤为明显。
Httpinvoker使用java的序列化技术传输对象，与RMI在本质上是一致的。
从效率上看，两者也相差无几，Httpinvoker与RMI的传输时间基本持平。
Hessian在传输少量对象时，比RMI还要快速高效，但传输数据结构复杂的对象或大量数据对象时，较RMI要慢20%左右。
Burlap仅在传输1条数据时速度尚可，通常情况下，它的耗时是RMI的3倍。
WebService的效率低下是众所周知的，平均来看，WebService的通讯毫时是RMI的10倍。
3.结果分析
1、直接调用
直接调用的所有毫时都接近0，这说明程序处理几乎没有花费时间，记录的全部时间都是远程调用耗费的。
2、RMI调用
与设想的一样，RMI理所当然是最快的，在几乎所有的情况下，它的耗时都是最少的。
特别是在数据结构复杂，数据量大的情况下，与其他协议的差距尤为明显。
3、Hessian调用
caucho公司的resin服务器号称是最快的服务器，在java领域有一定的知名度。
Hessian做为resin的组成部分，其设计也非常精简高效，实际运行情况也证明了这一点。
平均来看，Hessian较RMI要慢20%左右，但这只是在数据量特别大，数据结构很复杂的情况下才能体现出来，中等或少量数据时，Hessian并不比RMI慢。
Hessian的好处是精简高效，可以跨语言使用，而且协议规范公开，我们可以针对任意语言开发对其协议的实现。
目前已有实现的语言有：
java,c++,.net,python,ruby。
另外，Hessian与WEB服务器结合非常好，借助WEB服务器的成熟功能，在处理大量用户并发访问时会有很大优势，在资源分配，线程排队，异常处理等方面都可以由成熟的WEB服务器保证。
而RMI本身并不提供多线程的服务器。
而且，RMI需要开防火墙端口，Hessian不用。
4、Burlap调用
Burlap与Hessian都是caucho公司的开源产品，只不过Hessian采用二进制的方式，而Burlap采用xml的格式。
测试结果显示，Burlap在数据结构不复杂，数据量中等的情况下，效率还是可以接受的，但如果数据量大，效率会急剧下降。
平均计算，Burlap的调用耗时是RMI的3倍。
我认为，其效率低有两方面的原因，一个是XML数据描述内容太多，同样的数据结构，其传输量要大很多；另一方面，众所周知，对xml的解析是比较费资源的，特别对于大数据量情况下更是如此。
5、HttpInvoker调用
HttpInvoker是SpringFramework提供的JAVA远程调用方法，使用java的序列化机制处理对象的传输。
从测试结果看，其效率还是可以的，与RMI基本持平。
不过，它只能用于JAVA语言之间的通讯，而且，要求客户端和服务端都使用Spring框架。
另外，HttpInvoker并没有经过实践的检验，目前还没有找到应用该协议的项目。
6、Webservice调用
本次测试选用了apache的AXIS组件作为Webservice 的实现，AXIS在Webservice领域相对成熟老牌。
为了仅测试数据传输和编码、解码的时间，客户端和服务端都使用了缓存，对象只需实例化一次。
但是，测试结果显示，Webservice的效率还是要比其他通讯协议慢10倍。
如果考虑到多个引用指向同一对象的传输情况，Webservice要落后更多。
因为RMI，Hessian等协议都可以传递引用，而webservice有多少个引用，就要复制多少份对象实体。
Webservice传输的冗余信息过多是其速度慢的原因之一，监控发现，同样的访问请求，描述相同的数据，Webservice返回的数据量是hessian协议的6.5倍。
另外，Webservice的处理也很耗时，目前的xml解析器效率普遍不高，处理xml<->bean很毫资源。
从测试结果看，异地调用比本地调用要快，也从侧面说明了其毫时主要用在编码和解码xml文件上。
这比冗余信息更为严重，冗余信息占用的只是网络带宽，而每次调用的资源耗费直接影响到服务器的负载能力。
五、总结：
本文主要阐述了现在一些主流框架的优缺点，以及一些后台服务的通信协议与规范，并且针对于SSH和SpringMVC框架做了对比，觉得SpringMVC比SSH更实用。
同时比较了RMI，Hessian，Burlap，Httpinvoker，Webservice等5种通讯协议的在不同的数据结构和不同数据量时的传输性能。
的出的结论是，几种协议的通讯效率依次为：
RMI>Httpinvoker>=Hessian>>Burlap>>Webservice。
升级会员 