我正在处理执行以下操作的服务器应用程序：
我当前的原型是一个独立的Java应用程序，通过将数据写入通过Web服务器（Apache）传递给客户端的XML文件来实现任务（4），但我认为这是一个黑客攻击，不是一个干净的解决方案
此服务器应用程序需要在没有任何Web客户端的情况下启动和工作。
我想将此服务器应用程序集成到Java应用程序服务器中，但我对这些技术没有太多经验，也不知道从哪里开始。我已经为TomCat和GlassFish尝试了一些简单的例子，但这并没有让我更进一步，因为它们都是围绕同步服务Web请求而构建的，并且停止了对我来说有趣的地方。
这可以在TomCat或GlassFish中运行这样的应用程序吗？
如果是，那么开始的好点（示例，基类，......）？
分割应用程序并在servlet中实现task（4），普通应用程序中的其余部分，通过套接字进行通信等等，是否有意义？
其他服务器，例如JBoss，是否是更好的选择，如果是，为什么？
编辑：
我想使用Java EE容器的原因是：
我想为步骤（4）设置一个干净的外部界面。
从长远来看，应用程序需要扩展到大量的并发客户端（至少几个10.000），因此需要一种标准的可扩展性和应用程序管理方式。
答案 0 :(得分：1)
我会松散地结合解决方案而不是尝试在Java EE / Servlet容器上做所有事情，因为使用套接字（由应用程序本身管理）交换数据不是您通常想要从Java EE / Servlet容器中执行的操作。
在Java EE容器上运行它也可能过度，因为这听起来不像典型的企业应用程序，其中安全性和事务管理之类的东西很重要，应用程序可以从Java EE / Servlet容器提供的服务中受益。
答案 1 :(得分：1)
通常，在诸如Tomcat之类的servlet容器中实现所有这些并不是一个好主意。
servlet容器旨在为来自客户端的请求提供服务。听起来你有一个将一直运行或至少定期运行的进程。您可以在Tomcat中执行此操作，但在外部执行此操作可能更容易。让Tomcat做好它的擅长，为浏览器的请求提供服务。当请求很短暂时，这是最快乐的。
所以我会按照你的建议做，并且只在容器中有第4步。您可以轻松查询在步骤3中填充的数据库，因此无需创建Web服务来填充servlet容器。
对于第4步，您需要通过休息，肥皂以及任何您喜欢的方式公开来自Tomcat的一些服务。然后，javascript客户端可以查询这些服务。这完全可以用Tomcat完成。
对于可伸缩性，使用Tomcat应该没有问题。如果它所做的只是将数据从数据库泵送到客户端，那么可能没有理由选择J2EE容器。如果您不需要复杂的事务管理或安全性，请尝试使用开源的东西。听起来你可以从Tomcat得到你想要的东西（如果需要的话，还可以使用hibernate＆amp; spring security）。如果你开始遇到性能问题，那么JBoss＆amp; amp; Tomcat：你需要更多的服务器。
我的建议：坚持使用简单的开源解决方案，只有在您认为有必要时才转移到应用服务器。