Javaweb

一、原生jdbc操做数据库流程

第一步： Class.forName()加载数据库毗连驱动；

第二步： DriverManager.getConnection()获取数据毗连对象;

第三步：按照 SQL 获取 sql 会话对象，有 2 种体例 Statement、 PReparedStatement ;

第四步：施行 SQL 处置成果集，施行 SQL 前若是有参数值就设置参数值 setXXX();

第五步：封闭成果集、封闭会话、封闭毗连

二、为什么要利用 PreparedStatement

1、 PreparedStatement 接口继承 Statement， PreparedStatement 实例包罗已编译的 SQL 语句，所以其施行速度要快于 Statement 对象。

2 、做为 Statement 的子类， PreparedStatement 继承了 Statement 的所有功用。三种方

法 execute、 executeQuery 和 executeUpdate 已被更改以使之不再需要参数。

3、在 JDBC 应用中,在任何时候都不要利用 Statement，原因如下：

一、代码的可读性和可维护性.Statement 需要不竭地拼接，而 PreparedStatement 不会。

二、 PreparedStatement 尽更大可能进步性能.DB 有缓存机造，不异的预编译语句再次被挪用不会再次需要编译。

三、最重要的一点是极大地进步了平安性.Statement 容易被 SQL 注入，而 PreparedStatementc 传入的内容不会和 sql 语句发作任何婚配关系。

三、关系数据库中毗连池的机造是什么

前提：为数据库毗连成立一个缓冲池。

1：从毗连池获取或创建可用毗连

2：利用完毕之后，把毗连返回给毗连池

3：在系统封闭前，断开所有毗连并释放毗连占用的系统资本

4：可以处置无效毗连，限造毗连池中的毗连总数不低于或者不超越某个限制值。

此中有几个概念需要各人理解：

最小毗连数是毗连池不断连结的数据毗连。若是应用法式对数据库毗连的利用量不大，将会有大量的数据库毗连资本被浪费掉。

更大毗连数是毗连池能申请的更大毗连数。若是数据毗连恳求超越此数，后面的数据毗连恳求将被参加到期待队列中，那会影响之后的数据库操做。

若是最小毗连数与更大毗连数相差太大，那么，更先的毗连恳求将会获利，之后超越最小毗连数量的毗连恳求等价于成立一个新的数据库毗连。不外，那些大于最小毗连数的数据库毗连在利用完不会马上被释放，它将被放到毗连池中期待反复利用或是空闲超时后被释放。

上面的解释，能够如许理解：数据库池毗连数量不断连结一个很多于最小毗连数的数量，当数量不敷时，数据库会创建一些毗连，曲到一个更大毗连数，之后毗连数据库就会期待。

四、http 的长毗连和短毗连

HTTP 协议有 HTTP/1.0 版本和 HTTP/1.1 版本。 HTTP1.1 默认连结长毗连（HTTP PErsistentconnection，也翻译为耐久毗连），数据传输完成了连结 TCP 毗连不竭开（不发 RST 包、不四次握手），期待在同域名下继续用那个通道传输数据；相反的就是短毗连。

在 HTTP/1.0 中，默认利用的是短毗连。也就是说，阅读器和办事器每停止一次 HTTP 操做，就成立一次毗连，使命完毕就中断毗连。从 HTTP/1.1 起，默认利用的是长毗连，用以连结毗连特征。

五、HTTP/1.1 与 HTTP/1.0 的区别

可扩展性

a) HTTP/1.1 在动静中增加版本号，用于兼容性判断。

b) HTTP/1.1 增加了 OPTIONS 办法，它允许客户端获取一个办事器撑持的办法列表。

c) 为了与将来的协议标准兼容， HTTP/1.1 在恳求动静中包罗了 Upgrade 头域，通过该头域，客户端能够让办事器晓得它可以撑持的其它备用通信协议，办事器能够据此停止协议切换，利用备用协议与客户端停止通信。

缓存

在 HTTP/1.0 中，利用 Expire 头域来判断资本的 fresh 或 stale，并利用前提恳求（conditionalrequest）来判断资本能否仍有效。 HTTP/1.1 在 1.0 的根底上参加了一些 cache 的新特征，当缓存对象的 Age 超越 Expire 时变stale 对象， cache 不需要间接丢弃 stale 对象，而是与源办事器停止从头激活（revalidation）。

带宽优化

HTTP/1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部门，而办事器却将整个对象送过来了。例如，客户端只需要显示一个文档的部门内容，又好比下载大文件时需要撑持断点续传功用，而不是在发作断连后不能不从头下载完好的包。HTTP/1.1 中在恳求动静中引入了 range 头域，它允许只恳求资本的某个部门。在响应动静中 Content-Range 头域声了然返回的那部门对象的偏移值和长度。若是办事器响应地返回了对象所恳求范畴的内容，则响应码为 206（Partial Content），它能够避免 Cache 将响应误认为是完好的一个对象。别的一种情况是恳求动静中若是包罗比力大的实体内容，但不确定办事器能否可以领受该恳求（如能否有权限），此时若贸然发出带实体的恳求，若是被回绝也会浪费带宽。HTTP/1.1 参加了一个新的形态码 100（Continue）。客户端事先发送一个只带头域的恳求，若是办事器因为权限回绝了恳求，就回送响应码 401（Unauthorized）；若是办事器领受此恳求就回送响应码 100，客户端就能够继续发送带实体的完好恳求了。留意， HTTP/1.0 的客户端不撑持 100 响应码。但能够让客户端在恳求动静中参加 Expect头域，并将它的值设置为 100-continue。节省带宽资本的一个十分有效的做法就是压缩要传送的数据。 Content-Encoding 是抵消息停止端到端（end-toend）的编码，它可能是资本在办事器上保留的固有格局（如 jpeg 图片格局）；在恳求动静中参加 Accept-Encoding头域，它能够告诉办事器客户端可以解码的编码体例

长毗连

HTTP/1.0 规定阅读器与办事器只连结短暂的毗连，阅读器的每次恳求都需要与办事器成立一个 TCP 毗连，办事器完成恳求处置后立即断开 TCP 毗连，办事器不跟踪每个客户也不记录过去的恳求。此外，因为大大都网页的流量都比力小，一次 TCP 毗连很少能通过 slow-start 区，倒霉于进步带宽操纵率。HTTP 1.1 撑持长毗连（PersistentConnection）和恳求的流水线（Pipelining）处置，在一个 TCP 毗连上能够传送多个 HTTP 恳求和响应，削减了成立和封闭毗连的消耗和延迟。例如：一个包罗有许多图像的网页文件的多个恳求和应答能够在一个毗连中传输，但每个零丁的网页文件的恳求和应答仍然需要利用各自的毗连。

HTTP 1.1 还允许客户端不消期待上一次恳求成果返回，就能够发出下一次恳求，但办事器端必需根据领受到客户端恳求的先后挨次依次回送响应成果，以包管客户端可以区分出每次恳求的响应内容，如许也显著地削减了整个下载过程所需要的时间

动静传递

HTTP 动静中能够包罗肆意长度的实体，凡是它们利用 Content-Length 来给出动静完毕标记。但是，关于良多动态产生的响应，只能通过缓冲完好的动静来判断动静的大小，但如许做会加大延迟。若是不利用长毗连，还能够通过毗连封闭的信号来断定一个动静的完毕。HTTP/1.1 中引入了 Chunkedtransfer-coding 来处理上面那个问题，发送方将动静朋分成若干个肆意大小的数据块，每个数据块在发送时城市附上块的长度，最初用一个零长度的块做为动静完毕的标记。那种办法允许发送方只缓冲动静的一个片段，制止缓冲整个动静带来的过载在 HTTP/1.0 中，有一个 Content-MD5 的头域，要计算那个头域需要发送方缓冲完好个动静后才气停止。而HTTP/1.1 中，接纳 chunked 分块传递的动静在最初一个块（零长度）完毕之后会再传递一个拖尾（trailer），它包罗一个或多个头域，那些头域是发送方在传递完所有块之后再计算出值的。发送方会在动静中包罗一个 Trailer 头域告诉领受方那个拖尾的存在。

Host 头域

在HTTP1.0中认为每台办事器都绑定一个独一的IP地址，因而，恳求动静中的URL并没有传递主机名（hostname）。但跟着虚拟主机手艺的开展，在一台物理办事器上能够存在多个虚拟主机（Multi-homed WebServers），而且它们共享一个 IP 地址。HTTP1.1 的恳求动静和响应动静都应撑持 Host 头域，且恳求动静中若是没有 Host 头域会陈述一个错误（400Bad Request）。此外，办事器应该承受以绝对途径标识表记标帜的资本恳求。

错误提醒

HTTP/1.0 中只定义了 16 个形态响应码，对错误或警告的提醒不敷详细。 HTTP/1.1 引入了一个Warning 头域，增加对错误或警告信息的描述。此外，在 HTTP/1.1 中新增了 24 个形态响应码，如 409（Conflict）暗示恳求的资本与资本的当前形态发作抵触；410（Gone）暗示办事器上的某个资本被永久性的删除

六、http 常见的形态码有哪些

200 OK //客户端恳求胜利

301 Moved Permanently（永久移除)，恳求的 URL 已移走。 Response 中应该包罗一个 LocationURL, 申明资本如今所处的位置

302 found 重定向

400 Bad Request //客户端恳求有语法错误，不克不及被办事器所理解

401 Unauthorized //恳求未经受权，那个形态代码必需和 WWW-Authenticate 报头域一路利用

403 Forbidden //办事器收到恳求，但是回绝供给办事

404 Not Found //恳求资本不存在， eg：输入了错误的 URL

500 Internal Server Error //办事器发作不成预期的错误

503 Server Unavailable //办事器当前不克不及处置客户端的恳求，一段时间后可能恢复一般

七、GET 和 POST 的区别

从外表现象上面看 GET 和 POST 的区别：

1. GET 恳求的数据会附在 URL 之后（就是把数据放置在 HTTP 协议头中），以?朋分 URL 和传输数据，参数之间以&相连，如： login.action?name=zhagnsan&password=123456。 POST 把提交的数据则放置在是 HTTP 包的包体中。

2. GET 体例提交的数据最多只能是 1024 字节，理论上 POST 没有限造，可传较大量的数据。其实如许说是错误的，禁绝确的： GET 体例提交的数据最多只能是 1024 字节"，因为 GET 是通过 URL 提交数据，那么 GET 可提交的数据量就跟URL 的长度有间接关系了。而现实上， URL 不存在参数上限的问题， HTTP 协议标准没有对 URL 长度停止限造。那个限造是特定的阅读器及办事器对它的限造。IE对URL长度的限造是2083 字节(2K+35)。关于其他阅读器，如 Netscape、FireFox 等，理论上没有长度限造，其限造取决于操做系统的撑持。

3. POST 的平安性要比 GET 的平安性高。留意：那里所说的平安性和上面 GET 提到的“平安”不是同个概念。上面“平安”的含义仅仅是不当准据修改，而那里平安的含义是实正的 Security 的含义，好比：通过GET 提交数据，用户名和密码将明文呈现在 URL 上，因为(1)登录页面有可能被阅读器缓存， (2)其别人查看阅读器的汗青记录，那么他人就能够拿到你的账号和密码了，除此之外，利用 GET 提交数据还可能会形成 Cross-site request forgery 攻击。Get 是向办事器发索取数据的一种恳求，而 Post 是向办事器提交数据的一种恳求，在 FORM（表单）中， Method默认为"GET"，本色上， GET 和 POST 只是发送机造差别，并非一个取一个发！

八、http 中重定向和恳求转发的区别

素质区别：转发是办事器行为，重定向是客户端行为。

重定向特点：两次恳求，阅读器地址发作变革，能够拜候本身 web 之外的资本，传输的数据会丧失。

恳求转发特点：一次强求，阅读器地址稳定，拜候的是本身自己的 web 资本，传输的数据不会丧失

九、Cookie 和 Session 的区别

Cookie 是 web 办事器发送给阅读器的一块信息，阅读器会在当地一个文件中给每个 web 办事器存储cookie。以后阅读器再给特定的 web 办事器发送恳求时，同时会发送所有为该办事器存储的 cookie。Session 是存储在 web 办事器端的一块信息。 session 对象存储特定用户会话所需的属性及设置装备摆设信息。当用户在应用法式的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丧失，而是在整个用户会话中不断存鄙人。

Cookie 和 session 的差别点：

1、无论客户端做如何的设置， session 都可以一般工做。当客户端禁用 cookie 时将无法利用cookie。

2、在存储的数据量方面： session 可以存储肆意的 java 对象， cookie 只能存储 String 类型的对象

十、session 共享怎么做的（散布式若何实现 session 共享）

问题描述：一个用户在登录胜利以后会把用户信息存储在 session 傍边，那时 session 所在办事器为server1，那么用户在 session 失效之前若是再次利用 app，那么可能会被路由到 server2，那时问题来了， server没有该用户的session，所以需要用户从头登录，那时的用户体验会十分欠好，所以我们想若何实现多台 server 之间共享 session，让用户形态得以保留。

1、办事器实现的 session 复造或 session 共享，那类型的共享 session 是和办事器慎密相关的，好比webSphere或 JBOSS 在搭建集群时候能够设置装备摆设实现 session 复造或 session 共享，但是那种体例有一个致命的缺点，就是欠好扩展和移植，好比我们改换办事器，那么就要修改办事器设置装备摆设。

2、操纵成熟的手艺做session复造，好比12306利用的gemfire，好比常见的内存数据库如redis或memorycache，那类计划固然比力普适，但是严峻依赖于第三方，如许当第三方办事器呈现问题的时候，那么将是应用的灾难。

3、将 session 维护在客户端，很容易想到就是操纵 cookie，但是客户端存在风险，数据不平安，并且能够存放的数据量比力小，所以将 session 维护在客户端还要对 session 中的信息加密。我们实现的计划能够说是第二种计划和第三种计划的合体，能够操纵 gemfire 实现 session 复造共享，还能够将session 维护在 redis 中实现 session 共享，同时能够将 session 维护在客户端的 cookie 中，但是前提是数据要加密。

那三种体例能够敏捷切换，而不影响应用一般施行。我们在理论中，首选 gemfire 或者 redis 做为session 共享的载体，一旦 session 不不变呈现问题的时候，能够告急切换 cookie 维护 session 做为备用，不影响应用供给办事。

那里次要讲解 redis 和 cookie 计划， gemfire 比力复杂各人能够自行查看 gemfire 工做原理。操纵redis 做session 共享，起首需要与营业逻辑代码解耦，否则 session 共享将没有意义，其次撑持动态切换到客户端 cookie 形式。 redis 的计划是，重写办事器中的 HttpSession 和 HttpServletRequest，起首实现HttpSession 接口，重写 session的所有办法，将 session 以 hash 值的体例存在 redis 中，一个session 的 key 就是 sessionID， setAtrribute 重写之后就是更新 redis 中的数据， getAttribute 重写之后就是获取 redis 中的数据，等等需要将 HttpSession 的接口逐个实现实现了 HttpSesson，那么我们先将该 session 类叫做 MySession（当然理论中不是那么定名的），当MySession呈现之后问题才起头，怎么能在不影响营业逻辑代码的情况下，还能让本来的 request.getSession（）获取到的是MySession，而不是办事器原生的 session。那里，我决定重写办事器的HttpServletRequet，那里先称为 MyRequest，但是那可不是单纯的重写，我需要在原生的 request 根底上重写，于是我决定在 filter 中，实现 request 的偷梁换柱，我的思绪是如许的， MyRequest 的构建器，必需以 request 做为参数，于是我在 filter 中将办事器原生的 request（也有可能是框架封拆过的 request ），当做参数 new 出来一个 MyRequest ，而且 MyRequest 也实现了HttpServletRequest 接口，其实就是对原生 request 的一个加强，那里次要重写了几个 request 的办法，但是最重要的是重写了 request.getSession()，写到那里各人应该都大白为什么重写那个办法了吧，当然是为了获取 MySession，于是如许就在filter中，悄悄的将原生的request换成MyRequest了，然后再将替代过的request传入chan.doFilter()，如许 filter 时候的代码都利用的是 MyRequest 了，同时对营业代码是通明的，营业代码获取 session 的办法仍然是request.getSession（），但其实获取到的已经是 MySession 了，如许对 session 的操做已经酿成了对 redis 的操做。如许实现的益处有两个，第一开发人员不需要对 session 共享做任何存眷， session 共享对用户是通明的；第二， filter是可设置装备摆设的，通过 filter 的体例能够将 session 共享做成一项可插拔的功用，没有任何侵入性。那个时候已经实现了一套可插拔的 session 共享的框架了，但是我们想到若是 redis 办事出了问题，那时我们该怎么办呢，于是我们延续 redis 的设法，想到能够将 session 维护在客户端内（加密的 cookie），当然实现办法仍是一样的，我们重写 HttpSession 接口，实现其所有办法，好比 setAttribute 就是写入cookie， getAttribute 就是读取cookie，我们能够将重写的 session 称做 MySession2，那时怎么闪开发人员通明的获取到 MySession2 呢，实现办法仍是在 filter 内偷梁换柱，在 MyRequest 加一个判断，读取 sessionType 设置装备摆设，若是 sessionType 是 redis 的，那么 getSession 的时候获取到的是MySession，若是 sessionType 是 coolie 的，那么 getSession 的时候获取到的是MySession2，以此类推，用同样的办法就能够获取到 MySession 3,4,5,6 等等。如许两种体例都有了，那么我们怎实现两种 session 共享体例的快速切换呢，刚刚我提到一个sessionType，那是用来决定获取到session的类型的，只要变更sessionType就能实现两种session共享体例的切换，但是sessionType必需对所有的办事器都是一致的，若是纷歧致那将会呈现比力严峻的问题，我们目前是将 sessionType 维护在情况变量里，若是要切换 sessionType 就要重启每一台办事器，完成 session共享的转换，但是当办事器太多的时候将是一种灾难。并且重启办事意味着办事的中断，所以如许的体例只合适办事器规模比力小，并且用户量比力少的情况，当办事器太多的时候，务必须要一种协调手艺，可以让办事器可以及时获取切换的通知。基于如许的原因，我们选用zookeeper 做为设置装备摆设平台，每一台办事器城市订阅 zookeeper 上的设置装备摆设，当我们切换 sessionType 之后，所有办事器城市订阅到修改之后的设置装备摆设，那么切换就会立即生效，当然可能会有短暂的时间延迟，但那是能够承受的。

十一、在单点登录中，若是 cookie 被禁用了怎么办

单点登录的原理是后端生成一个 session ID，然后设置到 cookie，后面的所有恳求阅读器城市带上cookie，然后办事端从 cookie 里获取 session ID，再查询到用户信息。所以，连结登录的关键不是 cookie，而是通过cookie 保留和传输的 session ID，其素质是能获取用户信息的数据。除了 cookie，还凡是利用 HTTP恳求头来传输。但是那个恳求头阅读器不会像 cookie 一样主动照顾，需要手工处置。

十二、什么是 jsp，什么是 Servlet？ jsp 和 Servlet 有什么区别

jsp 素质上就是一个 Servlet，它是 Servlet 的一种特殊形式（由 SUN 公司推出），每个 jsp 页面都是一个 servlet实例。Servlet 是由 Java 供给用于开发 web 办事器应用法式的一个组件，运行在办事端，由 servlet 容器办理，用来生成动态内容。一个 servlet 实例是实现了特殊接口 Servlet 的 Java 类，所有自定义的 servlet 均必需实现 Servlet 接口。

区别：

jsp 是 html 页面中内嵌的 Java 代码，偏重页面显示；

Servlet 是 html 代码和 Java 代码别离，偏重逻辑控造， mvc 设想思惟中 jsp 位于视图层， servlet 位于控造层。

JVM 只能识别 Java 类，其实不能识别 jsp 代码！ web 容器收到以.jsp 为扩展名的 url 恳求时，会将拜候恳求交给tomcat 中 jsp 引擎处置，每个 jsp 页面第一次被拜候时， jsp 引擎将 jsp 代码解释为一个 servlet 源法式，接着编译servlet 源法式生成.class 文件，再有 web 容器 servlet 引擎去拆载施行 servlet 法式，实现页面交互。

十三、jsp 有哪些域对象和内置对象及他们的感化

四大域对象：

（1） pageContext page 域-指当前页面，在当前 jsp 页面有效，跳到其它页面失效

（2） request request 域-指一次恳求范畴内有效，从 http 恳求到办事器处置完毕，返回响应的整个过程。在那个过程中利用 forward（恳求转发）体例跳转多个 jsp，在那些页面里你都能够利用那个变量

（3） session session 域-指当前会话有效范畴，阅读器从翻开到封闭过程中，转发、重定向均能够利用

（4） application context 域-指只能在统一个 web 中利用，办事器未封闭或者重启，数据就有效

十四、什么是 xml，利用 xml 的优缺点， xml 的解析器有哪几种，别离有什么区别

xml 是一种可扩展性标识表记标帜语言，撑持自定义标签（利用前必需预定义）利用 DTD 和 XML Schema 尺度化 XML 构造

长处：用于设置装备摆设文件，格局同一，契合尺度；用于在互不兼容的系统间交互数据，共享数据便利；

缺点： xml 文件格局复杂，数据传输占流量，办事端和客户端解析 xml 文件占用大量资本且不容易维护

Xml 常用解析器有 2 种，别离是： DOM 和 SAX;

次要区别在于它们解析 xml 文档的体例差别。利用 DOM 解析， xml 文档以 DOM树形构造加载入内存，而 SAX 接纳的是事务模子，

十五、对 ajax 的认识

Ajax 是一种创建交互式网页应用的的网页开发手艺； Asynchronous JavaScript and XML”的缩写。

Ajax 的优势：

通过异步形式，提拔了用户体验。

优化了阅读器和办事器之间的传输，削减没必要要的数据往返，削减了带宽占用。

Ajax 引擎在客户端运行，承担了一部门原来由办事器承担的工做，从而削减了大用户量下的办事器负载。

Ajax 的更大特点：

能够实现部分刷新，在不更新整个页面的前提下维护数据，提拔用户体验度。

十六、jsonp 原理

JavaScript 是一种在 Web 开发中经常利用的前端动态脚本手艺。在 JavaScript 中，有一个很重要的平安性限造，被称为“Same-Origin Policy”（同源战略）。那一战略关于 JavaScript 代码可以拜候的页面内容做了很重要的限造，即 JavaScript 只能拜候与包罗它的文档在统一域下的内容。JavaScript 那个平安战略在停止多 iframe 或多窗口编程、以及 Ajax 编程时显得尤为重要。按照那个战略，在 baidu.com 下的页面中包罗的 JavaScript 代码，不克不及拜候在 google.com 域名下的页面内容；以至差别的子域名之间的页面也不克不及通过 JavaScript 代码互相拜候。关于 Ajax 的影响在于，通过XMLHttpRequest 实现的Ajax 恳求，不克不及向差别的域提交恳求，例如，在 abc.example.com 下的页面，不克不及向 def.example.com 提交Ajax 恳求，等等。然而，当停止一些比力深切的前端编程的时候，不成制止地需要停止跨域操做，那时候“同源战略”就显得过于苛刻。 JSONP 跨域 GET 恳求是一个常用的处理计划，下面我们来看一下 JSONP 跨域是若何实现的，而且切磋下 JSONP 跨域的原理。jsonp 的最根本的原理是：动态添加一个标签，利用 script 标签的 src 属性没有跨域的限造的特点实现跨域。起首在客户端注册一个 callback, 然后把 callback 的名字传给办事器。此时，办事器先生成 json数据。然后以 javascript 语法的体例，生成一个 function , function 名字就是传递上来的参数 jsonp。最初将json 数据间接以入参的体例，放置到 function 中，如许就生成了一段 js 语法的文档，返回给客户端。客户端阅读器，解析 script 标签，并施行返回的 javascript 文档，此时数据做为参数，传入到了客户端预先定义好的 callback 函数里。

十七、谈谈你对 restful 的理解以及在项目中的利用

一种软件架构气概、设想气概，而不是尺度，只是供给了一组设想原则和约束前提。它次要用于客户端和办事器交互类的软件。 REST 指的是一组架构约束前提和原则。满足那些约束前提和原则的应用法式或设想就是RESTful。它构造明晰、契合尺度、易于理解、扩展便利，所以正得到越来越多网站的接纳。给各人保举如下一篇博客，该博客从多个维度讲解了什么是 Restful 而且给了 Restful 气概款式的 API接口。

十八、什么是 webService

WebService 是一种跨编程语言和跨操做系统平台的长途挪用手艺。所谓跨编程语言和跨操做平台，就是说办事端法式接纳 java 编写，客户端法式则能够接纳其他编程语言编写，反之亦然！跨操做系统平台则是指办事端法式和户端法式能够在差别的操做系统上。

十九、常见的长途挪用手艺

RMI 是 java 语言自己供给的长途通信协议，不变高效，是 EJB 的根底。但它只能用于 JAVA 法式之间的通信。Hessian 和 Burlap 是 caucho 公司供给的开源协议，基于 HTTP 传输，办事端不消开防火墙端口。协议的标准公开，能够用于肆意语言。跨平台有点小问题。Httpinvoker 是 SpringFramework 供给的长途通信协议，只能用于 JAVA 法式间的通信，且办事端和客户端必需利用 SpringFramework。Web service 是毗连异构系统或异构语言的首选协议，它利用 SOAP 形式通信，能够用于任何语言，目前的许多开发东西对其的撑持也很好。

效率比拟： RMI > Httpinvoker >= Hessian >> Burlap >> web service。