Java远程通讯技术及原理Word格式.docx
《Java远程通讯技术及原理Word格式.docx》由会员分享,可在线阅读,更多相关《Java远程通讯技术及原理Word格式.docx(14页珍藏版)》请在冰豆网上搜索。
4、传输协议是?
不过应用级的远程通信协议并不会在传输协议上做什么多大的改进,主要是在流操作方面,让应用层生成流和处理流的这个过程更加的贴合所使用的语言或标准,至于传输协议则通常都是可选的,在java领域中知名的有:
RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS,来具体的看看这些远程通信的应用级协议:
------------------------------------------------------------------------------------------------
RMI
RMI是个典型的为java定制的远程通信协议,我们都知道,在singlevm中,我们可以通过直接调用javaobjectinstance来实现通信,那么在远程通信时,如果也能按照这种方式当然是最好了,这种远程通信的机制成为RPC(RemoteProcedureCall),RMI正是朝着这个目标而诞生的。
来看下基于RMI的一次完整的远程通信过程的原理:
1、客户端发起请求,请求转交至RMI客户端的stub类;
2、stub类将请求的接口、方法、参数等信息进行序列化;
3、基于tcp/ip将序列化后的流传输至服务器端;
4、服务器端接收到流后转发至相应的skelton类;
5、skelton类将请求的信息反序列化后调用实际的处理类;
6、处理类处理完毕后将结果返回给skelton类;
7、Skelton类将结果序列化,通过tcp/ip将流传送给客户端的stub;
8、stub在接收到流后反序列化,将反序列化后的JavaObject返回给调用者。
来看jboss-remoting对于此过程的一个更好的图示:
根据原理来回答下之前学习应用级协议带着的几个问题:
是JavaObjectStream。
基于Java串行化机制将请求的javaobject信息转化为流。
根据采用的协议启动相应的监听端口,当有流进入后基于Java串行化机制将流进行反序列化,并根据RMI协议获取到相应的处理对象信息,进行调用并处理,处理完毕后的结果同样基于java串行化机制进行返回。
tcp/ip。
XML-RPC
XML-RPC也是一种和RMI类似的远程调用的协议,它和RMI的不同之处在于它以标准的xml格式来定义请求的信息(请求的对象、方法、参数等),这样的好处是什么呢,就是在跨语言通讯的时候也可以使用。
来看下XML-RPC协议的一次远程通信过程:
1、客户端发起请求,按照XML-RPC协议将请求信息进行填充;
2、填充完毕后将xml转化为流,通过传输协议进行传输;
3、接收到在接收到流后转换为xml,按照XML-RPC协议获取请求的信息并进行处理;
4、处理完毕后将结果按照XML-RPC协议写入xml中并返回。
图示以上过程:
同样来回答问题:
1、传输的标准格式是?
标准格式的XML。
将XML转化为流。
通过监听的端口获取到请求的流,转化为XML,并根据协议获取请求的信息,进行处理并将结果写入XML中返回。
Http。
Binary-RPC
Binary-RPC看名字就知道和XML-RPC是差不多的了,不同之处仅在于传输的标准格式由XML转为了二进制的格式。
标准格式的二进制文件。
将二进制格式文件转化为流。
通过监听的端口获取到请求的流,转化为二进制文件,根据协议获取请求的信息,进行处理并将结果写入XML中返回。
--------------------------------------------------------------------------------------------------------------------------------------------------
SOAP
SOAP原意为SimpleObjectAccessProtocol,是一个用于分布式环境的、轻量级的、基于XML进行信息交换的通信协议,可以认为SOAP是XMLRPC的高级版,两者的原理完全相同,都是http+XML,不同的仅在于两者定义的XML规范不同,SOAP也是Webservice采用的服务调用协议标准,因此在此就不多加阐述了。
CORBA
Common
Object
Request
Broker
Architecture(公用对象请求代理[调度]程序体系结构),是一组用来定义"
分布式对象系统"
的标准,由OMG(Object
Menagement
Group)作为发起和标准制定单位。
CORBA的目的是定义一套协议,符合这个协议的对象可以互相交互,不论它们是用什么样的语言写的,不论它们运行于什么样的机器和操作系统。
CORBA在我看来是个类似于SOA的体系架构,涵盖可选的远程通信协议,但其本身不能列入通信协议这里来讲,而且CORBA基本淘汰,再加上对CORBA也不怎么懂,在此就不进行阐述了。
JMS
JMS呢,是实现java领域远程通信的一种手段和方法,基于JMS实现远程通信时和RPC是不同的,虽然可以做到RPC的效果,但因为不是从协议级别定义的,因此我们不认为JMS是个RPC协议,但它确实是个远程通信协议,在其他的语言体系中也存在着类似JMS的东西,可以统一的将这类机制称为消息机制,而消息机制呢,通常是高并发、分布式领域推荐的一种通信机制,这里的主要一个问题是容错(详细见ErLang论文)。
来看JMS中的一次远程通信的过程:
1、客户端将请求转化为符合JMS规定的Message;
2、通过JMSAPI将Message放入JMSQueue或Topic中;
3、如为JMSQueue,则发送中相应的目标Queue中,如为Topic,则发送给订阅了此Topic的JMSQueue。
4、处理端则通过轮训JMSQueue,来获取消息,接收到消息后根据JMS协议来解析Message并处理。
回答问题:
JMS规定的Message。
将参数信息放入Message中即可。
轮训JMSQueue来接收Message,接收到后进行处理,处理完毕后仍然是以Message的方式放入Queue中发送或Multicast。
不限。
基于JMS也是常用的实现远程异步调用的方法之一。
可选实现技术
当然,在上面的原理中并没有介绍到所有的java领域可选的远程通信协议了,例如还有EJB采用的ORMI、Spring自己定义的一个简单的HttpInvoker等等。
看完原理后我们再来看看目前java领域可用于实现远程通讯的框架或library,知名的有:
JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire(Axis)、ActiveMQ、Mina、Mule、EJB3等等,来对每种做个简单的介绍和评价,其实呢,要做分布式服务框架,这些东西都是要有非常深刻的了解的,因为分布式服务框架其实是包含了解决分布式领域以及应用层面领域两方面问题的。
当然,你也可以自己根据远程网络通信原理(transportprotocol+NetIO)去实现自己的通讯框架或library。
那么在了解这些远程通讯的框架或library时,会带着什么问题去学习呢?
1、是基于什么协议实现的?
2、怎么发起请求?
3、怎么将请求转化为符合协议的格式的?
4、使用什么传输协议传输?
5、响应端基于什么机制来接收请求?
6、怎么将流还原为传输格式的?
7、处理完毕后怎么回应?
JBoss-Remoting
Jboss-remoting是由jboss编写的一个java领域的远程通讯框架,基于此框架,可以很简单的实现基于多种传输协议的java对象的RPC。
直接来回答问题:
JBoss-Remoting是个通讯框架,因此它支持多种协议方式的通信,例如tcp/ip+io方式、rmi方式、http+io方式等。
在JBoss-Remoting中,只需将需要发起的请求参数对象传入jboss-remoting的InvocationRequest对象即可,也可根据协议基于InvocationRequest封装符合需求的InvocationRequest对象。
JBoss-Remoting基于Java串行化机制或JBoss自己的串行化实现来将请求转化为对象字节流。
支持多种传输协议,例如tcp/ip、http等。
响应端只需将自己的处理对象注册到JBoss-Remoting提供的server端的Connector对象中即可。
JBoss-Remoting基于java串行化机制或jboss自己的串行化实现来将请求信息还原为java对象。
处理完毕后将结果对象直接返回即可,jboss-remoting会将此对象按照协议进行序列化,返回至调用端。
另外,jboss-remoting支持多种通信方式,例如同步/异步/单向通信等。
Spring-Remoting
Spring-remoting是Spring提供java领域的远程通讯框架,基于此框架,同样也可以很简单的将普通的springbean以某种远程协议的方式来发布,同样也可以配置springbean为远程调用的bean。
和JBoss-Remoting一样,作为一个远程通讯的框架,Spring通过集成多种远程通讯的library,从而实现了对多种协议的支持,例如rmi、http+io、xml-rpc、binary-rpc等。
在Spring中,由于其对于远程调用的bean采用的是proxy实现,发起请求完全是通过服务接口调用的方式。
Spring按照协议方式将请求的对象信息转化为流,例如SpringHttpInvoker是基于Spring自己定义的一个协议来实现的,传输协议上采用的为http,请求信息是基于java串行化机制转化为流进行传输。
支持多种传输协议,例如rmi、http等等。
响应端遵循协议方式来接收请求,对于使用者而言,则只需通过spring的配置方式将普通的springbean配置为响应端或者说提供服务端。
按照协议方式来进行还原。
处理完毕后直接返回即可,spring-remoting将根据协议方式来做相应的序列化。
Hessian
Hessian是由caucho提供的一个基于binary-RPC实现的远程通讯library。
基于Binary-RPC协议实现。
需通过Hessian本身提供的API来发起请求。
Hessian通过其自定义的串行化机制将请求信息进行序列化,产生二进制流。
Hessian基于Http协议进行传输。
响应端根据Hessian提供的API来接收请求。
Hessian根据其私有的串行化机制来将请求信息进行反序列化,传递给使用者时已是相应的请求信息对象了。
处理完毕后直接返回,hessian将结果对象进行序列化,传输至调用端。
Burlap
Burlap也是有caucho提供,它和hessian的不同在于,它是基于XML-RPC协议的。
基于XML-RPC协议实现。
根据Burlap提供的API。
将请求信息转化为符合协议的XML格式,转化为流进行传输。
Http协议。
监听Http请求。
根据XML-RPC协议进行还原。
返回结果写入XML中,由Burlap返回至调用端。
XFire、Axis
XFire、Axis是Webservice的实现框架,WebService可算是一个完整的SOA架构实现标准了,因此采用XFire、Axis这些也就意味着是采用webservice方式了。
基于SOAP协议。
获取到远端service的proxy后直接调用。
将请求信息转化为遵循SOAP协议的XML格式,由框架转化为流进行传输。
根据SOAP协议进行还原。
返回结果写入XML中,由框架返回至调用端。
ActiveMQ
ActiveMQ是JMS的实现,基于JMS这类消息机制实现远程通讯是一种不错的选择,毕竟消息机制本身的功能使得基于它可以很容易的去实现同步/异步/单向调用等,而且消息机制从容错角度上来说也是个不错的选择,这是Erlang能够做到容错的重要基础。
基于JMS协议。
遵循JMSAPI发起请求。
不太清楚,猜想应该是二进制流。
支持多种传输协议,例如tcp/ip、udp、http等等。
监听符合协议的端口。
同问题3。
遵循JMSAPI生成消息,并写入JMSQueue中。
基于JMS此类机制实现远程通讯的例子有Spring-Intergration、Mule、Lingo等等。
Mina
Mina是Apache提供的通讯框架,在之前一直没有提到网络IO这块,之前提及的框架或library基本都是基于BIO的,而Mina是采用NIO的,NIO在并发量增长时对比BIO而言会有明显的性能提升,而java性能的提升,与其NIO这块与OS的紧密结合是有不小的关系的。
可选的传输协议+NIO。
通过Mina提供的ClientAPI。
Mina遵循java串行化机制对请求对象进行序列化。
支持多种传输协议,例如tcp/ip、http等等。
以NIO的方式监听协议端口。
遵循java串行化机制对请求对象进行反序列化。
遵循MinaAPI进行返回。
MINA是NIO方式的,因此支持异步调用是毫无悬念的。
------