2012-04-17 65 views
11

这可能听起来类似于this,但事实并非如此。当您可以实现Web服务(SOA/REST)时,使用RMI实现EJB仍然有用吗?

我有点理解EJB和RMI,而且我一直在SOA下使用Web服务。我想知道为什么使用EJB公开RMI下的远程接口而不是发布Web服务(SOA/REST,但主要是SOA)是有用的。我并不是问哪一个更好,只是我想知道为什么我更喜欢通过Web服务实现具有远程接口的EJB。

我回顾了很多网页,但都显得过时。到目前为止,我所拥有的是在与Java遗留系统集成时,暴露远程接口的EJB只比WS更好。如果我想管理事务,我可以用本地接口实现EJB。另外我不认为选择EJB over RMI比Web Service接口更有效率。

我对不对?有什么我失踪?

真的在此先感谢。

回答

21

EJB是更好,如果

  • 您需要执行哪些应该在一个 交易完成呼叫数(在理论上,我们有事务的web服务,但不 每个执行提供的话),(状态)当谈到事务管理时,EJB发光。几乎在任何时候你需要有状态EJB都会比Web Service更好;
  • 你需要性能 - Web 服务很慢 - 它们使用通过HTTP推送的XML/JSON,RMI通过 EJB使用的IIOP协议更有效;
  • 您需要连接到一些遗留系统,该遗留系统使用Java Web服务的过时规范(丑陋的Axis 1.0东西,与JAX-WS不兼容),将所有与Web服务连接起来可能是一场噩梦,处理不兼容的WSDL定义,奇怪的SOAP信封。 EJB向后兼容,可以连接旧的EJB 2而没有EJB 3.1的任何问题;
  • 现代的EJB(EJB 3.X)可以通过添加两个或三个简单的注解

为什么(REST)Web服务暴露它们的JAX-WS SOAP/WSDL服务或JAX-RS REST服务接口那么受欢迎呢? EJB只能连接到另一个Java应用程序。大多数现代富互联网应用程序都是用JavaScript编写的,因此将它们与任何后端连接的唯一方法是使用某种Web服务(通常为REST + JSON)。对于这样的应用程序来说,EJB是非常没用的。

+0

谢谢,但之前将其标记为已回答,第一个不会是一个有效的原因,因为我可以使用暴露本地接口的EJB来实现Web服务吗?所以交易是一样的。 – 2012-04-17 20:16:59

+2

的确,当您需要在一个事务中执行多个分离的调用时,问题就开始了。 Web服务通常是无状态的,并且必须“手动”管理事务,这可能很麻烦。有状态的EJB将免费提供。 – 2012-04-17 20:22:23

+0

那么,即使使用之前给出的最后一个原因,您也可以拥有有状态的Web服务。所以我会考虑第二个和第三个原因,效率(有点我猜)和遗产。谢谢! – 2012-04-17 20:27:11

6

如果您使用RMI作为有线协议,则客户端和服务都必须用Java编写。

SOAP使用XML over HTTP,REST使用纯HTTP进行客户端与服务之间的通信。对话的任何一端都可以使用任何可以通过HTTP发送适当请求的语言来编写,而这种限制要少得多。

我认为这是通过HTTP的Web服务已经胜过RMI的原因之一。简单而开放的胜利,每一次。

+0

因此,不再需要继续使用远程接口来学习EJB吗?就像我想学习Smalltalk(只是为了好玩和学习,但没用)? – 2012-04-17 20:12:12

+0

我不会那么远。这个问题的答案取决于你的情况。 – duffymo 2012-04-17 20:23:22

+0

好的,但现在唯一有用的环境是与Java遗留系统集成,对吗? – 2012-04-17 20:28:32

6

对于不同的目的他们是不同的东西。

EJB可用于N -ier系统,它紧密耦合,并且您可以控制所有元素。它们使用语言中的普通方法调用提供直接编码,以及IIOP上的局域网类型性能或EE供应商部署的任何其他协议。

SOAP/REST最适合在互联网或B2B或其他您无法控制两端并且需要松耦合的情况下使用。由于所有XML都会使性能下降得多,但您也可以在中间获得行业标准协议,从而使两端均可防止单一源问题。

+0

这可能是另一个问题,但可以轻松地调整EJB以将它作为Web服务的接口公开,因此,您可以启动您定义的第一个体系结构,如果将来需要扩展,则可以通过它展示Web服务,还是不? – 2012-04-18 14:38:38

+0

@ChristianVielma这是另一个问题,你不会从我这里得到答案;-)问它是一个问题。 – EJP 2012-04-18 23:17:08

相关问题