需要一个应用程序服务器 - Java

我来自客户端编程背景（主要是C++）。但是，我现在偶尔需要进入一些Java的小型服务器端项目&，因此需要来自有经验的服务器端人员的一些建议。我对应用程序服务器并不十分了解。需要一个应用程序服务器 - Java

是否有任何拇指规则或注意事项来决定程序何时需要应用程序服务器（如GlassFish或JBoss）？

我有两台使用Java编写的服务器，都运行在专用机器上。一台服务器在没有任何App Server的情况下在Tomcat上运行第二台服务器在应用程序服务器（Glassfish）上运行。

我需要写一个相当简单的程序，坐在中间。这是程序将要做的事

在套接字上侦听。当连接来自第一台服务器时，它会创建一个线程来接受连接&继续收听。
线程从第一个服务器获取少量数据（比如100-200字节），数据格式很小&通过web服务调用将它传递给第二个服务器。它会返回webservice调用的返回值，并基于它进行一些处理 - 可能大约有10-20行代码 - 这不是一些主要的处理 - 只是在不同的（第3）服务器上调用一些web服务调用。在此之后，它将一些数据返回给第一台服务器 - 再次不多 - 可能是50个字节。
我的程序不是web服务。它仅以特定格式从第一台服务器获取消息&根据从第一台服务器接收到的数据向第二台服务器发出web服务调用。在某些情况下，您可以用这种方式思考它 - 它充当第一台服务器的代理，以便将Web服务调用到第二台服务器。

所有主要的工作是由第一台服务器运行在Tomcat服务器上运行& GlassFish上运行的Web服务应用程序来完成。这两个都是测试良好的程序。我想写的中间程序非常简单&我可以在半天内完成。但是，我担心的是它是否能够承受负担。

有什么样的规则/考虑因素可以确定我是否可以将此Java程序作为常规Windows服务运行，或者是否需要Glassfish或任何其他应用程序服务器之类的东西。

我应该考虑每分钟/小时进入的连接数量吗？我将为每个连接分配一个线程，但线程本身不会很长寿。我应该在什么样的连接数阈值下考虑应用服务器？还有其他的考虑吗？如果可能的话，我宁愿避免使用Application Server。

是否在App Server下运行它只是一个问题 - 我还有什么问题吗？

来源

2012-12-10 user93353

不确定这是否适合您的用例，但此类服务连接的一种标准方式是通过使用JMS队列的发布 - 订阅模型。每个服务都有一个消息队列。您会在队列中堆积消息，处理消息并将结果发布到其他服务的队列中。 –

@Singularity - 第一台服务器以特定格式发送消息，并期望以特定格式回复。我将研究JMS队列，但我认为JMS队列有自己的格式。 – user93353

是JMS使用XML（Soap），但CDATA标签允许将任何原始数据放入XML中。 –

应用程序服务器并不神奇，因为它们不会创造更好的性能。事实上，对于一个简单的应用程序，如您所概述的，应用程序服务器可能会产生相反的效果，因为大多数应用程序服务器引入的额外开销。

应用程序服务器提供基础架构组件，用于企业级开发的实用模式以及标准规范的实现。它们主要用于组织更大规模的开发工作，并为较大数量的相对较短寿命的连接设置规模。也就是说，如果您已熟悉它们提供的基础架构，则可以使用轻量级服务器（如Tomcat或Jetty）。特别是，他们会为您提供入站HTTP连接处理。

虽然我认为根据你的问题描述，你最好使用像Apache HttpComponents这样的库来编写独立的java服务来处理HTTP和WebService客户端功能。目前还不清楚您需要多少额外的工作来处理入站连接。如果插座简单，那么自己编程就很容易。

您的描述关于需要同时支持多少个连接是模糊的（而且都是相对的）。如果每个连接需要一个线程并且希望支持数百个连接，那么我会建议使用线程连接池来实现连接处理，确保在耗尽服务器功能之前阻止新连接。如果要走这条路线，请查看Java 5+ ExecutorService和相关的类。

我怀疑如果您的需求很简单，应用程序服务器将提供很多好处。

来源

2012-12-10 17:51:11 kaliatech

谢谢你的回复。几个澄清 - 我正在使用Axis来进行web服务调用。它满足了我的所有需求。另外我需要每个连接1个线程 - 将查看ExecutorService。当你询问“需要支持数百个连接”时 - 我假设你正在谈论并发，对吧？ – user93353

关于负载，它确实取决于您的方案。如果线程在等待IO响应时主要被阻塞，那么很容易实现100个并发连接。如果您的线程始终处于活动状态，那么100个_active_线程可能需要严重的硬件。但是如果你的线程寿命短并且新的conten可以等待很短的时间，那么你可以有一个最多50个线程的池，但是有1000个连接的队列可以被服务。 “并发连接”的定义可能非常棘手。 – kaliatech

评估任何工具时的基本规则也应适用于此：它是否会使我的工作更轻松。

所以问题是：应用程序服务器提供的功能是否满足我的用例和限制将不会与我接壤。

基础上的用户情况说明：

的JavaEE应用服务器提供的Servlet抽象来轻松管理HTTP请求（在理论上其他类型的请求，可以实现通过您将需要做你的自我添加新的东西来实现应用服务器）。它还将通过Jax-WS或Jax-RS抽象提供Web服务端点创建。

这些抽象的代价是应用程序服务器将管理线程。大多数实现将使用线程池进行HTTP连接，因此每个请求无需创建线程成本。

此外全JavaEE将为您提供简单的声明式交易和安全（EJB），与JMS和其他人的远程消息。

它取决于您平衡提供的抽象的附加价值和它们的成本（更少的控制，在大多数情况下，更少的控制会导致更好的行为，因为已经制定了Java标准来匹配大多数用例，然后执行比一般的程序员代码好...）。

因此，在您的情况下，您应该查看您所需的功能，使用最简单的方法（快速）来满足您的功能，并使POC进行一些负载测试。

顺便说Tomcat的是应用服务器，它只是没有实现所有的JavaEE的一部分，它只是实现了basique网络相关的功能（servlet中，但默认情况下没有WS或WS REST类型，但这可以很容易地由libs添加）。新的Jboss和Glassfich提供了比Tomcat更大的功能（在部署时易于加载），具有与Tomcat类似的大小和性能。

来源

2012-12-10 18:00:57 Kazaag

我的程序不是一个web服务。它只是监听一个套接字。它期望以特定格式（而不是SOAP或任何其他格式）的消息通过进行web服务调用转发到web服务。我也做了一些处理。 – user93353

我认为性能问题会受到您的网络拓扑和机器硬件的影响，而不是您选择的应用服务器。一些应用服务器（如JBoss）提供了用于创建和管理群集的管理工具，但所有应用服务器都可以使用正确的工具进行类似的设置。也就是说，我认为你会得到一个嵌入式servlet容器，如jetty或grizzly。这将为您提供应用服务器提供的配置和可移植性优势，而无需额外负担您不太需要的EE兼容性任务，并且可以轻松设置您的开发配置。

来源

2012-12-10 18:14:28

你的意思是“配置和便携性”的好处。还需要付出多少努力才能像我描述的那样采用简单的程序并将其修改为在'jetty'或'grizzly'下运行。 – user93353

配置的一个很好的例子是能够通过Jetty xml文件管理线程池设置，例如：http://docs.codehaus.org/display/JETTY/Newbie+Guide+to+Jetty#NewbieGuidetoJetty-ThreadPooloptional –

In修改现有应用程序以使用它的条款，检查关于嵌入Jetty的文档，我想你会发现创建一个类来启动服务器并添加上下文非常简单：http://wiki.eclipse.org/码头/教程/ Embedding_Jetty –

需要一个应用程序服务器 - Java

回答

相关问题