从运行 Web 应用程序的 glass Fish 服务器监听 Java 中的串行端口
希望你们能帮助我。
- 我的笔记本电脑上有串行连接的信息。
- 此信息将传递到 Web 应用程序中的业务逻辑 - 在 Glassfish V3.1.1 上运行 [业务规则和数据库读取/持久性发生在此处]
- 根据业务逻辑返回的内容，更新网页（使用 a4j:push）
我的问题是：
- 是否可以使用 glassfish 服务器中的 Java comm 和 RxTx 库来获取串行数据？
- 我想“监听”串行端口，这样当有东西通过时（等待终止字符），信息就会传递到业务逻辑。我不想轮询串行端口（需要实时）
我真的很感激任何答案， 非常感谢
Hope you guys can help me out.
- I have information coming into a serial connection on my laptop.
- This information is passed to the business logic in a web application - running on Glassfish V3.1.1 [business rules and database reading/persistence happens here]
- Depending on what is returned by the business logic, a webpage is updated (using a4j:push)
My questions are:
- Is it possible to use the Java comm and RxTx libraries from a glassfish server to get the serial data?
- I want to "listen" to the serial port, so that when something comes through (wait for the terminating character), then information is passed to business logic. I don't want to poll the serial port (needs to be real time)
I really would appreciate any answers,
Thank you very much
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Java EE 执行此操作的方法是将串行通信代码实现为 JCA 入站资源适配器，然后触发消息驱动的 bean，这将依次触发您的业务逻辑（我想是 EJB 调用），然后触发推送事件 - - 可能通过 JMS。
不太一致的方法是直接在您的 web 应用程序中触发通信线程，例如在 servlet 或应用程序范围的 bean 中。这个解决方案会让 Java EE 架构师哭泣，但会更简单，并且如果您不希望出现并发问题（如果您写入串行端口，就会出现这种情况）或需要在简单的条件下同样工作得很好事务（例如业务层出现乐观锁错误时不需要重放消息）。
The Java EE way of doing this is to implement your serial communication code as JCA Inbound Resource Adapter, than would trigger an message-driven bean, which would in turn trigger your business logic (EJB invocation, I suppose) and then trigger push event -- probably over JMS.
Less conformant way would be to fire communication thread directly in your webapp, e. g. in servlet or application-scoped bean. This solution it will make Java EE architects weep, but will be much more simple and should work equally well in simple conditions, if you don't expect concurrency issues (that would be the case if you'd write to serial port) or require transactions (e. g. message needs not to be replayed in case of optimistic lock error in business layer).