Web服务与EJB对比RMI，优缺点？ [英] Web Services vs EJB vs RMI, advantages and disadvantages?

问题描述

如果所有的工作都在那里完成，我的网络服务器会很快超载。我将在其后面站起一个第二台服务器来处理数据。

EJB比RMI有什么优势，反之亦然？

Web服务（SOAP，REST）如何？

解决方案

EJB建立在RMI之上。两者都意味着Java客户端和bean。如果您的客户需要以其他方式（例如.NET，PHP等）编写，请使用Web服务或其他与平台无关的线路协议（例如HTTP或XML over HTTP或SOAP）的其他方式。

如果选择RMI，则不需要Java EE EJB应用服务器。您必须保持客户端和服务器JVM同步;您不能升级客户端而不升级服务器。您必须编写EJB应用服务器为您提供的所有服务（例如，连接池，命名和目录服务，池，请求队列，事务等）。

<当您考虑RMI时，RMI的水平相当低。为什么你会一直回到CORBA？

更好的选择是EJB 3.0与Spring。这取决于您是否喜欢POJO开发，除了需要选择除ORM和JPA之外的关系技术等。

您可以支付Java EE应用服务器（例如，WebLogic，WebSphere）或使用开放源代码（JBOSS，Glassfish和OpenEJB和ActiveMQ），或者您可以坚持使用Spring并在Tomcat，Jetty，Resin或任何其他servlet / JSP引擎上部署。

$ b $通过技术不可知，Spring提供了很多选择：持久性（Hibernate，iBatis，JDBC，JDO，JPA，TopLink），远程处理（HTTP，Hessian，Burlap，RMI，SOAP Web服务）等。

EJB 3.0是许多供应商的规范;春天只能从春天来源。

我建议春天。它非常坚固，有很大的牵引力，不会去任何地方。它使您的所有选项都可以打开。

Web服务在理论上是伟大的，但有一些需要注意的问题：

1. 延迟。福勒的分布式对象的第一部法律：不要！由许多细粒度的分布式SOAP服务组成的体系结构将优雅，美观，而且像糖蜜一样缓慢。分发前仔细考虑。


2. 从XML到对象和后台的编组消耗的CPU周期不能提供任何商业价值，除了允许您的客户使用平台无关协议。


3. SOAP是每天变得越来越笨重和复杂的标准，但它具有很多工具支持。供应商喜欢它，因为它有助于推动ESB的销售。 REST很简单，但不是很了解。它不受工具支持。

Spring的Web服务模块非常好，但要小心选择部署这种方式。用POJO服务接口编写。这些将允许您获得所需的概念隔离，将部署选择推迟到最后一刻，如果第一个想法效果不佳，可以改变主意。

My web server would be overloaded quickly if all the work were done there. I'm going to stand up a second server behind it, to process data.

What's the advantage of EJB over RMI, or vice versa?

What about web services (SOAP, REST)?

解决方案

EJBs are built on top of RMI. Both imply Java clients and beans. If your clients need to be written in something else (e.g., .NET, PHP, etc.) go with web services or something else that speaks a platform-agnostic wire protocol, like HTTP or XML over HTTP or SOAP.

If you choose RMI, you don't need a Java EE EJB app server. You have to keep client and server JVMs in synch; you can't upgrade the client without upgrading the server. You have to write all the services that the EJB app server provides for you (e.g., connection pooling, naming and directory services, pooling, request queuing, transactions, etc.).

RMI is quite low level when you think about it. Why would you drop all the way back to CORBA?

A better choice is EJB 3.0 versus Spring. It depends on whether you like POJO development, want a choice of relational technologies besides ORM and JPA, among other things.

You can pay for a Java EE app server (e.g., WebLogic, WebSphere) or use an open source one (JBOSS, Glassfish and OpenEJB and ActiveMQ), or you can stick to Spring and deploy on Tomcat, Jetty, Resin or any other servlet/JSP engine.

Spring offers a lot of choice by being technology agnostic: persistence (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), remoting (HTTP, Hessian, Burlap, RMI, SOAP web service), etc.

EJB 3.0 is a spec with many vendors; Spring can only be had from Spring Source.

I would recommend Spring. It's very solid, has lots of traction, isn't going anywhere. It leaves all your options open.

Web services are great in theory, but there are some gotchas that you need to watch out for:

1. Latency. Fowler's first law of distributed objects: "Don't!" An architecture consisting of lots of fine-grained distributed SOAP services will be elegant, beautiful, and slow as molasses. Think carefully before distributing.
2. Marshalling from XML to objects and back consumes CPU cycles that aren't providing any business value besides allowing your clients to speak a platform-agnostic protocol.
3. SOAP is a standard that is becoming more bloated and complex every day, but it has lots of tool support. Vendors like it because it helps drive sales of ESBs. REST is simple but not as well understood. It's not supported by tools.

Spring's web service module is very good, but do be careful about choosing to deploy this way. Write in terms of POJO service interfaces. These will allow you to get the conceptual isolation you want, defer the deployment choice until the last moment, and let you change your mind if the first thought doesn't perform well.

这篇关于Web服务与EJB对比RMI，优缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！