您会推荐哪种 Java 应用程序远程处理方法？
我想知道如何集成作为单独的 J(2)EE 应用程序开发的 Java 模块的最佳方法。 每个模块都公开 Java 接口。 POJO 实体（Hibernate）与那些 Java 接口一起使用，没有 DTO 对象。 集成这些模块的最佳方式是什么，即一个模块远程调用另一个模块接口？
我在考虑：EJB3、Hessian、SOAP、JMS。 每种方法都有优点和缺点。
各位，你们的看法或者经历是什么？
I wonder how is the best way to integrate Java modules developed as separate J(2)EE applications. Each of those modules exposes Java interfaces. The POJO entities (Hibernate) are being used along with those Java interfaces, there is no DTO objects. What would be the best way to integrate those modules i.e. one module calling the other module interface remotely?
I was thinking about: EJB3, Hessian, SOAP, JMS. there are pros and cons of each of the approaches.
Folks, what is your opinion or your experiences?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在接触过一些远程处理技术并发现它们普遍无趣之后，我现在将使用 Spring 远程处理作为实现的抽象。
它允许您专注于编写功能，并让 Spring 通过一些配置来处理远程部分。 您可以选择多种实现（RMI、Spring 的 HTTP 调用程序、Hessian、Burlap 和 JMS）。 抽象意味着您可以选择一种实现，并且如果您的需求发生变化，只需更换它即可。
有关更多信息，请参阅 SpringSource 文档。
Having dabbled with a few of the remoting technologies and found them universally unfun I would now use Spring remoting as an abstraction from the implementation.
It allows you to concentrate on writing your functionality and let Spring handle the remote part with some config. you have the choice of several implementations (RMI, Spring's HTTP invoker, Hessian, Burlap and JMS). The abstraction means you can pick one implementation and simply swap it if your needs change.
See the SpringSource docs for more information.
标准方法是在各种服务组件之间使用普通的 RMI，但这会带来共享 Java 接口和对域模型进行版本控制更改的问题，特别是当您有大量使用相同类的组件时。
您真的在单独的虚拟机中运行每个服务吗？ 如果这些 EJB 始终相互通信，那么您最好将它们放入同一个 VM 中并避免任何远程过程调用，因为这些服务可以使用它们的 LocalInterfaces。
另一件可能让您烦恼的事情是使用 Hibernate POJO。 您可能认为这些是简单的 POJO，但在幕后 Hibernate 一直忙于 CGLib 尝试执行诸如允许延迟初始化之类的操作。 如果这些 bean 被序列化并通过远程边界传递，那么您最终可能会遇到奇怪的 Hibernate 异常。 就我个人而言，我更喜欢创建简单的 DTO 或将 POJO 写为 XML 以在组件之间传递。 出于性能原因，我的同事会更进一步编写自定义有线协议来传输数据。
最近我一直在使用MULE ESB来集成各种服务组件。 这非常好，因为您可以混合使用 RMI、套接字、Web 服务等，而无需编写大部分样板代码。
http://www.mulesource.org/display/COMMUNITY/Home
The standard approach would be to use plain RMI between the various service components but this brings issues of sharing your Java interfaces and versioning changes to your domain model especially if you have lots of components using the same classes.
Are you really running each service in a separate VM? If these EJBs are always talking to each other then you're best off putting them into the same VM and avoiding any remote procedure calls as these services can use their LocalInterfaces.
The other thing that may bite you is using Hibernate POJOs. You may think that these are simple POJOs but behind the scenes Hibernate has been busy with CGLib trying to do things like allow lazy initialization. If these beans are serialzed and passed over remote boundaries then you may end up with odd Hibernate Exception getting thown. Personally I'd prefer to create simple DTOs or write the POJOs out as XML to pass between components. My colleagues would go one step further and write custom wire protocols for transferring the data for performance reasons.
Recently I have been using the MULE ESB to integrate various service components. It's quite nice as you can have a mix of RMI, sockets, web services etc without having to write most of the boiler plate code.
http://www.mulesource.org/display/COMMUNITY/Home
除了最简单有效的方法之外，你为什么还要选择其他方法呢？
在您的情况下，这听起来像 EJB3 或可能是 JMS，具体取决于通信是否需要同步或异步。
EJB3 是迄今为止最简单的构建在 RMI 之上的容器，它提供了您可能需要的所有附加功能 - 安全性、事务等。大概您的 POJO 位于共享 jar 中，因此可以简单地在 EJB 之间传递，尽管我我自己倾向于传递价值对象。 EJB 的另一个好处是，如果使用得当，它的性能是最高的（顺便说一句，这只是我的观点；-）。
JMS 涉及的内容较多，但不多，基于异步通信的系统在并行任务等方面提供了某些细节。Web
服务的性能开销、不可避免的额外配置和额外的故障点使它们，恕我直言，除非您有强制使用它们的要求，否则不值得麻烦 - 我正在考虑与非 Java 客户端进行互操作或在此处向外部各方提供数据。
Why would you go with anything other than the simplest thing that works?
In your case that sounds like EJB3 or maybe JMS, depending on whether the communication needs to be synchronous or asynchronous.
EJB3 is by far these easiest being built on top of RMI with the container providing all the additional features you might need - security, transactions, etc. Presumably your POJOs are in a shared jar and therefore can simply be passed between your EJBs, although I tend towards passing value objects myself. The other benefit of EJB is, when done right, that it's the most performant (that's just my opinion btw ;-).
JMS is a little more involved, but not much and a system based on asynchronous communication affords certain niceties in terms of parallelizing tasks, etc.
The performance overhead of web-services, the inevitable extra config and additional points of failure make them, IMHO, not worth the hassle unless you've a requirement that mandates their use - I'm thinking interop with non-Java clients or providing data to external parties here.
如果您需要在纯 Java 应用程序之间进行网络通信，Java RMI 是您的最佳选择。 它具有最好的集成度、最高的透明度和最少的开销。
但是，如果您的某些客户端不是基于 Java 的，您可能应该考虑其他选项（Java RMI 实际上有一个 IIOP 方言，它允许它与 CORBA 交互，但是 - 我不建议这样做，除非它用于一些遗留代码集成）。 根据您的需求，网络服务可能是您的朋友。 如果您关心网络负载，您可以通过 Hessian 来使用 Web 服务。
If you need network communication between Java-only applications, Java RMI is the way to go. It has the best integration, most transparency and the least overhead.
If, however, some of your clients aren't Java-based, you should probably consider other options (Java RMI actually have an IIOP-dialect, which allows it to interact with CORBA, however - I wouldn't recommend doing this, unless it's for some legacy-code integration). Depending on your needs, webservices are probably your friend. If you are conserned with the networkload, you could go webservices over Hessian.
你的意思是远程吗？ 就像在具有不同可用性特征的不同环境中运行一样？ 有网络开销吗？
假设“是”，我的第一步将是采用服务方法，暂时搁置调用技术。 只需考虑您的服务的设计和意义即可。 您知道它们的调用成本相对较高，因此小型繁忙的接口往往是一件坏事。 您知道服务系统可能会在调用之间发生故障，因此您可能会青睐无状态服务。 您可能需要在失败后重试请求，因此您可能会倾向于幂等服务设计。
然后考虑可用性关系。 您的客户端可以在没有远程系统的情况下工作吗？ 在某些情况下，如果远程系统不可用，您就无法取得进展（例如，如果您无法访问人力资源系统，则无法启用员工），在其他情况下，您可以采用“即发即报”的方式“以后我”的哲学； 将请求排队并稍后处理响应。
如果存在可用性依赖性，那么简单地公开同步接口似乎是合适的。 您可以使用 SLSB EJB 来做到这一点，如果一切都是 Java EE，那么就可以了。 我倾向于概括地认为，如果我的服务有用，那么非 Java EE 客户端也可能需要它们。 因此 SOAP（或 REST）往往很有用。 如今，向 SLSB 添加 Web 服务接口非常简单。
但我最喜欢的理论是，任何足够大的 IT 系统最终都需要 aynch 通信：您需要解耦可用性约束。 所以我倾向于寻找 JMS 风格的关系。 服务前面的 MDB 外观或 SOAP/JMS 并不难实现。 这种方法往往会突出可能潜伏的失败案例设计问题，JMS 往往会让您思考：“假设我没有得到答案？假设我的答案来晚了？”
You literally mean remotely? As in running in a different environment with therefore different availability characteristics? With network overheads?
Assuming "yes" my first step would be to take a service approach, set aside the invocation technology for a moment. Just consider the design and meaning of your services. You know they are comparativley expensive to invoke, hence small busy interfaces tend to be a bad thing. You know that the service system might fail between invocations, so you may favour stateless services. You may need to retry requests after failure, so you may favour idempotent service designs.
Then consider availability relationships. Can your client work without the remote system. In some cases you simply can't progress if the remote system isn't available (eg. can't enable the employee if you can't get to the HR system) in other cases you can adopt a "fire-and-tell-me-later" philosophy; queue up the requests and process responses later.
Where there is an availability depdency, then simply exposing a synchronous interface seems to fit. You can do that with SLSB EJBs, if everything is Java EE, that works. I tend to generalise expecting that if my services are useful then non Java EE clients may want them too. So SOAP (or REST) tends to be useful. These days adding a web service interface to your SLSB is pretty trivial.
But my pet theory is that any sufficiently large IT system ends up needing aynch communications: you need to decouple the availability contraints. So I would tend to look for a JMS-style relationship. An MDB facade in front of your services, or SOAP/JMS is not too hard to do. Such an approach tends to highlight the failure-case design issues that were probably lurking anyway, JMS tends to make you think: "suppose I don't get an answer? suppose my answer comes late?"
我会选择 SOAP。
JMS 会更高效，但您需要为每个接口编写一个消息驱动 bean。
另一方面，SOAP 附带了许多有用的工具包，当给定 EJB 时，这些工具包将生成消息定义 (WSDL) 和所有必需的处理程序（客户端和服务器）。
使用肥皂，您可以（但不必）处理证书安全和公共网络上的安全连接。 由于默认协议是通过端口 80 的 HTTP，因此您将不会遇到防火墙等方面的麻烦。SOAP 对于异构客户端（在您的情况下任何非 J2EE 的客户端）也非常有用，并且对最常见平台上的最常见语言提供了良好的支持。
I would go for SOAP.
JMS would be more efficient but you would need to code up an message driven bean for each interface.
SOAP on the other hand comes with lots of useful toolkits that will generate your message definition (WSDL) and all the neccesary handlers (client and server) when given an EJB.
With soap you can (but dont have to) deal with certificate security and secure connections over public networks. As the default protocol is HTTP over port 80 you will have minimal pain with firewalls etc. SOAP is also great for hetrogenious clients (in your case anything that isn't J2EE) with good support for most common languages on most common platforms.