将 Java 服务器应用程序集成到应用程序服务器中，例如 TomCat、GlassFish 等
我正在开发一个执行以下操作的服务器应用程序：
- 从通过串行接口（javax.comm、RXTX）或套接字寻址的测量设备读取数据。
- 使用套接字与另一个服务器应用程序交换数据（读和写）。
- 使用 JDBC 将 (1) 和 (2) 中的数据插入数据库。
- 将步骤 (1) 到 (3) 中的数据提供给基于 JavaScript 的 Web 应用程序。
我当前的原型是一个独立的 Java 应用程序，通过将数据写入通过 Web 服务器 (Apache) 传送到客户端的 XML 文件来实现任务 (4)，但我认为这是一种 hack，而不是干净的解决方案。
该服务器应用程序也需要在没有任何 Web 客户端的情况下启动和工作。
我想将此服务器应用程序集成到Java应用程序服务器中，但我对这些技术没有太多经验，不知道从哪里开始。我已经尝试了 TomCat 和 GlassFish 的一些简单示例，但这并没有给我带来任何进一步的帮助，因为它们都是围绕同步服务 Web 请求构建的，并在我感兴趣的地方停止。
是否可以在 TomCat 或 GlassFish 中运行此类应用程序？
如果是，从哪里开始比较好（示例，哪些基类，...）？
拆分应用程序并在 servlet 中仅实现任务 (4)，其余部分在普通应用程序中、通过套接字进行通信等是否有意义？
其他服务器（例如 JBoss）是否是更好的选择？如果是，为什么？
编辑：
我想要使用 Java EE 容器的原因是：
我希望为步骤 (4) 提供一个干净的外部接口。
从长远来看，应用程序需要扩展到大量并发客户端（至少数 10,000 个），因此需要一种可扩展性和应用程序管理的标准方法。
I am working on a server application that does the following:
- Read data from a measuring device that is being addressed via a serial interface (javax.comm, RXTX) or sockets.
- Exchange data (read and write) with another server application using sockets.
- Insert data from (1) and (2) into a database using JDBC.
- Offer the data from steps (1) to (3) to a JavaScript-based web app.
My current prototype is a stand-alone Java application and implements task (4) by writing the data to an XML file that is being delivered to the client via a web server (Apache), but I consider this to be a hack, not a clean solution.
This server application needs to start up and work also without any web clients being present.
I would like to integrate this server application into a Java application server, but I do not have much experience with these technologies and don't know where to start. I have tried some simple examples for TomCat and GlassFish, but that did not bring me any further because they are all built around serving web requests synchronously and stop where it would be getting interesting for me.
Is this possible to run such an app within TomCat or GlassFish?
If yes, where would be a good point to start (examples, which base classes, ...)?
Would it make any sense to split the application and implement only task (4) in a servlet, the rest in an ordinary application, communication via sockets, etc.?
Would other servers, e.g JBoss, be a better choice and if yes, why?
Edit:
The reasons I want to use a Java EE container are:
I would like to have a clean external interface for step (4).
On the long run, the application will need to scale to a huge number of simultaneous clients (at least several 10.000), so a want a standard way of scalability and application management.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，在 Tomcat 等 Servlet 容器中实现所有这些并不是一个好主意。
Servlet 容器旨在为来自客户端的请求提供服务。听起来您有一个一直运行或至少定期运行的进程。您可以在 Tomcat 中执行此操作，但在外部执行此操作可能更容易。让 Tomcat 做它擅长的事情，为来自浏览器的请求提供服务。当请求是短暂的时，它是最快乐的。
所以我会按照你的建议做，并且容器中只有步骤 4。您可以轻松查询步骤 3 中填充的数据库，因此无需创建 Web 服务来填充 servlet 容器。
对于第 4 步，您需要通过 Rest、soap 或任何您喜欢的方式从 Tomcat 公开一些服务。然后 JavaScript 客户端可以询问这些服务。这一切都可以通过 Tomcat 完全实现。
对于可扩展性来说，使用 Tomcat 应该不会有问题。如果它所做的只是将数据从数据库传送到客户端，那么可能没有理由选择 J2EE 容器。如果您不需要复杂的事务管理或安全性，请尝试使用开源的东西。听起来你可以从 Tomcat 得到你想要的东西（如果需要的话还有 hibernate 和 spring security）。如果您开始遇到性能问题，那么 JBoss 和 JBoss 的修复方法可能相同。 Tomcat：您需要更多服务器。
我的建议：坚持使用简单的开源解决方案，仅在您认为有必要时才迁移到应用程序服务器。
In general, it's not a good idea to implement all of this in a servlet container such as Tomcat.
A servlet container is designed to service requests from a client. It sounds like you have a process which will be running all the time or at least periodically. You can do this in Tomcat, but it's probably easier to do it outside. Leave Tomcat to do what it's good at, servicing requests from browsers. It's happiest when the requests are short lived.
So I would do as you suggest, and only have step 4 in the container. You can easily interrogate the database populated in step 3, so there is no need to create web services to populate the servlet container.
For step 4, you will need to expose some services from Tomcat, either through rest, soap, whatever you like. The javascript clients can then interrogate these services. This is all completely doable with Tomcat.
For scalability, there shouldn't be a problem using Tomcat. If all it's doing is pumping data from the database to the client, there probably isn't a reason to choose a J2EE container. If you don't have need of complex transaction management or security, try using something open source. It sounds like you can get what you want from Tomcat (& hibernate & spring security if necessary). If you start to have performance problems, then the fix will probably be the same for JBoss & Tomcat: you need more servers.
My advice: stick to the simple open source solutions and move to an application server only if you find it to be necessary.
我会松散地耦合解决方案，而不是尝试在 Java EE/Servlet 容器上执行所有操作，因为使用套接字（由应用程序本身管理）交换数据并不是您通常希望从 Java EE/Servlet 容器执行的操作。
在 Java EE 容器上运行它也可能有点过头了，因为这听起来不像典型的企业应用程序，其中安全性和事务管理等内容很重要，并且应用程序可以从 Java EE/Servlet 容器提供的服务中受益。
I would loosely couple the solution and not try to do everything on the Java EE/Servlet container as exchanging data using sockets (managed by the application itself) is not something you typically want to do from a Java EE/Servlet container.
Running this on a Java EE container might also be overkill as this doesn't sound like a typical enterprise application where stuff like security and transaction management is important and the app could benefit from services provided by the Java EE/Servlet container.