4

我正在计划一个 webapp，每个使用它的人都有一个客户端，可以在其计算机上运行计算（因为这些计算不能在服务器上完成，负载太大......），然后将结果发送到服务器。

我想会有很多人对我的应用程序感兴趣，这就是为什么我想知道我的架构是否良好以及我是否能够处理成千上万的人。

我打算通过带有 Glassfish 服务器的 JNDI 公开远程 EJB，因此 1000 人可以同时使用这些 EJB（我猜可能有 5-50 个请求/秒）来检索本地计算所需的数据，然后发送结果...

将 EJB 暴露给许多客户会很昂贵吗？使用webservices，rmi，另一种解决方案会更好吗？

你会为我将要做什么推荐另一种架构吗？

4

3 回答 3

7

首先，从纯架构的角度来看，EJB 用于构建分布式应用程序，Web 服务是一种集成技术，它们之间并不真正相互竞争。在您的情况下，EJB 将是一个自然的选择（我们正在谈论 EJB3，对吗？）并且会话 bean 的扩展性非常好。

其次，如果服务器端代码仅用于从数据库中检索数据并在客户端计算后保存结果，那么应用服务器很可能不会成为瓶颈，数据库会。换句话说，没什么好担心的。

因此，由于您的客户端都是 100% Java 客户端，我将只公开无状态会话 bean 1并避免 SOAP/XML 编组/解组和编写 WSDL 的开销（如果有一天您需要将服务公开为 Web 服务，这将仍然是可能的，而且很容易）。

1使用 JPA 或其他方式进行数据访问由您自行决定。

于 2010-03-18T21:48:34.723 回答
1

我的 2p 是从客户端的角度来看，提供 Web 服务或 XML/http 客户端更容易、更标准。一个好处是，如果它是一个 SOAP Web 服务，它们就不需要是 Java 客户端。

于 2010-03-18T12:24:56.710 回答
0

我在一个论坛上读到，在客户端检索实体可能是个坏主意，因为保留了代理并且它会产生流量

一个人测试过，一个 300 个对象的 40ko 序列化列表在 wireshark 中生成了 3.6mo 网络流量，但是如果你使用 EntityManager.clear() 来分离实体或者你使用 pojos dto 将类型返回到远程函数，那么没关系 :)

于 2010-03-18T20:32:29.550 回答