I need some advice on the best way to implement a software that I need to distribute and install on both windows and linux machines.
I have written a small Java messaging application that runs locally on my machine and listens to a particular port for streaming messages. This application pushes the messages onto a JMS queue. My web application then polls the JMS queue (also local) and runs as expected.
I now wish to scale my application significantly. This means I want to be able to distribute a messaging application to other users (potentially anywhere in the world) who can install it then select a port number using a simple user interface and then run the application. This application would perform the same as the messaging application I have written in JAVA. It would process messages on the selected port and then publish them to a queue on my queue server - from which my Java Application would poll the messages.
I am wondering a couple of things...
I am a Java programmer but wonder what would be the easiest way to produce the remote client that can be easily installed on various platforms? I would rather people could download and install rather than dealing with complex platform dependencies. This might mean a Windows installer...
I was thinking of using the AMQP messaging as the backbone - such as RabbitMQ. This is especially important if I decide to shy away from distributing a Java based message application.
Just some thoughts on the approach would be appreciated.
what would be the easiest way to produce the remote client that can be easily installed on various platforms?
Pure Java, with a GUI, deployed using Java Web Start. The user clicks a link, follows the prompts, and the app. is on screen (with automatic update).
Designed by Sun (maintained by Oracle) to be used on Windows, *nix & OS X.
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!
We have multiple java web applications and processes that are deployed on a server. we would like to find a mean to easily monitor these applications and check their status remotely. by motoring we mean the following :
Check if the websites are up, send notifications by email otherwise.
Easily access or display logs in real-time that are located in different places on our servers. Send emails when exceptions occurred and are logged
Issue commands and run scripts that are located on our servers. the os of the server is linux. commands could be like restart tomcat...
? not sure if there are other ideas about monitoring
My question is that is there any application that is already available that provide such functionalities or some of them? if not do you know what API can be used to build such applications (in JAVA).
UPDATE:
The tool should be free
Thanks in advance for any help!
For monitoring Java applications as well as website availability, issuing custom commands in your servers and in general, monitor applications go for a general-purpose monitoring solution, like Pandora FMS. I'll try to answer your questions in order:
Check if the websites are up, send notifications by email otherwise.
Doing a network check to TCP port 80 and parsing a 200 OK response.
Easily access or display logs in real-time that are located in different places on our servers. Send emails when exceptions occurred and are logged
Easy thing to do with the log retrieval feature. Check it out in the wiki.
Issue commands and run scripts that are located on our servers. the os of the server is linux. commands could be like restart tomcat...
I'd suggest using Pandora Agents in this case. Quite powerful, yet very low resource consumption. They allow to do post-actions if your app is down, your CPU is high, or in general terms, anything you can measure happens. Check out the server monitoring more deeply: http://pandorafms.com/monitoring-solutions/server-monitoring/
On Linux, you an use monit. You can use it to any monitor services such as apache as well as wildfly running behind apache. It is actually easy to configure and it also gives all that you have requested.
If you want to monitor java processes, there is nothing better than MoSKito: http://www.moskito.org.
The only problem is that it covers much more, than you stated as your requirements, you will also get:
health thresholds and notifications
detailed performance metrics of your java code
dashboards with most important information about your app
mobile applications to monitor your app on the run
detection of slow transactions in your application
and more more more ;-)
http://www.moskito.org
http://newest.moskito.org/moskito/ (nightly build of the UI)
Step by Step guide: http://blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-1/
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).
I am developing a java based application; its pertinent requirements are listed below
Large datasets exist on several machines on network. my program needs to (remotely) execute a java program to process these data sets and fetch the results
A user on a windows desktop will need to process datasets (several gigs) on machine A. My program can reside on the user's machine. He will execute my program from his machine and initiate the dataset processing on remote machine(s)
Instead of getting the dataset over the network from the remote machine to his machine, he will execute the program on the remote machine and fetch results
The user may have open access to the other machines but ftp is the requirement
Data should not be brought through network to the user's machine.
Users have windows OS
My question(s)
How can I perform this kind of remote process execution ? Any ideas?
I am looking at hadoop; I am working on Windows XP. I was unable to get hadoop working for a single node cluster; I am unable to find good documentation. I therefore haven't quite tested hadoop. Any comments on if I am on the right track?
Any links any of you has found useful for installation of hadoop and trouble shooting?
Thanks in advance for any responses. Do please let me know if I should provide any more/specific details.
-jv
Java has a RMI API that you could use, assuming that you can have a JAVA VM running on your remote machines. That's the lightest weight solution. The next lightest weight would be straight socket communication. After that you're getting into EJB servers or Web Servers, which is probably overkill.
Have a look at how to write web services with Java 6. That allows you to publish a method as a web service with an annotation. A web service client is small and does not require additional software. I found the Idea IntelliJ IDE easy to use, and generated a pure Java 6 client.
Then it essentially boils down to making a "normal" method call, and processing the result.
Keep it simple. Grid software is most likely not what you want.
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.)