你会推荐什么远程处理Java应用程序的方法？

我想知道如何集成作为独立的J（2）EE应用程序开发的Java模块。这些模块中的每一个都公开了Java接口。 POJO实体（Hibernate）与这些Java接口一起使用，没有DTO对象。集成这些模块的最佳方式是什么？即一个模块远程调用另一个模块接口？你会推荐什么远程处理Java应用程序的方法？

我在想：EJB3，Hessian，SOAP，JMS。每种方法都有其优点和缺点。

民间，你的意见或你的经验是什么？

来源

2009-07-03 Tomasz Błachowicz

已经涉足了几个远程访问技术，发现他们普遍unfun我现在会用Spring远程从实现的抽象。它允许你专注于编写你的功能，让Spring用一些配置来处理远程部分。你可以选择几种实现（RMI，Spring的HTTP调用者，Hessian，Burlap和JMS）。抽象意味着你可以选择一个实现，只要需要改变就交换它。查看SpringSource docs了解更多信息。

来源

2009-07-03 10:47:56

我会去用肥皂。

JMS会更有效，但你需要编写了驱动bean为每个接口的消息。在另一方面

SOAP附带了很多有用的工具包给出的EJB时，将产生你的消息定义（WSDL）和所有neccesary处理程序（客户端和服务器）的。

使用肥皂时，你可以（但不必须）处理证书的安全性和通过公共网络的安全连接。由于缺省协议是通过端口80的HTTP，所以对防火墙等问题的影响会很小。对于绝大多数常见平台上的大多数常见语言的良好支持，SOAP对于异性客户端（在您的情况下不是J2EE）非常有用。

来源

2009-07-03 10:14:03

JMS专为异步通信而设计，即消防和遗忘。因此，如果您需要服务电话的响应，则需要两个消息通道一个接收消息，另一个将回复发送回发件人。 – pjp 2009-07-03 10:20:54

我与SOAP看到的问题是，使用这种技术需要XML模式，我可以再使用绑定到XML对象（JAXB）的定义。正如我在我原来的文章中所述，目标是消除DTO，并尽可能使用模型实体（Hibernate/JPA）。 DTO的问题在于DTO和实体之间需要转换层。 – 2009-07-03 10:24:07

@pjp：不完全。您可以使用涉及专用队列（对于会话）的模式来接收响应。基本上，客户端创建临时队列，为请求消息设置'ReplyTo'属性并将消息发送到公共请求队列。响应者接收请求消息，启动逻辑，创建响应消息并将其发送到请求消息的'ReplyTo'中指定的临时队列。 – 2009-07-03 10:30:35

如果需要Java的应用程序只之间的网络通信，Java RMI的是要走的路。它具有最佳的整合性，最高的透明度和最小的开销。

但是，如果您的某些客户端不是基于Java的，您应该考虑其他选项（Java RMI实际上有一个IIOP方言，它允许它与CORBA交互，但是 - 我不会推荐这样做，除非它是为了一些遗留代码集成）。根据您的需求，webservices可能是您的朋友。如果你使用网络负载，你可以通过Hessian进行web服务。

来源

2009-07-03 10:14:37 cwap

+1 RMI是:-) – ATorras 2009-07-03 10:44:24

你的字面意思是远程？像在不同的环境中运行一样，因此具有不同的可用性特征？有网络开销？

假设“是”我的第一个步骤是采取的服务方式，抛开调用技术一会儿。只要考虑你的服务的设计和意义。你知道它们比较昂贵，因此繁忙的小接口往往是一件坏事。你知道服务系统可能在调用之间失败，所以你可能会倾向于无状态的服务。您可能需要在失败后重试请求，以便您可以支持幂等服务设计。

然后考虑可用性关系。你的客户可以在没有远程系统的情况下工在某些情况下，如果远程系统不可用（例如，如果您无法进入HR系统，则无法启用员工），您可能无法进展，而在其他情况下，您可以采用“消防和告知后来“哲学;稍后排队请求并处理响应。

那里有一个可用性depdency，然后简单地暴露同步接口似乎适合。如果所有东西都是Java EE，那么可以使用SLSB EJB执行此操作。我倾向于总结期望如果我的服务是有用的，那么非Java EE客户端可能也需要它们。所以SOAP（或REST）往往是有用的。现在，向您的SLSB添加Web服务界面非常简单。

但我的宠物理论是，任何足够大的IT系统最终都需要异步通信：您需要解耦可用性约束。所以我会倾向于寻找一种JMS风格的关系。在您的服务或者SOAP/JMS之前的MDB外观并不难做到。这种方法倾向于强调无论如何可能潜伏的失败案例设计问题，JMS倾向于让你想：“假设我没有得到答案？假设我的答案来得晚？”

来源

2009-07-03 10:20:20 djna

的标准方法是使用普通的RMI的各种服务组件之间，但由此带来的分享你的Java接口和版本，特别是如果你有很多使用相同的类组件到您的域模型的变化的问题。

你真的运行在一个单独的虚拟机每个服务？如果这些EJB总是彼此交谈，那么最好将它们放到同一个虚拟机中，并避免任何远程过程调用，因为这些服务可以使用它们的LocalInterfaces。

可能会咬你的另一件事是使用Hibernate的POJO。您可能会认为这些是简单的POJO，但在幕后，Hibernate一直忙于CGLib尝试执行诸如允许延迟初始化之类的操作。如果这些bean被序列化并通过远程边界传递，那么最终可能会出现奇怪的Hibernate Exception。就个人而言，我宁愿创建简单的DTO或将POJO编写为XML以在组件之间传递。出于性能原因，我的同事们会更进一步，编写自定义有线协议来传输数据。

最近我一直在使用MULE ESB整合各种服务组件。这很好，因为你可以混合使用RMI，套接字，Web服务等，而不必编写大部分的锅炉代码。

http://www.mulesource.org/display/COMMUNITY/Home

来源

2009-07-03 10:33:05 pjp

+1的容易和简单的解决方案，我喜欢的ESB方法 – ATorras 2009-07-03 10:43:24

你为什么会去与比对工作最简单的事情其他什么吗？

在你的情况这听起来像EJB3也许JMS，取决于沟通是否需要同步或异步的。

EJB3到目前为止最容易建立在RMI之上，容器提供了您可能需要的所有额外功能 - 安全性，事务处理等。推测您的POJO位于共享jar中，因此可以简单地在您的EJB，尽管我倾向于自己传递值对象。 EJB的另一个好处是，如果做得对，它是最高性能的（这只是我的意见btw ;-)。

JMS是一个涉及多一点，但不是很多，基于异步通信的系统得到一定的礼节在并行任务期限等

的网络服务的性能开销，必然额外的配置和附加失败点使他们，恕我直言，不值得麻烦，除非你有一个要求强制他们使用的要求 - 我正在考虑与非Java客户端交互或向外部提供数据。

来源

2009-07-03 10:38:34

你会推荐什么远程处理Java应用程序的方法？

回答

相关问题