来自 Web 应用程序的硬件支持
我有一个正在运行的网络应用程序，支持某些特定的硬件。这是通过以下步骤实现的：
- 用户运行一个小型安装程序，其中放置 java 文件（以及几个 其他）在客户端计算机上。主要部分是一个名为“hardwareManager”的 jar
- 用户访问 Web 应用程序。该 Web 应用程序运行一个 Java 小程序，由于 安装期间放置的 .java.policy 文件具有以下权限 与浏览器沙箱之外的客户端计算机进行交互。
- 小程序检查以确保 hardwareManager 正在运行， 如果没有运行命令来启动它。
- 用户与 Web 应用程序交互，该应用程序通过以下方式向小程序发送命令 JavaScript。然后小程序将命令写入文本文件 在客户端机器上。该文本文件由 hardwareManager 运行它读入的任何命令。
这可以工作，但看起来很笨重。我对如何改进它有一些想法，但我不知道哪些（如果有的话）值得尝试。
将 hardwareManager 设置为套接字服务器并让小程序直接连接到它而不是通过文本文件会更好吗？这可能吗？
有没有办法完全消除小程序并让 javascript 直接与 hardwareManager 对话？也许通过将 hardwareManager 编写为本地 http 服务器？它应该在什么端口上运行？ javascript xss 限制是否适合这里的某个地方？
I have a web application running with support for some specific pieces of hardware. This is achieved in the following steps:
- User runs a small installer that places java files (and a couple
others) on the client machine. The main piece is a jar called "hardwareManager" - User visits web app. The web app runs a java applet which, due to
a .java.policy file placed during the install, has permission to
interact with the client machine outside the browser sandbox. - The applet checks to make sure the hardwareManager is running,
and if not runs a command to start it. - User interacts with the web app which sends commands to the applet via
javascript. The applet then writes commands to a text file
on the client machine. The text file is constantly monitored by the
hardwareManager which runs any commands it reads in.
This works, but seems clunky. I have a couple ideas on how to improve it, but I don't know which, if any, are even worth trying.
Would it be better to set up the hardwareManager as a socketServer and have the applet connect directly to it, rather than going through text files? Is that even possible?
Is there a way to eliminate the applet altogether and have the javascript talk directly to the hardwareManager? Maybe by writing the hardwareManager to be a local http server? What port should it run on? Do javascript xss limitations fit in here somewhere?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 Java Web Start 启动 Java 应用程序会不会那么笨重。这将消除守护进程或安装 Java 硬件管理器的需要。
另一种选择是使用 Java 中的内置浏览器。我认为这不是一个选择，因为您严重依赖 Javascript（我想提供丰富的客户端体验）。
如果您已经必须在客户端计算机上安装某些内容，为什么选择使用 Web 应用程序？
经验之谈：我们有一个 Java EE 应用程序，需要打印到客户端的 PoS 打印机。我们安装了一个小型“同步器”应用程序，它通过 SSH 连接并同步所有客户端文件。然后，它加载 JAR 并执行程序。该程序通过 RMI 与服务器连接，并订阅 JMS 队列以接收打印分配。
适用于您的案例：为什么不让您的 Java 应用程序直接连接到服务器？您可以使用 HTTP、SOAP 甚至基于 RMI 的 JMS。然后，您可以从服务器（而不是从有限的 JavaScript Web 浏览器环境）启动硬件命令。通过这种方式，您可以获得大量功能：身份验证、命令缓冲，甚至可以在多个客户端之间共享硬件。
示意图：
您可以使用 Java Web Start 启动 Java 应用程序，这允许您自动更新应用程序（而不需要向每个客户端传递新的安装程序）。
It would be less clunky to start the Java application using Java Web Start. This would remove the need to daemonize or install the Java hardware manager.
Another alternative is to use a built-in browser inside Java. I supose this is not an option, since you depend heavily on Javascript (I suppose to provide a rich client experience).
If you already have to install something on the client machine, why did you make the choice to go with a web application?
Talking from experience: We had a Java EE application which needed to print to PoS printers at the client site. We installed a small "synchronizer" application that connects through SSH and synchronizes all clients files. Afterwards, it loads the JAR and executes the program. This program connects through RMI with the server and subscribes to a JMS queue to receive the print assignments.
Applied to your case: Why not let your Java application connect to the server directly? You can use HTTP, SOAP or even JMS over RMI. You can then launch the hardware command from the server (instead of from the limited JavaScript webbrowser environment). This way, you get tons of features: authentication, buffering of commands, and you can even share hardware between multiple clients.
Schematic:
You can launch the Java application using Java Web Start, which allows you to update the application automatically (instead of needing to pass every client a new installer).