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?
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:
<----AJAX------> Web browser
ApplicationServer
<---HTTP/SOAP--> Java hardware manager application
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).
Related
I'm working on a Project which aims to develop an app for a bloomberg anywhere subscriber. We have a Framework available, which we usually use to write our apps. These run ususally on a cloud as webapplications.
As apps using bloombergs open API can only run on the same machine as the subscriber is logged in biometrically, due to data acess restrictions and prohibition to distribute the data further, we plan to run our framework locally on the clients machine as a desktop application, in order to use the tools we are familiar with.
the back-end, which would use the bloomberg open api to get the data from the local interface provided by the local bloomberg-software, runs on a tomcat-server. the frontend is a javascript client, accessing the back end via API-calls locally.
My Questions are:
As bloomberg data-access is very restrictive, i'm wondering whether the bloomberg-interface accepts calls which come from a server software (like tomcat), even when running on the same machine an not used to distribute the data further?
Would set-up: framework running on a second machine (linux, its easyer to run there), calls Bloomberg Port on first machine via private local network, data not leaving second machine, be possible 1. technically and 2. legally?
Does anybody know that? Any advice highly appreciated, many thanks in advance!
Our app heavily makes use of applets to check-in (upload) and check out (download) files from users machine. Can someone please confirm what are the alternatives for applet (as it is going to be deprecated by Oracle in 2018)?
We had the same problem. We were using applets in our web application for printing, scanning etc. on local machines. We solved the problem with a simple Java Web Start client application that has a simple web server embedded (Jetty). Now when user starts the web application the client application is downloaded, if necessary, and started on the local machine. It sits there in a tray and listens for requests from the server side application. Handlers are implemented for different types of requests. When client side receives a request, it hands it over to a responsible handler, which executes its task and creates a response, that is sent back to the server side.
For now, this solution works perfect and we could reuse most of the applet code.
I have a simple cloud IDE,I want to make it able to build and run applications remotely, the target application's source files will be in a remote server in isolated virtual machine (e.g Windows 8.1,or Ubuntu 14.04). It's not difficult to build that application but how to run it and view its output to users ?
What if it's a desktop application (suppose it's written in C# or Java or Python)?
Note: users access there applications only using browsers (e.g Firefox,Chrome,...)
Edit: desktop application may contains GUI stuff not only console ;)
You need a web application.Now this web application when loads send request to backend code that backend code will do SSH to remote machine and read the file from specific location.Now that read stream will be send back in response and displayed on web based UI. In these type of application few thinks matters.
1) Like if you whole file at once then it will take time to display that content to user.Better idea will be read around 100 lines at once and when user scroll down then again send request to web server to read next 100 lines in this way you can decrease response time and better user experience.
Each of the languages you mentioned offers a Web Services framework of some kind. Pick one, and implement something that a) starts your app, b) shows the output. Depending on the processing time (how long it takes to complete) you might even get away with just one.
You can go for a self-contained, standalone service:
C#: Is it possible to create a standalone, C# web service deployed as an EXE or Windows service?
Python:
Best way to create a simple python web service
Java:
https://technology.amis.nl/2009/06/05/publish-a-webservice-from-a-poja-plain-old-java-application-that-is-out-of-the-container-using-endpoint-class/
Alternatively, you might use a container (server) for your app, like Apache with mod_mono or IIS for C#, Tomcat, Jetty, Jboss for Java, Apache with mod_wsgi for Python (just examples).
The web service would probably sit on the remote machine, so it could use system calls ('command line') to run your core app, and then it would send the results over http. Since you mention GUI, there could be more layers to the solution:
The GUI - static HTML, desktop app, sending requests to the 2nd layer, say displaying dropdowns for parameter1 and -2
The Web Service - takes the params from the request, say http://remote.machine.land/start/app?parameter1=X¶meter2=Y, runs a local command like /home/users/myapp.sh -parameter1=X -parameter2=Y
The application itself - not necessarily aware of any internet out there.
This way you stay free to change/enhance any part at a time, call the 2. layer programmatically, introduce load-balancing, etc.
3.
I developed a stand alone application for a medical channelling centre with VB6 seven years ago. There is a mandatory requirement of printing of a chit with a small size(219mm to 140mm) with a single click without the print dialog. Intermittently they need to take reports to full A4 pages from a different printer.
This could be easily achieved in VB6 with setting the printed and paper properties in variables. Now the center want to convert it into a web application, but beforehand they want to make sure that the printing capabilities can be achieved in such web application. They want specifically not to bring the printer dialog box every time.
Is it possible to change printer and paper properties in a web application with Java EE without bringing the printer dialog?. (at least with the support of Jasper reports, etc)
It is possible; however, you need to keep in mind which application would be printing.
If it is the web browser that is printing the web page, you are out-of-luck, as the web browser is already coded and will do exactly what it will always do.
If it is an application embedded within the web page, provided the application can connect to the client machine's printing resources, it is possible; however, often such a task implies that the application is trusted as a remote machine (the web server) is now using local resources (client disk and printing configurations). You may need to pre-configure the machine to elevate that application's level of trust, or you might get a popup declaring that a remote machine (the web server) is trying to use local resources.
If it is a multi-tiered application, and the web server receives the request to print from the web application, then the web server will be doing the printing. The web server trusts itself; however, its environment might be quite different. It may or may not have access to connect to nearby printers, depending on the rest of the network architecture and security policies.
I've got the following problem.
A client is looking for better latency to access a forex trading java web app (.jnlp) that is stored on a third party server. I can provide him access to one of our servers (running linux) that is geographicaly closer to the trading portal (rather than connecting directly to the trading server, less latency, which is critical to the client).
I'm trying to find a way to 'export' the web app interface (basically a simple window) back to the client without having to export the full desktop (using vnc, x export, etc). The client is new to linux and a 'one-click' solution would be the best.
Client is running Windows based OS, Server that will export him the java web app is running linux (debian).
What would be the best mix of technologies to get started ?
I think what you actually need is not better latancy to the jnlp app itself (it is propably insignificant really how long the app needs to start up).
You want lower latancy for the communication between the app and the trading server. Which means the machine on which the app runs, needs a broad/fast connection to the trading server.
This means any remote desktop application might be a solution to your problem.
(TeamViewer for example allows you to only share a single application (and not the whole desktop). Runs on linux using wine, but I'm not aware of all the compatibility issues.)