We have some code that must access low level windows XP os calls which do some simple manufacturing machine controls. These are not real time functions- just setup/config type operations.
All the rest of our system is cloud hosted, and is written in ruby on rails. I want to minimize the amount of windows code we have to write, and keep as much of the code running as a browser app. I also want to as much as possibly deploy the code from the rails server, with as little config or specialized setup of the PC's as possible.
I am looking for recommendations to somehow interface browser based html/javascript code to those low level calls, that minimizes the work we have to outside our normal rails framework, and is also fairly simple to set up / learn / etc.
What I would like is to keep everything as a normal web application, that some how can make a call out to some PC code.
These bits of PC code are intended to run on a very limited number of installations on PCs that we have full control of security etc in factory floors.
One way perhaps is to make a small java applet (which can be written in Ruby), but I don't know if you can then communicate between the java applet and javascript?
Another way is to do something with silverlight that just provides a basic interface, again I don't know if silver light allows any kind of communication from the HTML/javascript to the silverlight code.
Another way perhaps is to do something as a firefox plugin not sure at all if this would work...
Another way (I think) is create a .net app that contains a browser control. Then the .net app might be able to load the browser window from our rails server, etc.
What would be really nice, would be if there was some way to simply add a new javascript functions that would handle this low level stuff...
Look forward to your input!
As I interpret your requirements and please correct me if I am wrong, you're looking for a way to modify configuration on a number of factory floor PCs running Windows XP--that manage various manufacturing processes--from a web browser running on an administrator's computer.
If this is correct, you'd need to run a web server on each controller to process HTTP requests, and of course there are lots of options you can choose from, but I'm not sure this is the best path.
If I needed to solve this problem, I'd create a Windows "service" that would monitor a configuration file for changes and reconfigure the controller when they occurred.
Using this approach, you could use SCP or SFTP to copy the config file up to the controller(s) and let them reconfigure themselves. This would be more secure and far more lightweight than a web server.
For information on writing windows services in Ruby, see Running a Ruby Program as a Windows Service?
Related
I am sure this sounds silly, but for a beginner like me, this is cooking my brain up and I am not able to proceed in my quest without clearing this.
Lets say I am building a simple java command line calculator application that takes 2 numbers and an operator as input and returns the operation's result back to the user. Now, I want to build GUI on top of it (similar to like an online calculator). For this, I decided to build a web application so that I can open the application on my browser and use it seamlessly. It leads to the following questions in my head
Will I have to build a web server in java to allow communications between the front end/GUI and the back end? There is no communication with any other networks, its strictly local; yet I am having to create a web server to make this work and that is confusing me. Or do I need one because I decided to build a web application meant to be opened in a web browser? Or is the reason something else entirely?
If I instead decided to build a windows/android/mac/ios application, would I still to bake a web server for communicating? Or can I use something like swings (I know its really primitive) to do this which essentially would allow the GUI to directly communicate with the business logic?
I know front-end languages like javascript allow me to code the entirety of the calculator in itself, and as a result eliminate the need of a web server. However, what if I was building relatively complex application with a backend database, like spotify? (within the same constraint that the application doesn't need to communicate with other applications and all data is stored locally) Would this solution still work?
In brief, I am failing to understand the purpose of building an entire client-server infrastructure even though the entire thing is local and offline(if that makes sense?). Or is my very basic understanding of client-server flawed?
If you want to use a web browser as the tool to interface with your Java app, then you need a web server. The browser is simply an app that tries to make a network connection with another app, and passes some text as defined by the HTTP protocol.
You would have a choice of three scenarios for this:
Write an app that accepts network connections, processes HTTP, and sends back a response.
Write a Java app that uses the very basic web server built into Java 18 and later. Note that this web server is not intended to be a feature-rich or commercial-grade server.
Write a Jakarta Servlet class that runs on top of a Servlet container with a web server. For your needs, either Apache Tomcat or Eclipse Jetty would work well as both the Servlet container and the web server.
For your scenario, the middle option using Java JEP 408 seems most appropriate and easiest.
You said:
There is no communication with any other networks, its strictly local; yet I am having to create a web server to make this work and that is confusing me.
A Border Collie dog herds sheep. That is its most basic basic core mission. Those sheep can be herded across the hills of a mountain range or they can be herded locally within your own farm.
A web browser makes network connections. That is its most basic core mission. Those network connections can be made over the actual network or they can be made locally within a single computer ( a “localhost”).
You said:
Or do I need one because I decided to build a web application meant to be opened in a web browser?
Yes a web application accessed by a web browser needs a web server, by definition.
You said:
If I instead decided to build a windows/android/mac/ios application, would I still to bake a web server for communicating?
Or can I use something like swings (I know its really primitive)
There is nothing “primitive” about Swing. It is a fully-developed feature-rich GUI framework. Swing comes built in with every JDK. And Swing will be supported for many years to come.
However, the design and features of Swing may or may not suit your tastes. And Swing is now in maintenance-mode.
An alternative is JavaFX, now actively developed as the OpenJFX libraries.
To use JavaFX, you must either add the OpenJFX libraries to your project or else deploy to a JDK that comes bundled with the OpenJFX libraries (ZuluFX, LibericaFX, etc.).
to do this which essentially would allow the GUI to directly communicate with the business logic?
Yes the GUI and and your calculator business logic would all be plain Java classes, all peers, all running together within the same JVM.
You said:
I know front-end languages like javascript allow me to code the entirety of the calculator in itself, and as a result eliminate the need of a web server.
Yes. You could cook up JavaScript code to implement your little calculator. This JavaScript could be placed within the text of a file with the HTML of a web page. That web page file could be opened locally by the web browser. Your HTML and JavaScript would render. No web server is needed in this scenario.
But this scenario eliminates Java, and you said you want to (a) write your calculator in Java, and () use a web browser. So we go back to the three options listed above.
You said:
However, what if I was building relatively complex application with a backend database, like spotify? (within the same constraint that the application doesn't need to communicate with other applications and all data is stored locally) Would this solution still work?
Yes you could deploy a database server on your local machine. Then you could find and use a JavaScript binding tool to talk to that database.
But then you would not be using Java and all its goodness. For that scenario I would choose to write a JavaFX app with an embedded Java-based database engine such as H2. This would result in a single all-in-one double-clickable-app solution.
But that would be my choice based on my own preferences and skill set. Other people might choose other solutions.
the purpose of building an entire client-server infrastructure even though the entire thing is local and offline
👉 The “offline” part may be distracting you.
Conventional computers with modern operating systems such as macOS, BSD, Linux, Windows, etc. are always “online” in that they all maintain a networking stack. That network stack can be used locally by processes within the one computer to communicate with each other. Whether you happen to have an Ethernet cable plugged in, or WiFi turned on, makes little difference to the computer. The networking stack in the OS is still available and active regardless of outside network access.
So client-server architecture works just as well within a single computer as it does between computers. (Actually, it’s works faster locally, as hopping on and off the network is terribly slow.)
Why choose client-server architecture for a local app? Either:
You are skilled in, and prefer, the tools for a client-server architecture.
You want to eventually move from local-only to being networked.
If neither of those two is true, then the JavaFX with H2 solution I mentioned is likely a better fit for a Java programmer.
By the way, let me put in a plug for Vaadin Flow, a GUI framework for building web apps in pure Java.
It's not completely necessary to bake web server to host your application even with embedded tomcat application you can host your application. However, main purpose of webserver usage is for setting up your reverse proxy so that your application behind that won't be exposed and your webserver will be acting as endpoint to outside requests.
In case for hosting application in local webserver is not at all required webserver will come handy when your application hosted in production environment.
I have a question about how to manipulate files from the browser, currently we are using a java applet. To create some folders, replace/delete save some files/folders and execute a shell command with parameters. As we know Chrome no longer supports the npapi and therefor java applets, FireFox will soon follow and my guess is that IE will not stay behind forever.
So the actual question is what's the best way to go?
Should we think about creating plugins (but this then should be done for all major browsers - a lot of work)
Or do you recommend to install an external program, what we can launch on the users system? By for instance associating a specific extension, or by adding a url scheme?
What about this Java Web Start? Does this allow us to communicate with the domino api?
Any other technologies that would be better?
The website we are building is using IBM Domino 9.0.1 XPages (JSF).
Answering to your use case: content management system.
For adding files the HTML5 files API should do all you need. There are plenty of examples including multi file uploads.
It gets trickier when you want to provide a round-trip edit experience. Like you click something and Word, Excel, Impress, Photoshop opens and you edit. When you save it all goes back to Domino.
The solution here is wevDAV. You can even expose Domino views as folders in Explorer / Finder / Nautilus.
For Domino there is a project on OpenNTF that implements WebDAV for documents/attachments on Domino (I wrote it). It might be your best bet.
I think we should be making a distinction here:
things like file access can be done using HTML5 file access, but
things like local administration definitely aren't something that need or should be done from within the browser.
In fact, I always hated that Java suggested that users "need not install any software" to do this and that on their machine, which was a straight lie, considering they downloaded Java Software, had to tell their Java Policy framework to trust that and then that software was able to make local changes. That's just as unsecure as downloading any (signed) executable and making your user execute it.
Java's portability¹ doesn't apply to your use case, as it seems; "executing a shell command" sounds as non-portable as it gets. So, in the end, you either only have one platform you address, or one solution for every platform, in which case you gain no portability by the fact that the same Java executable can run on all JREs (given that's the case, even).
I'd say: It's a good time to let Java for Desktops die, especially since you don't seem to be doing anything that Java is good at² in your application.
As it sounds, the average installer framework can do what you want without you writing any code. There's plenty out there, especially for Windows, which you seem to be addressing; take microsoft's .MSI as an example. You'd end up with a two click, signable, trustable, updateable solution that wouldn't need the user to keep a JRE installed or secure at all.
CLARIFICATION: I really don't hate Java; I don't find it's the greatest language or has the best ecosystem, but whatever makes your application work is fine.
Now, you mention:
To be clear, we are creating a Document Managing System, which used to be on the Lotus Notes client and that we are trying to port to the Web.
That does in fact sound like it might be a good idea to chose any browser and embed that. In fact, Firefox is "merely" an application around a browser core, and you might just modify it (e.g. by writing an extension) to fit your needs. It's not really a "web application", that way, but it would meet your requirements of integration with a web application and local administrative access. I furthermore recommend thinking twice about the shell scripts you need to run locally -- maybe their job can be more easily replaced by another program or even something that is "web compatible" than calling them with local privileges from your web application.
¹ (which was a big thing back in the day, but honestly, Java applications nowadays are about as portable as your average .Net or Qt based application on desktop OSes, but never quite feel completely like home -- it's like portabilities ugly sister if you're portable, but only offer the minimal common subset of functionality and look and feel on each platform)
² ... whatever that might be!
I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!
JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.
try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.
Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.
In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.
I work on a standalone Java application that is a command-and-control system for an assortment of hardware. The C&C software basically runs from a command line, and controls the system hardware which is spread out all over the place. It does not require a GUI to meet the business requirements. I have written a small swing GUI just so I can see what the overall status is of the system, but again, that is not essential.
Going forward, we would like to have a Administrative web GUI with system status and something that would give a user some level of control over the hardware. We were thinking that GWT might be a viable solution. Our GWT app would have to have some sort of IPC with the C&C software. I don't know how viable that is, I don't know that we want the C&C software bundled as a web app that has to run under application server.
I just don't have much experience with this. I was thinking that the GWT client would interact through RPC with the GWT server, and the GWT server would have some sort of RPC (RMI???) with the C&C.
Another option you have is to run a Java Applet that can interact with both GWT (using JSNI) and with the OS. A simple example would be to open a common file in the user's home folder and read/write to that file (with the C&C app doing the same as well).
You can embed embedded tomcat or Jetty into your application and let it run a simple servlet/JSP - based or GWT-based web UI. In fact, when you debug/run your GWT application from Eclipse, it starts in an embedded Tomcat instance.
I found a solution by using Spring. We have modified much of our Command and Control app to use Spring IoC, and then we used other Spring libraries to extend its functionality. To interact with GWT, we exposed services and used httpInvokers to make calls from the GWT server code.
Of course, this meant we needed to use Spring with our GWT application too in order to make the http calls from the GWT server code. But all is working.
you dont have direct control on the client system with JavaScript (which GWT is based on). in your use-case that wouldn't even make sense, why using an external server for a website controlling a local program?
If you reverse this (the app server is running on the same system as the C&C software, and the web client is available from everywhere) than that would be possible, but that wouldn't have much to do with GWT. On the server you can write normal java code. GWT just would be used for the web GUI and the RPC-calls to the server.
The call to the C&C software from the app server could be realised with the following line (windows example):
Runtime.getRuntime().exec("C:\\PathTo\\Program.exe")
This function return a instance of class Process which provides an Input- and OutputStream to simulate user input and to read and process the programs output.
Please note that you lose platform independence with this method, because the parameter for exec() looks different for every OS.
EDIT
After re-reading your question, it would even make more sense to integrate the C&C software into the server code directly, as the comment on your question suggests. you need a application server to use GWT-RPC, not a webserver, but thats hairsplitting.
Informations on how GWT-RPC generally works can be found here: (tutorial), (detailed description)
Is there a way i can use an access database from my Blackberry Curve?
All i want is to be able to open the DB, open table and run queries.
How?
Thanks,
I'm not sure that's going to be possible due to the size of the engine needed to interface with Microsoft Access. Perhaps something like SQLite would be better? If you already have data in Access, then transforming it into something like SQLite first?
As a general rule you have to either adopt some web based technology, or at least get your hands on some developer tools that work on the particular product in question.
Obviously access does and run on Linux or a Mac Computer. Obviously word or excel does not run on your smartphone either.
However most smartphones do support web based technologies or have some type of web browser.
Access 2010 allows you to build web based applications. I'm currently testing and playing with some of my access applications on an apple iPad right now, and they work great.
For couple small little forms, it's probably likely cheaper and better to adopt some web based development tools like asp.net, but this is all going to come down to what type of infrastructure and web servers and other resources you have at your disposal within your organization to bring into play here.
You can take a look of the following video of mine, and you'll notice at approximately the halfway point, I switch to running the access application 100% inside of a standard based web browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
So Access 2010 + sharepoint allows you to build 100% browser neutral based applications. This means no ActiveX or even Silverlight is required. Thus the resulting access application will run inside most modern browser, and this includes most smartphones.